aw-review-quality-gate

name	aw-review-quality-gate
description	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".
disable-model-invocation	false
license	MIT
metadata	{"author":"mthines","version":"1.0.0","workflow_type":"advisory"}

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. Graceful skip: the workflow acts on the raw findings if this skill is not installed.
• After the 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.