# Strategy Red Team

Red-team a PRD, roadmap, or strategy by attacking its load-bearing assumptions before...

- Repository: https://github.com/phuryn/pm-skills (27597 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-10-29
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add phuryn/pm-skills --skill strategy-red-team -g -a claude-code -y`
Codex: `npx skills add phuryn/pm-skills --skill strategy-red-team -g -a codex -y`
Cursor: `npx skills add phuryn/pm-skills --skill strategy-red-team -g -a cursor -y`
Gemini CLI: `npx skills add phuryn/pm-skills --skill strategy-red-team -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add phuryn/pm-skills`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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.

The rest: https://github.com/phuryn/pm-skills/blob/HEAD/pm-execution/skills/strategy-red-team/SKILL.md