Unattended (Autopilot) Loop Engineering: We Open-Sourced New Agent Skills That Free Your Hands

In the last piece, on design-review and build-phases, I quoted Addy Osmani: loop engineering is replacing yourself as the person who prompts the agent. That pair of skills did exactly that. It got me out of the copy-paste between two terminals. After that, a person was still in the loop. The job just moved. Instead of answering twenty detail questions, you sat in a window and waited for the agent to stop and ask what to do next. That tiredness is not the same as writing code. When you write code, you are thinking. When you wait for an agent to stop, you are on duty.

What we have not said much about for the past few months is the next four skills: issue-review, issue-sweep, pr-review, pr-sweep. With those, a developer's main job is no longer driving an AI agent from a terminal. It is opening issues, reading issues, reading PRs, and answering the questions that actually need a person. Dispatching goes to a scheduled job, a Claude routine or something like a local crontab, that starts an agent session, sweeps, and leaves. It keeps turning at night. The jump in how much we get done feels at least as large as the jump from writing code by hand to using a code agent. Throughput feels like three to five times. That is not a controlled study. It is how the last few months have felt. The more important part is that people are less tired, because they are not sitting there waiting for it to stop.

"Unattended" and autopilot are easy to misread, as if a person can finally step off decisions, taste, and responsibility. The opposite is true. Agents take the busywork. People spend more of their attention on the few things that cannot be handed off: whether this is worth doing, whether the result is any good, and who owns it when it is not. What you get free of is not involvement. It is being on duty. Nobody left engineering. They moved back to the layer that actually needs a person.

The last pair took you out of the Q and A. You were still the dispatcher.

design-review is for plans that drift: each round a fresh agent reads the file cold, the fixes go into the file, then the next round starts. build-phases is for execution that drifts: a phase has to verify before the next one starts. After those two, you are no longer the person being grilled for details. You are still the person who hits return, watches it finish, and tells it what to do next. Whether the loop moves at all still depends on someone sitting in that window.

So what actually has to go is not "does a person still take part." It is "does a person still have to sit with the session." I already wrote this last time: details go to the agent, direction stays with the human. These four skills hand off the sitting-with-the-session part too. Direction, taste, and the last signature stay with the person. What changed is you do not have to keep a window open all night to keep them.

The working surface is GitHub now

It is easy to read this as swapping a terminal for a webpage. The difference is who moves first. Used to be, the person moved first: open an agent, describe the work, wait for questions, answer, wait again. The agent was the tool. The person was the dispatcher.

Now the issue moves first. You write down what should happen. A sweep finds it, does what it can, opens a PR; if it hits a fork, it writes the question and a recommendation as a comment on the issue or the PR, then goes on to the next item. A few hours later you come back to a batch that has already moved, plus a short list of real judgment calls. A normal GitHub comment is enough. The next sweep will read it.

The last of those four jobs is the one people underestimate. The agent is not stuck. It hit a fork. Change the architecture or not. Can this safety boundary move. Should this interaction be tighter or looser. A or B. It writes the options, what it already checked, and its recommendation, as a question a person can actually answer. You pick one. The next sweep continues. You get interrupted less often, and each interruption is heavier. That is where decisions, taste, and responsibility actually happen, and that is the work a person is for.

Opening an issue is not dumping a sentence and walking away. A clear issue lets the loop run a long way on its own. A vague one comes back with questions first. That is the same idea as IDD: write down what you want. The entry point is no longer a separate intent file. It is the GitHub issue the team already uses. The clearer the intent, the more of what comes back is judgment, not makeup work.

Four skills, two pairs

issue-review handles one issue: read the body and the thread, check it against the code that actually shipped, leave an evidence-backed judgment, and when it can, open a fix or a doc update, or stop and ask a person. pr-review handles one PR: read the diff, check it against the live tree, run verification, and say whether it is ready to merge. Those two are engines. You can call them by hand on a single item. issue-sweep and pr-sweep are the scheduled drivers. One pass finds the items with new human input, or work left unfinished last time, and hands each one to the matching engine. Issues get pushed until a PR exists. PRs get pushed until the ones that can merge do, and the ones that should not merge keep the questions and the evidence.

The two pairs are mirrors. One eats issues. One eats PRs. The line between them is the workflow a team was supposed to have anyway. We did not invent a new ceremony. One rule sounds dumb and is the reason this can run for months: if nothing new came in, do not do it again. Already reviewed, no human reply, no new commits: skip. Otherwise every hour reprints the same comments, and people start to hate the loop. If you want it turning at night, it has to know how to shut up.

And the boundary has to live in the sentence, or this starts to sound like a company with no people. pr-review only judges and comments. It does not merge. Low-risk PRs that tested clean, and whose title and body match the diff, pr-sweep can merge. Security, breaking changes, an undecided direction, or a taste question like "does this actually look right": it stops and waits. Two PRs on the same issue: it keeps one and closes the other.

So "hands free" does not mean "nobody looks." It means nobody has to be the dispatcher sitting in a window. You still look. You look at results and at the judgment calls, not at the agent typing. Responsibility stays with the person too. An agent can push the work forward. It cannot sign for you.

The last pair of skills is what got wired in here

These four are not a new pile. The pair we already open-sourced plugs straight into this loop. When issue-sweep hits a real multi-phase feature issue, and it can start, it runs design-review until the plan holds, then build-phases to build it one phase at a time. A small, sharp change does not go through that. It just gets fixed, verified, and opened as a PR. Same test as last time: are you worried this will be halfway done before you realize the direction is wrong. If yes, use the pair. If not, do not take a hatchet to a chicken.

Every pr-review round starts a new agent that cannot see the last round's conversation. That is the same idea as design-review spawning a brand-new auditor each round. The session that wrote the change does not get to grade it. All it can see is the files on disk and this PR's diff. You cannot talk it into "we covered that last round." When several agents edit code at once, each still gets its own working directory, a git worktree, so one of them switching branches does not drag the others along. How you clean those up without filling the disk is still the git-hygiene piece.

So we did not make four new toys. We took the pieces that already worked, plugged them into the GitHub surface the team already lives on, and added a driver that shows up on time. The attention that frees up is exactly what you want for direction, quality, and ownership.

How to use them

These are agent skills. Install them into Claude Code or Codex and run them as slash commands. They are not tied to one vendor. Those two happen to be what we use. Install is the same path as the other agentloop skills in this series:

npx add-skill arcblock/agentloop

When you are present and want one issue or one PR handled, swap in a number from the repo:

/agentloop:issue-review 115
/agentloop:pr-review 420

To let the loop turn on its own:

/agentloop:issue-sweep
/agentloop:pr-sweep
/agentloop:pr-sweep --merge

Add --dry-run to any of those if you want to see what it would do without writing back to GitHub. Plain pr-sweep reviews, closes duplicate PRs on the same issue, and comments. It does not merge. --merge turns merging on. Even then it still goes through a gate: tests have to pass, what the PR says has to match the diff, and security, high-risk changes, or a taste call that needs a human look still stop for a person.

Turning at night does not mean people stay up. Put the two sweeps on a Claude routine, or a local crontab, and run the same slash commands on a timer. Answer issues and PRs when you can. A normal comment is enough. The next sweep sees the reply and continues. No reply, it stays quiet. The repo has to be on GitHub, and the environment that runs these commands has to be able to act on that repo. The full implementation is each skill's own SKILL.md: issue-review, issue-sweep, pr-review, pr-sweep.

When not to use them

The fit is specific: the work already lives in GitHub issues and PRs, and the backlog is starting to pin people to a window. One person, one terminal, one small bug: let the agent do it and run a test. Starting a sweep for that is treating a kitchen burner like a power plant. If the team does not already put work in GitHub, this loop has nothing to eat. It consumes work that was written down, not ideas still in someone's head. Get the workflow first, then talk about a loop.

If you want to sit with an agent and talk a design into shape, the design-review we already wrote about is enough. Do not break a conversation you are actually having into overnight comment tennis just to say you are "on the loop." And it is a bad way to dodge judgment. The loop will send the judgment calls back. If you neither reply to issues nor look at PRs, it sits there. What turns around the clock is the machine. It does not think for you, and it does not sign for you. Autopilot takes the repetitive trim in flight. It does not pick the route, and it does not land the plane.

You do not have to be on duty

The last piece ended with this: the polishing of an intent can go to an agent. A person keeps the direction, and that last call of "is this what I wanted." These four skills take that sentence out of a single task and put it into the ordinary day. A person still keeps those things, and keeps them more tightly: what to do, whether it is any good, and who owns the result. What changed is you no longer have to sit in a terminal to keep them.

Addy Osmani said loop engineering is replacing yourself as the person who prompts the agent.^[1] The last pair replaced the person pasting between two windows. These four replace the person sitting in a window, waiting to be asked what is next. What is left is the part that actually needs a person. Not a withdrawal from engineering. Time, finally, to stay on decisions, taste, and responsibility, the three things that do not hand off.

GitHub: github.com/ArcBlock/agent-skills

Related in the series:

References