# 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](#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](https://continuous-refactoring.de/en/docs/driver.md) 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](https://continuous-refactoring.de/en/docs/driver.md) is rewritten around this, and
the [FAQ](https://continuous-refactoring.de/en/docs/faq.md#why-is-the-main-command-the-driver-and-not-a-single-run)
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](https://continuous-refactoring.de/en/docs/known-limitations.md): 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`](https://github.com/vercel-labs/skills)
installer (Node.js 22.20 or newer), for OpenCode, Claude Code, Codex and
other agents:

```bash
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](https://continuous-refactoring.de/en/docs/faq.md#what-is-the-bc-promise-and-when-does-the-suite-ask-about-it)
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](https://continuous-refactoring.de/en/docs/own-tool.md) 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](https://continuous-refactoring.de/en/docs/faq.md#how-do-i-keep-the-tracker-file-somewhere-else).
- **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)](https://github.com/Art4/continuous-refactoring/discussions/categories/show-and-tell).

## Changelog 0.11.0

The upstream changelog entries for 0.11.0, verbatim. Also on GitHub: [release 0.11.0](https://github.com/Art4/continuous-refactoring/releases/tag/0.11.0).

- **Breaking:** `/continuous-refactoring` is now the **Driver**: it works round after round by itself, each a run, its review and any rework, 30 minutes apart, and stops after five rounds or at more than three open merge requests. It merges nothing unless the call says `merge`. One run is now `/continuous-refactoring-run`, unchanged otherwise, and the references moved with it. To upgrade: add the third symlink, `skills/continuous-refactoring-run`, beside the other two; move any call that means one run, a scheduled job above all, to `/continuous-refactoring-run`; in a Pack of your own change the `$schema` line to the new path. The line "Used by `/continuous-refactoring`" in a tracker file already written is harmless and can stay.
- Onboarding no longer asks for the BC promise, and a run no longer asks for it at its start. The BC promise is now a tool on request of its own: the first time a plan keeps an old API only because the promise is open, the next scan files a ticket with what it found, or a draft that answers the usual questions of such a promise from the project's code and leaves open what only the human can say. The human's answer on that ticket decides; an autonomous run never answers it.
- The **BC promise** bullet may now name a page on the project's website, and it may list several promises, each with its scope: a folder of the code 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. A page that cannot be read leaves its part unsettled for that run, with a finding.
- A tool on request can now come up by itself, once, as a question: its Opener is the situation in which it would have paid off. A plan that meets it notes the Opener under its decisions, and the next scan files a ticket asking whether to set the tool up. The ticket waits for a human's yes, in an autonomous run too, and until then holds no Track back. A rejection keeps the tool from being offered again.
- Semgrep, Psalm's taint analysis and Infection can now come up by themselves, once, as a question. Semgrep and the taint analysis come when a plan fixes a security problem found by reading the code: an injection goes to the taint analysis where PHPStan Level 4 or Psalm is reached, anything else to Semgrep. Infection comes when a plan finds tests that run the code it changes but check little of it. Secret Detection stays on request only.
- Roave's backward-compatibility check now applies per part of the BC promise: when only some parts follow semantic versioning, the classes of the others are ignored, each entry commented with its scope. When Rector's type coverage takes its BC-safe path only because no promise is recorded, the plan notes that, and the next scan asks the human to set the promise up.
- A call can now build a Pack of your own: `/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 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 named outside the repository ends the run.
- 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.
- The suite now installs with the `skills` installer: `npx skills@latest add https://github.com/Art4/continuous-refactoring/tree/0.11.0/skills --skill '*' -a <agent>` copies exactly the three skills of that version into the target, for OpenCode, Claude Code, Codex and other agents, and an upgrade runs the same command with the new version. A Git checkout with symlinks still works; check out a release tag instead of following `main`.

---

Questions or comments on this post? Welcome in [GitHub Discussions (Q&A)](https://github.com/Art4/continuous-refactoring/discussions/categories/q-a).