[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71KDB3BEEK162AMMHR5FSK6":3,"skill-same:01M71KDB3BEEK162AMMHR5FSK6":74},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":73},"01M71KDB3BEEK162AMMHR5FSK6","start",null,"Use when starting curdx-flow, creating a spec, resuming work, or routing intent.","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\u002Fstart\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,38,39,40,41,42],"goal","when","path","mode","quick","fresh","agent skill","deep","intent","minimal","review","auto","edit","write","read","work","Bash","flow","commit","2026-11-10 10:12:30",false,"---\nname: start\ndescription: Use when starting curdx-flow, creating a spec, resuming work, or routing intent.\nargument-hint: \"[name] [goal] [--fresh] [--quick] [--mode auto|fast|deep] [--task-granularity auto|coarse|standard|fine] [--review minimal|standard|strict] [--commit-spec] [--no-commit-spec] [--specs-dir \u003Cpath>]\"\nallowed-tools: \"Read Write Edit Bash Agent Skill AskUserQuestion\"\ndisable-model-invocation: true\n---\n\n# Smart Start\n\nAct as the curdx-flow router. Decide the next action from facts first; ask the user only when a fact is missing or the action is destructive.\n\n## Dev Context\n\nBefore routing, assume the current project may be frontend-only, backend-only, full-stack monorepo, split frontend\u002Fbackend repos, a CLI\u002Flibrary, or a Claude Code plugin. The deterministic router reads project `CLAUDE.md` Dev sections, `.claude\u002Fcurdx-flow.local.md`, and cheap manifests to infer code roots.\n\nUsers do not need to know `--add-dir`. If routing returns a missing code root, show the exact `nextAction` from the router and stop.\n\n## Route First\n\n1. Parse `$ARGUMENTS` into optional spec name, goal text, and flags.\n2. Run the deterministic router:\n   ```bash\n   curdx-flow route \\\n     --name \"$name\" \\\n     --goal \"$goal\" \\\n     --flags \"$ARGUMENTS\"\n   ```\n   For routes that are not `direct-change` or `blocked-ask-user`, compile the\n   execution contract before planning:\n   ```bash\n   curdx-flow route --compile --record \\\n     --name \"$name\" \\\n     --goal \"$goal\" \\\n     --flags \"$ARGUMENTS\"\n   ```\n3. Run the last-mile autopilot:\n   ```bash\n   curdx-flow last-mile \\\n     --name \"$name\" \\\n     --goal \"$goal\"\n   ```\n   Treat `phase`, `problemTypes`, `capabilityPlan`, `evidenceRequired`, and\n   `coordinatorInstruction` as the automatic execution policy. Do not ask the\n   user which skill to run when the autopilot already identifies the needed\n   capability.\n4. Treat the returned `route` and `intent` as the source of truth. Do not invent a different workflow unless the router says `blocked-ask-user` and the user's answer changes the facts.\n4. Always read these adaptive facts before acting:\n   - `topology.workspaceState`: `empty`, `scaffolded`, `existing`, or `split-repo`\n   - `intent.intentKind`: `scaffold`, `product`, `prototype`, `import-spec`, `feature`, `fix`, `refactor`, `release`, or `unknown`\n   - `intent.clarity`, `intent.stackSpecified`, `intent.artifactProvided`, `intent.deliveryExpectation`, and `intent.missingFacts`\n5. If the router returns `recommendedCapabilities`, treat them as phase-specific hints, not mandatory steps. `availabilityState` is the operational signal: `available` means visible now, `expected` means the environment should provide it, and `missing` means skip or fix setup before relying on it. `availability: plugin-dependency` means a Claude Code plugin dependency; `availability: external-expected` means an MCP provided by the user's external setup such as `context7` or `sequential-thinking`. curdx-flow recommends existing wheels (`context7`, `claude-mem`, `ui-ux-pro-max`, `chrome-devtools-mcp`, `sequential-thinking`, `pua`) and must not reimplement or bundle duplicate MCP config for them. Workflow\u002Fpolicy hints such as `docs-query`, `tdd-cycle`, `security-review`, `stack-specific-verification`, and `context-budget` need no installation.\n6. For last-mile phase\u002Fcapability\u002Fevidence interpretation, use `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Flast-mile-autopilot.md`.\n7. For stack profile, quality gates, suggested verifier, and context-budget interpretation, use `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fintelligent-routing.md` only when the compact router output is insufficient.\n8. For execution brief fields, completion contract, and `.curdx\u002Fbrain.jsonl` interpretation, use `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fexecution-brief.md` only when the compact brief output is insufficient.\n\n## Route Actions\n\n| Route | Action |\n|---|---|\n| `resume-current` | Resume the active spec at `nextAction`. Do not create a new spec. |\n| `direct-change` | Handle the change directly in the current turn. Do not create a spec or `tasks.md`. |\n| `lite-spec` | Create a lightweight spec, then generate 1-3 value-slice tasks. |\n| `full-spec` | Run the normal research -> requirements -> design -> tasks -> implement workflow. |\n| `epic-split` | Invoke `\u002Fcurdx-flow:triage` with the same goal. Do not force the work into one spec. |\n| `scaffold` | Select the best scaffold source, create only the explicitly requested skeleton, write assumptions, then run baseline verification. |\n| `product-inception` | Create product context before application code: mission, constraints, roadmap, tech-stack assumptions, and constitution. |\n| `greenfield-spec` | Create a greenfield spec with product context, technical plan, walking skeleton, and vertical-slice tasks. |\n| `prototype` | Create a bounded prototype spec with an explicit success criterion and minimal verification loop. |\n| `import-spec` | Import the provided PRD\u002Fspec\u002Fdesign\u002FAPI artifact into curdx-flow phase artifacts, then plan implementation. |\n| `blocked-ask-user` | Ask one focused question, then rerun the router with the new fact. |\n\nIf `blocked-ask-user` includes `topology.missingRoots`, do not ask an open-ended question. Print the router's `Next` line exactly, such as `\u002Fadd-dir ..\u002Ffrontend`, and tell the user to rerun `\u002Fcurdx-flow:start` after adding the directory.\n\n## Pre-Question Discovery (Greenfield \u002F Inception \u002F Blocked)\n\n\u003Cmandatory>\n**For `product-inception`, `greenfield-spec`, `prototype`, `import-spec`, or `blocked-ask-user` routes with non-empty `intent.missingFacts`, you MUST fan out a Discovery subagent batch BEFORE asking the user any clarifying question and BEFORE writing any product-context artifact.**\n\nThis is the Discovery domain of `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fbounded-parallel-dispatch.md`. The independence rules and anti-patterns in that doc apply here.\n\u003C\u002Fmandatory>\n\n### Why\n\nAsking the user before fanning out is an anti-pattern (#14 in bounded-parallel-dispatch). It serializes work that should be parallel, surfaces low-leverage questions whose answers are already in the codebase or memory, and produces interview options without `[Recommended]` grounded in facts. Anthropic's canonical guidance frames subagents as the primary tool for investigation precisely because main-context exploration \"fills with file contents you won't reference again.\"\n\n### When this section fires\n\nAll of the following must hold:\n\n1. Route ∈ {`product-inception`, `greenfield-spec`, `prototype`, `import-spec`, `blocked-ask-user`}\n2. `intent.missingFacts` is non-empty (parse from `curdx-flow route` output)\n3. At least one `missingFact` is answerable from: prior memory, this repo's files, or current external docs\n\nIf route is `blocked-ask-user` AND `topology.missingRoots` is the only missing fact, skip this section and follow the `\u002Fadd-dir` instruction above. Missing-roots is a deterministic user action, not a discoverable fact.\n\n### Fan-out composition (minimum 3 agents in ONE message)\n\nFor empty workspaces and product-inception, dispatch ALL of these in a single message:\n\n```text\n1. general-purpose agent invoking mcp__plugin_claude-mem_mcp-search__smart_search\n   → Search user's claude-mem for prior decisions, failed attempts, similar projects\n   → Output cap: 250 words, concrete corpus\u002Fobservation references\n\n2. Explore agent rooted at .planning\u002F, docs\u002F, CLAUDE.md, .gitignore, package.json\n   → Surface existing conventions, prior planning notes, declared stack\n   → Output cap: 200 words, file:line references\n\n3. N research-analyst agents — ONE per candidate stack OR prior-art topic in missingFacts\n   → Each agent owns ONE topic; never combine\n   → Output cap: 300 words per agent, cite sources\n   → If a candidate stack is named (e.g., \"node-pty\", \"xterm.js\"), prefer Context7 MCP via the agent's tool surface before generic web search\n```\n\nFor non-empty workspaces or `blocked-ask-user` with codebase-resolvable facts, drop the research-analyst agents if `missingFacts` are all repo-internal.\n\n### Synthesis contract\n\nAfter all agents return, the coordinator MUST:\n\n1. **Cross-validate** memory hits against current repo state — claude-mem snapshots can be stale. A `function foo()` referenced in memory may have been renamed; treat memory as \"what was true when written\", not \"what is true now\". Verify with grep\u002FRead before recommending.\n2. **Map every `missingFact` to evidence**: which agent answered it, with what citation. Unanswered facts become the user-decision interview questions.\n3. **Re-derive interview options with `[Recommended]`** grounded in the synthesis. No fabricated options; every option must trace to a finding or an explicit assumption marker.\n4. **Persist findings** to `.planning\u002Fdiscovery\u002F\u003Croute>-\u003Ctimestamp>.md` if `.planning\u002F` exists, so re-runs and other sessions can reuse them.\n\n### What this section is NOT\n\n- Not a license to write product-context artifacts directly. Artifact writing still goes through the normal phase agents (research-analyst \u002F product-manager \u002F etc.) once a spec is created.\n- Not a replacement for the interview. It produces grounded interview options; the user still confirms the irreducible decisions.\n- Not for `direct-change`, `scaffold` (with clear stack), `lite-spec`, `full-spec`, `epic-split`, or `resume-current` routes. Those have their own dispatch patterns elsewhere.\n\n## Hard Rules\n\n- Use behavior route names exactly as returned: `direct-change`, `lite-spec`, `full-spec`, `epic-split`, `scaffold`, `product-inception`, `greenfield-spec`, `prototype`, `import-spec`, `resume-current`, `blocked-ask-user`.\n- Top-level tasks are value slices. Never split a slice into separate \"write test\", \"write implementation\", \"run test\", or \"commit\" tasks.\n- If the route says `direct-change`, skip branch prompts, spec creation, phase documents, task planning, and subagents unless the user explicitly asks for them.\n- If the route says `scaffold`, do only what the user explicitly asked to scaffold. Prefer official or ecosystem-maintained generators for the named stack when current docs show one exists; self-author the skeleton only when that is safer, smaller, or no trustworthy generator exists. Record assumptions in `CLAUDE.md` or `.curdx\u002Fassumptions.md` when no project convention exists, then run the best detected baseline command through `curdx-flow dev verify` or the project equivalent.\n- If the route says `product-inception`, do not write application source yet. Produce compact product context artifacts and ask at most the missing high-leverage questions from `intent.missingFacts`.\n- If the route says `greenfield-spec`, bootstrap curdx-flow artifacts before app code: product context, constitution, requirements, design, tasks, then implementation.\n- If the route says `prototype`, constrain scope to a success criterion; do not silently expand it into a production product.\n- If the route says `import-spec`, preserve source artifact traceability in research\u002Frequirements\u002Fdesign\u002Ftasks rather than re-interviewing from scratch.\n- If `recommendedCapabilities` includes tool, workflow, or policy hints, use the recommendation only at its listed phase and only when it materially reduces uncertainty, improves context efficiency, or verifies real behavior. If a future recommendation is marked `check-if-installed`, skip silently when that capability is absent.\n- If the route says `epic-split`, stop single-spec creation and run triage.\n- If a spec state is created, store `autoPolicy` for compatibility and set `maxGlobalIterations` from policy, defaulting to 30 if the helper fails.\n\n## Empty Workspace Rules\n\nAn empty folder is not a small feature request. When\n`topology.workspaceState == \"empty\"`, route by intent:\n\n- `scaffold`: the user named a stack or starter and expects files now.\n- `product-inception`: the user has a product idea but missing domain, user,\n  MVP, or acceptance facts.\n- `greenfield-spec`: the product and stack are clear enough to plan a usable\n  app.\n- `prototype`: the user wants a demo\u002FPOC\u002Fspike.\n- `import-spec`: the user supplied or referenced a PRD, design, OpenAPI, or\n  other source artifact.\n\nFor greenfield work, create or preserve these context artifacts before coding:\n\n```text\ndocs\u002Fmission.md          # product\u002Fuser\u002Fproblem\ndocs\u002Froadmap.md          # first usable slice and later slices\ndocs\u002Ftech-stack.md       # chosen stack and assumptions\ndocs\u002Fconstitution.md     # quality, testing, security, UX, deployment rules\n```\n\nIf the user already has equivalent files, reuse them. Do not create a separate\nmethodology folder when the repository has a better convention.\n\nThe first implementation task in a greenfield app must be a walking skeleton:\nselected runtime roots, contract, dev environment, and verification command run\ntogether. For example, a full-stack app should prove a real UI route can call\na real service health\u002Fstatus endpoint before business features begin.\n\nUse `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fgreenfield-delivery.md` as the detailed\ncontract for these artifacts and tasks.\n\n## Scaffold Source Selection\n\nFor `scaffold`, choose the source before writing files:\n\n1. Identify the requested target shape: frontend app, backend service,\n   full-stack workspace, CLI, library, plugin, data tool, or another explicit\n   shape from the user.\n2. When the user named a stack or framework, check the latest official docs or\n   trusted ecosystem docs for the current scaffold command\u002FAPI before running\n   it. Treat package-manager create flows, documented remote initializer APIs,\n   framework CLIs, templates, and project-local generators as candidates. Do\n   not make any single stack special in the route logic.\n3. Prefer non-global, repeatable commands (`npm create`, `pnpm create`,\n   `npx`, package-manager `dlx`, `curl` to a documented initializer API, or a\n   project-local generator). Avoid installing global CLIs.\n4. If the generator is interactive and missing choices materially affect the\n   result, ask one focused question. Otherwise choose conservative defaults\n   from the user's request and record them.\n5. Self-author the scaffold only when no trustworthy generator exists, the\n   generator cannot satisfy the requested constraints, the requested skeleton is\n   intentionally smaller than the generator output, or a custom skeleton is\n   clearly easier to verify. Record the reason.\n6. After generation, normalize scripts and run baseline verification. Do not\n   claim the scaffold works without evidence.\n\n## New Spec Creation\n\nFor `lite-spec`, `full-spec`, `greenfield-spec`, `prototype`, and `import-spec`:\n\n1. Ensure the current branch is appropriate using `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fbranch-management.md`.\n2. Validate or ask for a kebab-case spec name only if missing.\n3. Validate or ask for the goal only if missing.\n4. Resolve the spec directory from `--specs-dir` or the default specs dir.\n5. Create the spec directory, update `$defaultDir\u002F.current-spec`, and ensure `.gitignore` covers `$defaultDir\u002F.current-spec`, `$defaultDir\u002F.current-epic`, and `**\u002F.progress.md`.\n   - If writing the marker under the default specs dir, write only the bare spec name, e.g. `greet-helper`.\n   - If writing a non-default spec root, write the relative path, e.g. `packages\u002Fapi\u002Fspecs\u002Fauth-flow`.\n   - Do not write `specs\u002F\u003Cname>` for default-root specs; that can be interpreted as a path by newer runtime resolvers.\n   - Do not write a project-root `.current-spec`; runtime state lives under the configured specs root.\n   - Preferred write pattern:\n     ```bash\n     mkdir -p \"$defaultDir\"\n     if [ \"$basePath\" = \"$defaultDir\u002F$name\" ]; then\n       printf '%s\\n' \"$name\" > \"$defaultDir\u002F.current-spec\"\n     else\n       printf '%s\\n' \"$basePath\" > \"$defaultDir\u002F.current-spec\"\n     fi\n     ```\n6. Compute compatibility policy:\n   ```bash\n   ROUTE_JSON=$(curdx-flow route --name \"$name\" --goal \"$goal\" --flags \"$ARGUMENTS\")\n   POLICY_JSON=$(printf '%s' \"$ROUTE_JSON\" | node -e 'let s=\"\";process.stdin.on(\"data\",c=>s+=c);process.stdin.on(\"end\",()=>process.stdout.write(JSON.stringify(JSON.parse(s).policy)))')\n   ```\n7. Initialize the spec state file. The file lives at `$basePath\u002F.curdx-state.json` — never at the project root or anywhere else. Create the parent directory first if needed, then write the following shape:\n   ```json\n   {\n     \"version\": 2,\n     \"source\": \"spec\",\n     \"name\": \"$name\",\n     \"basePath\": \"$basePath\",\n     \"identity\": { \"name\": \"$name\", \"basePath\": \"$basePath\", \"goal\": \"$goal\" },\n     \"phase\": \"research\",\n     \"taskIndex\": 0,\n     \"totalTasks\": 0,\n     \"taskIteration\": 1,\n     \"maxTaskIterations\": \"\u003CPOLICY_JSON.maxTaskIterations or 5>\",\n     \"globalIteration\": 1,\n     \"maxGlobalIterations\": \"\u003CPOLICY_JSON.maxGlobalIterations or 30>\",\n     \"commitSpec\": true,\n     \"quickMode\": false,\n     \"executionDriver\": \"goal\",\n     \"autoPolicy\": \"\u003CPOLICY_JSON object>\",\n     \"route\": \"\u003CROUTE_JSON compact object>\",\n     \"intent\": \"\u003CROUTE_JSON.intent object>\",\n     \"completed\": false\n   }\n   ```\n   All later mutations to this file (verification blocks, completion markers, task index updates) must go through `curdx-flow verify run` or `curdx-flow state merge \"$basePath\u002F.curdx-state.json\" '\u003Cpatch>'`. Do not hand-edit `.curdx-state.json` with Write\u002FEdit after creation — the CLI maintains schema invariants such as `verificationBlocks.execution.srcMtime` (epoch ms) that hand-written JSON routinely omits.\n8. Create `.progress.md` with the original goal and the selected behavior route.\n\nIf policy computation fails, use this fallback cap:\n\n```json\n{ \"maxGlobalIterations\": 30 }\n```\n\nFor `lite-spec`, keep interviews minimal and generate only 1-3 value-slice tasks.\nFor `full-spec`, continue with research and the normal phase flow.\nFor `greenfield-spec`, include product context and constitution before design,\nthen require a walking-skeleton task before feature slices.\nFor `prototype`, keep tasks bounded to the success criterion.\nFor `import-spec`, keep traceability to the imported source artifact in every\nphase artifact.\n\nWhen a spec state is created and router output includes `topology`, `intent`, or `recommendedCapabilities`, store compact copies in `.curdx-state.json` as `projectTopology`, `intent`, and `recommendedCapabilities`. If last-mile output is available, store a compact `lastMile` object with `phase`, `problemType`, `problemTypes`, `capabilityPlan`, `evidenceRequired`, and `lastDecisionAt`.\n\n## Quick Artifact Contract\n\nWhen `--quick` causes this skill to generate phase artifacts inline instead of delegating through each phase command:\n\n\u003Cmandatory>\nThe quick path does not lift the runtime-CLI contract for `.curdx-state.json`. Even in `--quick --mode fast`, do not Write\u002FEdit the state file beyond the initial schema in \"New Spec Creation\" step 7. Verification blocks must be produced by `curdx-flow verify run`, and completion\u002Fiteration mutations must use `curdx-flow state merge \"$basePath\u002F.curdx-state.json\" '\u003Cpatch>'`. Hand-written `verificationBlocks` invariably miss `srcMtime` and break `check-verification-blocks` \u002F `verify-blocks` invariants.\n\u003C\u002Fmandatory>\n\n- `tasks.md` must still use the task-planner format contract.\n- Start `tasks.md` with `## Source Coverage Audit`.\n- Every executable top-level task must be a checkbox list item, not a heading:\n\n```markdown\n- [ ] 1.1 Implement greet helper\n  - **Do**:\n    1. Edit `src\u002Fgreet.js`\n    2. Run `npm test`\n  - **Files**: `src\u002Fgreet.js`, `test\u002Fgreet.test.js`\n  - **Done when**: `greet(\" Ada \")` and empty-name fallback pass\n  - **Verify**: `npm test`\n  - **Commit**: `feat(greet): implement greeting helper`\n  - _Requirements: FR-1, AC-1_\n```\n\n- Do not create heading-only task sections such as `## T1`; runtime task parsing ignores them and `\u002Fcurdx-flow:status` will report `empty-tasks`.\n- If implementation is completed in the same quick run, run the final task's exact **Verify** command through the runtime recorder before marking completion:\n  ```bash\n  curdx-flow verify run --phase execution --command \"\u003Cexact Verify command>\" --spec \"$name\"\n  ```\n  This command actually executes the verification, records `.curdx-state.json::verificationBlocks.execution` with the command, exit code, timestamp, and source mtime, and returns the verification exit code. If the verification fails, do not set `completed: true`; fix the issue and rerun the recorder.\n- If the goal, requirements, or acceptance criteria require browser evidence, Playwright, or Chrome DevTools MCP, `--check`\u002Ffile-existence commands are not sufficient completion evidence. The quick run must first perform the real browser interaction, then record the shell verifier with `--description` containing the concrete browser proof: tool used, URL, action sequence, final DOM assertion, and console-error result. Do not mark completion when that proof is absent.\n- After recorded verification passes, mark the checkbox `[x]`, set `completed: true`, and leave `taskIndex` equal to the number of top-level checkbox tasks.\n\n## Skill Discovery\n\nOnly scan and invoke additional skills when the route is `lite-spec`, `full-spec`, `greenfield-spec`, `prototype`, or `import-spec`. Match skills by semantic relevance to the goal. Skip discovery for `direct-change` and `scaffold` unless the user explicitly asks to use a skill.\n\n## Output\n\nAlways start with a short routing summary:\n\n```text\nRoute: \u003Croute>\nReason: \u003Creason>\nNext: \u003CnextAction>\n```\n\nThen perform the next action. If the route is `blocked-ask-user`, ask exactly one focused question.\n","# Smart Start\n\nAct as the curdx-flow router. Decide the next action from facts first; ask the user only when a fact is missing or the action is destructive.\n\n## Dev Context\n\nBefore routing, assume the current project may be frontend-only, backend-only, full-stack monorepo, split frontend\u002Fbackend repos, a CLI\u002Flibrary, or a Claude Code plugin. The deterministic router reads project `CLAUDE.md` Dev sections, `.claude\u002Fcurdx-flow.local.md`, and cheap manifests to infer code roots.\n\nUsers do not need to know `--add-dir`. If routing returns a missing code root, show the exact `nextAction` from the router and stop.\n\n## Route First\n\n1. Parse `$ARGUMENTS` into optional spec name, goal text, and flags.\n2. Run the deterministic router:\n   ```bash\n   curdx-flow route \\\n     --name \"$name\" \\\n     --goal \"$goal\" \\\n     --flags \"$ARGUMENTS\"\n   ```\n   For routes that are not `direct-change` or `blocked-ask-user`, compile the\n   execution contract before planning:\n   ```bash\n   curdx-flow route --compile --record \\\n     --name \"$name\" \\\n     --goal \"$goal\" \\\n     --flags \"$ARGUMENTS\"\n   ```\n3. Run the last-mile autopilot:\n   ```bash\n   curdx-flow last-mile \\\n     --name \"$name\" \\\n     --goal \"$goal\"\n   ```\n   Treat `phase`, `problemTypes`, `capabilityPlan`, `evidenceRequired`, and\n   `coordinatorInstruction` as the automatic execution policy. Do not ask the\n   user which skill to run when the autopilot already identifies the needed\n   capability.\n4. Treat the returned `route` and `intent` as the source of truth. Do not invent a different workflow unless the router says `blocked-ask-user` and the user's answer changes the facts.\n4. Always read these adaptive facts before acting:\n   - `topology.workspaceState`: `empty`, `scaffolded`, `existing`, or `split-repo`\n   - `intent.intentKind`: `scaffold`, `product`, `prototype`, `import-spec`, `feature`, `fix`, `refactor`, `release`, or `unknown`\n   - `intent.clarity`, `intent.stackSpecified`, `intent.artifactProvided`, `intent.deliveryExpectation`, and `intent.missingFacts`\n5. If the router returns `recommendedCapabilities`, treat them as phase-specific hints, not mandatory steps. `availabilityState` is the operational signal: `available` means visible now, `expected` means the environment should provide it, and `missing` means skip or fix setup before relying on it. `availability: plugin-dependency` means a Claude Code plugin dependency; `availability: external-expected` means an MCP provided by the user's external setup such as `context7` or `sequential-thinking`. curdx-flow recommends existing wheels (`context7`, `claude-mem`, `ui-ux-pro-max`, `chrome-devtools-mcp`, `sequential-thinking`, `pua`) and must not reimplement or bundle duplicate MCP config for them. Workflow\u002Fpolicy hints such as `docs-query`, `tdd-cycle`, `security-review`, `stack-specific-verification`, and `context-budget` need no installation.\n6. For last-mile phase\u002Fcapability\u002Fevidence interpretation, use `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Flast-mile-autopilot.md`.\n7. For stack profile, quality gates, suggested verifier, and context-budget interpretation, use `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fintelligent-routing.md` only when the compact router output is insufficient.\n8. For execution brief fields, completion contract, and `.curdx\u002Fbrain.jsonl` interpretation, use `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fexecution-brief.md` only when the compact brief output is insufficient.\n\n## Route Actions\n\n| Route | Action |\n|---|---|\n| `resume-current` | Resume the active spec at `nextAction`. Do not create a new spec. |\n| `direct-change` | Handle the change directly in the current turn. Do not create a spec or `tasks.md`. |\n| `lite-spec` | Create a lightweight spec, then generate 1-3 value-slice tasks. |\n| `full-spec` | Run the normal research -> requirements -> design -> tasks -> implement workflow. |\n| `epic-split` | Invoke `\u002Fcurdx-flow:triage` with the same goal. Do not force the work into one spec. |\n| `scaffold` | Select the best scaffold source, create only the explicitly requested skeleton, write assumptions, then run baseline verification. |\n| `product-inception` | Create product context before application code: mission, constraints, roadmap, tech-stack assumptions, and constitution. |\n| `greenfield-spec` | Create a greenfield spec with product context, technical plan, walking skeleton, and vertical-slice tasks. |\n| `prototype` | Create a bounded prototype spec with an explicit success criterion and minimal verification loop. |\n| `import-spec` | Import the provided PRD\u002Fspec\u002Fdesign\u002FAPI artifact into curdx-flow phase artifacts, then plan implementation. |\n| `blocked-ask-user` | Ask one focused question, then rerun the router with the new fact. |\n\nIf `blocked-ask-user` includes `topology.missingRoots`, do not ask an open-ended question. Print the router's `Next` line exactly, such as `\u002Fadd-dir ..\u002Ffrontend`, and tell the user to rerun `\u002Fcurdx-flow:start` after adding the directory.\n\n## Pre-Question Discovery (Greenfield \u002F Inception \u002F Blocked)\n\n\u003Cmandatory>\n**For `product-inception`, `greenfield-spec`, `prototype`, `import-spec`, or `blocked-ask-user` routes with non-empty `intent.missingFacts`, you MUST fan out a Discovery subagent batch BEFORE asking the user any clarifying question and BEFORE writing any product-context artifact.**\n\nThis is the Discovery domain of `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fbounded-parallel-dispatch.md`. The independence rules and anti-patterns in that doc apply here.\n\u003C\u002Fmandatory>\n\n### Why\n\nAsking the user before fanning out is an anti-pattern (#14 in bounded-parallel-dispatch). It serializes work that should be parallel, surfaces low-leverage questions whose answers are already in the codebase or memory, and produces interview options without `[Recommended]` grounded in facts. Anthropic's canonical guidance frames subagents as the primary tool for investigation precisely because main-context exploration \"fills with file contents you won't reference again.\"\n\n### When this section fires\n\nAll of the following must hold:\n\n1. Route ∈ {`product-inception`, `greenfield-spec`, `prototype`, `import-spec`, `blocked-ask-user`}\n2. `intent.missingFacts` is non-empty (parse from `curdx-flow route` output)\n3. At least one `missingFact` is answerable from: prior memory, this repo's files, or current external docs\n\nIf route is `blocked-ask-user` AND `topology.missingRoots` is the only missing fact, skip this section and follow the `\u002Fadd-dir` instruction above. Missing-roots is a deterministic user action, not a discoverable fact.\n\n### Fan-out composition (minimum 3 agents in ONE message)\n\nFor empty workspaces and product-inception, dispatch ALL of these in a single message:\n\n```text\n1. general-purpose agent invoking mcp__plugin_claude-mem_mcp-search__smart_search\n   → Search user's claude-mem for prior decisions, failed attempts, similar projects\n   → Output cap: 250 words, concrete corpus\u002Fobservation references\n\n2. Explore agent rooted at .planning\u002F, docs\u002F, CLAUDE.md, .gitignore, package.json\n   → Surface existing conventions, prior planning notes, declared stack\n   → Output cap: 200 words, file:line references\n\n3. N research-analyst agents — ONE per candidate stack OR prior-art topic in missingFacts\n   → Each agent owns ONE topic; never combine\n   → Output cap: 300 words per agent, cite sources\n   → If a candidate stack is named (e.g., \"node-pty\", \"xterm.js\"), prefer Context7 MCP via the agent's tool surface before generic web search\n```\n\nFor non-empty workspaces or `blocked-ask-user` with codebase-resolvable facts, drop the research-analyst agents if `missingFacts` are all repo-internal.\n\n### Synthesis contract\n\nAfter all agents return, the coordinator MUST:\n\n1. **Cross-validate** memory hits against current repo state — claude-mem snapshots can be stale. A `function foo()` referenced in memory may have been renamed; treat memory as \"what was true when written\", not \"what is true now\". Verify with grep\u002FRead before recommending.\n2. **Map every `missingFact` to evidence**: which agent answered it, with what citation. Unanswered facts become the user-decision interview questions.\n3. **Re-derive interview options with `[Recommended]`** grounded in the synthesis. No fabricated options; every option must trace to a finding or an explicit assumption marker.\n4. **Persist findings** to `.planning\u002Fdiscovery\u002F\u003Croute>-\u003Ctimestamp>.md` if `.planning\u002F` exists, so re-runs and other sessions can reuse them.\n\n### What this section is NOT\n\n- Not a license to write product-context artifacts directly. Artifact writing still goes through the normal phase agents (research-analyst \u002F product-manager \u002F etc.) once a spec is created.\n- Not a replacement for the interview. It produces grounded interview options; the user still confirms the irreducible decisions.\n- Not for `direct-change`, `scaffold` (with clear stack), `lite-spec`, `full-spec`, `epic-split`, or `resume-current` routes. Those have their own dispatch patterns elsewhere.\n\n## Hard Rules\n\n- Use behavior route names exactly as returned: `direct-change`, `lite-spec`, `full-spec`, `epic-split`, `scaffold`, `product-inception`, `greenfield-spec`, `prototype`, `import-spec`, `resume-current`, `blocked-ask-user`.\n- Top-level tasks are value slices. Never split a slice into separate \"write test\", \"write implementation\", \"run test\", or \"commit\" tasks.\n- If the route says `direct-change`, skip branch prompts, spec creation, phase documents, task planning, and subagents unless the user explicitly asks for them.\n- If the route says `scaffold`, do only what the user explicitly asked to scaffold. Prefer official or ecosystem-maintained generators for the named stack when current docs show one exists; self-author the skeleton only when that is safer, smaller, or no trustworthy generator exists. Record assumptions in `CLAUDE.md` or `.curdx\u002Fassumptions.md` when no project convention exists, then run the best detected baseline command through `curdx-flow dev verify` or the project equivalent.\n- If the route says `product-inception`, do not write application source yet. Produce compact product context artifacts and ask at most the missing high-leverage questions from `intent.missingFacts`.\n- If the route says `greenfield-spec`, bootstrap curdx-flow artifacts before app code: product context, constitution, requirements, design, tasks, then implementation.\n- If the route says `prototype`, constrain scope to a success criterion; do not silently expand it into a production product.\n- If the route says `import-spec`, preserve source artifact traceability in research\u002Frequirements\u002Fdesign\u002Ftasks rather than re-interviewing from scratch.\n- If `recommendedCapabilities` includes tool, workflow, or policy hints, use the recommendation only at its listed phase and only when it materially reduces uncertainty, improves context efficiency, or verifies real behavior. If a future recommendation is marked `check-if-installed`, skip silently when that capability is absent.\n- If the route says `epic-split`, stop single-spec creation and run triage.\n- If a spec state is created, store `autoPolicy` for compatibility and set `maxGlobalIterations` from policy, defaulting to 30 if the helper fails.\n\n## Empty Workspace Rules\n\nAn empty folder is not a small feature request. When\n`topology.workspaceState == \"empty\"`, route by intent:\n\n- `scaffold`: the user named a stack or starter and expects files now.\n- `product-inception`: the user has a product idea but missing domain, user,\n  MVP, or acceptance facts.\n- `greenfield-spec`: the product and stack are clear enough to plan a usable\n  app.\n- `prototype`: the user wants a demo\u002FPOC\u002Fspike.\n- `import-spec`: the user supplied or referenced a PRD, design, OpenAPI, or\n  other source artifact.\n\nFor greenfield work, create or preserve these context artifacts before coding:\n\n```text\ndocs\u002Fmission.md          # product\u002Fuser\u002Fproblem\ndocs\u002Froadmap.md          # first usable slice and later slices\ndocs\u002Ftech-stack.md       # chosen stack and assumptions\ndocs\u002Fconstitution.md     # quality, testing, security, UX, deployment rules\n```\n\nIf the user already has equivalent files, reuse them. Do not create a separate\nmethodology folder when the repository has a better convention.\n\nThe first implementation task in a greenfield app must be a walking skeleton:\nselected runtime roots, contract, dev environment, and verification command run\ntogether. For example, a full-stack app should prove a real UI route can call\na real service health\u002Fstatus endpoint before business features begin.\n\nUse `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fgreenfield-delivery.md` as the detailed\ncontract for these artifacts and tasks.\n\n## Scaffold Source Selection\n\nFor `scaffold`, choose the source before writing files:\n\n1. Identify the requested target shape: frontend app, backend service,\n   full-stack workspace, CLI, library, plugin, data tool, or another explicit\n   shape from the user.\n2. When the user named a stack or framework, check the latest official docs or\n   trusted ecosystem docs for the current scaffold command\u002FAPI before running\n   it. Treat package-manager create flows, documented remote initializer APIs,\n   framework CLIs, templates, and project-local generators as candidates. Do\n   not make any single stack special in the route logic.\n3. Prefer non-global, repeatable commands (`npm create`, `pnpm create`,\n   `npx`, package-manager `dlx`, `curl` to a documented initializer API, or a\n   project-local generator). Avoid installing global CLIs.\n4. If the generator is interactive and missing choices materially affect the\n   result, ask one focused question. Otherwise choose conservative defaults\n   from the user's request and record them.\n5. Self-author the scaffold only when no trustworthy generator exists, the\n   generator cannot satisfy the requested constraints, the requested skeleton is\n   intentionally smaller than the generator output, or a custom skeleton is\n   clearly easier to verify. Record the reason.\n6. After generation, normalize scripts and run baseline verification. Do not\n   claim the scaffold works without evidence.\n\n## New Spec Creation\n\nFor `lite-spec`, `full-spec`, `greenfield-spec`, `prototype`, and `import-spec`:\n\n1. Ensure the current branch is appropriate using `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fbranch-management.md`.\n2. Validate or ask for a kebab-case spec name only if missing.\n3. Validate or ask for the goal only if missing.\n4. Resolve the spec directory from `--specs-dir` or the default specs dir.\n5. Create the spec directory, update `$defaultDir\u002F.current-spec`, and ensure `.gitignore` covers `$defaultDir\u002F.current-spec`, `$defaultDir\u002F.current-epic`, and `**\u002F.progress.md`.\n   - If writing the marker under the default specs dir, write only the bare spec name, e.g. `greet-helper`.\n   - If writing a non-default spec root, write the relative path, e.g. `packages\u002Fapi\u002Fspecs\u002Fauth-flow`.\n   - Do not write `specs\u002F\u003Cname>` for default-root specs; that can be interpreted as a path by newer runtime resolvers.\n   - Do not write a project-root `.current-spec`; runtime state lives under the configured specs root.\n   - Preferred write pattern:\n     ```bash\n     mkdir -p \"$defaultDir\"\n     if [ \"$basePath\" = \"$defaultDir\u002F$name\" ]; then\n       printf '%s\\n' \"$name\" > \"$defaultDir\u002F.current-spec\"\n     else\n       printf '%s\\n' \"$basePath\" > \"$defaultDir\u002F.current-spec\"\n     fi\n     ```\n6. Compute compatibility policy:\n   ```bash\n   ROUTE_JSON=$(curdx-flow route --name \"$name\" --goal \"$goal\" --flags \"$ARGUMENTS\")\n   POLICY_JSON=$(printf '%s' \"$ROUTE_JSON\" | node -e 'let s=\"\";process.stdin.on(\"data\",c=>s+=c);process.stdin.on(\"end\",()=>process.stdout.write(JSON.stringify(JSON.parse(s).policy)))')\n   ```\n7. Initialize the spec state file. The file lives at `$basePath\u002F.curdx-state.json` — never at the project root or anywhere else. Create the parent directory first if needed, then write the following shape:\n   ```json\n   {\n     \"version\": 2,\n     \"source\": \"spec\",\n     \"name\": \"$name\",\n     \"basePath\": \"$basePath\",\n     \"identity\": { \"name\": \"$name\", \"basePath\": \"$basePath\", \"goal\": \"$goal\" },\n     \"phase\": \"research\",\n     \"taskIndex\": 0,\n     \"totalTasks\": 0,\n     \"taskIteration\": 1,\n     \"maxTaskIterations\": \"\u003CPOLICY_JSON.maxTaskIterations or 5>\",\n     \"globalIteration\": 1,\n     \"maxGlobalIterations\": \"\u003CPOLICY_JSON.maxGlobalIterations or 30>\",\n     \"commitSpec\": true,\n     \"quickMode\": false,\n     \"executionDriver\": \"goal\",\n     \"autoPolicy\": \"\u003CPOLICY_JSON object>\",\n     \"route\": \"\u003CROUTE_JSON compact object>\",\n     \"intent\": \"\u003CROUTE_JSON.intent object>\",\n     \"completed\": false\n   }\n   ```\n   All later mutations to this file (verification blocks, completion markers, task index updates) must go through `curdx-flow verify run` or `curdx-flow state merge \"$basePath\u002F.curdx-state.json\" '\u003Cpatch>'`. Do not hand-edit `.curdx-state.json` with Write\u002FEdit after creation — the CLI maintains schema invariants such as `verificationBlocks.execution.srcMtime` (epoch ms) that hand-written JSON routinely omits.\n8. Create `.progress.md` with the original goal and the selected behavior route.\n\nIf policy computation fails, use this fallback cap:\n\n```json\n{ \"maxGlobalIterations\": 30 }\n```\n\nFor `lite-spec`, keep interviews minimal and generate only 1-3 value-slice tasks.\nFor `full-spec`, continue with research and the normal phase flow.\nFor `greenfield-spec`, include product context and constitution before design,\nthen require a walking-skeleton task before feature slices.\nFor `prototype`, keep tasks bounded to the success criterion.\nFor `import-spec`, keep traceability to the imported source artifact in every\nphase artifact.\n\nWhen a spec state is created and router output includes `topology`, `intent`, or `recommendedCapabilities`, store compact copies in `.curdx-state.json` as `projectTopology`, `intent`, and `recommendedCapabilities`. If last-mile output is available, store a compact `lastMile` object with `phase`, `problemType`, `problemTypes`, `capabilityPlan`, `evidenceRequired`, and `lastDecisionAt`.\n\n## Quick Artifact Contract\n\nWhen `--quick` causes this skill to generate phase artifacts inline instead of delegating through each phase command:\n\n\u003Cmandatory>\nThe quick path does not lift the runtime-CLI contract for `.curdx-state.json`. Even in `--quick --mode fast`, do not Write\u002FEdit the state file beyond the initial schema in \"New Spec Creation\" step 7. Verification blocks must be produced by `curdx-flow verify run`, and completion\u002Fiteration mutations must use `curdx-flow state merge \"$basePath\u002F.curdx-state.json\" '\u003Cpatch>'`. Hand-written `verificationBlocks` invariably miss `srcMtime` and break `check-verification-blocks` \u002F `verify-blocks` invariants.\n\u003C\u002Fmandatory>\n\n- `tasks.md` must still use the task-planner format contract.\n- Start `tasks.md` with `## Source Coverage Audit`.\n- Every executable top-level task must be a checkbox list item, not a heading:\n\n```markdown\n- [ ] 1.1 Implement greet helper\n  - **Do**:\n    1. Edit `src\u002Fgreet.js`\n    2. Run `npm test`\n  - **Files**: `src\u002Fgreet.js`, `test\u002Fgreet.test.js`\n  - **Done when**: `greet(\" Ada \")` and empty-name fallback pass\n  - **Verify**: `npm test`\n  - **Commit**: `feat(greet): implement greeting helper`\n  - _Requirements: FR-1, AC-1_\n```\n\n- Do not create heading-only task sections such as `## T1`; runtime task parsing ignores them and `\u002Fcurdx-flow:status` will report `empty-tasks`.\n- If implementation is completed in the same quick run, run the final task's exact **Verify** command through the runtime recorder before marking completion:\n  ```bash\n  curdx-flow verify run --phase execution --command \"\u003Cexact Verify command>\" --spec \"$name\"\n  ```\n  This command actually executes the verification, records `.curdx-state.json::verificationBlocks.execution` with the command, exit code, timestamp, and source mtime, and returns the verification exit code. If the verification fails, do not set `completed: true`; fix the issue and rerun the recorder.\n- If the goal, requirements, or acceptance criteria require browser evidence, Playwright, or Chrome DevTools MCP, `--check`\u002Ffile-existence commands are not sufficient completion evidence. The quick run must first perform the real browser interaction, then record the shell verifier with `--description` containing the concrete browser proof: tool used, URL, action sequence, final DOM assertion, and console-error result. Do not mark completion when that proof is absent.\n- After recorded verification passes, mark the checkbox `[x]`, set `completed: true`, and leave `taskIndex` equal to the number of top-level checkbox tasks.\n\n## Skill Discovery\n\nOnly scan and invoke additional skills when the route is `lite-spec`, `full-spec`, `greenfield-spec`, `prototype`, or `import-spec`. Match skills by semantic relevance to the goal. Skip discovery for `direct-change` and `scaffold` unless the user explicitly asks to use a skill.\n\n## Output\n\nAlways start with a short routing summary:\n\n```text\nRoute: \u003Croute>\nReason: \u003Creason>\nNext: \u003CnextAction>\n```\n\nThen perform the next action. If the route is `blocked-ask-user`, ask exactly one focused question.\n",{"name":5,"description":7,"allowed-tools":48,"argument-hint":49,"disable-model-invocation":50},"Read Write Edit Bash Agent Skill AskUserQuestion","[name] [goal] [--fresh] [--quick] [--mode auto|fast|deep] [--task-granularity auto|coarse|standard|fine] [--review minimal|standard|strict] [--commit-spec] [--no-commit-spec] [--specs-dir \u003Cpath>]",true,"main","7357746802ae7a84cafa93b9dbffd138817b0290","plugins\u002Fcurdx-flow\u002Fskills\u002Fstart",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":62,"prompt":72,"zipAvailable":50},[63,66,69],{"tool":64,"command":65},"npx","npx skills add mugsun\u002Fcurdx-flow --skill start",{"tool":67,"command":68},"bunx","bunx skills add mugsun\u002Fcurdx-flow --skill start",{"tool":70,"command":71},"pnpm","pnpm dlx skills add mugsun\u002Fcurdx-flow --skill start","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Fstart\u002FSKILL.md",[],[75,84,103,116,128,138],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":82,"publishedAt":43},"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",[81],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[77,83],"fixture",{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":43},"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",[],[91,92,93,94,25,95,96,97,98,99,100,101,102],"verification","verification before completion","only","false","tasks","phase","evidence","fixes","tests","use","mock","state",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":110,"publishedAt":43},"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",[109],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[105,24,111,112,37,38,113,114,40,25,100,115],"true","feature","dependency","name","EPIC",{"skillNo":117,"name":95,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":122,"publishedAt":43},"01M71KDH7XFQJPKYZ0H9JDNSA5","Use when a spec has design.md and needs implementation tasks.","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Ftasks\u002FSKILL.md",[121],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[95,123,124,114,125,100,126,127,35,25,40,38,37,36,111],"implementation","spec","task","standard","design",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":43},"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",[134],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[130,40,136,111,100,25,137,114,38,124,37,26],"by name","active",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":43},"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",[144],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[140,111,100,25,40,102,146,137,147,38,41,148],"progress","update","index"]