What you are currently using
This is a "navigation + gate" type skill: in the Spec Pack (branch name {num}-{short-name}) process,only this skill (Router) has the authority to decide which skill to use next; all other skills are workers, responsible only for this stage's gate + writing to disk + DoD.
At the start you must announce:"I am using the using-aidlc skill to navigate the Spec Pack process, and am executing spec-context to obtain context."
Progressive disclosure (read on demand)
The mechanism you requested is "read the Router first, then read the details on demand", therefore:
- By default, read only this file
SKILL.md - Only when the Router needs to determine a certain chain should you then read that chain's routing details (R/D/I/V)
Routing rule index (read on demand)
- Requirement chain (R0–R4):
router/routing-requirements.md - Design chain (D0–D2):
router/routing-design.md(Required reading during the R→I transition, see the D0 mandatory gate) - Implementation chain (I1–I2 + Finish):
router/routing-implementation.md - Verification chain (V1–V4):
router/routing-verification.md - Multi-person collaboration / Task Pack (supplementary):
router/routing-collaboration.md(task branch,spec-contextextended fields, Phase B/C script entry points)
Path convention: paths inside this skill all use therelative to this skill directoryform.
Router / Worker responsibility boundary (hard constraint)
- Router(using-aidlc): the only one with the authority to decide "what to do next / whether to skip / which chain to take".
- Worker skills(e.g.
spec-product-clarify、spec-plan, etc.): responsible only for this stage's gate + writing artifacts to disk + DoD self-check; must not autonomously branch to the next skill within the skill.
Router's hard gates (must be followed)
As long as the task will read or write the following paths (or their subpaths), you must first execute spec-context to obtain context, and echo back FEATURE_DIR=...。If it fails, enter spec-init。
REQUIRED SUB-SKILL: executing spec-context to obtain context, and echo back in the conversation FEATURE_DIR=...(allowing (reuse))。
{FEATURE_DIR}/requirements/*{FEATURE_DIR}/design/*{FEATURE_DIR}/implementation/*{FEATURE_DIR}/verification/*
Command writing convention: defaults to PowerShell; for multiple commands on the same line use
;as the separator (do not use&&)。
AUTO_MODE detection (unattended mode)
After the Router obtains FEATURE_DIR and before performing routing determination, it should detect whether it is currently in automatic mode:
- Detection method (satisfying either one means
AUTO_MODE=true):{FEATURE_DIR}/requirements/raw.mdin the YAML Frontmatter ofmode: auto- the context already contains the
AUTO_MODE=truemarker (injected by the calling SubAgent)
- No Frontmatter or
modemissing/non-auto: treated asAUTO_MODE=false(interactive mode), all behavior is consistent with the original logic.
raw.md Full Frontmatter convention (all fields are optional, see comments for default values):
---
mode: auto # auto | interactive(默认 interactive)
skip_design: true # D0 预设:跳过设计阶段(默认 false)
skip_stages: # 声明式跳过阶段列表(默认空)
- R2
- R3
- R4
source: auto-app # 来源标识(仅用于追溯,不影响路由)
iteration: 1 # 迭代编号(仅用于追溯,不影响路由)
---
AUTO_COMMIT detection (automatic commit switch)
After the Router obtains FEATURE_DIR , it should read from the spec-context output the AUTO_COMMIT value:
- Source:
spec-contextThe script automatically reads the{REPO_ROOT}/.aidlc/config.yamlfield inauto_commitand outputsAUTO_COMMIT=true/false - Default value:
true(when the configuration file does not exist or the field is missing) - Behavior difference:
AUTO_COMMIT=true: thegit add+git commitstep in all worker skills executes normallyAUTO_COMMIT=false: the automatic commit step in all worker skills is skipped, and instead outputs "list of changed files, please commit manually"
Note:
auto_commitis aproject-level configuration(located in.aidlc/config.yaml), not a spec-level frontmatter field. It affects the commit behavior of all Spec Packs.
Auto-Advance (auto-advance by default)
- Default: when no "Hard stop" is triggered, the Router should automatically advance and immediately execute the next worker skill.
- Prohibited: end the reply with "should we continue/do you want to execute" after outputting the next step (unless a hard stop is triggered).
- When minimal input is needed: first collect the minimal input, and execute immediately once it is collected.
Hard stop (must stop and hand over to the user)
If any one is satisfied, it is a hard stop (the Router must stop and output the blocking reason + the required minimal input/decision point):
- Critical external input is needed and cannot be inferred by default (for example, R4 cannot find
DEMO_PROJECT_ROOT) - There is a major decision branch and choosing wrong is costly (for example: external contract/permission/caliber changes, data migration/rollback, introduction of new infrastructure or cross-team dependencies)
- The estimated implementation workload exceeds 1 working day (just give a reason based on impact scope and uncertainty)
- Involves irreversible/high-risk operations (for example: deprecating a Spec Pack must go through a dedicated process)
Soft checkpoint (does not interrupt, but must indicate a "reviewable point")
When generating/updating the following authoritative input artifacts, the Router should continue advancing while giving the "minimal review point for this round" in the output:
requirements/solution.md(especially#impact-analysis)requirements/prd.mdrequirements/prototype.mddesign/design.mdimplementation/plan.md
AUTO_MODE behavior: when AUTO_MODE=true , the soft checkpoint's "indicate reviewable point" output is skipped, and the Router directly auto-advances to the next step without any pause or review prompt. Hard stop rules are unaffected—even under AUTO_MODE, a hard stop must still stop.
Candidate next steps (output only on hard stop)
When the Router stops due to a hard stop, it must append "possible next steps (candidates)" and list 2–5 skill names in recommended order.
Constraints (avoid misleading):
- Once the implementation chain has been entered (
{FEATURE_DIR}/implementation/plan.mdhas been produced), the candidate list by default may only includespec-execute(and after completionfinishing-development). It must not listR2/R3/R4orI1as "subsequent optional steps". - For clarification gaps, output "blocking reason + required minimal input/write-back point (plan.md)", and once collected, directly enter I2.
Router output protocol (workers must comply)
After any worker skill is completed, the ending must output ROUTER_SUMMARY(YAML form is recommended, with fixed fields, to avoid free text), for automatic Router routing:
ROUTER_SUMMARY:
stage: CTX | R1 | R2 | R3 | R4 | D1 | D2 | I1 | I2 | V1 | V2 | V3 | V4 | Finish
artifacts:
- <path>
needs_human_review: true|false
blocked: true|false
block_reason: ""
notes: ""
Minimal routing algorithm (details not expanded)
The Router executes each round in the following order (read the corresponding routing file as needed for details):
- Entry preflight (Preflight): If the branch is non-compliant or
raw.mdis missing → enter R0spec-init(for details seerouting-requirements.md)。 - Gate: If the next step will read/write
{FEATURE_DIR}/...or write demo → first executespec-contextto obtain context, echoFEATURE_DIR=...,if it fails, enter spec-init。 - Read the previous step's
ROUTER_SUMMARY(if any): Ifblocked=true→ stop according to the hard interrupt rules in this file and provide candidate next steps. - D0 mandatory gate (R→I transition): When
solution.mdalready exists and the next-step intent points to I1,mustexecute the following steps,entering I1 directly without D0 is prohibited:- must read
routing-design.md - must execute the D0 determination
- decide based on the D0 result: enter D1/D2, or "skip design and enter I1"
- Prohibited: skipping D0 on the grounds of "the user wants the shortest closed loop/ready to run"; the D0 determination must be executed, and only its "skip design" conclusion is the legitimate basis for entering I1.
- must read
- Route based on user intent + SSOT file existence (read as needed):
- Requirement chain R: see
routing-requirements.md - Design chain D: see
routing-design.md - Implementation chain I: see
routing-implementation.md - Verification chain V: see
routing-verification.md - Collaboration supplement: When the intent enters I2(
spec-execute) or{FEATURE_DIR}/implementation/tasks/subdirectory already exists,should readrouter/routing-collaboration.md(task branch,TASK_PACK_DIR, scripts and Phase B/C gate), together withrouting-implementation.mdas determination inputs.
- Requirement chain R: see
- Auto-Advance: If no hard interrupt is hit, the Router must automatically advance and immediately execute the next-step worker.
Shortest closed loop (only as an entry hint)
When the user's intent is "run through the shortest development closed loop", the Router's default path is:
spec-init(如需) → spec-context → spec-product-clarify → spec-plan → spec-execute → finishing-development
Details and routing (whether to supplement PRD/prototype/whether to skip design) are all delegated to the routing file; among them, the R→I transition must pass through the mandatory D0 gate(read
routing-design.mdand execute the D0 determination), which must not be omitted.
Common errors (Red Flags)
- Entering I1 directly without D0 during the R→I transition:
solution.mdWhen it already exists and the intent points to I1, you must first readrouting-design.md, execute the D0 determination, and then route according to the result. - Skipping D0 on the grounds of "shortest closed loop/ready to run": The D0 determination must be executed; only D0's "skip design" conclusion is the legitimate basis for entering I1.