[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71KDH7XFQJPKYZ0H9JDNSA5":3,"skill-same:01M71KDH7XFQJPKYZ0H9JDNSA5":69},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":68},"01M71KDH7XFQJPKYZ0H9JDNSA5","tasks",null,"Use when a spec has design.md and needs implementation tasks.","mugsun\u002Fcurdx-flow","mugsun","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F100790155?v=4","01M6KJSAN2W4WRPDFBKTJTDDQ2","Mugsun","01M71K65VJXA4C1KPJAHZ6ZVHC",4,"MIT","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Ftasks\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"design","auto","when","Bash","read","write","edit","true","use","standard","task","name","spec","implementation","2026-11-10 10:12:30",false,"---\nname: tasks\ndescription: Use when a spec has design.md and needs implementation tasks.\nargument-hint: \"[spec-name] [--task-granularity auto|coarse|standard|fine]\"\nallowed-tools: \"Read Write Edit Bash Agent AskUserQuestion\"\ndisable-model-invocation: true\n---\n\n\n# Tasks Phase\n\nGenerate implementation tasks for the active spec. Running this command implicitly approves design. You are a **coordinator, not a task planner** -- delegate ALL work to the `task-planner` subagent.\n\n## Coordinator Checklist\n\nComplete these coordination steps in order; do not create user-facing implementation tasks from this checklist:\n\n1. **Gather context** -- run workflow snapshot, read design, requirements, research\n2. **Interview** -- brainstorming dialogue (skip if `--quick`)\n3. **Execute task generation** -- dispatch task-planner via direct Agent; Agent Teams optional\n4. **Artifact review** -- parallel two-stage review (`spec-reviewer` + `code-quality-reviewer`); QuickMode bypass per D5\n5. **Walkthrough & approval** -- display summary, get user approval\n6. **Finalize** -- update state, commit, stop\n\n## Step 1: Gather Context\n\n1. Run `curdx-flow snapshot --spec \"$ARGUMENTS\"` when `$ARGUMENTS` begins with a spec name; otherwise run `curdx-flow snapshot`.\n2. If `snapshot.active` is false, error: \"No active spec. Run \u002Fcurdx-flow:new \u003Cname> first.\"\n3. Use `snapshot.spec.fsPath` as `$SPEC_PATH`.\n4. If `snapshot.artifacts.design.exists` is false, error: \"Design not found. Run \u002Fcurdx-flow:design first.\"\n5. If `snapshot.artifacts.requirements.exists` is false, error: \"Requirements not found. Run \u002Fcurdx-flow:requirements first.\"\n6. Clear approval flag:\n   ```bash\n   curdx-flow state merge \"$SPEC_PATH\u002F.curdx-state.json\" '{\"awaitingApproval\":false}'\n   ```\n7. **`--task-granularity` flag handling**: Check `$ARGUMENTS` for `--task-granularity` flag:\n   - Valid values: `auto`, `coarse`, `standard`, `fine`\n   - If valid: update `granularity` in `.curdx-state.json` and treat it as an explicit override of `autoPolicy.taskGranularity`\n   - If invalid: warn the user (`Invalid --task-granularity value \"\u003Cvalue>\", using autoPolicy\u002Fdefault standard`) and set `\"granularity\": \"auto\"`\n   - If `--task-granularity` flag is absent: leave `granularity` unchanged in `.curdx-state.json` (preserve any value set by `\u002Fcurdx-flow:start`)\n8. **AutoPolicy default**: If no `autoPolicy` exists in the snapshot, run:\n   ```bash\n   curdx-flow route --goal \"$GOAL\" --flags \"$ARGUMENTS\"\n   ```\n   Merge the JSON into `.curdx-state.json` as `{ \"autoPolicy\": \u003Cpolicy>, \"granularity\": \u003Cpolicy.taskGranularity> }`.\n9. Read route context from `.curdx-state.json` when present: `route.stackProfile`, `route.qualityGates`, `route.suggestedVerifier`, and `route.contextBudget`. Use `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fintelligent-routing.md` only when the compact route facts need interpretation.\n10. Read context: `requirements.md`, `design.md`, `research.md` (if exists), `.progress.md`\n\n## Step 2: Interview (skip if --quick)\n\nCheck if `--quick` appears in `$ARGUMENTS`. If present, skip to Step 3.\n\n### Read Context from .progress.md\n\nParse Intent Classification and all prior interview responses to skip already-answered questions.\n\n**Intent-Based Question Counts:**\n- TRIVIAL: 1-2 | REFACTOR: 3-5 | GREENFIELD: 5-10 | MID_SIZED: 3-7\n\n### Brainstorming Dialogue\n\nApply adaptive dialogue from `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Finterview-framework\u002FSKILL.md`. Ask context-driven questions one at a time.\n\n**Tasks Exploration Territory** (hints, not a script):\n- **Testing thoroughness** -- minimal POC-only tests, standard unit + integration, or comprehensive E2E?\n- **Deployment considerations** -- feature flags, database migrations, backward compatibility, rollback plan?\n- **Execution priority** -- ship fast with shortcuts, balanced pace, or quality-first from the start?\n- **Dependency ordering** -- are there tasks that must complete before others can begin?\n- **Team workflow constraints** -- PR review process, CI pipeline requirements, branch strategy?\n- **Browser verification** -- ask only when `autoPolicy.verificationLevel` is `strict` or the design has explicit UI\u002Fdeployment risk; prefer Playwright CLI, but select Chrome DevTools MCP for GIS\u002FWebGL\u002Fcanvas\u002Fmap\u002FGPU or console\u002Fnetwork\u002Fperformance debugging.\n- **Task granularity** -- do not ask by default. AutoPolicy selects the task target range. Ask only if the user explicitly requests manual sizing.\n\n### Tasks Approach Proposals\n\nAfter dialogue, propose 2-3 execution strategies. Examples (illustrative only):\n- **(A)** Aggressive POC -- fewer tasks, ship in small increments, add polish later\n- **(B)** Thorough -- more tasks with full test coverage and quality gates throughout\n- **(C)** Phased delivery -- split into multiple PRs with clear milestones\n\n### Store Interview & Approach\n\nAppend to `.progress.md` under \"Interview Responses\":\n```markdown\n### Tasks Interview (from tasks.md)\n- [Topic 1]: [response]\n- Browser verification: playwright\u002Fchrome-devtools-mcp\u002Fnone\u002Fblocked -- [strategy or \"auto\"]\n- Chosen approach: [name] -- [brief description]\n```\n\nPass combined context to delegation prompt as \"Interview Context\".\n\n## Step 3: Execute Task Generation (Agent-Based, Teams Optional)\n\n\u003Cmandatory>\n**Default path: use the normal `Agent` tool with `task-planner`. Do not require Agent Teams.**\n\nALL specs MUST follow POC-first workflow. Read `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fphase-rules.md` for the mandatory 5-phase structure and phase distribution rules.\n\nRead `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fquality-checkpoints.md` for checkpoint insertion rules (frequency, format, final verification sequence).\n\nAgent Teams are experimental and disabled by default in Claude Code. Use the team lifecycle only when `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is set and the `TeamCreate` \u002F `TaskCreate` \u002F `TaskList` \u002F `SendMessage` tools are visible in the current session. If any team tool is unavailable or fails, immediately continue with the direct `Agent(agent_type: task-planner)` path. Treat this as the normal path, not a degraded path.\n\nDirect path:\n\n1. Optionally create a visible native task with `TaskCreate(subject: \"Generate implementation tasks for $spec\", activeForm: \"Generating tasks\")`. If unavailable or failing, continue without it.\n2. Dispatch `Agent(agent_type: task-planner)` with requirements, design, interview context, and the Delegation Context below. Instruct it to:\n   - Read `references\u002Fworkflow-contract.md`, `references\u002Fsource-coverage-audit.md`, `references\u002Fbrowser-verification-policy.md`, and `references\u002Fagent-output-contract.md`\n   - Start `tasks.md` with `## Source Coverage Audit`, then `## Browser Verify`\n   - Cover every source item; if coverage cannot be complete, stop with `TASKS_BLOCKED`\n   - Break implementation into value-slice tasks, using POC-first or TDD phases only as structure\n   - Create tasks with Do\u002FFiles\u002FDone when\u002FVerify\u002FCommit fields\n   - Keep top-level task count inside `autoPolicy.taskTargetRange`; if this requires more than 12 tasks, stop and recommend `\u002Fcurdx-flow:triage`\n   - Insert quality checkpoints according to `autoPolicy.reviewCadence` and `autoPolicy.verificationLevel`\n   - Each task = one commit, tasks must be executable without human interaction\n   - Count total tasks, output to `.\u002Fspecs\u002F$spec\u002Ftasks.md`\n   - If quick mode and policy verification is strict: auto-enable VE tasks. Otherwise keep VE tasks risk-triggered. For UI\u002Ffull-stack work, Browser Verify must select Playwright CLI or Chrome DevTools MCP.\n   - When Browser Verify selects Playwright and no E2E package script exists, include a task to add `test:e2e` or the repo's equivalent script before final verification.\n   - For greenfield work (`intent.workspaceState == \"empty\"` or route `greenfield-spec`), include a walking-skeleton task before business slices. It must prove the selected project shape, contract, and dev runtime can start and verify together.\n   - For scaffold or greenfield foundation work, prefer official or ecosystem-maintained scaffold generators for named stacks when current docs show one exists; self-author only when no trustworthy generator exists, the requested skeleton is intentionally smaller, or a custom skeleton is safer to verify.\n   - Prefer `curdx-flow dev detect`, `curdx-flow dev up`, `curdx-flow dev health`, `curdx-flow dev verify`, and `curdx-flow dev down` for local runtime evidence when project scripts exist.\n   - If the source requirements explicitly require Chrome DevTools MCP, do not make the final verifier a file\u002Ftooling check such as `.\u002Fverify.sh --check` by itself. Generate startup\u002Fcheck\u002Fcleanup steps that keep the server alive for browser interaction, and require `curdx-flow verify run --description` to include the concrete MCP proof: tool used, URL, add\u002Ftoggle\u002Fdelete or equivalent action sequence, DOM assertion, and console-error result.\n3. Wait for the Agent result. Require `TASKS_READY` before proceeding; if `TASKS_BLOCKED`, surface the blocking source items and stop.\n4. Read `$SPEC_PATH\u002Ftasks.md`.\n\nOptional Agent Teams path:\n\n1. `TeamDelete()` once to release any stale team; errors are harmless.\n2. `TeamCreate(team_name: \"tasks-$spec\")`\n3. `TaskCreate(subject: \"Generate implementation tasks for $spec\", activeForm: \"Generating tasks\")`\n4. `Agent(agent_type: task-planner, team_name: \"tasks-$spec\", name: \"planner-1\")` with the same prompt as the direct path.\n5. Wait via automatic teammate messages or a single `TaskList` check.\n6. `SendMessage(type: \"shutdown_request\", recipient: \"planner-1\")`\n7. Read `.\u002Fspecs\u002F$spec\u002Ftasks.md`, then `TeamDelete()`.\n\n> **Delegation Context**: When delegating to task-planner, include these inputs:\n> - **AutoPolicy**: full `.curdx-state.json::autoPolicy` JSON\n> - **Granularity**: `autoPolicy.taskGranularity`, unless `granularity` explicitly overrides it\n> - **Task Target**: `autoPolicy.taskTargetRange`\n> - **Review Cadence**: `autoPolicy.reviewCadence`\n> - **Verification Level**: `autoPolicy.verificationLevel`\n> - **Value Slice Rule**: test\u002Freproduce + implementation + verification + commit stay inside one top-level task\n> - **Intent Facts**: full `.curdx-state.json::intent` JSON when present\n> - **Project Topology**: full `.curdx-state.json::projectTopology` JSON when present\n> - **Greenfield Rule**: if workspace is empty\u002Fgreenfield, plan foundation as a walking skeleton before business slices\n>\n> For VE Tasks — VE1 (startup), VE2 (check), VE3 (cleanup) — generation:\n> - **Browser Verification**: Playwright CLI by default, Chrome DevTools MCP for GIS\u002FWebGL\u002Fcanvas\u002Fmap\u002FGPU\u002Frendering or console\u002Fnetwork\u002Fperformance diagnosis, none only for non-browser work\n> - **Verification Tooling**: the Verification Tooling section from research.md (dev server commands, browser deps, ports, health endpoints)\n> - **Strategy**: the user's chosen verification strategy, or \"auto\" in quick mode\n> - **Lifecycle**: startup must keep the dev server alive until cleanup; short-lived background commands from a subshell are not valid evidence unless a health check proves the server remains reachable.\n\u003C\u002Fmandatory>\n\n## Step 4: Artifact Review (Parallel Two-Stage)\n\n\u003Cmandatory>\n**Review loop must complete before walkthrough. Max 3 iterations.**\n\nRead `.curdx-state.json::autoPolicy.reviewCadence`:\n- `minimal`: skip subagent artifact review for tasks.md; run the task-planner self-check and proceed to walkthrough.\n- `final`, `periodic`, `strict`: run the two-stage review below.\n\nThis step runs the **two-stage review protocol** at the tasks phase boundary: `spec-reviewer` (specCompliance) and `code-quality-reviewer` (codeQuality) are dispatched **in parallel**, in ONE message, against the frozen `tasks.md` artifact. Both reviewers must complete before reconciliation.\n\n**Required reading before dispatch** (read once at top of step, do not skip):\n- [`bounded-parallel-dispatch.md`](${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fbounded-parallel-dispatch.md) — independence criteria + the Review-domain \"ALL Agent calls in ONE message\" rule (anti-pattern #3 + #5–#8). Both reviewers must be spawned in the SAME message.\n- [`two-stage-review.md`](${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Ftwo-stage-review.md) — domain boundary table (specCompliance vs codeQuality), 3-layer drift defense, anti-rationalization rule, SLSA-shape verdict glossary, QuickMode behavior contract.\n\nThe two reviewers do **not** see each other's output (Layer 2 isolation). The coordinator never arbitrates findings across domains.\n\n### 4.1 Bounded parallel dispatch (direct Agent default)\n\n```\n1. Optional TaskCreate(subject: \"Spec-compliance review of tasks.md\",\n                       activeForm: \"Reviewing tasks (spec-compliance)\")\n   Optional TaskCreate(subject: \"Code-quality review of tasks.md\",\n                       activeForm: \"Reviewing tasks (code-quality)\")\n2. # ALL Agent calls in ONE message — see bounded-parallel-dispatch.md anti-pattern #3\n   Agent(agent_type: spec-reviewer,\n        prompt: \"Review .\u002Fspecs\u002F$spec\u002Ftasks.md for spec-compliance ONLY.\n                 Upstream: design.md + requirements.md.\n                 Your domain: traceability, phase artifact structure, requirement\n                 coverage, artifact format. Do NOT comment on code-quality concerns\n                 (smell \u002F security \u002F readability \u002F test-shape) — those belong to the\n                 peer code-quality-reviewer (which you do NOT see and MUST NOT\n                 reference). Emit a markdown findings table and a final line\n                 `REVIEW_PASS` or `REVIEW_FAIL` (byte-equal).\")\n   Agent(agent_type: code-quality-reviewer,\n        prompt: \"Review .\u002Fspecs\u002F$spec\u002Ftasks.md for code-quality ONLY.\n                 Your domain: code smell \u002F security \u002F implementation quality \u002F\n                 readability \u002F test quality \u002F no-hallucinations. Do NOT comment\n                 on traceability to requirements \u002F phase artifact structure \u002F\n                 requirement coverage \u002F artifact format \u002F front-matter — those\n                 belong to spec-reviewer (which you do NOT see and MUST NOT\n                 reference). Emit a markdown findings table and a final line\n                 `REVIEW_PASS` or `REVIEW_FAIL` (byte-equal).\")\n3. # Wait for both Agent results; collect REVIEW_PASS\u002FREVIEW_FAIL final lines.\n4. # Persist verdicts under verificationBlocks.tasks.reviews via merge-state (FR-T3 — never hand-edit state):\n   curdx-flow state merge \\\n     \"$SPEC_PATH\u002F.curdx-state.json\" \\\n     '{\"verificationBlocks\":{\"tasks\":{\"reviews\":{\n        \"specCompliance\":{\"verdict\":\"\u003CPASS|FAIL>\",\"findings\":[...],\"reviewerId\":\"spec-compliance\",\"timestamp\":\"\u003CISO8601>\"},\n        \"codeQuality\":{\"verdict\":\"\u003CPASS|FAIL>\",\"findings\":[...],\"reviewerId\":\"code-quality\",\"timestamp\":\"\u003CISO8601>\"}\n     }}}}'\n```\n\nOptional Agent Teams overlay: if Agent Teams are enabled and available, create `TeamCreate(team_name: \"review-tasks-$spec\")`, add matching `team_name` and `name` fields to both Agent calls, wait via automatic teammate messages or one `TaskList` check, then `SendMessage(...shutdown_request...)` and `TeamDelete()`. If any team step fails, rerun or continue with the direct dual `Agent(...)` calls above.\n\n### 4.2 QuickMode branch (D5)\n\nRead `state.quickMode` from `.curdx-state.json`. **specCompliance is always a hard gate**; QuickMode only relaxes codeQuality.\n\n```\nif state.quickMode === true:\n  if specCompliance.verdict === \"FAIL\":\n    # Hard gate even in QuickMode — FR-M2 reverse contract.\n    block; show findings; do NOT advance to Step 5.\n  if codeQuality.verdict === \"FAIL\":\n    # Advisory downgrade — set advisory:true via merge-state, surface findings,\n    # continue. Never set advisory on specCompliance.\n    merge-state into verificationBlocks.tasks.reviews.codeQuality.advisory = true\n    log warning to .progress.md; proceed to Step 5.\nelse:                                  # normal mode\n  if specCompliance.verdict === \"FAIL\" OR codeQuality.verdict === \"FAIL\":\n    # Either FAIL blocks. Display findings table, ask user (Step 5 \"Run review\" \u002F \"Request changes\" loop).\n    Iteration \u003C 3: re-invoke task-planner with merged feedback, loop back to 4.1.\n    Iteration >= 3: graceful degradation, log warning, proceed (permissive ceiling matches prior behavior).\n  else:\n    proceed to Step 5.\n```\n\n**Anti-rationalization**: the coordinator MUST NOT pass spec-reviewer's findings into the code-quality-reviewer prompt (or vice versa). Both verdicts are stored verbatim under `verificationBlocks.tasks.reviews`. See [`two-stage-review.md`](${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Ftwo-stage-review.md) §2.\n\n**Revision delegation**: Re-invoke task-planner with the merged feedback (both reviewers' findings concatenated, attributed by `reviewerId`) and design.md + requirements.md upstream context. Focus on the union of issues.\n\n**Error handling**: Reviewer no signal = treat as REVIEW_PASS for that slot (permissive ceiling). Agent failure = retry once, then use the surviving reviewer's verdict alone (still hard-gate on specCompliance if it survived).\n\n**Fallback**: Direct dual `Agent(...)` calls in ONE message are the default. Team failures are non-blocking unless both reviewers fail to return a verdict.\n\u003C\u002Fmandatory>\n\n## Step 5: Walkthrough & Approval\n\n\u003Cmandatory>\n**WALKTHROUGH IS REQUIRED - DO NOT SKIP.**\n\nRead `.\u002Fspecs\u002F$spec\u002Ftasks.md` and display:\n\n```\nTasks complete for '$spec'.\nOutput: $PWD\u002Fspecs\u002F$spec\u002Ftasks.md\n\n## What I Planned\n\n**Total**: [X] tasks across 4 phases\n\n**Phase Breakdown**:\n- Phase 1 (POC): [count] tasks - proves the idea works\n- Phase 2 (Refactor): [count] tasks - clean up\n- Phase 3 (Testing): [count] tasks - add coverage\n- Phase 4 (Quality): [count] tasks - CI\u002FPR\n\n**POC Milestone**: Task [X.Y] - [brief description of what's working at that point]\n```\n\u003C\u002Fmandatory>\n\n### User Approval (skip if --quick)\n\nIf `--quick`, skip to Step 6.\n\nAsk ONE question: \"How do you want to proceed?\" with these options via AskUserQuestion:\n1. **Approve** (Recommended) -- Accept artifact as-is, advance to next phase\n2. **Run review** -- Spawn spec-reviewer to validate against rubrics, show findings, then loop back to this choice\n3. **Request changes** -- Provide specific feedback to revise the artifact\n\n**If \"Approve\"**: proceed to Step 6.\n**If \"Run review\"**: Invoke spec-reviewer via Agent tool with full tasks.md content (upstream: design.md + requirements.md). Display findings table. If REVIEW_PASS, note it. If REVIEW_FAIL, show feedback. Then loop back to this same 3-choice question (user decides next action).\n**If \"Request changes\" or \"Other\"**:\n1. Ask what to change\n2. Re-invoke task-planner with direct `Agent(agent_type: task-planner)` and feedback; use the optional team lifecycle only if Agent Teams are enabled and available\n3. Re-display walkthrough, ask again with same 3 choices. Loop until approved.\n\n## Step 6: Finalize\n\n### Update State\n\n1. Count total tasks from generated file\n2. Update `.curdx-state.json`: `{ \"phase\": \"tasks\", \"totalTasks\": \u003Ccount>, \"awaitingApproval\": true }`\n3. Update `.progress.md`: mark design as implicitly approved, set current phase, update task count\n\n### Commit Spec (if enabled)\n\nRead `commitSpec` from `.curdx-state.json`. If true:\n```bash\ngit add .\u002Fspecs\u002F$spec\u002Ftasks.md\ngit commit -m \"spec($spec): add implementation tasks\"\ngit push -u origin $(git branch --show-current)\n```\nIf commit or push fails, display warning but continue.\n\n### Stop\n\n\u003Cmandatory>\n**STOP HERE. DO NOT PROCEED TO IMPLEMENT.**\n\n(Does not apply in `--quick` mode.)\n\n1. Display: `-> Next: Run \u002Fcurdx-flow:implement to start execution`\n2. End your response immediately\n3. Wait for user to explicitly run `\u002Fcurdx-flow:implement`\n\u003C\u002Fmandatory>\n","# Tasks Phase\n\nGenerate implementation tasks for the active spec. Running this command implicitly approves design. You are a **coordinator, not a task planner** -- delegate ALL work to the `task-planner` subagent.\n\n## Coordinator Checklist\n\nComplete these coordination steps in order; do not create user-facing implementation tasks from this checklist:\n\n1. **Gather context** -- run workflow snapshot, read design, requirements, research\n2. **Interview** -- brainstorming dialogue (skip if `--quick`)\n3. **Execute task generation** -- dispatch task-planner via direct Agent; Agent Teams optional\n4. **Artifact review** -- parallel two-stage review (`spec-reviewer` + `code-quality-reviewer`); QuickMode bypass per D5\n5. **Walkthrough & approval** -- display summary, get user approval\n6. **Finalize** -- update state, commit, stop\n\n## Step 1: Gather Context\n\n1. Run `curdx-flow snapshot --spec \"$ARGUMENTS\"` when `$ARGUMENTS` begins with a spec name; otherwise run `curdx-flow snapshot`.\n2. If `snapshot.active` is false, error: \"No active spec. Run \u002Fcurdx-flow:new \u003Cname> first.\"\n3. Use `snapshot.spec.fsPath` as `$SPEC_PATH`.\n4. If `snapshot.artifacts.design.exists` is false, error: \"Design not found. Run \u002Fcurdx-flow:design first.\"\n5. If `snapshot.artifacts.requirements.exists` is false, error: \"Requirements not found. Run \u002Fcurdx-flow:requirements first.\"\n6. Clear approval flag:\n   ```bash\n   curdx-flow state merge \"$SPEC_PATH\u002F.curdx-state.json\" '{\"awaitingApproval\":false}'\n   ```\n7. **`--task-granularity` flag handling**: Check `$ARGUMENTS` for `--task-granularity` flag:\n   - Valid values: `auto`, `coarse`, `standard`, `fine`\n   - If valid: update `granularity` in `.curdx-state.json` and treat it as an explicit override of `autoPolicy.taskGranularity`\n   - If invalid: warn the user (`Invalid --task-granularity value \"\u003Cvalue>\", using autoPolicy\u002Fdefault standard`) and set `\"granularity\": \"auto\"`\n   - If `--task-granularity` flag is absent: leave `granularity` unchanged in `.curdx-state.json` (preserve any value set by `\u002Fcurdx-flow:start`)\n8. **AutoPolicy default**: If no `autoPolicy` exists in the snapshot, run:\n   ```bash\n   curdx-flow route --goal \"$GOAL\" --flags \"$ARGUMENTS\"\n   ```\n   Merge the JSON into `.curdx-state.json` as `{ \"autoPolicy\": \u003Cpolicy>, \"granularity\": \u003Cpolicy.taskGranularity> }`.\n9. Read route context from `.curdx-state.json` when present: `route.stackProfile`, `route.qualityGates`, `route.suggestedVerifier`, and `route.contextBudget`. Use `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fintelligent-routing.md` only when the compact route facts need interpretation.\n10. Read context: `requirements.md`, `design.md`, `research.md` (if exists), `.progress.md`\n\n## Step 2: Interview (skip if --quick)\n\nCheck if `--quick` appears in `$ARGUMENTS`. If present, skip to Step 3.\n\n### Read Context from .progress.md\n\nParse Intent Classification and all prior interview responses to skip already-answered questions.\n\n**Intent-Based Question Counts:**\n- TRIVIAL: 1-2 | REFACTOR: 3-5 | GREENFIELD: 5-10 | MID_SIZED: 3-7\n\n### Brainstorming Dialogue\n\nApply adaptive dialogue from `${CLAUDE_PLUGIN_ROOT}\u002Fskills\u002Finterview-framework\u002FSKILL.md`. Ask context-driven questions one at a time.\n\n**Tasks Exploration Territory** (hints, not a script):\n- **Testing thoroughness** -- minimal POC-only tests, standard unit + integration, or comprehensive E2E?\n- **Deployment considerations** -- feature flags, database migrations, backward compatibility, rollback plan?\n- **Execution priority** -- ship fast with shortcuts, balanced pace, or quality-first from the start?\n- **Dependency ordering** -- are there tasks that must complete before others can begin?\n- **Team workflow constraints** -- PR review process, CI pipeline requirements, branch strategy?\n- **Browser verification** -- ask only when `autoPolicy.verificationLevel` is `strict` or the design has explicit UI\u002Fdeployment risk; prefer Playwright CLI, but select Chrome DevTools MCP for GIS\u002FWebGL\u002Fcanvas\u002Fmap\u002FGPU or console\u002Fnetwork\u002Fperformance debugging.\n- **Task granularity** -- do not ask by default. AutoPolicy selects the task target range. Ask only if the user explicitly requests manual sizing.\n\n### Tasks Approach Proposals\n\nAfter dialogue, propose 2-3 execution strategies. Examples (illustrative only):\n- **(A)** Aggressive POC -- fewer tasks, ship in small increments, add polish later\n- **(B)** Thorough -- more tasks with full test coverage and quality gates throughout\n- **(C)** Phased delivery -- split into multiple PRs with clear milestones\n\n### Store Interview & Approach\n\nAppend to `.progress.md` under \"Interview Responses\":\n```markdown\n### Tasks Interview (from tasks.md)\n- [Topic 1]: [response]\n- Browser verification: playwright\u002Fchrome-devtools-mcp\u002Fnone\u002Fblocked -- [strategy or \"auto\"]\n- Chosen approach: [name] -- [brief description]\n```\n\nPass combined context to delegation prompt as \"Interview Context\".\n\n## Step 3: Execute Task Generation (Agent-Based, Teams Optional)\n\n\u003Cmandatory>\n**Default path: use the normal `Agent` tool with `task-planner`. Do not require Agent Teams.**\n\nALL specs MUST follow POC-first workflow. Read `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fphase-rules.md` for the mandatory 5-phase structure and phase distribution rules.\n\nRead `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fquality-checkpoints.md` for checkpoint insertion rules (frequency, format, final verification sequence).\n\nAgent Teams are experimental and disabled by default in Claude Code. Use the team lifecycle only when `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is set and the `TeamCreate` \u002F `TaskCreate` \u002F `TaskList` \u002F `SendMessage` tools are visible in the current session. If any team tool is unavailable or fails, immediately continue with the direct `Agent(agent_type: task-planner)` path. Treat this as the normal path, not a degraded path.\n\nDirect path:\n\n1. Optionally create a visible native task with `TaskCreate(subject: \"Generate implementation tasks for $spec\", activeForm: \"Generating tasks\")`. If unavailable or failing, continue without it.\n2. Dispatch `Agent(agent_type: task-planner)` with requirements, design, interview context, and the Delegation Context below. Instruct it to:\n   - Read `references\u002Fworkflow-contract.md`, `references\u002Fsource-coverage-audit.md`, `references\u002Fbrowser-verification-policy.md`, and `references\u002Fagent-output-contract.md`\n   - Start `tasks.md` with `## Source Coverage Audit`, then `## Browser Verify`\n   - Cover every source item; if coverage cannot be complete, stop with `TASKS_BLOCKED`\n   - Break implementation into value-slice tasks, using POC-first or TDD phases only as structure\n   - Create tasks with Do\u002FFiles\u002FDone when\u002FVerify\u002FCommit fields\n   - Keep top-level task count inside `autoPolicy.taskTargetRange`; if this requires more than 12 tasks, stop and recommend `\u002Fcurdx-flow:triage`\n   - Insert quality checkpoints according to `autoPolicy.reviewCadence` and `autoPolicy.verificationLevel`\n   - Each task = one commit, tasks must be executable without human interaction\n   - Count total tasks, output to `.\u002Fspecs\u002F$spec\u002Ftasks.md`\n   - If quick mode and policy verification is strict: auto-enable VE tasks. Otherwise keep VE tasks risk-triggered. For UI\u002Ffull-stack work, Browser Verify must select Playwright CLI or Chrome DevTools MCP.\n   - When Browser Verify selects Playwright and no E2E package script exists, include a task to add `test:e2e` or the repo's equivalent script before final verification.\n   - For greenfield work (`intent.workspaceState == \"empty\"` or route `greenfield-spec`), include a walking-skeleton task before business slices. It must prove the selected project shape, contract, and dev runtime can start and verify together.\n   - For scaffold or greenfield foundation work, prefer official or ecosystem-maintained scaffold generators for named stacks when current docs show one exists; self-author only when no trustworthy generator exists, the requested skeleton is intentionally smaller, or a custom skeleton is safer to verify.\n   - Prefer `curdx-flow dev detect`, `curdx-flow dev up`, `curdx-flow dev health`, `curdx-flow dev verify`, and `curdx-flow dev down` for local runtime evidence when project scripts exist.\n   - If the source requirements explicitly require Chrome DevTools MCP, do not make the final verifier a file\u002Ftooling check such as `.\u002Fverify.sh --check` by itself. Generate startup\u002Fcheck\u002Fcleanup steps that keep the server alive for browser interaction, and require `curdx-flow verify run --description` to include the concrete MCP proof: tool used, URL, add\u002Ftoggle\u002Fdelete or equivalent action sequence, DOM assertion, and console-error result.\n3. Wait for the Agent result. Require `TASKS_READY` before proceeding; if `TASKS_BLOCKED`, surface the blocking source items and stop.\n4. Read `$SPEC_PATH\u002Ftasks.md`.\n\nOptional Agent Teams path:\n\n1. `TeamDelete()` once to release any stale team; errors are harmless.\n2. `TeamCreate(team_name: \"tasks-$spec\")`\n3. `TaskCreate(subject: \"Generate implementation tasks for $spec\", activeForm: \"Generating tasks\")`\n4. `Agent(agent_type: task-planner, team_name: \"tasks-$spec\", name: \"planner-1\")` with the same prompt as the direct path.\n5. Wait via automatic teammate messages or a single `TaskList` check.\n6. `SendMessage(type: \"shutdown_request\", recipient: \"planner-1\")`\n7. Read `.\u002Fspecs\u002F$spec\u002Ftasks.md`, then `TeamDelete()`.\n\n> **Delegation Context**: When delegating to task-planner, include these inputs:\n> - **AutoPolicy**: full `.curdx-state.json::autoPolicy` JSON\n> - **Granularity**: `autoPolicy.taskGranularity`, unless `granularity` explicitly overrides it\n> - **Task Target**: `autoPolicy.taskTargetRange`\n> - **Review Cadence**: `autoPolicy.reviewCadence`\n> - **Verification Level**: `autoPolicy.verificationLevel`\n> - **Value Slice Rule**: test\u002Freproduce + implementation + verification + commit stay inside one top-level task\n> - **Intent Facts**: full `.curdx-state.json::intent` JSON when present\n> - **Project Topology**: full `.curdx-state.json::projectTopology` JSON when present\n> - **Greenfield Rule**: if workspace is empty\u002Fgreenfield, plan foundation as a walking skeleton before business slices\n>\n> For VE Tasks — VE1 (startup), VE2 (check), VE3 (cleanup) — generation:\n> - **Browser Verification**: Playwright CLI by default, Chrome DevTools MCP for GIS\u002FWebGL\u002Fcanvas\u002Fmap\u002FGPU\u002Frendering or console\u002Fnetwork\u002Fperformance diagnosis, none only for non-browser work\n> - **Verification Tooling**: the Verification Tooling section from research.md (dev server commands, browser deps, ports, health endpoints)\n> - **Strategy**: the user's chosen verification strategy, or \"auto\" in quick mode\n> - **Lifecycle**: startup must keep the dev server alive until cleanup; short-lived background commands from a subshell are not valid evidence unless a health check proves the server remains reachable.\n\u003C\u002Fmandatory>\n\n## Step 4: Artifact Review (Parallel Two-Stage)\n\n\u003Cmandatory>\n**Review loop must complete before walkthrough. Max 3 iterations.**\n\nRead `.curdx-state.json::autoPolicy.reviewCadence`:\n- `minimal`: skip subagent artifact review for tasks.md; run the task-planner self-check and proceed to walkthrough.\n- `final`, `periodic`, `strict`: run the two-stage review below.\n\nThis step runs the **two-stage review protocol** at the tasks phase boundary: `spec-reviewer` (specCompliance) and `code-quality-reviewer` (codeQuality) are dispatched **in parallel**, in ONE message, against the frozen `tasks.md` artifact. Both reviewers must complete before reconciliation.\n\n**Required reading before dispatch** (read once at top of step, do not skip):\n- [`bounded-parallel-dispatch.md`](${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fbounded-parallel-dispatch.md) — independence criteria + the Review-domain \"ALL Agent calls in ONE message\" rule (anti-pattern #3 + #5–#8). Both reviewers must be spawned in the SAME message.\n- [`two-stage-review.md`](${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Ftwo-stage-review.md) — domain boundary table (specCompliance vs codeQuality), 3-layer drift defense, anti-rationalization rule, SLSA-shape verdict glossary, QuickMode behavior contract.\n\nThe two reviewers do **not** see each other's output (Layer 2 isolation). The coordinator never arbitrates findings across domains.\n\n### 4.1 Bounded parallel dispatch (direct Agent default)\n\n```\n1. Optional TaskCreate(subject: \"Spec-compliance review of tasks.md\",\n                       activeForm: \"Reviewing tasks (spec-compliance)\")\n   Optional TaskCreate(subject: \"Code-quality review of tasks.md\",\n                       activeForm: \"Reviewing tasks (code-quality)\")\n2. # ALL Agent calls in ONE message — see bounded-parallel-dispatch.md anti-pattern #3\n   Agent(agent_type: spec-reviewer,\n        prompt: \"Review .\u002Fspecs\u002F$spec\u002Ftasks.md for spec-compliance ONLY.\n                 Upstream: design.md + requirements.md.\n                 Your domain: traceability, phase artifact structure, requirement\n                 coverage, artifact format. Do NOT comment on code-quality concerns\n                 (smell \u002F security \u002F readability \u002F test-shape) — those belong to the\n                 peer code-quality-reviewer (which you do NOT see and MUST NOT\n                 reference). Emit a markdown findings table and a final line\n                 `REVIEW_PASS` or `REVIEW_FAIL` (byte-equal).\")\n   Agent(agent_type: code-quality-reviewer,\n        prompt: \"Review .\u002Fspecs\u002F$spec\u002Ftasks.md for code-quality ONLY.\n                 Your domain: code smell \u002F security \u002F implementation quality \u002F\n                 readability \u002F test quality \u002F no-hallucinations. Do NOT comment\n                 on traceability to requirements \u002F phase artifact structure \u002F\n                 requirement coverage \u002F artifact format \u002F front-matter — those\n                 belong to spec-reviewer (which you do NOT see and MUST NOT\n                 reference). Emit a markdown findings table and a final line\n                 `REVIEW_PASS` or `REVIEW_FAIL` (byte-equal).\")\n3. # Wait for both Agent results; collect REVIEW_PASS\u002FREVIEW_FAIL final lines.\n4. # Persist verdicts under verificationBlocks.tasks.reviews via merge-state (FR-T3 — never hand-edit state):\n   curdx-flow state merge \\\n     \"$SPEC_PATH\u002F.curdx-state.json\" \\\n     '{\"verificationBlocks\":{\"tasks\":{\"reviews\":{\n        \"specCompliance\":{\"verdict\":\"\u003CPASS|FAIL>\",\"findings\":[...],\"reviewerId\":\"spec-compliance\",\"timestamp\":\"\u003CISO8601>\"},\n        \"codeQuality\":{\"verdict\":\"\u003CPASS|FAIL>\",\"findings\":[...],\"reviewerId\":\"code-quality\",\"timestamp\":\"\u003CISO8601>\"}\n     }}}}'\n```\n\nOptional Agent Teams overlay: if Agent Teams are enabled and available, create `TeamCreate(team_name: \"review-tasks-$spec\")`, add matching `team_name` and `name` fields to both Agent calls, wait via automatic teammate messages or one `TaskList` check, then `SendMessage(...shutdown_request...)` and `TeamDelete()`. If any team step fails, rerun or continue with the direct dual `Agent(...)` calls above.\n\n### 4.2 QuickMode branch (D5)\n\nRead `state.quickMode` from `.curdx-state.json`. **specCompliance is always a hard gate**; QuickMode only relaxes codeQuality.\n\n```\nif state.quickMode === true:\n  if specCompliance.verdict === \"FAIL\":\n    # Hard gate even in QuickMode — FR-M2 reverse contract.\n    block; show findings; do NOT advance to Step 5.\n  if codeQuality.verdict === \"FAIL\":\n    # Advisory downgrade — set advisory:true via merge-state, surface findings,\n    # continue. Never set advisory on specCompliance.\n    merge-state into verificationBlocks.tasks.reviews.codeQuality.advisory = true\n    log warning to .progress.md; proceed to Step 5.\nelse:                                  # normal mode\n  if specCompliance.verdict === \"FAIL\" OR codeQuality.verdict === \"FAIL\":\n    # Either FAIL blocks. Display findings table, ask user (Step 5 \"Run review\" \u002F \"Request changes\" loop).\n    Iteration \u003C 3: re-invoke task-planner with merged feedback, loop back to 4.1.\n    Iteration >= 3: graceful degradation, log warning, proceed (permissive ceiling matches prior behavior).\n  else:\n    proceed to Step 5.\n```\n\n**Anti-rationalization**: the coordinator MUST NOT pass spec-reviewer's findings into the code-quality-reviewer prompt (or vice versa). Both verdicts are stored verbatim under `verificationBlocks.tasks.reviews`. See [`two-stage-review.md`](${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Ftwo-stage-review.md) §2.\n\n**Revision delegation**: Re-invoke task-planner with the merged feedback (both reviewers' findings concatenated, attributed by `reviewerId`) and design.md + requirements.md upstream context. Focus on the union of issues.\n\n**Error handling**: Reviewer no signal = treat as REVIEW_PASS for that slot (permissive ceiling). Agent failure = retry once, then use the surviving reviewer's verdict alone (still hard-gate on specCompliance if it survived).\n\n**Fallback**: Direct dual `Agent(...)` calls in ONE message are the default. Team failures are non-blocking unless both reviewers fail to return a verdict.\n\u003C\u002Fmandatory>\n\n## Step 5: Walkthrough & Approval\n\n\u003Cmandatory>\n**WALKTHROUGH IS REQUIRED - DO NOT SKIP.**\n\nRead `.\u002Fspecs\u002F$spec\u002Ftasks.md` and display:\n\n```\nTasks complete for '$spec'.\nOutput: $PWD\u002Fspecs\u002F$spec\u002Ftasks.md\n\n## What I Planned\n\n**Total**: [X] tasks across 4 phases\n\n**Phase Breakdown**:\n- Phase 1 (POC): [count] tasks - proves the idea works\n- Phase 2 (Refactor): [count] tasks - clean up\n- Phase 3 (Testing): [count] tasks - add coverage\n- Phase 4 (Quality): [count] tasks - CI\u002FPR\n\n**POC Milestone**: Task [X.Y] - [brief description of what's working at that point]\n```\n\u003C\u002Fmandatory>\n\n### User Approval (skip if --quick)\n\nIf `--quick`, skip to Step 6.\n\nAsk ONE question: \"How do you want to proceed?\" with these options via AskUserQuestion:\n1. **Approve** (Recommended) -- Accept artifact as-is, advance to next phase\n2. **Run review** -- Spawn spec-reviewer to validate against rubrics, show findings, then loop back to this choice\n3. **Request changes** -- Provide specific feedback to revise the artifact\n\n**If \"Approve\"**: proceed to Step 6.\n**If \"Run review\"**: Invoke spec-reviewer via Agent tool with full tasks.md content (upstream: design.md + requirements.md). Display findings table. If REVIEW_PASS, note it. If REVIEW_FAIL, show feedback. Then loop back to this same 3-choice question (user decides next action).\n**If \"Request changes\" or \"Other\"**:\n1. Ask what to change\n2. Re-invoke task-planner with direct `Agent(agent_type: task-planner)` and feedback; use the optional team lifecycle only if Agent Teams are enabled and available\n3. Re-display walkthrough, ask again with same 3 choices. Loop until approved.\n\n## Step 6: Finalize\n\n### Update State\n\n1. Count total tasks from generated file\n2. Update `.curdx-state.json`: `{ \"phase\": \"tasks\", \"totalTasks\": \u003Ccount>, \"awaitingApproval\": true }`\n3. Update `.progress.md`: mark design as implicitly approved, set current phase, update task count\n\n### Commit Spec (if enabled)\n\nRead `commitSpec` from `.curdx-state.json`. If true:\n```bash\ngit add .\u002Fspecs\u002F$spec\u002Ftasks.md\ngit commit -m \"spec($spec): add implementation tasks\"\ngit push -u origin $(git branch --show-current)\n```\nIf commit or push fails, display warning but continue.\n\n### Stop\n\n\u003Cmandatory>\n**STOP HERE. DO NOT PROCEED TO IMPLEMENT.**\n\n(Does not apply in `--quick` mode.)\n\n1. Display: `-> Next: Run \u002Fcurdx-flow:implement to start execution`\n2. End your response immediately\n3. Wait for user to explicitly run `\u002Fcurdx-flow:implement`\n\u003C\u002Fmandatory>\n",{"name":5,"description":7,"allowed-tools":43,"argument-hint":44,"disable-model-invocation":45},"Read Write Edit Bash Agent AskUserQuestion","[spec-name] [--task-granularity auto|coarse|standard|fine]",true,"main","7357746802ae7a84cafa93b9dbffd138817b0290","plugins\u002Fcurdx-flow\u002Fskills\u002Ftasks",0,"https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow","https:\u002F\u002Fcurdx.org","https:\u002F\u002Fgithub.com\u002Fmugsun","📮 bydongxin@gmail.com","🧑‍💻 AI Builder & Software Engineer\r\n🚀 Turning ideas into software.          \r\n\r\n","2026-08-19 15:19:29",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":45},[58,61,64],{"tool":59,"command":60},"npx","npx skills add mugsun\u002Fcurdx-flow --skill tasks",{"tool":62,"command":63},"bunx","bunx skills add mugsun\u002Fcurdx-flow --skill tasks",{"tool":65,"command":66},"pnpm","pnpm dlx skills add mugsun\u002Fcurdx-flow --skill tasks","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Ftasks\u002FSKILL.md",[],[70,79,96,108,119,131],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":77,"publishedAt":38},"01M71KDR5EJP6G4VWFCHNJ35PT","help","Fixture help skill","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fruntime-readiness\u002Fclaude-code-plugin-like\u002Fskills\u002Fhelp\u002FSKILL.md",[76],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[72,78],"fixture",{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":38},"01M71KDNAVB000W3MZB1W7CMD8","verification-before-completion","Use when checking fixes, phase exits, completion evidence, or mock-heavy tests before claiming success.","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[86,87,88,89,26,5,90,91,92,93,32,94,95],"verification","verification before completion","only","false","phase","evidence","fixes","tests","mock","state",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":103,"publishedAt":38},"01M71KDKFE975GFYRDC21H1NEE","triage","Use when a large feature should be decomposed into dependency-aware specs.","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Ftriage\u002FSKILL.md",[102],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[98,32,26,27,104,105,28,29,106,31,107,35],"goal","dependency","feature","EPIC",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":115,"publishedAt":38},"01M71KDEV9G51MCXDQWPJH7QST","switch","Use when changing the active spec by name or path.","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Fswitch\u002FSKILL.md",[114],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[110,28,35,36,29,116,117,32,26,31,118,27],"path","active","by name",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":126,"publishedAt":38},"01M71KDDJFRV09YZ08B3WJ39SC","status","Use when inspecting curdx-flow specs, active state, progress, or index status.","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Fstatus\u002FSKILL.md",[125],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[121,127,128,129,28,130,117,95,27,26,32,31],"progress","index","flow","update",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":138,"publishedAt":38},"01M71KDB3BEEK162AMMHR5FSK6","start","Use when starting curdx-flow, creating a spec, resuming work, or routing intent.","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Fstart\u002FSKILL.md",[137],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[133,139,129,30,29,28,104,140,141,142,143,144,27,26,25,145,146,147,148,116],"review","intent","work","fresh","agent skill","commit","mode","quick","deep","minimal"]