I had built a fairly elaborate delivery system around named roles, hooks, state, and handoffs. I am now trying a much smaller surface: one skill for working as a team and one for the moments when repository delivery really needs formal custody.
The old system encoded the workflow as a cast of constrained roles. The new experiment keeps the useful boundaries, but asks two broader skills to activate only when the work earns them.
A voice-directed runtime, registry, hooks, capabilities, transitions, and role-specific contracts carried work through the delivery graph.
Codex handles ordinary work directly. Coordination and formal delivery become explicit, progressive-disclosure layers rather than the default shape of every task.
This is less about removing safety than deciding where the safety belongs.
Teamwork gives the coordinator a small set of rules for bounded, non-overlapping agent lanes while keeping one person responsible for synthesis and approval gates.
Governed Delivery is the narrower gate for tracked repository work: issue, branch, worktree, pull request, exact-head review, merge, deploy, migration, and post-delivery proof.
The working rule: do ordinary work directly; use Teamwork when multiple agents will materially help; use Governed Delivery when tracked custody, independent review, or an external delivery gate is actually required.
The point of this pass is not to prove that two is the perfect number. It is to see whether a smaller instruction surface gives the agents more room to do good work without losing the boundaries I care about.
Do fewer always-available roles and runtime rules reduce hidden instruction noise?
Can ordinary work stay light while risky delivery still gets a real custody trail?
Is it easier to understand why Codex delegated, reviewed, paused, or asked for authority?
Can the durable invariants be tested without maintaining a full orchestration runtime?
This visual reflects the current working tree on the
issue-41-release-teamwork-govern-evals branch. The package manifest proposes v2.0.0
and the new README describes the two-skill model, but these changes are still uncommitted in the
inspected checkout. The canonical remote main remains the released v1.0.0 state.
This is a field note about what I am trying, not a claim that v2 has shipped.
I am testing whether the smallest setup that preserves the important gates is also the one that makes the work feel the most legible.