spec-implementation-plan

Spec implementation plan

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

Persist the plan locally and emit Forge readiness for 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.

Prayog owns the WorkManifest contract (apiVersion: prayog/v1, prayog-skills/references/workmanifest-contract.md). Launchpad only materializes the pin — it does not own, parse, or execute WorkManifest.

NON-NEGOTIABLE

1. Never skip a check in references/checks.md. Mark SKIPPED with reason.
2. Every TASK has objective exit evidence: observable exit criteria, proving command or review, expected result, and evidence location — plus an Implements list of product REQ-* ids and toolchain commands where applicable. Do not invent shadow REQ-W* ids — see prayog-skills/references/id-conventions.md.
3. Every acceptance criterion maps to a verification layer (unit, integration/contract, smoke, or sandbox) in the wave Verification Coverage table. Plan scope must not exceed the initiative spec.
4. Dual output: chat summary + saved plan file (local + Forge readiness).
5. Run T0–T5 control loop.
6. Wave IDs must use W0, W1, … (one GitHub Issue per wave; WorkManifest id: convention).
7. Every TASK row must include codebase, spec_path, verify_command, Implements REQ-*, depends_on, file path/action scope, and exit proof fields — required for WorkManifest generation. §9 wave entries must include tasks[], verification, and a body table listing those TASK ids.
8. Spec product-spec H1–H3 citations (and G1 when applicable) must agree with live handoff; tip continuous. Stop on authority drift. Feas/TDD file digests are walk-time only — not long-term stale SSOT. Implementation-Plan is walk-time (§9 → board); may be purged at initiative closure.
9. Resolve canonical check_command, test_command, verify_command, and ground_command before planning. Required commands may come from the consumer profile, AGENTS.md, or tests_readme; missing required commands block the plan. verify_command is the live script entry under live_verify_dir — never {test_command} / unit-only. Use N/A with reason only when a layer is not applicable. When P15 applies (new/material product surface), bare N/A or unit-as-live is invalid — co-ship the verify FILE and fixture pack path(s) under fixtures_dir for the capability (CAP-*) and/or journey (J-*) rung being shipped (see references/checks.md P15; prayog-skills/references/live-fixture-contract.md).
10. Persist the plan locally and fill handoff.forge for /commit-workspace onto the same Draft spec PR. Do not commit, push, branch, open PRs, apply labels, create issues, or merge inside this skill. Coding-readiness label stays spec-pending. After T5, present the coding-readiness unlock checklist from the output template so PE knows when to set spec-lgtm.
11. Select workflow outcome from the rubric below; map evidence deterministically.
12. Before coding-readiness, run a read-only cross-artifact consistency pass (spec ↔ plan REQ ids, plan ↔ §9 WorkManifest, Accepted ADR citations). Corrections belong in the owning artifact — do not invent a parallel truth in chat.
13. Live-verify coverage lives in the artifact's own marker, not in tests/README.md or as a growing table in implementation-status.md — see prayog-skills/references/live-verify-coverage-contract.md. Run the required overlap check (P15) via --capability / --journey / --req before declaring a new live_verify_dir or fixture FILE. covers must include relevant CAP-* and/or J-* (plus REQ-*). As-built writes go to Implementation-Status-{INIT}.md (detail) + one index row in implementation-status.md (pointer) — never a new table appended to the shared index.
14. Capability ≠ journey. Plan separate prove artifacts/covers when both rungs ship; do not collapse journey proof into “all CAP journeys passed”. Populate dependencies, fixtures, and human_observations when opaque (logs alone are not pass evidence).
15. If a codegraph provider is available (MCP tool matching prayog-skills/references/codegraph-tool-contract.md, or a local CLI), prefer it for architecture/impact/coverage questions. Always fall back to direct source_roots reads when unavailable — never block or change outcome selection on its absence.