Perform a threat assessment of a repository and produce a threat-model.md. Supports --repo to analyze external repos and --output to set the output directory. Optionally also writes threat-model.yaml with --yaml flag.
Maintainer/dev skill that triages an anonymised diagnostic bundle (appsec-diag-*.tgz, produced by scripts/diagnostic_bundle.py) a user sent after a pipeline failure. Runs the deterministic inspect, then cross-references the plugin source (scripts/, agents/phases/, AGENTS.md) and known-bug history to produce a grounded root-cause hypothesis. Does NOT re-run the pipeline and never needs the user's repo.
Answer ANY question about the threat model in this repo — read-only Q&A over the committed threat-model.yaml. The default surface for every natural-language query about the model, however simple: does one exist at all ("is there a threat model here?", "gibt es hier ein bedrohungsmodell?"), how it stands ("how bad is it?", "is it still current?"), anything about its contents ("what are the critical findings?", "does it cover SSRF / IDOR / auth?", "which findings touch the payment service?", "is there a fix for F-003?", "welche kritischen findings gibt es?", "deckt mein bedrohungsmodell XSS ab?"), and meta questions ("what does P1 mean?", "what is STRIDE here?"). Grounds every data answer in the model and cites F-ids; never analyzes code, re-scores, spawns agents, or writes files. Prefer this over show-threat-model for anything phrased as a question — show only prints a fixed summary block on explicit request. To act on findings use review-threat-model; to (re)generate use create-threat-model.
Print the standard summary block of the current threat model — scan identity, findings by severity, the remediation backlog (P1/P2/P3) and mitigation coverage, the worst-case scenarios, control posture, and whether the model is still up to date. A DISPLAY command, not a question-answering surface: use it only for an explicit request to see that block ("show me the threat model summary", "zeig mir die threat-model-uebersicht", "print the overview"). Reuses the same change detection that decides if an incremental scan is needed. Does not analyze code, write files, or compose prose — it prints a rendered block verbatim and cannot answer anything the block does not already contain. Do NOT route a natural-language question here, not even "is there a threat model?" / "gibt es hier ein bedrohungsmodell?" — every question goes to ask-threat-model, which answers directly and can produce this block too.
User-facing triage of an existing threat model — an overview-first console over an already-generated threat-model.yaml (backlog by priority, severity mix, worst-case scenarios), then one of three modes. "Just look around" browses findings read-only by severity, security aspect, requirement, or control posture. "Fix or accept findings now" applies the code fix for findings you pick — or accepts the risk instead — one at a time for review. "Build a remediation plan" decides mitigate / accept-risk per finding and emits a remediation-plan.md without code changes. Within a session you can also discuss a single finding by id (F-/T-/M-/W-), a read-only aside that changes nothing. Runs later and independently of create-threat-model; reads the model, never regenerates or re-scores it. Not an artifact-quality check (that is eval-threat-model). To only *ask* about the model without acting on it, use ask-threat-model.
Convenience alias for create-threat-model in incremental mode — re-analyzes only the components that changed since the last run. Unlike the bare create-threat-model, it does NOT bootstrap — it aborts with a clear message when no threat model exists yet, so an "update" can never silently turn into a first full assessment. An explicit mode flag the user passes (--full, --rebuild, --rerender, --resume) is honored instead of the injected --incremental. Everything else (flags, --repo, --output, behavior, output) is identical to create-threat-model.
Audit the current repository against a security requirements catalog and verify whether each requirement is implemented. Requirement IDs follow your catalog's own naming scheme (e.g. SEC-CSP-1, SCG-HARDENXML, or anything your YAML defines); tagging code with those IDs is optional and not required. Prints open requirements to the conversation with color-coded status and concise evidence. Optionally saves Markdown/PDF reports. With --json or --gate it also persists a deterministic structured verdict (.requirements-audit.json) and can act as a CI gate.
Help a developer check the code they just changed against their company security requirements — or, if none are configured, against a built-in best-practices baseline. Scopes to the current diff, dispatches the appsec-reviewer subagent to grade only the triggered requirements, and prints concrete, code-aware guidance (what to fix and how). Advisory by default; an opt-in --gate turns it into a CI/merge gate. Complements the full-repo audit-security-requirements skill.