@ 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
- never 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; never add features or tools beyond what the user asked for.
@ 4) Quality checks
Confirm the Blue Book includes:
- Threat model (assumptions + out-of-scope)
- Data classification + handling rules
- Trust boundaries + controls
- Auth/session policy
- Token handling policy
- Logging/audit policy
- Retention/deletion
- Incident response mini-runbook
- Security gates + go/no-go checklist
@ Resources
- references/bluebook_template.md
@ Limitations
- Use this skill only when the task clearly matches the scope described above.
- never treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
Source: Regtransfers/agency-agents-mcp — distributed by TomeVault.
1---2name: security-bluebook-builder-33description: 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. Use when this capability is needed.4---5@ Security Bluebook Builder67@ When to Use8- You need a concise but enforceable security policy for an app handling sensitive data.9- You want a single Blue Book document with explicit assumptions, controls, and go/no-go gates.10- The user needs policy guidance grounded in scope, threat model, and operational security defaults rather than generic advice.1112@ Overview13Build 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.1415@ Workflow1617@ 1) Gather inputs (ask only if missing)18Collect just enough context to fill the template. If the user has not provided details, ask up to 6 short questions:19- What data classes are handled (PII, PHI, financial, tokens, content)?20- What are the trust boundaries (client/server/third parties)?21- How do users authenticate (OAuth, email/password, SSO, device sessions)?22- What storage is used (DB, object storage, logs, analytics)?23- What connectors or third parties are used?24- Retention and deletion expectations (default + user-initiated)?2526If the user cannot answer, proceed with safe defaults and mark TODOs.2728@ 2) Draft the Blue Book29Load references/bluebook_template.md and fill it with the provided details. Keep it concise, deterministic, and enforceable.3031@ 3) Enforce guardrails32- never include secrets, tokens, or internal credentials.33- If something is unknown, write "TODO" plus a clear assumption.34- Fail closed: if a capability is required but unavailable, call it out explicitly.35- Keep scope minimal; never add features or tools beyond what the user asked for.3637@ 4) Quality checks38Confirm the Blue Book includes:39- Threat model (assumptions + out-of-scope)40- Data classification + handling rules41- Trust boundaries + controls42- Auth/session policy43- Token handling policy44- Logging/audit policy45- Retention/deletion46- Incident response mini-runbook47- Security gates + go/no-go checklist4849@ Resources50- references/bluebook_template.md5152@ Limitations53- Use this skill only when the task clearly matches the scope described above.54- never treat the output as a substitute for environment-specific validation, testing, or expert review.55- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.5657---58> Source: [Regtransfers/agency-agents-mcp](https://github.com/Regtransfers/agency-agents-mcp) — distributed by [TomeVault](https://tomevault.io).59<!-- tomevault:4.0:skill_md:2026-06-16 -->