spec-implementation-execute (I2: Execution / plan.md SSOT)

Overview

The goal of I2 is to execute the tasks in

{FEATURE_DIR}/implementation/plan.md

in batches, and write back only the execution status and minimal audit information to

plan.md

(as the sole SSOT for execution checklist and status).

This skill is the Spec implementation phase version of

skills/executing-plans/SKILL.md

: it heavily reuses its "five-step execution + batch checkpoint + stop on block" framework, but replaces the semantics of "plan file" with the hard constraints of the implementation phase SOP (see

design/aisdlc_spec_implementation.md

```
plan.md
```
is the only source of execution checklist and status (checkbox + audit information + validation result summary)
By default, execute the first 3 uncompleted tasks per batch
Any
```
NEEDS CLARIFICATION
```
/ critical plan defect / block: stop and report immediately (no speculative advancement allowed)
If decisions/contract changes arise during execution: draft only within
{FEATURE_DIR}
, and append a Merge-back Todo List to
```
plan.md
```
(direct updates to
```
project/*
```
are prohibited in this phase)

Announce at start: "I am using the spec-implementation-execute skill to execute in batches according to plan.md and write back to SSOT."

When to Use / Not to Use

Use Scenarios
- ```
{FEATURE_DIR}/implementation/plan.md
```
  already exists (I1 is completed), and now enter I2 to implement tasks according to the plan.
- You need to strictly perform "batch checkpoint reporting" during execution, and write back status/audit information to
```
plan.md
```
  .
Do Not Use
- ```
spec-context
```
  fails and
```
FEATURE_DIR
```
  cannot be obtained (stop immediately in this case).
- ```
plan.md
```
  does not exist, or lacks an executable task list (return to I1:
```
spec-implementation-plan
```
  in this case).
- Unresolved
```
NEEDS CLARIFICATION
```
  exists in
```
plan.md
```
  , which will block execution (stop and propose clarification/plan revision first in this case).

Gatekeeping / Stopping (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 met):

```
FEATURE_DIR
```
is not obtained
Current branch is
```
main/master
```
(or you have not obtained explicit user consent to implement on the main branch)
```
{FEATURE_DIR}/implementation/plan.md
```
does not exist or is unreadable
Unresolved
```
NEEDS CLARIFICATION
```
exists in
```
plan.md
```
and it will block further execution
Critical plan defects exist: missing executable commands/missing minimal validation/unclear scope/unknown dependencies, making safe execution impossible
Blocks encountered during execution: missing dependencies/permissions/environments/data, repeated test failures, unclear instructions

Seek clarification instead of guessing.

Input / Output (Disk Storage Convention)

Reading (Progressive Disclosure, Minimal Necessary)
- ```
{FEATURE_DIR}/implementation/plan.md
```
  (required; SSOT)
- ```
{FEATURE_DIR}/requirements/*
```
  ,
```
{FEATURE_DIR}/design/*
```
  referenced in
```
plan.md
```
  (read on demand, do not expand all)
- Project-level indexes (read-only, on demand):
```
project/memory/*
```
  ,
```
project/contracts/
```
  ,
```
project/adr/
```
Writing (Only Status Source)
- Write only status/audit information back to
```
{FEATURE_DIR}/implementation/plan.md
```
  : check off tasks, fill in
```
commit/pr/changed_files
```
  , record key validation result summaries and block evidence paths
Code and Configuration Changes
- Implement according to the paths specified in each task of
```
plan.md
```
  (create/modify/test)
Spec Decision/Contract Drafts (If Generated During Execution)
- ADR drafts: prefer writing to the "Decisions/Trade-offs" section of
```
{FEATURE_DIR}/design/design.md
```
  ; add
```
{FEATURE_DIR}/design/adr/*.md
```
  if necessary
- Contract drafts: write to
```
{FEATURE_DIR}/design/contracts/
```
- Synchronization requirement: append/update the "Merge-back Todo List" in
```
plan.md
```
  (only record, do not directly modify
```
project/*
```
  in I2)

Command writing convention: PowerShell by default; use
;
to separate multiple commands on the same line (do not use
&&
).

Process (Reusing the Five-Step Framework of executing-plans)

Step 1: Load and Review Plan (Review)

Open and read
```
{FEATURE_DIR}/implementation/plan.md
```
Strictly review—identify any issues or concerns that will block execution, such as:
- Tasks do not specify "which files to modify/which commands to run/what signals to expect"
- Missing minimal validation methods or unexecutable validation
- Task scope creep (inconsistent with the scope/milestones of plan.md)
- Unmet dependencies/permissions/environments
- Unresolved
```
NEEDS CLARIFICATION
```
If there are critical concerns: stop and report before starting (clearly state the problem, provide evidence paths; return to I1 to revise plan.md if necessary)
If no concerns: Create TodoWrite and proceed to batch execution

Step 2: Execute Batch (Batch execute)

Default: First 3 uncompleted tasks (adjustable based on risks and dependencies, but must explain the reason).

For each task:

Mark as in_progress
Strictly execute according to task steps (do not skip steps; do not replace commands; do not secretly modify acceptance criteria)
Run minimal validation as specified in the task, and record key outputs/signals (criteria for PASS/FAIL)
Commit frequently (if the plan requires finer-grained commit points, follow the plan first)
- Commit message must be in Chinese
Write back to
```
plan.md
```
(only status source):
- ```
- [ ]
```
  →
```
- [x]
```
- Fill in
```
commit/pr/changed_files
```
- Record the key validation result summary of the task (including commands and key signals)
- If blocked: clearly state "what is missing, how to supplement it, who to ask/where to obtain evidence", and stop proceeding to the next task
Mark as completed (or blocked)

Step 3: Batch Checkpoint Report (Report checkpoint)

Report must be submitted when the batch is completed:

List of completed tasks (corresponding Task IDs)
Validation result summary (key commands + key outputs/signals)
Location and audit information written back to
```
plan.md
```
(commit/pr/changed_files)
Overview of uncompleted tasks
List of blocked items (if any)

Then say: "Ready for feedback." and wait for feedback before proceeding to the next batch.

Step 4: Continue / Return to Review (Continue / Re-review)

Based on feedback:

If the plan is updated or new critical concerns arise: return to Step 1 for re-review
Otherwise: Execute the next batch and repeat Steps 2–3 until the task list is processed

Step 5: Complete Development (Finish)

When all planned tasks in

plan.md

are completed and minimal validation passes:

Announce: "I am using the finishing-development skill to perform development finalization confirmation (validation only, ensuring all tests/checks pass)."
Required sub-skill: Use
```
finishing-development
```
Product requirement: Ensure the audit information in
```
plan.md
```
is fully traceable (at least includes
```
commit
```
and key validation result summaries; fill in
```
pr
```
if there is a PR)

When to Stop and Seek Help (Stop on block)

Stop execution immediately:

Blocks encountered in the batch (missing dependencies/permissions/environments/data)
Repeated test or validation failures (cannot locate or fix with current evidence)
Unclear instructions or acceptance criteria
Critical defects found in
```
plan.md
```
(cannot continue safe execution)
New/unresolved
```
NEEDS CLARIFICATION
```
that affects correctness or scope

Seek clarification instead of guessing.

When to Return to Earlier Steps

Return to Review (Step 1) when:

Collaborators updated
```
plan.md
```
based on your feedback
You need to adjust task order/splitting to continue (must clarify in
```
plan.md
```
first before execution)
The core solution needs to be reconsidered (stop first, then revise the plan/supplement evidence)

Key Reminders

Always execute
```
spec-context
```
first to obtain
```
FEATURE_DIR=...
```
; stop if it fails
```
plan.md
```
is the only SSOT for execution checklist and status: do not create alternative status sources
Strictly execute according to
```
plan.md
```
steps; do not skip validation
By default, execute the first 3 uncompleted tasks per batch; only report and wait between batches
Stop immediately when encountering blocks/clarification items; do not advance speculatively
ADRs/contracts generated during execution: only draft within
```
{FEATURE_DIR}
```
, and record Merge-back todos in
```
plan.md
```
(do not directly modify
```
project/*
```
in I2)

Integration

Upstream / Downstream Skills:

spec-implementation-plan

- Generate

{FEATURE_DIR}/implementation/plan.md

(SSOT)

```
finishing-development
```
- Perform development finalization confirmation after all tasks are completed

spec-implementation-execute

NPX Install

Tags

SKILL.md Content (Chinese)