Architect

---
name: architect
description: "Design caller-first types and modules, compare alternatives, then implement within scope."
---

# Architect

## Codex delegation binding

For every delegated worker in this workflow, derive the exact `model`,
`reasoning_effort`, and complete role-plus-task `message` with
`../../scripts/codex-delegation.mjs prepare` relative to this Skill. It resolves
the nearest project manifest first, then the user manifest. Supply the named
route/panel entry where configured; otherwise supply the canonical role
and the observed parent model and effort. Pass
the returned `task_name`, `fork_turns=none`, model, effort, and message
explicitly to the spawn call. Do not use a generated custom-role name as a selector or
claim its TOML was activated. After the worker finishes, run the helper's
`verify` mode on the persisted parent and child records when available; it
checks the spawn metadata, parent link, and child `turn_context`.
The persisted spawn message may be encrypted; disclose when its exact
role/task text cannot be audited. If records are unavailable, state that
runtime model resolution is unverified.

## Child session handoff

Read [the handoff contract](../poteto-mode/references/subagent-handoff.md).
New tasks, repair rounds, retries, and queue items use fresh child sessions
with the original brief, every later directive, prior findings and responses,
and unresolved objections. Reuse only for required costly live state, and
only when the host allows it. Stop and fence active writers before replacement.
A host-owned orchestrator's model catalog, workspace binding, child tools,
and review-round rules take precedence over the native binding above.
Keep its task handles and attribution receipts. Do not use a backing child
conversation as a new delegated review, or claim native-record verification
for a host-owned child. Report attribution evidence gaps explicitly.

Design before implementation. Track grounding, sketches, synthesis/checkpoint,
implementation, and redesign. A design-only request stops at a design. This
workflow does not expand a request for advice into permission to edit code.

## Ground

Run [how](../how/SKILL.md) on affected subsystems, retaining traced entry points,
data flow, ownership, boundaries, and invariants. For changing ownership or
layering, also run [why](../why/SKILL.md) and carry forward Preserve / Change /
Avoid / Risk constraints with their confidence. Genuinely greenfield work may
skip existing-system grounding, but must still identify integration constraints.

## Sketch and synthesize

Read [the design contract](references/design-contract.md). Run
[arena](../arena/SKILL.md) with the same grounded problem for each runner and
that design contract. Require at least two structurally distinct candidates,
not two cosmetic versions of one design. State this requirement in the common
brief. If candidates converge, ask for a concrete alternative within the budget
or mark alternative exploration incomplete; do not silently waive the requirement.
When configured, pass the ordered `architect.runners` panel to Arena rather
than its general runner panel; its length sets the default candidate count.

Candidates write caller usage first, derive types/signatures and module
ownership from it, and mark bodies as pseudocode or not implemented. Keep
unfinished scaffolding out of the user's working code unless scaffold editing
was requested as part of implementation. Screen red flags before synthesis.
The parent selects and grafts against the rubric, recording interface depth,
invariants, tradeoffs, rejected alternatives, and open questions.

## Checkpoint and implement

Respect an explicit request to stop for approval. Otherwise proceed only when
the user requested implementation and the chosen scope is authorized. A design
request ends with the sketch, rationale, risks, and next implementation step.
Publication, destructive migration, or new external authority still needs its
own authorization.

For implementation, replace placeholders incrementally and verify each usable
unit against the caller examples and invariants. Maintain a deviation ledger:
changed signature or ownership, triggering evidence, and whether the sketch,
requirement, or implementation was wrong. Do not absorb contradictions silently.

## Redesign when needed

Repeated workarounds across unrelated paths, internal details leaking to
callers, type escape hatches, or two independent deviations of the same shape
trigger reassessment. A single legitimate edge case is not automatically a
failed architecture. Re-run how on the actual implementation, make the new
constraints explicit, subtract unnecessary structure, and return to arena
within the agreed budget. Preserve user changes; redesign never authorizes
destructive reset or discarding unrelated work.

Return caller usage, chosen types/signatures and module map, synthesis rationale,
tradeoffs, alternative shapes, open risks, and the next step. If implementation
ran, also report deviations and checks of the final code. Clearly distinguish
a verified design sketch from implemented and behaviorally verified software.