/threat-model
Use when Codex is already in the threat-modeling phase of a security scan, the user explicitly invokes $threat-model, or the user explicitly asks to create, update, or persist a repository threat model. Do not use as the primary trigger for full PR, commit, branch, patch, or
$ npx -y skills add CoWork-OS/CoWork-OS --skill threat-model --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/threat-model
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when Codex is already in the threat-modeling phase of a security scan, the user explicitly invokes $threat-model, or the user explicitly asks to create, update, or persist a repository threat model. Do not use as the primary trigger for full PR, commit, branch, patch, or
SKILL.md
threat-model.SKILL.mdname: threat-model
description: Use when Codex is already in the threat-modeling phase of a security scan, the user explicitly invokes $threat-model, or the user explicitly asks to create, update, or persist a repository threat model. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
metadata:
short-description: Build a repository threat model
Security Threat Model
Objective
Establish the repository-scoped threat model at the path defined in `../../references/scan-artifacts.md`. If this already exists, stop here. If a threat model or clearly authoritative security scan guidance is provided or already exists, persist it unchanged to this file, then stop here.
`AGENTS.md` can be that authoritative source when it is sufficiently specific about the repository's product surfaces, trust boundaries, attacker-controlled inputs, assumptions, or security scan guidance to serve as the threat model.
If no threat model is provided, generate a repository-scoped threat model to be used in future bug discovery. The threat model should holistically cover the entire repository and should make it obvious:
- what assets or privileges matter
- what trust boundaries exist
- what inputs are attacker-controlled
- what invariants the code must preserve
- what repository-wide failure modes would matter most
Artifact Resolution
The path references in this skill are the default locations for this phase. If the user explicitly provides a different path for a required input or output, use the user-provided path instead of the corresponding default path referenced in this skill. If a required input is still missing, stop and ask the user for it before continuing. Use the shared scan artifact path conventions in `../../references/scan-artifacts.md`.
Workflow
1. Resolve `repo_name`, `security_scans_dir`, and the repository-scoped threat model path using `../../references/scan-artifacts.md`. 2. If the repository-scoped threat model already exists, stop here. 3. If a threat model or authoritative security scan guidance is provided or referenced:
- write it exactly to the repository-scoped threat model path
- treat that file as the only threat model source of truth
- do not expand, summarize, or reinterpret it
- `AGENTS.md` is acceptable here when it is clearly being used as the security scan guidance or threat model source for this scan and is sufficiently repository-specific to stand in for a threat model
4. Otherwise, generate a repository-scoped threat model using the checklist below. 5. Before finalizing this phase, sanity-check that:
- the threat model is repository-scoped rather than being centered around any specific scan target
- it describes repository-wide primary product or runtime surfaces and trust boundaries before covering any narrower examples
- any vulnerability-class discussion is about repository-context classes, not findings about any current diff
6. Write the exact threat model to the repository-scoped threat model path.
Threat Model Generation Guidance
Generate and structure the threat model using `references/threat-model-guidance.md`.
Hard Rules
- A provided threat model or authoritative security scan guidance is authoritative.
- Threat model generation must stay at repository scope unless the user explicitly asks for narrower scope.
- Do not turn this phase into findings about any current diff.
- Do not let the current scan target, touched subsystem, or changed directories become the center of gravity for this phase unless the user explicitly asks for that narrower scope.
- In large monorepos, avoid centering `personal/`, `test/`, `tests/`, `docs/`, `examples/`, or one-off developer tooling unless repository evidence shows those are real deployed or privileged workflow surfaces.
- Call out trust boundaries and assumptions explicitly.
- Keep references to vulnerability types at the level of repository-context classes, rather than any diff findings.
- Persist the threat model output to the repository-scoped threat model path from `../../references/scan-artifacts.md`.
Read more
name: threat-model description: Use when Codex is already in the threat-modeling phase of a security scan, the user explicitly invokes $threat-model, or the user explicitly asks to create, update, or persist a repository threat model. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans. metadata: short-description: Build a repository threat model
Security Threat Model
Objective
Establish the repository-scoped threat model at the path defined in `../../references/scan-artifacts.md`. If this already exists, stop here. If a threat model or clearly authoritative security scan guidance is provided or already exists, persist it unchanged to this file, then stop here.
`AGENTS.md` can be that authoritative source when it is sufficiently specific about the repository's product surfaces, trust boundaries, attacker-controlled inputs, assumptions, or security scan guidance to serve as the threat model.
If no threat model is provided, generate a repository-scoped threat model to be used in future bug discovery. The threat model should holistically cover the entire repository and should make it obvious:
- what assets or privileges matter
- what trust boundaries exist
- what inputs are attacker-controlled
- what invariants the code must preserve
- what repository-wide failure modes would matter most
Artifact Resolution
The path references in this skill are the default locations for this phase. If the user explicitly provides a different path for a required input or output, use the user-provided path instead of the corresponding default path referenced in this skill. If a required input is still missing, stop and ask the user for it before continuing. Use the shared scan artifact path conventions in `../../references/scan-artifacts.md`.
Workflow
1. Resolve `repo_name`, `security_scans_dir`, and the repository-scoped threat model path using `../../references/scan-artifacts.md`. 2. If the repository-scoped threat model already exists, stop here. 3. If a threat model or authoritative security scan guidance is provided or referenced:
- write it exactly to the repository-scoped threat model path
- treat that file as the only threat model source of truth
- do not expand, summarize, or reinterpret it
- `AGENTS.md` is acceptable here when it is clearly being used as the security scan guidance or threat model source for this scan and is sufficiently repository-specific to stand in for a threat model
4. Otherwise, generate a repository-scoped threat model using the checklist below. 5. Before finalizing this phase, sanity-check that:
- the threat model is repository-scoped rather than being centered around any specific scan target
- it describes repository-wide primary product or runtime surfaces and trust boundaries before covering any narrower examples
- any vulnerability-class discussion is about repository-context classes, not findings about any current diff
6. Write the exact threat model to the repository-scoped threat model path.
Threat Model Generation Guidance
Generate and structure the threat model using `references/threat-model-guidance.md`.
Hard Rules
- A provided threat model or authoritative security scan guidance is authoritative.
- Threat model generation must stay at repository scope unless the user explicitly asks for narrower scope.
- Do not turn this phase into findings about any current diff.
- Do not let the current scan target, touched subsystem, or changed directories become the center of gravity for this phase unless the user explicitly asks for that narrower scope.
- In large monorepos, avoid centering `personal/`, `test/`, `tests/`, `docs/`, `examples/`, or one-off developer tooling unless repository evidence shows those are real deployed or privileged workflow surfaces.
- Call out trust boundaries and assumptions explicitly.
- Keep references to vulnerability types at the level of repository-context classes, rather than any diff findings.
- Persist the threat model output to the repository-scoped threat model path from `../../references/scan-artifacts.md`.
Local-first personal agentic OS and everything app for coding, knowledge work, web design, automations, and artifacts.
Repo: CoWork-OS/CoWork-OS
Other skills on cowork-os.
- /attack-path-analysis
Use when Codex is already in the attack-path-analysis phase of a security scan or the user explicitly asks to trace a security finding from source to sink and calibrate severity. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
Open skill - /deep-security-scan
Use when the user asks for a deep, exhaustive, multi-pass, or variance-reducing repository-wide Codex Security scan. Run repeated independent repository-wide discovery passes with worker-specific threat models, semantically merge candidates, synthesize one canonical validation
Open skill - /finding-discovery
Use when Codex is already in the finding-discovery phase of a security scan or the user explicitly asks to discover candidate security findings in a repository or code change. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
Open skill - /fix-finding
Use when the user explicitly asks to fix and verify a validated or plausible security finding. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
Open skill - /security-diff-scan
Use when the user asks for a security review of a pull request, commit, branch diff, working-tree patch, or other Git-backed change set.
Open skill - /security-scan
Use when the user asks for a repository-wide or scoped-path security scan.
Open skill

