agentic-gates

Tier-aware CI meta-gates for agentic engineering: quality, supply-chain hygiene and spec traceability that cannot silently regress.

How it runs

One order at the front, one approval at the end

Between those two moments nothing waits for a person. Every step is a check that either passes the change on or stops it. The two dashed boxes are the question round, before anything binds.

you

Order

What should exist, and the approvals along the way.

round 1

Project charter

The question round: what do we actually want?

round 2

Architecture proposals

Proposed, walked through and decided with you.

01

Write the spec

What to build, in requirements and scenarios.

02

Write the code

The spec stays as it is while the code is written.

03

Write the tests

The code stays as it is while the tests are written.

04

Re-think

The AI optimizes its own code, in the same context window.

05

Pre-push battery

All gates, on the machine, before anything leaves it.

06

PR checks

The same gates again in CI, in parallel.

07

Merge queue

Integration test against the full matrix.

08

main

Single source of truth. Green is the only way in.

09

Gate report

Per pull request, and a dashboard over time.

The report goes back to you. That is the second and last human moment.

Shared stores: every check reads from here

Architecture

The result of the proposal round: cut, style, prohibitions. It binds once you have approved it.

Spec shelf openspec/

Every finished spec lands here with all its requirements and scenarios. The checks hold the code against them.

Rulebook security/

Which check applies, from when it blocks, and which defects are already known.

Two ways in

In your pipeline, or on your machine

The same gates in both places. What blocks a pull request has already blocked the commit locally, so a red pipeline is a surprise rather than a routine.

Route 1, git

One reference in your workflow

Your pipeline calls ours. Nothing is copied into your repository, and an update reaches you by moving one version pin.

# .github/workflows/gates.yml
jobs:
  gates:
    uses: ...   # pinned to a version
    with:
      spec-root: .

Route 2, your machine

The battery before the push

The same checks locally, at the point where a fix is cheap. This is what the pre-push step in the run above does.

Two commands: the full battery of gates for the tier you are on, and the drift check that holds the spec and the code against each other. Same checks, same answers as in CI.

Later

Over the network

Hand over a repository and receive the same gate report back, for pipelines that are not GitHub. Not part of the first release.

What comes back

One report per pull request: which gate ran, what it read, what it found, and from when a finding blocks. The same report feeds a board across all your repositories, so a gate that is quietly weakened shows up as a line that stops moving.

The board

A dash means not measured

Every figure on the board is read from the pipeline itself, so a repository publishes nothing to appear on it. Where a value has not been measured yet the cell stays a dash. It is never filled with a zero, because a zero reads as an all-clear that nobody checked.

Example board

Repos23
with CI19
gated server-side17
last run red of 21 readable1
PRs open in 21 of 237
Coverage87%
Test strength74%
Gate Answer Duration
Secret scan green 4s
Dependency and license scan green 16s
Spec drift red 3s
Conventions green 12s
Test strength 74% of mutants killed, floor 60% green 6m 08s
Structure drift no evidence file for this run yet

not measured. The board names the cause and what closes it, so the gap is a task rather than a mystery.

Launching soon on GitHub Marketplace and PyPI

Written up in detail: Spec Coding on the betteryields blog