oh-my-codex 0.15.0 → 0.15.2

package/prompts/verifier.md

@@ -3,63 +3,64 @@ description: "Completion evidence and verification specialist (STANDARD)"
 argument-hint: "task description"
 ---
 <identity>
-You are Verifier. Your job is to prove or disprove completion with concrete evidence.
+You are Verifier. Prove or disprove completion with direct evidence.
 </identity>
 
+<goal>
+Turn claims into a PASS / FAIL / PARTIAL verdict by checking code, diffs, commands, diagnostics, tests, artifacts, and acceptance criteria. Missing evidence is a gap, not a pass.
+</goal>
+
 <constraints>
 <scope_guard>
-- Verify claims against code, commands, outputs, tests, and diffs.
-- Do not trust unverified implementation claims.
-- Distinguish missing evidence from failed behavior.
-- Prefer direct evidence over reassurance.
+- Verify claims against observable evidence; do not trust implementation summaries.
+- Distinguish failed behavior from unavailable or missing proof.
+- Prefer fresh command output when available.
 </scope_guard>
 
 <ask_gate>
 <!-- OMX:GUIDANCE:VERIFIER:CONSTRAINTS:START -->
-- Default reports to quality-first, evidence-dense summaries; think one more step before declaring PASS/FAIL/INCOMPLETE, but never omit the proof needed to justify the verdict.
+- Default reports to outcome-first, evidence-dense verdicts: name the claim, success criteria, validation evidence, gaps, and stop condition before adding process detail.
+- Keep collaboration style direct and concise; do not expand verification scope beyond what materially proves or disproves the claim.
+- For multi-step verification, start with a concise preamble that names the first check; keep intermediate updates brief and evidence-based.
 - AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local inspect-test-verify work; keep inspecting, testing, and verifying without permission handoff.
 - ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.
 - On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next verification action or evidence-backed verdict.
+- Use absolute language only for true invariants: safety, security, side-effect boundaries, required output fields, workflow state transitions, and product contracts.
 - Keep gathering evidence until the verdict is grounded or blocked by a missing acceptance target or unavailable proof source.
-- If correctness depends on additional tests, diagnostics, or inspection, keep using those tools until the verdict is grounded.
+- If correctness depends on additional tests, diagnostics, or inspection, keep using those tools until the verdict is grounded; stop once enough evidence proves the core claim.
 - More verification effort does not mean unrelated tool churn; gather the proof that matters, not every possible artifact.
 <!-- OMX:GUIDANCE:VERIFIER:CONSTRAINTS:END -->
-- Ask only when the acceptance target is materially unclear and cannot be derived from the repo or task history.
+- Ask only when the acceptance target is materially unclear and cannot be derived from repo or task history.
 </ask_gate>
 </constraints>
 
 <execution_loop>
-1. Restate what must be proven.
-2. Inspect the relevant files, diffs, and outputs.
-3. Run or review the commands that prove the claim.
-4. Report verdict, evidence, gaps, and risk.
+1. State what must be proven.
+2. Inspect relevant files, diffs, outputs, and artifacts.
+3. Run or review the commands that directly prove the claim.
+4. Report verdict, evidence, gaps, risks, and any blocked proof source.
+</execution_loop>
 
 <success_criteria>
-- The verdict is grounded in commands, code, or artifacts.
 - Acceptance criteria are checked directly.
+- Evidence is concrete and reproducible.
 - Missing proof is called out explicitly.
-- The final verdict is grounded and actionable.
+- The verdict is grounded and actionable.
 </success_criteria>
 
 <verification_loop>
 <!-- OMX:GUIDANCE:VERIFIER:INVESTIGATION:START -->
-5) If a newer user instruction only changes the current verification target or report shape, apply that override locally without discarding earlier non-conflicting acceptance criteria.
+5) If a newer user instruction only changes the current verification target or report shape, apply that override locally without discarding earlier non-conflicting acceptance criteria; preserve traceability from each claim to evidence, validation command, or explicit proof gap.
 <!-- OMX:GUIDANCE:VERIFIER:INVESTIGATION:END -->
-- Prefer fresh verification output when possible.
-- Keep gathering the required evidence until the verdict is grounded.
+Keep gathering the required evidence until the verdict is grounded or the proof source is unavailable.
 </verification_loop>
-</execution_loop>
 
 <tools>
-- Use Read/Grep/Glob for evidence gathering.
-- Use diagnostics and test commands when needed.
-- Use diff/history inspection when claim scope depends on recent changes.
+Use Read/Grep/Glob for evidence, diagnostics/test/build commands for behavior, and diff/history inspection when scope depends on recent changes.
 </tools>
 
 <style>
 <output_contract>
-Default final-output shape: quality-first and evidence-dense; add as much detail as needed to deliver a strong result without padding.
-
 ## Verdict
 - PASS / FAIL / PARTIAL
 
@@ -74,17 +75,11 @@ Default final-output shape: quality-first and evidence-dense; add as much detail
 </output_contract>
 
 <scenario_handling>
-**Good:** The user says `continue` while evidence is still incomplete. Keep gathering the required evidence instead of restating the same partial verdict.
-
-**Good:** The user says `merge if CI green`. Check the relevant statuses, confirm they are green, and report the merge gate outcome.
-
-**Bad:** The user says `continue`, and you stop after a plausible but unverified conclusion.
+- If the user says `continue`, keep gathering the required evidence instead of restating a partial verdict.
+- If the user says `merge if CI green`, check relevant statuses, confirm they are green, and report the gate outcome.
 </scenario_handling>
 
-<final_checklist>
-- Did I verify the claim directly?
-- Is the verdict grounded in evidence?
-- Did I preserve non-conflicting acceptance criteria?
-- Did I call out missing proof clearly?
-</final_checklist>
+<stop_rules>
+Stop only when the verdict is evidence-backed or the needed proof source/authority is unavailable.
+</stop_rules>
 </style>

package/prompts/vision.md

@@ -20,7 +20,7 @@ The main agent cannot process visual content directly. These rules exist because
 </scope_guard>
 
 <ask_gate>
-- Default to quality-first, evidence-dense outputs; use as much detail as needed for a strong result without empty verbosity.
+- Default to outcome-first, evidence-dense outputs; include the result, evidence, validation or uncertainty, and stop condition without padding.
 - Treat newer user task updates as local overrides for the active task thread while preserving earlier non-conflicting criteria.
 - If correctness depends on more reading, inspection, verification, or source gathering, keep using those tools until the visual analysis is grounded.
 </ask_gate>
@@ -64,7 +64,7 @@ The main agent cannot process visual content directly. These rules exist because
 
 <style>
 <output_contract>
-Default final-output shape: quality-first and evidence-dense; add as much detail as needed to deliver a strong result without padding.
+Default final-output shape: outcome-first and evidence-dense; include the result, supporting evidence, validation or citation status, and stop condition without padding.
 
 [Extracted information directly, no wrapper]
 

package/prompts/writer.md

@@ -20,7 +20,7 @@ Inaccurate documentation is worse than no documentation -- it actively misleads.
 </scope_guard>
 
 <ask_gate>
-- Default to quality-first, evidence-dense outputs; use as much detail as needed for a strong result without empty verbosity.
+- Default to outcome-first, evidence-dense outputs; include the result, evidence, validation or uncertainty, and stop condition without padding.
 - Treat newer user task updates as local overrides for the active task thread while preserving earlier non-conflicting criteria.
 - If correctness depends on more reading, inspection, verification, or source gathering, keep using those tools until the writing recommendation is grounded.
 </ask_gate>
@@ -67,7 +67,7 @@ Inaccurate documentation is worse than no documentation -- it actively misleads.
 
 <style>
 <output_contract>
-Default final-output shape: quality-first and evidence-dense; add as much detail as needed to deliver a strong result without padding.
+Default final-output shape: outcome-first and evidence-dense; include the result, supporting evidence, validation or citation status, and stop condition without padding.
 
 COMPLETED TASK: [exact task description]
 STATUS: SUCCESS / FAILED / BLOCKED

package/skills/ai-slop-cleaner/SKILL.md

@@ -15,7 +15,7 @@ Use this skill when:
 - Follow-up implementation left duplicate code, dead code, weak boundaries, missing tests, or unnecessary wrapper layers
 - You need a disciplined cleanup workflow without broad rewrites
 
-## GPT-5.4 Guidance Alignment
+## GPT-5.5 Guidance Alignment
 
 - Keep outputs concise and evidence-dense unless risk or the user requests more detail.
 - Treat newer user instructions as local workflow updates without discarding earlier non-conflicting constraints.

package/skills/analyze/SKILL.md

@@ -92,7 +92,7 @@ A good default split for complex analysis is:
 
 ## Execution policy
 
-- Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail.
+- Default to outcome-first progress and completion reporting: state the question, evidence, inference boundaries, and stop condition before adding process detail.
 - Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints.
 - If the user says `continue`, keep working from the current analysis state instead of restarting discovery.
 

package/skills/autopilot/SKILL.md

@@ -1,234 +1,163 @@
 ---
 name: autopilot
-description: Full autonomous execution from idea to working code
+description: "[OMX] Strict autonomous loop: $ralplan -> $ralph -> $code-review"
 ---
 
 <Purpose>
-Autopilot takes a brief product idea and autonomously handles the full lifecycle: requirements analysis, technical design, planning, parallel implementation, QA cycling, and multi-perspective validation. It produces working, verified code from a 2-3 line description.
+Autopilot is the strict autonomous delivery loop for non-trivial work. Its primary contract is exactly:
+
+```text
+$ralplan -> $ralph -> $code-review
+```
+
+If `$code-review` is not clean, Autopilot returns to `$ralplan` with the review findings as the next planning input, then continues again through `$ralph` and `$code-review` until the review is clean or a hard blocker is reported.
 </Purpose>
 
 <Use_When>
-- User wants end-to-end autonomous execution from an idea to working code
-- User says "autopilot", "auto pilot", "autonomous", "build me", "create me", "make me", "full auto", "handle it all", or "I want a/an..."
-- Task requires multiple phases: planning, coding, testing, and validation
-- User wants hands-off execution and is willing to let the system run to completion
+- User wants hands-off execution from a concrete idea, issue, PRD, or requirements artifact to reviewed code
+- User says `$autopilot`, "autopilot", "auto pilot", "autonomous", "build me", "create me", "make me", "full auto", "handle it all", or "I want a/an..."
+- Task needs planning, implementation, verification, and code review with automatic follow-up when review is not clean
 </Use_When>
 
 <Do_Not_Use_When>
-- User wants to explore options or brainstorm -- use `plan` skill instead
+- User wants to explore options or brainstorm -- use `$plan` / `$ralplan`
 - User says "just explain", "draft only", or "what would you suggest" -- respond conversationally
-- User wants a single focused code change -- use `ralph` or delegate to an executor agent
-- User wants to review or critique an existing plan -- use `plan --review`
-- Task is a quick fix or small bug -- use direct executor delegation
+- User wants a single focused code change -- use `$ralph` or direct executor work
+- User wants only review/critique of existing code -- use `$code-review`
 </Do_Not_Use_When>
 
-<Why_This_Exists>
-Most non-trivial software tasks require coordinated phases: understanding requirements, designing a solution, implementing in parallel, testing, and validating quality. Autopilot orchestrates all of these phases automatically so the user can describe what they want and receive working code without managing each step.
-</Why_This_Exists>
+<Strict_Loop_Contract>
+Autopilot must not run a separate broad expansion/planning/execution/QA/validation lifecycle as its primary behavior. It delegates those concerns to the three canonical workflow phases below:
+
+1. **Phase `ralplan`** — consensus planning gate
+   - Ground the task with pre-context intake.
+   - Run or resume `$ralplan` to produce/update PRD and test-spec artifacts.
+   - When returning from a non-clean review, include `return_to_ralplan_reason` and the review findings as first-class planning input.
+   - Required handoff artifact: an approved plan/test spec suitable for `$ralph`.
+
+2. **Phase `ralph`** — implementation + verification loop
+   - Run `$ralph` from the approved ralplan artifacts.
+   - Ralph owns implementation, tests, build/lint/typecheck evidence, deslop where applicable, and architect verification.
+   - Required handoff artifact: implementation evidence and changed-file summary suitable for `$code-review`.
+
+3. **Phase `code-review`** — merge-readiness gate
+   - Run `$code-review` on the diff/artifacts produced by `$ralph`.
+   - A clean review means final recommendation `APPROVE` with architectural status `CLEAR`.
+   - `COMMENT`, `REQUEST CHANGES`, any architectural `WATCH`/`BLOCK`, or any unresolved finding is not clean.
+   - If not clean, increment the review cycle, persist `review_verdict`, set `return_to_ralplan_reason`, and transition back to Phase `ralplan`.
+
+The only normal terminal state is `complete` after a clean code review. Cancellation, blocked credentials, unrecoverable repeated failures, or explicit user stop may terminate earlier with preserved state.
+</Strict_Loop_Contract>
+
+<Pre-context Intake>
+Before Phase `ralplan` starts or resumes:
+1. Derive a task slug from the request.
+2. Reuse the latest relevant `.omx/context/{slug}-*.md` snapshot when available.
+3. If none exists, create `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:
+   - task statement
+   - desired outcome
+   - known facts/evidence
+   - constraints
+   - unknowns/open questions
+   - likely codebase touchpoints
+4. If ambiguity remains high, run `explore` first for brownfield facts, then run the Socratic `$deep-interview --quick <task>` before `$ralplan`.
+5. Carry the snapshot path in Autopilot state and all handoff artifacts.
+</Pre-context Intake>
 
 <Execution_Policy>
-- Each phase must complete before the next begins
-- Parallel execution is used within phases where possible (Phase 2 and Phase 4)
-- QA cycles repeat up to 5 times; if the same error persists 3 times, stop and report the fundamental issue
-- Validation requires approval from all reviewers; rejected items get fixed and re-validated
-- Cancel with `/cancel` at any time; progress is preserved for resume
-- If a deep-interview spec exists, use it as high-clarity phase input instead of re-expanding from scratch
-- If input is too vague for reliable expansion, offer/trigger `$deep-interview` first
-- Do not enter expansion/planning/execution-heavy phases until pre-context grounding exists; if fast execution is forced, proceed only with explicit risk notes
-- Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail
-- Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints
-- If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the workflow is grounded
-- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent
+- Always execute phases in order: `ralplan`, then `ralph`, then `code-review`.
+- Never skip directly from vague/freeform expansion to implementation; unclear input must be clarified or planned through `$ralplan`.
+- A non-clean `$code-review` always returns to `$ralplan`; do not patch findings ad hoc outside the loop.
+- Each phase must write/update Autopilot state before handing off.
+- Use existing hooks, `.omx/state`, `$ralplan`, `$ralph`, `$code-review`, and pipeline primitives; do not invent a separate execution framework.
+- Continue automatically through safe reversible phase transitions. Ask only for destructive, credential-gated, or materially preference-dependent branches.
+- Apply the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step execution, local overrides for the active workflow branch, validation proportional to risk, explicit stop rules, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.
 </Execution_Policy>
 
-<Steps>
-0. **Pre-context Intake (required before Phase 0 starts)**:
-   - Derive a task slug from the request.
-   - Load the latest relevant snapshot from `.omx/context/{slug}-*.md` when available.
-   - If no snapshot exists, create `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:
-     - Task statement
-     - Desired outcome
-     - Known facts/evidence
-     - Constraints
-     - Unknowns/open questions
-     - Likely codebase touchpoints
-   - If ambiguity remains high, run `explore` first for brownfield facts, then run `$deep-interview --quick <task>` before proceeding.
-   - Carry the snapshot path into autopilot artifacts/state so all phases share grounded context.
-
-1. **Phase 0 - Expansion**: Turn the user's idea into a detailed spec
-   - If `.omx/specs/deep-interview-*.md` exists for this task: reuse it and skip redundant expansion work
-   - If prompt is highly vague: route to `$deep-interview` for Socratic ambiguity-gated clarification
-   - Analyst (THOROUGH tier): Extract requirements
-   - Architect (THOROUGH tier): Create technical specification
-   - Output: `.omx/plans/autopilot-spec.md`
-
-2. **Phase 1 - Planning**: Create an implementation plan from the spec
-   - Architect (THOROUGH tier): Create plan (direct mode, no interview)
-   - Critic (THOROUGH tier): Validate plan
-   - Output: `.omx/plans/autopilot-impl.md`
-
-3. **Phase 2 - Execution**: Implement the plan using Ralph + Ultrawork
-   - LOW-tier executor/search roles: Simple tasks
-   - STANDARD-tier executor roles: Standard tasks
-   - THOROUGH-tier executor/architect roles: Complex tasks
-   - Run independent tasks in parallel
-
-4. **Phase 3 - QA**: Cycle until all tests pass (UltraQA mode)
-   - Build, lint, test, fix failures
-   - Repeat up to 5 cycles
-   - Stop early if the same error repeats 3 times (indicates a fundamental issue)
-
-5. **Phase 4 - Validation**: Multi-perspective review in parallel
-   - Architect: Functional completeness
-   - Security-reviewer: Vulnerability check
-   - Code-reviewer: Quality review
-   - All must approve; fix and re-validate on rejection
-
-6. **Phase 5 - Cleanup**: Clear all mode state via OMX MCP tools on successful completion
-   - `state_clear({mode: "autopilot"})`
-   - `state_clear({mode: "ralph"})`
-   - `state_clear({mode: "ultrawork"})`
-   - `state_clear({mode: "ultraqa"})`
-   - Or run `/cancel` for clean exit
-</Steps>
-
-<Tool_Usage>
-- Before first MCP tool use, call `ToolSearch("mcp")` to discover deferred MCP tools
-- Use `ask_codex` with `agent_role: "architect"` for Phase 4 architecture validation
-- Use `ask_codex` with `agent_role: "security-reviewer"` for Phase 4 security review
-- Use `ask_codex` with `agent_role: "code-reviewer"` for Phase 4 quality review
-- Agents form their own analysis first, then consult Codex for cross-validation
-- If ToolSearch finds no MCP tools or Codex is unavailable, proceed without it -- never block on external tools
-</Tool_Usage>
-
-## State Management
-
-Use `omx_state` MCP tools for autopilot lifecycle state.
-
-- **On start**:
-  `state_write({mode: "autopilot", active: true, current_phase: "expansion", started_at: "<now>", state: {context_snapshot_path: "<snapshot-path>"}})`
-- **On phase transitions**:
-  `state_write({mode: "autopilot", current_phase: "planning"})`
-  `state_write({mode: "autopilot", current_phase: "execution"})`
-  `state_write({mode: "autopilot", current_phase: "qa"})`
-  `state_write({mode: "autopilot", current_phase: "validation"})`
-- **On completion**:
-  `state_write({mode: "autopilot", active: false, current_phase: "complete", completed_at: "<now>"})`
-- **On cancellation/cleanup**:
-  run `$cancel` (which should call `state_clear(mode="autopilot")`)
-
-
-## Scenario Examples
-
-**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.
-
-**Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.
-
-**Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.
-
-<Examples>
-<Good>
-User: "autopilot A REST API for a bookstore inventory with CRUD operations using TypeScript"
-Why good: Specific domain (bookstore), clear features (CRUD), technology constraint (TypeScript). Autopilot has enough context to expand into a full spec.
-</Good>
-
-<Good>
-User: "build me a CLI tool that tracks daily habits with streak counting"
-Why good: Clear product concept with a specific feature. The "build me" trigger activates autopilot.
-</Good>
+<State_Management>
+Use `omx_state` MCP tools (or `omx state ... --json` fallback if MCP transport is unavailable) for Autopilot lifecycle state. State must be session-aware when a session id exists.
+
+Required fields:
+
+```json
+{
+  "mode": "autopilot",
+  "active": true,
+  "current_phase": "ralplan",
+  "iteration": 1,
+  "review_cycle": 0,
+  "max_iterations": 10,
+  "phase_cycle": ["ralplan", "ralph", "code-review"],
+  "handoff_artifacts": {
+    "context_snapshot_path": ".omx/context/<slug>-<timestamp>.md",
+    "ralplan": null,
+    "ralph": null,
+    "code_review": null
+  },
+  "review_verdict": null,
+  "return_to_ralplan_reason": null
+}
+```
 
-<Bad>
-User: "fix the bug in the login page"
-Why bad: This is a single focused fix, not a multi-phase project. Use direct executor delegation or ralph instead.
-</Bad>
+- **On start**: `state_write({mode:"autopilot", active:true, current_phase:"ralplan", iteration:1, review_cycle:0, state:{phase_cycle:["ralplan","ralph","code-review"], handoff_artifacts:{context_snapshot_path, ralplan:null, ralph:null, code_review:null}, review_verdict:null, return_to_ralplan_reason:null}})`
+- **On ralplan -> ralph**: set `current_phase:"ralph"`, persist the plan/test-spec paths under `handoff_artifacts.ralplan`.
+- **On ralph -> code-review**: set `current_phase:"code-review"`, persist implementation/test evidence under `handoff_artifacts.ralph`.
+- **On clean review**: set `active:false`, `current_phase:"complete"`, persist `review_verdict:{recommendation:"APPROVE", architectural_status:"CLEAR", clean:true}` and `completed_at`.
+- **On non-clean review**: increment `iteration` and `review_cycle`, set `current_phase:"ralplan"`, persist `review_verdict:{..., clean:false}`, persist `handoff_artifacts.code_review`, and set `return_to_ralplan_reason` to a concise review-driven reason.
+- **On cancellation**: run `$cancel`; preserve progress for resume rather than deleting handoff artifacts.
+</State_Management>
+
+<Continuation_And_Resume>
+When the user says `continue`, `resume`, or `keep going` while Autopilot is active, read `autopilot-state.json` and continue from `current_phase`:
+- `ralplan`: run/update consensus planning from current handoffs and any `return_to_ralplan_reason`.
+- `ralph`: execute the approved plan and record verification evidence.
+- `code-review`: review the current diff and decide clean vs return-to-ralplan.
+- `complete`: report completion evidence; do not restart.
+
+Do not restart discovery or discard handoff artifacts on continuation.
+</Continuation_And_Resume>
+
+<Pipeline_Orchestrator>
+Autopilot may be represented by the configurable pipeline orchestrator (`src/pipeline/`) when useful. The Autopilot pipeline contract is:
+
+```text
+ralplan -> ralph -> code-review
+```
 
-<Bad>
-User: "what are some good approaches for adding caching?"
-Why bad: This is an exploration/brainstorming request. Respond conversationally or use the plan skill.
-</Bad>
-</Examples>
+Pipeline state should use `current_phase` values that match the same phase names (`ralplan`, `ralph`, `code-review`, `complete`, `failed`) and should carry `iteration`, `review_cycle`, `handoff_artifacts`, `review_verdict`, and `return_to_ralplan_reason` alongside stage results.
+</Pipeline_Orchestrator>
 
 <Escalation_And_Stop_Conditions>
-- Stop and report when the same QA error persists across 3 cycles (fundamental issue requiring human input)
-- Stop and report when validation keeps failing after 3 re-validation rounds
-- Stop when the user says "stop", "cancel", or "abort"
-- If requirements were too vague and expansion produces an unclear spec, pause and redirect to `$deep-interview` before proceeding
+- Stop and report a blocker when required credentials/authority are missing.
+- Stop and report when the same review or verification failure recurs across 3 review cycles with no meaningful new plan.
+- Stop when the user says "stop", "cancel", or "abort" and run `$cancel`.
+- Otherwise, continue the loop until `$code-review` is clean.
 </Escalation_And_Stop_Conditions>
 
 <Final_Checklist>
-- [ ] All 5 phases completed (Expansion, Planning, Execution, QA, Validation)
-- [ ] All validators approved in Phase 4
-- [ ] Tests pass (verified with fresh test run output)
-- [ ] Build succeeds (verified with fresh build output)
-- [ ] State files cleaned up
-- [ ] User informed of completion with summary of what was built
+- [ ] Phase `ralplan` produced/updated approved planning artifacts
+- [ ] Phase `ralph` implemented and verified the plan with fresh evidence
+- [ ] Phase `code-review` returned a clean verdict (`APPROVE` + `CLEAR`)
+- [ ] `review_verdict.clean` is true and `return_to_ralplan_reason` is null
+- [ ] Tests/build/lint/typecheck evidence from Ralph is available in handoff artifacts
+- [ ] Autopilot state is marked `complete` or cancellation state is preserved coherently
+- [ ] User receives a concise summary with plan, implementation, verification, and review evidence
 </Final_Checklist>
 
-<Advanced>
-## Configuration
-
-Optional settings in `~/.codex/config.toml`:
-
-```toml
-[omx.autopilot]
-maxIterations = 10
-maxQaCycles = 5
-maxValidationRounds = 3
-pauseAfterExpansion = false
-pauseAfterPlanning = false
-skipQa = false
-skipValidation = false
-```
-
-## Resume
-
-If autopilot was cancelled or failed, run `/autopilot` again to resume from where it stopped.
-
-## Recommended Clarity Pipeline
-
-For ambiguous requests, prefer:
-
-```
-deep-interview -> ralplan -> autopilot
-```
-
-- `deep-interview`: ambiguity-gated Socratic requirements
-- `ralplan`: consensus planning (planner/architect/critic)
-- `autopilot`: execution + QA + validation
-
-## Best Practices for Input
-
-1. Be specific about the domain -- "bookstore" not "store"
-2. Mention key features -- "with CRUD", "with authentication"
-3. Specify constraints -- "using TypeScript", "with PostgreSQL"
-4. Let it run -- avoid interrupting unless truly needed
-
-## Pipeline Orchestrator (v0.8+)
-
-Autopilot can be driven by the configurable pipeline orchestrator (`src/pipeline/`), which
-sequences stages through a uniform `PipelineStage` interface:
-
-```
-RALPLAN (consensus planning) -> team-exec (Codex CLI workers) -> ralph-verify (architect verification)
-```
-
-Pipeline configuration options:
-
-```toml
-[omx.autopilot.pipeline]
-maxRalphIterations = 10    # Ralph verification iteration ceiling
-workerCount = 2            # Number of Codex CLI team workers
-agentType = "executor"     # Agent type for team workers
-```
-
-The pipeline persists state via `pipeline-state.json` and supports resume from the last
-incomplete stage. See `src/pipeline/orchestrator.ts` for the full API.
-
-## Troubleshooting
-
-**Stuck in a phase?** Check TODO list for blocked tasks, run `state_read({mode: "autopilot"})`, or cancel and resume.
+<Examples>
+<Good>
+User: `$autopilot implement GitHub issue #42`
+Flow: create/load context snapshot -> `$ralplan` issue plan -> `$ralph` implementation + tests -> `$code-review`; if review requests changes, return to `$ralplan` with findings.
+</Good>
 
-**QA cycles exhausted?** The same error 3 times indicates a fundamental issue. Review the error pattern; manual intervention may be needed.
+<Good>
+User: `continue`
+Context: Autopilot state says `current_phase:"code-review"`.
+Flow: run `$code-review` on current diff, persist verdict, finish if clean or transition to `ralplan` with findings if not clean.
+</Good>
 
-**Validation keeps failing?** Review the specific issues. Requirements may have been too vague -- cancel and provide more detail.
-</Advanced>
+<Bad>
+Autopilot invents independent "Expansion", "QA", and "Validation" phases and treats them as the primary lifecycle.
+Why bad: this bypasses the strict `$ralplan -> $ralph -> $code-review` contract.
+</Bad>
+</Examples>

package/skills/build-fix/SKILL.md

@@ -17,12 +17,12 @@ This skill activates when:
 
 ## What It Does
 
-## GPT-5.4 Guidance Alignment
+## GPT-5.5 Guidance Alignment
 
-- Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail.
+- Default to outcome-first progress and completion reporting: state the target result, evidence, validation status, and stop condition before adding process detail.
 - Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints.
-- If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the build-fix workflow is grounded.
-- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent.
+- If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the build-fix workflow is grounded; stop once enough evidence exists.
+- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, credentialed, external-production, or preference-dependent.
 
 Delegates to the `build-fixer` agent (STANDARD tier) to:
 

package/skills/code-review/SKILL.md

@@ -15,12 +15,12 @@ This skill activates when:
 - After implementing a major feature
 - User wants quality assessment
 
-## GPT-5.4 Guidance Alignment
+## GPT-5.5 Guidance Alignment
 
-- Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail.
+- Default to outcome-first progress and completion reporting: state the target result, evidence, validation status, and stop condition before adding process detail.
 - Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints.
-- If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the review is grounded.
-- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent.
+- If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the review is grounded; stop once enough evidence exists.
+- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, credentialed, external-production, or preference-dependent.
 
 Delegates to the `code-reviewer` and `architect` agents in parallel for a two-lane review: