fable-opus-codex

# Delegate implementation, then require independent review Compose the `fable-opus` implementation protocol with the `codex-review` iterative reviewer protocol. The skill name records the default Fable → Opus → Codex pairing; each role is independently replaceable. ## Role selection Resolve all roles before work: 1. Apply explicit user selections for host, orchestrator, implementer, reviewer, and models. 2. Fill unspecified roles from compatible project or session configuration. 3. Use defaults only for remaining roles: - orchestrator: Fable 5.1 at high effort; - implementer/fixer: the provider or harness's `opus` latest-model alias, currently Claude Opus 5.5 (`claude-opus-5-5`), at xhigh for code and high for browser work; - reviewer: Codex CLI with `gpt-6-astra`, high reasoning, regular service tier, and read-only access. Confirm alias resolution for the installed provider and CLI version. The current Opus target is `claude-opus-5-5`; Claude Code requires v2.1.280 or later. If `opus` or `fable` resolves to an older release, use the current full model ID or provider deployment ID and report the actual model selected. Settings propagate by role. For example, `implementer=cursor-agent reviewer=claude-opus` replaces both defaults while leaving the active host free to be Codex, Claude Code, Cursor, or another Agent Skills client. Never silently replace an explicitly requested role. If only a default is unavailable, declare the compatible fallback before continuing. ## Steps 1–3: implement and verify Load the companion `fable-opus` skill when it is installed. Otherwise use this self-contained implementation protocol: 1. create or adopt a written plan; 2. delegate disjoint workstreams to the selected implementation workers; 3. verify the real diff, project checks, runtime behavior, and every plan item; 4. send confirmed defects to fresh workers using the same selected implementer. Do not start independent review while orchestrator verification has open findings. The reviewer evaluates finished work, not work in progress. ## Step 4: independent code-review gate Load the companion `codex-review` skill when it is installed. Otherwise apply the tool-selection, session handling, verdict, and five-round protocol described below, reviewing the implemented diff against the plan. ### 1. Prepare the review packet Create a session-scoped review directory using the platform's safe temporary-directory mechanism. Write an implementation map containing: - repository root and branch; - merge base or exact commit range; - plan path; - changed files; - summary of each workstream; - verification already completed; - documented constraints and intentional decisions. Keep the map concise. The selected reviewer must inspect the actual changed files through read-only repository access. ### 2. Review Ask the selected reviewer to assess: 1. plan compliance and missing or stubbed work; 2. correctness with real input and state tracing; 3. regressions in adjacent behavior; 4. security, privacy, data-loss, and permission risks; 5. leftover debug code, temporary artifacts, or dead paths; 6. gaps in tests and runtime verification. Require file/line/scenario evidence and one exact final line: `VERDICT: APPROVED` or `VERDICT: REVISE`. The default reviewer is the `codex-review` Codex CLI configuration. When the user selects another reviewer, use that agent's native isolated review capability or authenticated non-interactive CLI while preserving read-only access and the same verdict protocol. ### 3. Verify and resolve findings For every finding: - verify it against the current checkout; - classify it as confirmed, stale, wrong, intentional, or blocked; - send confirmed fixes to a fresh worker using the selected implementer; - rebut stale, wrong, or intentional findings with evidence; - rerun relevant checks after fixes. The orchestrator must not implement reviewer fixes directly. ### 4. Re-review Resume the exact reviewer session when supported. Otherwise start a fresh read-only round whose packet includes the previous review, verified fixes, rebuttals, and current diff. Never use a global “last session” selector during concurrent work. Stop after approval or five rounds. Five rounds without approval is not success; report unresolved findings for the user to decide. ## Step 5: report Report: - selected host and all role/model choices; - plan completion evidence; - review verdict and round count; - findings fixed, rebutted, or blocked; - exact test/build/runtime outcomes; - remaining environment/provider/device setup. Do not commit or push. Shipping remains a separate explicit action through the `ship` skill. ## Requirements - An isolated implementation-worker capability or compatible external coding-agent CLI. - A read-only reviewer capability or compatible external reviewer CLI. - Defaults require access to Fable 5.1, the runtime-resolved latest Opus model, and an installed/authenticated Codex CLI with GPT-6 Astra access; user-selected alternatives replace only the corresponding requirement.