After the dev team has written their spec slice from the PRD, review it against the current codebase — baseline, gaps, impact, test harness, architecture governance (ADR + MDC), risks, and 4-lane triage. Use when the dev has drafted the spec and wants to check buildability before technical review and planning. Runs while the spec PR is open.
Before implementing one wave slice, produce a pre-flight checklist: verify the prior wave's human gate is satisfied, confirm contracts consumed from prior Ground Reports match what was actually built, then read specs/ADRs/rules. Use when starting implementation, opening a branch, or asked what to read before coding.
After feasibility (and technical review when applicable), produce a wave-level implementation plan with REQ/TASK/FILE/TEST tables and a WorkManifest YAML seed section (§9). Runs while the spec PR is open, before spec merge. Board seeding (gh issue create) happens after spec PR merge — not before.
After feasibility, produce a principal-engineer design document: resolve all engineering decisions (ADRs, interface contracts, test policy, module boundaries), draft any required ADRs, and route only true product questions back to PM on the meta PRD PR. Use before /spec-implementation-plan when the feasibility report contains NEW-ADR findings, Critical/Should-fix engineering items, or unclear module boundaries. TDD commits on the spec PR branch; PE gives GitHub Approve on the same spec PR.
Translate the PRD into a spec slice for this repo. Reads the PRD from the meta PRD PR branch or merged develop, extracts capabilities relevant to this repo, and drafts docs/specification/product/INIT-*.md. Use after engineering opens the spec PR and before /initiative-feasibility.
Map a PRD to affected repos using the service catalog. Reads the PRD and config/service-catalog.yaml from <client>-meta, matches PRD capabilities to service descriptions, and posts an impact map as a PR comment on the meta PRD PR for tech lead confirmation. Run in <client>-meta Cursor session after PRD is validated and before engineering opens spec PRs in app repos.
Propagates corrections, new information, terminology changes, and scope changes across multiple related documents. Structures changes, verifies with user, performs impact analysis, presents a change manifest for approval, applies edits preserving each document's format and tone, and runs document-audit as a final consistency check. Use when a fact, assumption, or decision changes and multiple documents need updating, or when new information (e.g., from a design review, stakeholder feedback, or discovery session) must be reflected across a document set.
Validate a completed wave implementation against its product spec FRs, repo artifacts, and cross-spec contracts. Produces a Ground Report including a Contracts Produced section that is the required input for pre-implement of the next wave. Use when a wave claims complete, before human checkpoint, or when asked to ground a spec.