菜单
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.
Use when a value (project id, model, threshold, rubric) would be duplicated across Makefile, scripts, docs, and code — collapse to one source.
| name | adversarial-lens-review |
| description | Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it. |
Cooperative review confirms what the author already believes; adversarial review tries to break it. An author who reviews their own work grades against their own blind spots — everything looks compliant because they wrote it to look compliant. The fix is structural, not attitudinal: put the artifact in front of a reviewer with no context from writing it, whose only job is to find what's wrong, through a specific named lens.
At the spec-to-plan, plan-to-code, and code-to-merge gates — anywhere an artifact needs to be trusted before the next hard-to-reverse step. This hardens the "gate each phase behind review" step of spec-driven-development into a concrete, binding protocol.
Red-flag thoughts that mean STOP and apply this skill:
| Artifact | Named lenses (one fresh reviewer each) |
|---|---|
| spec | factual-grounding, completeness, design-flaw/race-condition, testability |
| plan | spec-coverage, testing-and-trackability, sequencing-and-anti-hubris |
| implementation | spec-compliance, THEN code-quality |
For implementation, run spec-compliance first, then code-quality — they catch different bugs: compliance asks "did you build what was specified," quality asks "did you build it correctly." Running them out of order lets a style fix quietly bless a missed requirement. The sequencing-and-anti-hubris lens enforces that every bare constant or threshold in a plan carries its selection logic — "why 7 retries, not 3" — not just a number that felt right.
[BLOCKER|MAJOR|MINOR] <location> — <problem> → <suggested fix>, plus a one-line verdict per reviewer. This is what makes findings actionable and comparable across review rounds.A reviewer who wrote the artifact cannot see past their own framing — they will re-derive the same reasoning that produced the artifact and confirm it, because that reasoning is invisible to them as a choice. A fresh reviewer with a named lens has no such blind spot for that specific failure class, because the lens is the only thing they were asked to look for. Splitting the row into named lenses also guarantees coverage that a single "does this look right" pass reliably misses: a reviewer asked generically to review a plan will gravitate to whatever catches their eye, not systematically to sequencing, coverage, and trackability in turn. Severity grading turns a wall of comments into a triage list, and the re-review loop is what catches the possibility that a fix for one finding introduced another.
Adapted from cmanaha/extended-superpowers (MIT) and rewritten here as an agent-agnostic protocol: any reviewer capable of reading the artifact and returning severity-graded findings can fill a lens — a separate agent session, a different model, or a human colleague — with no reference to a specific hook mechanism, marketplace, or bundled reviewer agent. On a migration plan, a sequencing-and-anti-hubris pass once caught a hard-coded retry_count = 7 with no comment explaining the choice; the fix wasn't a different number, it was one line tying the count to the provider's documented rate-limit window. On a spec, a design-flaw lens found that two of the plan's steps both wrote the same record with no ordering guarantee between them — a race the author hadn't seen, because while writing the doc they'd mentally serialized the two writes without realizing nothing in the system actually enforced that order. Neither finding would have surfaced from one reviewer skimming for "does this look right"; each came from a lens whose only job was that specific failure class.
What a machine can check: the protocol, not the insight. Phase advancement blocked while any BLOCKER or MAJOR lacks a recorded resolution; findings parseable in the one severity-graded shape, with MINORs carried forward under explicit dispositions; and in agent setups the dispatch itself — one fresh reviewer per lens in the artifact's row, spec-compliance strictly before code-quality. The quality of a refutation is judgment; the completeness of the row is not.