plugins/ordis-security-architect/skills/using-security-architect/SKILL.md
Use when designing or reviewing security architecture - threat modeling (STRIDE), defense-in-depth controls, secure-by-design patterns, LLM/AI security (OWASP LLM Top 10, MITRE ATLAS), supply-chain security (SLSA/SBOM/Sigstore), compliance mapping (NIST CSF/ISO 27001/PCI-DSS/GDPR), classified-systems MLS, and government authorization (ATO/RMF/FedRAMP).
npx skillsauth add tachyon-beep/skillpacks using-security-architectInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This meta-skill routes you to the right security architecture skills based on your situation. Load this skill when you need security expertise but aren't sure which specific security skill to use.
Core Principle: Different security tasks require different skills. Match your situation to the appropriate skill, load only what you need.
Load this skill when:
Don't use for: Simple features with no security implications (e.g., UI styling, basic CRUD with existing auth)
IMPORTANT: All reference sheets are located in the SAME DIRECTORY as this SKILL.md file.
When this skill is loaded from:
skills/using-security-architect/SKILL.md
Reference sheets like threat-modeling.md are at:
skills/using-security-architect/threat-modeling.md
NOT at:
skills/threat-modeling.md ← WRONG PATH
When you see a link like [threat-modeling.md](threat-modeling.md), read the file from the same directory as this SKILL.md.
Symptoms: "Design a new...", "We're building...", "Greenfield project"
Route to:
Example: "Design authentication system" → Load all three in order
Symptoms: "Review this design", "Security audit", "Does this look secure?"
Route to: security-architecture-review.md
When to add:
Example: "Review this plugin system" → Load security-architecture-review.md
Route to:
Route to:
Route to:
Symptoms: "LLM", "prompt injection", "RAG", "vector store", "agent", "MCP", "model registry", "AI safety" (security flavor), "jailbreak", "model poisoning"
Route to: llm-and-ai-security.md
When to add:
Example: "Threat model our customer support chatbot with tool-use" → Load llm-and-ai-security.md + threat-modeling.md
Symptoms: "supply chain", "SBOM", "SLSA", "Sigstore", "cosign", "dependency confusion", "typosquat", "provenance", "build attestation", "signed releases"
Route to: supply-chain-security.md
When to add:
Example: "Design our SLSA L2 build pipeline" → Load supply-chain-security.md
Symptoms: "TOP SECRET", "classified data", "security clearances", "multi-level security", "Bell-LaPadula"
Route to:
Example: "Design system handling SECRET and UNCLASSIFIED" → Load classified-systems-security.md first
Symptoms: "HIPAA", "PCI-DSS", "SOC2", "GDPR", "compliance audit", "regulatory requirements"
Route to: compliance-awareness-and-mapping.md
When to add:
Example: "Build HIPAA-compliant system" → Load compliance-awareness-and-mapping.md + threat-modeling.md
Symptoms: "ATO", "AIS", "authority to operate", "SSP", "SAR", "POA&M", "FedRAMP", "FISMA"
Route to: security-authorization-and-accreditation.md
Cross-reference: Load muna/technical-writer/operational-acceptance-documentation for SSP/SAR writing
Symptoms: "Document security decisions", "Write security docs", "Explain threat model"
Route to: documenting-threats-and-controls.md
Cross-faction reference: Load muna/technical-writer/documentation-structure for ADR format, clarity guidelines
Example: "Document why we chose MLS" → Load documenting-threats-and-controls.md + documentation-structure
Load these for any project with security needs:
Load these only when context requires:
Decision: If you're unsure whether context is "specialized", start with core skills. Specialized contexts will be explicit in requirements.
Is this security-related?
├─ No → Don't load security skills
└─ Yes → Continue
What's the situation?
├─ New system design → threat-modeling + secure-by-design-patterns + security-controls-design
├─ Reviewing existing → security-architecture-review
├─ Documenting security → documenting-threats-and-controls + muna/technical-writer/documentation-structure
└─ Domain-specific → See "Specific Security Domains" above
Is this a specialized context?
├─ LLM / RAG / agent → ADD: llm-and-ai-security
├─ Build pipeline / SBOM / signing → ADD: supply-chain-security
├─ Classified data → ADD: classified-systems-security
├─ Compliance required → ADD: compliance-awareness-and-mapping
├─ Government ATO → ADD: security-authorization-and-accreditation
└─ No → Core skills sufficient
Security work often requires skills from other factions:
Muna (Documentation):
muna/technical-writer/documentation-structure - When documenting security (ADRs, SSPs)muna/technical-writer/clarity-and-style - When explaining security to non-expertsLoad both factions when: Documenting security decisions, writing security policies, explaining threats to stakeholders
Axiom (Audit Pipelines):
axiom-audit-pipelines:using-audit-pipelines (or /audit-pipelines) — When the system makes procedural decisions whose provenance must be defensible after the fact (rule firings, governor verdicts, automated approvals). This pack designs the evidence (canonical encoding, fingerprint chains, signed exports, decision provenance, retention reconciled with RTBF). Security architecture designs system controls; audit pipelines design the log itself. Cross-link: the audit-log threat model lives in the audit pack (07-threat-model.md); the system threat model lives here (threat-modeling.md). They reference each other rather than duplicate STRIDE tables.Load both packs when: A system has both regulatory compliance obligations and procedural decisions auditors will sample. Order: this pack first (system threat model + controls), then audit pipelines (decision-log specification, integrity scheme, replay capability) consuming the system threat model as input.
User: "Design authentication with passwords and OAuth"
You: Loading threat-modeling + secure-by-design-patterns + security-controls-design
User: "Review this plugin security design"
You: Loading security-architecture-review
User: "Build system handling TOP SECRET data"
You: Loading classified-systems-security + threat-modeling + secure-by-design-patterns
User: "Build HIPAA-compliant patient portal"
You: Loading compliance-awareness-and-mapping + threat-modeling + security-controls-design
User: "Document our MLS security decisions"
You: Loading documenting-threats-and-controls + muna/technical-writer/documentation-structure
Don't load security skills for:
Example: "Add dark mode toggle to settings" → No security skills needed (unless settings include security-sensitive preferences)
| Task Type | Load These Skills | Notes | |-----------|------------------|-------| | New system design | threat-modeling, secure-by-design-patterns, security-controls-design | Load in order | | Design review | security-architecture-review | Add threat-modeling if no threat analysis exists | | Authentication | threat-modeling, secure-by-design-patterns | Consider authorization-and-accreditation if ATO needed | | API security | threat-modeling, security-architecture-review | Apply STRIDE to endpoints | | Classified data | classified-systems-security + core skills | Extension required | | Compliance | compliance-awareness-and-mapping + core skills | Extension for regulatory contexts | | Government ATO | security-authorization-and-accreditation + core skills | Extension for ATO/AIS | | LLM / RAG / agent | llm-and-ai-security + threat-modeling | Extension for AI systems | | Build pipeline / SBOM | supply-chain-security + threat-modeling | Extension for release/supply chain | | Document security | documenting-threats-and-controls, muna/documentation-structure | Cross-faction |
Wrong: Load all 10 security-architect skills for every security task Right: Load only the skills your situation needs (use decision tree)
Wrong: Jump straight to implementation for new security features Right: Always threat model first for new systems/features
Wrong: Use generic threat modeling for classified systems Right: Load classified-systems-security for MLS contexts
Wrong: Write security docs without documentation structure skills Right: Load both ordis/documenting-threats + muna/documentation-structure
User: "Design a payment processing microservice"
Your routing:
1. Recognize: New system + financial domain → security critical
2. Load: threat-modeling (identify payment-specific threats)
3. Load: secure-by-design-patterns (encryption, secrets management)
4. Load: security-controls-design (PCI-DSS controls)
5. Consider: compliance-awareness-and-mapping (PCI-DSS is compliance requirement)
User: "Add a favorites button to the UI"
Your routing:
1. Recognize: UI feature, uses existing auth, no new security surface
2. Decision: No security skills needed
3. Proceed with standard implementation
User: "Review architecture for system handling SECRET and UNCLASSIFIED data"
Your routing:
1. Recognize: Classified context (SECRET mentioned) + review task
2. Load: classified-systems-security (MLS patterns required)
3. Load: security-architecture-review (review process)
4. Load: threat-modeling (if threats not already modeled)
User: "Threat model our support chatbot — it reads tickets and can issue refunds"
Your routing:
1. Recognize: LLM + agentic + tool use + financial action
2. Load: llm-and-ai-security (OWASP LLM Top 10, agentic threats)
3. Load: threat-modeling (STRIDE spine, attack trees on tool calls)
4. Consider: security-controls-design (action-side controls, refund cap enforcement)
User: "Design our release pipeline to meet SLSA L2 and produce signed SBOMs"
Your routing:
1. Recognize: Supply chain + provenance + signing
2. Load: supply-chain-security (SLSA, SBOM, Sigstore)
3. Load: security-architecture-review (tooling alignment)
4. Consider: compliance-awareness-and-mapping (EO 14028 / EU CRA mapping if in scope)
This skill maps your situation → specific security skills to load.
Meta-rule: When in doubt, start with threat-modeling.md. Threats drive everything else.
After routing, load the appropriate specialist skill for detailed guidance:
tools
Use when designing, implementing, or auditing an MCP (Model Context Protocol) server — tool API design, idempotency under agent retry, structured error envelopes agents can recover from, schema versioning across model drift, transport reliability (stdio / HTTP), output-shape and pagination discipline, and choosing between tools / resources / prompts / sampling. Also use when an MCP server's tools confuse agents, return unstructured errors, deadlock under concurrent calls, double-execute under retry, or lose state across reconnects. Do not use for general REST/GraphQL API design (use `/web-backend`), for client-side prompt engineering or tool-loop design (use `/llm-specialist`), for general in-process plugin architecture (use `/system-architect`), or for cryptographic-provenance audit trails (use `/audit-pipelines`).
development
Use when running **SQLite or DuckDB inside an application process** as the durable store — not as a development convenience but as the production database. Use when scaling an SQLite layer that worked at low concurrency and is now hitting SQLITE_BUSY, WAL bloat, lock contention, schema-migration ceremony, or correctness gaps under multi-process writers. Use when introducing DuckDB as an OLAP complement to an OLTP SQLite store, or when picking between the two for a new component. Pairs with `/web-backend` (the API surface above the DB) and `/audit-pipelines` (when the DB is also the audit trail). Do not load for server databases (Postgres, MySQL), key-value stores, or ORM choice in isolation.
development
Use when designing or critiquing the structure of a staged procedure — a wizard, configuration flow, troubleshooting tree, training curriculum, multi-stage approval pipeline, decision pipeline, or any decomposition of expert work into composable stages. Use for both producer work (build the decomposition) and critic work (audit a proposed decomposition). Use when reasoning about capacity, bottlenecks, or soundness of a procedural flow. Do not use for implementation-plan critique of code changes (use `/axiom-planning` instead), for execution-time dynamics (use `/simulation-foundations`), or for rendering an already-designed procedure as docs or UI (use `/technical-writer` or `/ux-designer`).
testing
Use when the user wants to draft fiction or creative nonfiction prose, get craft critique on prose they have written, or plan story structure, outline, or premise. Workshop-voiced. Three explicit modes (draft, critique, plan) and the router will refuse to begin work without a declared mode.