SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsusing-aisdlc

using-aisdlc

General & other

View repository

Updated 10-16 06:45

About this skill

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

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 (the Router) has the authority to decide which skill to use next; all other skills are workers, responsible only for this stage's gate + writing artifacts to disk + DoD.

At the start you must announce:"I am using the using-aisdlc 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 rules index (read on demand)

  • Requirements chain (R0-R4)：router/routing-requirements.md
  • Design chain (D0-D2)：router/routing-design.md（Must-read during the R→I transition, see D0 mandatory gate)
  • Implementation chain (I1-I2 + Finish)：router/routing-implementation.md
  • Verification chain (V1-V4)：router/routing-verification.md

Path convention: paths within this skill all userelative to this skill's directorynotation.

Router / Worker responsibility boundaries (hard constraints)

  • Router（using-aisdlc）: the sole 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 route to the next skill within the skill.

The Router's hard gates (must be followed)

Whenever a 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: currently 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: PowerShell by default; for multiple commands on the same line use ; as the separator (do not use &&）。

Auto-Advance (automatic advance by default)

  • Default: when a "Hard stop" is not triggered, the Router should automatically advance and immediately execute the next worker skill.
  • Prohibited: after outputting the next step, ending the reply with "continue or not / do you want to execute" (unless a hard stop is triggered).
  • When minimal input is needed: first collect the minimal input, and once collected, execute immediately.

Hard stop (must stop and hand over to the user)

If any one is met, it is a hard stop (the Router must stop and output the blocking reason + the minimal input/decision point required):

  • Critical external input is needed and cannot be inferred by default (e.g. R4 cannot find DEMO_PROJECT_ROOT）
  • There is a major decision branch and choosing wrong is costly (e.g. external contract/permission/caliber changes, data migration/rollback, introducing new infrastructure or cross-team dependencies)
  • Estimated implementation effort exceeds 1 workday (just give the reason based on impact scope and uncertainty)
  • Involves irreversible/high-risk operations (for example: abandoning a Spec Pack, which must go through a dedicated process)

Soft checkpoint (Soft checkpoint: does not interrupt, but must indicate "reviewable point")

When generating/updating the following authoritative input-type artifacts, the Router should continue advancing and at the same time provide the "minimum review points for this round" in the output:

  • requirements/solution.md(especially #impact-analysis）
  • requirements/prd.md
  • requirements/prototype.md
  • design/design.md
  • implementation/plan.md

Candidate next steps (output only during a hard interrupt)

When the Router stops due to a hard interrupt, 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 (already produced {FEATURE_DIR}/implementation/plan.md), the candidate list by default may only include spec-execute(and after completion, finishing-development). Must not list R2/R3/R4 or I1 as "subsequent optional steps".
  • For clarification gaps, output "blocking reason + the minimum required input/write-back point (plan.md)"; once collected, directly enter I2.

Router output protocol (workers must comply)

After any worker skill completes, the ending must output ROUTER_SUMMARY(recommended YAML form, fixed fields, avoid free text), for Router automatic 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 ROUTER_SUMMARY(if any): if blocked=true → stop according to the hard interrupt rules in this document 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,forbidden to enter I1 directly without D0：
    • 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"
    • Forbidden: skipping D0 on the grounds that "the user wants the shortest closed loop/run-through-and-use"; the D0 determination must be executed, and only its "skip design" conclusion is the basis for legally entering I1.
  5. Routing based on user intent + SSOT file existence (read as needed)：
    • Requirements 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
  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 to "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 branching (whether to add PRD/prototype/whether to skip design) are all pushed down to the routing file; among them the R→I transition must pass through the D0 mandatory gate(read routing-design.md and execute the D0 determination), and must not be omitted.

Common errors (Red Flags)

  • During the R→I transition, entering I1 directly without D0：solution.md 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/works out of the box": The D0 determination must be executed; only D0's "skip design" conclusion is a legitimate basis for entering I1.