canon

problem

Every project I started got the same agent scaffolding typed into it again, and every copy moved away from the last. I wanted one source I could install rather than a folder I kept re-authoring.

Drift on this surface is quiet. A rule that fell behind still loads, still reads as authoritative, and produces work against a convention I had already abandoned somewhere else. Nothing fails, so nothing reports it.

standards

Content reaches a project through two operations. install lays it down once. sync updates only files already present, and it is safe to repeat against a project that has edited what it was given, because an install stamp records what the toolkit wrote and so tells a file canon moved from a file the project changed.

Rules carry a path glob, so a Python rule stays dormant in a TypeScript project. The project's own rules live in a folder the sync never walks, and a rule canon has retired is deleted from every project rather than left loading. A sync cannot introduce a surface the project never asked for, and it cannot overwrite a rule the project wrote.

workflow

The rules are not the whole product. The plan, review, and ship loop ships alongside them as skills a session invokes rather than steps a person remembers.

An idea is sorted first. What the repository can already answer goes to a plan, and what nobody has measured goes to groundwork, a short investigation that ends in a decision. The plan names every file it will touch and gives each open question a suggested answer, so it can be approved in one pass. A worker then writes a failing test before any code, and the checks have to pass before it opens a pull request.

Review travels on the pull request itself. One skill posts findings to it, another reads them back, fixes each, and pushes a follow-up, and the review then runs again against only the commits that follow-up added.

The workflow it ships is the workflow that built it.

It runs my other repositories the same way, including a private one whose whole job is keeping the copy on my CV, LinkedIn, GitHub profile, and this site in step.

parallel

Work runs across parallel Claude Code sessions split by vantage rather than by capability, in four roles. One warm orchestrator session holds the cross-feature picture and dispatches the rest as background sessions: a planner writes one plan, a worker builds one plan in its own git worktree and stops at a draft pull request, and a reviewer reads a pull request it did not write. The orchestrator edits no tracked file and merges nothing. I start the orchestrator and merge every pull request.

The two review passes differ by vantage rather than by depth. A worker's self-review asks whether it built the plan and whether it passes, and it is blind to its own misreadings, because the same misreading wrote both the code and the review. The independent pass reads the diff, the plan, and the rules, and leaves the author's own summary unread. A dedicated reviewer takes it when a change touches code or several pull requests are waiting, and the orchestrator keeps one pass across every branch in a wave for merge order and overlap.

What binds the number of tracks is collision between file sets rather than a fixed cap. A candidate opens only where its files are disjoint from every track already running. What thins as tracks multiply is my own read before each merge, and the orchestrator's context as it holds more work in flight.

agents

All of it depends on agents being able to drive the same tooling without a person reading terminal output beside them.

Every command has a non-interactive path, every listing emits JSON on stdout, and the framed terminal UI goes to stderr. A skill shelling out to the CLI can treat stdout as data without parsing around a progress frame.

A unit suite covers the code whose failures stay invisible at runtime, and the workflow itself is tested on sandbox scenarios. Each scenario provisions an isolated project state, points a headless session at it, and asserts which files the run wrote, whether it escaped that scope, and what its own reply said. A disposable GitHub remote lets the skills that depend on gh run end to end, including opening a pull request, merging it, and editing its body.

Testing a workflow that opens pull requests means letting it open real ones somewhere it cannot do damage.