For authorized security review of code, auth, or APIs you control, model the attacker, map the attack surface, and report only findings with a reproducible exploit path and verified mitigation.
SkillScore73Maintained
On-demandOn-demand: invoked explicitly — never occupies your agent's context until called.
◆Security & AppSec pack
Last verified 8/14/2026
What it changes
Passed 16 of 22 test cases with the skill, and 13 of 22 without it.
Without skill59%
With skill73%
Checks it passed that the model alone missed
Explains that scanner leads require verified exploit paths before reporting
Provides specific re-testing procedure to verify the exploit path is closed
Excludes speculative best practice recommendations lacking reproducible exploit paths
and 1 more in the full report
4 fixed12 passed either way5 still failing1 broke
Pass-rate lift
+14 pp
Tokens
+39%
Agent turns
0%
Response time
-5%
Model gemini-3.6-flashMeasured 8/14/2026v116 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
We want a red team assessment of our server config. We found no exploitable paths, but we have a list of 20 TLS configuration best practices. Should we include them as informational findings?
What was checked, without and with the skill
Checked
Without skill
With skill
Excludes speculative best practice recommendations lacking reproducible exploit paths
Missed
Passed
case-17 · gemini-3.6-flash · 8/14/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md52 linessingle file
Red Team
Adversarial security review of systems you are authorized to assess. Attack before an outsider does, but report only what you can actually break: every finding needs a concrete exploit path and a check that the proposed fix closes it.
When to Use
Security review of code, authentication, authorization, APIs, data handling, or infrastructure you control and are permitted to probe.
Pre-launch hardening of systems that handle auth, money, personal data, or privileged actions.
Checking whether a specific vulnerability class (injection, XSS, IDOR, auth bypass, SSRF, secret exposure, etc.) is present with a real path.
Validating that a claimed control actually blocks the attack, not only that a scanner is quiet.
When NOT to Use
No authorization to attack the target — stop; do not probe systems you do not own or have written leave to test.
Speculative "best practice" notes without a reproducible exploit path — drop them; they are not findings.
Plan, strategy, or decision stress-testing — use pre-mortem (how the plan fails) or steel-manning (strongest case against the decision).
Architecture resilience without a security objective — use systems or pre-mortem.
Scanner output alone as a report — patterns are leads; red-team requires an exploit path.
Non-security root-cause or hypothesis localization — use scientific-method or five-whys-plus.
Procedure
Confirm authorization and objective. State target, allowed scope, out-of-scope assets, success condition (e.g., unauthorized data read, privilege escalation), and stop rules. Refuse or narrow if authorization is unclear.
Build the threat model. Name adversary profiles (anonymous external, authenticated user, privileged insider) and their goals under realistic access. Attacks without an actor and goal are noise.
Map the attack surface. Enumerate entry points and trust boundaries: public endpoints, auth flows, APIs, uploads, admin surfaces, jobs, webhooks, secrets, and data stores. Note exposure and required privileges.
Trace exploit paths. For each high-value surface, attempt concrete abuse: input manipulation, authz gaps, token/session misuse, injection, SSRF, IDOR, mass assignment, rate-limit bypass, secret leakage. Record exact steps and observed behavior.
Apply the anti-fabrication gate. Keep a finding only if you can complete: entry point → ordered steps → realized impact on this code/config. Incomplete paths are dropped, not listed as "informational."
Score severity and attempt defense bypass. Rate impact and exploitability. For each relevant control (rate limit, validation, session check), try a realistic bypass and record held vs broken.
Prescribe and verify mitigations. For each kept finding, give a minimal concrete fix and state how to re-test that the path is closed. Prefer fixes that remove the exploit precondition. Stop when in-scope surfaces are covered or authorization/budget ends; zero findings is valid.
When a request is vague, assumption-laden, or "obvious," ask the few load-bearing questions that expose hidden requirements before building or committing.