speckit.companion.implement

Custom agent imported from rnoap/spec-kit-shared-knowledge (.github/agents/speckit.companion.implement.agent.md). Copyright stays with the author.

User Input

$ARGUMENTS

Outline

1. Read .specify/feature.json for the feature directory; load <feature_directory>/tasks.md, plan.md, and spec.md. Then record the implement START so the step's duration begins now (the script stamps the real clock; the end-of-step hook records each task and closes the step — do not hand-write implement timing):

   python3 .specify/extensions/companion/scripts/write-context.py --feature-dir <feature_directory> --step implement --status implementing --kind start --by extension

2. Execute tasks in dependency order:

   • Complete each layer before the next: Setup → Foundational → Core → Integration → Polish.
   • Tasks marked [P] (different files, no incomplete dependency) may run together; tasks touching the same file run sequentially.
   • Halt on a failed non-parallel task and report the cause; for [P] tasks, continue the others and report the failure.

3. After completing a task, mark it - [x] in tasks.md.

4. On completion, validate the result against the spec's Functional Requirements and Success Criteria, and report a short summary of what was built and anything left undone.

Output: working changes per tasks.md, with completed tasks checked off.

Timing — keep .spec-context.json honest

These rules apply to every Companion profile command. The extension records lifecycle timing with its own scripts wherever it can; these rules keep anything you append consistent with that and accurate for any dispatcher (terminal, IDE chat, or the GUI). The model is finish-only: each task and each substep records a single finish event, and its duration is the gap to the previous finish (or the step's start). Never a start+complete pair for a task or substep — a pair stamped at one instant is what produces 0s ticks and bursts.

• Live timestamps. When you append a history entry yourself, stamp it by running date -u +"%Y-%m-%dT%H:%M:%SZ" at that moment. Never hand-type a timestamp, never reuse an earlier value, never stamp several entries with one shared value.

• Self-close — but not specify or implement. When your own work for plan, tasks, clarify, or analyze ends, append { "step": "<this step>", "substep": null, "kind": "complete", "by": "ai", "at": "<date -u output>" }. Do NOT self-close specify or implement: the extension closes those itself (specify from its own command, implement from the end-of-step hook), so an ai complete there would duplicate it.

• Substeps — one finish each. For each substep boundary (plan: research, design; tasks: generate) append a single finish { "step": "<step>", "substep": "<name>", "kind": "complete", "by": "ai", "at": "<fresh date -u>" } the moment that substep ends. One entry per substep, each with its own real timestamp — never two substeps sharing a value, never a separate start. The delta between consecutive finishes is each substep's duration.

• Implement — journal each task with a script (finish-only). As you finish each task: mark it - [x] **<TaskID>** in tasks.md, append task_summaries.<TaskID>, then run (feature dir from .specify/feature.json):

  python3 .specify/extensions/companion/scripts/write-context.py --feature-dir <feature_dir> --task <TaskID> --kind complete --by ai

  Run this the moment that task completes — one finish per task, as you go. Do NOT defer journaling to the end of the step and do NOT dump every task's finish in one end-of-step batch: that collapses their real durations into a single instant, and the cadence check now FAILS a run whose task finishes are clustered into a tiny fraction of the step's real duration. This stamps one finish event from the real clock — its delta to the previous task's finish is that task's duration. Do NOT hand-author per-task JSON and do NOT write a per-task start. The end-of-step hook is a backstop that fills any task you didn't journal (it won't duplicate one you did). Parallel [P] tasks: journal each as it finishes; the batch's time is attributed to whichever finishes last (accepted limitation).

• Never write the next step's start. Only the next command appends the next step's start entry; writing it here makes the viewer render a phantom "Generating …".