Quick Summary

Goal: Enforce quality gates, verify compliance with standards, and track quality metrics across the development lifecycle.

Renamed: formerly /qc-specialist — that name no longer resolves as a slash command; use /quality-gate-review.

Workflow:

Identify Gate — Determine which quality gate applies (Idea>PBI, PBI>Dev, Dev>QA, QA>Release)
Verify Checklist — Run through pass/fail criteria for the gate stage
Generate Report — Produce PASS/FAIL/CONDITIONAL gate status with evidence
Track Metrics — Log in audit trail and update quality metrics dashboard

Key Rules:

Every gate must have a clear PASS/FAIL/CONDITIONAL status
Evidence must be provided for critical checklist items
Sign-offs are required before release gates can pass

Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).

Quality Gate Review

Enforce quality gates, verify compliance with standards, track quality metrics, and generate audit trails across the development lifecycle.

Core Capabilities

1. Quality Gates

Define pass/fail criteria at each stage:

Gate: Idea → PBI

Problem statement present
Business value articulated
No technical solution prescribed
Target users identified

Gate: PBI → Development

Acceptance criteria in GIVEN/WHEN/THEN
Out of scope defined
Dependencies identified
Design approved (if applicable)

Gate: Development → QA

Code review approved
Mutation score meets target; surviving mutants triaged (line-coverage diagnostic only — not a gate)
No P1/P2 linting errors
Documentation updated

Gate: QA → Release

All test cases executed
No open P1/P2 bugs
Regression suite passed
PO sign-off received

PO Acceptance Decision (per-AC verdict — how "PO sign-off received" is earned)

For each acceptance criterion from the PBI/story:

Read criterion — Ensure it's testable and measurable
Check evidence — Review test results, screenshots, demo recordings
Verify — Does the implementation satisfy the criterion?
Verdict — PASS or FAIL with specific evidence

Decision rules: Every acceptance criterion must have a PASS/FAIL verdict. REJECT must list the specific items that failed. CONDITIONAL ACCEPT must list conditions and a timeline.

## Acceptance Decision

**Feature/PBI:** {Reference}
**Reviewer:** {PO name/role}
**Date:** {date}
**Verdict:** ACCEPT | REJECT | CONDITIONAL ACCEPT

### Criteria Review

| # | Criterion | Verdict | Evidence |
|---|-----------|---------|----------|
| 1 | {AC text} | PASS | {Evidence} |
| 2 | {AC text} | FAIL | {Why it failed} |

### Decision Details
- {Rationale for overall verdict}

### Conditions (if CONDITIONAL)
- {Condition — deadline}

### Rejected Items (if REJECT)
- {Item — what needs to change}

Verdict Validation Gate (why-review — MANDATORY before emitting REJECT/CONDITIONAL or any FAIL criterion)

Purpose: ACCEPT/REJECT/CONDITIONAL is a JUDGMENT. Validate it adversarially before it is emitted so a wrong verdict or a mis-classified FAIL criterion does not gate a release on ground that does not hold. This gate validates the verdict only — it routes any required fix back to the owning team/sibling review, it does NOT self-converge a fix-loop.

Trigger: Any REJECT, any CONDITIONAL ACCEPT, or any criterion marked FAIL. Skip ONLY when every criterion PASSES with an unconditional ACCEPT.

Protocol:

Read the finalized gate report (the Acceptance Decision above) from plans/reports/{skill}-{date}-{slug}.md (or the exact report path written).
Invoke /why-review --validate-findings <report-path> — verify each FAIL criterion and each stated condition has file:line / evidence proof and clears why-review's finding-survival bar.
If why-review demotes/removes any FAIL criterion or condition: update the verdict and criteria table, then add a ## Why-Review Validation Notes section citing what changed and why.
If the verdict changed after validation: re-run this gate — maximum 2 validation passes — until the remaining FAIL criteria/conditions are validated. No fix-loop: this skill decides the gate and routes fixes to the owning team; it never restarts a full review over its own fixes.

Anti-bias (MANDATORY before emitting): steel-man the OPPOSITE verdict — argue for ACCEPT if about to REJECT, and for REJECT if about to ACCEPT; the verdict that survives its own counter-argument ships. A gate decision that was never challenged is not validated.

2. Compliance Verification

Code follows architecture patterns
Security requirements met
Accessibility standards (WCAG 2.1 AA)
Performance benchmarks

3. Audit Trail

Track artifact lifecycle:

{Artifact} | {Action} | {By} | {Date} | {Notes}

4. Quality Metrics

Code Quality

Cyclomatic complexity
Mutation score (line-coverage diagnostic only — not a gate)
Technical debt ratio
Duplication %

Process Quality

Defect escape rate
First-time-right %
Cycle time
Lead time

Quality Gate Checklists

Pre-Development Checklist

## Quality Gate: PBI Ready for Development

**PBI:** {PBI-ID}
**Reviewer:** {Name}
**Date:** {Date}

### Requirements

- [ ] Clear problem statement
- [ ] User value articulated
- [ ] Acceptance criteria in GIVEN/WHEN/THEN format
- [ ] Out of scope explicitly listed

### Design

- [ ] Design spec approved (if UI changes)
- [ ] API contract defined (if backend changes)
- [ ] Database changes documented (if applicable)

### Dependencies

- [ ] Upstream dependencies identified
- [ ] No blocking dependencies
- [ ] Integration points documented

### Gate Status: PASS / FAIL / CONDITIONAL

**Notes:**
{Any concerns or conditions}

Pre-QA Checklist

## Quality Gate: Ready for QA (Dev → QA)

**Feature/PBI:** {Reference}
**Reviewer:** {Name}
**Date:** {Date}

### Readiness

- [ ] All acceptance criteria implemented
- [ ] Unit tests passing
- [ ] Code review complete
- [ ] No known critical bugs
- [ ] Test data prepared

### Gate Status: PASS / FAIL / CONDITIONAL

**Notes:**
{Any concerns or conditions}

Database Performance gate (applies to all stages)

Database performance (pagination on all list queries; indexes on filter/FK/sort columns) — verified via /production-readiness-review and /performance-review

Pre-Release Checklist

## Quality Gate: Ready for Release

**Feature:** {Feature name}
**Release:** {Version}
**Date:** {Date}

### Testing

- [ ] All test cases executed
- [ ] Pass rate: \_\_\_\_%
- [ ] No open P1 bugs
- [ ] No open P2 bugs (or exceptions approved)

### Code Quality

- [ ] Code review approved
- [ ] Mutation score meets target; surviving mutants triaged (line-coverage reported as a diagnostic only, no threshold)
- [ ] No security vulnerabilities
- [ ] Performance benchmarks met

### Documentation

- [ ] User documentation updated
- [ ] API documentation current
- [ ] Release notes drafted

### Sign-Offs

- [ ] QA Lead: **\*\***\_**\*\*** Date: **\_\_\_**
- [ ] Dev Lead: **\*\***\_**\*\*** Date: **\_\_\_**
- [ ] PO: **\*\*\*\***\_\_**\*\*\*\*** Date: **\_\_\_**

### Gate Status: PASS / FAIL

**Release Decision:**
{Go / No-Go with notes}

Workflow Integration

Running Quality Gate

When user runs /quality-gate {artifact-or-pr}:

Identify gate type based on artifact/stage
Load appropriate checklist
Verify each criterion
Generate pass/fail report
Log in audit trail

Metrics Dashboard Template

## Quality Metrics - Sprint {N}

### Code Quality

| Metric         | Target          | Actual | Trend |
| -------------- | --------------- | ------ | ----- |
| Mutation score | meets target    |        | ↑↓→   |
| Line coverage  | diagnostic only |        | ↑↓→   |
| Complexity     | <15             |        |       |
| Duplication    | <5%             |        |       |
| Debt Ratio     | <10%            |        |       |

### Process Quality

| Metric            | Target | Actual |
| ----------------- | ------ | ------ |
| Defect Escape     | <5%    |        |
| First-Time-Right  | >90%   |        |
| Avg Review Cycles | <2     |        |

### Defect Trends

| Sprint | Found | Fixed | Escaped |
| ------ | ----- | ----- | ------- |
| N-2    |       |       |         |
| N-1    |       |       |         |
| N      |       |       |         |

Output Conventions

File Naming

{YYMMDD}-qc-gate-{stage}-{slug}.md
{YYMMDD}-qc-audit-{feature}.md
{YYMMDD}-qc-metrics-sprint-{n}.md

Quality Checklist

Before completing QC artifacts:

spec
code-review

[IMPORTANT] Use TaskCreate to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.

docs/project-reference/domain-entities-reference.md — Domain entity catalog, relationships, cross-service sync (read when task involves business entities/models)

AI Mistake Prevention — Failure modes to avoid on every task:

Re-read files after context changes. Context compaction, resume, or long-running work can make memory stale; verify current files before acting.
Verify generated content against source evidence. AI hallucinates APIs, names, claims, and document facts. Check the relevant source before documenting or referencing.
Check downstream references before deleting or renaming. Removing an artifact can stale docs, generated mirrors, configs, and callers; map references first.
Trace the full impact chain after edits. Changing a definition can miss derived outputs and consumers. Follow the affected chain before declaring done.
Verify ALL affected outputs, not just the first. One green check is not all green checks; validate every output surface the change can affect.
Assume existing values are intentional — ask WHY before changing OR flagging one as a defect. Before changing or reporting a constant, limit, flag, cutoff, wording, or pattern, read nearby context and history, the CALLER's ordering, and 2+ sibling call sites of the same convention. A doc stating WHAT without WHY is missing rationale, not proof of a missing guard.
Surface ambiguity before acting — don't pick silently. Multiple valid interpretations require an explicit question or stated assumption with risk.
Assert the outcome your system owns, not the intermediate state your infrastructure owns. When verifying async work, assert the final business state — never the delivery/retry bookkeeping held in shared infrastructure that any co-running process can write. Such a check passes when run alone and flakes the moment anything else shares that infrastructure.
Keep shared guidance role-relevant. Universal guidance must help every receiving skill or agent; code-specific obligations belong only in code-specific protocols.

Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act.
Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.

Sequential Thinking Protocol — Structured multi-step reasoning for complex/ambiguous work. Use when planning, reviewing, debugging, or refining ideas where one-shot reasoning is unsafe.

Trigger when: complex problem decomposition · adaptive plans needing revision · analysis with course correction · unclear/emerging scope · multi-step solutions · hypothesis-driven debugging · cross-cutting trade-off evaluation.

Format (explicit mode — visible thought trail):

1. Thought N/M: [aspect] — one aspect per thought, state assumptions/uncertainty
2. Thought N/M [REVISION of Thought K]: ... — when prior reasoning invalidated; state Original / Why revised / Impact
3. Thought N/M [BRANCH A from Thought K]: ... — explore alternative; converge with decision rationale
4. Thought N/M [HYPOTHESIS]: ... then [VERIFICATION]: ... — test before acting
5. Thought N/N [FINAL] — only when verified, all critical aspects addressed, confidence >80%

Mandatory closers: Confidence % stated · Assumptions listed · Open questions surfaced · Next action concrete.

Stop conditions: confidence <80% on any critical decision → escalate via AskUserQuestion · ≥3 revisions on same thought → re-frame the problem · branch count >3 → split into sub-task.

Implicit mode: apply methodology internally without visible markers when adding markers would clutter the response (routine work where reasoning aids accuracy).

Deep-dive: see /sequential-thinking skill (.claude/skills/sequential-thinking/SKILL.md) for worked examples (API design, debugging, architecture), advanced techniques (spiral refinement, hypothesis testing, convergence), and meta-strategies (uncertainty handling, revision cascades).

Goal Contract Satisfaction Loop — Persist the user goal in an external file, execute against it, and loop review/fix until every saved required criterion passes or a blocker escalates. Bounded closed loop — NEVER open-ended autonomous exploration.

1. Resolve the active goal (in order): active plan goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md → create a new Goal Contract from the current user request (template: .claude/templates/goal-contract-template.md).
2. Required sections: Original Request, Purpose, Success Criteria (checkboxes; mark required vs optional), Constraints, Evidence Required, Iteration Log, Goal Satisfaction matrix.
3. Before work: read the active goal and map planned work to saved success criteria — execution serves the saved criteria, never chat memory alone.
4. After execution/verification: append an Iteration Log entry — result, evidence references (file:line, command output, report path), remaining gaps.
5. Review gate: emit a Goal Satisfaction matrix — | Success Criterion | Evidence | Status | with PASS/FAIL/BLOCKED. Overall PASS requires every required criterion PASS.
6. Loop rule (retry): required criterion FAIL → validate the gap is real → fix → re-review only the affected criteria. Stop cleanly when all required criteria PASS.
7. Escalation rule (stop): two consecutive iterations with no criterion progressing, or a blocker needing user input → mark the criterion BLOCKED with a user-facing reason and escalate. NEVER loop indefinitely.
8. Skip rule: tiny conversational tasks may skip the goal file ONLY with a recorded one-line reason. User-accepted gate skips are recorded in the goal file with reason and scope.
9. Security: NEVER store secrets, tokens, credentials, or private customer data in goal files — store evidence references and redact sensitive values.

Blocked until: active goal resolved (or skip reason recorded) · saved success criteria read before edits · iteration evidence appended after execution · Goal Satisfaction matrix emitted before any PASS verdict.

Trade-Off Interrogation Gate — ALWAYS ask these THREE questions before ANY verdict, score, finding, or recommendation — about the thing under review AND about every recommendation YOU make. — why: naming a benefit without its price is an endorsement, not a review; the costliest trade-offs are the ones nobody wrote down.

1. Is there any trade-off? Name what it SACRIFICES. "None" / "pure win" is an unfinished analysis, NOT an answer — to claim none, state which dimensions you checked and why each is unaffected: future change cost · complexity · performance/latency · memory/cost · coupling · reversibility · migration burden · operational load · blast radius · security posture · testability · team skill/ramp · delivery time · UX.
2. Is it worth it? Weigh gain against sacrifice EXPLICITLY — what is gained (with a metric) · what it costs · WHO pays · WHEN it comes due — then emit WORTH IT / NOT WORTH IT / UNCLEAR. "Better" with no metric and no cost FAILS this question. NOT WORTH IT → withdraw or replace the recommendation, never keep it as-is.
3. Is the trade-off material enough to CONFIRM WITH THE USER? A material trade-off is the user's call, never yours. MATERIAL when ANY holds: irreversible / one-way door (data migration, public contract, storage format, vendor lock-in) · cost shifted onto someone else (another team, ops/on-call, future maintainer, end user) · one quality attribute traded for another (correctness↔speed, security↔convenience, latency↔cost, simplicity↔flexibility) · a boundary crossed (client↔server tier, service contract, event contract, shared library) · a high-consequence path (auth, money, data integrity, breaking change, High/Medium residual risk) · the worth-it verdict is UNCLEAR.

MATERIAL → STOP and confirm via AskUserQuestion BEFORE the verdict stands — state the trade-off, both options, what each sacrifices, and your recommendation. NOT material → record it inline with a one-line justification and proceed.

Non-asking execution contexts — ESCALATE BY HANDOFF, never by silence. AskUserQuestion reaches only the main interactive agent: a sub-agent cannot ask the user, and a terminal/verdict-only mode asks nothing by design. When you are running in such a context, the obligation is redirected, never waived — do ALL of: (a) complete questions 1 and 2 normally; (b) decide materiality and record it in the Trade-Off Assessment row with confirmed? = NO — cannot ask from this context; (c) name the unconfirmed MATERIAL trade-off explicitly in your returned summary/verdict so the CALLER (or parent orchestrator) escalates it via AskUserQuestion on your behalf — a material trade-off mentioned only inside a report file on disk is NOT a handoff; (d) do not emit an unqualified PASS — mark the verdict as carrying an unconfirmed material trade-off, so the caller's gate stays closed until the user answers. The caller inherits the escalation duty the moment it reads your return.

This carve-out is about reachability, not convenience: it applies ONLY where the tool genuinely cannot reach the user (spawned sub-agent, terminal validate/verdict-only mode, non-interactive/headless run). It is NEVER a licence to skip the question, to self-approve a one-way door, or to downgrade materiality because asking is inconvenient — if you CAN ask, you MUST ask.

Emit a Trade-Off Assessment row per reviewed decision and per recommendation: | decision | sacrifices | gain (metric) | who pays, when | WORTH IT/NOT/UNCLEAR | material? | confirmed? |.

BLOCKED until: trade-off named (or dimensions-checked justification given) · worth-it verdict emitted · materiality decided · every MATERIAL trade-off either confirmed with the user OR — in a non-asking context — handed off in the returned verdict for the caller to confirm. A MATERIAL trade-off that is neither confirmed nor handed off can NEVER be PASS, and NEVER gets buried as a Low-severity note.

NEVER answer "no trade-off" without checking · decide a material trade-off silently on the user's behalf · let convergence/delivery pressure authorize walking through a one-way door · bundle several material trade-offs into one vague "proceed?".

MUST ATTENTION apply critical + sequential thinking — every claim needs appropriate traced evidence (file:line for repo/code claims; source URL or artifact section for research, product, content, and docs claims); confidence >80% to act, <60% DO NOT recommend. Anti-hallucination: never present guess as fact, admit uncertainty freely, cross-reference independently, stay skeptical of own confidence.

MUST ATTENTION apply sequential-thinking — multi-step Thought N/M, REVISION/BRANCH/HYPOTHESIS markers, confidence % closer; see /sequential-thinking skill.

MUST ATTENTION apply AI mistake prevention — verify generated content against evidence, trace downstream references before deleting or renaming, verify all affected outputs, re-read files after context loss, and surface ambiguity before acting.

MANDATORY Resolve the active Goal Contract BEFORE work (active plan goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md → create from current request) and read saved success criteria before editing.
MANDATORY Append iteration evidence after execution; emit a Goal Satisfaction matrix (PASS/FAIL/BLOCKED) before reporting PASS; loop on validated FAIL; escalate repeated no-progress or blockers. NEVER store secrets in goal files.

MANDATORY MUST ATTENTION ALWAYS ASK THE 3 TRADE-OFF QUESTIONS — on the thing under review AND on every recommendation you make: (1) is there any trade-off? name what it SACRIFICES (change cost · complexity · perf · coupling · reversibility · migration · ops load · blast radius · security · testability · delivery time · UX) — "none"/"pure win" is an unfinished analysis, so state the dimensions checked; (2) is it worth it? gain (with a metric) vs cost, WHO pays, WHEN → emit WORTH IT / NOT WORTH IT / UNCLEAR; NOT WORTH IT → withdraw or replace it; (3) is it material enough to confirm with the user? irreversible/one-way door · cost shifted onto another team/ops/maintainer/user · one quality attribute traded for another · a tier/service/event/library boundary crossed · auth/money/data-integrity/breaking-change/High-or-Medium-risk path · verdict UNCLEAR → STOP and confirm via AskUserQuestion BEFORE the verdict.
MANDATORY A MATERIAL trade-off with no user confirmation can NEVER be PASS; NEVER bury one as a Low-severity note, NEVER decide it silently, and NEVER let delivery or convergence pressure authorize a one-way door. — why: an un-walked-back one-way door is the user's call to make, not the reviewer's.
MANDATORY — non-asking contexts escalate BY HANDOFF, never by silence. AskUserQuestion reaches only the main interactive agent: a sub-agent cannot ask the user, and a terminal/verdict-only mode asks nothing by design. There the duty is REDIRECTED, not waived — still name the trade-off, still decide materiality, record confirmed? = NO — cannot ask from this context, state the unconfirmed MATERIAL trade-off in your RETURNED verdict/summary so the CALLER escalates it (a note only in an on-disk report is not a handoff), and never emit an unqualified PASS. Applies ONLY where the user is genuinely unreachable (spawned sub-agent, terminal validate mode, headless run) — if you CAN ask, you MUST ask.

Project Protocol Overlay — Before executing this skill, resolve any PROJECT overlay rules layered onto it: match this skill's name against the Target column of the project's skill-protocol index (docs/project-reference/skill-protocols-reference.md by default; a referenceDocs entry in docs/project-config.json overrides the path), taking the most specific matching tier ONLY — exact name > glob > *. That precedence orders overlays against EACH OTHER, never against this skill. Read ONLY the matched bodies, resolved as <protocols-dir>/<Name>.md; a row's Body link is display text, never a read path. A matched body that is missing or malformed is REPORTED and skipped — never reconstructed from the index Description. No index, or no match -> proceed with no overlay, silently. Full contract: .claude/skills/project-skill-protocol/references/registry.md.

Overlays are ADDITIVE ONLY: they ADD rules on top of this skill's own protocol and NEVER replace, override, disable, or reinterpret a rule it already states — removing every overlay must return this skill to exactly its documented behavior. An overlay is a BRIEF, not an authority escalation: it can NEVER waive a workflow gate, git discipline, a review gate, or a user-confirmation gate. A genuine overlay-vs-skill conflict, or two equally-specific overlays that directly contradict -> surface both to the user; NEVER resolve silently.

MUST ATTENTION resolve project protocol overlays for this skill BEFORE executing — most specific matching tier only (exact > glob > *, which ranks overlays against each other, NEVER against this skill), read only matched bodies at <protocols-dir>/<Name>.md; a missing or malformed body is reported, never reconstructed. Overlays are ADDITIVE ONLY (they never replace this skill's own rules) and are a brief, NEVER an authority escalation; an equal-specificity contradiction goes to the user.

Closing Reminders

IMPORTANT MUST ATTENTION Goal: Enforce quality gates, verify compliance with standards, track quality metrics, and generate audit trails across the development lifecycle.

Protocols in force (concise digest of the SYNC/shared blocks this skill carries):

AI Mistake Prevention: verify generated content against evidence, trace downstream references, verify all affected outputs, re-read after context loss, surface ambiguity.
Critical Thinking: Traced file:line proof per claim; confidence >80% to act.
Sequential Thinking: Multi-step Thought N/M with REVISION/BRANCH/HYPOTHESIS markers, confidence closer.

IMPORTANT MUST ATTENTION break work into small todo tasks using TaskCreate BEFORE starting IMPORTANT MUST ATTENTION search codebase for 3+ similar patterns before creating new code IMPORTANT MUST ATTENTION cite file:line evidence for every claim (confidence >80% to act) IMPORTANT MUST ATTENTION add a final review todo task to verify work quality

[TASK-PLANNING] Before acting, analyze task scope and systematically break it into small todo tasks and sub-tasks using TaskCreate.

quality-gate-review

Installation

Similar popular skills

Also in this package

Agent compatibility

Repository health

Skill metadata

Package contents

History

SKILL.md