Review the change before it exists.

Agent PRs are hard to review because the review is late.
Extra files. A helper that grew. A rename you did not ask for.
Radius Principle is a small practice: write a non-prose expectation first.
That file is expect.yml.

Hi, I'm Daniel (@ddyods), a lead software engineer from Paris.
I like TypeScript (a lot) and clean agentic workflows.

About 20 expect-bounded PRs are reviewed by my team then merged each week on an enterprise monorepo, where I work as a freelancer.
I also build Lumpcode, a CLI to manage agent loops directly on your codebase.
Those PRs are written with it.

Anticipate your reviews

An agent PR asks you to reconstruct intent from a finished diff.
If that PR is the first thing you read, the review is already late.

A markdown spec, a requirement, or a ticket is hard to read at a glance. What will happen stays hard to see. Verifying that an implementation matches that prose is hard.

An expect.yml names the files and symbols that should change. You can review that list at a glance.
If the list seems too big, you can split it. Pair the expect with the ticket's .md description, then let the agent try to implement against the contract you validated. If that contract is missed, /radius:drift shows where to look more closely.

expect.yml

Radius Principle is the practice. expect.yml is the artifact: which files move, a line of why, optional size, optional symbols you already know must change.

desc: "Extract acquireLock so setup and teardown share one release callback."
files:
  src/lock.ts:
    desc: "New helper: acquire and release the path lock."
    "-": 0
    "+": 40
    symbols:
      acquireLock: create
      releaseLock: create
  src/run.ts:
    desc: "Call acquireLock. Drop the inlined lock block."
    "-": 12
    "+": 8
    symbols:
      run: update

desc is for humans. files is the expect. + / - are expected size, not a pass or fail. symbols are not exhaustive: create, update, or delete for names you already care about.

If the expect is already big, split it

The file list has to fit in your head. If it does not, the PR will not either. Split until each expect is one change you can review. Those PRs stay small, precise, easy to review, and easy to combine.

You still read the file before implementation. If the first time you see it is inside the impl PR, you are late.

Then let the agent implement. Then look at the gaps.

1 /radius:expect drafts the file from a requirement or a conversation.
2 You read it. Split or drop files. Validate the expectation. That is the first and most important gate.
3 /radius:impl implements against the listed files and tries to stay close to the estimates.
4 /radius:drift measures what missed: extra files, blown size, a listed symbol that did not move.
It tells you where to turn your attention.

Two expects that share a file, or that update the same symbol, should run one after the other, so they do not conflict.

The expect is also something a script can read, so a reviewer can start at the drift instead of reconstructing intent.

Three skills

/radius:expect Write expect.yml before any code.
/radius:impl Implement to match that expect.
/radius:drift Score how far the branch drifted from it.

Install

Three skills, installed from skills.sh:

npx skills add danilouli/radius-principle

Then run /radius:expect.