| name | lean-regression-gate |
| description | Gate CI on sustainability regressions — compare a fresh audit's findings against a committed baseline findings file and fail the build (or warn) when new high-severity findings appear. Use this skill whenever the user wants sustainability checks in CI/CD, asks to "fail the build if we get less green", wants a merge check for efficiency regressions, or mentions enforcing green budgets automatically. Part of Lean Agentic AI Skills; a transformer designed to run headless in pipelines. |
Green Regression Gate
Transformer skill built for CI. Input: a baseline lean-findings.json (committed to the repo) + a fresh audit of the same subject. Output: a pass/warn/fail verdict with a machine-readable summary and a human-readable comment block (for PR comments).
Performance budgets made speed a merge-time concern; this makes efficiency one. The gate's job is narrow: detect regressions against an agreed baseline — it is not a linter that blocks on pre-existing debt.
Gate policy (default, overridable per repo)
- FAIL — any new high-severity finding (present in fresh audit, absent from baseline).
- WARN — new medium findings; severity escalations on persisting findings; loss of a
passed item.
- PASS — no new findings at/above threshold; resolved findings noted with congratulations kept to one line.
- NEUTRAL/SKIP — scope mismatch between baseline and fresh audit (different methodology depth): the gate must skip with an explanation rather than fail on incomparable data. A gate that fails for tooling reasons erodes trust in one sprint.
Procedure
- Reuse findings-diff mechanics for matching and classification (same id-matching and scope-comparability rules).
- Apply the policy. Emit: exit-code semantics (0 pass, 1 fail, 78 skip), a compact JSON verdict (
{verdict, new_findings[], escalations[], resolved[]}), and a markdown comment block listing each blocking finding with its evidence and fix — actionable in the PR, not just red.
- Baseline lifecycle: on intentional acceptance of new debt, the fix is updating the committed baseline in the same PR with a stated reason — the gate should explain this path in its failure message so teams aren't stuck.
Setup guidance (when asked to design the pipeline step)
Producer audit runs first in CI (e.g. web-carbon-audit on the built site preview, lean-ci-audit on workflow changes), gate runs second; baseline lives at a conventional path (.green/baseline.lean-findings.json). Keep the audited subject deterministic (built artifacts, not live prod) so the gate is reproducible.
Honesty rules
The gate never blocks on directional-impact wording or unmeasured claims — only on the presence/severity of findings, which are evidence-backed by contract. False-positive escapes matter: the skip-on-scope-mismatch rule and the baseline-update path are mandatory parts of any setup this skill designs.
Not this skill's job
Producing the audit (producers), longitudinal reporting (findings-diff + lean-dashboard), CI pipeline efficiency itself (lean-ci-audit).
