Spec Implementation Plan

Spec implementation plan

Turn an accepted initiative spec (+ feasibility report + technical review when present) into an executable plan with a board-seed artifact (§9). Do not implement — plan only.

Commit the plan to the spec PR branch alongside spec, feasibility, and TDD. Table shape borrowed from awesome-copilot create-implementation-plan (REQ/TASK/FILE/TEST/RISK). §9 WorkManifest YAML is generated here; dev seeds the board after spec PR merge.

NON-NEGOTIABLE

1. Never skip a check in [references/checks.md](references/checks.md). Mark SKIPPED with reason.
2. Every TASK has done when criteria and test/verify command from profile toolchain where applicable.
3. Plan scope must not exceed the initiative spec.
4. Dual output: chat summary + saved plan file on spec branch.
5. Run T0–T5 control loop.
6. Wave IDs must use W0, W1, … (one GitHub Issue per wave; launchpad WorkManifest id: convention).
7. Every TASK row must include codebase, spec_path, and verify_command — required for WorkManifest generation.

Inputs

Resolve paths from .harness/profile.yaml or [references/layout-defaults.md](references/layout-defaults.md).

1. Initiative spec — on spec branch (REQUIRED)
2. Feasibility report — if exists (RECOMMENDED)
3. Technical review — Technical-Review-{initiative}.md if produced (RECOMMENDED; required when feasibility had NEW-ADR findings)
4. As-built, testsreadme, liveverify_dir layout (REQUIRED for test tasks)
5. Layout — .harness/profile.yaml or [references/layout-defaults.md](references/layout-defaults.md)
6. rules_glob — workspace MDC rules (REQUIRED). Read before T2 Analyze.
7. adr_dir — architecture decision records (REQUIRED). Run relevant-ADR pass per [references/governance.md](references/governance.md) before T2 Analyze.

Prerequisite

Run while spec PR is open, before spec merge, after:

• Feasibility accepted (no blocking PM questions on meta PRD PR)
• PE Approve on spec PR when TDD was required (NEW-ADR findings)

> How to confirm PE Approve reached the skill chain: > There is no automatic signal from GitHub. After PE clicks Approve on the spec PR, > the dev must commit a TDD status update to the spec branch: > | Status | Accepted — @{pe-name} {YYYY-MM-DD} | (document header) > **Status:** Accepted — @{pe-name} {YYYY-MM-DD} (each §4.N draft ADR) > This committed file state is what /spec-implementation-plan reads to verify > sign-off. P13 will FAIL if the TDD Status field still reads Draft.

Process

1. T0 Gather — spec waves, feasibility findings, technical review (if exists), repo layout
2. T1 Understand — initiative id, wave boundaries, PR granularity from spec
3. T2 Analyze — map each wave to concrete files and tests; cross-reference rules_glob and relevant ADRs; flag spec wording that conflicts with MDC patterns or Accepted ADRs as MDC notes / ADR notes in the TASK table
4. T3 Plan — build REQ/TASK/FILE tables per wave; when TDD contains §4 draft ADRs or feasibility flagged NEW-ADR, add a mandatory pre-W0 TASK-SPEC-ADR-NN for each draft: promote TDD §4 section → {adr_dir}/adr-NNN-{slug}.md with status Accepted, PE name, and date; collect codebase/spec_path/verify_command per TASK
5. T4 Execute — write plan; build WorkManifest seed section; run P1–P14 checks; commit to spec branch
6. T5 Verify — self-contained plan readable by a fresh session; WorkManifest YAML is valid

Output

Save to {reports_dir}/{plan_prefix}-{initiative}.md.

Use [references/output-template.md](references/output-template.md).

WorkManifest integration

The plan's final section (§9) emits a ready-to-use WorkManifest YAML stub.

After spec PR merge — not before — the dev team seeds the board from §9:

# One GitHub Issue per wave (W0, W1, …) — primary path
gh issue create --repo {org}/{repo} \
  --title "[{INITIATIVE} W0] {wave goal}" \
  --body-file /tmp/w0-body.md \
  --label "{initiative-label}"

# Optional multi-repo / bulk: copy §9 to work/{initiative}.yaml, then:
# launchpad seed-work --config work/{initiative}.yaml --dry-run
# launchpad seed-work --config work/{initiative}.yaml --apply

One TASK row in the plan maps to work described in the wave issue body. Wave hierarchy is expressed via depends_on in §9 YAML (and GitHub issue links in issue bodies when seeding manually).

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: drivestream-lab
• Source: drivestream-lab/prayog-skills
• License: MIT

Install and usage instructions live in the source repository linked above.