prayog-skills

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.

Execute the per-wave implementation loop: implement against spec, run verification, fix failures, repeat until green — then stop and request human checkpoint. Use during active wave development. Stops at human checkpoint; does not advance to the next wave.

Validates requirements documents using 15 checks across 2 dimensions: semantic accuracy (11 checks — source truth, inference detection, requirement purity, over-generalization, scope boundaries, testability, ambiguity, assumption dependencies, negative paths, actor capability, intra-document consistency) and structural integrity (4 checks — staleness, contradictions, cross-references, completeness). Supports incremental mode: when a prior validation report is provided, only re-runs checks whose inputs have changed, carries forward findings that remain valid, and detects resolved findings — cutting re-validation effort by 40-60%. Produces a unified report with clear Semantic vs Structural grouping. Use after generating requirements, before sharing with stakeholders, when suspecting inaccuracies, or as a periodic quality sweep.

Define or run live verify discipline for a feature — one live-verify artifact per product area, no overlap with unit tests. Use when finishing a slice, adding live-verify tests, or when asked what command proves the feature on a running stack.

Interactively walks users through findings from any audit or validation report (validate-requirements, document-audit, or future skills). Reads the report file, detects its format, presents findings via AskQuestion for user decisions, and produces a resolution summary. Use after any skill that generates a findings report, or standalone against any structured findings markdown file.