Strategy Red Team
Pawel HurynCommunityCreated by Pawel Huryn
- Skill
- Review and audit
- Business and productivity
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
Strategy Red-Team provides a structured approach to pressure-testing PRDs, roadmaps, and business strategies. Rather than generating generic risk lists, it forces an adversarial review of load-bearing assumptions. By steelmanning each claim before attacking it, the skill ensures that feedback is grounded in the plan's actual logic. It culminates in a prioritized list of failure modes, ranked by impact, likelihood, and the ease of testing, providing actionable kill criteria and the smallest possible experiments to validate or invalidate the strategy before significant resources are committed.
What it does
- Extracts and isolates load-bearing assumptions from strategic documents.
- Applies a steelman-then-attack methodology to ensure fair and rigorous critique.
- Defines concrete, falsifiable failure conditions for each critical assumption.
- Ranks risks based on impact, likelihood, and the cost of testing.
- Provides specific, actionable experiments and kill criteria for high-priority risks.
- Identifies well-reasoned components of the plan to balance critique with validation.
When to use it
- Before presenting a PRD or roadmap to executive leadership.
- When you need to stress-test a strategic bet to avoid shipping the wrong product.
- During the planning phase to identify which assumptions require immediate validation.
- When a team feels overconfident in a plan and needs an objective, adversarial perspective.
Advantages
- Focuses on high-impact, testable assumptions rather than generic risk lists.
- Reduces the fear of shipping the wrong bet by providing clear kill criteria.
- Encourages evidence-based decision making through small, cheap experiments.
- Prevents strawman arguments by requiring a steelman of the original claim first.
Usage examples
- “Red-team this PRD for our new mobile subscription feature.”
- The agent will analyze the PRD, identify the core assumptions about user willingness to pay, rank the failure modes, and provide a list of cheap tests to validate the subscription model.
- “I have a Q3 product roadmap. Can you challenge my assumptions?”
- The agent will break down the roadmap's claims, identify which ones are load-bearing, and suggest specific data points or conversations to gather this week to confirm the plan's viability.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/phuryn/strategy-red-team/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip strategy-red-team.zip -d .agents/skills
Documentation by Pawel Huryn
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
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.
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.
Write each failure mode as "Fails if ___." Be concrete and falsifiable. "Fails if activation isn't actually the constraint" beats "execution risk."
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.
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.
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
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.
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
Files
- ATTRIBUTION.mdAdded by AutoGineer866 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md4.4 KiB
SKILL.md
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
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.
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.
Write each failure mode as "Fails if ___." Be concrete and falsifiable. "Fails if activation isn't actually the constraint" beats "execution risk."
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.
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.
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
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.
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
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- Pawel Huryn
- Publisher
- Pawel Huryn (Community)
- Source
- phuryn/pm-skills · pm-execution/skills/strategy-red-team · commit 2a12295
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Pawel Huryn.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download strategy-red-team.zip