---
name: project-planning-lifecycle
description: Use when converting brainstorms, early project notes, accepted requests, or rough feature ideas into a complete PRD, architecture, implementation-plan, and traceability-ready planning chain.
---

# Project Planning Lifecycle

## Deterministic Entry

Plan and run `planning.requirements` when enabled. The workflow owns current
state validation and the source-bound requirements judgment envelope; this
skill owns the quality and traceability of the returned planning judgment.

Use this skill to orchestrate brainstorm -> PRD -> architecture -> implementation plan.

## Rules

- Do not skip artifacts. Gather or create source context first, then PRD, then
  architecture, then implementation plan.
- Use `project-brainstorm` when the idea is still exploratory or source
  context has not been captured with stable `BR-*` IDs.
- Use `project-prd` before architecture when product requirements or acceptance
  criteria are missing, ambiguous, or stale.
- Use `project-architecture` before implementation planning when components,
  interfaces, decisions, risks, or validation strategy are missing.
- Use `project-implementation-plan` only after PRD and architecture are
  coherent enough to plan from.
- Use `project-traceability-sync` after creating or revising lifecycle
  artifacts so source IDs map forward.
- Use `project-traceability-review` before closeout to catch missing or weak
  links.
- Do not create or revise an implementation plan until PRD and architecture are
  coherent enough to plan from.
- Route disputed, experimental, or unproven planning changes through a `DBR-*`
  document branch rather than changing mainline project truth.
- Do not put time/duration estimates on planning artifacts; use complexity and
  confidence ratings (plus risk) per `.prd_plugin/method/estimation.md`.

## Canonical Artifact Format

See `.prd_plugin/method/artifact-format.md` for the authoritative rule.

JSON/JSONL is canonical for planning artifacts. Generate Markdown only on
explicit human request.

For each PRD, architecture doc, or implementation plan, create or refresh the
canonical JSON artifact under
`.prd_plugin/state/artifacts/{artifact_type}/{artifact_id}.json`. The JSON
artifact is project truth and should contain IDs, summaries, source links,
traceability, stale follow-ups, and evidence expectations. Markdown exports are
snapshots for human review only; do not edit them as canonical state.

## Traceability Gates

- Every `PRD-REQ-*` must cite a `BR-*` source or accepted `REQ-*` source.
- Every major `ARCH-*` item must cite a `PRD-*` or `DEC-*` source.
- Every `IMP-TASK-*` must cite both `PRD-*` and `ARCH-*` sources.
- Every validation or evidence expectation should map to an `IMP-VAL-*`,
  `TRK-*`, or future `EV-*` path.
- Run traceability sync and traceability review before closeout.

## Tool Reachability at Intake

For every feature entering the planning chain ask: "what tool exposes this —
i.e. should an agent be able to invoke this capability?" If yes, the PRD and
plan carry the tool as a first-class deliverable; if no, record the exemption
rationale. This prevents the feature-vs-tool drift where capabilities ship
unreachable by agents.

## Staleness Coverage

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


Before promoting brainstorm output into PRD, architecture, or implementation
planning, check open questions, risks, requests, tracking records, health
findings, stale request threads, and stale request transport for the same scope.

Open `BR-Q-*`, `BR-RISK-*`, stale `TRK-*`, stale `REQ-*`, and open `HLT-*`
items must be carried forward or explicitly recorded as follow-up.

Resolve, refresh, or supersede stale items only with evidence. If evidence is
missing, leave the item visible in the PRD, architecture, implementation plan,
request thread, health finding, or tracking state.

## Workflow

1. Identify source material: brainstorm notes, user requests, accepted
   `REQ-*`, existing docs, health findings, tracking records, and evidence.
2. If no stable brainstorm/source IDs exist, run `project-brainstorm` and
   capture `BR-REQ-*`, `BR-DEC-*`, `BR-Q-*`, and `BR-RISK-*` records.
3. Run `project-prd` to create or update canonical requirements, non-functional
   requirements, acceptance criteria, dependencies, and open questions.
4. Run `project-architecture` to map requirements into canonical components,
   interfaces, decisions, risks, and validation strategy.
5. Run `project-implementation-plan` to create canonical phases, tasks,
   validation checks, evidence expectations, tracking updates, and changelog
   proposals.
6. Run `project-traceability-sync` to update registries and forward maps.
7. Run `project-traceability-review` and report findings before claiming the
   planning chain is ready for implementation.

## Stage Readiness Checkpoints

Do not advance to the next artifact until the current one passes its readiness
check; a weak artifact must not be inherited downstream.

- **Brainstorm → PRD**: the problem, target users, and success criteria are
  captured with stable `BR-*` IDs and no unresolved blocking `BR-Q-*`.
- **PRD → Architecture**: every `PRD-REQ-*` is unambiguous, testable, and
  source-linked; acceptance criteria exist.
- **Architecture → Plan**: components, interfaces, key `ARCH-DEC-*`, risks, and a
  validation strategy each map back to a `PRD-*`.
- **Plan → Implementation**: each `IMP-TASK-*` cites `PRD-*` + `ARCH-*` and has an
  `IMP-VAL-*` / evidence expectation.

If a checkpoint fails, stay on the current stage (or open a `DBR-*`/`HLT-*` for
the gap) rather than advancing.

## Output

Lead with the current lifecycle stage and the next required artifact. Report:

- artifacts created or updated
- IDs carried forward from brainstorms, requests, tracking, and health
- traceability gaps fixed or remaining
- stale items resolved, refreshed, superseded, or kept as explicit follow-up
- whether implementation planning is allowed yet