Audit an incoming problem statement, feature brief, or requirements draft before domain modeling or architecture work. Use when Codex needs a structured pre-design review that surfaces weak assumptions, contradictions, scope gaps, missing constraints, hidden risks, and unanswered questions. Do not use for architecture design, contract design, or implementation.
Design external system contracts from approved domain and architecture artifacts with stable IDs. Use when Codex needs REST, gRPC, event, CLI, queue, or other interface definitions that trace back to use cases, ports, and invariants and are ready for implementation planning. Do not use for domain modeling, architecture design, or implementation.
Design clean architecture boundaries from an approved domain model with stable use-case and invariant IDs. Use when Codex needs layers, dependency direction, ports, adapters, module boundaries, placement rules, and forbidden dependencies before defining interfaces or writing code. Do not use for reviewing existing code or for interface contract design.
Extract a reusable domain model from an approved brief or problem framing artifact. Use when Codex needs actors, use cases, entities, value objects, business rules, invariants, constraints, and canonical terms distilled into a stable domain artifact before architecture or contract design. Do not use for API design, module design, or implementation.
Implement exactly one approved slice from existing contracts and architecture rules. Use only when Codex has one approved `SLICE-*`, relevant contracts, architecture rules, resolved technology context, and codebase context and must write or modify code, tests, and a mandatory implementation report using established repository conventions, repo-backed stack profiles, or explicitly justified fallback practices. Do not use for planning, architecture redesign, or multi-slice delivery.
Orchestrate the reusable workflow from a brief through producer, gate, and rework stages. Use when Codex must decide the current stage, missing inputs, next producer skill, gate profile, and whether rework is required. Do not use to replace the producer or gate skills themselves.
Split an approved design into small, traceable implementation slices. Use when Codex needs reviewable, testable, dependency-aware coding increments with stable slice IDs, done criteria, touched modules, and validation scope before implementation starts. Do not use for coding, bug fixing, or architecture redesign.
Review code and contracts for clean architecture boundary violations. Use when Codex needs a structured boundary review and, only when explicit gate inputs are provided, a gate decision about dependency direction, layer leakage, port-adapter separation, DTO leakage, framework leakage, or forbidden imports after implementation or refactoring. Do not use to design the architecture from scratch.