Build Security Bluebooks for Sensitive Apps

Security Bluebook Builder generates a single, coherent security policy document - a Blue Book - for applications handling sensitive data. It produces enforceable policies using MUST/SHOULD/CAN language, with explicit assumptions, scope definitions, threat models, and security gates grounded in operational security defaults rather than generic advice.

Use this skill when you need a concise but enforceable security policy for an app handling sensitive data, want a single Blue Book document with explicit assumptions and controls, or need policy guidance grounded in scope and threat model rather than generic recommendations.

Do not use this as a substitute for environment-specific validation, testing, or expert review. Stop and request clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

You provide context through up to 6 short questions covering: data classes handled (PII, PHI, financial, tokens, content), trust boundaries (client/server/third parties), authentication methods (OAuth, email/password, SSO, device sessions), storage types (DB, object storage, logs, analytics), connectors or third parties used, and retention/deletion expectations (default plus user-initiated). If you cannot answer, the skill proceeds with safe defaults and marks TODOs.

You receive a complete Blue Book document that includes: threat model with assumptions and out-of-scope items, data classification and handling rules, trust boundaries and controls, auth/session policy, token handling policy, logging/audit policy, retention/deletion guidelines, incident response mini-runbook, and security gates with a go/no-go checklist. The output is kept concise and uses the references/bluebook_template.md structure.

This skill is for those building applications that handle sensitive data and need documented security policies. The Blue Book format provides a single coherent document rather than scattered guidance.

The skill enforces strict guardrails: it never includes secrets, tokens, or internal credentials in output; explicitly calls out required capabilities that are unavailable with fail-closed logic; marks unknowns as TODOs with clear assumptions; and keeps scope minimal without adding features or tools beyond what you requested.