菜单
Defines strict review-then-fix authority for reviewers. Use when a reviewer is allowed to repair findings after review, when avoiding reviewer-as-stealth-builder drift, or when verifying that fixes stay limited to documented findings.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | reviewer-fix-mode |
| description | Defines strict review-then-fix authority for reviewers. Use when a reviewer is allowed to repair findings after review, when avoiding reviewer-as-stealth-builder drift, or when verifying that fixes stay limited to documented findings. |
Use this skill when reviewers are allowed to fix issues they find.
Reviewer-fix mode is useful, but only if the review happens first and the fix scope is locked to documented findings.
### HIGH-1: [summary]
- Evidence: file.py:LN
- Regression analysis: if X changes, which test catches it?
- Fix scope: exactly what may change
## Reviewer-fix mode report
### Fixed findings
- HIGH-1: [what changed]
### Changed files
- path/file.py
### Verification
- command: result
- runtime/API/browser proof: result
### Out of scope
- [things noticed but not fixed]
### Remaining risk
- [none / listed]
Allowed:
Not allowed without orchestrator approval:
The orchestrator checks:
Stop and return to orchestrator if:
Preserves useful state across long agent sessions, context compaction, handoffs, and restarts. Use when compressing context, handing work between agents, resuming after interruption, writing session summaries, or preventing repeated work.
Enforces a design/spec approval gate before production implementation. Use when UI, UX, product flows, architecture, API shape, prototypes, visual direction, or user-facing behaviour need signoff before builders write production code.
Keeps agent work safe in messy repositories. Use when git status is dirty, unrelated files exist, generated artefacts are present, multiple agents share a repo, or you must commit only the intended slice without damaging someone else's work.
Proves model and provider capability claims before changing agent defaults. Use when swapping models, checking context windows, reasoning effort, tool use, streaming, media support, OAuth entitlement, fallback behaviour, or provider-specific runtime paths.
Converts bug reports, screenshots, user panic, QA notes, and vague complaints into durable engineering briefs. Use when turning observed failures into reproducible issues with severity, expected behaviour, evidence, scope, owner, and acceptance tests.
Defines safe sandbox-to-production promotion gates for agent-built software. Use when deploying, restarting, promoting builds, validating runtime surfaces, checking rollback readiness, or proving that the running production artefact matches the reviewed source commit.