A set of agent skills that produce a high-quality threat model for a targeted open-source repository or package — the implicit security contract between a project and its downstream users (assumptions, guarantees, disclaimed properties, misuses), not an audit, pentest, CVE list, or build-hygiene checklist.
The skills and their shared references are the operational specification. The bundle contains an orchestrator plus independently invocable specialists; the orchestrator performs the handoffs rather than specialists invoking one another.
- Unstructured — a root-level prose document (
threat-model.md) written to a fixed section structure, with structured tables embedded inline (per-input-operand trust table, contract-dimension matrix, disposition set, triager quick-start). - Structured — a machine-readable companion (
threat-model.yaml) that a triage pipeline or AI can consume. - Export — a flat
threat-model.jsonconforming to the repo'sschema.json, for external consumers that speak that schema. Lossy by design; authority order is prose > yaml > json, and triage never runs from the JSON alone.
| Skill | Role | Phase |
|---|---|---|
threat-model |
Orchestrator — drives phases 3.1–3.7, owns iteration/sign-off, then runs publication gates. Holds the shared references. | all |
threat-model-recon |
Orient + mine SECURITY.md/prior docs; carve component families; classify project type. |
3.1–3.2 |
threat-model-surface |
Deep in-scope code pass → per-input-operand trust table + contract-dimension matrix + no-surprise side-effects inventory. | 3.3 |
threat-model-interview |
Clarifying-question waves (framed as proposed answers); provenance promotion; termination policy. | 3.4 |
threat-model-authoring |
Draft the prose document with embedded structured tables; provenance tagging. | 3.5 |
threat-model-backtest |
Validate the draft against the historical finding corpus; feed §1.15. | 3.6 |
threat-model |
Iterate revisions, obtain sign-off, or publish unratified under the termination policy. | 3.7 |
threat-model-sidecar |
Emit + validate the machine-readable companions: threat-model.yaml and the threat-model.json export. |
§1.19 |
threat-model-triage |
Downstream reuse — route one inbound finding to a single disposition. | consume |
flowchart TD
O[threat-model orchestrator] --> R[recon]
O --> S[surface]
O --> I[interview]
O --> A[authoring]
O --> B[backtest]
O --> Y[sidecar]
R -->|orientation brief| A
S -->|surface analysis| A
I -->|answers + provenance| A
A -->|threat-model.md| B
B -->|revisions + §1.15| A
A -->|canonical prose| Y
A -. finished model .-> T[triage]
Y -. finished model .-> T
Phase 3.7 repeats the interview ⇄ authoring ⇄ backtest loop until the maintainer signs off or the termination policy publishes an unratified draft. Sidecar generation and the finalize gate run afterward as publication gates.
principles.md— what a threat model is/is not; the four-question framework; what to leave out.output-structure.md— the §1.1–§1.19 document spec, provenance tags, and closed disposition set.question-bank.md— reference questions, by wave.sidecar-schema.md— thethreat-model.yamlschema.json-report-schema.md— thethreat-model.jsonexport: field mapping, provenance collapse, and what the JSON does not carry.self-check.md— the four finalize gates.glossary.md— plain-language definitions of the threat-modeling jargon for non-expert maintainers.worked-example.md— a zlib flavor sketch.
Ask the agent to "produce a threat model for <repo/package>" to invoke the
orchestrator, or call a specialist directly (e.g., "triage this scanner finding
against the threat model" → threat-model-triage). Specialists are
independently invocable within this bundled skill set and may rely on its shared
references; the orchestrator sequences them and folds their artifacts into the
running draft.