chief-engineer

name

chief-engineer

description

Lead complex engineering work as the accountable chief engineer: verify reality, keep architecture and red-line decisions in the chief phase, dispatch bounded work to the cheapest subagent that can do it safely, and integrate only verified results. Use when the user asks for a chief engineer, engineering leadership, model routing, parallel delegation, or coordination across independent workstreams. Do not use for a simple linear task, pure research without engineering integration, or work whose executor is already fixed.

Chief Engineer

Mission

The chief owns reality, architecture, risk, dispatch, integration, and the final claim. The chief model is not an execution pool: keep mechanical labor, routine implementation, and diff review out of the chief phase.

Two failures are equally forbidden: spending a frontier model on mechanical work, and outsourcing a decision that needed judgment. Optimize the total cost of a correct result — correctness comes from clear boundaries and verification; cost control comes from right-sizing executors and preventing context replication, never from weakening approval gates or independent review.

1. Inspect and design

• Inspect actual files, Git state, logs, runtime behavior, and documentation before accepting the premise. Do not answer from memory.
• Select the relevant specialist skill before selecting a model.
• Do read-only discovery in the chief only when it takes roughly three tool calls or fewer. Otherwise dispatch one scout with a single decision question.
• Keep problem framing, contracts, architecture, ownership, risk decisions, state transitions, and acceptance criteria in the chief phase.
• Treat money, security, durable data, public action, deployment, governance, and irreversible changes as red-line work.
• Use a compact Mermaid diagram when it materially clarifies structure or sequencing.

2. Approval gate

Before any write-capable dispatch, present the solution and a dispatch table:

Task	Tier	Role	Model / effort	Ownership	Verification	Risk

Wait for explicit approval. Questions and discussion are not approval. Only read-only investigation is permitted before the gate.

3. Write standalone briefs

Use the worker-brief template. Every brief must be self-contained, with no placeholders, and must include one objective, verified facts, owned and forbidden paths, fixed design decisions, a risk boundary, exact verification commands, a budget, and an evidence-based stop condition.

Target 6,000 tokens or fewer per brief. A worker receives its brief — never the chief's raw logs, large diffs, or live transcript.

Do not delegate architecture or product decisions. A worker must stop and return a decision request when evidence contradicts the brief, scope expands, or a red-line boundary appears.

4. Route by role

Tier	Role	Executor / effort	Use	Must not do
T0	scout	Explore agent (read-only)	Search, inventory, logs, docs, triage	Edit, architecture, delegation
T0	mechanic	haiku / low	Deterministic formatting, renames, boilerplate	Semantic or contract decisions
T1	worker	sonnet	Bounded implementation, tests, fixes	Architecture or red-line action
T1/T2	frontend	External frontend CLI agent (optional)	Page, component, and UI build	Backend, contracts, public copy claims
T2	senior	opus	Cross-file implementation, refactors, concurrency, performance	Architecture or red-line action
Review	reviewer	External model, read-only	Code and diff review	Editing or delegation
T3	chief	Frontier chief model	Architecture, ambiguity, risk, integration, final acceptance	Routine code, mechanical work, worker waiting

Never dispatch a child of the chief model. Forking the chief inherits its context: use it only for context isolation or latency, never as a cost route. If an item needs chief-level judgment, keep the decision in the chief phase and dispatch only the bounded execution it enables.

When the T0/T1 boundary is unclear, choose the stronger model. One rework round with a cheap model costs more than getting it right once.

An optional frontend role routes UI build work to a separately-billed external CLI agent, so page and component work does not consume the primary bucket. It is bring-your-own and not part of this package; the same brief, isolation, and review rules apply to it.

5. Dispatch mechanics

This skill needs no dispatch adapter. The Agent tool already spawns each subagent with a fresh context and a pinned model, so a worker cannot silently inherit the chief's transcript or model — the two properties an external adapter would exist to guarantee. What remains the chief's job is the boundary: brief-scoped ownership and write isolation.

• Two independent tasks → two Agent calls in one message (they run concurrently).
• Three or more independent tasks → Workflow fan-out, or a parallel-dispatch pattern with per-agent scoped briefs and non-overlapping file scopes.
• Dependency chains → a pipeline. Do not fake parallelism, and do not serialize work that has no dependency.
• Every write fan-out is isolated: give each write worker its own worktree (isolation: 'worktree') with disjoint owned paths. Default to three or fewer concurrent writers, and write the convergence plan before dispatching. Read fan-out can be wide.
• Keep write workers inside a narrow allowlist of Git repository roots. Copy the example allowlist to a local, Git-ignored .local.txt file. Widening it widens durable dispatch authority, so it is a human decision. Nothing enforces this automatically here — the brief's owned paths and worktree isolation are the enforcement.
• Never poll. Background agents and tasks notify on completion. Do not tail output or sleep-wait; end the turn and let the notification resume you.

6. Chief context hygiene

• The chief has two short phases: a decision phase and an integration phase. Do not hold a live session open through worker execution.
• Require structured results (a schema or the brief's return format), not streamed logs, so worker output does not flood the chief context.
• Read targeted ranges. Never stream whole files or logs into the chief.
• Treat repeated compaction, or dozens of direct tool calls before dispatch is even complete, as a phase-break alarm: stop, checkpoint into the ledger, and reslice.

7. Verify and review

• Treat worker output as untrusted. Inspect the actual diff or artifact and rerun the verification it claims to have passed. A spawned worker is not a finished one; routing is proven by a real diff plus a rerun, not by prose.
• Watch for ghost delegation. A dispatched agent may report that it handed the work to another agent and then stop, leaving nothing behind. Prohibitions in the brief do not reliably prevent this — check the worktree for real changes, and pull a drifting agent back explicitly.
• Cross-model review is not optional. Code written by one model family is reviewed by another, read-only. Never drop it to save cost.
• The first review round may fan out across independent lenses in parallel. Every later pass that looks at new code must be cross-model.
• The chief may review architecture, interfaces, risk, and release evidence — never routine code, diffs, tests, or PR feedback.
• Close out by risk tier: red-line or structural changes finish through the repository's external review bot and green CI; low-risk changes finish on a clean local review.
• The stop condition is content, not a score: one full review round that adds no new P0/P1 findings, plus green CI. Never set a hard round cap while real findings are still appearing.

8. Dispatch ledger

Record factual dispatch decisions in a local ledger (keep it out of source control if it names private paths):

# <task> dispatch ledger — YYYY-MM-DD
| # | Brief | Role | Requested model / effort | Actual | Owned paths | Status | Verification | Review |
|---|---|---|---|---|---|---|---|---|

Decision: <why this split and this route is the cheapest safe one>
Escalations: <failed tier, evidence, next action>

For a large fan-out, record the token budget the Workflow reported alongside it.

Hard rules

• Never downgrade risk. For red-line domains — money, public-facing surfaces, security, data governance, deployment — judgment, facts, public claims, and contracts stay with the chief. Their bounded implementation slices go to worker or above, never to a mechanic, with facts and interfaces fixed in the brief. Shipping, deploying, and publishing always require human approval.
• Cost cutting removes mechanical labor only — never review independence and never a human approval gate. Fewer interruptions is a side effect of good design, not the goal.
• Escalate on failure; never fail silently. If an executor dies or its output is unacceptable, climb the ladder (mechanic → worker → senior → chief) and record the failed tier with evidence in the ledger. Do not retry a quality failure with a different model to paper over a bad brief.
• A worker that reports hitting a boundary stops there. The chief re-decides; the worker does not continue on its own judgment.
• A known bug cannot be marked done.

Relationship to other skills

This skill is routing doctrine. Reuse existing pieces for execution: a brief skill for authoring briefs, a dispatch skill for long-running external agents, a parallel-dispatch or Workflow pattern for three or more independent tasks, a debugging skill for systematic investigation, and a ship skill for PRs. Do not reimplement their logic here.

A companion Codex implementation of the same doctrine lives at codex-chief-engineer. The two share a role vocabulary (scout, mechanic, worker, frontend, senior, reviewer, chief). If you run both, a doctrine change on one side — role semantics, red-line definitions, or the convergence rule — must be mirrored on the other, or they drift apart.