pressure-test

星标14

分支0

更新时间2026年6月29日 22:23

Use when the user wants an existing plan attacked rather than built, they have a roadmap, plan, PRD, bet, or strategy and want you to find what's wrong with it before they commit. Triggers on any adversarial-critique intent: tear it apart, find the holes, poke holes, play devil's advocate, stress-test, pressure-test, challenge the assumptions, what are we missing / not seeing, where will this break, why might this fail, talk me out of this, red-team it. The defining signal is skeptical scrutiny of a decision the user is about to make. Surfaces thin evidence, hidden or unexamined assumptions, wrong scope, and drift, then returns blocking issues, suggestions, strengths, and a ready/needs-fixes/not-ready verdict. Do NOT use for generating new ideas, brainstorming directions, writing or updating a plan/PRD/roadmap, or reviewing metrics and status updates, this only critiques something that already exists.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

sparkline-ventures

sparkline-ventures/product-eval

打开 GitHub 仓库查看创作者相关仓库

下载

Pressure Test

Adversarial review of an existing plan, roadmap, PRD, bet, or strategy, find what's wrong before the user commits. This is critique pointed at a whole artifact: it runs the same independent adversarial engine, so there is one critic, not two.

Workflow

Take in the artifact and its supporting evidence/scores from .product-eval/<scope>/.
Run critique on it: the multi-lens panel (skeptical customer, competitor, CFO, engineer, contrarian, security) plus the critic-checklist.md checks (evidence→solution, solution→ship, cross-stage consistency) and a scope-mode recommendation (Expand / Hold / Reduce). Run it independently (a fresh-context subagent; a different model if available) so it does not rubber-stamp.
Hunt counter-evidence and force hidden assumptions into the open; check that metrics are not vanity and that success criteria are falsifiable.
Terminate each point as resolved / open (→ a gap routed to gather-evidence) / contested (→ logged dissent), never argue to consensus.

Output

Blocking issues (with fixes), suggestions, strengths, a scope-mode call, and an overall ready / needs fixes / not ready verdict. Append the findings to .product-eval/<scope>/decisions-log.md. Lead with the verdict and the blocking issues. End with Next move: and recommend fixing the blockers, writing the decision memo, making the build brief, or using critique if the artifact is only a finding/problem statement rather than a full plan.

同仓库更多 Skills

同仓库

calibrate

sparkline-ventures/product-eval

Tune and validate the scoring constants (evidence-weight base, diversity factors, gate threshold, crispness bars) against past decisions with known outcomes. Use when the user says "calibrate", "tune the thresholds", "validate the scoring", "the confidence numbers feel off", or has a set of past decisions to check the model against. Reports mismatches and recommended constant changes; never silently changes them.

2026-06-2914

critique

sparkline-ventures/product-eval

Use when someone wants existing thinking attacked, graded, or handed to fresh eyes, not written or summarized. The point is to break the artifact, not produce it. It owns three intents: a skeptical outside read of conclusions, findings, themes, a synthesis, a brief, or a FAQ, from someone who was not in the room; running those findings past hostile lenses (a wary customer, CFO, engineer, competitor) to see where they collapse; and grading a problem statement or one-liner (right altitude, names a real persona, or vague mush) with a score and what is missing. Reach for it on 'give this a fresh adversarial read', 'put this in front of a skeptical X', 'score how crisp this problem statement is', 'poke holes', 'red-team this'. Do not use it to create or restate the artifact. Attacking a whole plan, roadmap, or PRD routes through pressure-test; this skill owns findings, syntheses, problem statements, and panels.

2026-06-2914

decision-readiness

sparkline-ventures/product-eval

Judge whether there is enough evidence to make a build decision on a specific problem or bet, and return one of three outcomes: Decide now, Run a research sprint, or Do not commit yet. Use when the user asks "do we have enough data to decide?", "is this worth building?", "are we ready to commit to X?", "what's the evidence for this?", or "decision readiness". This is the core gate, Confidence band drives the decision; signal strength is assessed per evidence item.

2026-06-2914

design-test

sparkline-ventures/product-eval

Turn a "Run a research sprint" verdict (promising but under-evidenced) into the cheapest experiment that would close the gap, a concrete validating test with a hypothesis, method, sample, effort, and pass/fail threshold. Use when decision-readiness returns Run a research sprint, or when the user asks "how do we validate this", "what's the cheapest test", "how do we de-risk this bet", or has a promising idea with thin first-party evidence. Designs the test; its results feed back into gather-evidence. Do NOT use to pull existing data (that is gather-evidence) or to judge sufficiency (that is decision-readiness).

2026-06-2914

discover-sources

sparkline-ventures/product-eval

Map what product-data sources a user can draw on, connectors, tools, files, offline systems, and the decision-confidence ceiling those sources allow. Use when the intent is discovery and setup of the evidence base itself: "what data do I have / could connect", "scan/inventory my sources", "is X hooked up", "where could product insights come from", "how confident could any decision be given my data", or starting a new project before any framing or prioritizing. Do NOT use when the user wants you to actually work the data they already have, pulling, summarizing, grading, or reporting on tickets, reviews, surveys, metrics, scorecards, or trends. Those are analysis and reporting tasks, not source discovery. The trigger is "what evidence exists and how good can it get," not "analyze the evidence." Produces a source map plus a confidence ceiling.

2026-06-2914

drift-check

sparkline-ventures/product-eval

Compare an investigation's CURRENT state against an EARLIER SNAPSHOT of itself and report what moved between those two points in time: problem-statement drift, evidence added or retired, Value/Confidence score movement, theme or narrative reframing, and whether confidence is genuinely accumulating or just churning. Use when the user says "what changed since last month", "has this drifted", "compare this to the prior version", "is the confidence trajectory improving", or wants to audit a scope before re-deciding. Reads scoped snapshots and git history and runs the cross-stage consistency checks. Do NOT use for finding patterns or trends WITHIN the current evidence set, that is synthesize; nor for reviewing a product-metrics dashboard, that is a metrics review. This is specifically a then-vs-now diff of the investigation. No daemon; runs on demand or on a schedule.

2026-06-2914

name

pressure-test

description

Pressure Test

Workflow

Take in the artifact and its supporting evidence/scores from .product-eval/<scope>/.
Run critique on it: the multi-lens panel (skeptical customer, competitor, CFO, engineer, contrarian, security) plus the critic-checklist.md checks (evidence→solution, solution→ship, cross-stage consistency) and a scope-mode recommendation (Expand / Hold / Reduce). Run it independently (a fresh-context subagent; a different model if available) so it does not rubber-stamp.
Hunt counter-evidence and force hidden assumptions into the open; check that metrics are not vanity and that success criteria are falsifiable.
Terminate each point as resolved / open (→ a gap routed to gather-evidence) / contested (→ logged dissent), never argue to consensus.