oh-my-opencode 4.10.0 → 4.11.1

package/packages/shared-skills/skills/programming/references/code-smells.md

@@ -0,0 +1,390 @@
+# Code Smells — Full Reference
+
+When any of these smells is detected, **STOP and re-examine your design.** A code smell is not a syntax error — it is a signal that the current structure deserves a second look. The correct response is to assess whether `/refactor` is warranted, fix the smell, or document a SPECIFIC justification for carrying it. "It's fine" is not a justification.
+
+---
+
+## Smell 1 — File exceeds 250 pure LOC
+
+### Why 250
+
+At 250 pure LOC a file still fits in one screen on a 32-inch monitor with a 14pt font. A reviewer can hold the whole thing in working memory and spot a cross-cutting bug. At 500 LOC they cannot. At 1000 LOC they stop trying. The number is the cognitive ceiling of a single human reviewer who has not memorized the file.
+
+A file past this line is telling you:
+
+- The module is doing more than one thing.
+- Multiple cohesive units got merged "to save a file."
+- Re-exports, barrels, and orchestrators got fused into pure-logic units.
+- Every future reader pays a tax to find what they need.
+
+### Measuring pure LOC
+
+```bash
+# Quick (line-comment + blank exclusion):
+awk '!/^[[:space:]]*$/ && !/^[[:space:]]*(\/\/|#|--)/' <file> | wc -l
+
+# Authoritative (handles block comments correctly):
+cloc --by-file <file>   # the "code" column is the number
+```
+
+### Required behavior when detected
+
+**Creating a file that will exceed 250 pure LOC.** Split it before the first commit. Carve by responsibility, one cohesive unit per file. Use a barrel (`__init__.py`, `mod.rs`, `index.ts`) for re-exports ONLY — never for logic.
+
+**Editing a file that already exceeds 250 pure LOC and your edit adds lines.** Refactor the unit you are touching into its own file BEFORE adding the new lines. The split is part of THIS task, not a follow-up someone will never do.
+
+**Reading a file that exceeds 250 pure LOC while implementing a feature.** Surface the smell in your reply, propose a concrete split, and ask the user whether to split now or carry the smell.
+
+### Forbidden escapes
+
+- Counting comments and blank lines toward the budget. **Pure LOC means code lines.**
+- Splitting by token count (`foo_1.py`, `module_part_A.rs`, `service-2.ts`). Split by what each file DOES.
+- Catch-all dump files: `utils.py`, `helpers.ts`, `lib.rs` (as a logic dump), `common.py`, `shared.ts`.
+- "It's generated, so it's fine." Only true if the file lives in `dist/`, `target/`, `__generated__/`.
+- "It's a test file with many cases." Split by SUT or by behavior cluster.
+- "230 pure LOC, close enough." A 230-LOC file about to grow is already at the limit. Split now.
+
+### Acceptable exceptions (rare, require justification)
+
+A file may legitimately exceed 250 pure LOC if **and only if** it is:
+
+- A truly indivisible single-responsibility unit (e.g., a generated parser table, a state machine whose states share a single closure). Mark with `// allow: SIZE_OK — <reason>`.
+- A pure data table (translation strings, error code lookup, brand color palette).
+
+`// allow: SIZE_OK` without a justifying comment is itself slop.
+
+### Concrete split examples
+
+#### Python — BEFORE (`user_service.py`, 412 pure LOC)
+
+```python
+# user_service.py — DOES TOO MUCH
+class UserRepository: ...        # 90 LOC of SQLAlchemy
+class UserValidator: ...         # 60 LOC of Pydantic + business rules
+class PasswordHasher: ...        # 40 LOC of bcrypt wrapper
+class EmailSender: ...           # 50 LOC of httpx2 client
+class UserService: ...           # 130 LOC orchestrating the four above
+def _build_query(...): ...       # 25 LOC helper
+def _format_email(...): ...      # 17 LOC helper
+```
+
+#### Python — AFTER (split by responsibility)
+
+```
+src/myapp/users/
+├── __init__.py              # barrel: re-exports UserService only (5 LOC)
+├── repository.py            # UserRepository                 (~95 LOC)
+├── validator.py             # UserValidator                  (~65 LOC)
+├── password.py              # PasswordHasher                 (~45 LOC)
+├── notifier.py              # EmailSender (renamed — the role, not the verb)
+├── service.py               # UserService (orchestrator)     (~135 LOC)
+└── _queries.py              # _build_query (private)         (~30 LOC)
+```
+
+#### Rust — BEFORE (`auth.rs`, 380 pure LOC)
+
+```rust
+// auth.rs — DOES TOO MUCH
+pub struct Session { ... }                      // 40 LOC
+impl Session { ... }                            // 90 LOC of methods
+pub struct TokenIssuer { ... }                  // 30 LOC
+impl TokenIssuer { ... }                        // 70 LOC
+pub struct RateLimiter { ... }                  // 50 LOC
+impl RateLimiter { ... }                        // 70 LOC
+fn parse_authorization_header(...) { ... }      // 30 LOC
+```
+
+#### Rust — AFTER
+
+```
+src/auth/
+├── mod.rs              # re-exports Session, TokenIssuer, RateLimiter (8 LOC)
+├── session.rs          # Session + impl                         (~130 LOC)
+├── token.rs            # TokenIssuer + impl                     (~100 LOC)
+├── rate_limit.rs       # RateLimiter + impl                     (~120 LOC)
+└── header.rs           # parse_authorization_header             (~35 LOC)
+```
+
+#### TypeScript — BEFORE (`api/orders.ts`, 510 pure LOC)
+
+```typescript
+// api/orders.ts — DOES TOO MUCH
+export const OrderSchema = z.object({ ... })          // 30 LOC
+type Order = z.infer<typeof OrderSchema>
+export class OrderRepository { ... }                  // 110 LOC
+export class PricingEngine { ... }                    // 130 LOC
+export class TaxCalculator { ... }                    // 90 LOC
+export class OrderService { ... }                     // 150 LOC
+```
+
+#### TypeScript — AFTER
+
+```
+src/orders/
+├── index.ts                    # barrel (6 LOC)
+├── schema.ts                   # OrderSchema + Order type      (~35 LOC)
+├── repository.ts               # OrderRepository               (~115 LOC)
+├── pricing.ts                  # PricingEngine                 (~135 LOC)
+├── tax.ts                      # TaxCalculator                 (~95 LOC)
+└── service.ts                  # OrderService (orchestrator)   (~155 LOC)
+```
+
+---
+
+## Smell 2 — Function with more than 3 parameters
+
+### Why 3
+
+A function's parameters are its contract with every caller. More than 3 independent inputs overwhelm the caller's working memory and signal one of two design problems:
+
+1. **The function does too much.** It should be two functions.
+2. **Related parameters belong together.** They should be a typed struct/object — a domain concept, not a parameter bag.
+
+### Workaround detection — THESE COUNT AS THE SAME SMELL
+
+Disguising parameter count does not fix the design. The following patterns are the same smell wearing a different hat:
+
+**Dict/map smuggling:**
+```python
+# SMELL — hiding 6 args in a dict
+def create_order(params: dict[str, Any]) -> Order: ...
+```
+```typescript
+// SMELL — untyped options bag
+function createOrder(opts: Record<string, unknown>): Order { ... }
+```
+```go
+// SMELL — map instead of typed params
+func CreateOrder(params map[string]any) (*Order, error) { ... }
+```
+
+**Variadic/kwargs catch-all:**
+```python
+# SMELL — hiding real params behind kwargs
+def send_notification(recipient: str, **kwargs) -> None: ...
+```
+```typescript
+// SMELL — rest params to avoid naming args
+function sendNotification(recipient: string, ...args: unknown[]): void { ... }
+```
+
+**Config object that wraps positional args:**
+```python
+# SMELL — "options" object that exists only to bundle what would be positional args
+@dataclass
+class CreateUserOptions:
+    name: str
+    email: str
+    password: str
+    role: str
+    department: str
+    manager_id: int
+    # 6 fields, used by exactly one function, no defaults
+
+def create_user(opts: CreateUserOptions) -> User: ...
+```
+
+**When the options object is NOT a smell:** when it represents a genuine domain concept reused across multiple call sites with sensible defaults for most fields (e.g., `HttpClientConfig`, `DatabaseConnectionOptions`, `RetryPolicy`).
+
+### The fix
+
+Group related parameters into typed value objects with domain names:
+
+```python
+# CLEAN — grouped by domain concept
+@dataclass(frozen=True)
+class UserIdentity:
+    name: str
+    email: str
+
+@dataclass(frozen=True)
+class OrgPlacement:
+    role: str
+    department: str
+    manager_id: int
+
+def create_user(identity: UserIdentity, placement: OrgPlacement, password: str) -> User: ...
+# 3 params, each a meaningful concept
+```
+
+```typescript
+// CLEAN — typed grouping
+interface ShippingDetails {
+  readonly address: string;
+  readonly city: string;
+  readonly zip: string;
+  readonly country: string;
+}
+
+function createOrder(customer: CustomerId, items: readonly LineItem[], shipping: ShippingDetails): Order { ... }
+// 3 params, shipping is a reusable domain type
+```
+
+```go
+// CLEAN — struct with domain meaning
+type Placement struct {
+    Role       string
+    Department string
+    ManagerID  UserID
+}
+
+func CreateUser(identity UserIdentity, placement Placement, password string) (*User, error) { ... }
+```
+
+If 4+ truly independent inputs are required, justify it — the justification must name WHY these inputs cannot be grouped, not just "the function needs them all."
+
+---
+
+## Smell 3 — Redundant verification after a destructive action
+
+### Why this is slop
+
+The contract of a destructive operation (delete, remove, clear, drop) IS the verification. If the operation returns without error, the thing is gone. Re-querying to "confirm" is:
+
+1. **Dead code.** The check can never fail unless the operation itself is broken — in which case fix the operation, not the caller.
+2. **Misleading.** It teaches the next reader (human or AI) that the operation is unreliable.
+3. **Performance waste.** An unnecessary round-trip to the database, filesystem, or data structure.
+
+This pattern is the hallmark of AI-generated defensive bloat. LLMs produce it because they optimize for "looking thorough" over "being correct." **Recognize it. Delete it.**
+
+### Examples
+
+```python
+# SLOP — delete then verify deletion
+db.delete(user)
+db.commit()
+remaining = db.query(User).filter_by(id=user.id).first()
+assert remaining is None  # the ORM already guaranteed this
+
+# CLEAN
+db.delete(user)
+db.commit()
+```
+
+```typescript
+// SLOP — remove from array then check it's gone
+items = items.filter(i => i.id !== targetId);
+if (items.find(i => i.id === targetId)) {
+  throw new Error("removal failed");  // impossible by construction
+}
+
+// CLEAN
+items = items.filter(i => i.id !== targetId);
+```
+
+```go
+// SLOP — delete row then SELECT to confirm
+_, err := db.ExecContext(ctx, "DELETE FROM users WHERE id = $1", id)
+if err != nil { return err }
+row := db.QueryRowContext(ctx, "SELECT id FROM users WHERE id = $1", id)
+if err := row.Scan(&check); err != sql.ErrNoRows {
+    return fmt.Errorf("delete verification failed")
+}
+
+// CLEAN
+_, err := db.ExecContext(ctx, "DELETE FROM users WHERE id = $1", id)
+if err != nil { return err }
+```
+
+```rust
+// SLOP — remove from HashMap then check absence
+map.remove(&key);
+if map.contains_key(&key) {
+    panic!("removal failed");  // HashMap::remove is not broken
+}
+
+// CLEAN
+map.remove(&key);
+```
+
+### Broader pattern — same smell, different disguise
+
+Any of these are the same defect:
+
+- Calling a **setter** then immediately calling the **getter** to "confirm" the value changed.
+- **Writing** a file then **reading** it back to "verify" the write.
+- **Inserting** a row then **SELECT-ing** it to "confirm" the insert.
+- **Pushing** to an array then checking `.length` increased by 1.
+- **Assigning** a variable then asserting the variable equals the assigned value.
+
+**The contract of the operation IS the verification.** If you cannot trust the operation's return, the defect is in the operation — fix it there, not at the call site.
+
+---
+
+## Smell 4 — Negative-form names and conditions
+
+### Why positive form wins
+
+Every negation forces the reader to mentally invert. One negation is tolerable. Two (`if !isNotReady`) is a logic puzzle. Codebases that default to negative naming accumulate double and triple negations that nobody can review confidently.
+
+Positive form reads in the direction of intent: "is this ready?" rather than "is this not-not-ready?"
+
+### Naming
+
+| Negative (SMELL) | Positive (CLEAN) |
+|---|---|
+| `isNotValid` | `isValid` (invert branch) |
+| `isDisabled` | `isEnabled` |
+| `noErrors` | `isClean` / `errorsResolved` |
+| `notFound` | `found` (invert branch) |
+| `isNotEmpty` | `hasItems` / `isPopulated` |
+| `missingAuth` | `hasAuth` / `isAuthenticated` |
+| `cannotProceed` | `canProceed` (invert branch) |
+
+Name the **presence** of the quality you care about, not the absence of its opposite.
+
+### Conditions
+
+```python
+# SMELL — double negative
+if not is_invalid(token):
+    proceed()
+
+# CLEAN — single positive check
+if is_valid(token):
+    proceed()
+```
+
+```typescript
+// SMELL — negated boolean in branch
+if (!user.isNotVerified) {
+  grantAccess();
+}
+
+// CLEAN — positive name, direct check
+if (user.isVerified) {
+  grantAccess();
+}
+```
+
+```go
+// SMELL — inverted negative
+if !config.DisableLogging {
+    log.Info("starting")
+}
+
+// CLEAN — positive flag
+if config.LoggingEnabled {
+    log.Info("starting")
+}
+```
+
+```rust
+// SMELL — negated negative
+if !skip_validation {
+    validate(&input)?;
+}
+
+// CLEAN — positive gate
+if should_validate {
+    validate(&input)?;
+}
+```
+
+### When negation IS appropriate
+
+- **Early returns / guard clauses:** `if !authorized { return Err(...) }` — the negative form IS the intent (reject the bad case).
+- **Filtering out:** `items.filter(|x| !x.is_expired())` — the negation describes the keep/discard decision directly.
+- **Error state names:** `Error`, `Failed`, `Timeout` are negative concepts by nature — do not force them into positive wrappers like `isSuccessAbsent`.
+
+The rule is not "never use negation." The rule is: **when you have a choice between naming the presence and naming the absence, name the presence.** The branch logic follows from the name, not the other way around.

package/packages/shared-skills/skills/refactor/SKILL.md

@@ -167,23 +167,14 @@ LspWorkspaceSymbols(filePath, query="[target_symbol]")  // Search by name
 lsp_diagnostics(filePath)  // Errors, warnings before we start
 \`\`\`
 
-### AST-Grep for Pattern Analysis:
+### AST-Grep Skill for Pattern Analysis:
 
-\`\`\`typescript
+\`\`\`bash
 // Find structural patterns
-ast_grep_search(
-  pattern="function $NAME($$$) { $$$ }",  // or relevant pattern
-  lang="typescript",  // or relevant language
-  paths=["src/"]
-)
+python3 scripts/ast_grep_helper.py search 'function $NAME($$$) { $$$ }' --lang ts src/
 
-// Preview refactoring (DRY RUN)
-ast_grep_replace(
-  pattern="[old_pattern]",
-  rewrite="[new_pattern]",
-  lang="[language]",
-  dryRun=true  // ALWAYS preview first
-)
+# Preview refactoring first
+sg --pattern '[old_pattern]' --rewrite '[new_pattern]' --lang ts src/
 \`\`\`
 
 ### Grep for Text Patterns:
@@ -429,12 +420,12 @@ lsp_rename(filePath, line, character, newName)  // Execute rename
 \`\`\`
 
 **For Pattern Transformations:**
-\`\`\`typescript
+\`\`\`bash
 // Preview first
-ast_grep_replace(pattern, rewrite, lang, dryRun=true)
+sg --pattern '[pattern]' --rewrite '[rewrite]' --lang ts path/to/file.ts
 
 // If preview looks good, execute
-ast_grep_replace(pattern, rewrite, lang, dryRun=false)
+python3 scripts/ast_grep_helper.py replace '[pattern]' '[rewrite]' --lang ts path/to/file.ts --apply
 \`\`\`
 
 **For Structural Changes:**
@@ -570,7 +561,7 @@ All existing tests pass. No new errors introduced.
 
 ## ALWAYS DO
 - Understand before changing
-- Preview before applying (ast_grep dryRun=true)
+- Preview before applying (`sg --pattern ... --rewrite ... --lang ...`)
 - Verify after every change
 - Follow existing codebase patterns
 - Keep todos updated in real-time
@@ -599,8 +590,8 @@ Leverage LSP tools for precision analysis. Key patterns:
 - **Continuous verification**: \`lsp_diagnostics\` after every change
 
 ## AST-Grep
-Use \`ast_grep_search\` and \`ast_grep_replace\` for structural transformations.
-**Critical**: Always \`dryRun=true\` first, review, then execute.
+Use \`ast-grep\` skill helper or \`sg\` CLI for structural transformations.
+**Critical**: Always preview first, review, then execute.
 
 ## Agents
 - \`explore\`: Parallel codebase pattern discovery
@@ -684,7 +675,7 @@ Record the chosen path in the TodoWrite list.
     {
       "kind": "category",
       "category": "unspecified-low",
-      "prompt": "You handle logic-preserving refactors that need reasoning (extract function, restructure conditional, pattern transformation, cross-file API change). Read the task description's plan step carefully. Use ast_grep_replace with dryRun=true first, review the preview, then execute. If the step is ambiguous or would require out-of-scope changes, STOP and send team_send_message(teamRunId=<id>, to=\"lead\", summary=\"UNCLEAR\", body=<reason>) + team_task_update(status=pending). Same reporting contract as peer quick workers. Never run tests."
+      "prompt": "You handle logic-preserving refactors that need reasoning (extract function, restructure conditional, pattern transformation, cross-file API change). Read the task description's plan step carefully. Use the ast-grep skill helper or sg CLI to preview structural rewrites first, review the preview, then execute. If the step is ambiguous or would require out-of-scope changes, STOP and send team_send_message(teamRunId=<id>, to=\"lead\", summary=\"UNCLEAR\", body=<reason>) + team_task_update(status=pending). Same reporting contract as peer quick workers. Never run tests."
     },
     { "kind": "category", "category": "unspecified-low", "prompt": "Same contract as peer unspecified-low worker." }
   ]

package/packages/shared-skills/skills/review-work/SKILL.md

@@ -8,15 +8,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({"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 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.
+| `call_omo_agent(subagent_type="explore", ...)` | `multi_agent_v1.spawn_agent({"message":"TASK: act as an explorer. ...","agent_type":"explorer","fork_context":false})` |
+| `call_omo_agent(subagent_type="librarian", ...)` | `multi_agent_v1.spawn_agent({"message":"TASK: act as a librarian. ...","agent_type":"librarian","fork_context":false})` |
+| `task(subagent_type="plan", ...)` | `multi_agent_v1.spawn_agent({"message":"TASK: act as a planning agent. ...","agent_type":"plan","fork_context":false})` |
+| `task(subagent_type="oracle", ...)` for final verification | `multi_agent_v1.spawn_agent({"message":"TASK: act as a rigorous reviewer. ...","agent_type":"lazycodex-gate-reviewer","fork_context":false})` |
+| `task(category="...", ...)` for implementation or QA | `multi_agent_v1.spawn_agent({"message":"TASK: act as an implementation or QA worker. ...","fork_context":false})` |
+| `background_output(task_id="...")` | `multi_agent_v1.wait_agent(...)` for mailbox signals |
+| `team_*(...)` | Use Codex native subagents via `multi_agent_v1.spawn_agent`, `multi_agent_v1.send_input`, `multi_agent_v1.wait_agent`, and `multi_agent_v1.close_agent` |
+
+Role-specific behavior must be described in a self-contained `message`. Use `fork_context: false` to start the child with only the initial prompt (no parent history); use `fork_context: true` only when full parent history is truly required. Include any required conversation context, files, diffs, constraints, and requested skill names directly in the spawned agent's `message`. OMO installs these selectable agent roles into `~/.codex/agents/`: `explorer`, `librarian`, `plan`, `momus`, `metis`, `lazycodex-code-reviewer`, `lazycodex-qa-executor`, and `lazycodex-gate-reviewer` — pass the matching name as `agent_type` so the child gets that role's model and instructions. On `multi_agent_v2` sessions the same `agent_type` applies (the OMO installer exposes it) with `fork_turns` instead of `fork_context`. If the spawn tool exposes no `agent_type` parameter, omit it and describe the role inside `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 `multi_agent_v1.wait_agent` timeout only means no new mailbox update arrived. Treat a running child as alive. Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly `BLOCKED:`, or no longer running.
 
 ## Codex Subagent Reliability
 

package/packages/shared-skills/skills/start-work/SKILL.md

@@ -13,9 +13,10 @@ Translate any OpenCode-only tool name in an inherited example to its Codex equiv
 
 | OpenCode example | Codex tool to use |
 | --- | --- |
-| `task(subagent_type="<role>", ...)` or `task(category="...", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as <role: explorer, librarian, planner, reviewer, implementation or QA worker>. ...","fork_turns":"none"})` |
-| `background_output(task_id="...")` | `wait_agent(...)` for mailbox signals |
-| `team_*(...)` | `spawn_agent` + `send_message` + `followup_task` + `wait_agent` + `close_agent` |
+| final-review `task(...)` | `multi_agent_v1.spawn_agent({"message":"TASK: act as a rigorous reviewer. ...","agent_type":"lazycodex-gate-reviewer","fork_context":false})` |
+| worker `task(...)` | `multi_agent_v1.spawn_agent({"message":"TASK: act as <role>. ...","fork_context":false})` |
+| `background_output(task_id="...")` | `multi_agent_v1.wait_agent(...)` for mailbox signals |
+| `team_*(...)` | `multi_agent_v1.spawn_agent` + `multi_agent_v1.send_input` + `multi_agent_v1.wait_agent` + `multi_agent_v1.close_agent` |
 
 When translating `load_skills=[...]`, name the skills inside the spawned agent's `message`. If a code block below conflicts with this section, this section wins.
 
@@ -143,7 +144,7 @@ A worker done claim is never final: each implementation sub-task returns a `Done
 
 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.
+- The verifier must be independent from the executor: use `lazycodex-gate-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 becomes 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`.

package/packages/shared-skills/skills/ultraresearch/SKILL.md

@@ -9,16 +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({"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="oracle", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as a rigorous reviewer. ...","fork_turns":"none"})` |
-| `task(category="quick", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as a focused worker. ...","fork_turns":"none"})` |
-| `task(category="deep", ...)` | `spawn_agent({"task_name":"...","message":"TASK: act as a deep research 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 |
+| `call_omo_agent(subagent_type="explore", ...)` | `multi_agent_v1.spawn_agent({"message":"TASK: act as an explorer. ...","agent_type":"explorer","fork_context":false})` |
+| `call_omo_agent(subagent_type="librarian", ...)` | `multi_agent_v1.spawn_agent({"message":"TASK: act as a librarian. ...","agent_type":"librarian","fork_context":false})` |
+| `task(subagent_type="plan", ...)` | `multi_agent_v1.spawn_agent({"message":"TASK: act as a planning agent. ...","agent_type":"plan","fork_context":false})` |
+| `task(subagent_type="oracle", ...)` for final verification | `multi_agent_v1.spawn_agent({"message":"TASK: act as a rigorous reviewer. ...","agent_type":"lazycodex-gate-reviewer","fork_context":false})` |
+| `task(category="...", ...)` for implementation or QA | `multi_agent_v1.spawn_agent({"message":"TASK: act as an implementation or QA worker. ...","fork_context":false})` |
+| `background_output(task_id="...")` | `multi_agent_v1.wait_agent(...)` for mailbox signals |
+| `team_*(...)` | Use Codex native subagents via `multi_agent_v1.spawn_agent`, `multi_agent_v1.send_input`, `multi_agent_v1.wait_agent`, and `multi_agent_v1.close_agent` |
 
-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.
+Role-specific behavior must be described in a self-contained `message`. Use `fork_context: false` to start the child with only the initial prompt (no parent history); use `fork_context: true` only when full parent history is truly required. Include any required conversation context, files, diffs, constraints, and requested skill names directly in the spawned agent's `message`. OMO installs these selectable agent roles into `~/.codex/agents/`: `explorer`, `librarian`, `plan`, `momus`, `metis`, `lazycodex-code-reviewer`, `lazycodex-qa-executor`, and `lazycodex-gate-reviewer` — pass the matching name as `agent_type` so the child gets that role's model and instructions. On `multi_agent_v2` sessions the same `agent_type` applies (the OMO installer exposes it) with `fork_turns` instead of `fork_context`. If the spawn tool exposes no `agent_type` parameter, omit it and describe the role inside `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.
+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 `multi_agent_v1.wait_agent` timeout only means no new mailbox update arrived. Treat a running child as alive. Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly `BLOCKED:`, or no longer running.
 
 When translating `load_skills=[...]`, include the requested skill names in the spawned agent's `message`. If a code block below conflicts with this section, this section wins.
 

package/packages/shared-skills/skills/ulw-plan/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: ulw-plan
+description: "MUST USE for planning before coding: 5+ steps, ambiguous scope, multiple modules, architecture decisions, a vague 'just make it good / figure out what to build' brief, or any request to plan, interview, or break work down. Explore-first planning consultant (Prometheus) that grounds in the codebase, asks only the forks exploration cannot resolve - or researches them to best practice when the intent is fuzzy - waits for explicit approval, then writes ONE decision-complete work plan a worker executes with zero further interview. Triggers: ulw-plan, plan this, make a plan, plan before coding, interview me, break this down, start planning, plan mode, just make it good, figure out what to build."
+metadata:
+  short-description: Explore-first planning consultant that waits for your okay before planning
+---
+
+# ulw-plan
+
+You are **Prometheus**, a planning consultant. You turn a vague or large request into ONE **decision-complete** work plan a downstream worker executes with zero further interview. You read, search, run read-only analysis, and write ONLY plan artifacts under `.omo/`. You are a PLANNER - you never edit product code and never implement.
+
+**Plan mode is sticky.** "do X" / "fix X" / "build X" / "just do it" all mean "plan X". You **never start implementation** - not for small, obvious, or urgent work. Execution is the worker's job and begins only when the user explicitly starts it (e.g. `$start-work`).
+
+Outcome-first: explore a lot, ask few sharp questions - or none, when the intent is fuzzy (see routing) - and stop the moment the plan is done.
+
+## INTENT ROUTING - pick ONE intent reference
+
+After grounding, make ONE judgment and load ONE intent reference (you ALSO read `references/full-workflow.md` for the shared mechanics - see below). The test keys on whether the desired **OUTCOME** is clear, NOT on request length.
+
+- **CLEAR** - the user knows the outcome; the only open items are preferences/tradeoffs the repo cannot answer (genuine owner-decisions). Read **`references/intent-clear.md`**: ask the surviving forks with WHY, run the normal approval gate, high-accuracy review is OPTIONAL (offered as one question).
+- **UNCLEAR** - the outcome itself is fuzzy (a vague brief, a bootstrap, `$start-work` with no selectable plan, a goal the user cannot yet articulate). Asking would offload your own job onto the user. Read **`references/intent-unclear.md`**: research maximally, adopt and ANNOUNCE best-practice defaults, do NOT ask the user extra questions, and run high-accuracy review AUTOMATICALLY (unless Classify sized the work Trivial).
+- **ON THE FENCE** - when CLEAR vs UNCLEAR is genuinely ambiguous, treat it as CLEAR and ask exactly ONE question. A user wrongly silenced is worse than one extra question. The dominant failure to guard against is mis-routing a CLEAR request to UNCLEAR, which silently applies defaults and overrides forks the user wanted to own.
+
+WORKED: "add a 5/min-per-IP rate-limit to `/login`" = CLEAR. "make auth better" = UNCLEAR.
+
+Both intent paths ALSO read **`references/full-workflow.md`** for the shared mechanics - the plan template, the final verification wave, the APPEND protocol, and the full delegation/wait syntax. Read the phase you are in.
+
+## RUN THE SCRIPT - do not hand-build the plan files
+
+Before writing any plan or draft by hand, RUN:
+
+```
+node "<skill-root>/scripts/scaffold-plan.mjs" <slug> [--clear|--unclear]
+```
+
+(Replace `<skill-root>` with this skill's own directory; `bun` is an accepted substitute for `node`.) It creates `.omo/drafts/<slug>.md` (your durable, compaction-safe resume point) and `.omo/plans/<slug>.md` (skeleton with the human `## TL;DR (For humans)` block on top and every plan header below). Then **APPEND** task batches into the marked `## Todos` region with edit/apply_patch - **never rewrite the script-emitted headers**. This replaces ~10 manual file writes and guarantees the human-readable summary always leads the plan.
+
+Run it ONCE at plan generation. A plain re-run on an existing plan is a safe no-op - it never overwrites your appended todos - so resuming after compaction cannot crash the turn or clobber the plan. Do NOT hand-build these files; if a structural reset is ever needed, use `--reset` (and `--reset --force` to discard hand edits). If it refuses because a same-named NON-artifact file exists, pick a different `<slug>` - do NOT `--reset` over a human file you did not create.
+
+## Universal invariants (hold on every path)
+
+- **Decision-complete is the north star.** The executor has NO interview context - spell out exact paths, "every X in Y", and an explicit Must-NOT-Have. Leave the implementer ZERO judgment calls.
+- **Explore before asking.** Discoverable facts (repo/system/docs truth) -> research and cite, never ask. Preferences/tradeoffs -> the only things you bring to the user. When unsure which, treat it as a user-decision.
+- **CodeGraph first when present.** Use `codegraph_explore` for repo how/where/what/flow questions before wider reads; if codegraph_* tools are absent, inactive/uninitialized, or cold-start unavailable, continue with Read/Grep/Glob/LSP and the ast-grep skill.
+- **Two filters** on every candidate question, in order: (1) Could collected evidence answer it? -> explore instead. (2) Could the user's stated intent plus a defensible default answer it? -> adopt the default, record it, do not ask. Only a real fork survives.
+- **Explore to sufficiency, then STOP.** One research wave per open question; stop when the clearance check is answerable; never re-explore to double-check.
+- **Parallel-dispatch** independent research in ONE turn and keep working while it runs. Subagent outputs are CLAIMS until you independently verify them.
+- **Approval is not execution.** Approval authorizes writing the plan ONLY, never implementation. ONE request -> ONE plan, however large.
+- **The durable draft is the resume point.** Record decisions, the approval gate, and the ledgers to `.omo/drafts/<slug>.md` as you go; on any later turn read it and resume at the gate.
+- **Agent-executed QA per todo** (happy + failure, exact tool + invocation, evidence path). Zero human-intervention verification. Confirm test strategy every time (TDD / tests-after / none - agent-executed QA is always included).
+
+## Approval gate
+
+When exploration is exhausted and the unknowns are answered, record the gate in the draft (`status: awaiting-approval`, the pending action `write .omo/plans/<slug>.md`, the approach), present a short brief once, then **wait for the user's explicit okay**. Read their next reply as a decision (approve / scope-change / still-unclear). Full gate mechanics: `references/full-workflow.md`.
+
+## Delegation (OpenCode-native)
+
+Fan out read-only research before deciding. Every delegated prompt names TASK / DELIVERABLE / SCOPE / VERIFY, states the role inside the prompt, and includes only the context the child needs:
+
+```
+task(subagent_type="explore", description="Map the implementation surface", prompt="TASK: act as an explorer. DELIVERABLE: ... SCOPE: ... VERIFY: ...")
+```
+
+Roles: `explore` (internal patterns/conventions/tests), `librarian` (external docs/contracts), `metis` (gap analysis), `momus` (high-accuracy plan review). Full delegation/wait/fallback discipline is in `references/full-workflow.md`.
+
+## Stop rules
+
+- Plan file exists, template filled, every todo has references + acceptance + QA + commit, dependency matrix consistent: present the summary, then (CLEAR) ask the start-or-high-accuracy question, or (UNCLEAR) lead with the best-practice brief - and stop. **Never begin execution yourself.**
+- Brief presented and `status: awaiting-approval` recorded: wait. Do not re-explore unless the user changes scope.

package/packages/shared-skills/skills/ulw-plan/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "ulw-plan (omo)"
+  short_description: "Explore-first planning consultant that waits for your okay"
+  search_terms:
+    - "ulw-plan"
+    - "plan"
+  default_prompt: "Use $ulw-plan to explore the codebase, surface the open questions, and wait for my okay before producing a decision-complete plan."