Does the backlog work a worker structurally cannot: linking dependencies ACROSS goals, catching the same work described differently in two goals, goal hygiene, and staleness. Use PROACTIVELY when items have landed in several goals, or on a cadence. Boundary: does not refine within a goal — a worker derives its own…
Reads one turn's work and records anything it implied that would otherwise be lost — a feature, guardrail, schema change, risk or mitigation. Use PROACTIVELY after a turn that changed files or reached a conclusion. Returns only the ids it recorded and what it skipped. Boundary: records single items as they surface…
Runs an investigation whose deliverable is a document and a recommendation, not code — whether an effect is real, which design survives contact with the data, whether something is worth building at all. Use for "/oz study" and when a question needs analysis before anything can sensibly be built. Concluding "do not…
Sorts the backlog so the human reads less: finds duplicates, and separates what two specialists can settle from what only the principal can decide. Use PROACTIVELY before a checkpoint, or when the backlog has grown faster than it has been read. Boundary: reports and re-links; never decides gates and never marks…
Drives one goal's features to completion in priority order: claims the next ready item, implements it, records evidence, releases the claim, repeats. Use for "/oz task " and for the sessions "/oz start" spawns. Boundary: works one goal in one worktree; shaping the queue is oz-backlog's job and deciding gates is the…
The project's feature, parity and decision-gate tracker. Use for "/oz", "oz status", "oz table", "oz gates", "oz add", "oz help", and whenever work implies a feature, guardrail, schema change, risk or mitigation that would otherwise be lost. Backed by a per-project database in the repo's .oz folder.