oh-my-opencode 4.7.4 → 4.8.0

package/packages/shared-skills/skills/lcx-report-bug/SKILL.md

@@ -1,21 +1,25 @@
 ---
 name: lcx-report-bug
-description: "Create a high-signal LazyCodex bug report for code-yeongyu/lazycodex. Use this whenever the user asks to report, file, open, or triage a LazyCodex, lazycodex-ai, omo-codex, or Codex plugin bug, especially when they need root cause, reproduction steps, expected fix guidance, and a GitHub issue."
+description: "Create a high-signal bug issue or PR in the repo that owns the defect. Use this whenever the user asks to report, file, open, or triage a LazyCodex, lazycodex-ai, omo-codex, Codex plugin, or upstream Codex CLI bug, especially when they need source-backed root cause, reproduction steps, fix guidance, and GitHub routing."
 metadata:
-  short-description: Report LazyCodex bugs with debugging evidence
+  short-description: Route LazyCodex or Codex bugs with source evidence
 ---
 
 # lcx-report-bug
 
-You are a LazyCodex bug reporter. Produce one useful GitHub issue in English for `code-yeongyu/lazycodex`, backed by runtime evidence rather than guesses.
+You are a LazyCodex bug router and reporter. Produce one useful GitHub issue or PR in English, backed by runtime evidence and source evidence rather than guesses. Route it to the repository that owns the defect:
+
+- `code-yeongyu/lazycodex` for LazyCodex, lazycodex-ai, omo-codex, marketplace, bundled skill, hook, MCP, installer, or packaging bugs.
+- `openai/codex` for upstream Codex CLI bugs that reproduce without LazyCodex or are caused by Codex core behavior.
 
 Use GPT-5.5 style: outcome first, concise, evidence-bound. Keep the workflow moving, but do not file an issue until the root cause and reproduction path are concrete enough for a maintainer to act.
 
 ## Goal
 
-Create or prepare a GitHub issue that includes:
+Create or prepare a GitHub issue or PR that includes:
 
 - clear title
+- target repository decision
 - environment
 - reproducible steps
 - expected behavior
@@ -23,24 +27,66 @@ Create or prepare a GitHub issue that includes:
 - confirmed or strongly evidenced root cause
 - fix approach, including files or components likely involved
 - verification plan
+- `lazycodex-generated` label and footer tag
 
 ## Required Workflow
 
 1. Read the user's bug report and identify the affected surface: LazyCodex installer, Codex plugin, skill, hook, MCP, CLI alias, GitHub marketplace sync, or web/docs.
 2. Invoke `$omo:debugging` for the investigation. If Codex exposes only unqualified skill names in the current session, invoke `$debugging` and state that it is the OMO debugging skill.
-3. Follow the debugging skill far enough to gather runtime evidence:
+3. Materialize upstream Codex source under `/tmp` before deciding ownership:
+
+```bash
+CODEX_SRC="/tmp/openai-codex-source"
+if [ ! -d "$CODEX_SRC/.git" ]; then
+  gh repo clone openai/codex "$CODEX_SRC" -- --depth=1
+else
+  git -C "$CODEX_SRC" fetch --depth=1 origin
+fi
+```
+
+If `gh` is unavailable, use `git clone --depth=1 https://github.com/openai/codex "$CODEX_SRC"`.
+4. Follow the debugging skill far enough to gather runtime evidence:
    - form at least three plausible hypotheses
    - run the smallest reproduction that exercises the real surface
    - confirm the root cause by observing the failing state
    - identify the minimal fix path or maintainer action
-4. Search for an existing issue before creating a new one:
+5. Compare local LazyCodex evidence with `/tmp/openai-codex-source` before choosing the target repo. Cite exact files, commands, logs, or source paths that support the routing decision.
+6. Choose the target repo:
+   - Use `code-yeongyu/lazycodex` when the bug is in LazyCodex integration, distribution, bundled plugin code, skills, hooks, MCP wiring, installer behavior, aliases, marketplace sync, docs, or any behavior that disappears in clean upstream Codex.
+   - Use `openai/codex` when the bug reproduces in clean upstream Codex without LazyCodex, or the failing behavior comes from Codex CLI core, plugin API contracts, sandboxing, approvals, config loading, or built-in tool behavior.
+   - If ownership remains ambiguous after evidence gathering, do not guess. Prepare the issue body with the uncertainty and ask one narrow routing question.
+7. Search for an existing issue in the selected repo before creating a new one. Search the other repo too when the ownership boundary is close:
 
 ```bash
-gh issue list --repo code-yeongyu/lazycodex --search "<short error or symptom>" --state open
+TARGET_REPO="code-yeongyu/lazycodex" # or openai/codex
+gh issue list --repo "$TARGET_REPO" --search "<short error or symptom>" --state open
 ```
 
-5. If a matching open issue exists, add a comment with the new evidence instead of creating a duplicate.
-6. If no matching issue exists, create the issue with `gh`.
+8. If a matching open issue exists, add a comment with the new evidence instead of creating a duplicate.
+9. Ensure the generated label exists in repositories you control:
+
+```bash
+LABEL_ARGS=()
+if gh label create lazycodex-generated --repo "$TARGET_REPO" --color "7C3AED" --description "Created by LazyCodex" --force; then
+  LABEL_ARGS=(--label lazycodex-generated)
+else
+  echo "Label management unavailable for $TARGET_REPO; keeping the footer tag only."
+fi
+```
+
+If the selected repo is `openai/codex` and label management is not available, still include the footer tag in the body and continue without claiming label creation succeeded.
+10. If no matching issue exists, create the issue with `gh` and apply the `lazycodex-generated` label.
+11. Create a PR only when the user asked for a PR, the fix is already implemented on a branch, or the smallest correct fix can be safely made in the selected repo. Apply the `lazycodex-generated` label to every PR created by this skill. Otherwise create an issue with fix guidance.
+
+## Required Label And Footer
+
+Every issue body, evidence comment, and PR body created by this skill must use the GitHub label `lazycodex-generated` when the artifact supports labels. It must also end with this footer. Do not put content after it.
+
+```markdown
+---
+This issue or PR was generated by LazyCodex.
+Tag: lazycodex-generated
+```
 
 ## Issue Body Template
 
@@ -57,6 +103,12 @@ Write the issue body in English and keep it direct:
 - Install method:
 - Relevant config:
 
+## Repository Decision
+- Target repository:
+- Why this belongs there:
+- LazyCodex evidence:
+- Upstream Codex source evidence from `/tmp/openai-codex-source`:
+
 ## Reproduction
 1. [Exact command or UI action]
 2. [Exact next step]
@@ -81,6 +133,40 @@ Write the issue body in English and keep it direct:
 - [Check that reproduces the original failure]
 - [Check that proves the fix]
 - [Regression check for adjacent LazyCodex/Codex plugin behavior]
+
+---
+This issue or PR was generated by LazyCodex.
+Tag: lazycodex-generated
+```
+
+## PR Body Template
+
+Use this when a PR is the right artifact:
+
+```markdown
+## Summary
+[One or two sentences describing the fix and the user-visible failure it resolves.]
+
+## Repository Decision
+- Target repository:
+- Why this belongs there:
+- LazyCodex evidence:
+- Upstream Codex source evidence from `/tmp/openai-codex-source`:
+
+## Root Cause
+[Confirmed cause. Cite runtime evidence and source paths.]
+
+## Fix
+[What changed and why.]
+
+## Verification
+- [Check that reproduced the original failure before the fix]
+- [Check that passes after the fix]
+- [Regression check for adjacent behavior]
+
+---
+This issue or PR was generated by LazyCodex.
+Tag: lazycodex-generated
 ```
 
 ## GitHub Creation Path
@@ -90,18 +176,35 @@ Prefer `gh`:
 ```bash
 ISSUE_BODY="/tmp/lcx-report-bug-$(date +%Y%m%d-%H%M%S).md"
 $EDITOR "$ISSUE_BODY"
-gh issue create --repo code-yeongyu/lazycodex --title "<clear title>" --body-file "$ISSUE_BODY"
+gh issue create --repo "$TARGET_REPO" --title "<clear title>" "${LABEL_ARGS[@]}" --body-file "$ISSUE_BODY"
 ```
 
 If `$EDITOR` is not usable, write the file with the available file-editing tool, then run the same `gh issue create` command.
 
-After creating or commenting, return the issue URL and a short summary of the evidence used.
+For an existing issue:
+
+```bash
+COMMENT_BODY="/tmp/lcx-report-bug-comment-$(date +%Y%m%d-%H%M%S).md"
+gh issue comment "<issue-number>" --repo "$TARGET_REPO" --body-file "$COMMENT_BODY"
+if [ "${#LABEL_ARGS[@]}" -gt 0 ]; then
+  gh issue edit "<issue-number>" --repo "$TARGET_REPO" --add-label lazycodex-generated
+fi
+```
+
+For a PR from a branch pushed to the selected repo or fork:
+
+```bash
+PR_BODY="/tmp/lcx-report-bug-pr-$(date +%Y%m%d-%H%M%S).md"
+gh pr create --repo "$TARGET_REPO" --title "<clear title>" "${LABEL_ARGS[@]}" --body-file "$PR_BODY"
+```
+
+After creating or commenting, return the issue or PR URL and a short summary of the evidence used.
 
 ## Browser use fallback
 
 If `gh` is unavailable, unauthenticated, or blocked, use Browser Use against the real GitHub page:
 
-1. Open `https://github.com/code-yeongyu/lazycodex/issues/new`.
+1. Open the new issue page for the selected repo: `https://github.com/code-yeongyu/lazycodex/issues/new` or `https://github.com/openai/codex/issues/new`.
 2. Fill the title and body from the template.
 3. Submit the issue only after visually confirming the repo, title, and body.
 4. Capture the resulting issue URL.
@@ -110,7 +213,7 @@ If `gh` is unavailable, unauthenticated, or blocked, use Browser Use against the
 
 If Browser Use is unavailable but a desktop browser is open and authenticated, use Computer Use:
 
-1. Navigate to `https://github.com/code-yeongyu/lazycodex/issues/new`.
+1. Navigate to the new issue page for the selected repo: `https://github.com/code-yeongyu/lazycodex/issues/new` or `https://github.com/openai/codex/issues/new`.
 2. Fill the title and body.
 3. Verify the target repository and final text before submission.
 4. Submit and capture the issue URL.
@@ -124,4 +227,6 @@ Do not file:
 - a vague issue without reproduction steps
 - an issue that claims a root cause not supported by runtime evidence
 - a duplicate when commenting on an existing issue is enough
-- a fix PR unless the user separately asks for one
+- an upstream Codex issue without checking `/tmp/openai-codex-source`
+- a LazyCodex issue when the bug is proven to reproduce in clean upstream Codex
+- a fix PR without a concrete branch, implemented fix, and verification result

package/packages/shared-skills/skills/lcx-report-bug/agents/openai.yaml

@@ -1,9 +1,11 @@
 interface:
   display_name: "lcx-report-bug (omo)"
-  short_description: "Report LazyCodex bugs with debugging evidence"
+  short_description: "Route LazyCodex or Codex bugs with source evidence"
   search_terms:
     - "lcx-report-bug"
     - "lazycodex bug"
     - "lazycodex issue"
     - "omo-codex bug"
-  default_prompt: "Use $lcx-report-bug to investigate this LazyCodex bug and file a clear issue with reproduction, root cause, and fix guidance."
+    - "openai codex bug"
+    - "codex upstream issue"
+  default_prompt: "Use $lcx-report-bug to investigate this LazyCodex or Codex bug, compare LazyCodex evidence with /tmp openai/codex source, choose the correct GitHub repo, and file an issue or PR with reproduction, root cause, fix guidance, and the lazycodex-generated label and footer."

package/packages/shared-skills/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/shared-skills/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/shared-skills/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/shared-skills/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/shared-skills/skills/refactor/SKILL.md

@@ -109,13 +109,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."
@@ -221,8 +221,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/shared-skills/skills/remove-ai-slops/SKILL.md

@@ -193,7 +193,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/shared-skills/skills/review-work/SKILL.md

@@ -8,35 +8,48 @@ 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
 
@@ -518,19 +531,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 +561,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 +570,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]