spec-implementation-execute

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

Overview

The goal of I2 is to take the tasks in {FEATURE_DIR}/implementation/plan.md tasks inexecute in batches, and write execution status and minimal audit informationback only to plan.md(as the sole execution checklist and status SSOT).

This skill is the Spec implementation-phase version of skills/executing-plans/SKILL.md :heavily reuses its "five-step execution + batch checkpoints + stop upon blockers" skeleton, but replaces the semantics of the "plan file" with the hard constraints of the implementation-phase SOP (see design/aisdlc_spec_implementation.md):

• plan.md is thesoleexecution checklist and status source (checkbox + audit information + verification result summary)
• By default, execute each batchthe first 3 unfinished tasks
• Any NEEDS CLARIFICATION / critical plan defect / blocker:stop immediately and report(do not push forward by guessing)
• If decisions/contract changes arise during execution:draft only within {FEATURE_DIR} draft in, and append to plan.md a Merge-back todo list(directly updating is prohibited at this stage project/*）

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

When to use / not use

• When to use
  • already exists {FEATURE_DIR}/implementation/plan.md(I1 is complete), and now proceed to I2 to implement by task.
  • You need to strictly perform "batch checkpoint reporting" during execution, and write status/audit back to plan.md。
• Do not use when
  • spec-context fails, cannot obtain FEATURE_DIR(in this case you must stop).
  • plan.md does not exist, or lacks an executable task checklist (in this case return to I1:spec-implementation-plan）。
  • plan.md 's NEEDS CLARIFICATION has still not been eliminated, or there are critical defects that make it impossible to start (in this case you must first stop and propose clarification/plan fixes).

Gates / Stop (strictly enforced)

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

Stop immediately (satisfying any one is sufficient):

• Did not obtain FEATURE_DIR
• The current branch is main/master(or you did not obtain the user's explicit consent to implement on the main branch)
• {FEATURE_DIR}/implementation/plan.md does not exist or is unreadable
• plan.md contains an unresolved NEEDS CLARIFICATION, and it will block continued execution
• The plan has critical defects: missing executable commands/missing minimal verification/unclear scope/unclear dependencies, making it impossible to start safely
• A blocker is encountered during execution: missing dependencies/permissions/environment/data, repeated test failures, or an instruction that is not understood

Seek clarification, not guesses.

Input / Output (persistence conventions)

• Read (progressive disclosure, minimum necessary)
  • {FEATURE_DIR}/implementation/plan.md(required; SSOT)
  • plan.md referenced by {FEATURE_DIR}/requirements/*、{FEATURE_DIR}/design/*(read as needed, do not expand in full)
  • {FEATURE_DIR}/requirements/solution.md#impact-analysis(look up as needed: list of affected modules, invariants to follow, related ADRs, cross-module impact)
  • Project-level index (read-only, as needed):project/memory/*、project/contracts/、project/adr/
• Write (single source of truth)
  • Only write status/audit back {FEATURE_DIR}/implementation/plan.md: check off tasks, fill in commit/pr/changed_files, record a summary of key verification results and the evidence-gathering path for blockers
• Code and configuration changes
  • Implement according to plan.md the path declared for each task (create/modify/test)
• Decision/contract drafts within the Spec (if produced during execution)
  • ADR draft: preferably write to {FEATURE_DIR}/design/design.md the "Decisions/Trade-offs" section; if necessary add {FEATURE_DIR}/design/adr/*.md
  • Contract draft: write to {FEATURE_DIR}/design/contracts/
  • Sync requirement: in plan.md append/update the "Merge-back TODO list" (record only, do not directly modify in I2 project/*）

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

Process (reuse the five-step skeleton of executing-plans)

Step 1: Load and review the plan (Review)

1. Open and read {FEATURE_DIR}/implementation/plan.md
2. Review strictly—identify any issues or concerns that would block execution, such as:
   • The task does not clearly state "which files to change/what commands to run/what signal is expected"
   • Missing a minimal verification method or verification is not executable
   • Task out of bounds (inconsistent with the scope/milestones of plan.md)
   • Dependencies/permissions/environment not satisfied
   • NEEDS CLARIFICATION not eliminated
3. If there are critical concerns:Stop before starting and report(write the problem clearly, provide the evidence-gathering path; if necessary return to I1 to revise plan.md)
4. If there are no concerns: proceed to batch execution

Step 2: Batch execute

Default: the first 3 incomplete tasks(can be adjusted based on risk and dependencies, but the reason must be explained).

For each task:

1. Mark as in_progress
2. Execute strictly according to the task steps(do not skip steps; do not replace commands; do not secretly change acceptance criteria)
3. Run the minimal verification declared by the task, and record key outputs/signals (PASS/FAIL criteria)
4. Commit frequently(if the plan requires finer commit points, follow the plan first)
   • Commit message Must be in Chinese
5. Write back to plan.md(single source of truth):
   • - [ ] → - [x]
   • Fill in commit/pr/changed_files
   • Record a summary of the key verification results for this task (including commands and key signals)
   • If blocked: clearly state "what is missing, how to fill it in, from whom/where to gather evidence", and stop before proceeding to the next task
6. Mark as completed (or blocked)

Step 3: Batch checkpoint report (Report checkpoint)

When the batch is complete, you must report:

• List of completed tasks (corresponding Task IDs)
• Summary of verification results (key commands + key outputs/signals)
• plan.md The location and audit information written back (commit/pr/changed_files)
• Overview of incomplete tasks
• List of blockers (if any)

Then say: "Ready for feedback." andWait for feedbackbefore continuing with the next batch.

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

Based on the feedback:

• If the plan has been updated or a new key concern has emerged: return to Step 1 to re-review
• Otherwise: execute the next batch and repeat steps 2–3 until the task list is fully processed

Step 5: Finish development (Finish)

When plan.md all planned tasks are completed and minimal verification passes:

• This skill does not directly decide the "next step". Pleaseimmediately call using-aisdlc to route to Finish:finishing-development(verification only, ensuring tests/checks are all green).
• Before entering Finish, ensure that plan.md the audit information is complete and traceable (including at least commit and a summary of key verification results; if there is a PR, complete pr）

When to stop and seek help (Stop on block)

Stop execution immediately:

• A blocker is encountered in the batch (missing dependency/permission/environment/data)
• Tests or verification fail repeatedly (cannot be located or fixed under the current evidence)
• An instruction or acceptance criterion is not understood
• Discover plan.md a critical defect (cannot continue safe execution)
• Discover/add NEEDS CLARIFICATION that affects correctness or scope

Seek clarification rather than guessing.

When to return to earlier steps

When returning to review (Step 1):

• The collaborator has updated plan.md
• based on your feedback. You need to adjust the task order/breakdown to continue (must first clarify in plan.md before executing)
• The fundamental approach needs to be reconsidered (stop first, then fix the plan/add evidence)

Keep in mind

• Always first spec-context obtain FEATURE_DIR=..., stop on failure
• plan.md is the only execution checklist and status SSOT:do not create a separate "source of status"
• Strictly follow the plan.md steps; do not skip verification
• By default, the first 3 unfinished tasks per batch; between batches, only report and wait
• Stop immediately when encountering blockers/clarification items; do not guess and push forward
• ADRs/contracts produced during execution: only write draft files in {FEATURE_DIR} and record the Merge-back todo in plan.md (I2 does not directly modify project/*）

Output and automatic routing after completion (must be executed)

At any of the following moments (end of batch checkpoint report / stop due to blocker / all tasks completed and preparing to enter Finish),you mustcomplete the following actions (in order, cannot be omitted):

1. Output ROUTER_SUMMARY(in YAML form, for Router decision-making; fill in according to the current status, do not always hardcode it to the same value):

Filling rules:

• Batch checkpoint (waiting for feedback)：needs_human_review=true，blocked=false
• Blocked stop：needs_human_review=true，blocked=true, and clearly write block_reason
• All tasks completed, preparing to enter Finish：needs_human_review=false，blocked=false

ROUTER_SUMMARY:
  stage: I2
  artifacts:
    - "{FEATURE_DIR}/implementation/plan.md"
  needs_human_review: true
  blocked: false
  block_reason: ""
  notes: "示例：批次检查点已汇报，等待反馈后继续下一批"

1. Immediately execute using-aisdlc: pass the above ROUTER_SUMMARY as routing input to using-aisdlc, and the Router determines the next step andautomatically advances(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 within the same conversation turn (such as the next batch of I2, Finish, etc.)
   • 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; calling using-aisdlc to route the next step."

Integration

Upstream / downstream skills:

• spec-implementation-plan - Generate {FEATURE_DIR}/implementation/plan.md（SSOT）
• finishing-development - After all tasks are completed, perform the development wrap-up confirmation