[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6J79ZKXS1YSY0DXSVPM3TBS":3,"skill-same:01M6J79ZKXS1YSY0DXSVPM3TBS":105},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6J79ZKXS1YSY0DXSVPM3TBS","deep-implement",null,"Implements code from \u002Fdeep-plan section files with TDD methodology, code review, and git workflow. Use when implementing plans created by \u002Fdeep-plan.","LUAgam\u002Fagent-delivery","LUAgam","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F17228757?v=4","01M6J6SXFE8K594FYSKADACG8A","LUA","01M6J6SXKRXPD3511T0QQX2JE7",1,"MIT","https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fdeep-implement\u002Fskills\u002Fdeep-implement\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"deep implement","implement","deep","methodology","implementing","with","plans","files","uv","use","plan","code review","repository","git","code","git workflow","workflow","tdd","python","review","2026-11-10 10:12:30",false,"---\nname: deep-implement\ndescription: Implements code from \u002Fdeep-plan section files with TDD methodology, code review, and git workflow. Use when implementing plans created by \u002Fdeep-plan.\nlicense: MIT\ncompatibility: Requires uv (Python 3.11+), git repository recommended\n---\n\n# Deep Implementation Skill\n\nImplements code from \u002Fdeep-plan section files with integrated review and git workflow.\n\n## CRITICAL: First Actions\n\n**BEFORE using any other tools**, do these in order:\n\n### A. Print Intro Banner\n\n```\n⚠️  CONTEXT WARNING: This workflow is token-intensive. Consider compacting first.\n\n═══════════════════════════════════════════════════════════════\nDEEP-IMPLEMENT: Section-by-Section Implementation\n═══════════════════════════════════════════════════════════════\nImplements \u002Fdeep-plan sections with:\n  - TDD methodology\n  - Code review at each step\n  - Git commits with review trails\n\nUsage: \u002Fdeep-implement @path\u002Fto\u002Fsections\u002F.\n\nNote: deep-implement creates a large TODO list. Expand your window to avoid flickering\n═══════════════════════════════════════════════════════════════\n```\n\n### B. Validate Input\n\nCheck if user provided @directory argument ending with a path to a `sections\u002F.` directory.\n\nIf NO argument or invalid:\n```\n═══════════════════════════════════════════════════════════════\nDEEP-IMPLEMENT: Sections Directory Required\n═══════════════════════════════════════════════════════════════\n\nThis skill requires a path to a sections directory from \u002Fdeep-plan.\n\nExample: \u002Fdeep-implement @path\u002Fto\u002Fplanning\u002Fsections\u002F.\n\nThe sections directory must contain:\n  - index.md with SECTION_MANIFEST block\n  - section-NN-\u003Cname>.md files for each section\n═══════════════════════════════════════════════════════════════\n```\n**Stop and wait for user to re-invoke with correct path.**\n\n### C. Discover Plugin Root\n\n**CRITICAL: Locate plugin root BEFORE running any scripts.**\n\nThe SessionStart hook injects `DEEP_PLUGIN_ROOT=\u003Cpath>` into your context. Look for it now — it appears alongside `DEEP_SESSION_ID` in your context from session startup.\n\n**If `DEEP_PLUGIN_ROOT` is in your context**, use it directly as `plugin_root`. The setup script is at:\n`\u003CDEEP_PLUGIN_ROOT value>\u002Fscripts\u002Fchecks\u002Fsetup_implementation_session.py`\n\n**Only if `DEEP_PLUGIN_ROOT` is NOT in your context** (hook didn't run), fall back to search:\n```bash\nfind \"$(pwd)\" -name \"setup_implementation_session.py\" -path \"*\u002Fscripts\u002Fchecks\u002F*\" -type f 2>\u002Fdev\u002Fnull | head -1\n```\nIf not found: `find ~ -name \"setup_implementation_session.py\" -path \"*\u002Fscripts\u002Fchecks\u002F*\" -path \"*deep*implement*\" -type f 2>\u002Fdev\u002Fnull | head -1`\n\n**Store the script path.** The plugin_root is the directory two levels up from `scripts\u002Fchecks\u002F`.\n\n### D. Determine Target Directory\n\nThe target directory is where implementation code will be written. Check if a previous session exists with a saved target:\n\n```bash\n# Check for existing config\ncat \"{sections_dir}\u002F..\u002Fimplementation\u002Fdeep_implement_config.json\" 2>\u002Fdev\u002Fnull | grep -o '\"target_dir\": \"[^\"]*\"'\n```\n\n**If config exists with target_dir:** Use that value (skip the prompt).\n\n**If no config or no target_dir:** Get current working directory and ask user:\n\n```bash\npwd\n```\n\n```\nAskUserQuestion:\n  question: \"Where should implementation code be written?\"\n  options:\n    - label: \"{cwd}\"\n      description: \"Current working directory (Recommended)\"\n    - label: \"Specify path\"\n      description: \"Enter a different absolute path\"\n```\n\nIf user selects \"Specify path\", they will type the absolute path.\n\n**Store target_dir** for use in setup script.\n\n### E. Run Setup Script\n\n**First, check for session_id in your context.** Look for `DEEP_SESSION_ID=xxx`\nwhich was set by the SessionStart hook. This appears in your context as additional context.\n\nRun the setup script with discovered paths:\n```bash\nuv run {script_path} \\\n  --sections-dir \"{sections_dir}\" \\\n  --target-dir \"{target_dir}\" \\\n  --plugin-root \"{plugin_root}\" \\\n  --session-id \"{DEEP_SESSION_ID}\"\n```\n\nIf `DEEP_SESSION_ID` is not in your context, omit `--session-id`\n(setup will fall back to `DEEP_SESSION_ID` env var).\n\nParse the JSON output.\n\n**If `success == false`:** Display error and stop.\n\n**Session ID diagnostics in output:**\n- `session_id`: The session ID being used for tasks\n- `session_id_source`: Where it came from (\"context\", \"env\", or \"none\")\n- `session_id_matched`: If both context and env were present, whether they matched (useful for debugging)\n\n### F. Handle Branch Check\n\nIf `is_protected_branch == true` (setup script detects main, master, release\u002F* branches):\n```\nAskUserQuestion:\n  question: \"You're on the {current_branch} branch. Committing here may not be ideal.\"\n  options:\n    - label: \"Continue on {current_branch}\"\n      description: \"Proceed with implementation on this branch\"\n    - label: \"Exit to create feature branch\"\n      description: \"Stop to create a dedicated branch first\"\n```\n\nIf user chooses \"Exit\", stop the workflow.\n\n### G. Handle Working Tree Status\n\nIf `working_tree_clean == false`:\n```\nAskUserQuestion:\n  question: \"Working tree has {N} uncommitted changes. This may cause issues.\"\n  options:\n    - label: \"Continue anyway\"\n      description: \"Proceed with implementation (changes may get mixed)\"\n    - label: \"Exit to commit\u002Fstash first\"\n      description: \"Stop to handle uncommitted changes\"\n```\n\n### H. Print Preflight Report\n\n```\n═══════════════════════════════════════════════════════════════\nPREFLIGHT REPORT\n═══════════════════════════════════════════════════════════════\nTarget dir:     {target_dir}\nRepo root:      {git_root}\nBranch:         {current_branch}\nWorking tree:   {Clean | Dirty (N files)}\nPre-commit:     {Detected (type) | None}\n                {May modify files: Yes (formatters) | No | Unknown}\nTest command:   {test_command}\nSections:       {N} detected\nCompleted:      {M} already done\nState storage:  {state_dir}\n═══════════════════════════════════════════════════════════════\n```\n\n### I. Verify Task List\n\nCheck the setup output for task status:\n\n1. If `tasks_written > 0`: Tasks have been written. Call `TaskList` to see them.\n2. If `task_write_error` is present: Task write failed - log the error and continue with manual tracking.\n3. If no `task_list_id`: Session ID not available - the SessionStart hook may not have run.\n\n**After setup succeeds:** Call `TaskList` to see the implementation tasks.\n\n**Understanding the task list:**\n\nThe task list contains **6 high-level reminders per section**:\n1. Implement section-NN\n2. Run code review subagent for section-NN\n3. Perform code review interview for section-NN\n4. Update section-NN documentation\n5. Commit section-NN\n6. Record section-NN completion\n\nPlus a **compaction prompt every 2nd section** (after 02, 04, 06, etc.).\n\nContext items appear as pending tasks at the start (e.g., `plugin_root=\u002Fpath\u002F...`, `sections_dir=\u002Fpath\u002F...`).\n\nThese are **milestones to track progress**, not detailed instructions. For the actual workflow steps, always refer to:\n- This file (SKILL.md) for the overall orchestration\n- The reference documents in `references\u002F` for detailed protocols\n\nMark each task as `in_progress` when starting: `TaskUpdate(taskId=X, status=\"in_progress\")`\nMark each task as `completed` when done: `TaskUpdate(taskId=X, status=\"completed\")`\n\n---\n\n## Implementation Loop\n\nFor each incomplete section (in manifest order):\n\n**Task milestone mapping:**\n| Task Subject | Workflow Steps |\n|-----------|----------------|\n| Implement section-NN | Steps 1-5 (read, TDD, stage) |\n| Run code review subagent | Step 6 (launch subagent, write review) |\n| Perform code review interview | Steps 7-8 (triage, interview, apply fixes) |\n| Update section-NN documentation | Step 9 (update section file with what was actually built) |\n| Commit section-NN | Step 10 (commit implementation + doc update together) |\n| Record section-NN completion | Step 11 (run update_section_state.py to save commit hash) |\n| Context check (every 2nd section only) | Step 13 (context management options) |\n\n**Note:** Step 12 (Mark Complete) is internal task status update. Step 14 (Loop) continues to next section. Context checks only appear after sections 02, 04, 06, etc.\n\n### Step 1: Mark In Progress\n\nUpdate task: `TaskUpdate(taskId=X, status=\"in_progress\")`\n\n### Step 2: Read Section File\n\n```\nRead {sections_dir}\u002Fsection-NN-\u003Cname>.md\n```\n\n### Step 3: Implement Section\n\nSee [implementation-loop.md](references\u002Fimplementation-loop.md)\n\nFollow TDD workflow:\n1. Create skeleton files for imports\n2. Write tests from section spec\n3. Run tests (expect failures)\n4. Write implementation\n5. Run tests (expect pass)\n6. Handle failures with retry (max 3)\n\n### Step 4: Track Created Files\n\nMaintain list of all files created during implementation.\n\n### Step 5: Stage Changes\n\n```bash\n# Stage new files\ngit add {created_files...}\n\n# Stage modified files\ngit add -u\n```\n\n### Step 6: Code Review (Subagent)\n\nSee [code-review-protocol.md](references\u002Fcode-review-protocol.md)\n\n1. Create `{state_dir}\u002Fcode_review\u002F` directory if it doesn't exist\n2. Write staged diff to `{code_review_dir}\u002Fsection-NN-diff.md`\n3. Launch `code-reviewer` subagent to analyze the diff\n4. Write subagent's review to `{code_review_dir}\u002Fsection-NN-review.md`\n\n### Step 7: Code Review Triage and Interview\n\nSee [code-review-interview.md](references\u002Fcode-review-interview.md)\n\nTriage the review findings and interview the user only on important items:\n\n1. Read the review and use judgment to categorize:\n   - **Ask user:** Decisions with real tradeoffs, security concerns\n   - **Auto-fix:** Obvious improvements, low-risk changes\n   - **Let go:** Nitpicks, pedantic observations\n2. Interview user only on items that need their input\n3. Write transcript with both interview decisions AND auto-fixes to `{code_review_dir}\u002Fsection-NN-interview.md`\n\nThe goal is a useful conversation, not a comprehensive audit.\n\n### Step 8: Apply Fixes\n\nSee [apply-interview-fixes.md](references\u002Fapply-interview-fixes.md)\n\nApply all fixes recorded in the transcript:\n\n1. Read `{code_review_dir}\u002Fsection-NN-interview.md`\n2. Apply user-approved fixes and auto-fixes (if already applied, skip)\n3. Run tests to verify nothing broke\n4. Re-stage modified files\n\n**Recovery:** If compaction happens, the interview file is the checkpoint. Restart applying fixes from the beginning - you'll notice already-applied changes. The commit is the definitive checkpoint.\n\n### Step 9: Update Section Documentation\n\nSee [section-doc-update.md](references\u002Fsection-doc-update.md)\n\n**Before committing**, update the original section file to reflect what was actually implemented:\n\n1. Read `{sections_dir}\u002Fsection-NN-\u003Cname>.md`\n2. Compare planned implementation vs actual:\n   - Code review fixes that changed the approach\n   - File paths that differed from plan\n   - Tests that were added\u002Fmodified\n3. Update the section file with:\n   - Actual file paths created\u002Fmodified\n   - Any deviations from original plan (with rationale)\n   - Final test count and coverage notes\n4. **If sections_dir is inside git_root**, stage the section doc:\n   ```bash\n   git add {sections_dir}\u002Fsection-NN-\u003Cname>.md\n   ```\n   (If sections_dir is outside git_root, skip staging - the doc update lives with the planning files)\n\nThis keeps section files as accurate documentation of what was built, not just what was planned.\n\n### Step 10: Commit\n\nSee [git-operations.md](references\u002Fgit-operations.md) and [pre-commit-handling.md](references\u002Fpre-commit-handling.md)\n\nCommit implementation + doc update together (one commit per section):\n\n1. Create commit message matching detected style\n2. Attempt commit\n3. Handle pre-commit hooks:\n   - If files modified: re-stage and retry (max 2)\n   - If lint error: present options to user\n4. On success: store commit hash in session config\n\n```bash\ngit commit -m \"$(cat \u003C\u003C'EOF'\nImplement section NN: Name\n\n- Very concise summary of features\u002Fchanges\n\nPlan: section-NN-\u003Cname>.md\nCo-Authored-By: Claude \u003Cnoreply@anthropic.com>\nEOF\n)\"\n```\n\n### Step 11: Update State\n\nAfter successful commit, update the session config:\n\n```bash\nuv run {plugin_root}\u002Fscripts\u002Ftools\u002Fupdate_section_state.py \\\n    --state-dir \"{state_dir}\" \\\n    --section \"{section_name}\" \\\n    --commit-hash \"{commit_hash}\"\n```\n\nThis records the commit hash so the section is recognized as complete on resume.\n\n### Step 12: Mark Complete\n\nUpdate task: `TaskUpdate(taskId=X, status=\"completed\")`\n\n### Step 13: Context Check (Every 2nd Section)\n\n**Only prompt after sections 02, 04, 06, etc.** (every 2nd section).\n\nIf this is NOT a 2nd section, skip directly to Step 14.\n\nIf this IS a 2nd section (02, 04, 06, ...):\n\n```\n═══════════════════════════════════════════════════════════════\nSection NN complete and committed.\n═══════════════════════════════════════════════════════════════\n\nCompleted: {M}\u002F{N} sections\nNext: section-{NN+1}-{name}\n\nContext Management Options:\n  1. \u002Fclear + re-run \u002Fdeep-implement (Recommended)\n     - Fresh context with full instructions\n     - Progress preserved via file-based recovery\n\n  2. Continue in current session\n     - Auto-compact triggers at ~95% if needed\n     - May lose some instruction detail after compaction\n\nType \"continue\" or run \u002Fclear and re-invoke \u002Fdeep-implement @{sections_dir}\u002F.\n```\n\nWait for user response. If they say \"continue\", proceed to Step 14.\n\n### Step 14: Loop\n\nRepeat from Step 1 for next section.\n\n---\n\n## Finalization\n\nAfter all sections complete, see [finalization.md](references\u002Ffinalization.md):\n\n1. Generate `{state_dir}\u002Fusage.md` with usage guide for what was built\n2. Print completion summary with commits, files, and next steps\n\n---\n\n## Error Handling\n\n### Test Failures\n\nAfter 3 failed fix attempts:\n```\nAskUserQuestion:\n  question: \"Tests still failing after 3 attempts. How to proceed?\"\n  options:\n    - label: \"Review and debug\"\n      description: \"I'll show you the test and implementation for inspection\"\n    - label: \"Skip section\"\n      description: \"Mark section as skipped and continue to next\"\n    - label: \"Stop implementation\"\n      description: \"Pause to manually investigate\"\n```\n\n### Pre-Commit Failures\n\nSee [pre-commit-handling.md](references\u002Fpre-commit-handling.md)\n\n### Git Commit Failures\n\nIf commit fails (non-pre-commit):\n```\nGit commit failed: {error}\n\nThe staged changes are preserved.\nYou can manually commit with: git commit -m \"message\"\n\nContinue to next section? [y\u002Fn]\n```\n\n### Path Safety Violations\n\n```\n═══════════════════════════════════════════════════════════════\nSECURITY ERROR\n═══════════════════════════════════════════════════════════════\n\nAttempted to write file outside allowed directory:\n  Path: {attempted_path}\n  Allowed root: {git_root}\n\nThis section file may contain invalid paths.\nPlease review the section file.\n═══════════════════════════════════════════════════════════════\n```\n\n---\n\n## Context Recovery\n\n**After `\u002Fclear` + re-run `\u002Fdeep-implement`:**\n\nThe setup script detects completed sections via `deep_implement_config.json` and marks their tasks complete. You'll resume from the next pending section with fresh instructions.\n\n**After compaction (if user chose \"continue\"):**\n\n1. Call `TaskList` to see current state\n2. Find context tasks to recover paths:\n   - `plugin_root=...` - extract value after `=`\n   - `sections_dir=...` - extract value after `=`\n   - `state_dir=...` - extract value after `=`\n3. Find next pending, unblocked task\n4. Resume workflow from that task\n\n---\n\n## Reference Documents\n\n- [implementation-loop.md](references\u002Fimplementation-loop.md) - TDD workflow details\n- [code-review-protocol.md](references\u002Fcode-review-protocol.md) - Subagent review process\n- [code-review-interview.md](references\u002Fcode-review-interview.md) - Interactive interview with user\n- [apply-interview-fixes.md](references\u002Fapply-interview-fixes.md) - Applying fixes from interview\n- [section-doc-update.md](references\u002Fsection-doc-update.md) - Updating section documentation\n- [git-operations.md](references\u002Fgit-operations.md) - Git handling\n- [pre-commit-handling.md](references\u002Fpre-commit-handling.md) - Hook handling\n- [finalization.md](references\u002Ffinalization.md) - Usage guide and completion summary\n","# Deep Implementation Skill\n\nImplements code from \u002Fdeep-plan section files with integrated review and git workflow.\n\n## CRITICAL: First Actions\n\n**BEFORE using any other tools**, do these in order:\n\n### A. Print Intro Banner\n\n```\n⚠️  CONTEXT WARNING: This workflow is token-intensive. Consider compacting first.\n\n═══════════════════════════════════════════════════════════════\nDEEP-IMPLEMENT: Section-by-Section Implementation\n═══════════════════════════════════════════════════════════════\nImplements \u002Fdeep-plan sections with:\n  - TDD methodology\n  - Code review at each step\n  - Git commits with review trails\n\nUsage: \u002Fdeep-implement @path\u002Fto\u002Fsections\u002F.\n\nNote: deep-implement creates a large TODO list. Expand your window to avoid flickering\n═══════════════════════════════════════════════════════════════\n```\n\n### B. Validate Input\n\nCheck if user provided @directory argument ending with a path to a `sections\u002F.` directory.\n\nIf NO argument or invalid:\n```\n═══════════════════════════════════════════════════════════════\nDEEP-IMPLEMENT: Sections Directory Required\n═══════════════════════════════════════════════════════════════\n\nThis skill requires a path to a sections directory from \u002Fdeep-plan.\n\nExample: \u002Fdeep-implement @path\u002Fto\u002Fplanning\u002Fsections\u002F.\n\nThe sections directory must contain:\n  - index.md with SECTION_MANIFEST block\n  - section-NN-\u003Cname>.md files for each section\n═══════════════════════════════════════════════════════════════\n```\n**Stop and wait for user to re-invoke with correct path.**\n\n### C. Discover Plugin Root\n\n**CRITICAL: Locate plugin root BEFORE running any scripts.**\n\nThe SessionStart hook injects `DEEP_PLUGIN_ROOT=\u003Cpath>` into your context. Look for it now — it appears alongside `DEEP_SESSION_ID` in your context from session startup.\n\n**If `DEEP_PLUGIN_ROOT` is in your context**, use it directly as `plugin_root`. The setup script is at:\n`\u003CDEEP_PLUGIN_ROOT value>\u002Fscripts\u002Fchecks\u002Fsetup_implementation_session.py`\n\n**Only if `DEEP_PLUGIN_ROOT` is NOT in your context** (hook didn't run), fall back to search:\n```bash\nfind \"$(pwd)\" -name \"setup_implementation_session.py\" -path \"*\u002Fscripts\u002Fchecks\u002F*\" -type f 2>\u002Fdev\u002Fnull | head -1\n```\nIf not found: `find ~ -name \"setup_implementation_session.py\" -path \"*\u002Fscripts\u002Fchecks\u002F*\" -path \"*deep*implement*\" -type f 2>\u002Fdev\u002Fnull | head -1`\n\n**Store the script path.** The plugin_root is the directory two levels up from `scripts\u002Fchecks\u002F`.\n\n### D. Determine Target Directory\n\nThe target directory is where implementation code will be written. Check if a previous session exists with a saved target:\n\n```bash\n# Check for existing config\ncat \"{sections_dir}\u002F..\u002Fimplementation\u002Fdeep_implement_config.json\" 2>\u002Fdev\u002Fnull | grep -o '\"target_dir\": \"[^\"]*\"'\n```\n\n**If config exists with target_dir:** Use that value (skip the prompt).\n\n**If no config or no target_dir:** Get current working directory and ask user:\n\n```bash\npwd\n```\n\n```\nAskUserQuestion:\n  question: \"Where should implementation code be written?\"\n  options:\n    - label: \"{cwd}\"\n      description: \"Current working directory (Recommended)\"\n    - label: \"Specify path\"\n      description: \"Enter a different absolute path\"\n```\n\nIf user selects \"Specify path\", they will type the absolute path.\n\n**Store target_dir** for use in setup script.\n\n### E. Run Setup Script\n\n**First, check for session_id in your context.** Look for `DEEP_SESSION_ID=xxx`\nwhich was set by the SessionStart hook. This appears in your context as additional context.\n\nRun the setup script with discovered paths:\n```bash\nuv run {script_path} \\\n  --sections-dir \"{sections_dir}\" \\\n  --target-dir \"{target_dir}\" \\\n  --plugin-root \"{plugin_root}\" \\\n  --session-id \"{DEEP_SESSION_ID}\"\n```\n\nIf `DEEP_SESSION_ID` is not in your context, omit `--session-id`\n(setup will fall back to `DEEP_SESSION_ID` env var).\n\nParse the JSON output.\n\n**If `success == false`:** Display error and stop.\n\n**Session ID diagnostics in output:**\n- `session_id`: The session ID being used for tasks\n- `session_id_source`: Where it came from (\"context\", \"env\", or \"none\")\n- `session_id_matched`: If both context and env were present, whether they matched (useful for debugging)\n\n### F. Handle Branch Check\n\nIf `is_protected_branch == true` (setup script detects main, master, release\u002F* branches):\n```\nAskUserQuestion:\n  question: \"You're on the {current_branch} branch. Committing here may not be ideal.\"\n  options:\n    - label: \"Continue on {current_branch}\"\n      description: \"Proceed with implementation on this branch\"\n    - label: \"Exit to create feature branch\"\n      description: \"Stop to create a dedicated branch first\"\n```\n\nIf user chooses \"Exit\", stop the workflow.\n\n### G. Handle Working Tree Status\n\nIf `working_tree_clean == false`:\n```\nAskUserQuestion:\n  question: \"Working tree has {N} uncommitted changes. This may cause issues.\"\n  options:\n    - label: \"Continue anyway\"\n      description: \"Proceed with implementation (changes may get mixed)\"\n    - label: \"Exit to commit\u002Fstash first\"\n      description: \"Stop to handle uncommitted changes\"\n```\n\n### H. Print Preflight Report\n\n```\n═══════════════════════════════════════════════════════════════\nPREFLIGHT REPORT\n═══════════════════════════════════════════════════════════════\nTarget dir:     {target_dir}\nRepo root:      {git_root}\nBranch:         {current_branch}\nWorking tree:   {Clean | Dirty (N files)}\nPre-commit:     {Detected (type) | None}\n                {May modify files: Yes (formatters) | No | Unknown}\nTest command:   {test_command}\nSections:       {N} detected\nCompleted:      {M} already done\nState storage:  {state_dir}\n═══════════════════════════════════════════════════════════════\n```\n\n### I. Verify Task List\n\nCheck the setup output for task status:\n\n1. If `tasks_written > 0`: Tasks have been written. Call `TaskList` to see them.\n2. If `task_write_error` is present: Task write failed - log the error and continue with manual tracking.\n3. If no `task_list_id`: Session ID not available - the SessionStart hook may not have run.\n\n**After setup succeeds:** Call `TaskList` to see the implementation tasks.\n\n**Understanding the task list:**\n\nThe task list contains **6 high-level reminders per section**:\n1. Implement section-NN\n2. Run code review subagent for section-NN\n3. Perform code review interview for section-NN\n4. Update section-NN documentation\n5. Commit section-NN\n6. Record section-NN completion\n\nPlus a **compaction prompt every 2nd section** (after 02, 04, 06, etc.).\n\nContext items appear as pending tasks at the start (e.g., `plugin_root=\u002Fpath\u002F...`, `sections_dir=\u002Fpath\u002F...`).\n\nThese are **milestones to track progress**, not detailed instructions. For the actual workflow steps, always refer to:\n- This file (SKILL.md) for the overall orchestration\n- The reference documents in `references\u002F` for detailed protocols\n\nMark each task as `in_progress` when starting: `TaskUpdate(taskId=X, status=\"in_progress\")`\nMark each task as `completed` when done: `TaskUpdate(taskId=X, status=\"completed\")`\n\n---\n\n## Implementation Loop\n\nFor each incomplete section (in manifest order):\n\n**Task milestone mapping:**\n| Task Subject | Workflow Steps |\n|-----------|----------------|\n| Implement section-NN | Steps 1-5 (read, TDD, stage) |\n| Run code review subagent | Step 6 (launch subagent, write review) |\n| Perform code review interview | Steps 7-8 (triage, interview, apply fixes) |\n| Update section-NN documentation | Step 9 (update section file with what was actually built) |\n| Commit section-NN | Step 10 (commit implementation + doc update together) |\n| Record section-NN completion | Step 11 (run update_section_state.py to save commit hash) |\n| Context check (every 2nd section only) | Step 13 (context management options) |\n\n**Note:** Step 12 (Mark Complete) is internal task status update. Step 14 (Loop) continues to next section. Context checks only appear after sections 02, 04, 06, etc.\n\n### Step 1: Mark In Progress\n\nUpdate task: `TaskUpdate(taskId=X, status=\"in_progress\")`\n\n### Step 2: Read Section File\n\n```\nRead {sections_dir}\u002Fsection-NN-\u003Cname>.md\n```\n\n### Step 3: Implement Section\n\nSee [implementation-loop.md](references\u002Fimplementation-loop.md)\n\nFollow TDD workflow:\n1. Create skeleton files for imports\n2. Write tests from section spec\n3. Run tests (expect failures)\n4. Write implementation\n5. Run tests (expect pass)\n6. Handle failures with retry (max 3)\n\n### Step 4: Track Created Files\n\nMaintain list of all files created during implementation.\n\n### Step 5: Stage Changes\n\n```bash\n# Stage new files\ngit add {created_files...}\n\n# Stage modified files\ngit add -u\n```\n\n### Step 6: Code Review (Subagent)\n\nSee [code-review-protocol.md](references\u002Fcode-review-protocol.md)\n\n1. Create `{state_dir}\u002Fcode_review\u002F` directory if it doesn't exist\n2. Write staged diff to `{code_review_dir}\u002Fsection-NN-diff.md`\n3. Launch `code-reviewer` subagent to analyze the diff\n4. Write subagent's review to `{code_review_dir}\u002Fsection-NN-review.md`\n\n### Step 7: Code Review Triage and Interview\n\nSee [code-review-interview.md](references\u002Fcode-review-interview.md)\n\nTriage the review findings and interview the user only on important items:\n\n1. Read the review and use judgment to categorize:\n   - **Ask user:** Decisions with real tradeoffs, security concerns\n   - **Auto-fix:** Obvious improvements, low-risk changes\n   - **Let go:** Nitpicks, pedantic observations\n2. Interview user only on items that need their input\n3. Write transcript with both interview decisions AND auto-fixes to `{code_review_dir}\u002Fsection-NN-interview.md`\n\nThe goal is a useful conversation, not a comprehensive audit.\n\n### Step 8: Apply Fixes\n\nSee [apply-interview-fixes.md](references\u002Fapply-interview-fixes.md)\n\nApply all fixes recorded in the transcript:\n\n1. Read `{code_review_dir}\u002Fsection-NN-interview.md`\n2. Apply user-approved fixes and auto-fixes (if already applied, skip)\n3. Run tests to verify nothing broke\n4. Re-stage modified files\n\n**Recovery:** If compaction happens, the interview file is the checkpoint. Restart applying fixes from the beginning - you'll notice already-applied changes. The commit is the definitive checkpoint.\n\n### Step 9: Update Section Documentation\n\nSee [section-doc-update.md](references\u002Fsection-doc-update.md)\n\n**Before committing**, update the original section file to reflect what was actually implemented:\n\n1. Read `{sections_dir}\u002Fsection-NN-\u003Cname>.md`\n2. Compare planned implementation vs actual:\n   - Code review fixes that changed the approach\n   - File paths that differed from plan\n   - Tests that were added\u002Fmodified\n3. Update the section file with:\n   - Actual file paths created\u002Fmodified\n   - Any deviations from original plan (with rationale)\n   - Final test count and coverage notes\n4. **If sections_dir is inside git_root**, stage the section doc:\n   ```bash\n   git add {sections_dir}\u002Fsection-NN-\u003Cname>.md\n   ```\n   (If sections_dir is outside git_root, skip staging - the doc update lives with the planning files)\n\nThis keeps section files as accurate documentation of what was built, not just what was planned.\n\n### Step 10: Commit\n\nSee [git-operations.md](references\u002Fgit-operations.md) and [pre-commit-handling.md](references\u002Fpre-commit-handling.md)\n\nCommit implementation + doc update together (one commit per section):\n\n1. Create commit message matching detected style\n2. Attempt commit\n3. Handle pre-commit hooks:\n   - If files modified: re-stage and retry (max 2)\n   - If lint error: present options to user\n4. On success: store commit hash in session config\n\n```bash\ngit commit -m \"$(cat \u003C\u003C'EOF'\nImplement section NN: Name\n\n- Very concise summary of features\u002Fchanges\n\nPlan: section-NN-\u003Cname>.md\nCo-Authored-By: Claude \u003Cnoreply@anthropic.com>\nEOF\n)\"\n```\n\n### Step 11: Update State\n\nAfter successful commit, update the session config:\n\n```bash\nuv run {plugin_root}\u002Fscripts\u002Ftools\u002Fupdate_section_state.py \\\n    --state-dir \"{state_dir}\" \\\n    --section \"{section_name}\" \\\n    --commit-hash \"{commit_hash}\"\n```\n\nThis records the commit hash so the section is recognized as complete on resume.\n\n### Step 12: Mark Complete\n\nUpdate task: `TaskUpdate(taskId=X, status=\"completed\")`\n\n### Step 13: Context Check (Every 2nd Section)\n\n**Only prompt after sections 02, 04, 06, etc.** (every 2nd section).\n\nIf this is NOT a 2nd section, skip directly to Step 14.\n\nIf this IS a 2nd section (02, 04, 06, ...):\n\n```\n═══════════════════════════════════════════════════════════════\nSection NN complete and committed.\n═══════════════════════════════════════════════════════════════\n\nCompleted: {M}\u002F{N} sections\nNext: section-{NN+1}-{name}\n\nContext Management Options:\n  1. \u002Fclear + re-run \u002Fdeep-implement (Recommended)\n     - Fresh context with full instructions\n     - Progress preserved via file-based recovery\n\n  2. Continue in current session\n     - Auto-compact triggers at ~95% if needed\n     - May lose some instruction detail after compaction\n\nType \"continue\" or run \u002Fclear and re-invoke \u002Fdeep-implement @{sections_dir}\u002F.\n```\n\nWait for user response. If they say \"continue\", proceed to Step 14.\n\n### Step 14: Loop\n\nRepeat from Step 1 for next section.\n\n---\n\n## Finalization\n\nAfter all sections complete, see [finalization.md](references\u002Ffinalization.md):\n\n1. Generate `{state_dir}\u002Fusage.md` with usage guide for what was built\n2. Print completion summary with commits, files, and next steps\n\n---\n\n## Error Handling\n\n### Test Failures\n\nAfter 3 failed fix attempts:\n```\nAskUserQuestion:\n  question: \"Tests still failing after 3 attempts. How to proceed?\"\n  options:\n    - label: \"Review and debug\"\n      description: \"I'll show you the test and implementation for inspection\"\n    - label: \"Skip section\"\n      description: \"Mark section as skipped and continue to next\"\n    - label: \"Stop implementation\"\n      description: \"Pause to manually investigate\"\n```\n\n### Pre-Commit Failures\n\nSee [pre-commit-handling.md](references\u002Fpre-commit-handling.md)\n\n### Git Commit Failures\n\nIf commit fails (non-pre-commit):\n```\nGit commit failed: {error}\n\nThe staged changes are preserved.\nYou can manually commit with: git commit -m \"message\"\n\nContinue to next section? [y\u002Fn]\n```\n\n### Path Safety Violations\n\n```\n═══════════════════════════════════════════════════════════════\nSECURITY ERROR\n═══════════════════════════════════════════════════════════════\n\nAttempted to write file outside allowed directory:\n  Path: {attempted_path}\n  Allowed root: {git_root}\n\nThis section file may contain invalid paths.\nPlease review the section file.\n═══════════════════════════════════════════════════════════════\n```\n\n---\n\n## Context Recovery\n\n**After `\u002Fclear` + re-run `\u002Fdeep-implement`:**\n\nThe setup script detects completed sections via `deep_implement_config.json` and marks their tasks complete. You'll resume from the next pending section with fresh instructions.\n\n**After compaction (if user chose \"continue\"):**\n\n1. Call `TaskList` to see current state\n2. Find context tasks to recover paths:\n   - `plugin_root=...` - extract value after `=`\n   - `sections_dir=...` - extract value after `=`\n   - `state_dir=...` - extract value after `=`\n3. Find next pending, unblocked task\n4. Resume workflow from that task\n\n---\n\n## Reference Documents\n\n- [implementation-loop.md](references\u002Fimplementation-loop.md) - TDD workflow details\n- [code-review-protocol.md](references\u002Fcode-review-protocol.md) - Subagent review process\n- [code-review-interview.md](references\u002Fcode-review-interview.md) - Interactive interview with user\n- [apply-interview-fixes.md](references\u002Fapply-interview-fixes.md) - Applying fixes from interview\n- [section-doc-update.md](references\u002Fsection-doc-update.md) - Updating section documentation\n- [git-operations.md](references\u002Fgit-operations.md) - Git handling\n- [pre-commit-handling.md](references\u002Fpre-commit-handling.md) - Hook handling\n- [finalization.md](references\u002Ffinalization.md) - Usage guide and completion summary\n",{"name":5,"license":15,"description":7,"compatibility":49},"Requires uv (Python 3.11+), git repository recommended","main","764659f5d3508ec0dc87a5ceb7cb1fceae687736","deep-implement\u002Fskills\u002Fdeep-implement",0,"https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery","https:\u002F\u002Fgithub.com\u002FLUAgam","2026-03-27 17:25:40",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add LUAgam\u002Fagent-delivery --skill deep-implement",{"tool":63,"command":64},"bunx","bunx skills add LUAgam\u002Fagent-delivery --skill deep-implement",{"tool":66,"command":67},"pnpm","pnpm dlx skills add LUAgam\u002Fagent-delivery --skill deep-implement","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fdeep-implement\u002Fskills\u002Fdeep-implement\u002FSKILL.md",true,[71,77,81,85,89,93,97,101],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fapply-interview-fixes.md","REFERENCE","参考文档",1387,"https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fdeep-implement\u002Fskills\u002Fdeep-implement\u002Freferences\u002Fapply-interview-fixes.md",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fcode-review-interview.md",6128,"https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fdeep-implement\u002Fskills\u002Fdeep-implement\u002Freferences\u002Fcode-review-interview.md",{"path":82,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fcode-review-protocol.md",2959,"https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fdeep-implement\u002Fskills\u002Fdeep-implement\u002Freferences\u002Fcode-review-protocol.md",{"path":86,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Ffinalization.md",1883,"https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fdeep-implement\u002Fskills\u002Fdeep-implement\u002Freferences\u002Ffinalization.md",{"path":90,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fgit-operations.md",2792,"https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fdeep-implement\u002Fskills\u002Fdeep-implement\u002Freferences\u002Fgit-operations.md",{"path":94,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fimplementation-loop.md",2491,"https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fdeep-implement\u002Fskills\u002Fdeep-implement\u002Freferences\u002Fimplementation-loop.md",{"path":98,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fpre-commit-handling.md",3622,"https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fdeep-implement\u002Fskills\u002Fdeep-implement\u002Freferences\u002Fpre-commit-handling.md",{"path":102,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fsection-doc-update.md",3414,"https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fdeep-implement\u002Fskills\u002Fdeep-implement\u002Freferences\u002Fsection-doc-update.md",[106,137,163,189,212,232],{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":120,"publishedAt":44},"01M6J91S60RJA2X5XZ4AMYW37V","ring:visual-explainer","Generate beautiful, self-contained HTML pages that visually explain systems, code changes, plans, and data. Use when the user asks for a diagram, architecture overview, diff review, plan review, project recap, comparison table, or any visual explanation of technical concepts. Also use proactively when you are about to render a complex ASCII table (4+ rows or 3+ columns) — present it as a styled HTML page instead.","https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fring\u002Fdefault\u002Fskills\u002Fvisual-explainer\u002FSKILL.md",[112,115],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[121,122,123,124,125,43,126,127,128,129,38,130,34,131,132,31,133,134,135,136],"visual explainer","explainer","visual","ring:visual explainer","image","cli","architecture","diagram","generate","browser","recap","generated","self","project","render","you",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":149,"publishedAt":44},"01M6J8Y5P999CWG7ZVYWTQ2RPA","drawing-diagrams","Generate Mermaid diagrams from context and open them in mermaid.live in the browser. Use when the user asks for a diagram, visualization, flowchart, sequence diagram, ER diagram, or any visual representation of code, architecture, or processes. Produces lightweight, shareable mermaid.live URLs that open in the browser for interactive editing.","https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Fring\u002Fdefault\u002Fskills\u002Fdrawing-diagrams\u002FSKILL.md",[143,146],{"categoryNo":144,"categoryName":145,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":147,"categoryName":148,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000030","开发工程师",[150,151,152,127,128,153,154,129,155,38,130,156,157,158,159,160,31,133,161,162],"diagrams","drawing","drawing diagrams","flowchart","mermaid","visualization","library","open","context","html","only","live","sequence",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":167,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":44},"01M6J8KCG67F3ZXHH6M275AJCP","returns-reverse-logistics","Codified expertise for returns authorization, receipt and inspection, disposition decisions, refund processing, fraud detection, and warranty claims management. Informed by returns operations managers with 15+ years experience. Includes grading frameworks, disposition economics, fraud pattern recognition, and vendor recovery processes. Use when handling product returns, reverse logistics, refund decisions, return fraud detection, or warranty claims.","Apache-2.0","https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Feverything-claude-code\u002Fskills\u002Freturns-reverse-logistics\u002FSKILL.md",[],[171,172,173,174,38,175,176,33,177,178,179,180,181,182,183,184,185,186,187,188],"returns","returns reverse logistics","reverse logistics","reverse","product","decisions","claims management","frameworks","fraud detection","pattern","grading","processing","economics","managers","claims","for","expertise","refund",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":167,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":44},"01M6J8K2D6JZRFECQC2TSKH1GK","quality-nonconformance","Codified expertise for quality control, non-conformance investigation, root cause analysis, corrective action, and supplier quality management in regulated manufacturing. Informed by quality engineers with 15+ years experience across FDA, IATF 16949, and AS9100 environments. Includes NCR lifecycle management, CAPA systems, SPC interpretation, and audit methodology. Use when investigating non-conformances, performing root cause analysis, managing CAPAs, interpreting SPC data, or handling supplier quality issues.","https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Feverything-claude-code\u002Fskills\u002Fquality-nonconformance\u002FSKILL.md",[],[196,197,198,38,199,200,201,202,203,33,204,205,206,207,208,209,210,211,186,187],"quality","quality nonconformance","interpretation","issues","audit","data","lifecycle","analysis","audit methodology","across","manufacturing","environments","corrective action","supplier quality management","action","conformance",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":167,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":218,"publishedAt":44},"01M6J8J6M07KCYBENXVT0F78V5","production-scheduling","Codified expertise for production scheduling, job sequencing, line balancing, changeover optimization, and bottleneck resolution in discrete and batch manufacturing. Informed by production schedulers with 15+ years experience. Includes TOC\u002Fdrum-buffer-rope, SMED, OEE analysis, disruption response frameworks, and ERP\u002FMES interaction patterns. Use when scheduling production, resolving bottlenecks, optimizing changeovers, responding to disruptions, or balancing manufacturing lines.","https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Feverything-claude-code\u002Fskills\u002Fproduction-scheduling\u002FSKILL.md",[],[219,220,221,38,222,223,203,224,225,33,226,227,178,228,229,230,206,231,186,187],"Production","production scheduling","scheduling","batch","Optimization","erp","bottleneck","toc","patterns","line","interaction","sequencing","buffer",{"skillNo":233,"name":234,"nameZh":6,"description":235,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":167,"licenseFileUrl":6,"sourceHtmlUrl":236,"categories":237,"keywords":238,"publishedAt":44},"01M6J8H1SJA23P77QVBBGAT0KW","logistics-exception-management","Codified expertise for handling freight exceptions, shipment delays, damages, losses, and carrier disputes. Informed by logistics professionals with 15+ years operational experience. Includes escalation protocols, carrier-specific behaviors, claims procedures, and judgment frameworks. Use when handling shipping exceptions, freight claims, delivery issues, or carrier disputes.","https:\u002F\u002Fgithub.com\u002FLUAgam\u002Fagent-delivery\u002Fblob\u002Fmain\u002Feverything-claude-code\u002Fskills\u002Flogistics-exception-management\u002FSKILL.md",[],[239,240,241,38,242,199,243,244,245,33,178,246,247,248,29,185,186,187],"management","logistics exception management","github","shipping","protocols","https","escalation","delivery","claude-code","judgment"]