SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsspec-implementation-plan

spec-implementation-plan

Coding & development

View repository

Updated 10-16 09:35

About this skill

spec-implementation-plan (I1: implementation plan / plan.md SSOT)

Overview

The goal of I1 is to convert {FEATURE_DIR}/requirements/* and {FEATURE_DIR}/design/* intodirectly executableimplementation plan {FEATURE_DIR}/implementation/plan.md, and treat it as thesingle execution checklist and status SSOT(checkbox tasks + steps per task + minimal verification + commit points + audit information).

At the start, announce:"I am using the spec-implementation-plan skill to create the implementation plan (plan.md SSOT)."

When to use / when not to use

  • When to use
    • You need to produce or update {FEATURE_DIR}/implementation/plan.md(required for I1).
    • You are about to enter I2 execution, but there is currently no "checkable + executable" task list.
  • Do not use when
    • spec-context fails, and FEATURE_DIRcannot be obtained (in this case you must stop).
    • Input-side SSOT is insufficient:requirements/solution.md and requirements/prd.md both do not exist, and scope/acceptance cannot be traced (you must mark NEEDS CLARIFICATION in plan.md and block entry into I2).

Gates / stop (strictly enforced)

REQUIRED SUB-SKILL: first satisfy the spec-context gate and echo it in the conversation FEATURE_DIR=...(allowing (reuse)）。

Stop immediately (satisfying any one is sufficient):

  • Did not obtain FEATURE_DIR
  • Branch/directory is uncertain (you find yourself wanting to "guess the .aisdlc/specs/... path")
  • requirements/solution.md and requirements/prd.md are both missing, making the goal/scope/acceptance criteria untraceable
  • Any key uncertainty cannot be evidenced in the input (must be written into plan.md/## NEEDS CLARIFICATION, and explicitly state "block entry into I2")

Input / output (persistence conventions)

  • Read (progressive disclosure, minimum necessary)
    • Project level (must read its index or necessary fragments):project/memory/*、project/contracts/、project/adr/
    • Spec level (read the minimum as needed):{FEATURE_DIR}/requirements/solution.md or {FEATURE_DIR}/requirements/prd.md(at least one of them)
    • Impact analysis (mandatory, if solution.md exists): must read {FEATURE_DIR}/requirements/solution.md#impact-analysis, extract the list of affected modules and the invariants that must be observed, and use them as constraint input for I1 (if missing, stop and return to R1 to fill in)
    • Spec level (if it exists and is relevant):{FEATURE_DIR}/design/design.md、{FEATURE_DIR}/design/research.md
  • Write (only)
    • {FEATURE_DIR}/implementation/plan.md

Small-block task granularity (reuse writing-plans)

Each step is one action (2–5 minutes), and in plan.md write it so that "anyone can copy it and execute it":

  • "Write a failing test" (if applicable) - one step
  • "Run to ensure it fails" - one step
  • "Implement the minimum code to make the test pass" - one step
  • "Run verification to ensure it passes" - one step
  • "Commit" (commit frequently) - one step

Constraint: I1 only writes the plan, not code; but each task must declare itsminimal verification method(command + expected signal).

plan.md header (required)

Must begin with this header(Template see ./assets/plan-template.md）：

# [需求名] 实现计划（SSOT）

> **必需技能：** `spec-implementation-execute`（按批次执行本计划）
> **上下文门禁：** 必须先用 `spec-context` 定位 `{FEATURE_DIR}`，失败即停止

**目标：** [一句话描述要交付什么]
**范围：** In / Out
**架构：** [2–3 句方法说明 + 关键约束]
**验收口径：** [引用 requirements/solution.md 或 requirements/prd.md 的 AC/验收点]
**影响范围：** [引用 requirements/solution.md#impact-analysis 的受影响模块清单]
**需遵守的不变量：** [从 requirements/solution.md#impact-analysis 提取的关键 API/Data 契约不变量]

---

Plan body (required)

  • TL;DR: Summarize the plan's goals and scope in one sentence
  • Scope and boundaries: In/Out (align with requirements and design)
  • Impact scope and constraints (required)：
    • List of affected modules and impact types (reference requirements/solution.md#impact-analysis）
    • API/Data contract invariants that must be followed (list them one by one, annotate source module/anchor)
    • Cross-module impacts and coordination items (based on dependency graph/impact analysis)
  • Milestones and cadence: Phase breakdown, time estimates, deliverables list
  • Dependencies and resources: External systems/teams/permissions/environments/data dependencies
  • Risks and verification: Risk list, verification methods, Owner
  • Acceptance criteria: Key ACs corresponding to the PRD/solution and the acceptance person
  • NEEDS CLARIFICATION (required): Uniformly list unresolved uncertainties (must not enter I2 before they are resolved)

Task structure (reuse writing-plans, but add SSOT/audit/gates)

plan.md must containcheckabletask list, as the sole execution list and source of status (- [ ]/- [x]）。

Each task must include:

  • Exact file paths (create/modify/test)
  • Verifiable acceptance points (testable conditions)
  • Executable steps (command + expected output/signal)
  • Commit points and minimal audit information (commit/pr/changed_files）

Task template (example skeleton):

## 任务清单（SSOT）

### Task T1: [任务标题]

- [ ] **状态**：未开始 / 进行中 / 完成 / 阻塞（阻塞必须写明取证路径）

**文件：**
- 创建：`exact/path/to/new.file`
- 修改：`exact/path/to/existing.file`（可选：精确到段落/函数）
- 测试：`tests/exact/path/to/test.file`（如适用）

**验收点：**
- [可验证条件 1]
- [可验证条件 2]

**步骤 1：写失败测试（如适用）**
- 修改点：`tests/...`
- Run: `[精确命令]`
- Expected: FAIL（写出期望看到的关键失败信号）

**步骤 2：写最少实现**
- 修改点：`path/to/file`

**步骤 3：运行验证**
- Run: `[精确命令]`
- Expected: PASS（写出期望看到的关键通过信号）

**步骤 4：提交（频繁提交；commit message 必须中文）**
- Commit message: `[一句话说明 why（中文）]`
- 审计信息：`commit=<TBD>`、`pr=<TBD>`、`changed_files=<TBD>`

Command writing convention: default to PowerShell; for multiple commands on the same line use ; as separator (do not use &&）。

I1-DoD (gate: none may be missing)

  • Plan scope and {FEATURE_DIR}/requirements/*、{FEATURE_DIR}/design/* are consistent and traceable
  • Milestones are clear and acceptable (each has a corresponding artifact or verifiable standard)
  • Dependencies and risks are listed, with minimal verification/mitigation actions (including Owner)
  • Key acceptance criteria are traceable (reference at least requirements/prd.md or requirements/solution.md）
  • Impact scope and constraints have been injected：plan.md contains an "Impact scope and constraints" section; affected modules and invariants to be followed have been extracted from requirements/solution.md#impact-analysis and listed one by one
  • plan.md contains a "Task list (SSOT)", and each task includes: file paths, acceptance points, minimal verification method, commit points, and audit information
  • Any uncertain item goes into NEEDS CLARIFICATION, andmust not enter I2 before it is resolved

Keep in mind (quick reference for high-frequency rules)

  • Always first spec-context get FEATURE_DIR=..., stop on failure
  • Always writeexact paths、exact commandsandexpected signals
  • Do not write uncertainty as known; uniformly put it into NEEDS CLARIFICATION and block I2
  • DRY, YAGNI, TDD, frequent commits (the plan must also reflect commit cadence)

Execution handoff (after writing plan.md)

After saving the plan, this skill no longer decides "next step/execution method". Uniform approach:

  • Announce:{FEATURE_DIR}/implementation/plan.md has been written to disk, and is the sole SSOT on the implementation side
  • Prompt:immediately call using-aisdlc Route the next step (usually route to I2:spec-implementation-execute, then to Finish:finishing-development）
  • If the user explicitly requests "use subagent-driven-development for parallel execution in this session", you should also firstcall using-aisdlc clarify the routing conclusion before starting execution (to avoid having a second routing source)

After completion, output and automatic routing (must be executed)

plan.md After being written to disk,mustcomplete the following actions (in order, none may be omitted):

  1. Output ROUTER_SUMMARY(in YAML form, for Router decision-making):
ROUTER_SUMMARY:
  stage: I1
  artifacts:
    - "{FEATURE_DIR}/implementation/plan.md"
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "软检查点：plan.md 建议评审；如不触发硬中断 Router 可继续自动推进"

  1. Immediately execute using-aisdlc: pass the above ROUTER_SUMMARY as routing input to using-aisdlc, let the Router determine the next step andautomatically advance(no need to wait for the user to say "continue").

    • If the Router determines that automatic continuation is possible: continue executing the next worker skill (such as I2, Finish, etc.) within the same conversation turn
    • If the Router triggers a hard interrupt: stop and output the blocking reason, the required input, and candidate next steps

  2. Conversation output: before calling using-aisdlc, you may briefly state "the artifacts for this stage have been written to disk, and using-aisdlc is being called to route the next step."