review-scope-guard
Review Scope Guard
Overview
A scope-aware triage skill that sits between a review tool and a user-facing summary. It takes a list of review findings, a Definition of Done (DoD), and optional explicit project context, classifies each finding into one of four action categories, and maintains a rejected-findings ledger so the same complaint is never re-litigated across cycles. The skill never applies fixes itself — it only decides which findings are worth escalating and which should be suppressed.
This skill exists because adversarial review tools (including codex's adversarial-review) are calibrated for "correctness gaps from a theoretical ideal", not "impact on the stated scope". Without a scope filter the implementer chases edge cases and semantic implementations that were never in scope, then reverts them. A 19-cycle curl-import session that reverted ~50% of its Phase 2-3 additions is the empirical baseline this skill is designed to prevent.
Language
All user-facing output is rendered in the user's language (the language the user has been using in the conversation, or as configured in the Claude Code system-level language setting). This section is the authoritative translation contract — any per-language sample reference (e.g. references/output-samples.ja.md) is illustrative only and MUST NOT contradict these rules.
Translate into the user's language:
- Section headings and column labels (target-language equivalents of
Category/Rationale/Action) - Free-text fields Claude authors:
rationalebody,recommended_actionvalues, stop-signal evidence prose, next-action hints, degraded-mode warnings AskUserQuestionquestion,header, and optionlabel/descriptionfields (e.g. during DoD interview)
Keep verbatim (do NOT translate), regardless of user language:
More from adhi-jp/agent-skills
codex-review-cycle
Use when the user explicitly asks to run an iterative Codex review cycle on a non-empty git diff, including working-tree changes, current branch vs base, explicit commit/tag/branch refs, code diffs, or Markdown planning documents. Do not use for one-shot reviews, auto-hardening, background checks, plan drafting, or empty review targets.
34writing-style-guide
Use when generating or editing user-facing prose, including docs, comments, READMEs, changelogs, commit messages, PR descriptions, and chat replies.
32minecraft-modding-workbench
>
22review-fix-cascade-guard
Use when applying user-selected review findings after scope triage, especially inside codex-review-cycle or after a standalone Codex adversarial review, and a line-scoped fix may create follow-on valid findings. Do not use for ordinary edits, plan drafting, single-shot lint, no-review contexts, or generic refactor checklists.
19vibe-planning
>
17vibe-plan-execution
Use when the user asks to execute, implement, continue, or apply an existing implementation plan, specification, acceptance criteria, task plan, or vibe-planning output. Do not use for plan creation or coding requests with no concrete plan to bind.
17