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

Overview

The goal of I2 is to execute tasks in
{FEATURE_DIR}/implementation/plan.md
in batches, and only write back execution status and minimal audit information to
plan.md
(as the only execution list and status SSOT).

This skill is the Spec implementation phase version of

skills/executing-plans/SKILL.md

: heavily reuse its "five-step execution + batch checkpoint + stop on block" framework, but replace 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 list and status (checkbox + audit information + verification result summary)
By default, execute the first 3 unfinished tasks per batch
Any
```
NEEDS CLARIFICATION
```
/ critical plan defect / block: stop and report immediately (no guesswork allowed to proceed)
If decision/contract changes occur during execution: draft only within
{FEATURE_DIR}
, and append a Merge-back to-do list to
```
plan.md
```
(direct update of
```
project/*
```
is prohibited in this phase)

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

When to use / not to use

Use case
- ```
{FEATURE_DIR}/implementation/plan.md
```
  already exists (I1 is completed), now enter I2 to implement according to tasks.
- You need to strictly perform "batch checkpoint reporting" during execution, and write back status/audit information to
```
plan.md
```
  .
Do not use
- ```
spec-context
```
  failed,
```
FEATURE_DIR
```
  cannot be obtained (must stop at this time).
- ```
plan.md
```
  does not exist, or lacks an executable task list (return to I1:
```
spec-plan
```
  at this time).
- The
```
NEEDS CLARIFICATION
```
  in
```
plan.md
```
  has not been eliminated, or there are critical defects that prevent starting (must stop first and request clarification/revise the plan).

Entrance Control / Stop Rules (strictly enforced)

REQUIRED SUB-SKILL: You are executing
spec-context
to get context, and echo
FEATURE_DIR=...
in the conversation (allow
(reuse)
).

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 consent from the user to implement on the main branch)
```
{FEATURE_DIR}/implementation/plan.md
```
does not exist or is unreadable
There is unresolved
```
NEEDS CLARIFICATION
```
in
```
plan.md
```
that will block further execution
The plan has critical defects: missing executable commands / missing minimal verification / unclear scope / unknown dependencies, making it impossible to start safely
Block encountered during execution: missing dependencies/permissions/environment/data, repeated test failures, incomprehensible instructions

Seek clarification instead of guessing.

Input / Output (Persistence Convention)

Read (progressive disclosure, minimum necessary)
- ```
{FEATURE_DIR}/implementation/plan.md
```
  (required; SSOT)
- ```
{FEATURE_DIR}/requirements/*
```
  ,
```
{FEATURE_DIR}/design/*
```
  referenced by
```
plan.md
```
  (read on demand, do not expand all)
- ```
{FEATURE_DIR}/requirements/solution.md#impact-analysis
```
  (check back on demand: list of affected modules, invariants to comply with, related ADR, cross-module impact)
- Project-level index (read-only, on demand):
```
project/memory/*
```
  ,
```
project/contracts/
```
  ,
```
project/adr/
```
Write (only status source)
- Only write status/audit information back to
```
{FEATURE_DIR}/implementation/plan.md
```
  : check tasks, fill in
```
commit/pr/changed_files
```
  , record key verification result summary and block evidence path
Code and configuration changes
- Implement according to the path declared for each task in
```
plan.md
```
  (create/modify/test)
Spec internal decision/contract draft (if generated during execution)
- ADR draft: prefer to write to the "Decision/Trade-off" section of
```
{FEATURE_DIR}/design/design.md
```
  ; add
```
{FEATURE_DIR}/design/adr/*.md
```
  if necessary
- Contract draft: write to
```
{FEATURE_DIR}/design/contracts/
```
- Synchronization requirement: append/update "Merge-back to-do list" in
```
plan.md
```
  (only record, do not directly modify
```
project/*
```
  in I2)

Command writing convention: default for PowerShell; separate multiple commands in the same line with
;
(do not use
&&
).

Process (reuse the 5-step framework of executing-plans)

Step 1: Load and review the plan (Review)

Open and read
```
{FEATURE_DIR}/implementation/plan.md
```
Strictly review - identify any problems or doubts that will block execution, such as:
- The task does not clearly state "which files to modify/what commands to run/what signals to expect"
- Missing minimal verification method or verification is not executable
- Task is out of bounds (inconsistent with the scope/milestone of plan.md)
- Dependencies/permissions/environment are not met
- ```
NEEDS CLARIFICATION
```
  is not resolved
If there are critical doubts: stop and report before starting (clarify the problem, provide the evidence path; return to I1 to revise plan.md if necessary)
If there are no doubts: enter batch execution

Step 2: Execute batches (Batch execute)

Default: the first 3 unfinished tasks (can be adjusted according to risk and dependencies, but the reason must be explained).

For each task:

Mark as in_progress
Execute strictly according to task steps (do not skip steps; do not replace commands; do not secretly change acceptance criteria)
Run minimal verification as stated in the task, and record key output/signals (PASS/FAIL criteria)
Commit frequently (if the plan requires more granular 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 verification result summary of the task (including commands and key signals)
- If blocked: clearly write "what is missing, how to supplement, who to ask/where to get evidence", and stop entering the next task
Mark as completed (or blocked)

Step 3: Batch checkpoint report (Report checkpoint)

You must report when the batch is completed:

List of completed tasks (corresponding Task ID)
Verification result summary (key commands + key output/signals)
Location of written back content in
```
plan.md
```
and audit information (commit/pr/changed_files)
Overview of unfinished tasks
List of blocked items (if any)

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

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

According to feedback:

If the plan is updated or new critical doubts arise: return to Step 1 to 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 verification passes:

This skill does not directly decide the "next step". Please immediately call
```
using-aisdlc
```
to route to Finish:
```
finishing-development
```
(only verify, ensure all tests/checks are green).
Before entering Finish, ensure that the audit information in
```
plan.md
```
is complete and traceable (at least include
```
commit
```
and key verification result summary; fill in
```
pr
```
if there is a PR)

When to stop and ask for help (Stop on block)

Stop execution immediately:

Block encountered in the batch (missing dependencies/permissions/environment/data)
Tests or verification fail repeatedly (cannot be located or fixed with current evidence)
Do not understand a certain instruction or acceptance standard
Found critical defects in
```
plan.md
```
(cannot continue to execute safely)
Found/added
```
NEEDS CLARIFICATION
```
that will affect correctness or scope

Seek clarification instead of guessing.

When to return to earlier steps

When returning to review (Step 1):

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

Remember

Always execute
```
spec-context
```
first to get context, get
```
FEATURE_DIR=...
```
, stop if failed
```
plan.md
```
is the only execution list and status SSOT: do not create another "status source"
Execute strictly according to the steps in
```
plan.md
```
; do not skip verification
Default to the first 3 unfinished tasks per batch; only report and wait between batches
Stop immediately when encountering blocking/clarification items, do not proceed with guesswork
ADR/contract generated during execution: only persist drafts within
```
{FEATURE_DIR}
```
, and record Merge-back to-do items in
```
plan.md
```
(do not directly modify
```
project/*
```
in I2)

Output after completion and automatic routing (must be executed)

At any of the following moments (batch checkpoint report completed / stopped due to block / all tasks completed and ready to enter Finish), must complete the following actions (in order, cannot be omitted):

Output ROUTER_SUMMARY (YAML format, for Router decision; fill in according to current status, do not always write the same fixed value):

Filling rules:

Batch checkpoint (waiting for feedback):
```
needs_human_review=true
```
,
```
blocked=false
```

Stopped due to block:

needs_human_review=true

blocked=true

, and clearly write

block_reason

All tasks completed, ready to enter Finish:
```
needs_human_review=false
```
,
```
blocked=false
```

yaml

ROUTER_SUMMARY:
  stage: I2
  artifacts:
    - "{FEATURE_DIR}/implementation/plan.md"
  needs_human_review: true
  blocked: false
  block_reason: ""
  notes: "Example: Batch checkpoint has been reported, wait for feedback before continuing to the next batch"

Immediately execute
using-aisdlc
: Pass the above
```
ROUTER_SUMMARY
```
as routing input to using-aisdlc, and the Router will determine the next step and automatically proceed (no need to wait for the user to say "continue").
- If the Router determines that it can automatically resume running: continue to execute the next worker skill in the same round of conversation (such as next batch of I2, Finish, etc.)
- If the Router triggers a hard interrupt: stop and output the blocking reason, required input, candidate next steps
Conversation output: Before calling using-aisdlc, you can briefly state "The products of this phase have been persisted, calling using-aisdlc to route the next step."

Integration

Upstream / Downstream Skills:

spec-plan

- Generate

{FEATURE_DIR}/implementation/plan.md

(SSOT)

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

spec-execute

NPX Install

Tags

SKILL.md Content (Chinese)