redteam-mindset
Teaches your agent to think like a security professional. It adopts a methodical mindset focused on finding and exploiting weaknesses.
What it does
This tool helps you think like a 'red teamer', focusing on finding security flaws and proving their impact, rather than just listing issues. It ensures you have permission and follow rules to test systems ethically and effectively.
When to use it
- ✓When testing a system's security with explicit permission.
- ✓When you need to simulate an attack to find weaknesses.
- ✓When encountering a roadblock and needing to decide whether to continue testing.
Example of what to ask your AI
“I want to test the security of example.com. I have written authorization for 'red team' testing within the defined scope.”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
The tool first checks if you have permission to test. Then, it helps decide how to continue testing even when facing difficulties, always focusing on proving the real damage an attacker could cause.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add sickn33/agentic-awesome-skills --skill redteam-mindsetOr download just the file:
curl -L https://raw.githubusercontent.com/sickn33/agentic-awesome-skills/main/plugins/agentic-awesome-skills-claude/skills/redteam-mindset/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.
Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
- Ask the user to state the exact target URL, IP, account, or resource.
- Ask the user to confirm written authorization and the permitted scope.
- Show the exact command(s) and explain their expected effect.
- Wait for explicit confirmation in the current conversation.
Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.
When to use this skill
Trigger when:
- Engagement scope says "red team", "adversary emulation", "assume breach", "TIBER-style"
- You're tempted to retract a finding because reproducibility failed once
- You're tempted to call a defense "working as intended" instead of probing further
- You hit a blocker (captcha, rate limit, WAF, CA-block, lockout) and consider stopping
- You're about to spend time on IDOR/CSRF/XSS instead of access-yielding bugs
- You found a vuln on app A and there are sister apps B, C, D you haven't touched
DO NOT use for:
- Bug bounty programs (use bug-bounty skill — different scope rules)
- WAPT/PCI-style assessments (use OWASP-aligned skills)
- Pure compliance audits
The one-line summary
Red team scope = "gain access, prove impact". Bug bounty / WAPT scope = "find a bug, write a report".
These produce DIFFERENT decisions at every blocker. Internalize the difference before starting.
DO NOT STOP — primary directive (read this twice)
The 9 corrections below are nuance. THIS is the core. If you only retain one thing from this skill, retain this.
Authorization given at engagement start covers the entire engagement.
Do not insert mid-engagement permission gates. If the user chose a mode at the start ("full engagement", "Option D", "go deep", "test these assets") that authorization stands until the engagement window expires or the user explicitly revokes it. AskUserQuestion mid-loop after the user already chose a path is a stall, not a check.
Discipline rules are about correctness of FINDINGS, not throttling of EFFORT.
Read this twice. The bundle's discipline rules — OOB-Or-It-Didn't-Happen, Marker Discipline, Body-Diff, Pre-Severity Gate, Server-Policy-vs-State, Statistical Sampling — all answer one question: "is this signal actually a finding?". None of them answer the question "should I send the next probe?" The answer to that second question is always yes, unless scope is exhausted or the user said stop.
"Stop at PoC" means stop ESCALATING, not stop TESTING.
When you confirm impact on bug class X, don't keep escalating class X (no need to pivot from id=1 IDOR to dumping the whole user table). But classes Y and Z have not been tested yet. Run Y. Then Z. Then the rest of the Pattern Library.
The data-minimization boundary is AS LOUD as "DO NOT STOP". Read this twice.
"Keep digging" applies to coverage (untested surfaces, classes, hosts), NOT to extraction. These pull in opposite directions and the persistence directive must NOT bleed into over-collection:
- An access/exfil vulnerability is proven by the MISSING CHECK, not by the volume of data you copy out. 3 records that should have required auth = complete proof. 3,000 records = the same finding + a liability you created. Pulling more never strengthens the finding.
- "Keep digging" = test the next endpoint family / the next host / the next class. It does NOT mean "enumerate every record from the endpoint you already broke." Breadth of coverage, not depth of theft.
- The data usually belongs to the target's customers / fourth parties (their clients, their users' PII, partner financials). They didn't sign the SOW/program. Copying their data onto your host is harm you shouldn't create when the point is already made.
…
FAQ
What is 'red teaming'?
It's a team that simulates real attacks to find security flaws in systems, acting like an actual attacker.
Can I use this to test any website?
No, you need explicit, written permission from the system owner before using this tool for any testing.
What's the difference between 'red teaming' and bug bounty hunting?
Red teaming focuses on 'gaining access and proving impact', while bug bounty hunting focuses on 'finding a bug and reporting it'.
Details
Popularity
- GitHub stars
- 48k
- Ranking position
- #3986
- License
- MIT
- Updated
- 10/15/2026
Comments
- …
More skills from this repository
00-andruia-consultant
Helps your agent start or improve AI projects. It analyzes code, suggests tools, and creates action plans in Spanish.
sickn33/agentic-awesome-skills
007
Lets your agent perform security audits and threat modeling. It's useful for protecting projects against attacks and vulnerabilities.
sickn33/agentic-awesome-skills
10-andruia-skill-smith
Helps your agent create or improve AI tools. It defines how tools work, writes documentation, and validates the structure.
sickn33/agentic-awesome-skills
20-andruia-niche-intelligence
Lets your agent create a summary about a specific industry. It's useful for understanding the context, rules, usage patterns, and risks of a project, using reliable sources.
sickn33/agentic-awesome-skills
Similar skills
dashboard-builder
Helps your agent create useful monitoring dashboards. It turns data into charts that answer important system questions.
affaan-m/ECC
dev-team
Simulates a collaborative development team where different roles respond to a problem together. It's useful for getting multiple perspectives without manually switching agents.
affaan-m/ECC
ecc-council
Has your agent convene a four-voice council for difficult decisions. It's useful when there are multiple good options and debate is needed before choosing.
affaan-m/ECC