본문으로 건너뛰기
cccskills
무료GitHub에 공개

strategy-red-team

Review a product requirements document, roadmap, or strategy by challenging the assumptions it depends on. Rank potential failures by impact, likelihood, and testing cost, then propose small tests, evidence to gather, and criteria for stopping or changing course.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

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.

설치 방법 보기

이럴 때 유용합니다

  • Challenging critical assumptions before starting a plan
  • Preparing a strategy document for executive review
  • Choosing low-cost tests to run this week
  • Defining when to stop or change direction

포함된 파일(1)

  • SKILL.md4.4 KB

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

  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

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Analyze A/B test results to decide whether to launch a change, extend testing, stop, or investigate further. Check sample size, statistical significance, uncertainty ranges, and effects on other important metrics, then summarize the recommendation and next steps.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Checking whether an A/B test shows a meaningful difference
  • Reviewing sample size and test duration
  • Deciding whether to launch a tested change
phuryn/pm-skills2.7만2026년 10월 16일 업데이트

Organize customer feature requests into themes and rank the top three against product goals, customer value, effort, and risk. For each recommendation, explain the underlying need, possible alternatives, uncertain assumptions, and simple ways to test them.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Grouping customer requests into themes
  • Selecting the top three requests for product goals
  • Considering alternatives to requested features
phuryn/pm-skills2.7만2026년 10월 16일 업데이트

Compare growth options across existing and new products and markets using the Ansoff Matrix, a four-part planning framework. Assess opportunities, resources, competition, and risks, then develop market launch plans and a phased roadmap for priority options.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Comparing growth options for an existing business
  • Planning expansion into new regions or customer groups
  • Evaluating new products for current customers
phuryn/pm-skills2.7만2026년 10월 16일 업데이트

Choose the first customer segment for a product launch by comparing urgent needs, willingness to pay, achievable market share, and referral potential. Get scored recommendations, a priority segment, a 90-day acquisition plan, and expansion options.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Choosing the first customer segment for a new product
  • Focusing limited resources on a launch market
  • Comparing segments using interviews and customer feedback
phuryn/pm-skills2.7만2026년 10월 16일 업데이트

Plan low-effort experiments to check assumptions about an existing product before building a feature. Compare prototypes, A/B tests, and other methods, with a clear assumption, procedure, metric, and success threshold for each experiment.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Checking feature assumptions before implementation
  • Planning prototype usability tests
  • Defining metrics and success thresholds for A/B tests
phuryn/pm-skills2.7만2026년 10월 16일 업데이트

Turn a new product idea into a testable hypothesis and two or three simple experiments. Define target customers, expected actions, measurement methods, and success thresholds to assess demand through behavior such as sign-ups, pre-orders, or paid commitments.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Testing demand before building a new product
  • Planning landing page or waitlist experiments
  • Checking willingness to pay through pre-orders
phuryn/pm-skills2.7만2026년 10월 16일 업데이트

phuryn의 스킬 모두 보기

이 스킬의 문제 신고