SuperAPI AI Directory

using-aidlc

General & other

View repository

Updated 10-16 08:46

About this skill

using-aidlc (the sole router for the Spec Pack process / Router)

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-context extended 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.md in the YAML Frontmatter of mode: auto
    • the context already contains the AUTO_MODE=true marker (injected by the calling SubAgent)
  • No Frontmatter or mode missing/non- auto: treated as AUTO_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-context The script automatically reads the {REPO_ROOT}/.aidlc/config.yaml field in auto_commit and outputs AUTO_COMMIT=true/false
  • Default value:true(when the configuration file does not exist or the field is missing)
  • Behavior difference:
    • AUTO_COMMIT=true: the git add + git commit step in all worker skills executes normally
    • AUTO_COMMIT=false: the automatic commit step in all worker skills is skipped, and instead outputs "list of changed files, please commit manually"

Note:auto_commit is 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.md
  • requirements/prototype.md
  • design/design.md
  • implementation/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 include spec-execute(and after completion finishing-development). It must not list R2/R3/R4 or I1 as "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):

  1. Entry preflight (Preflight): If the branch is non-compliant or raw.md is missing → enter R0 spec-init(for details see routing-requirements.md)。
  2. Gate: If the next step will read/write {FEATURE_DIR}/... or write demo → first execute spec-context to obtain context, echo FEATURE_DIR=...,if it fails, enter spec-init。
  3. Read the previous step's ROUTER_SUMMARY(if any): If blocked=true → stop according to the hard interrupt rules in this file and provide candidate next steps.
  4. D0 mandatory gate (R→I transition): When solution.md already 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.
  5. 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 read router/routing-collaboration.md(task branch,TASK_PACK_DIR, scripts and Phase B/C gate), together with routing-implementation.md as determination inputs.
  6. 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.md and execute the D0 determination), which must not be omitted.

Common errors (Red Flags)

  • Entering I1 directly without D0 during the R→I transition:solution.md When it already exists and the intent points to I1, you must first read routing-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.