Use when reviewing code, auth, or APIs for security vulnerabilities — adopt an attacker mindset, enumerate the attack surface, report only findings with a concrete reproducible attack path.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/thinking-red-team
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when reviewing code, auth, or APIs for security vulnerabilities — adopt an attacker mindset, enumerate the attack surface, report only findings with a concrete reproducible attack path.
📊 Stats
Stars863
Forks126
LanguageJavaScript
LicenseMIT
📦 Ships with thinking-skills
</> SKILL.md
thinking-red-team.SKILL.md
---name: thinking-red-team
description: Use when reviewing code, auth, or APIs for security vulnerabilities — adopt an attacker mindset, enumerate the attack surface, report only findings with a concrete reproducible attack path.
---# Red Team Thinking
## Overview
Red teaming is **adversarial security review**: deliberately attacking a system you control to find vulnerabilities before an attacker does. This skill is scoped to security/code vulnerability detection — it is NOT for plan stress-testing or decision challenge (use `thinking-pre-mortem` or `thinking-steel-manning` for those).
**The anti-fabrication gate is the most important rule:** every reported finding MUST include a concrete, reproducible attack path — entry point → exact steps → realized impact. If you cannot describe how the attack actually executes against *this* code/config, it is not a finding. Drop it. A short report of real, demonstrable vulnerabilities beats a long list of speculation.
**Core Principle:** Attack yourself before others do. But only report what you can actually break.
## When to Use
- Security review of code, authentication, authorization, APIs, or infrastructure you control
- Pre-launch security hardening of a system that handles auth, data, or money
- Evaluating whether a specific vulnerability class (injection, XSS, auth bypass, etc.) is present in your code
Decision flow:
```
Reviewing a system for security?
→ Can you demonstrate an attack path? → No → Don't report it
→ Is the finding reproducible against this code/config? → No → Drop it
→ Is this plan stress-testing or decision challenge? → Yes → Use thinking-pre-mortem or thinking-steel-manning
→ No → RED TEAM IT
```
## When NOT to Use
- **Speculative claims without a reproducible attack path.** This is the anti-fabrication gate. "Best practice says X" or "this could theoretically be vulnerable" is not a finding. State the entry point, exact steps, and realized impact — or drop it.
- **Plan, strategy, or decision stress-testing.** For "how could this plan fail," use `thinking-pre-mortem`. For "what's the strongest case against this decision," use `thinking-steel-manning`.
- **Architecture review without security focus.** For architecture resilience, use `thinking-systems` or `thinking-pre-mortem`.
- **Running scanners replaces thinking.** Where you can actually run a SAST tool, fuzzer, or PoC, do that. This skill structures the adversarial thinking; it doesn't replace automated verification.
- **Padding the report to look thorough.** A short list of real vulnerabilities beats a long list of theoretical ones. Resist the incentive to add "informational" or "best-practice" items.
## Procedure
### Step 1: Define the Target and Scope
```markdown
Target: [System/component under review]
Scope: [What to attack — be specific]
Out of scope: [What to skip]
Goal: [What constitutes a successful attack — e.g., unauthorized access, data exfiltration, privilege escalation]
```
### Step 2: Adopt the Adversary Mindset
Identify who would attack this system and what they want:
```markdown
Adversary profiles:
- External attacker (no access): targets public endpoints, auth bypass, injection
- Authenticated user (basic access): targets privilege escalation, IDOR, business logic
- Insider (elevated access): targets data exfiltration, audit bypass
For each profile, ask: "If I wanted to cause maximum damage with their access level, how would I?"
```
### Step 3: Enumerate the Attack Surface
Map every entry point and trust boundary:
| Surface | Exposure | Trust Boundary |
|---------|----------|----------------|
| Login form | Public internet | Anonymous → Authenticated |
| API /graphql | Public (with key) | Authenticated → Application |
### Step 6: Document Findings — With the Anti-Fabrication Gate
For EVERY finding, fill out:
```markdown
Finding: [Title]
Severity: Critical / High / Medium / Low
Attack path (REQUIRED):
Entry point: [URL, endpoint, parameter, file]
Steps: [1. Send X, 2. Observe Y, 3. Escalate to Z]
Realized impact: [What the attacker actually achieves — data access, privilege, DoS]
Remediation: [Concrete fix]
```
**If you cannot fill out the attack path completely, drop the finding.** Do not report "Missing HttpOnly flag" as a standalone finding without demonstrating session token theft. Do not report "No rate limiting" without demonstrating a viable brute-force attack.
## Output Contract
A completed Red Team report produces:
1. **Target and Scope** — what was reviewed and what was excluded
2. **Attack Surface Map** — entry points with exposure levels and trust boundaries
3. **Attack Scenarios Executed** — each scenario with steps, observations, and outcome
4. **Findings Report** — each with severity AND a concrete, reproducible attack path (entry point → steps → impact)
5. **Defense Bypass Results** — which defenses held and which were circumvented
6. **Remediation Recommendations** — prioritized by severity with concrete fixes
Findings without a complete attack path are excluded from the report. A report with zero findings is acceptable if no reproducible vulnerabilities were discovered.
## Anti-Patterns
| Anti-Pattern | Symptom | Correction |
|---|---|---|
| **Speculative claims** | Findings that say "could be vulnerable" or "best practice says" without a demonstrated attack path | Drop them; only report what you can actually break |
| **Padding the report** | Adding "informational" or "best-practice" items to look thorough | A short report of real vulns beats a long list of theory |
| **Non-security red-teaming** | Using this skill for plan stress-testing or decision challenge | Use `thinking-pre-mortem` (plans) or `thinking-steel-manning` (decisions) |
| **Skipping the adversary model** | Attacking without defining who the attacker is and what access they have | Define the adversary profile first; attacks make sense only in context |
| **Missing the attack path** | Reporting a vulnerability without showing how to reach it | Every finding needs: entry point → steps → impact |
| **Scanner-as-substitute** | Running a SAST tool and reporting its output without adversarial thinking | The tool finds patterns; red-teaming finds exploitable paths |
