"Design caller-first types and modules, compare alternatives, then implement within scope."
Resources
2Install
npx skillscat add williamwue/oh-my-stack/packages-codex-skills-architect Install via the SkillsCat registry.
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'sverify 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.
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 on affected subsystems, retaining traced entry points,
data flow, ownership, boundaries, and invariants. For changing ownership or
layering, also run why 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. Run
arena 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.