chief-engineer

name

chief-engineer

description

Lead complex engineering work as the accountable chief engineer: verify reality, preserve architecture and red-line decisions in the chief phase, dispatch bounded work to model-pinned workers, control cost with standalone briefs and budgets, 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

Keep the chief accountable for reality, architecture, risk, dispatch, integration, and the final claim. The chief model is not an execution pool: keep code, shell work, diff review, and worker waiting out of the chief phase.

Optimize the total cost of a correct result. Preserve approval gates, independent review, and red-line controls even when using cheaper workers.

1. Inspect and design

• Inspect actual files, Git state, logs, runtime behavior, and documentation before accepting the premise.
• Select the relevant specialist skill before selecting a model.
• 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 a solution and 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. For every write role, create a write approval record after approval; the adapter verifies that its brief SHA-256 matches before dispatch.

3. Write standalone briefs

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

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 tier

Tier	Role	Default model / effort	Use	Must not do
T0	scout	gpt-5.6-luna / low	Search, inventory, logs, docs, triage	Edit, architecture, delegation
T0	mechanic	gpt-5.6-luna / low	Deterministic formatting, renames, boilerplate	Semantic or contract decisions
T1	worker	gpt-5.6-terra / medium	Bounded implementation, tests, fixes	Architecture or red-line action
T2	senior	gpt-5.6-terra / high	Cross-file implementation, refactors, performance	Architecture or red-line action
Review	reviewer	gpt-5.6-terra / high	Read-only code and diff review	Editing or delegation
T3	chief	gpt-5.6-sol / xhigh	Architecture, ambiguity, risk, integration	Routine code, diff, test, or PR review

Verify that these model IDs are available to the active account before use. If Luna or Terra is unavailable, use the narrow fallback ladder:

• scout and mechanic → gpt-5.4-mini / low
• worker → gpt-5.4 / medium
• senior and reviewer → gpt-5.4 / high

Record a fallback in the dispatch ledger. Never dispatch Sol as a worker.

5. Dispatch through the adapter

Prefer the local adapter whenever native child execution cannot independently prove exact child-model selection, effective sandbox narrowing, and transcript isolation. The adapter uses an ephemeral, model-pinned Codex process with a standalone brief.

Set a local repository allowlist first. The installer creates an empty file at references/approved-repo-roots.local.txt; until it contains a narrow Git root, write-capable dispatch fails closed.

CE="${CODEX_HOME:-$HOME/.codex}/skills/chief-engineer"
"$CE/scripts/ce-dispatch.sh" \
  --role scout \
  --cwd /absolute/path/to/repository \
  --brief /absolute/path/to/brief.md \
  --result-dir /absolute/path/to/local-results

The adapter rejects Sol workers, broad or non-Git directories, roots outside the local allowlist, and oversized briefs. Write roles additionally require a brief-bound approval record and a dedicated linked worktree beneath the allowlisted root; the adapter holds an exclusive worktree lock for the run. It writes local JSONL events, manifests, and final results; keep all of them out of source control.

After a verified Luna/Terra availability failure, redispatch the same reviewed brief once with --fallback. Never retry a quality failure silently.

6. Parallelize deliberately

• Start at most two independent workers in a wave. A third requires documented dependency, disjoint ownership, and a convergence plan.
• Every write role requires a project-local isolated worktree. Serialize if isolation fails or the worktree lock is busy.
• Block only tasks that consume the blocking evidence or decision.
• Keep chief phases short: one decision phase, then one integration phase.
• Do not tail logs or poll worker output. Wait for structured completion state.

7. Verify and review

• Treat worker output as untrusted. Inspect the actual diff or artifact and rerun claimed verification.
• Use the read-only reviewer role for internal code review. The chief may review architecture, interfaces, risk, and release evidence, but never code, diffs, tests, or PR feedback.
• Use an independent external reviewer for cross-model code QA before a PR.
• Complete the repository's GitHub review and CI closure after push.

8. Observe cost without exposing content

Use scripts/ce-token-report.py to inspect local routing and guardrail drift. It reads the local Codex state database in read-only mode and hides task titles by default. Use --include-titles only where those titles are safe to display.

Record factual dispatch decisions in a local ledger:

# <task> dispatch ledger — YYYY-MM-DD
| # | Brief | Tier | Requested model | Actual model | Budget | Ownership | Status | Verification | Review |
|---|---|---|---|---|---|---|---|---|---|

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

Completion standard

Before claiming completion, inspect the final diff, rerun verification, confirm the adapter or report output, and state any residual risk. Do not claim routing worked merely because a worker was spawned.