strategy-red-team
Skill2 starsChanged 22 days agoMITView on GitHub
Red-team a PRD, roadmap, or strategy by attacking its load-bearing assumptions before reality does. Steelmans then attacks each claim, ranks failure modes by impact × likelihood × cheapness-to-test, and returns the cheapest test and kill criteria for each. Use when stress-testing a plan, pressure-testing a strategy, challenging assumptions, or preparing a doc for executive review.
5 other projects use a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- daviszhen/agent-skillsword for word, first seen Oct 25, 2026
- Usermuse/em-pluginedited, first seen Jul 31, 2026
- Adhamxon/claude-code-skillsword for word, first seen Jul 30, 2026
- maeng777/claude-skillsword for word, first seen Jun 19, 2026
- miovrag/claude-skillsword for word, first seen Jun 12, 2026
Other versions5 projects use a version of this.
Word for word · 4
- Adhamxon/claude-code-skills★ 2100% same
- daviszhen/agent-skills★ 1100% same
- miovrag/claude-skills★ 1100% same
- maeng777/claude-skills★ 0100% same
Edited · 1
- Usermuse/em-plugin★ 013% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository100 other files it gives its agents.
- ab-test-analysisSkill
- analyze-feature-requestsSkill
- ansoff-matrixSkill
- api-and-interface-designSkill
- beachhead-segmentSkill
- brainstorm-experiments-existingSkill
- brainstorm-experiments-newSkill
- brainstorm-ideas-existingSkill
- brainstorm-ideas-newSkill
- brainstormingSkill
- brainstorm-okrsSkill
- browser-testing-with-devtoolsSkill
- business-modelSkill
- ci-cd-and-automationSkill
- code-review-and-qualitySkill
- code-simplificationSkill
- cohort-analysisSkill
- competitive-battlecardSkill
- context-engineeringSkill
- customer-journey-mapSkill
- debugging-and-error-recoverySkill
- define-hypothesisSkill
- define-jtbd-canvasSkill
- define-opportunity-treeSkill
- define-problem-statementSkill
- deliver-acceptance-criteriaSkill
- deliver-edge-casesSkill
- deliver-prdSkill
- deprecation-and-migrationSkill
- develop-solution-briefSkill
- discover-competitive-analysisSkill
- discover-interview-synthesisSkill
- discover-market-sizingSkill
- document-architectureSkill
- documentation-and-adrsSkill
- draft-ndaSkill
- dummy-datasetSkill
- frontend-ui-engineeringSkill
- git-workflow-and-versioningSkill
- grammar-checkSkill
- growth-loopsSkill
- gtm-motionsSkill
- gtm-strategySkill
- ideal-customer-profileSkill
- identify-assumptions-existingSkill
- identify-assumptions-newSkill
- incremental-implementationSkill
- intended-vs-implementedSkill
- interview-meSkill
- interview-scriptSkill
- job-storiesSkill
- lean-canvasSkill
- marketing-ideasSkill
- market-segmentsSkill
- measure-experiment-designSkill
- metrics-dashboardSkill
- modern-web-guidanceSkill
- monetization-strategySkill
- north-star-metricSkill
- observability-and-instrumentationSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 20
Extract every claim: Read the plan and list what it asserts as true — about the user, the market, the constraint, the mechanism, the …
- Distinctive: line 60
No strawmanning — attack the steelman or don't attack.
- Distinctive: line 61
No generic risk lists — every item must be specific to *this* plan.
- Distinctive: line 62
No fabrication — if it's sound, say so.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
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
- 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
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

