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

Overview

The goal of I1 is to convert

{FEATURE_DIR}/requirements/*

and

{FEATURE_DIR}/design/*

into a directly executable implementation plan

{FEATURE_DIR}/implementation/plan.md

, which serves as the single source of truth (SSOT) for execution checklist and status (checkbox tasks + steps per task + minimal validation + commit points + audit information).

Announce at the start: "I am using the spec-implementation-plan skill to create an implementation plan (plan.md SSOT)."

When to Use / Not to Use

When to use
- You need to generate or update
```
{FEATURE_DIR}/implementation/plan.md
```
  (mandatory for I1).
- You are preparing to enter I2 execution but currently do not have a "checkable + executable" task list.
Do not use when
- ```
spec-context
```
  fails and you cannot obtain
```
FEATURE_DIR
```
  (must stop immediately).
- Insufficient input SSOT: Both
```
requirements/solution.md
```
  and
```
requirements/prd.md
```
  do not exist, and you cannot trace the scope/acceptance (must mark NEEDS CLARIFICATION in plan.md and block entry into I2).

Gatekeeping / Stop (Strictly Enforced)

REQUIRED SUB-SKILL: Execute
spec-context
first and echo
FEATURE_DIR=...
in the conversation.

powershell

$repoRoot = (git rev-parse --show-toplevel)
. (Join-Path $repoRoot "skills\spec-context\spec-common.ps1")
$context = Get-SpecContext
$FEATURE_DIR = $context.FEATURE_DIR
Write-Host "FEATURE_DIR=$FEATURE_DIR"

Stop immediately if any of the following is true:

```
FEATURE_DIR
```
is not obtained
Branch/directory is uncertain (you find yourself wanting to "guess the
```
.aisdlc/specs/...
```
path")
Both
```
requirements/solution.md
```
and
```
requirements/prd.md
```
are missing, making it impossible to trace the objective/scope/acceptance criteria
Any critical uncertainty cannot be evidenced in the input (must be written into
```
plan.md/## NEEDS CLARIFICATION
```
and clearly state "block entry into I2")

Input / Output (File Storage Convention)

Read (Progressive Disclosure, Minimal Necessary)
- Project-level (must read its index or necessary fragments):
```
project/memory/*
```
  ,
```
project/contracts/
```
  ,
```
project/adr/
```
- Spec-level (read minimally as needed): Either
```
{FEATURE_DIR}/requirements/solution.md
```
  or
```
{FEATURE_DIR}/requirements/prd.md
```
  (at least one)
- Spec-level (if exists and relevant):
```
{FEATURE_DIR}/design/design.md
```
  ,
```
{FEATURE_DIR}/design/research.md
```
Write (Only)
- ```
{FEATURE_DIR}/implementation/plan.md
```

Small Task Granularity (Reuse writing-plans)

Each step is an action (2–5 minutes) and should be written in

plan.md

to the extent that "anyone can follow and execute it":

"Write failing test" (if applicable) - one step
"Run to ensure failure" - one step
"Implement minimal code to make the test pass" - one step
"Run verification to ensure pass" - one step
"Commit" (frequent commits) - one step

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

plan.md

Header (Mandatory)

Must start with this header (template see

./plan-template.md

markdown

# [Requirement Name] Implementation Plan (SSOT)

> **Required Skill:** `spec-implementation-execute` (execute this plan in batches)
> **Context Gatekeeping:** Must first use `spec-context` to locate `{FEATURE_DIR}`, stop if failed

**Objective:** [One-sentence description of what to deliver]
**Scope:** In / Out
**Architecture:** [2–3 sentences of method description + key constraints]
**Acceptance Criteria:** [Reference AC/acceptance points from requirements/solution.md or requirements/prd.md]

---

Plan Body (Mandatory)

TL;DR: One-sentence summary of the plan's objective and scope
Scope and Boundaries: In/Out (aligned with requirements and design)
Milestones and Rhythm: Phase split, time estimation, deliverable list
Dependencies and Resources: Dependencies on external systems/teams/permissions/environments/data
Risks and Verification: Risk list, verification methods, Owner
Acceptance Criteria: Key AC and acceptors corresponding to PRD/solution
NEEDS CLARIFICATION (Mandatory): Unified list of unresolved uncertainties (cannot enter I2 until resolved)

Task Structure (Reuse writing-plans, add SSOT/Audit/Gatekeeping)

The

plan.md

must include a checkable task list as the only source of truth for execution and status (

- [ ]/- [x]

Each task must include:

Exact file path (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):

markdown

## Task List (SSOT)

### Task T1: [Task Title]

- [ ] **Status**: Not Started / In Progress / Completed / Blocked (must provide evidence path if blocked)

**Files:**
- Create: `exact/path/to/new.file`
- Modify: `exact/path/to/existing.file` (optional: exact paragraph/function)
- Test: `tests/exact/path/to/test.file` (if applicable)

**Acceptance Points:**
- [Verifiable condition 1]
- [Verifiable condition 2]

**Step 1: Write failing test (if applicable)**
- Modification point: `tests/...`
- Run: `[exact command]`
- Expected: FAIL (write the key failure signal expected)

**Step 2: Write minimal implementation**
- Modification point: `path/to/file`

**Step 3: Run verification**
- Run: `[exact command]`
- Expected: PASS (write the key pass signal expected)

**Step 4: Commit (commit frequently; commit message must be in Chinese)**
- Commit message: `[One-sentence explanation in Chinese]`
- Audit Information: `commit=<TBD>`、`pr=<TBD>`、`changed_files=<TBD>`

Command Writing Convention: Default to PowerShell; use
;
to separate multiple commands on the same line (do not use
&&
).

I1-DoD (Gatekeeping: No Exceptions)

The plan scope is consistent and traceable with

{FEATURE_DIR}/requirements/*

and

{FEATURE_DIR}/design/*

Milestones are clear and acceptable (each has a corresponding deliverable or verifiable standard)
Dependencies and risks are listed, with minimal verification/mitigation actions (including Owner)
Key acceptance criteria are traceable (at least reference
```
requirements/prd.md
```
or
```
requirements/solution.md
```
)
The
```
plan.md
```
contains a "Task List (SSOT)", and each task includes: file path, acceptance points, minimal verification method, commit points and audit information
Any unresolved uncertainties are listed in
```
NEEDS CLARIFICATION
```
, and cannot enter I2 until resolved

Keep in Mind (Quick Reference for High-Frequency Rules)

Always use
```
spec-context
```
first to get
```
FEATURE_DIR=...
```
, stop if failed
Always write exact paths, exact commands and expected signals
Do not treat uncertainties as known; uniformly list them in
```
NEEDS CLARIFICATION
```
and block I2
DRY, YAGNI, TDD, frequent commits (the commit rhythm should also be reflected in the plan)

Execution Handover (After Writing plan.md)

After saving the plan, provide execution options (reuse the handover wording of

writing-plans

, but align the output location and execution skill with the Spec implementation phase):

"The plan has been completed and saved to
{FEATURE_DIR}/implementation/plan.md
. Two execution methods:"

1. Subagent-Driven (This Session) - Stay in this session, use sub-agents to execute tasks, and conduct checkpoint reviews and rewrites between tasks

Required Sub-Skill: Use
```
subagent-driven-development
```
Execution Method:
- Take
```
{FEATURE_DIR}/implementation/plan.md
```
  as the only SSOT
- Execute in batches (default first 3 incomplete tasks), report after each batch is completed and wait for feedback
- Rewrite during execution: Check off tasks (
```
- [ ]
```
  →
```
- [x]
```
  ) + fill in
```
commit/pr/changed_files
```
  + key verification results

2. Parallel Session (New Session) - Open a new session to execute in batches, suitable for more execution-oriented, end-to-end advancement

Required Sub-Skill: Prefer to use
```
spec-implementation-execute
```
(I2 execution skill in the implementation phase SOP; execute in batches and rewrite
```
plan.md
```
)

Which one to choose?

If there are critical defects/uncertainties in the plan: Stay in I1 first, complete the evidence path and minimal verification actions for
NEEDS CLARIFICATION
, then enter I2 (do not guess and advance).

spec-implementation-plan

NPX Install

Tags

SKILL.md Content (Chinese)