# Spec Implement

> Execute open tasks from specs/{feature}/plan.md using an implement → self-validate → fix loop, updating plan.md progress after each completed task. Use this skill whenever someone wants to start or continue feature implementation guided by plan.md, run a self-validating coding loop, continue from a specific task ID, or work through phased tasks with built-in quality checks. This is the execution phase after spec-plan in the spec-driven workflow. Don't use for ad-hoc bug fixes, code review, or implementation tasks not defined in plan.md.

- Skill: `h3y6e/spec-implement` (Agent Skill)
- Install (CLI): `npx skillmds@latest add h3y6e/spec-implement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/h3y6e/spec-implement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- License: MIT
- Author: h3y6e (https://skillmd.com/u/h3y6e)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/h3y6e/spec-implement

---


# Implement Skill

## Purpose

Implement using `specs/{feature}/plan.md` as the single progress source.

**Iron Law:** No completion claims without fresh verification evidence. If you haven't run the command in this step, you cannot claim it passes.

## Input

- Existing `specs/constitution.md` when present
- `specs/{feature}/spec.md` and `specs/{feature}/plan.md`

## Output

- Implemented code with passing tests
- Updated `specs/{feature}/plan.md` (and `spec.md` if findings require it)
- Progress log entries with verification evidence

## Steps

1. Resolve `language` and shared rules from `specs/constitution.md` when present; otherwise infer from workflow documents and the user's message. Ask only if still unclear.
2. Confirm spec/plan approval state — both must be `approved` before work begins — and critically review the plan for gaps, contradictions, or unclear verification before implementing.
3. Process open tasks from top to bottom. Set `plan.md` to `in-progress` when work starts.
4. **Implementation loop** for each task:
   - Implement the smallest coherent slice
   - When testing is required to prove the task is complete, make the test change, verification command, and expected outcome explicit before claiming success
   - For bug fixes, test failures, or unexpected behavior, reproduce and identify root cause before changing implementation; create the failing check first when practical
   - Classify findings: `local-only` (continue), `plan-impacting` (update plan, realign), `spec-impacting` (stop, return upstream)
   - Delegate deep investigation to `spec-research` when needed
   - Self-validate (tests, type checks, static analysis, security checks)
   - Fix until green
   - Run the actual verification command and read the output before claiming pass; never trust "should pass" or stale results
5. **Update `plan.md`** after each successful task:
   - Map the task or phase DoD to the fresh evidence that proves it; passing commands are not enough if they do not cover the requirement
   - Mark task complete, keep `status: in-progress` until all tasks and phase DoD items finish
   - Append under `## Progress Log` (create if missing):
     - Task: [TASK_ID] | Change: [SUMMARY] | Doc Impact: [local-only|plan-impacting|spec-impacting]
     - Coverage: [US/FR/DoD proven]
     - Validation: [PASS/FAIL + evidence] | Next: [NEXT_TASK]
6. Escalate exception cases: conflicting requirements, high-risk changes, unresolvable validation failures.
7. **Stop-the-line backflow** when findings change approved documents:
   - `plan-impacting`: update `plan.md`, realign before resuming
   - `spec-impacting`: update `spec.md`, reset to `draft`, stop until re-approved
8. Confirm DoD completion per phase. Set `plan.md` to `done` when all tasks and DoD items pass.
9. If documents are updated, review and keep within 150 lines.
10. Suggest next step: continue `spec-implement` or final completion report.

## Success Criteria

- `plan.md` progress matches actual implementation state
- Every task has fresh verification evidence (not stale or assumed)
- Completion is backed by requirement-to-evidence mapping, not proxy green status alone
- Findings that affect plan/spec trigger document realignment before continuing
- Phase DoD items are satisfied
- Non-exception issues resolved inside the self-validation loop

## Completion Guidance

- Next recommended step: continue `spec-implement` or close implementation
- Include completed tasks, remaining tasks, and the next task in the response