Onboard a repo

1. Your first finding

Write a file that looks like a normal afternoon's work, and watch Redline name four problems in it, with no model call.

Start a branch

terminal
$ git checkout -b feat/load-user

Create the file

Save this as src/user.ts, creating src/ if your repository has none. Every line of it is something an assistant writes when it is told to make the error go away.

src/user.ts
type User = { id: string; name: string }

// TODO: handle retries
export function loadUser(raw: string) {
  // @ts-ignore
  return JSON.parse(raw) as unknown as User
}

export type Payload = unknown

Stage it

Redline reviews a diff, and a file git does not track yet is not in one. Skip this and the review stops with there is nothing to review — the diff is empty.

terminal
$ git add src/user.ts

Run the review

terminal
$ npx redlinegate@latest review
profile javascript-typescript — rules in scope: core, typescript
src/user.ts:3
  Redline/HIGH [core/untracked-todo]: this TODO carries no ticket reference, so nothing will bring anyone back to it.
src/user.ts:5
  Redline/BLOCKER [core/type-checker-suppression]: a type-checker suppression needs an inline explanation AND a ticket reference on the same line.
src/user.ts:6
  Redline/BLOCKER [core/unsafe-assertion]: a double assertion overrides the type checker with no stated reason.
src/user.ts:9
  Redline/HIGH [typescript/unknown-type-alias]: this alias names `unknown`, so it reads as a contract it is not.
4 finding(s)
that is every rule a checker can decide; the rest of the standard needs a model

The messages are shortened here; your terminal prints each one in full, with the fix. In the playground you see exactly these four. In your own repository the profile line names your profile, a warn line may say which files no stack covers, and anything else already on your branch is reviewed too.

Run it in a terminal. When the output is piped or captured, for example by a script or an assistant running it for you, review prints the prompt for a model instead of the findings.

Reading a finding

Every finding has the same three parts, in the same order:

  • Severity — BLOCKER must not merge, HIGH is a deliberate trade-off, SUGGESTION is optional. See The output contract.
  • Rule id — the part in brackets. It is stable, it is what you pass to explain, and it is how the organisation measures which rules earn their place.
  • The problem and the fix, in one or two sentences.

These four came from a checker, not a model, which is why they are the same every time. Most of the standard needs judgement — a missing auth check, customer data in a log line — and that is what the next step adds.

ℹ

A local review always exits 0 and is never recorded. It is a mirror, not a gate: nothing here can block you.