security-bluebook-builder

Supporting material availability

This catalog copy contains the inline guidance below, but does not include the following supporting paths. They are external prerequisites, not bundled files:

• <support-root>/references/bluebook_template.md

Ask for the original supporting material or an existing installation before using a step that depends on these paths; this catalog does not identify a verified download source for them. Resolve each path relative to that installation, inspect its contents, and verify any applicable license and execution prerequisites. Do not run a command or claim a referenced procedure was followed until its required file exists. Do not fabricate the missing scripts or treat an unrelated file with the same name as equivalent. Independent steps fully documented here can proceed within the user’s authorized scope; report any dependent step as unavailable.

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

If the original supporting installation is available, load <support-root>/references/bluebook_template.md and fill it with the provided details. Otherwise draft an independent policy using the Quality checks below and disclose that the upstream template was unavailable. Keep it concise and distinguish proposed controls from controls actually implemented or verified.

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.

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

• <support-root>/references/bluebook_template.md

Example

User request:

Create a concise, enforceable security policy for this sensitive application using explicit MUST, SHOULD, and CAN requirements.

Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not 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.