# Red Team

> Attacks the user's own plan, design, code, or argument the way a motivated adversary or reality would, to surface the holes before a real opponent finds them. Use this skill when the user says "find the flaws", "poke holes in this", "what could go wrong", "stress-test this", wants a security or robustness review, is about to ship or launch something, is finalizing a strategy, or asks you to attack/break their work. Best right before a commitment point, when the cost of a hidden weakness is about to jump.

- Skill: `opelpleple/red-team` (Agent Skill)
- Install (CLI): `npx skillmds@latest add opelpleple/red-team`
- Raw SKILL.md: https://api.skillmd.com/api/skills/opelpleple/red-team/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: opelpleple (https://skillmd.com/u/opelpleple)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/opelpleple/red-team

---


# Red Team

Switch sides. Become the attacker, the competitor, the failure mode, or Murphy's Law — and try to break the thing the user just built, on purpose.

## When to use
- Right before shipping, launching, publishing, or signing.
- Security/abuse review: "how would someone exploit this?"
- A strategy or plan that an opponent (competitor, regulator, adversary) could counter.
- A claim or argument going in front of a hostile audience.
- Anything where the cost of a missed weakness is high and rises after commitment.

## When NOT to use
- Early brainstorming, where attacking ideas kills the generative phase. Diverge first, red-team later.
- When the user needs encouragement to start, not reasons to stop.
- Trivial, reversible decisions where the failure cost is near zero.

## The method
1. **Define the target and the win condition precisely.** What exactly are you attacking, and what counts as "broken"? "The plan fails" is vague; "an attacker reads another user's data" or "the launch misses its date" is a target.
2. **Pick your adversaries and put on each mask in turn.** Run distinct passes, e.g.:
   - **The malicious attacker** — wants to exploit, steal, abuse, or cheat.
   - **The competitor** — wants to out-maneuver, copy, or undercut you.
   - **Reality / Murphy** — no intent, just everything that can fail will: outages, edge cases, bad inputs, scale, time.
   - **The hostile critic** — wants to discredit the argument publicly.
3. **For each mask, ask "how do I win against this?"** Generate concrete attacks, not vague worries. Name the exact input, move, or condition.
4. **Probe the seams.** Attacks live at boundaries: trust boundaries, handoffs, assumptions, "this will never happen," default configs, the unhappy path, the 10x-load path, the malicious-input path.
5. **For each attack, rate severity × likelihood.** A devastating-but-impossible attack and an annoying-but-certain one are different problems. Sort by the product.
6. **Steelman the defense, then attack again.** For the top attacks, imagine the best fix, then try to break *that*. Stop when remaining attacks are low-severity or genuinely hard.
7. **Deliver the kill list.** Ranked attacks, each with: the exact exploit, why it works, severity × likelihood, and the cheapest mitigation.

## What good looks like
- Specific, reproducible attacks — a concrete input/move, not "security could be better."
- At least one finding the user clearly hadn't considered.
- Honest severity ratings, including downgrading scary-sounding but trivial issues.
- Every finding paired with a mitigation, so it's actionable, not just discouraging.
- Coverage across multiple adversary types, not just one favorite angle.

## Anti-patterns
- **Vague FUD:** "this might not scale" with no scenario. Name the load and the breaking point.
- **Attacking the person, not the work.** Red-team the artifact, never the author.
- **Only finding flaws you already know how to fix.** Push into uncomfortable territory.
- **No prioritization:** a flat list of 30 issues is as useless as none. Rank them.
- **Forgetting the boring adversary:** most real failures are Murphy, not a genius hacker.

## Example
Target: a referral feature giving $10 credit per signup. Win condition: extract money without real referrals. Attacker mask: "I script 10,000 throwaway emails, self-refer, cash out $100k in credit." Seam probed: the trust boundary assumes one human per email. Reality mask: "two legit users refer each other in a loop." Severity × likelihood: high × high — this *will* be hit on day one. Mitigation: credit only unlocks after the referred account makes a verified action with cost (a real payment), not at signup. Re-attack the fix: "I make one real $1 purchase to unlock $10" — so cap credit at the verified spend. Kill list delivered, ranked, with the cheapest patch first.