The first case studies are about engineers. This one is about a repository: the Camunda 8 command-line tool, where the method left the SDKs it was born in, and many people grew a product inside one structure.
c8ctl is the Camunda 8 command-line tool. It is not an SDK, and it was not started by Engineer A. That makes it the test of whether the method is general: here it left its original domain, and other people grew a product inside it.
Its originator started with a clear vision, down to the user experience: every command is a verb and a resource, like c8 list pi. He committed that vision first, as a plan, agent instructions and the API spec. Then he set up CI on a matrix of versions and let a coding agent run at full speed. The first day ended with every command implemented, tests, docs and a 1.0.0 release.
Integration testing was done by users, with the originator as user zero. Today every merge publishes to an alpha channel straight away. When nobody reports a problem against an alpha, it is promoted to stable.
--fields, --dry-run and a CONTEXT.md for agents. Designing for agent users.Before the registry, users found commands with parts missing: a get that did not exist, a flag rejected by every search command, a flag accepted and then ignored. When one was patched, the next one was still possible to write. #256 says so: the instance was fixed, “but the pattern is still expressible”.
After April, one built-in report of this kind remains (#441). The rest are at the edges the registry did not cover yet: plugins, verb aliases, flag parsing and shell completion. Each got a structural fix rather than a patch: a plugin contract, and two-stage flag parsing that scopes every flag to its verb (#373).
Source: issues in camunda/c8ctl, open and closed, to October 2026, classified by hand. Built-in: a command, flag or help entry that was declared but missing or not wired (#41, #43, #111, #246, #256, #441). Edges: the same kind of gap in plugins, aliases, parsing or completion (#358, #363, #364, #407, #593, #597, #638). The numbers are small; the chart shows where the bugs are, not a rate.
28 people have filed issues and 26 have committed. Most arrived after the hardening, and they arrive with features, not with questions about where to put them.
process.argv” (#593). Another made plugins declare the c8ctl version they need (#523). A third built an element-template migration engine in about ten small, typed, tested slices, and wrote its bugs up as defect classes (#643–#660).An automated repository audit in July, run by an agent skill, called c8ctl “a near-exemplar of LLM-velocity engineering discipline” (#474). The philosophy is “if it is green, it merges”, and main enforces it: a pull request can only merge when the Tests passed check is green, and direct pushes are rejected. The merge button is part of the system.
Source: git history, issues and releases of camunda/c8ctl, and npm download counts for @camunda8/cli, to October 2026. Branch rules checked on the repository in November 2026.
A clear vision and a coding agent produced a working tool in a day. Users found what was missing. Hardening made whole classes of mistake impossible, and that structure is what let other teams, and their agents, add what they needed without asking where it goes. Only green changes merge.