attack-path-analysisUse when a security scan is already in its attack-path-analysis phase 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.
deep-security-scanUse when the user asks for a deep, exhaustive, multi-pass, or variance-reducing repository-wide or scoped-path security scan. Do not use for PRs, commits, branch diffs, or working-tree diffs, or for standard single-pass scans.
define-security-policyDefine, review, or update SECURITY.md guidance for a repository or component. Use when the user wants to clarify what Security should review, what is out of scope, which security properties must hold, or whether existing guidance still matches the code.
finding-discoveryUse when a security scan is already in its finding-discovery phase 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.
fix-findingUse 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.
propose-security-hardeningDevelop evidence-backed structural and architectural security hardening proposals from vulnerability disclosures, supplied findings, incident or assessment documents, source code, or a completed Security scan. Use when a user asks for systemic improvements, alternatives beyond per-finding patches, b
security-diff-scanUse when the user asks for a security review of a pull request, commit, branch diff, working-tree patch, or other Git-backed change set.
security-scanUse for a standard, single-pass security audit of an entire repository or a scoped path, package, folder, or submodule with no diff to review. This is the default repository scan. Do not use for PR, commit, branch, or working-tree diffs, or for deep, multi-pass scans.
threat-modelUse when a security scan is already in its threat-modeling phase, the user explicitly invokes security: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.
track-findingsTrack validated findings from a sealed Security scan directory in Linear, Jira, GitHub issues, or draft GitHub security advisories. The source must be a sealed scan bundle that passes validate_tracking_source.py. Use it for one finding or an explicitly selected batch of up to 25 findings tracked as
triage-findingUse when the user supplies or imports existing security findings, vulnerability reports, or security/vulnerability Jira/Linear tickets from scanners, advisories, GitHub, Jira, Linear, or similar backlog sources and wants static repo-impact triage. Do not use for discovery, duplicate-bug triage, vali
validationUse when a security scan is already in its validation phase or the user explicitly asks to determine whether one or more candidate security findings are valid. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
vulnerability-writeupWrite up vulnerabilities from disclosure documents, rough notes, supplied findings, PoCs, source code, or Security scan output into polished, self-contained, source-backed reports. Use for one vulnerability or a disclosure campaign; a Security scan is optional.