Interactive field guide

The /cleanup-light pipeline

The backlog fills with small fixes: a dead rule, a stale line of copy, a missing semantic tag. This pipeline clears one without letting it grow into a refactor. Same critique discipline as the heavy pipeline; the only thing lighter is the scope.

Scope creep is the real risk here, so a critic exists just to guard it. If the ceremony feels heavy for a one-file fix, tell us. Reply on LinkedIn.

How to read this map

Each card is a stage of the pipeline, in order. The tucked-in card is a half-stage: a re-check of the item's claims before any code changes.

The colour on each card's edge tells you what kind of work it is: a gate, a fix, critique, or the close.

Open any card for the full, plain-language walkthrough at that stage.

Pick a stage to walk, or start at the top

Get this command /plugin marketplace add fire-farmer/red-line-toolkit view source →

The walkthrough, as text

Every stage of the interactive walkthrough above, as plain readable text. Each stage has its own link.

Stage 1Pick the item, check the rigorOne or two files, no more

Pick

You point the pipeline at one backlog item, or it lists them and you choose. It reads the affected files, states the smallest fix that would clear it, and checks that this is genuinely light work and not a refactor wearing a small hat.

Pick a single backlog item, load its context, and confirm it's light: one or two files, no new abstraction.

What happens

The pipeline finds the item in the backlog, reads its original note, opens the files it points at, and checks git for whether the surrounding code has shifted since it was flagged. Then it states the minimal scope of the fix.

The gate: is this one or two files with no new abstraction? If it looks like three-plus files or a new structure, it says so and offers to escalate to the heavy pipeline. It also flags a risk surface like logins, payments, or money math, which arms a security review later.

Who acts

Read / git log, tool: Loads the item's files and checks whether the code moved since it was flagged.
AskUserQuestion, command: The picker when no item is named, and the escalate prompt if the scope looks heavy.

The rules

Light means one or two files. More than that, or a new abstraction, and the pipeline offers to escalate rather than stretch a light pass over heavy work.

In: A backlog item, or an empty invocation. Out: One item, its files loaded, and its minimal scope stated.

Stage 1.5Re-check the item's claimsNotes drift; verify them

Re-check · half-stage

Backlog notes age. Before touching code, the pipeline re-checks the specific claims the item makes, a caller count, a single-use assertion, against the current code. If a claim is wrong, it shows you the corrected facts before writing anything.

Empirically re-verify the explicit claims in the item's note against the live code, because backlog notes drift as code lands around them.

What happens

The pipeline greps the exact selector or identifier the item cites and compares it to the stated count, checks that a cited file still contains what the note describes, and reads every callsite of the specific thing named, not every file that might be related.

If a claim is wrong, a corrected-facts block goes to you before any task is written, never silently absorbed. If the whole premise turns out false, the pipeline stops and asks whether to close the item as validated-no-action, escalate, or continue with the corrected scope.

Who acts

grep / Read, tool: Re-counts callers and confirms the cited code still matches the note.

The rules

Corrections are visible. A wrong claim is surfaced to you with corrected facts before any code changes, never quietly absorbed.
A false premise stops the fix. If the item's framing turns out wrong, the pipeline pauses rather than fixing the wrong thing.

In: The picked item and its files. Out: Verified claims, or a corrected scope, or a no-action close.

Stage 2Make the minimal fixNothing while you're here

Fix

The pipeline makes the change, and only the change. Anything else it notices along the way, a nearby smell, a tempting tidy-up, goes to the backlog as a new item, not silently into this diff. If the fix starts sprawling, it stops and asks.

Make the smallest change that clears the item. Noticed-but-out-of-scope goes to the backlog; a sprawling fix surfaces to escalate.

What happens

The change is kept to the item's scope. The hard rule is no while-I'm-here cleanup: something worth doing but outside this item becomes its own backlog entry, so the diff stays honest to what was picked.

If the implementation blows past one or two files or needs a new abstraction, the pipeline stops and asks whether to continue here or escalate to the heavy pipeline. It never auto-escalates; that call is yours.

Who acts

Edit, tool: Makes the scoped change and nothing else.

The rules

No while-I'm-here. Anything noticed but out of scope becomes a new backlog item, not a silent addition to the diff.
Sprawl surfaces, never auto-escalates. A fix that outgrows one or two files stops and asks; you decide whether to continue or escalate.

In: The verified item. Out: A minimal diff, scoped to the item.

Stage 3Light critiqueScope critic is load-bearing

Critique

Two critics always read the diff: one for scope discipline, one for bugs and quality. Two more join only when they apply, a security review if the change touched a risk surface, a simplifier if the diff is more than a few lines. The scope critic is the one that earns its keep here.

Always a scope critic and a code reviewer; a security review and a simplifier join only when the change warrants them.

What happens

The scope critic asks the load-bearing question: does every changed line trace to the item, or did a while-I'm-here creep in? The code reviewer reports high-confidence bugs and convention slips.

The conditional two save tokens by only running when their lens applies: a security review if the diff touched a risk path, a simplifier if the diff is more than a few lines. All of them run in parallel and blind.

Who acts

scope critic, agent: Guards against scope creep; the load-bearing critic here.
code reviewer, agent: High-confidence bugs and convention slips.
security / simplifier, agent: Conditional: security review on a risk surface, simplifier on a larger diff.

The rules

Scope is the load-bearing lens. On a cleanup, the highest risk is creep, so the scope critic always runs and its findings carry weight.
Conditional critics save tokens. Security and simplifier only run when the change actually calls for them.

In: The minimal diff. Out: A block of findings, ready for the referee.

Stage 4Referee, then your callKeep, ditch, or modify

Adjudicate

The referee marks each finding keep, ditch, or modify against the project's standards, with a security bump if a risk surface was in play. Then you choose which to absorb before the revise pass.

The Adjudicator rules on the findings with a security-asymmetric upgrade when engaged, then a checkpoint asks which to absorb.

What happens

The referee judges the critics' findings against the project's real standards, cutting generic noise, and bumps a plausible security finding a level if the change touched a risk surface. Its own field guide walks the judgement.

Then your checkpoint: absorb everything kept and revise, absorb nothing and proceed to verify, or pick specific findings.

Who acts

the Adjudicator, agent: Marks findings KEEP/DITCH/MODIFY, security-weighted. Has its own guide.
AskUserQuestion, command: The checkpoint: which findings to absorb.

The rules

Your call on what lands. You choose which surviving findings the revision absorbs.

In: The critics' findings. Out: A filtered set of findings to fix.

Stage 5Revise and buildGreen, or debug and retry

Verify

The pipeline makes the fixes you approved and builds the project. If the build breaks, it debugs to the root cause and loops until it's green. A cleanup that leaves the build red is not a cleanup.

Apply the verdicts, then build; a failing build loops through debugging until it passes.

What happens

The approved fixes are applied and the project is built. A break is not the end of the line; the pipeline finds the root cause, fixes it, and re-runs until the build is clean.

It also confirms the lint count did not get worse. Only a green build lets the item be marked done.

Who acts

the build, tool: The gate: a clean build, or the pipeline debugs and loops.

The rules

Green or loop. A failing build loops through debugging until it passes; the item is not closed on a red build.

In: The filtered findings. Out: A revised, building diff.

Stage 6Mark it done, audit the commitClear it, then check it

With the fix verified, the pipeline offers to mark the item cleared in the backlog. Then, before you commit, a pre-commit audit checks that the commit message is true, the scope held, and any follow-ups were captured, not left in the code as a comment.

Mark the item cleared in the backlog, then a pre-commit audit checks the commit's truth, scope, and follow-up discipline.

What happens

You choose whether to move the item to the cleared log with a one-line resolution note, leave it open, or revise it. The backlog edit is surgical, just the one row.

Then the pre-commit audit runs three checks: does the commit message match the diff, did every changed line trace to the item, and did any noticed-but-deferred work get written to the backlog rather than left as a stray comment. You commit once it is clean.

Who acts

AskUserQuestion, command: The mark-complete confirmation before the backlog is edited.
pre-commit-check, skill: Audits commit truth, scope discipline, and follow-up capture before you commit.

The rules

The audit is not optional. Except on a no-action close, the pre-commit audit always runs; it is the pipeline's truth-and-scope gate.
The pipeline never commits for you. It stages and audits; the final commit is always your call.

In: The verified fix. Out: A cleared backlog item and an audited, ready-to-commit diff.

Stage ✓One item, cleared cleanlySmall, but disciplined

Cleared

What you end with is one backlog item gone, cleared by a diff that stayed scoped, got critiqued, built green, and passed a commit audit. The discipline of the heavy pipeline, sized for small work.

The light pipeline proves that small does not have to mean sloppy: full discipline, minimal scope.

What happens

The item is gone from the backlog and the diff is honest to it: no creep, no red build, no stray follow-ups left in the code. That is the whole point of a light pass that still keeps the critique.

For a bigger sweep of related items, the cluster engine groups the backlog into batches; for a cross-file refactor, the heavy pipeline is the tool. Both have their own field guides.

The rules

Light, not loose. The scope is small, but the critique, verification, and audit are the same as the heavy pipeline.

In: One backlog item. Out: A cleared item and a clean, audited diff.