Passed 20 of 23 test cases with the skill, and 19 of 23 without it.
Without skill83%
With skill87%
Checks it passed that the model alone missed
Identifies missing location details such as file path and line range.
Excludes non-security code quality, style issues, and linting violations from security findings.
2 fixed18 passed either way2 still failing1 broke
Pass-rate lift
+4 pp
Tokens
+35%
Agent turns
0%
Response time
-6%
Model gemini-3.6-flashMeasured 8/23/2026v120 of 23 cases passed with skill
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
During our audit of `server/controllers/userController.js`, we noticed unused variables, inconsistent tab indentation, missing JSDoc comments, and a helper function that uses `var` instead of `const`. How should these findings be represented in our security audit report?
What was checked, without and with the skill
Checked
Without skill
With skill
Excludes non-security code quality, style issues, and linting violations from security findings.
Missed
Passed
case-05 · gemini-3.6-flash · 8/23/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md85 linessingle file
Security Audit
Phased security scan. Each phase is independent — skip phases that do not apply
to the codebase.
Phase 1: Scope
Identify the attack surface: what accepts external input? (HTTP endpoints,
CLI args, file uploads, WebSocket messages, IPC, environment variables)
Identify trust boundaries: where does data cross from untrusted to trusted?
List authentication and authorization mechanisms in use
Note the deployment model (server, serverless, desktop, CLI)
Phase 2: Input Validation
For each entry point identified in Phase 1:
Is user input validated and sanitized before use?
Are SQL queries parameterized (not string-interpolated)?
Is HTML output escaped to prevent XSS?
Are file paths validated to prevent path traversal?
Are file uploads constrained by type and size?
Is deserialization of untrusted data avoided or sandboxed?
Phase 3: Auth and Session
Are all protected routes/endpoints checked for authentication?
Is authorization checked per-resource, not just per-route?
Are session tokens generated with sufficient entropy?
Are tokens stored securely (httpOnly, secure, sameSite)?
Is there rate limiting on login/auth endpoints?
Are password reset flows safe from enumeration?
Phase 4: Secrets
grep -r for common secret patterns in source (API keys, tokens, passwords,
connection strings) — exclude node_modules, .git, lock files
Check git log --all -p -S "password\|secret\|api_key\|token" for secrets
that were committed and later removed (they are still in history)
Verify .gitignore covers .env, credential files, and key material