process-pack

Use at the polish stage of a design direction, once structure is settled, to turn a prototype's own tokens into a small panel of eye-decidable knobs a designer drives by hand, and to route what they settle back into the token system and the taste rules. Emits an altitude-appropriate facet spec, and at polish a self-contained tunable playground. Skip it when the artifact has no eye-tunable surface.

Use when onboarding a new person or a new repo to this pack — constants files don't exist yet, need regenerating, or a repo needs its own landmine list captured. Also use when a standing correction keeps recurring and hasn't been turned into a candidate rule yet.

Use before grounding a design or technical direction in external references — comparing tools, evaluating approaches, gathering prior art — before committing to a direction. Produces a source index, a synthesis, and concrete candidate directions instead of a pile of links.

Use before writing any planning artifact a human has to approve - a spec, an implementation plan, or a long dispatch brief. Gate the full artifact behind a tight stub the human will actually read, get approval on the stub, then elaborate and adversarially review the full thing.

Use when receiving a design or code review to execute, or when writing a review someone else will execute. Splits every review item into one of four buckets before any work starts, so parked items don't get silently rebuilt and outgoing reviews arrive pre-executable.

Use any time more than one lane of work (delegate, agent, or workstream) is active against the same project. Maintains board.json as the single source of truth for lane state — written on every lane transition, not batched — so status reporting, "what's running", handoffs, and kill decisions are all queries against one file instead of reconstructed from memory.

Use when declaring any work item done, or when writing the report/evidence block of a dispatch brief. Defines the gate list — the specific evidence required before something counts as done — per class of work, plus universal rules that apply to every class.

Use when writing the prompt or brief for any delegate — an in-session subagent, an external coding-agent CLI, a peer on a multi-agent mesh, or a background/cloud runtime — before you dispatch. Also use when a delegate returned wrong or incomplete work, since that almost always means the brief was underspecified, not that the delegate was weak.

Use when a fork in the work could produce a consequence outside this task's own blast radius, or when a decision is hard enough that you're tempted to reach for the most capable model available to resolve it. Names the fork classes that always stop for a human, and the pattern for calling in a top-tier model as a consultant rather than a resident decision-maker.

Use before any dispatch or command that touches an external runtime, an account, an org-scoped tool, or a billing surface — including invoking another agent runtime headlessly. Answers which wallet, which org, and which identity before the command runs, and stops at a wall instead of working around it.

Use whenever writing a delegate brief, triaging an automated review, or about to do something a standing correction already covers — a compatibility shim, a squash merge, unlabeled jargon, reinventing an existing pattern, or a judgment call a hook could verify instead. Reads the standing taste rules from constants and carries them into the brief or the review response.

Use before dispatching more than one delegate against the same repo, or whenever a work list has more than two items. Produces the lane table — ownership, phase, and merge order — that has to exist before any dispatch happens, not after a collision is discovered.

Use whenever a task-notification arrives from a delegate, whenever you're asked "still going?" or "did it finish?", or whenever a dispatched delegate has gone quiet longer than its stated estimate. Classifies every completion signal before anything gets relayed as done.

Use before proposing any fix for a bug, test failure, performance regression, or unexpected behavior. Requires a stated causal mechanism before a fix is written, and treats a contradicted hypothesis as progress, not failure.