create-spec-implement

Files (1)

• SKILL.md

SKILL.md (first lines)

# Phase-by-phase Plan Implementer (IMPLEMENT)

You are a senior engineer. Your task is to implement one phase of the plan: **$ARGUMENTS**

> **Implementation = one phase at a time. Write code, verify, record.**
> Input is an approved plan from `docs/plans/`.


## PHASE 1: Recon (SILENT, no output)

### 1.1. Find the plan

If `$ARGUMENTS` contains a file path → read it.
If `$ARGUMENTS` is a name → find it:
```
Glob: docs/plans/*$ARGUMENTS*
```
If not found → show the list: `ls docs/plans/` and suggest `/create-spec-plan <name>`.

### 1.2. Determine progress

Read the plan in full. For each phase, determine status:
- ✅ **Completed** — all `[x]` in the checklist
- 🔄 **In progress** — some `[x]`, some `[ ]`
- ⬜ **Not started** — all `[ ]`

### 1.3. Find the linked spec

Read the `**Specification:**` field in the plan → load the linked spec from `docs/specs/`.

### 1.4. Check for unresolved questions

Read the "Deferred questions" section in both the plan and the spec. For each entry:

- If `When the answer is needed` points to the CURRENT plan phase or earlier → that question **blocks** implementation. Add to the queue.
- If the entry concerns a phase that's NOT selected right now — skip, you'll deal with it on the next `/create-spec-implement` call for that phase.

If the queue is non-empty — ask the questions **one at a time** via `AskUserQuestion` (see [interactive questions rules](#interactive-questions-rules-shared-block)). After each answer:

1. Open the source file (plan or spec) and move the entry from "Deferred" to "Plan decisions" / "Spec decisions".
2. If the answer changes the phase's tasks — update the phase's checklist in the plan.

Don't advance to Phase 2 until the queue is empty.

### 1.5. Pre-flight

1. Read the brief's **Principles** (`docs/brief/PROJECT-BRIEF.md`, if present) — they bind implementation choices too.
2. Verify the toolchain runs on the **current** tree before touching code: the project's check command (`cargo check` / `tsc --noEmit` / equivalent) and test runner. A broken baseline → report and stop; fixing pre-existing breakage is not part of the phase (offer it as a separate task).


## PHASE 2: Phase selection

Show the user **in a single message**:

```
📋 Plan: [Plan name]
📄 Spec: [path to spec]

Phase progress:
  ✅ Phase 1: [Name] — completed
  🔄 Phase 2: [Name] — in progress (3/5 tasks)
  ⬜ Phase 3: [Name] — not started
  ⬜ Phase 4: [Name] — not started

→ Proposing: Phase N — [Name] (estimate: X h)
  Tasks:
  - [ ] Task 1
  - [ ] Task 2
  - ...
```

If the user specified a phase number in `$ARGUMENTS` → propose that one.
Otherwise → propose the next unfinished one (the first ⬜ or 🔄).

If the user specified a different phase — wait for their input. Otherwise, proceed automatically.


## PHASE 3: Loading context (SILENT, no output)

After phase confirmation:

### 3.1. Phase files
Read ALL files listed in the selected phase's tasks (paths from the checklist `→ path/to/file`).

### 3.2. Related requirements
In the "Traceability: Requirements → Tasks" table, find which FR-XXX this phase covers.
Read those requirements in the spec.

### 3.3. Project patterns
Study analogous implementations in the codebase — how similar modules, error handling, tests are organized.


## PHASE 4: Approval checkpoint

Show the user **in a single message** the attack plan:

```
🎯 Phase N: [Name]

Covers requirements: FR-001, FR-002, ...

Tasks:
1. [Task] → `path/to/file`
   Approach: [brief description of what and how we change]

2. [Task] → `path/to/file`
   Approach: [brief description]

...

Validation after implementation:
- [ ] cargo check / tsc --noEmit (compilation)
- [ ] [Relevant tests]
- [ ] [Manual check if needed]
```

Proceed to implementation automatically after displaying this plan. If the user wants to adjust — they will interrupt.

From askidmobile/ai-spec-kit, MIT.

More from askidmobile/ai-spec-kit