0.11.0: the Driver takes over, installing with npx, and a BC promise asked at the right moment

November 3, 2026 · Release · written for 0.11.0

0.11.0 is about the suite keeping going continuously, with careful defaults. /continuous-refactoring is now the Driver, the suite installs with one npx command, and the BC promise is asked about when it starts to matter instead of at the door. It has one breaking change, and it touches every call that means "one run": see What changes for your project.

¶How a run worked so far

One call of /continuous-refactoring was one run: it reconciled what became of earlier merge requests, chose a Track, scanned, filed tickets, planned the next workable ticket, implemented it test-first on a branch of its own and opened one merge request. At every decision point it laid out findings, options and a recommendation and asked you; "do it yourself" made it take its own recommendations. Then it stopped. Whatever should call the next run was yours to set up: a cron job, /schedule, /loop, or you at the keyboard.

¶The Driver playbook, in 0.10.0

0.10.0 added a playbook for the step after that: an agent that calls one autonomous run after another, each in a subagent of its own so every run starts with a fresh context, reviews each merge request in a second subagent, and asks you only where a decision is yours. It was a prompt you copied into a session.

¶The Driver is now the main command

Since then a run has become stable and reliable enough that I want the Driver to be the normal way to use the suite, not a prompt on the side. So the names moved to fit:

• /continuous-refactoring is the Driver. The name says "continuous", and a single run stops. What continues is the Driver, so it took the name. It works round after round by itself: a run in a subagent, the review of its merge request in a second subagent, and any rework.
• One run is now /continuous-refactoring-run, unchanged otherwise. An agent that wants refactoring done calls that one.
• The suite has three skills now: the Driver, a run, and /continuous-housekeeping.

The Driver playbook is rewritten around this, and the FAQ says why the names moved.

¶Safe where you say nothing

Here too I start careful and loosen only where it has proven itself, as with everything in the suite: a Driver called without further instructions does the careful thing. It starts without asking, says back in one sentence what it took, and then:

• merges nothing. It comments on each merge request, and you merge. Say merge and it merges, once CI is green. It then checks that the merge really landed the branch's content, and stops if not: the correction is a normal merge request, never a rewrite of history.
• stops after five rounds, and also when more than three of its merge requests are open.
• waits 30 minutes between rounds. The pace is meant to be slow and steady, beside other agents and humans, and the wait is a chance to notice a job that still calls the old command.
• keeps rework in the round and limited. A request for changes is answered at once; after two reworks without a mergeable result the merge request goes to you.
• stops when something is off: a failed run, a working tree that is not clean afterwards, a merge that did not land, or two runs in a row without a merge request and without a new waiting ticket.
• never answers an open question itself. It goes on with the next ticket while one waits for you.
• is meant for you or a schedule, not for an agent. It works for hours and writes to your forge, so an agent that was only asked to tidy something should not set it off. Its description says so and points an agent to /continuous-refactoring-run instead. Nothing blocks it technically: a skill setting such as disable-model-invocation would also stop a scheduled task from calling it. Only inside a subagent does it stop, because it needs subagents of its own and a subagent cannot start any.

Every one of these you change in your own words: another number of rounds, an end such as a time or "until nothing is workable", another cadence or "no pause", a Track or a restriction ("Guardrails", "only the Rector tools"), a log file your repository ignores.

Two catches are in known limitations: a session holds a short cadence only (in Claude Code, one wait reaches an hour), and the Driver does not know when it last ran. For a daily rhythm, point your own scheduler at /continuous-refactoring, and run one Driver per project.

¶Installing with npx skills

The suite now installs with the skills installer (Node.js 22.20 or newer), for OpenCode, Claude Code, Codex and other agents:

npx skills@latest add https://github.com/Art4/continuous-refactoring/tree/0.11.0/skills --skill '*' -a <agent>

It copies exactly the three skills of that version into the target, and nothing else of the repository, and records the version in skills-lock.json. Always install all three: the Driver and Housekeeping read files of the run skill. An upgrade runs the same command with the new version in the URL; --skill '*' also brings a skill the new version adds. A Git checkout with symlinks still works, without Node.js or to work on the suite itself: check out a release tag instead of following main.

¶The BC promise, asked at the right moment

Whether the suite may delete an old API depends on your BC promise, the document saying what stays stable for code outside your project. Up to 0.10 the onboarding asked for it, and a project onboarded before was asked at the start of its next run. That was early and without context. Now nothing asks up front. Until the suite knows your promise, it treats code reachable from outside as covered, which is safe but keeps old APIs nobody outside may use.

The BC promise is now a tool on request of its own, and that brings a new mechanism: an Opener. A tool on request is still never set up unasked, but it may now come up by itself, once, as a question, at the moment it would have paid off. A plan that meets the moment notes it, and the next scan files a ticket asking whether to set the tool up. The ticket waits for your yes, in an autonomous run too, and until then holds no Track back. A no keeps the tool from being offered again.

For the BC promise that moment is the first time a plan keeps an old API only because the promise is open. The ticket carries what the suite found: your document, or a draft that answers the usual questions of such a promise from your code and leaves open what only you can say, such as how long a deprecation lasts. Your answer on the ticket decides, and an autonomous run never answers it for you.

The BC promise bullet got more capable, too:

• It may name a page on your website instead of a file. A page the run cannot open leaves that part unsettled for the run, with a finding.
• It may list several promises, each with its scope: a folder such as packages/client/, or a surface such as the PHP API, an HTTP API or the command line. Where two cover the same code, the stricter one applies; code none covers stays covered.
• Roave's backward-compatibility check applies per part. When only some parts follow semantic versioning, the classes of the others are ignored, each entry commented with its scope.
• Rector's type coverage says why it was careful. When it takes its BC-safe path only because no promise is recorded, the plan notes that, and the next scan asks you to set the promise up.

Other tools use the Opener, too. Semgrep and Psalm's taint analysis come up when a plan fixes a security problem found by reading the code: an injection goes to the taint analysis once PHPStan Level 4 or Psalm is reached, anything else to Semgrep. Infection comes up when a plan finds tests that run the code it changes but check little of it. Secret Detection stays on request only, since Housekeeping's scan of the Git history already finds a committed secret.

The FAQ has the reasoning.

¶Also in 0.11.0

• A Pack of your own, built for you. /continuous-refactoring-run a Pack of its own for Deptrac skips the worklist and the Track choice, proposes the Tool, its Role and its Stages, checks the Pack with the parser and ends with one merge request. The playbook starts with this and keeps the by-hand route below it. The parser's --own-pack now takes a relative path against the target, as documented, not against the working directory.
• The tracker file may live elsewhere. Name it in your AGENTS.md (or CLAUDE.md), in your own words, and the suite reads and writes the ## Refactoring operations section there. Without such a line nothing changes; a file outside the repository ends the run. See the FAQ.
• One playbook less. The reviewer-loop playbook is gone: it was a tool for developing the suite, not for a project using it. Reviewing inside a project is the Driver's job.

¶What changes for your project

To do, because of the breaking change:

• Make sure all three skills are installed: with npx skills, run the command above (--skill '*' brings the new one); with symlinks, add the third, skills/continuous-refactoring-run, beside the other two.
• Move every call that means one run to /continuous-refactoring-run, a scheduled job above all. Left on /continuous-refactoring, it would now start a Driver.
• In a Pack of your own, change the $schema line to the new path under continuous-refactoring-run.

The line "Used by /continuous-refactoring" in a tracker file already written is harmless and can stay.

What you will notice:

• The onboarding no longer asks about the BC promise, and a run no longer asks for it at its start. If an old API is kept only for that reason, a ticket asks you later.
• The next scan may offer a tool on request as a ticket, if one of the Openers above was met. It waits for you and blocks nothing.
• A Roave check under a mixed promise is narrowed to the parts that follow SemVer.

If you let the Driver loose on a project of yours, I would love to read how it went in GitHub Discussions (Show and tell).