A senior code reviewer for production Python backend code. The reviewer who won't touch your keyboard — points at the lines that will page you at 3am, tells you why, and hands the fix back to you.
Built for Competition #9, as an ICM workspace (interpretable context — folders as architecture) built to the writing-great-skills principles. Redline is an editor, not a rewriter: it surfaces what's weak and pushes you to fix it. It never hands back a "corrected version."
Give Redline a Python backend diff / PR — an API endpoint, an ORM query, an async worker, a data-pipeline step — and it returns feedback that:
- names the exact lines that don't work (not "the error handling"),
- explains the concrete failure and who feels it (not "this could be better"),
- gives a measurable result to aim for (not a rewritten function),
- and leaves you to write the fix.
Senior bar: correctness under real load and failure, data integrity, concurrency, security, performance at scale, maintainability. Not a linter — Black / Ruff / mypy already catch formatting and typing; Redline spends attention on what tools can't see.
Redline is an editor built the interpretable-context way — a folder where each file does one job. The five canonical parts:
identity.md— who the editor is and what work it reviews (senior Python backend).rules.md— how it critiques. Its first law, RULE 0, is point, don't fix.reference/examples.md— what good critique looks like, worked on real Python.reference/— the checklists and frameworks it uses: the 14-class failure catalog, the comment craft (5P, Triple-R), triage.README.md— this file.
Everything else — the stages/ pipeline, _templates/, the optional execution phase — is an ICM expansion around that core, never a substitute for it. The editor's job is to critique; it does that first and always.
The workspace is folders as architecture. Each file does one job, and each stage reads only what it needs, so the context window stays small and every step is inspectable.
| Layer | File | Role |
|---|---|---|
| entry | CLAUDE.md |
Auto-load pointer (Claude Code) → identity + master map. Holds no content. |
| 0 — Where am I? | identity.md |
Routing + the prime directive; persona lives one pointer away |
| 1 — Where to go? | CONTEXT.md |
Master map: full file tree, exact paths, navigation law |
| 2 — What am I doing? | stages/0X_*/CONTEXT.md |
5 stage contracts (Inputs → Process → Outputs → Human check) |
| 3 — What rules? (recipe) | rules.md, reference/* |
The law + persona (voice.md) + failure catalog + frameworks + ticket method |
| 4 — What am I working with? (ingredients) | <project>/redline_review/<runid>/ |
The run's artifacts — in the reviewed project, not the tool |
Blank ticket stamps live in _templates/ (method kept apart from instance). Every structural file carries YAML frontmatter (layer, type, stage) so the workspace is queryable. The tool stays stateless — every per-run artifact is written into the reviewed project (<project>/redline_review/<runid>/ for the review trail, <project>/redline_tickets/ for tickets), never inside Redline/. A run is done only when its artifacts are on disk (RULE 8); a blocked write is a hard stop, not carried inline.
The pipeline: 01_intake → 02_scan → 03_triage → 04_compose → 05_tickets → 06_execute.
Each stage writes into the run folder in the reviewed project, and each contract names a Human check — one concrete thing to verify at that review gate before the next stage runs. Expect a U-curve: edit heavily at intake and triage/compose, lightly in the middle.
Stages 05–06 are optional and sit beyond the core review — the editor never touches your code unless you explicitly opt in, and even then only implements a fix you or an orchestrator chose from researched options. Reviewing (stages 01–04) is always pure point, don't fix. 05_tickets turns findings into redline_tickets/. 06_execute (opt-in) drives those tickets to closed — one agent per ticket, six beats each (study → research → decide → implement → validate → document), gated by a chosen fix. Two modes: Autopilot (an AI orchestrator decides and signs off) or Co-pilot (you decide each fix and each close). Validation is an independent pass — a fresh Redline scan of the fix plus the ticket's acceptance criteria — so a ticket only closes clean. See reference/execution-protocol.md and reference/validation-protocol.md.
Closed navigation. Every folder has a CONTEXT.md that lists its files with exact paths and links back to the master map and forward to the next step. If any pointer ever fails, the rule is: don't search — open CONTEXT.md, the single source of truth for where everything lives. You can reach anything from anywhere, and get back.
- Create a Claude Project and add this whole folder as project knowledge (keep the structure — the
CONTEXT.mdfiles are the navigation). In Claude Code,CLAUDE.mdauto-loads and points the agent in. - Point Claude at
identity.mdfirst, thenCONTEXT.md. - Paste your Python diff / file / PR — ideally with line numbers, the intent, and framework + versions.
- Claude becomes Redline and runs the pipeline.
Ask "turn these into tickets" and stage 05_tickets creates a redline_tickets/ folder at the root of the project under review (the tickets are the product and live with the code they concern — not inside this tool repo; overridable, and falling back to the workspace only for a pasted snippet): one ticket per finding, each self-contained — the problem, the failure scenario, acceptance criteria, blocking edges, and references — following reference/ticket-format.md (a tracer-bullet slice with its own test). An index CONTEXT.md links them and loops back to the tool map. If you don't ask, Redline offers when a review has real findings. Tickets restate the problem and the target — never the fixed code.
Tool vs product. Redline is a standalone tool repo — it holds the method (rules, stages, reference, templates). Everything a run produces — tickets and the six-beat execution records under
redline_tickets/work/— is written into the reviewed project, alongside its code. In-project links are relative (portable with the repo); links to the tool are writtenRedline/…(the installed skill root, never a machine path).
Needs change — a check-then-insert race can create duplicate accounts.
BLOCKING
needs change: Can we rely on a DB unique constraint on `email` and handle
the integrity error, instead of the read-then-write on lines 2–6?
Rationale: two concurrent signups both pass `first()` before either commits,
then both insert — duplicate accounts under a retry storm or bot traffic.
Result: two simultaneous registrations for one email → exactly one account.
Question: does `users` already have a unique index on `email`?
NON-BLOCKING
levelup: worth deciding retry-vs-fail-fast for the downstream email send.
praise: the argon2 hashing on line 8 is the right call, not a bare sha256.
No rewritten function, no drop-in patch. You write the fix.
Someone with no context hands Redline a Python backend diff and gets back feedback that actually improves it — specific enough it could only apply to this code, structured so the author knows what to fix and why, without Redline having fixed it for them.
If the output reads like "consider strengthening your error handling," Redline has failed its own review.
Every internal link is written Redline/…, relative to this skill's own root — so the folder works unchanged wherever it lives: your machine, a teammate's, ~/.claude/skills/…, or a fresh GitHub checkout. There are no machine-specific paths to update when you move, install, or share it. (Redline/ resolves to wherever the skill is loaded from.)
MIT — see LICENSE.
- Adrienne Braganza — Looks Good To Me: Constructive Code Reviews — comment craft: 5P, Triple-R, signals, Politeness Principles.
- Thomas & Hunt — The Pragmatic Programmer · Robert C. Martin — Clean Code — maintainability judgment.
- ICM (interpretable context methodology) — the five-layer architecture and stage contracts.
- writing-great-skills — leading words, progressive disclosure, single source of truth.
Start here: Redline/identity.md → Redline/CONTEXT.md