Review gates

A gate is an explicit, binary criterion: the reviewer declares it PASS or FAIL before the pipeline moves to the next phase. Nothing implicit, nothing “by feel”.

Why — the problem it solves

Without written criteria, a review depends on the reviewer’s mood and memory. Gates make the review reproducible: every verdict rests on a checklist known in advance, shared by the producer and the reviewer. A failing gate blocks the transition (BLOCKER) or flags a risk (HIGH/MEDIUM) — never a vague feeling.

How to read this catalogue

Each phase has its own gate grid, checked by an independent reviewer organised into lenses (each lens groups the gates defending one quality). For every gate: its Gxx identifier, what it checks and its pass condition (binary).

The four artefact-review phases — DISCOVER, DISCUSS, DESIGN, DISTILL — also carry a severity, which says how a failed gate lands in the reviewer’s verdict:

DELIVER carries no such scale: every quality gate blocks. There is no advisory level, no warning level, no override and no rationale that buys an exemption — the skraft-quality-bar skill owns the enforcement level of every gate and the value of every threshold, and nothing downstream restates them.

Total: 48 gates across product workflows and engineering phases. What follows is the full grid, exactly as each reviewer applies it.

DISCOVER — G1 to G6

Reviewer: backlog-discoverer-reviewer. 3 lenses. Checks the triage report and the sprint proposal.

Lens 1 — Completeness

Lens 2 — Prioritization

Lens 3 — Duplicate detection

DISCUSS — G1 to G8

Reviewer: backlog-planner-reviewer. 4 lenses. Checks stories, acceptance criteria and the sprint plan.

Lens 1 — INVEST

Lens 2 — Acceptance-criteria quality

Lens 3 — Planning coherence

Lens 4 — Definition of Ready compliance

DESIGN — G1 to G15

Reviewer: solution-architect-reviewer. 3 lenses + 1 cross-cutting escalation gate. Checks ADRs, the supersession registry, diagrams, contracts, consistency matrices.

Lens 1 — Consistency

Lens 2 — Architecture compliance

Lens 3 — Fitness

Cross-cutting — Escalation

If G13 fails, the reviewer returns REJECTED immediately without evaluating other gates: the next action is human escalation, not a retry.

DISTILL — G1 to G8

Reviewer: acceptance-designer-reviewer. 4 lenses. Checks Gherkin scenarios, the test plan and the implementation plan.

Lens 1 — Coverage

Lens 2 — Business alignment

Lens 3 — Testability

Lens 4 — Boundary enforcement

DELIVER — G1 to G11

Producer: software-engineer; verifier: quality-gates-lens. Every gate is attested by falsifiable evidence (git SHA, tool output written to disk) the reviewer re-resolves without ever re-running the build.

Every gate below blocks, on every repository and every work item. The framework once carried a repo-wide strictness dial that could lower this grid — fewer reviewer lenses, a smaller mutation threshold, the Gherkin gate switched off. That dial is gone, and it was also the framework’s cost governor: every run now pays the full shape. The repository owner accepted that trade deliberately — quality is not negotiable.

G8 policy: inline commit rules in the existing agents, on both native clients (Copilot and Claude Code). No additional skill, validator or completion receipt.

• Message: type(feature): subject (optional ! before :), with the approved feature scope. Use git commit -s for the Signed-off-by trailer.
• Issue: for a known issue, end the body with Refs: #N for intermediate work or Closes #N only when the whole issue is genuinely finished and all required gates pass. A green slice or DESIGN alone does not close delivery. Omit the issue line when unknown.
• Verification: G8 checks covered Git messages and existing gate evidence. Missing verifiable evidence means inconclusive. The evidence v3 schema is unchanged; the standalone subject audit remains a syntax check, not proof of completion.

G6 is an exit code, not a number. Each quality-gates-<tech> adapter bundles two sequenced mutation scripts — mutation-core.sh then mutation-boundary.sh on .NET. Each script carries its own expected value and passes it to the runner’s --break-at, so the runner exits non-zero below the bar and that exit code is the verdict. Core runs first and short-circuits: there is nothing to learn from mutating adapters while the domain is unproven. A score read from a report and judged in prose is an opinion about a gate, not a gate — and G11 is attested the same way, by the coverage runner’s own threshold flags.

A genuinely irrelevant gate is marked not_applicable with a rationale — never as a substitute for fail or missing evidence. A gate that cannot run — no mutation runner installed, no SDK — is fail, never not_applicable.

Verdict logic

On the four artefact-review phases, the reviewer aggregates gates with a deterministic rule — no fuzzy weighting:

On DELIVER the rule is flat, because every gate blocks:

inconclusive is never equivalent to pass: absence of evidence is not evidence of success.

Why this practice

« A software inspection is a rigorous review with explicit entry and exit criteria. » — Wiegers, K., Peer Reviews in Software, 2002.

Explicit entry/exit criteria are exactly what a gate materialises: the phase is only “done” once its gates are crossed.

Pitfalls & anti-patterns

• Cosmetic gate: a criterion too vague (“the code is clean”) is not a gate — you need a verifiable binary test.
• Complacent reviewer: if the producer and the reviewer are the same person, the gate loses its power. SKRAFT mandates an independent reviewer.
• Short-circuit: some gates (e.g. DESIGN G13) short-circuit the whole review if an unresolved human blocker remains — do not bypass them.
• Negotiated bar: a DELIVER gate cannot be talked down. There is no strictness setting, no advisory level and no rationale that grants an exemption — a gate that did not pass has not passed.

Going further

• The adversarial review lenses
• Review before review
• The review-before-review deep dive

Sources

• Wiegers, K. Peer Reviews in Software, 2002.

Terms to know: gate, reviewer, BLOCKER, INVEST, walking skeleton — see the glossary.