← All skills

atlas-review

v1.0.0MITHanding over a pile of work

The other half of the same app. It reviews the open pull requests, fixes what the review finds and lands them, then does the three jobs nobody asks for: covering the new screens with tests, wiring the backend the product owner left alone, and breaking every check on purpose to find out which ones could never have failed.

Install
/plugin install atlas-review@fledgeling-plugins

Needs the marketplace added first — how to do that.

Reach for it when

Atlas/Bella review conductor. Takes the open PRs from arrival to reviewed, fixed, merged, pushed and reported.

Not for

NOT for cutting a release (use atlas-publish:atlas-publish), NOT for a repo's whole backlog (use ship-fleet:ship-fleet), and NOT for reviewing one diff in isolation (use code-review:code-review directly).

What ships with it

Say any of this

  • review the open PRs
  • land Elysee's stack
  • go through the PRs and merge them
  • the CEO has pushed some work
  • review and merge what's open

Taken from the skill’s own trigger description — these are the phrases it listens for. You do not have to match them exactly.

Easily confused with

atlas-publishThe one plugin here built for a single app.ship-fleetHand it a repo's whole backlog and it works through it.code-reviewReviews a change and, unusually, tells you what it did not look at.

Takes the open pull requests on the Atlas monorepo from arrival to merged, pushed and reported.

The product owner writes the interface and hands it over. The review, the fixes, the backend wiring, the tests for the new screens and the report all sit on the other side of that handover, and this skill does them in the order they get asked for.

What it does

1 review the open PRs          6 update the tests for what the PRs added
2 resolve what it found        7 do the backend work, plus the owner's notes
3 commit and push              8 test and iterate until green, unit and on a device
4 rebase onto main             9 commit and push
5 pull

Stages 2, 6 and 7 are the ones nobody files a ticket for. The review skill it calls is read-only, so fixing is this skill's own job. A stack that adds four screens adds no tests for them. And the owner says plainly that they left the backend alone, so it is waiting.

The two things it does differently

It does not trust a test until it has watched it fail. Three quarters of compiling machine-written tests are vacuous, and reading one is measured as poor at spotting the shapes that matter, because a reader treats a mock as a valid fixture. So a test the change touched gets a fault injected into the code it covers, and has to go red. Eighteen checks that could not fail were found this way in a single session, and not one was found by running the tests.

It checks the tree after merging, not the branches before. Between a fifth and a third of merges that apply cleanly still carry a conflict of meaning, and no check that runs on a branch alone can see one. Two of them turned up in the session this was built from, and both were records that disagreed with their twin only once they sat in the same tree.

What comes out

A comment on each pull request, in Luke's voice. A single-column HTML page the product owner can read without knowing what any of it is called, with figures doing the work that long sentences would otherwise do. And a status page that joins the portfolio dashboard.

What it will not do

Cut a release; that is atlas-publish, which begins where this ends. Work the wider backlog; that is ship-fleet. Weaken a check so it passes. Or report a verdict it did not measure: "still passing" and "passed once, weeks ago" are different claims, and the record says which.

Evidence

skills/atlas-review/references/evidence.md separates what the field has measured from what was measured in this one repo. The research panel is in docs/deep-research/. evals/EVALS.md says plainly that no comparison against not using the skill has been run, and names the three tasks that would settle it.