oh-my-codex 0.8.4 → 0.8.6

package/skills/autopilot/SKILL.md

@@ -35,6 +35,10 @@ Most non-trivial software tasks require coordinated phases: understanding requir
 - 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
 </Execution_Policy>
 
 <Steps>
@@ -54,19 +58,19 @@ Most non-trivial software tasks require coordinated phases: understanding requir
 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 (Opus): Extract requirements
-   - Architect (Opus): Create technical specification
+   - 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 (Opus): Create plan (direct mode, no interview)
-   - Critic (Opus): Validate plan
+   - 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
-   - Executor-low (Haiku): Simple tasks
-   - Executor (Sonnet): Standard tasks
-   - Executor-high (Opus): Complex tasks
+   - 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)
@@ -113,6 +117,15 @@ Use `omx_state` MCP tools for autopilot lifecycle state.
 - **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"

package/skills/build-fix/SKILL.md

@@ -17,7 +17,14 @@ This skill activates when:
 
 ## What It Does
 
-Delegates to the `build-fixer` agent (Sonnet model) to:
+## GPT-5.4 Guidance Alignment
+
+- 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 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.
+
+Delegates to the `build-fixer` agent (STANDARD tier) to:
 
 1. **Collect Errors**
    - Run the project's type check command (e.g., `tsc --noEmit`, `mypy`, `cargo check`, `go vet`)
@@ -45,9 +52,9 @@ Delegates to the `build-fixer` agent (Sonnet model) to:
 ## Agent Delegation
 
 ```
-spawn_sub_agent(
-  subagent_type="oh-my-codex:build-fixer",
-  model="sonnet",
+delegate(
+  role="build-fixer",
+  tier="STANDARD",
   prompt="BUILD FIX TASK
 
 Fix all build and TypeScript errors with minimal changes.
@@ -100,6 +107,15 @@ Verification: [type check command] (exit code 0)
 - **Document why** - Comment non-obvious fixes
 - **Test after** - Ensure tests still pass
 
+
+## 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.
+
 ## Use with Other Skills
 
 Combine with other skills for comprehensive fixing:

package/skills/code-review/SKILL.md

@@ -17,7 +17,14 @@ This skill activates when:
 
 ## What It Does
 
-Delegates to the `code-reviewer` agent (Opus model) for deep analysis:
+## GPT-5.4 Guidance Alignment
+
+- 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 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.
+
+Delegates to the `code-reviewer` agent (THOROUGH tier) for deep analysis:
 
 1. **Identify Changes**
    - Run `git diff` to find changed files
@@ -44,9 +51,9 @@ Delegates to the `code-reviewer` agent (Opus model) for deep analysis:
 ## Agent Delegation
 
 ```
-spawn_sub_agent(
-  subagent_type="oh-my-codex:code-reviewer",
-  model="opus",
+delegate(
+  role="code-reviewer",
+  tier="THOROUGH",
   prompt="CODE REVIEW TASK
 
 Review code changes for quality, security, and maintainability.
@@ -179,6 +186,15 @@ The code-reviewer agent checks:
 **REQUEST CHANGES** - CRITICAL or HIGH issues present
 **COMMENT** - Only LOW/MEDIUM issues, no blocking concerns
 
+
+## 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.
+
 ## Use with Other Skills
 
 **With Team:**

package/skills/ecomode/SKILL.md

@@ -13,9 +13,9 @@ Overrides default model selection to prefer cheaper tiers:
 
 | Default Tier | Ecomode Override |
 |--------------|------------------|
-| HIGH (opus) | MEDIUM (sonnet), HIGH only if essential |
-| MEDIUM (sonnet) | LOW (haiku) first, MEDIUM if fails |
-| LOW (haiku) | LOW (haiku) - no change |
+| THOROUGH | STANDARD, THOROUGH only if essential |
+| STANDARD | LOW first, STANDARD if needed |
+| LOW | LOW - no change |
 
 ## What Ecomode Does NOT Do
 
@@ -39,9 +39,9 @@ Ecomode is a modifier that combines with execution modes:
 
 | Decision | Rule |
 |----------|------|
-| DEFAULT | Start with LOW tier (Haiku) for most tasks |
-| UPGRADE | Escalate to MEDIUM (Sonnet) when LOW tier fails or task requires multi-file reasoning |
-| AVOID | HIGH tier (Opus) - only for planning/critique if essential |
+| DEFAULT | Start with LOW tier for most tasks |
+| UPGRADE | Escalate to STANDARD when LOW tier fails or task requires multi-file reasoning |
+| AVOID | THOROUGH tier - only for planning/critique if essential |
 
 ## Agent Selection in Ecomode
 
@@ -55,16 +55,16 @@ This provides the complete agent tier matrix, MCP tool assignments, and selectio
 
 ```
 // PREFERRED - Use for most tasks
-spawn_sub_agent(subagent_type="oh-my-codex:executor-low", model="haiku", prompt="...")
-spawn_sub_agent(subagent_type="oh-my-codex:explore", model="haiku", prompt="...")
-spawn_sub_agent(subagent_type="oh-my-codex:architect-low", model="haiku", prompt="...")
+delegate(role="executor", tier="LOW", task="...")
+delegate(role="explore", tier="LOW", task="...")
+delegate(role="architect", tier="LOW", task="...")
 
 // FALLBACK - Only if LOW fails
-spawn_sub_agent(subagent_type="oh-my-codex:executor", model="sonnet", prompt="...")
-spawn_sub_agent(subagent_type="oh-my-codex:architect-medium", model="sonnet", prompt="...")
+delegate(role="executor", tier="STANDARD", task="...")
+delegate(role="architect", tier="STANDARD", task="...")
 
 // AVOID - Only for planning/critique if essential
-spawn_sub_agent(subagent_type="oh-my-codex:planner", model="opus", prompt="...")
+delegate(role="planner", tier="THOROUGH", task="...")
 ```
 
 ## Delegation Enforcement
@@ -73,10 +73,10 @@ Ecomode maintains all delegation rules from core protocol with cost-optimized ro
 
 | Action | Delegate To | Model |
 |--------|-------------|-------|
-| Code changes | executor-low / executor | haiku / sonnet |
-| Analysis | architect-low | haiku |
-| Search | explore | haiku |
-| Documentation | writer | haiku |
+| Code changes | executor | LOW / STANDARD |
+| Analysis | architect | LOW |
+| Search | explore | LOW |
+| Documentation | writer | LOW |
 
 ### Background Execution
 Long-running commands (install, build, test) run in background. Maximum 20 concurrent.
@@ -84,10 +84,10 @@ Long-running commands (install, build, test) run in background. Maximum 20 concu
 ## Token Savings Tips
 
 1. **Batch similar tasks** to one agent instead of spawning many
-2. **Use explore (haiku)** for file discovery, not architect
-3. **Prefer executor-low** for simple changes - only upgrade if it fails
-4. **Use writer (haiku)** for all documentation tasks
-5. **Avoid opus agents** unless the task genuinely requires deep reasoning
+2. **Use explore (LOW tier)** for file discovery, not architect
+3. **Prefer LOW-tier executor routing** for simple changes - only upgrade if it fails
+4. **Use writer (LOW tier)** for all documentation tasks
+5. **Avoid THOROUGH-tier agents** unless the task genuinely requires deep reasoning
 
 ## Disabling Ecomode
 

package/skills/frontend-ui-ux/SKILL.md

@@ -22,7 +22,7 @@ If ToolSearch finds no MCP tools, use the Codex agent fallback below.
 
 ### Fallback: Codex Agent
 ```
-spawn_sub_agent(subagent_type="oh-my-codex:designer", model="sonnet", prompt="{{ARGUMENTS}}")
+delegate(role="designer", tier="STANDARD", task="{{ARGUMENTS}}")
 ```
 
 ## Capabilities

package/skills/git-master/SKILL.md

@@ -16,7 +16,7 @@ Routes to the git-master agent for git operations.
 ## Routing
 
 ```
-spawn_sub_agent(subagent_type="oh-my-codex:git-master", model="sonnet", prompt="{{ARGUMENTS}}")
+delegate(role="git-master", tier="STANDARD", task="{{ARGUMENTS}}")
 ```
 
 ## Capabilities

package/skills/help/SKILL.md

@@ -151,7 +151,7 @@ Format a summary with:
 
 TOKEN SUMMARY:
 - Total records: 1,234
-- By Model: opus 45%, sonnet 40%, haiku 15%
+- By Reasoning Effort: high 45%, medium 40%, low 15%
 
 TOP AGENTS:
 1. executor (234 uses)

package/skills/plan/SKILL.md

@@ -33,6 +33,10 @@ Jumping into code without understanding requirements leads to rework, scope cree
 - Plans must meet quality standards: 80%+ claims cite file/line, 90%+ criteria are testable
 - Consensus mode outputs the final plan by default; add `--interactive` to enable execution handoff
 - Consensus mode uses RALPLAN-DR short mode by default; switch to deliberate mode with `--deliberate` or when the request explicitly signals high risk (auth/security, data migration, destructive/irreversible changes, production incident, compliance/PII, public API breakage)
+- 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 plan is grounded
+- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent
 </Execution_Policy>
 
 <Steps>
@@ -53,7 +57,7 @@ Jumping into code without understanding requirements leads to rework, scope cree
 2. **Ask one focused question** using `AskUserQuestion` for preferences, scope, and constraints
 3. **Gather codebase facts first**: Before asking "what patterns does your code use?", spawn an `explore` agent to find out, then ask informed follow-up questions
 4. **Build on answers**: Each question builds on the previous answer
-5. **Consult Analyst** (Opus) for hidden requirements, edge cases, and risks
+5. **Consult Analyst** (THOROUGH tier) for hidden requirements, edge cases, and risks
 6. **Create plan** when the user signals readiness: "create the plan", "I'm ready", "make it a work plan"
 
 ### Direct Mode (detailed requests)
@@ -127,7 +131,7 @@ Plans are saved to `.omx/plans/`. Drafts go to `.omx/drafts/`.
 - Before first MCP tool use, call `ToolSearch("mcp")` to discover deferred MCP tools
 - Use `AskUserQuestion` for preference questions (scope, priority, timeline, risk tolerance) -- provides clickable UI
 - Use plain text for questions needing specific values (port numbers, names, follow-up clarifications)
-- Use `explore` agent (Haiku, 30s timeout) to gather codebase facts before asking the user
+- Use the `explore` agent (LOW tier, bounded quick pass) to gather codebase facts before asking the user
 - Use `ask_codex` with `agent_role: "planner"` for planning validation on large-scope plans
 - Use `ask_codex` with `agent_role: "analyst"` for requirements analysis
 - Use `ask_codex` with `agent_role: "critic"` for plan review in consensus and review modes
@@ -138,6 +142,15 @@ Plans are saved to `.omx/plans/`. Drafts go to `.omx/drafts/`.
 - In consensus mode with `--interactive`, on user approval **MUST** invoke `$ralph` for execution (step 9) -- never implement directly in the planning agent
 </Tool_Usage>
 
+
+## 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>
 Adaptive interview (gathering facts before asking):

package/skills/ralph/SKILL.md

@@ -35,6 +35,10 @@ Complex tasks often fail silently: partial implementations get declared "done",
 - Always pass the `model` parameter explicitly when delegating to agents
 - Read `docs/shared/agent-tiers.md` before first delegation to select correct agent tiers
 - Deliver the full implementation: no scope reduction, no partial completion, no deleting tests to make them pass
+- 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 execution loop is grounded
+- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent
 </Execution_Policy>
 
 <Steps>
@@ -53,9 +57,9 @@ Complex tasks often fail silently: partial implementations get declared "done",
 1. **Review progress**: Check TODO list and any prior iteration state
 2. **Continue from where you left off**: Pick up incomplete tasks
 3. **Delegate in parallel**: Route tasks to specialist agents at appropriate tiers
-   - Simple lookups: LOW tier (Haiku) -- "What does this function return?"
-   - Standard work: MEDIUM tier (Sonnet) -- "Add error handling to this module"
-   - Complex analysis: HIGH tier (Opus) -- "Debug this race condition"
+   - Simple lookups: LOW tier -- "What does this function return?"
+   - Standard work: STANDARD tier -- "Add error handling to this module"
+   - Complex analysis: THOROUGH tier -- "Debug this race condition"
 4. **Run long operations in background**: Builds, installs, test suites use `run_in_background: true`
 5. **Visual task gate (when screenshot/reference images are present)**:
    - Run `$visual-verdict` **before every next edit**.
@@ -69,9 +73,9 @@ Complex tasks often fail silently: partial implementations get declared "done",
    c. Read the output -- confirm it actually passed
    d. Check: zero pending/in_progress TODO items
 7. **Architect verification** (tiered):
-   - <5 files, <100 lines with full tests: STANDARD tier minimum (architect-medium / Sonnet)
-   - Standard changes: STANDARD tier (architect-medium / Sonnet)
-   - >20 files or security/architectural changes: THOROUGH tier (architect / Opus)
+   - <5 files, <100 lines with full tests: STANDARD tier minimum (architect role)
+   - Standard changes: STANDARD tier (architect role)
+   - >20 files or security/architectural changes: THOROUGH tier (architect role)
    - Ralph floor: always at least STANDARD, even for small changes
 8. **On approval**: Run `/cancel` to cleanly exit and clean up all state files
 9. **On rejection**: Fix the issues raised, then re-verify at the same tier
@@ -101,13 +105,22 @@ Use the `omx_state` MCP server tools (`state_write`, `state_read`, `state_clear`
 - **On cancellation/cleanup**:
   run `$cancel` (which should call `state_clear(mode="ralph")`)
 
+
+## 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>
 Correct parallel delegation:
 ```
-spawn_sub_agent(subagent_type="oh-my-codex:executor-low", model="haiku", prompt="Add type export for UserConfig")
-spawn_sub_agent(subagent_type="oh-my-codex:executor", model="sonnet", prompt="Implement the caching layer for API responses")
-spawn_sub_agent(subagent_type="oh-my-codex:executor-high", model="opus", prompt="Refactor auth module to support OAuth2 flow")
+delegate(role="executor", tier="LOW", task="Add type export for UserConfig")
+delegate(role="executor", tier="STANDARD", task="Implement the caching layer for API responses")
+delegate(role="executor", tier="THOROUGH", task="Refactor auth module to support OAuth2 flow")
 ```
 Why good: Three independent tasks fired simultaneously at appropriate tiers.
 </Good>
@@ -118,7 +131,7 @@ Correct verification before completion:
 1. Run: npm test           → Output: "42 passed, 0 failed"
 2. Run: npm run build      → Output: "Build succeeded"
 3. Run: lsp_diagnostics    → Output: 0 errors
-4. Spawn architect-medium  → Verdict: "APPROVED"
+4. Delegate to architect at STANDARD tier  → Verdict: "APPROVED"
 5. Run /cancel
 ```
 Why good: Fresh evidence at each step, architect verification, then clean exit.
@@ -133,9 +146,9 @@ Why bad: Uses "should" and "look good" -- no fresh test/build output, no archite
 <Bad>
 Sequential execution of independent tasks:
 ```
-spawn_sub_agent(executor-low, "Add type export") → wait →
-spawn_sub_agent(executor, "Implement caching") → wait →
-spawn_sub_agent(executor-high, "Refactor auth")
+delegate(executor, LOW, "Add type export") → wait →
+delegate(executor, STANDARD, "Implement caching") → wait →
+delegate(executor, THOROUGH, "Refactor auth")
 ```
 Why bad: These are independent tasks that should run in parallel, not sequentially.
 </Bad>

package/skills/ralplan/SKILL.md

@@ -26,6 +26,13 @@ $ralplan --interactive "task description"
 
 ## Behavior
 
+## GPT-5.4 Guidance Alignment
+
+- 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 consensus-planning flow is grounded.
+- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent.
+
 This skill invokes the Plan skill in consensus mode:
 
 ```
@@ -147,3 +154,11 @@ The gate auto-passes when it detects **any** concrete signal. You do not need al
 | Want to bypass the gate | Prefix with `force:` or `!` (e.g., `force: ralph fix it`) |
 | Gate does not fire on a vague prompt | The gate only catches prompts with <=15 effective words and no concrete anchors; add more detail or use `$ralplan` explicitly |
 | Redirected to ralplan but want to skip planning | In the ralplan workflow, say "just do it" or "skip planning" to transition directly to execution |
+
+## 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.

package/skills/security-review/SKILL.md

@@ -19,7 +19,14 @@ This skill activates when:
 
 ## What It Does
 
-Delegates to the `security-reviewer` agent (Opus model) for deep security analysis:
+## GPT-5.4 Guidance Alignment
+
+- 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 security 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.
+
+Delegates to the `security-reviewer` agent (THOROUGH tier) for deep security analysis:
 
 1. **OWASP Top 10 Scan**
    - A01: Broken Access Control
@@ -61,9 +68,9 @@ Delegates to the `security-reviewer` agent (Opus model) for deep security analys
 ## Agent Delegation
 
 ```
-spawn_sub_agent(
-  subagent_type="oh-my-codex:security-reviewer",
-  model="opus",
+delegate(
+  role="security-reviewer",
+  tier="THOROUGH",
   prompt="SECURITY REVIEW TASK
 
 Conduct comprehensive security audit of codebase.
@@ -254,6 +261,15 @@ The security-reviewer agent verifies:
 4. **Fix MEDIUM** - Planned (within 1 month)
 5. **Fix LOW** - Backlog (when convenient)
 
+
+## 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.
+
 ## Use with Other Skills
 
 **With Team:**

package/skills/team/SKILL.md

@@ -11,6 +11,13 @@ This skill is operationally sensitive. Treat it as an operator workflow, not a g
 
 ## What This Skill Must Do
 
+## GPT-5.4 Guidance Alignment
+
+- 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 team 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.
+
 When user triggers `$team`, the agent must:
 
 1. Invoke OMX runtime directly with `omx team ...`
@@ -139,7 +146,7 @@ Model precedence (highest to lowest):
 
 Thinking-level rule (critical):
 - **No model-name heuristic mapping.**
-- Team runtime must **not** infer `model_reasoning_effort` from model strings (e.g., `spark`, `opus`, `mini`).
+- Team runtime must **not** infer `model_reasoning_effort` from model-name substrings (e.g., `spark`, `high-capability`, `mini`).
 - Worker thinking level is applied **only when explicitly provided** (leader/user launch args or explicit config).
 - If no explicit thinking value is provided, runtime leaves `model_reasoning_effort` unset.
 
@@ -450,3 +457,11 @@ Two cleanup tools exist and must not be confused:
 - Worktree provisioning requires a git repository and can fail on branch/path collisions
 - send-keys interactions can be timing-sensitive under load
 - stale panes from prior runs can interfere until manually cleaned
+
+## 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.

package/skills/ultraqa/SKILL.md

@@ -9,6 +9,13 @@ description: QA cycling workflow - test, verify, fix, repeat until goal met
 
 ## Overview
 
+## GPT-5.4 Guidance Alignment
+
+- 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 QA cycle is grounded.
+- Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent.
+
 You are now in **ULTRAQA** mode - an autonomous QA cycling workflow that runs until your quality goal is met.
 
 **Cycle**: qa-tester → architect verification → fix → repeat
@@ -39,7 +46,7 @@ If no structured goal provided, interpret the argument as a custom goal.
    - `--custom`: Run appropriate command and check for pattern
    - `--interactive`: Use qa-tester for interactive CLI/service testing:
      ```
-     spawn_sub_agent(subagent_type="oh-my-codex:qa-tester", model="sonnet", prompt="TEST:
+     delegate(role="qa-tester", tier="STANDARD", task="TEST:
      Goal: [describe what to verify]
      Service: [how to start]
      Test cases: [specific scenarios to verify]")
@@ -51,7 +58,7 @@ If no structured goal provided, interpret the argument as a custom goal.
 
 3. **ARCHITECT DIAGNOSIS**: Spawn architect to analyze failure
    ```
-   spawn_sub_agent(subagent_type="oh-my-codex:architect", model="opus", prompt="DIAGNOSE FAILURE:
+   delegate(role="architect", tier="THOROUGH", task="DIAGNOSE FAILURE:
    Goal: [goal type]
    Output: [test/build output]
    Provide root cause and specific fix recommendations.")
@@ -59,7 +66,7 @@ If no structured goal provided, interpret the argument as a custom goal.
 
 4. **FIX ISSUES**: Apply architect's recommendations
    ```
-   spawn_sub_agent(subagent_type="oh-my-codex:executor", model="sonnet", prompt="FIX:
+   delegate(role="executor", tier="STANDARD", task="FIX:
    Issue: [architect diagnosis]
    Files: [affected files]
    Apply the fix precisely as recommended.")
@@ -105,6 +112,15 @@ Use `omx_state` MCP tools for UltraQA lifecycle state.
 - **For resume detection**:
   `state_read({mode: "ultraqa"})`
 
+
+## 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.
+
 ## Cancellation
 
 User can cancel with `/cancel` which clears the state file.

package/skills/ultrawork/SKILL.md

@@ -37,9 +37,9 @@ Sequential task execution wastes time when tasks are independent. Ultrawork enab
 1. **Read agent reference**: Load `docs/shared/agent-tiers.md` for tier selection
 2. **Classify tasks by independence**: Identify which tasks can run in parallel vs which have dependencies
 3. **Route to correct tiers**:
-   - Simple lookups/definitions: LOW tier (Haiku)
-   - Standard implementation: MEDIUM tier (Sonnet)
-   - Complex analysis/refactoring: HIGH tier (Opus)
+   - Simple lookups/definitions: LOW tier
+   - Standard implementation: STANDARD tier
+   - Complex analysis/refactoring: THOROUGH tier
 4. **Fire independent tasks simultaneously**: Launch all parallel-safe tasks at once
 5. **Run dependent tasks sequentially**: Wait for prerequisites before launching dependent work
 6. **Background long operations**: Builds, installs, and test suites use `run_in_background: true`
@@ -50,9 +50,9 @@ Sequential task execution wastes time when tasks are independent. Ultrawork enab
 </Steps>
 
 <Tool_Usage>
-- Use `spawn_sub_agent(subagent_type="oh-my-codex:executor-low", model="haiku", ...)` for simple changes
-- Use `spawn_sub_agent(subagent_type="oh-my-codex:executor", model="sonnet", ...)` for standard work
-- Use `spawn_sub_agent(subagent_type="oh-my-codex:executor-high", model="opus", ...)` for complex work
+- Use LOW-tier delegation for simple changes
+- Use STANDARD-tier delegation for standard work
+- Use THOROUGH-tier delegation for complex work
 - Use `run_in_background: true` for package installs, builds, and test suites
 - Use foreground execution for quick status checks and file operations
 </Tool_Usage>
@@ -74,9 +74,9 @@ Use `omx_state` MCP tools for ultrawork lifecycle state.
 <Good>
 Three independent tasks fired simultaneously:
 ```
-spawn_sub_agent(subagent_type="oh-my-codex:executor-low", model="haiku", prompt="Add missing type export for Config interface")
-spawn_sub_agent(subagent_type="oh-my-codex:executor", model="sonnet", prompt="Implement the /api/users endpoint with validation")
-spawn_sub_agent(subagent_type="oh-my-codex:executor", model="sonnet", prompt="Add integration tests for the auth middleware")
+delegate(role="executor", tier="LOW", task="Add missing type export for Config interface")
+delegate(role="executor", tier="STANDARD", task="Implement the /api/users endpoint with validation")
+delegate(role="test-engineer", tier="STANDARD", task="Add integration tests for the auth middleware")
 ```
 Why good: Independent tasks at appropriate tiers, all fired at once.
 </Good>
@@ -84,8 +84,8 @@ Why good: Independent tasks at appropriate tiers, all fired at once.
 <Good>
 Correct use of background execution:
 ```
-spawn_sub_agent(subagent_type="oh-my-codex:executor", model="sonnet", prompt="npm install && npm run build", run_in_background=true)
-spawn_sub_agent(subagent_type="oh-my-codex:executor-low", model="haiku", prompt="Update the README with new API endpoints")
+delegate(role="executor", tier="STANDARD", task="npm install && npm run build", run_in_background=true)
+delegate(role="writer", tier="LOW", task="Update the README with new API endpoints")
 ```
 Why good: Long build runs in background while short task runs in foreground.
 </Good>
@@ -93,9 +93,9 @@ Why good: Long build runs in background while short task runs in foreground.
 <Bad>
 Sequential execution of independent work:
 ```
-result1 = spawn_sub_agent(executor-low, "Add type export")  # wait...
-result2 = spawn_sub_agent(executor, "Implement endpoint")     # wait...
-result3 = spawn_sub_agent(executor, "Add tests")              # wait...
+result1 = delegate(executor, LOW, "Add type export")  # wait...
+result2 = delegate(executor, STANDARD, "Implement endpoint")     # wait...
+result3 = delegate(test-engineer, STANDARD, "Add tests")              # wait...
 ```
 Why bad: These tasks are independent. Running them sequentially wastes time.
 </Bad>
@@ -103,9 +103,9 @@ Why bad: These tasks are independent. Running them sequentially wastes time.
 <Bad>
 Wrong tier selection:
 ```
-spawn_sub_agent(subagent_type="oh-my-codex:executor-high", model="opus", prompt="Add a missing semicolon")
+delegate(role="executor", tier="THOROUGH", task="Add a missing semicolon")
 ```
-Why bad: Opus is expensive overkill for a trivial fix. Use executor-low with Haiku instead.
+Why bad: THOROUGH tier is expensive overkill for a trivial fix. Use LOW-tier execution instead.
 </Bad>
 </Examples>