project-quality-gates

Invoke with: the repository root (optional).

When to use

• a repo has tests but no coverage number, or tests nobody trusts
• review keeps catching formatting, dead code, duplication or conventions
• there is no CI, or CI only runs the build
• before handing a codebase to other agents, or before opening it up to contributors

Not for: fixing one lint error, or a project with no build or test step at all — scaffold those first (kernel-dev-build, kernel-dev-testing).

The one rule

A gate that is not honest gets fixed or deleted, never muted.

A warning nobody acts on is worse than no gate: it teaches everyone to scroll past. On the first run, every gate below must be either green or tuned with a reason written down at the point of the tunable. If a gate needs three suppressions to pass, the code is wrong or the gate is wrong — pick one.