Pressure Test Plan

Pressure Test Plan

Take a drafted plan, pressure-test it from several angles, fill the gaps with the user, rewrite it stronger, and score how confident you are that it will produce exactly what the user envisions — plus exactly what would raise that score.

The score and the path to raise it are the product. The interview, the review panel, and the rewrite all exist to earn and improve that number. This automates a manual loop: instead of the user pasting a plan into one fresh model after another, this skill runs a panel in one pass, gathers missing context interactively, and returns an improved plan plus an honest, defensible scorecard the user can feed onward to loop again.

The output contract (non-negotiable)

Every run ends with these three, no matter how the interactive steps go:

1. The scorecard — six dimensions each scored 1-100, plus the equal-weight composite (1-100).
2. Blockers — the specific unknowns, risks, and unverified assumptions holding the composite below 100.
3. Path to a higher score — a ranked, actionable list; each item names the action, the dimension(s) it lifts, and the rough point gain.

A fourth thing is just as non-negotiable, and it is a process guarantee, not a deliverable: if the panel (Step 4) raises any open question — BLOCKING or MINOR — you ask the user via AskUserQuestion before rewriting. This is not conditioned on whether the user generally likes being asked questions — it's conditioned on whether the panel actually raised something worth asking. A general "don't ask me questions" preference does not suppress a real panel-raised question (see Notes); only declining to answer a specific question, once asked, does.

You never end a run without producing the three guaranteed outputs. If the user disengages or declines to answer a question after being asked — score with what you have and convert every open question into a blocker plus a path item. An unanswered question never kills the score; it becomes the path to a higher one.

Workflow

Run these steps in order. Tell the user which step you're on with short status lines.

1. Locate the plan and the goal

Find the plan in this priority order: pasted inline in the message → a file the user names → the most recent plan produced earlier in the conversation. If no clear plan exists, ask for it and stop.

Identify the goal — what the plan is ultimately trying to build or achieve. If the intended end result isn't stated, that is your first interview question (Step 3); the score is meaningless without knowing what "exactly what the user envisions" means.

2. Decide grounding (auto-detect)

Determine whether the plan targets the current codebase:

• Signals it does: it references real file paths, modules, functions, routes, or frameworks that exist in the working directory; cwd is a git repo whose code matches the plan's language.
• If yes → ground it: read the files, functions, and interfaces the plan touches and check its factual assumptions — does this API/function/route actually exist? Is the described current behavior accurate? Are the dependencies present? For anything beyond a couple of files, spawn an Explore subagent so the main context stays clean, and have it return concise findings.
• If greenfield, a different project, or no repo → standalone: review the plan on its internal logic alone, and note explicitly that code-level assumptions could not be verified.

State which mode you're in ("Grounding against the current repo" vs "Reviewing as standalone text"). The scorecard carries this stamp — a standalone score is inherently softer because assumptions are unverified, and the user needs to know that.

3. Upfront interview (gather context before the panel)

Interview the user for the context the reviewers need to do their best work: the goal / definition of done, hard constraints, priorities, and any ambiguity about what the finished result must be. This is deliberately before the panel so the reviewers work with full context.

• Default to AskUserQuestion for everything, including questions that feel open-ended. Draft 2-4 concrete, plausible options grounded in the plan — the built-in "Other" free-text choice covers anything you didn't anticipate. Batch up to 4 questions per call.
• Only fall back to plain prose when no plausible option set exists at all (e.g. "paste the brand voice doc this needs to match") — that should be rare.
• Keep it lean. Ask only what genuinely shapes the review — do not manufacture filler questions. This governs which questions you draft, not whether you use the tool once you have one.
• If the user declines a specific question or says "just assume," record the explicit assumption you'll proceed with rather than silently guessing, and move on.

4. Run the review panel

Read references/review-lenses.md for the per-lens reviewer prompts, the dimension each owns, and how to fill the shared context block.

Spawn the reviewers in parallel — one message, multiple Agent/Task calls — each given the full plan, the stated goal, the Step 2 grounding findings, and the Step 3 interview answers. The six scored lenses (one per scorecard dimension):

1. Goal Fit
2. Completeness & Clarity
3. Correctness & Edge Cases
4. Simplicity & Elegance
5. Risk, Failure Modes & Sequencing
6. UX & Product Impact

Each reviewer returns: the strongest parts (so a rewrite doesn't break what works), specific findings, its open questions — each marked BLOCKING or MINOR and carrying 2-4 plausible answer options (exact format in review-lenses.md) so Step 5 can turn them straight into AskUserQuestion calls — and a 1-100 score for its dimension with a one-line justification. Also run the Scope, Effort & Estimation advisory lens for large or multi-phase plans — it contributes findings only, not a scored dimension.

If a dimension genuinely does not apply (e.g. UX for a pure backend data migration), mark it N/A and exclude it from the composite rather than inventing a score.

5. Synthesize, then ask the user (guaranteed check-in, uncapped follow-up)

Merge the panel outputs: dedupe overlapping points (multi-lens agreement is a strong signal a finding is real), and where reviewers disagree, surface the disagreement explicitly — that tension is signal, not noise. Merge the open questions per review-lenses.md's "Synthesizing the panel," which also covers turning the merged list directly into AskUserQuestion batches.

The merged list is a trigger, not a menu: if it's non-empty, you ask — full stop. This holds even if the user said earlier not to bother asking questions; it does not hold if the panel genuinely found nothing to ask (see below).

• Lead with BLOCKING questions (the answer changes the approach), then MINOR ones.
• Do not cap the number of questions or rounds. If the panel surfaced ten things worth clarifying, ask them, in as many AskUserQuestion batches as it takes (4 per batch).
• "Quality over quantity" governs which MINOR questions survive the dedupe/merge, not whether the tool fires once something survives. Any surviving BLOCKING question is always asked.
• If the user declines a specific question or says "just proceed," record the explicit assumption — it becomes a blocker and a path item, never a silent guess.

If the merged list is empty, there's nothing to ask — move straight to the rewrite. Trust the panel's own framing: a dimension scoring below 95 without an explicit open question is a finding, not a withheld question, and it already becomes a blocker and a path item in Step 7.

Don't move on until the consequential questions are answered or the user tells you to proceed.

6. Produce the updated plan

Rewrite the plan, incorporating the accepted panel improvements and the user's answers. Requirements:

• Self-contained — complete enough to hand to another model for a fresh pass with no extra context.
• Preserve what worked — keep the union of every lens's "strongest parts" intact.
• End with a short "What changed and why" summary so the user can mentally diff it against their draft.

7. Score the updated plan (the guaranteed terminal output)

Score the updated plan (not the original) using the scorecard below. Output, in this order:

1. Scorecard table — each of the six dimensions: its 1-100 score, a one-line "why", and the single biggest lever to raise it. Mark any N/A dimension.
2. Composite — the equal-weighted mean of the applicable dimensions, 1-100, tagged with the grounding mode (code-verified vs standalone) and mapped to the calibration band.
3. Blockers — the specific unknowns, risks, and unverified assumptions below 100, including every question the user skipped or deferred.
4. Path to a higher score — ranked by impact (lowest dimensions and BLOCKING gaps first). Each item: the concrete action → which dimension(s) it lifts → rough point gain → who decides or verifies it.

If you scored an earlier version of this plan in the conversation, show the movement — per-dimension and composite (e.g. Risk 62 → 81, Composite 71 → 86). Equal weights make passes directly comparable.

Be calibrated and honest. An inflated score defeats the entire purpose. Tie every number to concrete findings, not to a vibe — each dimension score must be defensible from its reviewer's justification.

8. Offer to loop

The updated plan is portable by design. Offer to run another panel pass on it, or hand it to the user to take to a different model — mirroring how they loop reviews manually. Because the scorecard is comparable across passes, each loop shows measurable movement toward 100.

Scorecard

Six dimensions, scored 1-100 each, weighted equally. Composite = mean of the applicable dimensions (exclude any marked N/A and re-normalize). Each dimension is owned by one panel reviewer.

Calibration anchors (for the composite and for each dimension):

100 means zero remaining uncertainty that the plan produces exactly the envisioned result, to the detail. Most good-but-not-perfect plans land in the 70-90 band even after a strong pass. A standalone (non-code-verified) plan should rarely score above 90 — unverified assumptions cap Correctness and Completeness.

Notes

• The contract holds even under pressure. If the conversation runs long, gets redirected, or the user bails on questions, you still close with the scorecard, blockers, and path. Never trail off without the score.
• A general "don't ask me questions" preference does not preempt the guaranteed check-in. Asking exists to make the score honest, not to be configured away in advance — if the panel raises a real BLOCKING or MINOR question, ask it. What does apply: if the user declines to answer a specific question once it's actually asked, or says "just assume" mid-round, record the assumption and move on — that's a live decline, not a preemptive skip.
• Keep the panel lean — reviewers use the grounding and interview answers you already gathered rather than each re-exploring the repo. Only have a reviewer request specific file reads when its lens genuinely needs detail the grounding pass didn't capture.
• The strongest signal a finding is real is multiple lenses raising it independently. Weight those heavily in both the rewrite and the scoring.