---
name: generate-spec
description: Gate 2 — After DEV approves the requirement document (Gate 1), AI creates a detailed implementation plan using TDD approach. This is the bridge between requirement and code.
keywords: spec, plan, implementation, tdd, coding plan
---

# Implementation Plan — Gate 2

> ⚠️ **Only invoke for `feature`, `bug-fix`, `refactor`, `investigation`, and `documentation` tasks.** For `gen-doc` tasks, skip this skill entirely — Gate 2 goes directly to document generation, no `plan.md` needed.

> **GATE 2: Runs after Gate 1 (requirement document) has been APPROVED by DEV.**
>
> Principle: AI uses the approved requirement document to create a detailed implementation plan with TDD steps. DEV confirms the plan before coding begins.

---

## Conditions to Enter Gate 2

- ✅ Gate 1 APPROVED — `AK-Docs/04.Coding/01.Requirements/[functionId]/[ticketId].md` reviewed and approved by DEV
- ✅ Requirement document includes: requirements, solution, impact analysis, estimate

## Fast Mode Output Rules (CRITICAL)

When updating `AK-Docs/04.Coding/04.Reviews/[functionId]/[ticketId].md` in **fast mode**:
- **Keep it extremely short.**
- Add a bullet point indicating Gate 2 plan is ready.
- **DO NOT copy the entire plan.md into summary.md.**

---

## Process

### Step 1: Read Approved Requirement

Read `AK-Docs/04.Coding/01.Requirements/[functionId]/[ticketId].md` — use the chosen approach, file list, and testing plan as input.

Also read **Section 2 (Dependency Map)** and **Section 4 (Impact Analysis)** — do NOT re-run dependency investigation, Gate 1 already collected it. Carry every area flagged 🟡 Medium / 🔴 High / ⛔ Critical into Step 2's task breakdown (see below).

### Step 1.5: Read Design Context (if present)

If `plan/[ticket-id]/design/design-context.md` exists (UI ticket from Gate 1):

1. Read `design-context.md` — do NOT call Figma MCP again; the design is already cached.
2. Feed these into the TDD plan:
   - **Component tree** → one build task per component (with its variants/states)
   - **Design tokens table** → mapping notes per component (color/type/space → project token)
   - **Image Map** → a task to copy images from `plan/[ticket-id]/design/images/`
     to `public/assets/figma/` before the component task that consumes them
3. Each UI task must carry an acceptance note: "matches design-context.md (layout, color, type, spacing)".

If the file is absent → skip this step (non-UI ticket).

### Step 2: Create Implementation Plan

**INVOKE:** `superpowers:writing-plans`

Create a detailed step-by-step plan based on the requirement document:

```markdown
## Implementation Plan

### Task Breakdown (TDD Order)

| # | Task | File | Test First? | Dependencies |
|---|------|------|-------------|--------------|
| 1 | Write test for [scenario] | [test file] | ✅ | None |
| 2 | Implement [component] | [source file] | — | Task 1 |
| 3 | Write test for [scenario] | [test file] | ✅ | Task 2 |
| ... | ... | ... | ... | ... |
| N | Update/verify dependent [Caller X] (impact: 🟡/🔴/⛔) | [dependent file] | ✅ | [task that changes the shared symbol] |

### Test Commands
```bash
[specific test commands for this project]
```
```

Output language: auto-detect from the ticket/task input — see `custom/rules/output-language.md` (Vietnamese input → Vietnamese output; otherwise English).

> For UI tasks, reference the exact node/component from `design-context.md` in the Task column
> (e.g. "Build UserCard — nodeId 78-910"). Add an image-copy task when the Image Map is non-empty.
>
> For every dependency in requirement.md Section 4 flagged 🟡 Medium / 🔴 High / ⛔ Critical, add one task per affected caller/dependent (update it, or add/extend a regression test) — placed right after the task that changes the shared symbol they depend on.

### Step 3: GATE 2 — Present Plan & Start Coding

```markdown
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⏸️  GATE 2: IMPLEMENTATION PLAN READY

Based on the approved requirement document, here is the coding plan:

[Show task breakdown summary]

**Total tasks:** [N]
**Test-first tasks:** [N]

Ready to start coding?
Type **"APPROVED"** to begin implementation.
Type feedback to adjust the plan.

⚠️  I will NOT write code until I receive "APPROVED".
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

### Step 4: Handle Feedback

**If DEV provides feedback:**
→ Update the implementation plan
→ Re-display GATE 2 prompt

**If DEV types "APPROVED":**
→ Proceed to Gate 3 (Code Generation with TDD)
→ Follow the task breakdown order exactly

---

## Mandatory Rules

- ❌ **DO NOT** start coding until "APPROVED" is received for the plan
- ❌ **DO NOT** deviate from the approved requirement document
- ✅ **MUST** use TDD order: test first, then implementation
- ✅ **MUST** invoke `superpowers:writing-plans` for plan creation
- ✅ **MUST** show clear task breakdown before getting approval
- ✅ **MUST** include a task for every dependency flagged 🟡 Medium / 🔴 High / ⛔ Critical in Gate 1's Impact Analysis (Section 4)
- ❌ **DO NOT** re-run dependency-map investigation — reuse Gate 1's Dependency Map (Section 2) as-is
- ❌ **DO NOT** include `git commit`, `git add`, or any git operations in the plan. The developer manages commits manually.