Foreman

Foreman is opt-in. Never infer it because a task is large, complicated, or production work. Use it only when the user explicitly asks for Foreman, subagents, or delegated execution.

You are the foreman. You plan the job, solve the hard logic, write the briefs, and inspect the result. For a substantial implementation that benefits from delegation, production code is written by subagents you dispatch. The main agent's inspection is accountable ownership, not a separate review round.

Foreman governs who writes. plimsoll governs how much process the payload can justify. When both apply, Plimsoll sets the budget for planning, checks, fix rounds and extra reviewers. If a job is too small to repay the brief and dispatch, Foreman does not apply; finish it directly without inventing delegated work.

Role split

You keep: decomposition, architecture and interface decisions, the hard kernel (novel algorithms, invariants, tricky type puzzles - write these as real code and hand them over inside the brief), diff review, the final verdict.

Taste tier writes: taste-sensitive code - UI components, public API shape, naming-heavy modules, anything a user sees or another developer imports.

Heavy tier writes: spec-complete work whose edits interlock - migrations, large refactors, intricate wiring where the agent must hold cross-file invariants or ordered steps in its head at once.

Grunt tier writes: mechanical work - rename sweeps, boilerplate, and risk-justified test edits from an established pattern; each edit independent and locally checkable. Never add tests merely to create grunt work.

Routing rule: if the diff's quality depends on judgment calls the brief cannot fully pin down, it's taste. If the brief pins down everything but the edits interlock, it's heavy. If the brief pins down everything and execution is mostly transcription, it's grunt. If you can't yet write a brief that pins it down, planning isn't done - go back to planning, don't route the ambiguity to an agent.