# Pressure Test Plan > Pressure-test a drafted plan before you execute it: interview for missing context, run a multi-lens review panel, rewrite the plan stronger, and ALWAYS finish with a calibrated confidence scorecard (1-100) plus a ranked, actionable path to raise it. Use when the user has written or pasted an implementation, build, or project plan and wants feedback before executing — triggers include "pressure-test this plan", "review this plan", "give me feedback on this plan", "poke holes in this", "what are we missing", "find the edge cases", "simplify this", "how confident are you in this plan", "score this plan", or pasting a plan alongside a request for gaps, risks, or a confidence score. Runs a panel of reviewers, gathers missing context interactively, produces an updated self-contained plan, and scores it on six equally-weighted dimensions with blockers and a concrete path to a higher score. - Skill: `dannyjpwilliams/pressure-test-plan` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add dannyjpwilliams/pressure-test-plan` - Raw SKILL.md: https://api.skillmd.com/api/skills/dannyjpwilliams/pressure-test-plan/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: dannyjpwilliams (https://skillmd.com/u/dannyjpwilliams) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dannyjpwilliams/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. | # | Dimension | What it measures | |---|-----------|------------------| | 1 | **Goal Fit** | Executing the plan produces *exactly* the envisioned result — not a proxy, not an adjacent thing. | | 2 | **Completeness & Clarity** | Self-contained and unambiguous; a fresh model could execute it without guessing. | | 3 | **Correctness & Edge Cases** | The approach is technically sound; boundary, empty/null, failure, and data conditions are handled. | | 4 | **Simplicity & Elegance** | The leanest path to the goal; no unnecessary abstraction, moving parts, or reinvention. | | 5 | **Risk & Sequencing** | Steps are ordered safely; the riskiest parts are de-risked; rollbacks/checkpoints exist for irreversible actions. | | 6 | **UX & Product Impact** | The result actually serves the end user; key states (loading, empty, error, permission) are covered. N/A for non-user-facing plans. | **Calibration anchors (for the composite and for each dimension):** | Range | Meaning | |-------|---------| | 95-100 | Complete and unambiguous; assumptions verified or trivially safe; no open questions of consequence. Rare on a first pass. | | 85-94 | Strong; only minor unknowns or low-risk assumptions; very likely to produce the intended result with small course-corrections. | | 70-84 | Solid direction, but real open questions or unverified assumptions remain that could still change the approach. | | 50-69 | Workable but meaningful gaps — missing edge cases, unclear sequencing, or untested assumptions that materially threaten the outcome. | | <50 | Significant ambiguity or risk; needs substantial rework before execution. | 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.