agentleFS
h3y6eh3y6e/spec-skills/skills/spec-implement/SKILL.md

spec-implement

Skill0 starsChanged 9 months agoMITView on GitHub

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.

6 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Iron Law: No completion claims without fresh verification evidence.

    line 16
  2. Distinctive:

    When testing is required to prove the task is complete, make the test change, verification command, and expected outcome explicit before …

    line 36
  3. Distinctive:

    Run the actual verification command and read the output before claiming pass.

    line 42
  4. Very specific:

    Update plan.md: after each successful task:

    line 43
  5. Distinctive:

    Stop-the-line backflow: when findings change approved documents:

    line 51
  6. Distinctive:

    If documents are updated, review and keep within 150 lines.

    line 55
  7. Distinctive:

    Every task has fresh verification evidence (not stale or assumed)

    line 61

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.