菜单
Use before calling moe.complete_step on the final step of a task, and again before moe.complete_task. Forces you to read your own diff as an attacker, not an author. Catches concurrency bugs, null-deref, embarrassing assumptions before QA does.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when writing, reviewing, or debugging modern C++ (C++11 and beyond) — .cpp/.cc/.cxx/.h/.hpp files, CMake builds, smart pointers, RAII, move semantics, templates, STL, or concurrency.
Use before referencing any function, model, method, relationship, constant, or import in a plan or implementation. Verifies things actually exist in the codebase before building on top of them. Eliminates an entire class of hallucinated-API bugs.
Use when an architect is turning an epic into a set of tasks (moe.create_task), before planning any single one. Covers where to cut the seams, how to size and order tasks, what each task's Definition of Done must carry, and the mandatory final integration-and-hardening task. Distinct from moe-planning, which plans the steps inside one task.
Use when an architect is turning a Moe task into an implementation plan via moe.submit_plan. Provides the canonical 8-phase template (plan, explore, tests, minimum impl, verify, document, adversarial review, QA loop), rules for when to skip phases on trivial tasks, and where the verification gate belongs — once at the end of a task, and at full scope only on the epic's final task.
Use when reviewing a task in REVIEW status as the QA agent. Provides the structured decision flow for moe.qa_approve vs moe.qa_reject, with rejectionDetails that drive a clean fix on the worker side.
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
| name | adversarial-self-review |
| description | Use before calling moe.complete_step on the final step of a task, and again before moe.complete_task. Forces you to read your own diff as an attacker, not an author. Catches concurrency bugs, null-deref, embarrassing assumptions before QA does. |
| when_to_use | Worker, on the final step of a task, before complete_step or complete_task. |
| allowed-tools | Read, Grep, Bash(git diff:*), Bash(git log:*) |
You wrote the code. Now read it like someone who wants to break it.
Run git diff (or git diff main...HEAD if you've committed). Print the diff. Read it top to bottom not as the author who knows what was intended, but as a hostile reviewer who assumes nothing.
This runs once per task, at the end — not after each step. On a mid-epic task, the diff you review is your own task's. On the epic's final task, widen it to the whole epic's diff: that's the pass that has to catch what the individual slices couldn't see about each other.
Before moe.complete_step on the final step or moe.complete_task, walk every item:
SELECT ... FOR UPDATE or an equivalent?Infinity? NaN?', ;, --, <script>, ${)?For each item that triggers concern:
complete_step. A bad fix is better than no fix; an explicit "we'll handle this in follow-up" is better than silence.summary field on complete_step so QA knows you considered it.moe.add_comment on the task, or moe.report_blocked if it changes the design.Tests verify behavior you thought to write. Adversarial review catches behavior you didn't think to write. Concurrency races, null-deref on optional fields, hard-coded category strings instead of the enum that was just added, missing cleanup on error paths — these almost never have a failing test before review, because the author didn't write one. They show up in postmortems instead.
Doc-only changes, single-line config tweaks, trivial typo fixes. For anything touching logic, IO, or state — run the full checklist. It takes three minutes and prevents the kind of bug that costs three days.