PRD Review Gate

The stress-test is not optional and not a step you pass once — it is a gate the PRD must clear before the pipeline advances. A drafted PRD (artifacts/prd.md) is not an approved PRD. This skill runs the PRD Review Panel against it and records the outcome so that no PRD reaches system design without having faced independent criticism.

The gate contract: advisory-with-override

This gate does not hard-block (that would lock a solo founder out of their own pipeline). It is advisory-with-override, which means all three of these are true at once:

1. The panel always runs. You cannot reach the competitive step without the panel having executed against the current PRD. Skipping is not available.
2. go passes silently. No unresolved S1 findings of confidence medium+ — the gate returns go, writes the review artifact, and the pipeline advances. Nothing to override.
3. Anything else requires a per-finding override to proceed. A no-go or go-with-conditions (i.e. unresolved S1/S2 findings) does not stop you — but to advance you must, for each blocking finding, record an override: the finding id and a one-line reason for proceeding despite it. Overrides are per-finding, never global ("override the whole review" is not permitted — that would defeat the gate). The override is cheap to do and impossible to do invisibly.

The single hard stop (not overridable): I1 — material too thin to review. If the PRD is below the reviewable threshold, the panel cannot run and there is nothing to override; fix the PRD first. "There is nothing to review" is not a judgment call.

Conventions

Follow _conventions.md (read-first order, docs/ vs artifacts/, don't-clobber guard).

Before you start

Read PROJECT.md and artifacts/prd.md. If artifacts/prd.md does not exist, stop and run agent-prd first — there is nothing to gate. Gather any discovery material referenced by the PRD (interview notes, data) as the panel's second input.

How to run the panel — script if it exists, else skill

Check for the orchestrator script first, in this order:

• assets/run_panel.py (bundled with this skill), or
• a path named in PROJECT.md under prd_review.orchestrator.

If the script exists — script mode (preferred). Invoke it with the PRD + discovery. It runs the real graph: parallel blind-pass critics (true independence — separate calls that cannot see each other), the informed revision pass, the consolidator's code-side evidence verification, and the judge. It writes the full per-finding output and appends to the ledger. This is the rigorous mode; the blind pass is genuine.

If no script — skill mode (fallback). Walk the personas in this session, in the panel's defined order (blind critics first, then inversion-informed revision, then synthUser → flowWalk → consolidator → judge). Record in the review artifact that this was skill mode, with the caveat: within a single context the blind pass is not truly blind — the personas share this conversation, so independence is weaker and correlated-consensus is more likely. Treat skill-mode [independent x N] counts with suspicion. Skill mode is a valid degraded fallback, not the target; note it so the reader knows which rigor produced the review.

Either way, the panel's personas, finding schema, severity rubric (S1/S2/S3), evidence rules (verbatim-quote-or-declared-absence), and blind→informed structure are defined in the PRD Review Panel — Spec v2 (the authoritative persona/schema reference). This skill governs the gate behavior; the spec governs the panel behavior.

Steps

1. Load & validate. Read the PRD + discovery. If below the reviewable threshold — I1 hard stop: tell the user the PRD is too thin to review, name what's missing, do not proceed. (This is the only non-overridable outcome.)
2. Run the panel (script or skill mode per above). Produce the consolidated findings and the judge's verdict + decision (go | no-go | go-with-conditions) + ranked_fixes.
3. Apply the gate:
   • go — write the review artifact, advance. Done.
   • no-go / go-with-conditions — present the blocking findings (unresolved S1s, and S2s the judge named as conditions) to the user. For each, the user either resolves it (revise the PRD — send back to agent-prd, then re-run this gate) or overrides it (records a reason). You may not advance while a blocking finding is neither resolved nor overridden.
4. Record overrides to the ledger. For every overridden finding, append an override record (see schema below). This is the Recourse-and-Evidence trail — every proceed-despite decision is on the record and queryable later.
5. Write the review artifact and, only once all blocking findings are resolved-or-overridden, clear the pipeline to advance to the competitive step.

Override record (appended to the ledger)

{
  "run_id": "uuid",
  "prd_version": "hash or artifacts/prd.md mtime",
  "finding_id": "cfo-002",
  "finding_severity": "S1",
  "finding_claim": "<the claim being overridden>",
  "override_reason": "one line: why we proceed despite this",
  "mode": "script | skill",
  "timestamp": "ISO-8601",
  "decided_by": "<user>"
}

One record per overridden finding. A run that advanced on go has zero override records (nothing was overridden) but still logs the run itself. A run advanced with overrides is permanently marked as such.

Output

• Write artifacts/prd-review.md: the mode used (script/skill), the judge's verdict + decision, the ranked findings (each with severity, confidence, origin, evidence), and — clearly sectioned — which findings were resolved (PRD revised) vs. overridden (with reasons).
• Append run + any override records to the ledger (path per PROJECT.md, default artifacts/prd-review-ledger.jsonl).
• Apply the don't-clobber guard; a re-run after a PRD revision writes a new dated review, it does not silently replace the prior one (the history of what was flagged and overridden is itself the audit trail).

End by stating: the decision (go/overridden/sent-back), how many findings were overridden and why in one line each, which mode produced the review (and if skill mode, the independence caveat), and confirmation that the pipeline is now cleared — or not — to advance to the competitive step.

The one thing to watch

Skill mode can quietly become the default if the script is never built, and skill mode's weaker independence is exactly the failure the panel was designed to avoid. Track in the ledger what fraction of gate runs used skill vs. script mode; if skill mode dominates, that's the signal to finish the orchestrator script — the gate is only as rigorous as the mode it actually runs in.