thinking-red-team

Conducts authorized adversarial security reviews of code, auth, and APIs with verified exploit paths.

Updated May 24, 2026
One-click install
npx skills add https://github.com/MWest2020/skill-forge --skill thinking-red-team-mwest2020
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: thinking-red-team
Source: https://github.com/MWest2020/skill-forge/tree/main/skills/thinking-red-team
Command: npx skills add https://github.com/MWest2020/skill-forge --skill thinking-red-team-mwest2020

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Security reviews often produce speculative best-practice lists or raw scanner output without proof of real risk. This Skill enforces a disciplined red-team methodology: every reported finding must include a reproducible exploit path and a verified mitigation, so teams fix what is actually exploitable. ## Core Features & Use Cases - Threat Modeling and Surface Mapping: Names adversary profiles, goals, entry points, and trust boundaries before any testing begins. - Anti-Fabrication Gate: Drops any finding lacking a concrete entry point, ordered steps, and realized impact, keeping reports free of noise. - Mitigation Verification: Prescribes minimal fixes and defines how to re-test that each exploit path is closed. - Use Case: Before launching an API that handles payments, run an authorized review covering auth flows, IDOR, injection, and rate-limit bypass, then receive a report containing only confirmed vulnerabilities with fixes. ## Quick Start Ask the agent to red-team review the authentication and authorization code in this repository and report only findings with a reproducible exploit path.

Frequently Asked Questions about thinking-red-team

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I do an adversarial security review of my own code?

Define the target, scope, and authorization first, then build a threat model with attacker profiles and goals. Map entry points and trust boundaries, trace concrete exploit paths, and report only findings with reproducible steps and realized impact.

How to validate that a vulnerability is real and not scanner noise?

Apply an anti-fabrication gate: keep a finding only if you can document the entry point, ordered exploitation steps, and realized impact on the actual code or configuration. Treat scanner patterns as leads, not findings.

When should I not use red-team style security testing?

Do not use it without written authorization to test the target, for non-security plan or strategy critique, or for general architecture resilience review. Speculative best-practice notes without exploit paths are also out of scope.

What should a red-team security report include?

Include target scope and authorization, threat model, attack surface map, and findings with severity, entry point, exploitation steps, impact, control bypass attempts, minimal mitigation, and a re-test procedure confirming the fix.

Can red-team review replace automated vulnerability scanners?

No, they serve different roles. Scanners generate leads at scale, while red-team review confirms which leads are actually exploitable and verifies that mitigations close the attack paths.