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.
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.
- 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.
Source: sickn33/agentic-awesome-skills → skills/security-bluebook-builder/SKILL.md
Also appears in: sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/security-bluebook-builder/SKILL.md, sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/security-bluebook-builder/SKILL.md
1---2name: security-bluebook-builder3description: 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.4---5
6
7# Security Bluebook Builder
8
9## When to Use
10- You need a concise but enforceable security policy for an app handling sensitive data.
11- You want a single Blue Book document with explicit assumptions, controls, and go/no-go gates.
12- The user needs policy guidance grounded in scope, threat model, and operational security defaults rather than generic advice.
13
14## Overview
15Build 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.
16
17## Workflow
18
19### 1) Gather inputs (ask only if missing)
20Collect just enough context to fill the template. If the user has not provided details, ask up to 6 short questions:
21- What data classes are handled (PII, PHI, financial, tokens, content)?
22- What are the trust boundaries (client/server/third parties)?
23- How do users authenticate (OAuth, email/password, SSO, device sessions)?
24- What storage is used (DB, object storage, logs, analytics)?
25- What connectors or third parties are used?
26- Retention and deletion expectations (default + user-initiated)?
27
28If the user cannot answer, proceed with safe defaults and mark TODOs.
29
30### 2) Draft the Blue Book
31Load `references/bluebook_template.md` and fill it with the provided details. Keep it concise, deterministic, and enforceable.
32
33### 3) Enforce guardrails
34- Do not include secrets, tokens, or internal credentials.
35- If something is unknown, write "TODO" plus a clear assumption.
36- Fail closed: if a capability is required but unavailable, call it out explicitly.
37- Keep scope minimal; do not add features or tools beyond what the user asked for.
38
39### 4) Quality checks
40Confirm the Blue Book includes:
41- Threat model (assumptions + out-of-scope)
42- Data classification + handling rules
43- Trust boundaries + controls
44- Auth/session policy
45- Token handling policy
46- Logging/audit policy
47- Retention/deletion
48- Incident response mini-runbook
49- Security gates + go/no-go checklist
50
51## Resources
52- `references/bluebook_template.md`
53
54## Limitations
55- Use this skill only when the task clearly matches the scope described above.
56- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
57- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
58
59---
60
61**Source:** [`sickn33/agentic-awesome-skills`](https://github.com/sickn33/agentic-awesome-skills) → `skills/security-bluebook-builder/SKILL.md`
62
63**Also appears in:** `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/security-bluebook-builder/SKILL.md`, `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/security-bluebook-builder/SKILL.md`
sickn33