菜单
Fix vulnerabilities identified by /security:review using the Fix-Verify Loop. Use when: user says "fix security findings", "remediate vulnerabilities", or invokes /security:fix with a report path. Requires an existing security review report as input. Modifies source code — explicit opt-in only.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Project-specific commit message format (verb-led, sentence case, single line, no conventional-commits prefix). Use when drafting a commit message, staging changes for commit, amending, squashing, or when user asks to commit, or runs git commit.
Evaluate, benchmark, compare, and optimize descriptions for existing skills. Use when users want to run evals to test a skill, benchmark skill performance with variance analysis, do blind A/B comparisons between skill versions, or optimize a skill's description for better triggering accuracy. Do NOT use for creating skills from scratch — see write-a-skill for that.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices, saved as a local Markdown file in docs/plans/. Use when user wants to break down a PRD, create an implementation plan, plan phases from a PRD, or mentions "tracer bullets".
Write a structured PRD from design decisions, rough ideas, or conversation context. Use when user wants to write a PRD, create requirements, document a feature spec, or bridge design decisions into a product requirements document. Bridges the gap between design exploration (grill-me) and implementation planning (prd-to-plan).
Load when performing dual-source security review, cross-validating Semgrep findings with Codex, or resolving conflicting vulnerability assessments. Trigger on: security audit, scan vulnerabilities, cross-validate findings, conflict resolution, confidence scoring.
基于 SOC 职业分类
| name | security-fix |
| description | Fix vulnerabilities identified by /security:review using the Fix-Verify Loop. Use when: user says "fix security findings", "remediate vulnerabilities", or invokes /security:fix with a report path. Requires an existing security review report as input. Modifies source code — explicit opt-in only. |
| disable-model-invocation | true |
| argument-hint | <report> [--finding <id>] [--deep] [--dry-run] [--yes] |
| allowed-tools | ["Read","Grep","Glob","Bash(git *)","Write","Edit","mcp__plugin_semgrep-plugin_semgrep__semgrep_scan","mcp__plugin_semgrep-plugin_semgrep__semgrep_scan_with_custom_rule","mcp__plugin_semgrep-plugin_semgrep__get_abstract_syntax_tree","mcp__codex__codex","mcp__codex__codex-reply"] |
Fix vulnerabilities identified in a /security:review report using the convergence-hardened Fix-Verify Loop (Section 4 of security-review-protocol).
This command modifies source code — it is never auto-triggered.
Fix-verify requires:
Delegating to a subagent would create a "telephone game" (handoff loses context fidelity) and hide the confirmation flow in a black box. Per our subagent best practices: split by context boundaries, not by roles.
/security:fix <report> [options]
<report> # Required: path to a security review report
--finding <id> # Fix only a specific finding (e.g., F-003).
# Note: if this finding shares a root-cause cluster
# with other findings, only this finding is fixed —
# sibling findings are skipped. The root cause may
# remain partially addressed.
--deep # Enable round 3 of fix-verify (default: 2 rounds)
--dry-run # Show fix plan without modifying files
--yes # Skip per-fix confirmation prompts
1. /security:review # Read-only audit → produces report
2. (User reviews report)
3. /security:fix .agents-output/security/2026-03-31-auth-security-review.md
# Or target a specific finding:
/security:fix .agents-output/security/2026-03-31-auth-security-review.md --finding F-003
<report> path--finding <id> specified, filter to that finding onlyGroup findings by root-cause cluster. A single root cause may manifest across multiple call sites. Order clusters by severity (CRITICAL first, then HIGH, then MEDIUM).
For each root-cause cluster, execute Section 4 of the security-review-protocol skill (4.1 through 4.7). The protocol defines the full logic — do not deviate from it.
Additional constraint for this command: Before applying each fix (after writing the prediction block per 4.2), display the prediction summary and wait for user confirmation. Skip this gate only if --yes was passed. The protocol itself does not enforce this gate — it's a command-level safety layer because /security:fix runs in the main conversation where user interaction is possible.
Append the ## Fix-Verify Hypothesis Log to the original security review report per Section 4.6 of the protocol.
When --dry-run is specified:
By default, before each fix is applied:
With --yes, skip confirmation prompts (use for trusted canonical fixes).
| Mode | Max Rounds | When to Use |
|---|---|---|
| Default | 2 | Covers ~90% of issues, low hypothesis drift risk |
--deep | 3 | CRITICAL findings, Round 3 uses fresh Codex session |
/security:review — Run the read-only audit that produces the report this command consumes/security:status — Check background review job status--yes skipped) every applied fix.agents-output/security/*.md file — the skill parses its structured format (Executive Summary, findings sections). Arbitrary markdown files will fail silently or extract zero findings/security:review first if the report is old--dry-run still calls Codex to get fix proposals (read-only) — it costs tokens even though no files are modified. The savings are only in skipping the apply+verify cycle--yes bypasses the user confirmation gate entirely. Only safe for well-understood canonical fixes (CWE-89, CWE-79, etc.). For Codex-proposed fixes, always let the user review the prediction block--finding <id> targets a finding that shares a root-cause cluster with other findings, only the specified finding is fixed — sibling findings in the same cluster are skipped. This may leave the root cause partially addressedsecurity-review-protocol Section 5/security:review for that)