oh-my-opencode 4.7.5 → 4.8.1

package/packages/omo-codex/plugin/skills/programming/references/go/concurrency.md

@@ -229,10 +229,10 @@ default:                    // already signaled, skip
 Highest level (preferred)
   channels (message passing — "share memory by communicating")
   errgroup / wait group
-  
+
   sync.RWMutex (many readers, occasional writer)
   sync.Mutex   (mutual exclusion)
-  
+
   atomic.Int64 / atomic.Pointer  (single-word lock-free)
 
 Lowest level (rare)

package/packages/omo-codex/plugin/skills/programming/references/python/async-anyio.md

@@ -27,9 +27,9 @@ async def main() -> None:
 anyio.run(main)
 ```
 
-**Signature**: `tg.start_soon(func, *args, name=None)`  
-- `func` must be a **coroutine function** (not a coroutine object).  
-- `name` is optional, for introspection/debugging.  
+**Signature**: `tg.start_soon(func, *args, name=None)`
+- `func` must be a **coroutine function** (not a coroutine object).
+- `name` is optional, for introspection/debugging.
 - No return value; exceptions propagate as `ExceptionGroup` on exit.
 
 ### `start` — wait for ready signal
@@ -74,9 +74,9 @@ async def main() -> None:
 anyio.run(main)
 ```
 
-**Signature**: `tg.create_task(coro, *, name=None, context=None) -> TaskHandle[T]`  
-- Returns a `TaskHandle` you can `await` for the result.  
-- If the task raises, awaiting raises `TaskFailed` (or `TaskCancelled`).  
+**Signature**: `tg.create_task(coro, *, name=None, context=None) -> TaskHandle[T]`
+- Returns a `TaskHandle` you can `await` for the result.
+- If the task raises, awaiting raises `TaskFailed` (or `TaskCancelled`).
 - This is the canonical replacement for `asyncio.gather` when you need results.
 
 ---

package/packages/omo-codex/plugin/skills/programming/references/python/pydantic-ai.md

@@ -11,7 +11,7 @@
 from pydantic_ai import Agent
 
 agent = Agent(
-    'openai:gpt-5.2',               # model (str | Model | None)
+    'openai:gpt-5.5',               # model (str | Model | None)
     output_type=MyOutputModel,       # structured output type; default=str
     instructions='You are a...',     # static or callable instructions
     system_prompt='Be concise.',     # static system prompt(s)
@@ -35,7 +35,7 @@ Format: `provider:model-name`. The framework infers the provider from the prefix
 
 | Provider prefix | Example |
 |---|---|
-| `openai:` | `'openai:gpt-5.2'`, `'openai:gpt-4o'` |
+| `openai:` | `'openai:gpt-5.5'`, `'openai:gpt-4o'` |
 | `anthropic:` | `'anthropic:claude-sonnet-4-6'`, `'anthropic:claude-opus-4-1'` |
 | `google-gla:` | `'google-gla:gemini-3-flash-preview'` |
 | `google-vertex:` | `'google-vertex:gemini-3-pro-preview'` |
@@ -43,9 +43,9 @@ Format: `provider:model-name`. The framework infers the provider from the prefix
 | `xai:` / `grok:` | `'xai:grok-3'`, `'grok:grok-3-fast'` |
 | `deepseek:` | `'deepseek:deepseek-chat'` |
 | `cohere:` | `'cohere:command-r-08-2024'` |
-| `gateway/...` | `'gateway/openai:gpt-5.2'` (PydanticAI Gateway) |
+| `gateway/...` | `'gateway/openai:gpt-5.5'` (PydanticAI Gateway) |
 
-Model can also be omitted at construction and passed per-run: `agent.run(prompt, model='openai:gpt-5.2')`.
+Model can also be omitted at construction and passed per-run: `agent.run(prompt, model='openai:gpt-5.5')`.
 
 ---
 
@@ -56,7 +56,7 @@ Model can also be omitted at construction and passed per-run: `agent.run(prompt,
 ```python
 from pydantic_ai import Agent, RunContext
 
-agent = Agent('openai:gpt-5.2', deps_type=str)
+agent = Agent('openai:gpt-5.5', deps_type=str)
 
 @agent.tool                    # default: receives RunContext as first arg
 async def greet(ctx: RunContext[str], name: str) -> str:
@@ -96,7 +96,7 @@ class City(BaseModel):
     country: str
     population_millions: float
 
-agent = Agent('openai:gpt-5.2', output_type=City)
+agent = Agent('openai:gpt-5.5', output_type=City)
 result = agent.run_sync('Tell me about Tokyo')
 print(result.output)            # City(name='Tokyo', country='Japan', ...)
 print(result.output.name)       # 'Tokyo'
@@ -150,7 +150,7 @@ class Deps:
     http_client: httpx.AsyncClient
 
 agent = Agent(
-    'openai:gpt-5.2',
+    'openai:gpt-5.5',
     deps_type=Deps,
 )
 
@@ -177,7 +177,7 @@ async def main():
 ```python
 from pydantic_ai import Agent, ModelRetry, UnexpectedModelBehavior, capture_run_messages
 
-agent = Agent('openai:gpt-5.2', retries=3)
+agent = Agent('openai:gpt-5.5', retries=3)
 
 @agent.tool_plain
 def calc_volume(size: int) -> int:
@@ -214,7 +214,7 @@ logfire.instrument_pydantic_ai()  # auto-traces all agent runs
 Alternatively, set `instrument=True` on the agent:
 
 ```python
-agent = Agent('openai:gpt-5.2', instrument=True)
+agent = Agent('openai:gpt-5.5', instrument=True)
 ```
 
 ---
@@ -231,7 +231,7 @@ class City(BaseModel):
     name: str
     country: str
 
-agent = Agent('openai:gpt-5.2', output_type=City)
+agent = Agent('openai:gpt-5.5', output_type=City)
 result = agent.run_sync('Tell me about Paris')
 print(result.output)   # City(name='Paris', country='France')
 ```
@@ -246,7 +246,7 @@ from pydantic_ai import Agent, RunContext
 class Deps:
     api_key: str
 
-agent = Agent('openai:gpt-5.2', deps_type=Deps)
+agent = Agent('openai:gpt-5.5', deps_type=Deps)
 
 @agent.tool
 async def get_secret(ctx: RunContext[Deps], code: str) -> str:
@@ -264,7 +264,7 @@ print(result.output)
 import anyio
 from pydantic_ai import Agent
 
-agent = Agent('openai:gpt-5.2')
+agent = Agent('openai:gpt-5.5')
 
 async def main() -> None:
     async with agent.run_stream('Write a haiku about Python') as response:

package/packages/omo-codex/plugin/skills/programming/references/typescript/backend-hono.md

@@ -1,7 +1,7 @@
 # Hono Backend Stack Reference (2026)
 
-> **Canonical stack**: `hono` + `hono-openapi` + `@scalar/hono-api-reference` + `@hono/swagger-ui`  
-> **Runtime**: Bun (TypeScript-first)  
+> **Canonical stack**: `hono` + `hono-openapi` + `@scalar/hono-api-reference` + `@hono/swagger-ui`
+> **Runtime**: Bun (TypeScript-first)
 > **Validator**: Zod v4 (Standard Schema compliant, zero extra deps for OpenAPI)
 
 ---
@@ -628,19 +628,19 @@ export function setupOpenAPI(app: Hono<any, any>, prefix = '/openapi') {
 
 ## 10. Common Pitfalls
 
-1. **Using `openAPISpecs` instead of `openAPIRouteHandler`**  
+1. **Using `openAPISpecs` instead of `openAPIRouteHandler`**
    Some docs (e.g. HONC) use `openAPISpecs` — this is **not** the current export name. The correct function is `openAPIRouteHandler` ([source](https://github.com/rhinobase/hono-openapi/blob/10f45a66ede3764b5e6065805fb60fd5df090466/src/index.ts#L1)).
 
-2. **Importing from `hono-openapi/zod`**  
+2. **Importing from `hono-openapi/zod`**
    There are **no subpath exports**. Always import from `hono-openapi` directly.
 
-3. **Forgetting `@hono/standard-validator`**  
+3. **Forgetting `@hono/standard-validator`**
    It is a peer dependency of `hono-openapi`. Modern package managers (npm ≥ 7, pnpm, bun) auto-install it. If you see validation errors, ensure it is present in `node_modules`.
 
-4. **Using `@hono/zod-openapi` (the OLD package)**  
+4. **Using `@hono/zod-openapi` (the OLD package)**
    The user explicitly wants `hono-openapi` (the newer, middleware-based, Standard Schema package). Do not confuse with `@hono/zod-openapi` which wraps the `Hono` class into `OpenAPIHono`.
 
-5. **Swagger UI `spec` option**  
+5. **Swagger UI `spec` option**
    `@hono/swagger-ui` does **not** accept a `spec` option to embed the document directly. It only accepts `url` (or `urls`) pointing to an external spec endpoint. If you need embedded specs, use Scalar's `content` option instead.
 
 ---

package/packages/omo-codex/plugin/skills/refactor/SKILL.md

@@ -9,15 +9,17 @@ This skill may include examples copied from the OpenCode harness. In Codex, do n
 
 | OpenCode example | Codex tool to use |
 | --- | --- |
-| `call_omo_agent(subagent_type="explore", ...)` | `spawn_agent(agent_type="explorer", task_name="...", message="...", fork_turns="none")` |
-| `call_omo_agent(subagent_type="librarian", ...)` | `spawn_agent(agent_type="librarian", task_name="...", message="...", fork_turns="none")` |
-| `task(subagent_type="plan", ...)` | `spawn_agent(agent_type="plan", task_name="...", message="...", fork_turns="none")` |
-| `task(subagent_type="oracle", ...)` for final verification | `spawn_agent(agent_type="codex-ultrawork-reviewer", task_name="...", message="...", fork_turns="none")` |
-| `task(category="...", ...)` for implementation or QA | `spawn_agent(agent_type="worker", task_name="...", message="...", fork_turns="none")` |
-| `background_output(task_id="...")` | `wait_agent(...)` to wait for subagent completion and mailbox updates |
+| `call_omo_agent(subagent_type="explore", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as an explorer. ...","fork_turns":"none"})` |
+| `call_omo_agent(subagent_type="librarian", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as a librarian. ...","fork_turns":"none"})` |
+| `task(subagent_type="plan", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as a planning agent. ...","fork_turns":"none"})` |
+| `task(subagent_type="oracle", ...)` for final verification | `spawn_agent({"task_name":"...","message":"TASK: act as a rigorous reviewer. ...","fork_turns":"none"})` |
+| `task(category="...", ...)` for implementation or QA | `spawn_agent({"task_name":"...","message":"TASK: act as an implementation or QA worker. ...","fork_turns":"none"})` |
+| `background_output(task_id="...")` | `wait_agent(...)` for mailbox signals; after a timeout, run one `list_agents` check for the named child if reassurance is needed |
 | `team_*(...)` | Use Codex native subagents plus `send_message`, `followup_task`, `wait_agent`, and `close_agent` |
 
-Codex full-history forks inherit the parent agent type, model, and reasoning effort, so role-specific spawns with `agent_type` must use a non-full-history fork mode such as `fork_turns="none"`. Include any required conversation context, files, diffs, constraints, and requested skill names directly in the spawned agent's `message`. If a code block below conflicts with this section, this section wins.
+Codex full-history forks inherit parent context, so role-specific behavior must be described in a self-contained `message` and usually should use a non-full-history fork mode such as `fork_turns="none"`. Include any required conversation context, files, diffs, constraints, and requested skill names directly in the spawned agent's `message`. If a code block below conflicts with this section, this section wins.
+
+For work likely to exceed one wait cycle, require the child to send `WORKING: <task> - <current phase>` before long passes and `BLOCKED: <reason>` only when progress stops. A `wait_agent` timeout only means no new mailbox update arrived. Treat a running child or latest `WORKING:` message as alive. Do not use `list_agents` as a polling loop. Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly `BLOCKED:`, or no longer running.
 
 export const REFACTOR_TEMPLATE = `# Intelligent Refactor Command
 
@@ -125,13 +127,13 @@ Fire ALL of these simultaneously using \`call_omo_agent\`:
 call_omo_agent(
   subagent_type="explore",
   run_in_background=true,
-  prompt="Find all occurrences and definitions of [TARGET]. 
+  prompt="Find all occurrences and definitions of [TARGET].
   Report: file paths, line numbers, usage patterns."
 )
 
 // Agent 2: Find related code
 call_omo_agent(
-  subagent_type="explore", 
+  subagent_type="explore",
   run_in_background=true,
   prompt="Find all code that imports, uses, or depends on [TARGET].
   Report: dependency chains, import graphs."
@@ -237,8 +239,8 @@ Based on Phase 1 results, build:
 
 ### Dependency Graph
 \`\`\`
-[TARGET] 
-├── imports from: 
+[TARGET]
+├── imports from:
 │   ├── module-a (types)
 │   └── module-b (utils)
 ├── imported by:

package/packages/omo-codex/plugin/skills/remove-ai-slops/SKILL.md

@@ -9,15 +9,17 @@ This skill may include examples copied from the OpenCode harness. In Codex, do n
 
 | OpenCode example | Codex tool to use |
 | --- | --- |
-| `call_omo_agent(subagent_type="explore", ...)` | `spawn_agent(agent_type="explorer", task_name="...", message="...", fork_turns="none")` |
-| `call_omo_agent(subagent_type="librarian", ...)` | `spawn_agent(agent_type="librarian", task_name="...", message="...", fork_turns="none")` |
-| `task(subagent_type="plan", ...)` | `spawn_agent(agent_type="plan", task_name="...", message="...", fork_turns="none")` |
-| `task(subagent_type="oracle", ...)` for final verification | `spawn_agent(agent_type="codex-ultrawork-reviewer", task_name="...", message="...", fork_turns="none")` |
-| `task(category="...", ...)` for implementation or QA | `spawn_agent(agent_type="worker", task_name="...", message="...", fork_turns="none")` |
-| `background_output(task_id="...")` | `wait_agent(...)` to wait for subagent completion and mailbox updates |
+| `call_omo_agent(subagent_type="explore", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as an explorer. ...","fork_turns":"none"})` |
+| `call_omo_agent(subagent_type="librarian", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as a librarian. ...","fork_turns":"none"})` |
+| `task(subagent_type="plan", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as a planning agent. ...","fork_turns":"none"})` |
+| `task(subagent_type="oracle", ...)` for final verification | `spawn_agent({"task_name":"...","message":"TASK: act as a rigorous reviewer. ...","fork_turns":"none"})` |
+| `task(category="...", ...)` for implementation or QA | `spawn_agent({"task_name":"...","message":"TASK: act as an implementation or QA worker. ...","fork_turns":"none"})` |
+| `background_output(task_id="...")` | `wait_agent(...)` for mailbox signals; after a timeout, run one `list_agents` check for the named child if reassurance is needed |
 | `team_*(...)` | Use Codex native subagents plus `send_message`, `followup_task`, `wait_agent`, and `close_agent` |
 
-Codex full-history forks inherit the parent agent type, model, and reasoning effort, so role-specific spawns with `agent_type` must use a non-full-history fork mode such as `fork_turns="none"`. Include any required conversation context, files, diffs, constraints, and requested skill names directly in the spawned agent's `message`. If a code block below conflicts with this section, this section wins.
+Codex full-history forks inherit parent context, so role-specific behavior must be described in a self-contained `message` and usually should use a non-full-history fork mode such as `fork_turns="none"`. Include any required conversation context, files, diffs, constraints, and requested skill names directly in the spawned agent's `message`. If a code block below conflicts with this section, this section wins.
+
+For work likely to exceed one wait cycle, require the child to send `WORKING: <task> - <current phase>` before long passes and `BLOCKED: <reason>` only when progress stops. A `wait_agent` timeout only means no new mailbox update arrived. Treat a running child or latest `WORKING:` message as alive. Do not use `list_agents` as a polling loop. Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly `BLOCKED:`, or no longer running.
 
 # Remove AI Slops Skill
 
@@ -209,7 +211,7 @@ For each skipped issue, give reason.
 )
 ```
 
-**Batch failure handling**: if a `deep` agent in a batch fails or times out, do NOT block the remaining 4 in that batch. Collect the successful results, mark the failed file for retry in a later batch (single retry max), and continue. If retry also fails, escalate that file under "Issues Found & Fixed" in the final report.
+**Batch failure handling**: a `wait_agent` timeout only means no new mailbox update arrived, not that a `deep` agent failed. For long passes, require each child to send `WORKING: <file> - <current phase>` and `BLOCKED: <reason>` only when it cannot progress. If you need reassurance after a timeout, run a single `list_agents` check for the named child; a running child or latest `WORKING:` message is alive. Mark a file for retry only when the child is completed without the deliverable, ack-only after followup, explicitly `BLOCKED:`, or no longer running. Do NOT block the remaining 4 in that batch; collect successful results and retry the failed file once later. If retry also fails, escalate that file under "Issues Found & Fixed" in the final report.
 
 ### Phase 5: Verify with quality gates + critical review
 

package/packages/omo-codex/plugin/skills/review-work/SKILL.md

@@ -8,40 +8,66 @@ This skill may include examples copied from the OpenCode harness. In Codex, do n
 
 | OpenCode example | Codex tool to use |
 | --- | --- |
-| `call_omo_agent(subagent_type="explore", ...)` | `spawn_agent(agent_type="explorer", task_name="...", message="...", fork_turns="none")` |
-| `call_omo_agent(subagent_type="librarian", ...)` | `spawn_agent(agent_type="librarian", task_name="...", message="...", fork_turns="none")` |
-| `task(subagent_type="plan", ...)` | `spawn_agent(agent_type="plan", task_name="...", message="...", fork_turns="none")` |
-| `task(subagent_type="oracle", ...)` for final verification | `spawn_agent(agent_type="codex-ultrawork-reviewer", task_name="...", message="...", fork_turns="none")` |
-| `task(category="...", ...)` for implementation or QA | `spawn_agent(agent_type="worker", task_name="...", message="...", fork_turns="none")` |
-| `background_output(task_id="...")` | `wait_agent(...)` to wait for subagent completion and mailbox updates |
+| `call_omo_agent(subagent_type="explore", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as an explorer. ...","fork_turns":"none"})` |
+| `call_omo_agent(subagent_type="librarian", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as a librarian. ...","fork_turns":"none"})` |
+| `task(subagent_type="plan", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as a planning agent. ...","fork_turns":"none"})` |
+| `task(subagent_type="oracle", ...)` for final verification | `spawn_agent({"task_name":"...","message":"TASK: act as a rigorous reviewer. ...","fork_turns":"none"})` |
+| `task(category="...", ...)` for implementation or QA | `spawn_agent({"task_name":"...","message":"TASK: act as an implementation or QA worker. ...","fork_turns":"none"})` |
+| `background_output(task_id="...")` | `wait_agent(...)` for mailbox signals; after a timeout, run one `list_agents` check for the named child if reassurance is needed |
 | `team_*(...)` | Use Codex native subagents plus `send_message`, `followup_task`, `wait_agent`, and `close_agent` |
 
-Codex full-history forks inherit the parent agent type, model, and reasoning effort, so role-specific spawns with `agent_type` must use a non-full-history fork mode such as `fork_turns="none"`. Include any required conversation context, files, diffs, constraints, and requested skill names directly in the spawned agent's `message`. If a code block below conflicts with this section, this section wins.
+Codex full-history forks inherit parent context, so role-specific behavior must be described in a self-contained `message` and usually should use a non-full-history fork mode such as `fork_turns="none"`. Include any required conversation context, files, diffs, constraints, and requested skill names directly in the spawned agent's `message`. If a code block below conflicts with this section, this section wins.
 
 ## Codex Subagent Reliability
 
 Every `spawn_agent` message must be self-contained. Start with
 `TASK: <imperative assignment>`, then name `DELIVERABLE`, `SCOPE`, and
 `VERIFY`. State that it is an executable assignment, not a context
-handoff. Role selection requires `agent_type`; `model` +
-`reasoning_effort` alone creates a default agent, not a reviewer or
-worker. Prefer `fork_turns: "none"` unless full history is truly
+handoff. Role or specialty instructions belong inside `message`; the
+Codex tool schema only accepts `task_name`, `message`, and `fork_turns`.
+Prefer `fork_turns: "none"` unless full history is truly
 required; paste only the review context that worker needs.
 
-Plan and reviewer agents may run for a long time; spawn them in the background, keep doing independent root work, and poll with short wait_agent cycles. Never use a single long blocking wait for them. While any child is active, keep the parent visibly alive with brief status updates that include active subagent count, agent names, last heartbeat, and whether the parent is waiting for mailbox updates.
-
-Use `wait_agent` for completion signals, but treat `wait_agent` as a
-mailbox signal, not proof of completion, content, or errors. After two
-waits with no substantive result, send one targeted followup:
-`TASK STILL ACTIVE: return <deliverable> or BLOCKED: <reason>`. If the
-child stays silent or ack-only, mark that review lane inconclusive, do
-not count it as PASS or approval, close if safe, and respawn a smaller
-`fork_turns: "none"` reviewer with the missing deliverable.
+Plan and reviewer agents may run for a long time; spawn them in the background, keep doing independent root work, and poll with short wait_agent cycles sized to the work. Never use a single long blocking wait for them, and never spin on tiny timeouts as a failure budget.
+
+Treat child status as a progress signal, not a timeout counter. For
+work likely to exceed one wait cycle, require the child to send
+`WORKING: <task> - <current phase>` before long reading, testing, or
+review passes, and `BLOCKED: <reason>` only when it cannot progress.
+While any child is active, keep the parent visibly alive with active
+subagent count, agent names, latest `WORKING:` phase, and whether the
+parent is waiting for mailbox updates. Track spawned agent names
+locally. Use `wait_agent` for mailbox signals, not proof of completion.
+A timeout only means no new mailbox update arrived; after a timeout,
+run a single `list_agents` check for the named child when you need
+reassurance. If it is running or its latest message is `WORKING:`,
+treat it as alive. Do not use `list_agents` as a polling loop or status
+feed; it can replay large payloads. Fallback only when the child is
+completed without the deliverable, ack-only after followup, explicitly
+`BLOCKED:`, or no longer running. Then mark that review lane
+`INCONCLUSIVE`, do not count it as PASS or approval, close if safe, and
+respawn a smaller `fork_turns: "none"` reviewer with the missing
+deliverable. Preserve completed lane results immediately. If the retry
+budget is exhausted, keep the lane `INCONCLUSIVE` and still emit a final
+aggregate result.
 
 # Review Work - 5-Agent Parallel Review Orchestrator
 
 Launch 5 specialized sub-agents in parallel to review completed implementation work from every angle. All 5 must pass for the review to pass. If even ONE fails, the review fails.
 
+When `review-work` is used as a final implementation, PR, or `$start-work`
+gate, it is blocking. A timeout, missing deliverable, ack-only response,
+explicit `BLOCKED:`, or inconclusive lane is not a pass. Treat that lane as
+failed, investigate the underlying uncertainty with the `debugging` skill when
+runtime behavior may be wrong, fix with evidence, and rerun the affected lane
+before claiming completion or handing off a PR.
+
+Review evidence must be safe to share. Redact or mask secrets and sensitive
+user data before including evidence in logs, PR bodies, or handoffs. Never
+include raw tokens, credentials, auth headers, cookies, API keys, env dumps,
+private logs, or PII; summarize with lengths, hashes, and short non-sensitive
+prefixes when identity is needed.
+
 The 5 agents cover complementary concerns - together they form a comprehensive review that no single reviewer could match:
 
 | # | Agent | Type | Role | Focus Level |
@@ -518,19 +544,27 @@ cycles. Do not treat a timeout, ack-only reply, or empty child result as
 a PASS.
 
 As each completes, collect via the Codex mapping above (`wait_agent`,
-then the child's substantive final result). Store each verdict:
+then the child's substantive final result). Preserve completed lane
+results immediately; never lose a PASS/FAIL because another lane is
+still running. Store each verdict independently:
 
 | Agent | Verdict | Notes |
 |-------|---------|-------|
-| 1. Goal Verification | pending | - |
-| 2. QA Execution | pending | - |
-| 3. Code Quality | pending | - |
-| 4. Security | pending | - |
-| 5. Context Mining | pending | - |
-
-Do NOT deliver the final report until ALL 5 have completed.
+| 1. Goal Verification | pending/PASS/FAIL/INCONCLUSIVE | - |
+| 2. QA Execution | pending/PASS/FAIL/INCONCLUSIVE | - |
+| 3. Code Quality | pending/PASS/FAIL/INCONCLUSIVE | - |
+| 4. Security | pending/PASS/FAIL/INCONCLUSIVE | - |
+| 5. Context Mining | pending/PASS/FAIL/INCONCLUSIVE | - |
+
+Do NOT deliver the final report until ALL 5 lanes have a terminal state:
+PASS, FAIL, or INCONCLUSIVE.
 If a lane remains silent after the reliability followup, record it as
 inconclusive and respawn a smaller reviewer/worker for that exact lane.
+If it still remains unfinished after that retry, close the still-running
+agent if safe, keep the lane INCONCLUSIVE, and emit the final aggregate
+review result with the incomplete lane named. Do not spin in repeated
+wait/followup cycles. Do not use `send_message` as an interrupt; queued
+followups are not cancellation.
 
 ---
 
@@ -540,6 +574,7 @@ inconclusive and respawn a smaller reviewer/worker for that exact lane.
 
 ALL 5 agents returned PASS → **REVIEW PASSED**
 ANY agent returned FAIL → **REVIEW FAILED - criteria not met**
+ANY lane is INCONCLUSIVE and none failed → **REVIEW INCONCLUSIVE - not approved**
 
 </verdict_logic>
 
@@ -548,15 +583,15 @@ Compile the final report in this format:
 ```markdown
 # Review Work - Final Report
 
-## Overall Verdict: PASSED / FAILED
+## Overall Verdict: PASSED / FAILED / INCONCLUSIVE
 
 | # | Review Area | Agent Type | Verdict | Confidence |
 |---|------------|------------|---------|------------|
-| 1 | Goal & Constraint Verification | Oracle | PASS/FAIL | HIGH/MED/LOW |
-| 2 | QA Execution | unspecified-high | PASS/FAIL | HIGH/MED/LOW |
-| 3 | Code Quality | Oracle | PASS/FAIL | HIGH/MED/LOW |
-| 4 | Security (supplementary) | Oracle | PASS/FAIL | Severity |
-| 5 | Context Mining | unspecified-high | PASS/FAIL | HIGH/MED/LOW |
+| 1 | Goal & Constraint Verification | Oracle | PASS/FAIL/INCONCLUSIVE | HIGH/MED/LOW |
+| 2 | QA Execution | unspecified-high | PASS/FAIL/INCONCLUSIVE | HIGH/MED/LOW |
+| 3 | Code Quality | Oracle | PASS/FAIL/INCONCLUSIVE | HIGH/MED/LOW |
+| 4 | Security (supplementary) | Oracle | PASS/FAIL/INCONCLUSIVE | Severity |
+| 5 | Context Mining | unspecified-high | PASS/FAIL/INCONCLUSIVE | HIGH/MED/LOW |
 
 ## Blocking Issues
 [Aggregated from all agents - deduplicated, prioritized]

package/packages/omo-codex/plugin/skills/start-work/SKILL.md

@@ -9,12 +9,12 @@ This skill ports the OpenCode `/start-work` flow onto Codex. Any OpenCode-only t
 
 | OpenCode example | Codex tool to use |
 | --- | --- |
-| `task(subagent_type="explore", ...)` | `spawn_agent(agent_type="explorer", task_name="...", message="...", fork_turns="none")` |
-| `task(subagent_type="librarian", ...)` | `spawn_agent(agent_type="librarian", task_name="...", message="...", fork_turns="none")` |
-| `task(subagent_type="plan", ...)` | `spawn_agent(agent_type="plan", task_name="...", message="...", fork_turns="none")` |
-| `task(subagent_type="oracle", ...)` for final verification | `spawn_agent(agent_type="codex-ultrawork-reviewer", task_name="...", message="...", fork_turns="none")` |
-| `task(category="...", ...)` for implementation or QA | `spawn_agent(agent_type="worker", task_name="...", message="...", fork_turns="none")` |
-| `background_output(task_id="...")` | `wait_agent(...)` |
+| `task(subagent_type="explore", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as an explorer. ...","fork_turns":"none"})` |
+| `task(subagent_type="librarian", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as a librarian. ...","fork_turns":"none"})` |
+| `task(subagent_type="plan", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as a planning agent. ...","fork_turns":"none"})` |
+| `task(subagent_type="oracle", ...)` for final verification | `spawn_agent({"task_name":"...","message":"TASK: act as a rigorous reviewer. ...","fork_turns":"none"})` |
+| `task(category="...", ...)` for implementation or QA | `spawn_agent({"task_name":"...","message":"TASK: act as an implementation or QA worker. ...","fork_turns":"none"})` |
+| `background_output(task_id="...")` | `wait_agent(...)` for mailbox signals; after a timeout, run one `list_agents` check for the named child if reassurance is needed |
 | `dispatchInternalPrompt(...)` | the `Stop` hook emits `{"decision":"block","reason":"<prompt>"}` automatically; see Continuation |
 | `team_*(...)` | `spawn_agent` + `send_message` + `followup_task` + `wait_agent` + `close_agent` |
 
@@ -25,20 +25,31 @@ When translating `load_skills=[...]`, name the skills inside the spawned agent's
 Every `spawn_agent` message must be self-contained. Start with
 `TASK: <imperative assignment>`, then name `DELIVERABLE`, `SCOPE`, and
 `VERIFY`. State that it is an executable assignment, not a context
-handoff. Role selection requires `agent_type`; `model` +
-`reasoning_effort` alone creates a default agent, not a reviewer or
-worker. Prefer `fork_turns: "none"` unless full history is truly
+handoff. Role or specialty instructions belong inside `message`; the
+Codex tool schema only accepts `task_name`, `message`, and `fork_turns`.
+Prefer `fork_turns: "none"` unless full history is truly
 required; paste only the context the child needs.
 
-Plan and reviewer agents may run for a long time; spawn them in the background, keep doing independent root work, and poll with short wait_agent cycles. Never use a single long blocking wait for them. While any child is active, keep the parent visibly alive with brief status updates that include active subagent count, agent names, last heartbeat, and whether the parent is waiting for mailbox updates.
-
-Use `wait_agent` for completion signals, but treat `wait_agent` as a
-mailbox signal, not proof of completion, content, or errors. After two
-waits with no substantive result, send one targeted followup:
-`TASK STILL ACTIVE: return <deliverable> or BLOCKED: <reason>`. If the
-child stays silent or ack-only, record the result as inconclusive, do
-not count it as pass/review approval, close if safe, and respawn a
-smaller `fork_turns: "none"` task with the missing deliverable.
+Plan and reviewer agents may run for a long time; spawn them in the background, keep doing independent root work, and poll with short wait_agent cycles sized to the work. Never use a single long blocking wait for them, and never spin on tiny timeouts as a failure budget.
+
+Treat child status as a progress signal, not a timeout counter. For
+work likely to exceed one wait cycle, require the child to send
+`WORKING: <task> - <current phase>` before long reading, testing, or
+review passes, and `BLOCKED: <reason>` only when it cannot progress.
+While any child is active, keep the parent visibly alive with active
+subagent count, agent names, latest `WORKING:` phase, and whether the
+parent is waiting for mailbox updates. Track spawned agent names
+locally. Use `wait_agent` for mailbox signals, not proof of completion.
+A timeout only means no new mailbox update arrived; after a timeout,
+run a single `list_agents` check for the named child when you need
+reassurance. If it is running or its latest message is `WORKING:`,
+treat it as alive. Do not use `list_agents` as a polling loop or status
+feed; it can replay large payloads. Fallback only when the child is
+completed without the deliverable, ack-only after followup, explicitly
+`BLOCKED:`, or no longer running. Then record the result as
+inconclusive, do not count it as pass/review approval, close if safe,
+and respawn a smaller `fork_turns: "none"` task with the missing
+deliverable.
 
 # start-work
 
@@ -60,7 +71,21 @@ $start-work [plan-name] [--worktree <absolute-path>]
 3. If `plan-name` was provided, select the matching plan.
 4. If exactly one active or paused Boulder work exists for this session, resume it.
 5. If no active work exists and exactly one plan exists, select it.
-6. If multiple plans remain possible, ask one focused selection question.
+6. If no active work exists and there is no selectable plan, enter **No-plan bootstrap**.
+7. If multiple plans remain possible, ask one focused selection question.
+
+### No-plan bootstrap
+
+When the user explicitly said `start work` / `$start-work` and no selectable plan exists, treat that phrase as approval to create the plan before execution. Do not stall on a missing plan and do not ask for generic approval again.
+
+If no selectable plan exists, bootstrap `ulw-plan` before execution.
+Execution requires an approved plan before implementation; bootstrap mode creates that approved plan from the user's `start work` request instead of skipping planning.
+
+1. Invoke the `ulw-plan` skill from the current request and require its dynamic adversarial workflow: collect, verify, design, adversarial plan-review, synthesize.
+2. The generated Prometheus plan must be saved under `.omo/plans/<slug>.md` before implementation or Boulder state writes that point at plan work.
+3. Use maximum safe parallelism in the generated plan: independent files/tasks fan out; same-file writes, shared state, and named dependencies serialize.
+4. Preserve safety boundaries. Ask one focused question only when the objective is missing, destructive, or has a safety/product ambiguity that repository exploration cannot resolve.
+5. After the plan exists, continue directly to Phase 2. The user's `start work` request is the bootstrap approval to create the plan and begin execution.
 
 ## Phase 2: Create or update Boulder state
 
@@ -121,6 +146,38 @@ For each checkbox, complete all five gates before marking it done:
 
 Append evidence to `.omo/start-work/ledger.jsonl` using one JSON object per line. Include at least `event`, `plan`, `task`, `session_id`, `commands`, `artifact`, `adversarial_classes`, and `cleanup` fields. `adversarial_classes` lists each probed class with its observable result and each ruled-out class with a one-line reason.
 
+### Sisyphus-style completion contract
+
+A worker done claim is never final. Each implementation sub-task returns a `DoneClaim`, then a different context runs `AdversarialVerify`, then the verifier probes or reproduces the claim, then failures loop back to the executor, and only a confirmed verifier verdict becomes `FullyDone`.
+
+```json
+{
+  "DoneClaim": {
+    "task": "<task id/title>",
+    "changed_files": ["path"],
+    "tests": ["exact command + result"],
+    "manual_qa": ["artifact path"],
+    "cleanup": ["receipt"],
+    "risks": ["known risk or none"]
+  },
+  "AdversarialVerify": {
+    "verdict": "confirmed | false-positive | needs-fix | needs-human-review",
+    "evidence": ["file path, command, log, artifact, or explicit not inspected"],
+    "repro": "exact command or manual steps when available",
+    "confidence": 0.0
+  }
+}
+```
+
+Rules:
+- `confirmed` is the only pass verdict. `false-positive`, `needs-fix`, and `needs-human-review` all block checkbox completion.
+- The verifier must be independent from the executor: use `codex-ultrawork-reviewer`, a scoped `worker` reviewer, or root only when root did not implement or materially rewrite that task.
+- A worker done claim must be independently verified before it can become checkbox completion.
+- On any non-confirmed verdict, append the feedback to the ledger, reset the checkbox work to in-progress, and re-dispatch the executor with the exact failure.
+- The verifier must probe the applicable adversarial keys, including `stale_state`, `dirty_worktree`, and `misleading_success_output`, before allowing `FullyDone`.
+- In prose evidence, name the same risks as stale state, dirty worktree, and misleading success output so reviewers can search for both key and human forms.
+- Tests passing, green builds, or a worker DoneClaim without independent verification are not enough to mark a checkbox complete.
+
 ## Phase 5: Mark progress
 
 Only after verification passes:
@@ -135,9 +192,15 @@ Only after verification passes:
 When all top-level checkboxes in `## TODOs` and `## Final Verification Wave` are complete:
 
 1. Run the plan's final verification commands.
-2. If worktree mode was used, sync `.omo/` state back to the main repo, merge or hand off exactly as requested, and remove the worktree only after successful merge or explicit handoff.
-3. Remove or mark the Boulder work as completed.
-4. Print an `ORCHESTRATION COMPLETE` block with the plan path, verification commands, artifacts, and cleanup receipts.
+2. Complete the **Global Review and Debugging Gate** before any completion claim, PR handoff, or branch handoff:
+   - Invoke the `review-work` skill with the final diff, changed files, user goal, constraints, run command, and verification evidence. All five review lanes must return PASS. A timeout, missing deliverable, ack-only child, `BLOCKED:`, or inconclusive lane is a gate failure, not approval.
+   - Run a debugging-oriented runtime audit even when the review passes: name at least three plausible failure hypotheses for the changed surface, run the distinguishing checks against the actual artifact, and append the ruled-out or confirmed result to `.omo/start-work/ledger.jsonl`.
+   - If any review lane or debugging hypothesis fails, invoke the `debugging` skill, confirm root cause with runtime evidence, add the minimal failing test or reproduction, fix it, rerun the affected verification, then rerun the Global Review and Debugging Gate.
+   - Evidence hygiene is mandatory: redact or mask secrets and sensitive user data before writing `.omo/start-work/ledger.jsonl`, a PR body, or a handoff. Never include raw tokens, credentials, auth headers, cookies, API keys, env dumps, private logs, or PII; use concise summaries, lengths, hashes, or short non-sensitive prefixes instead.
+   - If the work includes creating, updating, or handing off a PR, refresh `git status` and the PR/branch state after the gate, and include only redacted review/debugging evidence in the PR body or handoff.
+3. If worktree mode was used, sync `.omo/` state back to the main repo, merge or hand off exactly as requested, and remove the worktree only after successful merge or explicit handoff.
+4. Remove or mark the Boulder work as completed.
+5. Print an `ORCHESTRATION COMPLETE` block with the plan path, verification commands, Global Review and Debugging Gate verdict, artifacts, and cleanup receipts.
 
 ## Hard rules
 
@@ -145,5 +208,6 @@ When all top-level checkboxes in `## TODOs` and `## Final Verification Wave` are
 - No `--dry-run` as completion evidence.
 - No tests-only completion claim. A Manual-QA artifact is required.
 - No completion claim while an applicable ultraqa adversarial class was never probed. Each applicable class needs a captured observable result; each skipped class needs a one-line not-applicable reason in the ledger.
+- No `ORCHESTRATION COMPLETE`, final response, PR creation, or PR handoff before the Global Review and Debugging Gate passes with recorded evidence.
 - No unprefixed session ids in Boulder state. Codex sessions are always `codex:<session_id>`.
 - No stale-memory execution. The plan and ledger are the durable source of truth.