---
name: project-implementation-plan
description: Use when turning approved PRD Plugin requirements, architecture, accepted requests, or Superpowers-style design notes into a traceable implementation plan with phases, tasks, validations, and evidence expectations.
---

# Project Implementation Plan

Use this skill only after PRD and architecture are coherent enough to plan from.
Adapted from Superpowers by Jesse Vincent, MIT licensed:
https://github.com/obra/superpowers

## Principle

Detailed execution checklists are useful, but PRD Plugin IDs are non-negotiable.
No Superpowers checkbox task may replace an `IMP-TASK-*` ID.

## Rules

- Create or update the canonical `.prd_plugin/state/artifacts/implementation_plan/<artifact-id>.json`.
- Generate Markdown only on explicit human request.
- Use `IMP-PHASE-*` for phases.
- Use `IMP-TASK-*` for tasks.
- Use `IMP-VAL-*` for validation checks.
- Every task should cite relevant `PRD-*` and `ARCH-*` IDs.
- Split work by independently reviewable outcomes, not by ceremony.
- Keep implementation plans scoped to one MVP or delivery slice.
- Do not put time/duration estimates on phases or tasks. Rate each with
  complexity (trivial/small/medium/large/x-large) and confidence (low/medium/
  high), plus risk when relevant; use a schedule only if the user asks. Follow
  `.prd_plugin/method/estimation.md`.
- Use `DBR-*` document branches for critical paths, corrections, or proposed
  plan changes that are not yet proven enough for mainline plan updates.
- Track active implementation work in `.prd_plugin/state/tracking.json` using
  `TRK-*` records that cite `IMP-TASK-*`, `PRD-*`, and `ARCH-*` IDs.
- Add `CHG-*` changelog records for material plan creation, closure, scope
  changes, or promotion decisions.
- Link validations to evidence expectations so future `EV-*` records can close
  the relevant `TRK-*` items.
- Create or update `HLT-*` findings when tasks are unmapped, stale, blocked, or
  missing validation/evidence expectations.
- Accepted `REQ-*` records should graduate into `TRK-*`, `IMP-TASK-*`, `DBR-*`,
  or another explicit artifact before implementation begins.
- If a Superpowers-style design or plan exists, treat it as source material. Map
  its useful checklist items into `IMP-TASK-*` and `IMP-VAL-*`; do not maintain a
  second canonical plan that can drift from `.prd_plugin/state/artifacts`.

## Required Inputs

- Approved `PRD-*` requirements or accepted `REQ-*` records.
- Relevant `ARCH-*` components, interfaces, decisions, or risks.
- Open `BR-Q-*`, `BR-RISK-*`, `TRK-*`, `HLT-*`, and stale `REQ-*` context.

If these do not exist, use the planning lifecycle before implementation
planning.

## Canonical Format

JSON/JSONL is canonical for planning artifacts. Keep the implementation-plan
JSON compact: phase IDs, task IDs, requirement links, architecture links,
validation IDs, evidence expectations, stale follow-ups, and tracking IDs.
Markdown exports are human snapshots only and must not be edited as project
truth.

## Required Sections

1. Artifact metadata
2. Agent summary
3. Scope
4. Assumptions
5. Phases
6. Tasks
7. Dependencies
8. Validation plan
9. Evidence plan
10. Risks and rollback
11. Tracking and changelog updates, if applicable

## Execution Detail

For each `IMP-TASK-*`, include:

1. Files likely to change.
2. Failing test to write first.
3. Focused command to prove the red state.
4. Minimal implementation direction.
5. Focused command to prove green state.
6. Broader verification command.
7. Expected `EV-*`, `CHG-*`, `REQ-*`, or `HLT-*` updates.

## Tool Parity Deliverable

When a planned feature exposes an agent-invocable capability, the plan MUST
include an explicit tool deliverable task (IMP-TASK-*) covering the tool,
its catalog/coverage-map registration, and its tests — tool parity is part of
the definition of done, not a follow-up. Purely internal or UI-only features
record the exemption rationale in the coverage map instead.

## Staleness Coverage

Apply the shared policy in `.prd_plugin/method/staleness-rules.md`.


Before planning or revising active work, review stale `TRK-*`, `REQ-*`,
`IMP-TASK-*`, `DBR-*`, `BR-Q-*`, `BR-RISK-*`, and `HLT-*` records for the same
scope. Close or refresh stale items only with evidence; otherwise keep them
visible as health findings or explicit follow-up work.

## Output Shape

Report:

1. New or updated `IMP-PHASE-*`, `IMP-TASK-*`, and `IMP-VAL-*`.
2. Source `PRD-*`, `ARCH-*`, `DEC-*`, and `REQ-*` links.
3. Expected `EV-*` records.
4. Open questions or stale records carried forward.
5. Whether implementation should proceed with `project-test-driven-implementation`.

## Review Checklist

- Tasks are sized for reliable execution.
- Validation is specific.
- Dependencies are explicit.
- No task exists only to satisfy process unless it produces reusable evidence or reduces risk.
- Closed plans become reference-only; corrections use a new plan or document
  branch rather than endless appends.
- Active work tracking records cite implementation task IDs and include
  `AGENT-*` / `SES-*` provenance.
- Relevant `HLT-*` findings are created, resolved, or left open with a reason.
- Accepted `REQ-*` records are linked to the plan tasks or tracking records that
  carry the work.

## Parallel Worker State Boundary

When `tracking.branching.require_for_parallel_agents` is true, a parallel worker
is launched with `PRD_WORKER_SESSION=1`, `PRD_TRACKING_BRANCH_ID=<DBR-*>`, and
`PRD_TRACKING_BRANCH_OWNER=<owner>`. It calls only
`prd_update_tracking_branch` on that assigned branch. It records proposed plan,
`TRK-*`, `CHG-*`, evidence, and other canonical state changes as branch notes;
the lead applies them serially after merge and calls
`prd_promote_tracking_branch`. Workers never edit canonical state or
`.prd_plugin/ids/registry.json` directly.