Two approvals instead of four

Building a feature used to look like this. You type "run product owner". You wait. You read the result. You type "now architect". You wait. "Now pm". You wait. "Senior dev."

Agents did the work, formally. In practice you sat between them — a courier carrying a folder from one office to the next, knocking on every door.

That is the main thing that changed over the last two weeks.

Agents hand work to each other

When an agent finishes, the system now reads its verdict, checks the pipeline map, and starts the next one. The courier has been let go.

One question remains: where does it stop and ask you? Because "nowhere" is not automation, it is hope.

Two approvals per feature

A new mode is the answer:

approval-level: product-only

You get stopped twice. First on what we are building. Second on whether it ships. Everything between those two points — architecture, decomposition, code, review, tests, security — runs without you.

You decide what. The system decides how.

The old default asked you about architecture, which is a question about how. Plenty of people want exactly that, and that mode is still there. But if you trust the technical calls and want your hand on the product, there is now a setting for precisely that, instead of a compromise between "ask me about everything" and "ask me about nothing".

One exception is hard-wired: on a regulated archetype — fintech, healthcare, government — the security and compliance gates stay at every mode. Choosing a lighter mode delegates judgement; it does not skip compliance.

First, check the plugin is actually running

This is the only technical request in the post, and it is worth thirty seconds:

claude plugin list --json

Find your plugin and look at the errors field. Mine said "marketplace not found" — while the settings said "enabled", the files were on disk, and the version was current. The plugin was not loading, and nothing said a word about it.

That was true of all five of my local plugins. I found it by accident, while chasing why one specific feature did not work.

If you have ever installed plugins by hand or moved directories around, check. Otherwise everything below describes a system that never came up on your machine.

And an honest caveat about the previous section: agents handing work to each other rests on the plugin's hooks. The system computes the decision correctly — I verified that on a live run. But your host is what executes hooks, and I have an environment where the plugin loads and the hooks do not fire. There, you are still the courier, even though everything else works. The check above is exactly about that.

What stopped breaking quietly

An interrupted run no longer loses its place. Before, if a build was interrupted, the code survived but the memory of where it stopped did not. The resumed agent either redid finished work or skipped unfinished work and shipped. One product went out having skipped QA and the security review. /resume now reconstructs the completed stages by itself.

An agent cannot write outside its scope. It is told which files it may touch and which it may not. That used to be checked afterwards — so it could write a forbidden file and find out at review. Now the write does not go through. The difference between "you may not" and "you should not have" is roughly everything.

An unreviewable diff gets named out loud. A change can pass every check — tests green, security clean — and still be physically impossible to read. Past a few hundred lines, review turns into approval. My own benchmark contained commits of twelve thousand lines; whatever review those got, it was not review. The reviewer now measures the volume and says when it has passed the limit of human attention. It does not block — it just stops you pretending.

A stopped agent leaves evidence. Not "status: stopped", but a note: what it did, what remains, where the artifacts are, what backs them. The next agent — or you tomorrow morning — inherits a state rather than a flag.

QA started asking the awkward question

Two things that were not there before.

Every critical path is now first written in plain language — given, when, then — and only then does the test code get written. It is a thinking tool first: if a path cannot be phrased as precondition → action → observable result, it usually cannot be tested either.

And then comes the question almost nobody asks themselves: would these tests catch anything at all? Faults are deliberately injected into the code to see whether a single test turns red. Green tests and tests that check nothing look absolutely identical — until you try.

A new agent, for people building MCP servers

If you build your own MCP server rather than only using other people's, there is now a reviewer for exactly that.

The reasoning: an MCP server is the one thing whose output lands inside another agent's context. The tool description the server's author wrote is read by a model, which then acts with your credentials in your repository. The line between "data" and "instruction" here is held by nothing but good manners.

The reviewer checks that line: whether the description commands the agent instead of describing the tool, whether something is hidden in it that a human cannot see, whether a parameter can send the server somewhere you never asked it to go.

How to install

npm i -g [email protected]
great-cto init

init is not optional: the package updates the files but does not register the plugin with the host. Then restart your session and look at claude plugin list, as agreed above.

Switching the approval mode is one line in .great_cto/PROJECT.md:

approval-level: product-only