strategy-red-team

작성자: phuryn

PRD, 로드맵, 또는 전략을 리드팀(red-team) 방식으로 검토하여, 현실이 그 전제를 무너뜨리기 전에 핵심 가정을 공격합니다. 각 주장을 스틸맨(steelman) 방식으로 정리한 뒤 공격하고, 실패 모드를 영향력 × 발생 가능성 × 테스트 비용으로 순위를 매긴 후, 각각에 대한 최저 비용 테스트와 킬 기준을 반환합니다. 계획을 스트레스 테스트하거나, 전략을 압박 테스트하거나, 가정에 도전하거나, 경영진 검토용 문서를 준비할 때 사용하세요.

npx skills add https://github.com/phuryn/pm-skills --skill strategy-red-team

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

phuryn의 다른 스킬

create-prd
phuryn
8개 섹션으로 구성된 포괄적인 템플릿을 사용하여 제품 요구사항 문서를 작성합니다. 문제, 목표, 세그먼트, 가치 제안, 솔루션, 출시 계획을 다룹니다. PRD 작성, 제품 요구사항 문서화, 기능 사양 준비, 기존 PRD 검토 시 사용합니다.
prioritization-frameworks
phuryn
9가지 우선순위 결정 프레임워크에 대한 참조 가이드로, 공식, 사용 시기 안내, 템플릿을 포함합니다 — RICE, ICE, Kano, MoSCoW, Opportunity Score 등. 우선순위 결정 방법을 선택하거나 RICE 대 ICE 같은 프레임워크를 비교하거나 다양한 우선순위 접근 방식이 어떻게 작동하는지 배울 때 사용합니다.
outcome-roadmap
phuryn
출력 중심 로드맵을 전략적 의도를 전달하는 결과 중심 로드맵으로 전환합니다. 이니셔티브를 사용자 및 비즈니스 영향력을 반영한 결과 명제로 재작성합니다. 결과 중심 로드맵으로 전환하거나, 로드맵을 더 전략적으로 만들거나, 기능 목록을 결과물로 재작성할 때 사용하세요.
project-managementcommunication
pre-mortem
phuryn
PRD 또는 출시 계획에 대한 사전 치명적 위험 분석을 실행합니다. 위험을 호랑이(실제 문제), 종이 호랑이(과장된 우려), 코끼리(표면화되지 않은 우려)로 분류한 후, 출시 차단, 빠른 후속 조치, 추적 중으로 분류합니다. 출시 준비, 제품 계획 스트레스 테스트, 또는 문제 발생 가능성 식별 시 사용합니다.