I’m moving Command’s useful parts into the sessions where I build my projects. Command began as an operator: a separate system that watched repositories, coordinated workers, and brought decisions back to me. The new design is a shared kit of skills, rules, and guard hooks that each project session inherits. I want to find out whether those sessions can carry the work with less coordination for me to manage. As of September 11, the kit is one day into a seven-day trial, so that is still a question.
A shared kit in the project
Instead of opening Command and having it hand out work, I open a session in the project’s own folder. That session can research, build, test, and review a change, then take it through the repository’s approval process. When it needs help, it starts its own background workers. The parent session remains responsible for them; there’s no separate dispatcher assigning slots and waiting for leases to expire.
The kit supplies the global instructions, skills, hooks, settings, and output style. It also includes a short repository list: where each project lives, what a merge must never touch, and which label reaches me. Command’s private repository holds the kit’s source and the goals file the sessions work toward [measured 2026-09-11, the kit plan, section 4].
For example, the status skill checks the project’s state, the ask skill brings a decision to me, and the retro skill reviews recent work when asked. The review loop and handoff skills carry forward too. These are useful operations a project session can call without going through another layer that manages the same work.
Why this is worth trying
The strongest reason to simplify was where the effort went. In the last week of August, nine tokens in ten went to sessions that only ran the operator, and two thirds of my typed messages were about running it [measured 2026-09-11, the board’s design note, citing that week’s study]. Command existed to help the projects move; much of my attention was going into Command.
The next design replaced the manager layer with a board of files and a dispatcher without a model in it. In its first week, the board and its workers used a quarter of about 1,830 million input tokens and accounted for four of the 34 merged venture pull requests [measured 2026-09-10, the kit plan’s token table, counted once per API call]. That made a smaller design worth testing. It did not establish that the board could never work.
The strongest counterargument is that a system being built spends on itself by definition. The board was in its first week, it had a credit outage, and its worker-review step was never built. Sixteen open worker pull requests could mean the review step was missing rather than the architecture was wrong [measured 2026-09-11, the kit plan’s first section]. The kit’s first week may also be expensive. Comparing only each system’s share of the bill would reward doing less without showing that useful work survived.
So the decision is to test whether the rules and skills can travel without the separate coordinating system. The trial scores tokens per merged venture pull request alongside unattended work ownership and an actual release. Nothing gets deleted during this phase. Retiring the old system needs another decision from me.
The controls still need to work
Simplifying the architecture doesn’t make a written rule enforce itself. The September review found that the workflow meant to merge work after automated checks and a commit-specific review had been disabled since August 31. The board deferred merges on Command’s own repository to that workflow. Reading the source found a separate problem: the compiled default accepted an unsigned verdict [measured 2026-09-10, the workflow list, its last run, the gate’s source, and the board’s design note].
Those are different checks. A workflow can be running and still trust an approval it shouldn’t. Turning it back on would not, by itself, settle the approval question.
By September 11, the installed kit hook refused a merge that wasn’t pinned to a reviewed commit; it refused mine that morning until I pinned it. That shows a control running on that path, not that every approval or merge path has been verified. The review also called for checking checkout distance on a clock and counting asks that expire unanswered. These were filed as kit issues [measured 2026-09-11, the kit plan’s keep list]. Moving the controls into hooks and skills still leaves their behavior to check.
What the trial has to show
Phase A was approved on September 10 and runs to September 17, with the dispatcher off. It installs the status, ask, and retro skills without removing the old system [measured 2026-09-11, the goals file and kit plan]. The measures were written before the trial started:
| Measure | Baseline, the board’s week | Phase A has to show |
|---|---|---|
| Input tokens per venture pull request merged by background workers | About 35 million | Not above that |
| Venture items left ownerless: a worker that ended on a prompt or an error with nobody adopting it within a day | Not measured; three relaunches on one item | Zero |
| Share of my typed turns that are status questions | Measured on day 0 | Falling |
| A venture’s weekly release happened, read from live traffic rather than from GitHub | Yes | Yes |
The decision rule was written at the same time. If phase A holds, phase B waits on my go. If it fails on ownerless items or the release, nothing is reverted because nothing was removed; the finding becomes a kit issue and the board stays as it is today, dispatcher off, until the next decision.
The trial table comes from the kit plan’s section 6, read on September 11. A pull request is one delivery measure; it does not on its own show a venture goal moving. The release check needs evidence from live traffic, and the goals record needs to point outside Command to the thing that changed.
This is a review of my own system. I knew where to look and why the earlier choices were made, which can make it easier to forgive them. I read source, git, workflow states, and records; I did not run a full investigation of each job. The token evidence covers two weeks, and there was no second reader for the original review. I don’t yet know whether the kit will do better. The next useful evidence is what the trial shows on September 17.
A checklist for another system
The review used six questions. Each asks for something observable alongside what the system says it does. You can use them without adopting Command’s architecture.
| Question | Read this | It fails when |
|---|---|---|
| What it’s for | The stated goals, then where the tokens and the operator’s messages actually went | Most of the effort is the system working on itself, and the output that reaches the goals is small next to it |
| Authority boundaries | The written rule, then the code path that enforces it | The rule names a check that is disabled, unmerged, or lives only in a prompt |
| Unattended failure modes | Each job on empty input, a hung step, and a second attempt | Relaunch with no attempt limit; a fleet-wide pause read as many individual stalls |
| Verification of claims | Each “done” against an independent source: the merged commit, the live endpoint, the remote tip | The record is written by the thing it describes, and nothing re-reads the live state |
| Cost and run-away limits | Where spend is counted and what stops a loop | Spend is only visible in a retrospective; the only cap is the credit limit |
| Human handoffs | The path from “needs a person” to the person, and the count of items that never arrived | Asks expire silently; the queue has been rebuilt without measuring the loss |
Dated review notes
The review was made against Command’s default-branch commit 9e51640d on the evening of September 10, 2026 Pacific, with the pull-request counts re-read on September 11. The charter is the rulebook ratified on July 22; the board’s design note was written on September 3; the kit plan is the September 10 proposal. The notes below preserve the earlier designs and their measurements.
Read the earlier designs and the five findings from September 10–11
Five shapes since May, and what each one added
Command has had five shapes in fifteen weeks, counting the scaffold it started as. The later designs carried forward useful parts of the earlier ones. The evidence for replacing each design was uneven.
| Shape | Ran | What it added |
|---|---|---|
| The scaffold | From 29 May | A local service that senses a fleet of repositories, git state, CI and probes, with no model in the loop; a fleet view and a confirmation-gated action layer by the end of its first day [measured 2026-09-10, the first thirty commits] |
| The company | From 22 July | A written charter with an Owner and a President role, and a color for every piece of work; from 5 August, loop cards and a registry for every unattended job |
| The office | 13 August to 2 September | A standing manager session, a decision board, and workers reporting back |
| The board | 3 to 10 September | A board of files and a dispatcher with no model in it, moving work through one locked command |
| The kit | From 10 September | The rules, skills and guard hooks every project session inherits; under trial until 17 September |
The scaffold measured nothing as waste, because it had no goals attached. Its sensing layer is what every later shape ran on.
The company gave Command the part the kit carries forward whole: the colors. Green runs unattended, yellow is built but held for a session I’m in, red needs my signature, and four acts (spend money, publish, message someone new, destroy data) stay red at every rung. Loop cards, from 5 August, made every unattended job write down what it holds steady, how it measures, and what acts. What it measured as waste: thirty days of filing 31 problems against itself and closing 12 [measured 2026-09-10, the 26 July analysis], and on 4 August all seven items waiting on me were work staff could have done [measured 2026-08-16, the decision folder, via the project page].
The office showed that a scheduled job can finish work rather than only notice it: its four-hourly remediation tick opened 31 pull requests in 30 days and 29 merged [measured 2026-08-21, post 34]. What it measured as waste is the August token share described earlier, and the merge gate sitting off for two days before anyone noticed.
The board showed that a dispatcher with no model in it can move work, and it is where the two run-away limits were written and landed on 4 September: a second unclaimed return escalates, and a fleet-wide silence freezes launches. What it measured as waste: about 1,830 million input tokens in its week, a quarter of them to the board and its workers, for four of the 34 venture pull requests merged that week [measured 2026-09-10, the kit plan’s token table, counted once per API call], and a worker launched against work that was already finished, after which I turned the dispatcher off on 9 September [measured 2026-09-10, the dispatch log and the session record of the pause].
Since 3 June, 565 pull requests have merged into Command’s own repository, 227 of them in the last thirty days [measured 2026-09-11, the repository’s merged pull request list]. The colors, the loop cards, the review loop and the handoff skills all came out of those pull requests. So did four rebuilds, and the kit’s bet is that most of that work no longer needs doing.
What the review found, ranked by cost
On 10 September I put the six questions to the board shape, in order, reading the rulebook, the registry, the run records, the git history, and the live state of workflows and scheduled tasks. Five findings, ordered by what each cost me: attention and money first, then the controls, then the sensors, then the part that reaches a person.
1. It worked on itself more than on the goals it existed for. The goals file names eight active goals, seven of them for ventures, billing, publishing and discovery, and one for Command’s own evolvability [measured 2026-09-11, the goals file, dated 10 September]. Against that, the two weeks above. One week is a small sample. The board’s week was its first, it held the credit outage, and the review step for worker pull requests was never built, so the kit plan itself reads its sixteen open worker pull requests as consistent with “the review never got built” as with “the shape is wrong” [measured 2026-09-11, the kit plan’s first section]. That caveat cuts the 4 of 34. The office’s week, two weeks in, stands on its own, and so do the four rebuilds. The stronger objection is that a system being built spends on itself by definition, and the kit’s first week will look the same. That is why the trial described above scores tokens per merged venture pull request and not the operator’s share of the bill.
2. The controls the rulebook described were switched off. The green tier rests on one mechanical check: a pull request merges itself when CI is green and a review verdict pinned to the head commit is on record. The gate is a GitHub workflow, disabled by hand since 31 August [measured 2026-09-10, the repository’s workflow list and its last run]; a session found this on 2 September with seventeen pull requests open, and the September 11 count was 35. The compiled default still accepts an unsigned verdict [measured 2026-09-10, the gate’s source], and the September board refused to merge on Command’s own repository, deferring to the gate that was off [measured 2026-09-10, the board’s design note]. Nothing in the rulebook said the gate was off.
3. Records disagreed with repositories, and the primary checkout sat six days behind. The goals record said a venture’s production release had not been promoted when the cloud console showed it had, and a correction had to be filed [measured 2026-09-10, the goals correction in the git history]. A self-report is a sensor pointed at the worker, not at the world. On September 11, the primary Command folder on this machine sat at a 4 September commit on its default branch, thirteen commits ahead of the remote and ten behind it [measured 2026-09-11, git status, git rev-list and git diff against the fetched remote]. Two sensors were built after the same thing happened on 4 August. The weekly hygiene job checks which branch a checkout is on and has no read of distance [measured 2026-09-10, the hygiene script]. A session-start check does measure distance and prints a loud banner, but it runs only when a session starts in that folder and asks, and nothing on a clock reads its answer [measured 2026-09-11, the checkout-freshness script run against the primary folder].
4. The part that reached me was on its fourth form, and asks still fell out. Each form was built for something the one before showed. A folder of items awaiting my signature made a decision answerable in a word. The August decision board showed that staff could re-tier my queue themselves: of 26 resolutions, sixteen were re-tiered after re-running the checklist [measured 2026-08-16, the decision folder, via the project page]. The September board’s ask command put the ask beside the work item it came from. GitHub labels with a desktop notification put it where I already look. Each form also lost things the next one had to catch. A partner’s 4 September request sat in a parked item whose ask expired unanswered two days later, and it is nowhere on GitHub [measured 2026-09-10, the kit plan’s list of data lost between layers]. This is the human part, which the charter says must never be simulated, and no form so far counted how many asks it lost.
5. Spend had no cap, and the run-away limits came after the run-away. The charter treats compute as capital to allocate and warns against optimising for low burn, so there was no per-item, per-run or per-week budget [measured 2026-09-10, the charter and the board’s design note]. Overnight on 3 to 4 September my plan’s credits ran out, every worker paused, and the dispatcher, needing no credits, read every stale lease as a stalled worker and launched a replacement: fifteen launches, twelve returns, seven false escalations in eleven hours, and three items relaunched every forty minutes while the claim hook was broken [measured 2026-09-10, the fix’s commit body]. The loop had no way to notice it was looping, and it stopped when the outage ended. The metered thing is my plan’s quota, so it cost an outage and no money.
If you have a technical problem you’d like another engineer to investigate, tell me what you’re working through. We agree on the scope and price before I begin. I’ll investigate, write up my findings, then meet with you to discuss the recommendations and next steps. This illustrative excerpt shows how I’d write up the merge-control finding from my own review.
Revision log
-
September 12, 2026: Updated the invitation to a scoped investigation with written findings and a discussion afterward. Removed the fixed-price session. The historical findings are unchanged.
-
September 12, 2026: Reordered the essay around the kit design, the decision to try it, the strongest counterargument, and the trial. Preserved the September 10–11 source findings and trial limits. This was an editorial review against the existing article and project reference, not a new check of Command’s private records or a trial result; the verification date remains September 11.