Threat-model-driven security review of a change, feature, or subsystem. Runs a STRIDE-style pass (Spoofing, Tampering, Repudiation, Info disclosure, Denial of service, Elevation of privilege), examines the actual code, and produces a filing-ready report with severity, exploit scenario, and concrete remediation.
SkillScore64Maintained
Automatic
◆Security & AppSec pack
Last verified 9/27/2026
What it changes
Passed 13 of 21 test cases with the skill, and 11 of 21 without it.
Without skill55%
With skill64%
Checks it passed that the model alone missed
identifies Server-Side Request Forgery
recommends appending a record to .gsd/DECISIONS.md
2 fixed12 passed either way8 still failing0 broke
Pass-rate lift
+9 pp
Tokens
+152%
Agent turns
0%
Response time
+37%
Model gemini-3.6-flashMeasured 9/27/2026v114 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 2
Prompt
Evaluate this image downloader endpoint in src/controllers/media.ts:
line 22: app.post('/fetch-avatar', async (req, res) => {
line 23: const response = await fetch(req.body.imageUrl);
line 24: const data = await response.buffer();
line 25: res.send(data);
line 26: });
Identify the OWASP vulnerability present in this code.
What was checked, without and with the skill
Checked
Without skill
With skill
identifies Server-Side Request Forgery
Missed
Passed
case-14 · gemini-3.6-flash · 9/27/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md176 linessingle file
Invocation points:
Any change touching authentication, authorization, session handling
Any change touching user input → database, filesystem, or shell
Any change exposing a new external surface (HTTP endpoint, webhook, IPC boundary)
<core_principle>
CODE BEFORE CHECKLISTS. A threat model that doesn't read the code is theater. Find the actual input source, the actual validation (or absence), the actual sink. Cite file:line for every finding.
THREAT, NOT HYPOTHETICAL. "SQL injection is possible in theory" is useless. "If an attacker passes ' OR 1=1-- to getUser(name) at src/db/users.ts:42, the query becomes SELECT … WHERE name='' OR 1=1--', returning every row" is actionable.
READ-ONLY. Don't patch while reviewing — you conflate reviewer and author and lose the audit trail. Report, let the user act.
</core_principle>
Step 1: Scope the review
Identify what to review:
Recent diff (staged / branch / specific commit)
A named subsystem (src/auth/, the webhook handler, etc.)
A user-provided concern ("I'm worried about our JWT handling")
If the scope is vague, ask one round of clarifying questions (1–3 questions). Otherwise proceed.
Dedicated security-audit route for OWASP-style risks, secret leaks, auth flaws, injection, unsafe input handling, SSRF/XSS, and sensitive-data exposure. Use instead of code-reviewer when the prompt explicitly asks for security, vulnerability, threat, auth, or OWASP review.