# Aw Review Quality Gate

> Self-check quality gate for review findings. Validates that each finding is actionable, evidence-backed, correctly located, not duplicating linter output, and not a false positive. Use after generating findings but before delivering them. Triggers on: "quality gate findings", "validate findings", "gate my review", "/aw-review-quality-gate".

- Skill: `mthines/aw-review-quality-gate` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mthines/aw-review-quality-gate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mthines/aw-review-quality-gate/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- License: MIT
- Author: mthines (https://skillmd.com/u/mthines)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mthines/aw-review-quality-gate

---


# Review Quality Gate

Run this gate on every finding you have generated, **before** formatting output or delivering results.
The gate catches false positives, noise, and miscalibrated severity — the most common failure modes of single-pass review.

---

## When to Use

- As the `autonomous-workflow` Phase 6 review companion — invoked via `Skill()` after `review-changes` returns findings, before the workflow acts on them. See [`phase-6-pr-creation.md#findings-quality-gate`](../autonomous-workflow/rules/phase-6-pr-creation.md#findings-quality-gate). Graceful skip: the workflow acts on the raw findings if this skill is not installed.
- After the `pr-reviewer` agent generates findings (Step 2.5).
- After DX or UX review skills produce their finding lists.
- Any time a skill produces actionable recommendations that a human will read.

---

## Gate Checklist

For **each finding**, answer every question.
Be honest — a dropped false positive is worth more than a delivered one.

| # | Question | Fail means |
|---|----------|------------|
| 1 | **Is it actionable?** The author can do something concrete. No "consider", "might want to", or "could be improved" without a specific fix. | Finding is vague noise |
| 2 | **Did I read the surrounding code?** Not just the diff hunk — the full function, the caller, the guard clause three lines up. | Finding may be wrong |
| 3 | **Is severity calibrated?** A style nit is never "required." A SQL injection is never "suggestion." Re-check the severity assignment against the actual impact. | Severity is misleading |
| 4 | **Are file path and line number accurate?** Verify the cited location against actual file content. A finding pointing to the wrong line is worse than no finding. | Finding is unlocatable |
| 5 | **Does this duplicate linter/formatter/type-checker output?** If the project's toolchain would catch this automatically, do not flag it. Focus on semantic issues the toolchain cannot see. | Finding is redundant |
| 6 | **Is this actually true?** Re-read the function in full context. Check: is the "bug" handled elsewhere? Is the "unused import" used in a type annotation? Is the "missing null check" guarded by the caller? Is the "race condition" prevented by a lock you didn't notice? | Finding is a false positive |

---

## Gate Rules

| Check failures | Action |
|----------------|--------|
| **2 or more** | **Drop the finding entirely.** It is not worth the reader's time. |
| **Exactly 1** | **Downgrade severity by one level** (required → suggestion, suggestion → nitpick). Note which check failed. |
| **0** | Finding passes. Deliver as-is. |

When downgrading, append a brief note so the reader knows why:
> _(Downgraded: severity recalibrated — style concern, not a correctness issue.)_

---

## Output

After running the gate on all findings, emit a brief summary before the findings themselves:

```
### Quality Gate
- Findings reviewed: N
- Dropped: N (reason per drop)
- Downgraded: N
- Passed: N
```

List each dropped finding with a one-line reason so the reviewer can audit the gate:

```
- Dropped: "Missing error handling in fetchUser" — false positive, error is caught by caller middleware (check 6)
- Dropped: "Unused variable `config`" — linter would catch this (check 5) + not actionable without context (check 1)
```

---

## Anti-Patterns

- Do NOT skip the gate because "all findings look fine." Run it mechanically on every finding.
- Do NOT pass findings that say "consider" or "might want to" without a concrete fix. Rewrite them or drop them.
- Do NOT inflate the passed count by being lenient. The gate's value comes from its strictness.
- Do NOT run the gate on pre-existing issues. Those are informational and bypass the gate entirely.