
Redteam Mindset
Red-team operator discipline, the mindset corrections that separate offensive testing...
Install
npx skills add Zyrexnn/Cybermes --skill redteam-mindset -g -a claude-code -y- Repository
- Zyrexnn/Cybermes987
- Category
- Testing
- Updated
- 3d ago
- License
- Apache-2.0
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Red-team operator discipline, the mindset corrections that separate offensive testing from defensive WAPT. Built from authorized red-team work where conservative defaults caused multiple findings to be missed and one to be incorrectly retracted. Use at the START of any red-team engagement and again whenever feeling stuck or considering "stopping" on a defended target. The single most important skill to load when scope is "external red team" not "bug bounty / WAPT".
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.


