
Strategy Red Team
- 994 installs
- 24.9k repo stars
- Updated July 3, 2026
- phuryn/pm-skills
strategy-red-team is an agent skill that adversarially reviews PRDs, roadmaps, and strategy documents for developers and PMs who need to kill weak assumptions before executive review or engineering kickoff.
About
strategy-red-team is an agent skill from phuryn/pm-skills that adversarially reviews PRDs, roadmaps, and strategy documents before polite feedback lets bad plans survive. The skill steelmans then attacks each load-bearing claim, ranks failure modes by impact × likelihood × cheapness-to-test, and returns the cheapest validation experiment plus explicit kill criteria for every assumption. Developers and engineering leads reach for strategy-red-team when stress-testing a plan, pressure-testing a strategy, challenging roadmap assumptions, or preparing a document for executive review. The workflow produces ranked failure modes and actionable test plans rather than generic critique. Trigger phrases include red-team this PRD, pressure-test this strategy, and challenge these assumptions. The skill fits early validate-stage planning when scope decisions still have low reversal cost.
- strategy-red-team
Strategy Red Team by the numbers
- 994 all-time installs (skills.sh)
- +97 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #400 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/phuryn/pm-skills --skill strategy-red-teamAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 994 |
|---|---|
| repo stars | ★ 24.9k |
| Last updated | July 3, 2026 |
| Repository | phuryn/pm-skills ↗ |
How do you red-team a PRD before engineering starts?
Use strategy-red-team for development tasks
Who is it for?
Engineering leads and PMs preparing PRDs, roadmaps, or strategy docs for executive review who need adversarial assumption testing—not polite feedback.
Skip if: Teams seeking implementation guidance, code review, or technical architecture design rather than strategic assumption validation.
When should I use this skill?
The user asks to red-team, pressure-test, or challenge assumptions in a PRD, roadmap, strategy doc, or executive planning document.
What you get
Ranked failure modes per assumption with impact × likelihood × cheapness scores, cheapest validation tests, and explicit kill criteria.
- Ranked failure mode analysis
- Cheapest-test recommendations with kill criteria
By the numbers
- Ranks failure modes across three dimensions: impact, likelihood, and cheapness-to-test
Files
Strategy Red-Team: Attack the Assumptions Before Reality Does
Purpose
You are a sharp, fair adversary reviewing $ARGUMENTS. Most plans only survived polite feedback. This skill finds the load-bearing assumptions that would make the plan fail, attacks them honestly, and returns — for each — the evidence to get this week, the kill criteria, and the cheapest test.
Context
A red-team is not a pre-mortem. A pre-mortem imagines the plan already failed and narrates why. A red-team attacks the load-bearing assumptions and logic now, while there's still time to test the cheapest one. It improves judgment, not just confidence.
The goal is a sharper decision, not a longer risk list. Five real kill-assumptions with tests beat twenty generic risks.
Instructions
1. Extract every claim. Read the plan and list what it asserts as true — about the user, the market, the constraint, the mechanism, the timeline. Separate load-bearing claims (if false, the plan dies) from cosmetic ones. Only load-bearing claims are worth attacking.
2. Steelman, then attack. For each load-bearing claim, first state the strongest version of why it might be true. Then attack that — not a strawman. An attack on a weak version of the claim is worthless.
3. Write each failure mode as "Fails if ___." Be concrete and falsifiable. "Fails if activation isn't actually the constraint" beats "execution risk."
4. Rank by (impact if wrong) × (likelihood wrong) × (cheapness to test). The top of the list is what to test this week — high-impact, plausibly wrong, and cheap to check. Surface that ranking; don't bury the lede.
5. Self-refute, don't fabricate. Default to "this risk is real" unless the plan already cites evidence against it. But if a claim is genuinely well-reasoned, say so plainly — a red-team that manufactures doubt is as useless as one that rubber-stamps. Never invent a weakness the plan doesn't have.
6. For each surviving kill-assumption, give the operator something to do:
- Fails if: the precise condition that breaks the plan
- Evidence to get this week: the specific data, query, or conversation that would confirm or kill it cheaply
- Kill criterion: the threshold at which you'd stop or change course
- Cheapest test: the smallest experiment that moves the belief
7. Optional cross-model mode. If the user asks for a second opinion and another model (Codex, Gemini, a second Claude) is reachable, run the same plan through it and flag where the two disagree — different model families miss different things. Default is single-model; don't add this friction unless asked.
8. Structure the output (make it screenshot-native):
## Red-Team: [plan in one line]
### Top Kill-Assumptions (ranked)
For each (3–5 max):
- **Claim:** [the load-bearing assertion]
- **Fails if:** [concrete, falsifiable condition]
- **Evidence to get this week:** [specific]
- **Kill criterion:** [threshold]
- **Cheapest test:** [smallest experiment]
### What's Well-Reasoned
[State explicitly what holds up — and why. Don't manufacture doubt.]
### What I Couldn't Assess
[Gaps where the plan didn't give enough to judge.]Notes
- No strawmanning — attack the steelman or don't attack.
- No generic risk lists — every item must be specific to this plan.
- No fabrication — if it's sound, say so.
- Rank ruthlessly — the cheapest high-impact test is the whole point.
- The emotional job is relief from the fear of confidently shipping the wrong bet, so end with what to do, not just what to fear.
---
Further Reading
Related skills
How it compares
Pick this over generic planning skills when the deliverable must be ranked assumption failures with explicit kill criteria—not feature brainstorming.
FAQ
What documents does strategy-red-team review?
strategy-red-team adversarially reviews PRDs, roadmaps, and strategy documents. The skill attacks load-bearing assumptions in planning docs, ranks failure modes, and returns the cheapest test and kill criteria for each claim before executive review.
How does strategy-red-team rank risks?
strategy-red-team ranks failure modes by impact × likelihood × cheapness-to-test. For each assumption, the skill steelmans the claim, attacks it honestly, and outputs the cheapest validation experiment plus explicit kill criteria.
When should an agent invoke strategy-red-team?
strategy-red-team fits stress-testing plans, pressure-testing strategies, challenging assumptions, or preparing docs for executive review. Trigger when the user wants adversarial critique—not implementation help or code review.