Removing Redline

redline remove does this in one step and opens the pull request for you. The rest of this page is the manual path, and it is written out in full deliberately: redline init writes into files you already own and changes settings on your host, so “how do I back this out” deserves an answer you can read and check rather than a command you have to trust.

The order of work

1. git checkout -b redline/removeRemoval is a change to how this repository is reviewed and merged, so it goes through review like any other. redline init opens its own branch for the same reason.
2. Delete the files Redline owns wholeEverything under the redline- prefix, the rendered command files, and the gate caller workflow. Nothing in them was written by a human.
3. Strip the REDLINE blocks from the merged filesAGENTS.md, CLAUDE.md, .github/copilot-instructions.md and the pull request template are shared with your own content. Delete the marker pair and everything between it; leave every other byte.
4. Delete .redline.jsonThis is the file that says the repository is onboarded. Until it is gone, verify and the central registry both still count this repository as part of the estate.
5. Undo the host settings that are Redline'sThe branch ruleset entry, the labels, the repository property. Not the security floor — see below, it is the one part you almost certainly want to keep.
6. Open the pull requestOn an advisory repository the gate runs on this pull request and reports; it is the last thing it reviews. On a blocking one the required check has to come out before the pull request is opened, or nothing publishes it and nothing merges.

Files Redline owns whole — delete them

These are generated end to end. Nothing in them came from your repository, and the redline- prefix is what makes them identifiable: it is the same prefix render() prunes on when a stack leaves your profile.

Only the vendors your organisation has enabled ever wrote anything, so expect gaps in this list rather than a clean sweep. Every vendor listed below is enabled on the manifest as it ships today. Check .redline.json — it records the vendors this repository actually rendered.

Files that are yours — strip the block only

These files are shared. Redline writes into them between two marker lines and never touches a byte outside that span — that is the whole reason the markers exist. Removing Redline means deleting the marker pair and everything between them, and leaving the rest of the file exactly as it is.

# Checkout service
Your own notes, untouched by every redline run.

<!-- REDLINE:BEGIN — generated by Redline. Do not edit inside this block. -->
…everything here is Redline's — delete it…
<!-- REDLINE:END -->

More of your own notes, also untouched.

• AGENTS.md — the composed standard: core rules plus every stack in your profile. Usually the largest block.
• CLAUDE.md — four lines that import AGENTS.md.
• .github/copilot-instructions.md — the core standard for Copilot code review.
• The pull request template — .github/pull_request_template.md, or wherever your host resolves one. Same marker rule; see below.

If nothing but the markers was ever in the file — no notes of your own above or below the block — delete the file. That is exactly what Redline itself does when a vendor is deselected — strip the block, and remove the file if nothing is left.

The pull request template

Created, never taken over. A template your repository wrote for itself is not Redline's to edit, so there are four cases and only two of them leave you anything to undo:

• You had no template. Redline wrote the packaged one whole. Delete the file.
• You had one that already answered the gate. Redline left it untouched and there is nothing to undo.
• You had one that did not answer the gate. Redline still did not edit it. The install named the sections it lacks — ## Launch readiness, ## Architecture decision — and said the checklist job will fail until someone adds them or the gate is deselected. Nothing to undo; the file is entirely yours.
• Your template carries a REDLINE block. Redline put it there on an earlier run, and refreshes only what is inside it. Strip the block and keep every other byte.

On Azure DevOps, check the branch-specific templates too — anything under a branches/ folder inside pull_request_template/, in .azuredevops/, .vsts/, docs/ or the repository root. Azure serves those in preference to the default, so redline init considers every one it finds — under the same four cases above, which for a template you wrote means it is reported and left alone.

.github/CODEOWNERS

Seeded only if you asked for it, and only if this repository had none. Ownership is off by default — it is written when redline init --with review-ownership selects it, because the generated file names an owner Redline cannot prove exists and a ruleset requiring code-owner review with an unresolvable owner blocks every pull request in the repository. Where it is selected, redline init looks for .github/CODEOWNERS, CODEOWNERS and docs/CODEOWNERS; if any of the three exists the file is reported as already present, left untouched and Redline never writes ownership at all. So a pre-existing CODEOWNERS is not Redline's and must not be deleted.

The tell is the first line. A seeded file opens with # Managed by Redline. and then names one owning team against the sensitive paths — workflows, the rendered standards, infra/, Dockerfile. A file that does not open with that line was yours before Redline arrived.

.redline/local.md

Yours, entirely. Redline reads this file and renders a copy of it inside the block in each artifact; it never writes it, never prunes it and never fails a run over what is in it. Stripping the blocks removes the copies. The source file stays unless you delete it yourself.

.redline.json — what deleting it means

This is the file that makes the repository onboarded, and deleting it is what makes the removal real rather than cosmetic.

• redline verify stops recognising the repository. It reports a single finding — no .redline.json — run: npx redlinegate init — and exits 2, a usage error, not drift.
• Central discovery reads .redline.json from the default branch of every repository in the org. With the file gone this repository is simply not in the registry, and stops appearing in coverage and drift reporting.
• It also carries onboardedAt, the recorded menu, the pending-admin list and the content ids of the command files. All of that is gone with it — a later redline init would start from nothing and read as a fresh onboarding.

Host settings

None of these live in the repository, so no pull request removes them. They are split here into the ones that are Redline's and the ones that only arrived with Redline.

Keep these

Secret scanning, push protection and dependency alerts are an organisation-wide security floor. They are additive host settings — they displace nothing else the repository runs — and they have nothing to do with code review standards. Removing Redline is not a reason to turn them off. The CLI itself refuses --skip security-floor by name for exactly this reason, rather than quietly recording an opt-out.

Remove these

On Azure DevOps the equivalents are branch policies whose display name starts Redline: — the minimum-reviewers, comment-resolution, gate-status and gate-build policies — plus the build definition redline-gate in the \Redline folder. A policy of the same type without that prefix is a human's and was never touched by Redline.

Do it as a pull request

Onboarding never pushes to your default branch, and removal should not either. Everything above except the host settings is a file change, so it goes on a branch and through review — which is also the only way the rest of the team finds out that the standard they have been reviewing against is gone.

$ git checkout -b redline/remove
$ git add -A
$ git commit -m 'chore(redline): remove Redline from this repository'
$ git push -u origin redline/remove
  on an advisory repo the gate still runs here — it is the last thing it reviews

Once it has merged, take out what is left on the host: the ruleset, the redline=onboarded property, the three labels. Leave the security floor on.