Build a minimal but real security policy for sensitive apps. The output is a single, coherent Blue Book document using MUST/SHOULD/CAN language, with explicit assumptions, scope, and security gates.
SkillScore86Maintained
Automatic
◆Security & AppSec pack
Last verified 8/11/2026
What it changes
Passed 19 of 22 test cases with the skill, and 15 of 22 without it.
Without skill68%
With skill86%
Checks it passed that the model alone missed
The policy uses capital normative keywords like MUST.
The output explicitly states assumptions alongside TODO markers.
The policy explicitly forbids storing hardcoded credentials in policy files.
and 3 more in the full report
4 fixed15 passed either way3 still failing0 broke
Pass-rate lift
+18 pp
Tokens
+0%
Agent turns
0%
Response time
-16%
Model gemini-3.6-flashMeasured 8/11/2026v119 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
Can you create a security policy bluebook for our new mobile app? We process customer user records.
case-14 · gemini-3.6-flash · 8/11/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md51 linessingle file
Security Bluebook Builder
When to Use
You need a concise but enforceable security policy for an app handling sensitive data.
You want a single Blue Book document with explicit assumptions, controls, and go/no-go gates.
The user needs policy guidance grounded in scope, threat model, and operational security defaults rather than generic advice.
Overview
Build a minimal but real security policy for sensitive apps. The output is a single, coherent Blue Book document using MUST/SHOULD/CAN language, with explicit assumptions, scope, and security gates.
Workflow
1) Gather inputs (ask only if missing)
Collect just enough context to fill the template. If the user has not provided details, ask up to 6 short questions:
What data classes are handled (PII, PHI, financial, tokens, content)?
What are the trust boundaries (client/server/third parties)?
How do users authenticate (OAuth, email/password, SSO, device sessions)?
What storage is used (DB, object storage, logs, analytics)?
What connectors or third parties are used?
Retention and deletion expectations (default + user-initiated)?
If the user cannot answer, proceed with safe defaults and mark TODOs.
2) Draft the Blue Book
Load references/bluebook_template.md and fill it with the provided details. Keep it concise, deterministic, and enforceable.
3) Enforce guardrails
Do not include secrets, tokens, or internal credentials.
If something is unknown, write "TODO" plus a clear assumption.
Fail closed: if a capability is required but unavailable, call it out explicitly.
Keep scope minimal; do not add features or tools beyond what the user asked for.