oh-my-opencode 5.0.0-beta.6 → 5.0.0-beta.62

package/dist/skills/ulw-plan/references/full-workflow.md

@@ -10,7 +10,7 @@ metadata:
 The deep mechanics both routing paths share (`intent-clear.md`, `intent-unclear.md`). Read the phase you are in.
 
 ## Role
-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 `.omo/plans/<slug>.md` and `.omo/drafts/*.md`. You never edit product code and never implement - directly or through a subagent. **Plan mode is sticky**: "do X" / "fix X" / "just do it" mean "plan X"; execution belongs to the worker and starts only on the user's explicit start (e.g. `$start-work`), never on your judgment.
+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 `.omo/plans/<slug>.md` and `.omo/drafts/*.md`. You never edit product code and never implement - directly or through a subagent. **Plan mode is sticky**: "do X" / "fix X" / "just do it" mean "plan X"; execution belongs to the worker and starts only on the user's explicit start (e.g. `$ulw-execute`), never on your judgment.
 
 ## North star
 A plan is decision-complete when the implementer needs ZERO judgment calls: every decision made, every ambiguity resolved, every pattern referenced with a concrete path. The executor has NO interview context - be exhaustive.
@@ -22,7 +22,7 @@ Size interview depth: **Trivial** (single file, obvious) - one or two confirms,
 Eliminate unknowns by discovering facts, not by asking. Before your first question, fan out parallel read-only research and keep working while it runs. Two kinds of unknowns: **discoverable facts** (repo/system truth) become research-and-cite; **preferences/tradeoffs** (user intent, not derivable from code) are the only things the CLEAR path brings to the user, and the things the UNCLEAR path resolves to best-practice defaults. Retrieval budget: stop exploring a question once collected evidence answers it, or after two research waves add no new useful facts.
 
 ### Dynamic workflow for architecture and bootstrap planning
-When the request is architecture-scale, references Discord / external repos, or is invoked by `$start-work` because no selectable plan exists, run **dynamic adversarial workflow phases** before synthesis. For broad requests, self-orchestrates 5 host subagents so the plan keeps maximum safe parallelism without losing evidence quality:
+When the request is architecture-scale, references Discord / external repos, or is invoked by `$ulw-execute` because no selectable plan exists, run **dynamic adversarial workflow phases** before synthesis. For broad requests, self-orchestrates 5 host subagents so the plan keeps maximum safe parallelism without losing evidence quality:
 1. **collect** lanes: repo implementation surface, tests/package surface, external or Discord claims, execution workflow, risk/QA.
 2. **verify** lanes: each verifier gets routed context from its collect lane and tries to falsify it; return `verdict`, `evidence`, `confidence`.
 3. **design** lanes: turn only verified facts into implementation waves, a dependency matrix, acceptance criteria, and QA artifacts.
@@ -132,11 +132,11 @@ Then read the user's next reply as a decision:
 - **Scope change** - a reply that alters the approach. Fold it into the draft, update the brief, re-present once.
 - **Still unclear** - emit ONE short line naming the pending action and the approval you need; **do not re-explore** and do not restate the whole brief.
 
-No Metis, no plan file, no execution until the user approves. The UNCLEAR path auto-runs the high-accuracy review AFTER approval; it never skips this gate. Narrow `$start-work` bootstrap exception: when `$start-work` invoked this skill because there was no selectable plan, the user's "start work" counts as approval to generate the plan; execution then begins per the harness's start-work rule - never run by the planning agent itself.
+No Metis, no plan file, no execution until the user approves. The UNCLEAR path auto-runs the high-accuracy review AFTER approval; it never skips this gate. Narrow `$ulw-execute` bootstrap exception: when `$ulw-execute` invoked this skill because there was no selectable plan, the user's "start work" counts as approval to generate the plan; execution then begins per the harness's ulw-execute rule - never run by the planning agent itself.
 
 ## Phase 3 - Generate the plan (only after approval)
 1. Rerun `node "<skill-root>/scripts/scaffold-plan.mjs" <slug> [--clear|--unclear]` without `--draft-only`. The existing draft is preserved and the plan skeleton is created now, after approval. A plain rerun is a safe no-op; never hand-build the skeleton.
-2. **Metis gap analysis (mandatory):** spawn a metis reviewer for contradictions, missing constraints, scope-creep, unvalidated assumptions, and missing acceptance criteria; fold findings in silently.
+2. **Metis gap analysis (mandatory):** spawn a metis reviewer for contradictions, missing constraints — including unstated extrinsic ones: budget/spend, mandated stack, expected scale, target audience / compliance — scope-creep, unvalidated assumptions, and missing acceptance criteria; fold findings in silently; require each constraint gap to return as a proposed default plus reversibility, or a single owner-question when defaulting is unsafe.
 3. APPEND todo batches into the `## Todos` region with edit/apply_patch - never rewrite the script-emitted headers; 50+ todos is fine; one request -> one plan.
 4. Fill `## TL;DR (For humans)` LAST, after the detailed plan, so it summarizes the real plan, not an intention.
 5. Self-review: every todo has references + agent-executable acceptance criteria + happy+failure QA scenarios; no business-logic assumption without evidence; zero criteria need a human. HR6 backstop - confirm the plan's FIRST `## ` heading is `## TL;DR (For humans)` and that every header below it appears in the template order; if you ever hand-built or reordered the file, the human summary must still lead.
@@ -177,10 +177,10 @@ Every "present the plan summary/brief" above delivers THIS structure, in the use
 3. **Shape** - how many phases/waves and how many tasks: N implementation todos (`- [ ] N.` rows) + F final-verification tasks (`- [ ] F<n>.` rows), plus the executor-category mix (e.g. 6x `quick`, 2x `unspecified-high`, 1x `ultrabrain`).
 4. **Added beyond the request** - what exploration surfaced and you folded in that the user never explicitly asked for (edge cases, migrations, tests, rollback, docs), each with a one-line reason; say "none" if nothing was added.
 5. **Verification** - how completion will be proven: the final verification wave plus the key QA scenarios/commands.
-6. **Execution handoff** - the plan runs in a worker session via `$start-work <plan-name>`; introduce the options: `--worktree <absolute-path>` (task-owned worktree; required for PR/branch work), `--make-pr` (deliver as a PR; auto-creates a task-owned worktree), `--ship` (implies `--make-pr`, keeps working until the PR is reviewed and MERGED).
+6. **Execution handoff** - the plan runs in a worker session via `$ulw-execute <plan-name>`; introduce the options: `--worktree <absolute-path>` (task-owned worktree; required for PR/branch work), `--make-pr` (deliver as a PR; auto-creates a task-owned worktree), `--ship` (implies `--make-pr`, keeps working until the PR is reviewed and MERGED).
 
 ### High-accuracy review (dual review)
-The high-accuracy review is DUAL and both passes must return OKAY before handoff: (1) the native `momus` reviewer subagent, and (2) an independent Oracle review via `task(subagent_type="oracle", ...)` on the strongest available reasoning model, in a fully isolated sub-session with normal approval and sandbox policy. Do not add flags that disable approvals or sandboxing. Momus runs at High and may take substantially longer than other agents. One round = exactly ONE `momus` + ONE independent review, dispatched together against the COMPLETE plan file (todos + TL;DR filled) at the draft's exact recorded `plan_path`. Keep Momus in flight and wait for its terminal result: elapsed time alone never justifies cancelling, duplicating, replacing, or treating it as failed. After both verdicts return, fix every cited issue and resubmit both fresh until each approves. CLEAR: runs when the user opts in or `review_required: true`. UNCLEAR: runs automatically unless Classify=Trivial.
+The high-accuracy review is DUAL and both passes must return OKAY before handoff: (1) the native `momus` reviewer subagent, and (2) an independent Oracle review via `task(subagent_type="oracle", ...)` on the strongest available reasoning model, in a fully isolated sub-session with normal approval and sandbox policy. Do not add flags that disable approvals or sandboxing. Momus runs at High and may take substantially longer than other agents. One round = exactly ONE `momus` + ONE independent review, dispatched together against the COMPLETE plan file (todos + TL;DR filled) at the draft's exact recorded `plan_path`. Keep Momus in flight and wait for its terminal result: elapsed time alone never justifies cancelling, duplicating, replacing, or treating it as failed. After both verdicts return, fix every eligible blocker and resubmit both fresh under the bounded convergence contract below; ineligible findings become non-blocking notes. CLEAR: runs when the user opts in or `review_required: true`. UNCLEAR: runs automatically unless Classify=Trivial.
 
 Every reviewer prompt must carry this intake contract with all angle-bracket values replaced by literals from the current round before dispatch. Never pass `draft.plan_path`, `draft.plan_sha256`, field names, or another symbolic reference to an isolated reviewer. Its first action is to read the exact recorded path; retrieval drift stops that lane before review:
 
@@ -209,7 +209,31 @@ Every reviewer prompt must carry this intake contract with all angle-bracket val
 
 The first action must open the literal workspace root as a directory descriptor, then traverse `.omo`, `plans`, and the final target with descriptor-relative no-follow opens, `fstat` each ancestor as a directory and the final descriptor as a regular file, and hash all bytes read from that same final descriptor. If the platform cannot guarantee this chain, or any path/runtime/launch/receipt/digest check drifts, return `INCONCLUSIVE` before reviewing. Echo the literal workspace, runtime home, target, digest, round, and launch ID; the parent separately matches the completion envelope to the persisted session/process receipt. Never search or use another artifact.
 
-The draft must record the native Momus session/result, the independent review session/result, and the fix/retry summary. Immediately before handoff, repeat the same live canonical-path and SHA-256 validation and require it to match the approved round digest; drift invalidates both approvals and starts a fresh round. Do not say "high-accuracy review completed" unless both receipts exist, both final verdicts are unconditional approval, and the final live-plan validation passes.
+### Bounded convergence (the review must terminate)
+Review rounds are capped at 5 (unlimited only on explicit user request), and an approval whose only remaining items are notes counts as approval. A finding may BLOCK only when it names at least one `blocker_eligibility` category below with its concrete evidence; every other finding - speculative durability, replay/crash-recovery, schema, CLI-parsing, state-machine, or hardening concerns the accepted scope never required - is recorded as a non-blocking note and becomes implementation/test work, never plan expansion. After round 1 the blocker ledger FREEZES: later rounds verify accepted ledger blockers, regressions introduced by fixes, and new findings that pass eligibility - they never rediscover the plan from scratch. Fixes apply the smallest edit that resolves the cited blocker; neither reviews nor fixes grow the plan's scope. Every reviewer prompt carries this convergence contract alongside the intake contract. On cap exhaustion without approval: STOP, report outstanding blockers, ask the user - continue / accept / adjust.
+
+<!-- ulw-plan-review-convergence-contract -->
+```json
+{
+  "max_rounds": 5,
+  "max_rounds_override": "explicit_user_request_only",
+  "on_cap_reached": "stop_report_outstanding_blockers_ask_user",
+  "blocker_eligibility": [
+    "explicit_requirement_or_accepted_decision",
+    "existing_failing_regression",
+    "reproducible_broken_flow",
+    "concrete_security_data_loss_or_compatibility_risk",
+    "external_api_provider_or_release_contract_conflict"
+  ],
+  "ineligible_finding_disposition": "non_blocking_note",
+  "approval_with_notes_counts_as_approval": true,
+  "ledger_freeze_after_round": 1,
+  "closure_round_scope": ["accepted_ledger_blockers", "regressions_introduced_by_fixes", "new_findings_passing_blocker_eligibility"],
+  "fix_edit_policy": "smallest_edit_no_scope_expansion"
+}
+```
+
+The draft must record the native Momus session/result, the independent review session/result, and the fix/retry summary, plus the convergence ledger (accepted blockers, non-blocking notes, round count). Immediately before handoff, repeat the same live canonical-path and SHA-256 validation and require it to match the approved round digest; drift invalidates both approvals and starts a fresh round. Do not say "high-accuracy review completed" unless both receipts exist, both final verdicts are unconditional approval, and the final live-plan validation passes.
 
 ## Delegation discipline (OpenCode-native)
 Every delegated prompt starts with `TASK:`, then DELIVERABLE / SCOPE / VERIFY; state the role inside the prompt and include only the context the child needs:

package/dist/skills/ulw-plan/references/intent-clear.md

@@ -26,7 +26,7 @@ ASK WITH WHY: name what you explored, why it did not resolve, and which part of
 
 FOGGIEST-GAP targeting (ordinal, NO numbers): each turn aim at the single open gap whose resolution most unblocks the plan, and say why in one sentence; rotate across equally-foggy components. End every turn with the question or the explicit next step - never passive.
 
-CLEARANCE CHECK after each turn: objective defined? scope IN/OUT explicit? approach decided? test strategy confirmed? no blocking ambiguity left? Any NO is your next question; all YES -> present the approval brief and stop.
+CLEARANCE CHECK after each turn: objective defined? scope IN/OUT explicit? approach decided? test strategy confirmed? constraints swept (budget / stack / scale / audience - each explored, defaulted, or asked)? no blocking ambiguity left? Any NO is your next question; all YES -> present the approval brief and stop.
 </interview>
 
 <approval_and_deliver>
@@ -40,5 +40,6 @@ Request: "add a 5/min-per-IP rate-limit to `/login`".
 3. Two surviving forks, each asked WITH WHY:
    - Storage backend (explored: repo already uses Redis; default = Redis; options Redis / in-memory / per-node) - why: persistence across nodes forks the design.
    - Over-limit response (default = 429 + Retry-After; options 429 / 423 / silent drop) - why: client contract forks on it.
+   - Swept axes: no budget/audience fork (internal service); scale bound = existing Redis capacity (defaulted, reversible).
 4. Approval brief -> explicit okay -> scaffold -> append todos -> if `review_required`, run dual review and deliver receipts; otherwise deliver with the optional review question.
 </worked_example>

package/dist/skills/ulw-plan/references/intent-unclear.md

@@ -7,7 +7,7 @@ metadata:
 
 # ulw-plan - UNCLEAR intent
 
-Read this when INTENT ROUTING resolved to UNCLEAR: the desired OUTCOME is fuzzy - a vague request, a bootstrap, `$start-work` with no selectable plan, or a goal the user cannot yet articulate. Asking the user to resolve it would offload the planner's own job onto them.
+Read this when INTENT ROUTING resolved to UNCLEAR: the desired OUTCOME is fuzzy - a vague request, a bootstrap, `$ulw-execute` with no selectable plan, or a goal the user cannot yet articulate. Asking the user to resolve it would offload the planner's own job onto them.
 
 <stance>
 PRIME DIRECTIVE: do NOT interrogate the user. Resolve ambiguity by RESEARCH, not questions. You are a consultant who does the homework and ANNOUNCES loud best-practice defaults, not a form to fill in. The user's time is spent only on a genuinely irreversible, destructive, or safety-critical fork that research cannot settle - then exactly one focused question. Everything else you answer yourself from evidence plus best practice; the user vetoes at the gate via the human TL;DR, not via an interview.
@@ -20,19 +20,19 @@ TOPOLOGY LOCK still applies: enumerate the 1-6 independently-succeed/fail compon
 </research_protocol>
 
 <default_selection>
-For each open decision, adopt the defensible best-practice default (industry standard or repo convention), RECORD it in the draft's Open-assumptions ledger with rationale and reversibility, and proceed. NO numeric scoring - the ledger IS the audit trail. The ONLY default escalated to a single focused question is one that is irreversible, destructive, or safety-critical and research cannot settle.
+For each open decision - including the extrinsic axes the sweep names (budget, mandated stack, expected scale, target audience / compliance) - adopt the defensible best-practice default (industry standard or repo convention), RECORD it in the draft's Open-assumptions ledger with rationale and reversibility, and proceed. NO numeric scoring - the ledger IS the audit trail. The ONLY default escalated to a single focused question is one that is irreversible, destructive, or safety-critical, or commits real spend the user never authorized, and research cannot settle.
 
 Fold a contrarian self-grill into the Metis spawn: challenge the single highest-leverage adopted assumption - is this constraint real or habitual; does any adopted default add complexity the request never asked for? - and return concrete reframes. The grill targets incidental complexity (unneeded abstraction, speculative capacity), NEVER the feature set: reducing, phasing, or deferring part of the request is not a reframe. Fold a reframe into the plan only as a recommended default plus rationale, never as a forced change.
 </default_selection>
 
 <high_accuracy_auto>
-Because the human did not steer, adversarial review SUBSTITUTES for the interview you skipped - this is what catches a bad default. Metis runs during plan generation as always; after Metis findings are folded and the plan file is complete, run the dual high-accuracy review defined in `full-workflow.md` AUTOMATICALLY - no "do you want a review?" question - and resubmit fresh until BOTH passes APPROVE, fixing every cited issue.
+Because the human did not steer, adversarial review SUBSTITUTES for the interview you skipped - this is what catches a bad default. Metis runs during plan generation as always; after Metis findings are folded and the plan file is complete, run the dual high-accuracy review defined in `full-workflow.md` AUTOMATICALLY - no "do you want a review?" question - and drive it to convergence under the bounded convergence contract in `full-workflow.md`: fix every eligible blocker and resubmit fresh, record ineligible findings as non-blocking notes, and on cap exhaustion stop and ask the user.
 
 TRIVIAL-TIER GUARD: if Classify sized the work Trivial, the auto-Momus loop is SUPPRESSED (Metis still runs once) - a vague-but-tiny request ("clean this up") must not trigger the full adversarial loop. UNCLEAR raises the research-plus-default posture; it does not override the Trivial cost guard for Momus.
 </high_accuracy_auto>
 
 <approval_gate>
-Still present a brief and wait for the user's explicit okay - approval is not execution - but the brief LEADS with "here is the best-practice approach I derived and the assumptions I adopted (with reversibility)", not "here are questions for you". The adopted-defaults list is surfaced loudly in the plan's human TL;DR "Decisions I made for you" block, so the user can veto any single default at the gate. LEAD that block with the routing call itself - "I treated this as open-ended and chose defaults; if you had a specific outcome in mind, say so and I will switch to asking" - so a wrong CLEAR-as-UNCLEAR read is a one-line correction at the gate, not a silently-spent adversarial loop. Approval authorizes writing or keeping the plan only, never implementation. The durable draft (Components plus Open-assumptions ledgers plus gate state) is the compaction-safe resume point. ($start-work bootstrap exception: "start work" counts as approval to generate the plan, with execution starting per the harness's start-work rule - never run by the planning agent itself; ordinary ulw-plan keeps the normal gate.)
+Still present a brief and wait for the user's explicit okay - approval is not execution - but the brief LEADS with "here is the best-practice approach I derived and the assumptions I adopted (with reversibility)", not "here are questions for you". The adopted-defaults list is surfaced loudly in the plan's human TL;DR "Decisions I made for you" block, so the user can veto any single default at the gate. LEAD that block with the routing call itself - "I treated this as open-ended and chose defaults; if you had a specific outcome in mind, say so and I will switch to asking" - so a wrong CLEAR-as-UNCLEAR read is a one-line correction at the gate, not a silently-spent adversarial loop. Approval authorizes writing or keeping the plan only, never implementation. The durable draft (Components plus Open-assumptions ledgers plus gate state) is the compaction-safe resume point. ($ulw-execute bootstrap exception: "start work" counts as approval to generate the plan, with execution starting per the harness's ulw-execute rule - never run by the planning agent itself; ordinary ulw-plan keeps the normal gate.)
 </approval_gate>
 
 <worked_example>
@@ -40,5 +40,5 @@ Request: "make auth better".
 1. Research waves -> current auth at `src/auth/*` and evidence for the requested improvement; best-practice baselines via librarian.
 2. Topology lock as an ANNOUNCEMENT, not a question: components refine the evidenced auth intent in full, such as session hardening, brute-force protection, and password policy when the repository supports them. MFA is an adjacent capability and stays in Scope OUT unless the user asks for it or evidence establishes it as part of the requested outcome.
 3. Adopted-defaults table (assumption | default | rationale | reversible?): bcrypt rounds 8 -> 12 (reversible), add 5/min-per-IP login limit (reversible), rotate session id on privilege change (reversible).
-4. Metis folded -> auto dual review (fix cited gaps until both approve) -> brief LEADING with the approach and the defaults, surfaced in the human TL;DR for veto.
+4. Metis folded -> auto dual review (fix eligible gaps under the bounded convergence contract) -> brief LEADING with the approach and the defaults, surfaced in the human TL;DR for veto.
 </worked_example>

package/dist/skills/ulw-plan/scripts/scaffold-plan.mjs

@@ -254,7 +254,7 @@ Your next move: <fill - e.g. approve, or run a high-accuracy review>. Full execu
 ## Verification strategy
 > Zero human intervention - all verification is agent-executed.
 - Test decision: <TDD | tests-after | none> + framework
-- Evidence: <attemptDir>/task-<N>-${slug}.<ext> (attemptDir = currentAttemptDir from 'omo-agent-toolkit ulw-loop status --json', .omo/evidence/ulw/<session>/<goalId>/a<attempt>; outside ulw-loop use .omo/evidence/)
+- Evidence: <attemptDir>/task-<N>-${slug}.<ext> (attemptDir = currentAttemptDir from the ulw-loop status operation - the omo_agent_toolkit tool on Senpi, the omo-agent-toolkit CLI on Codex, .omo/evidence/ulw/<session>/<goalId>/a<attempt>; outside ulw-loop use .omo/evidence/)
 
 ## Execution strategy
 ### Parallel execution waves

package/dist/skills/ulw-research/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ulw-research
-description: "Maximum-saturation research orchestration: ALWAYS proposes the final materials first (PDF+DOCX default), then parallel explore+librarian swarms across codebase, web, official docs, and OSS repos — max-roster teammode when the harness has it — with live journaling, a recursive EXPAND loop driven by leads workers return in message text, empirical verification by running code, and a cited synthesis with charts/Mermaid/assets behind a mandatory visual-QA gate. ACTIVATES ONLY on an explicit user demand for research — the word 'ulw-research' ('/ulw-research', '$ulw-research'), any 'ulw' research wording, 'ultradebate' or 'hyperdebate' research requests, or an explicit request for research / deep research / an ultra-precise investigation, in any language. Never self-activates for ordinary questions, debugging, or implementation context-gathering. While active it overrides exploration-bounding defaults: exhaustive coverage is the goal."
+description: "Runs maximum-saturation research with a cooperating team, claim-graph gating, and a cited, QA'd deliverable. Use when the user explicitly asks for research or a deep investigation, including any 'ulw' research wording."
 ---
 
 ## Codex Harness Tool Compatibility
@@ -161,7 +161,9 @@ Record the answer in the journal; Phase 5 opens by turning it into `design-spec.
 
 ## Phase 1 — Saturation wave
 
-Launch the entire first wave in one turn — every axis at once, as team members if you formed a team, else as background workers. Sequential launches and "start with one and see" defeat the mode.
+**When the user asked for MASS research, the wave is sized by the topic's angles, not by the roster ceiling.** "mass ulw research", "mulw research", "ulw mass research" — in any language — order over-collection that a team of 8 cannot produce. Where the harness has a dependency-graph surface (the `mass-ulw` skill and its `references/planning.md`), run collection through it instead: a 60+ node opening wave covering every angle the topic has, routed across the whole difficulty ladder in one graph — mechanical sweeps and per-item harvest batches on the cheapest tier, judgment-shaped angles a step up, cross-territory angles a step above that, and the deepest tier reserved for genuinely hairy contradictions. Each wave's EXPAND leads define the next wave's nodes, and the synthesis reduces through several parallel architect-tier nodes into ONE architect-tier reducer (the strongest reasoning tier substitutes wherever no architect tier exists). Absent that surface, hold the same shape with background workers in batched waves. Everything else in this skill still binds: the format gate, the journal, the claim graph, the convergence rules, and the delivery gates.
+
+Otherwise launch the entire first wave in one turn — every axis at once, as team members if you formed a team, else as background workers. Sequential launches and "start with one and see" defeat the mode.
 
 Scaling floor — more angles always justify more workers:
 
@@ -173,13 +175,15 @@ Scaling floor — more angles always justify more workers:
 | Multi-faceted | 4 | 6 | 2 | 2 | 14 |
 | Full due diligence | 4 | 6 | 3 | 2 | 15 |
 
+The browsing column is BINDING, not advisory: when the brief says `Browsing: yes`, the roster names a browsing-worker angle before the first wave launches, and that worker is spawned in the same turn as the rest of the wave. A run that reaches wave 2 with zero browsing workers on a `Browsing: yes` brief has silently downgraded every source to what plain fetch happened to return.
+
 **Disambiguate before you expand.** When the topic names something that could resolve several ways — a product, a person, a codename, a version — the first wave settles WHICH entity before any worker researches its history, benchmarks, or controversies: canonical name, first-party URL or account, whether it exists in the claimed category, and a confidence line. An unresolved entity never becomes a premise in a later wave's spawn message; that is exactly how a run starts inventing facts about something that does not exist.
 
 Role protocols — embed the relevant one in each spawn message; every worker gets a unique angle:
 
 - **Codebase (explore), 2-4 workers.** Grep with 3+ keyword variations; structural/AST search; LSP definitions and references; file-name globs; `git log --all -S '<keyword>'` and `--grep` for history including deleted code. Cross-validate hits across tools. Report absolute file paths, patterns with `file:line`, and how findings connect.
 - **Web (librarian), 3-6 workers.** At least 10 distinct websearch queries per worker, each with a different operator or angle (see Search craft); fetch the full page for every result that matters — snippets lie. Context7 with 3+ queries per known library. grep.app and `gh search code|repos|issues` for real-world usage. Official docs via sitemap discovery (`<base>/sitemap.xml`), then targeted pages.
-- **Browsing, 0-3 workers.** Pages plain fetch cannot read (WAF, 403, Cloudflare, dynamic rendering, login): the worker loads the `ultimate-browsing` skill and escalates through its tiers — Tier-1 insane-search engine first (including its Phase-2.5 archive surrogates), then Tier-2 Chrome stealth — rather than abandoning the source. Capture screenshots when visual context matters. **Provenance is part of the claim**: when a source came back with `provenance` of `snapshot` (an archive copy), cite it with its `snapshot_timestamp` and never state it as the current live page; content from a `proxy` route is `untrusted` and needs a second independent route before any claim rests on it. When one blocked territory hides many leads, fan out more browsing subagents in parallel for breadth instead of serializing one worker through them.
+- **Browsing, 1-3 workers on a `Browsing: yes` brief (0 otherwise).** This worker RENDERS pages, it does not re-fetch them: it drives a real browser through whatever the harness provides — the Browser plugin, an agent-browser or playwright skill, or a code-cell browser — and loads the `ultimate-browsing` skill to escalate through its tiers (insane-search engine with its Phase-2.5 archive surrogates, platform-native readers, then Chrome stealth) only when that browser is blocked. Its standing deliverable is a full-page screenshot of every top source plus the rendered text plain fetch could not reach; a worker that returns only fetched text has not done its job. JS-rendered, login-gated, WAF-blocked, and screenshot-bearing sources all belong here rather than in the web lane. **Provenance is part of the claim**: when a source came back with `provenance` of `snapshot` (an archive copy), cite it with its `snapshot_timestamp` and never state it as the current live page; content from a `proxy` route is `untrusted` and needs a second independent route before any claim rests on it. When one blocked territory hides many leads, fan out more browsing subagents in parallel for breadth instead of serializing one worker through them.
 - **Repo deep-dive (librarian), 0-2 workers.** Shallow-clone the most relevant repos to `${TMPDIR:-/tmp}`, pin the HEAD SHA, read core modules, follow call chains, return SHA-pinned permalinks.
 
 Example spawn (codebase axis; librarian, browsing, and repo-dive follow the same contract with their own protocol):
@@ -379,6 +383,7 @@ High-yield combinations: official docs (`site:<docs domain>`), GitHub implementa
 | Obeying a surrounding "stop exploring" rule mid-research | Authority section — those rules do not bind this mode |
 | Asking a worker to write journal or session files | Workers are read-only; you journal every return |
 | Two workers given the same angle | One unique angle per worker, always |
+| A `Browsing: yes` run whose roster carries no browsing worker | The browsing column is binding — name the angle in the brief and spawn it with the first wave, before any lead is chased |
 | Contested claim settled by judgment | Phase 3 — run code, capture output, verdict |
 | Deliverable claims without citations | Every claim cites a source or a verification artifact |
 | Guessing the deliverable format instead of asking | The format gate is unconditional: propose PDF+DOCX plus the domain-fitting alternatives and the template, then wait before wave 1 |

package/dist/skills/visual-qa/AGENTS.md

@@ -0,0 +1,58 @@
+# visual-qa — Bundled Visual-Evidence CLI
+
+**Generated:** 2026-08-24 (f3642fcda)
+
+## OVERVIEW
+
+The visual-QA skill's executable core: a zero-dependency Node CLI that produces machine evidence (`image-diff`, `tui-check`) plus the TypeScript sources it is bundled from. Earned this file: the only shared skill shipping a built bundle whose runtime and development sources must be kept in lockstep.
+
+## STRUCTURE
+
+```
+visual-qa/
+├── SKILL.md                      # reviewer workflow (dual oracle, evidence gates) — the prose contract
+├── references/agent-browser-setup.md
+└── scripts/
+    ├── visual-qa.mjs             # SHIPPED RUNTIME: bun-build bundle of cli.ts (+ embedded modules)
+    ├── cli.ts                    # development source; dispatches image-diff / tui-check
+    ├── image-diff.ts             # diffImages — 8x8 grid cells, hotspots, rounded metrics
+    ├── tui-grid.ts               # checkTui — column overflow + border alignment verdicts
+    ├── east-asian-width.ts       # charWidth / stringWidth — CJK-aware width math
+    ├── ansi.ts                   # ANSI escape stripping (width must be escape-aware)
+    ├── png-decode.ts / png-crc.ts / png-synth.ts   # stdlib PNG codec (no deps)
+    ├── types.ts
+    └── *.test.ts                 # co-located bun tests for every module above
+```
+
+## BUNDLE/SOURCE DUALITY
+
+`visual-qa.mjs` is the artifact the skill's commands invoke (`node "$SKILL_DIR/scripts/visual-qa.mjs" …`); the `.ts` files exist for development and tests only. A behavior fix lands in the TS source AND the bundle is regenerated from `cli.ts` — editing one without the other makes tests and runtime disagree. Never hand-edit the `.mjs`.
+
+## SURFACE
+
+- Commands: `image-diff <reference.png> <actual.png>` and `tui-check <capture.txt> --cols <N>`; JSON verdict output (hotspot cells, overflow lines, wide-char columns, border alignment).
+- Module exports: `diffImages`, `checkTui`, `charWidth`/`stringWidth`, ANSI + PNG helpers. `cli.ts` owns `CliError`, `parseColumns`, `run`, `main`.
+
+## CONVENTIONS
+
+- Zero runtime dependencies — PNG decode/synthesis and ANSI handling are hand-rolled in `scripts/`; keep it that way (the bundle must stay require-free apart from `node:` builtins).
+- Width is never `String.length`: CJK wide characters and ANSI escapes are accounted for before any column math.
+- Tests are co-located `bun test scripts/*.test.ts`, given/when/then style per repo convention.
+
+## ANTI-PATTERNS
+
+- NEVER hand-edit `visual-qa.mjs`; regenerate from source.
+- Don't add an npm dependency to make PNG/diff easier — the no-dep bundle is the point.
+- Column math that ignores CJK width or ANSI escapes is wrong by construction; `tui-check` exists because text-diff tools get terminal grids wrong.
+- Skill-level rule worth repeating for code changes: `tmux capture-pane` is forbidden as a capture mechanism.
+
+## COMMANDS
+
+```bash
+# from packages/shared-skills/skills/visual-qa/
+node scripts/visual-qa.mjs image-diff <reference.png> <actual.png>
+node scripts/visual-qa.mjs tui-check <capture.txt> --cols 80
+bun test scripts/*.test.ts
+```
+
+- Parent: [`packages/shared-skills/AGENTS.md`](../../AGENTS.md).

package/dist/skills/visual-qa/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: visual-qa
-description: "MUST USE after building/changing any UI or when asked whether a page, component, or TUI looks right. Rigorous visual QA across web/page and terminal UIs. Prefer browser:control-in-app-browser for unauthenticated browser/page QA in Codex, then Playwright/agent-browser/dev-browser. Captures screenshot/TUI evidence with bundled diff scripts, runs design-system/functional and visual-fidelity/CJK reviewer passes, then synthesizes a good/bad verdict. Triggers: visual QA, screenshot/pixel diff, UI looks wrong, reference fidelity, design system check, responsive check, CJK text clipping, TUI alignment, box-drawing drift."
+description: "Runs rigorous visual QA across web, terminal, and paginated surfaces with screenshot evidence and a verdict. Use for any UI build or change, or when asked whether a page, component, or TUI looks right."
 ---
 
 # Visual QA - Dual-Oracle Web and TUI Verification
@@ -9,7 +9,7 @@ Verify a rendered UI against intent using objective script evidence plus two par
 
 ## Purpose and when to use
 
-- Use after you build or change any UI, before calling it done. Covers web/page UIs and TUI/terminal UIs.
+- Use after you build or change any UI, before calling it done. Covers web/page UIs, TUI/terminal UIs, and paginated documents.
 - Use when output must match a mock, a baseline, or a stated design intent; when you suspect a regression; when CJK (Korean/Japanese/Chinese) text may clip, misalign, or wrap awkwardly; when a claimed design system might actually be a flat image; when a terminal layout may overflow or its borders may break.
 - Skip when there is no rendered surface (pure backend or library logic with no visual or terminal output). For broad post-implementation review use review-work; this skill is the visual specialist.
 
@@ -19,6 +19,7 @@ In the commands below, `$SKILL_DIR` is this skill's own directory (the folder co
 
 - Web/page UI: renders in a browser (HTML/CSS/JS, components, canvas, SVG). Evidence is screenshots.
 - TUI/terminal UI: renders as text in a terminal (box-drawing, panes, status lines, REPL/TUI apps). Evidence is terminal captures.
+- Paginated document: renders as ordered pages (PDF report, printed HTML, exported deck). Evidence is every page rendered to an image - `pdftoppm -png -r 150 <file>.pdf <prefix>` or the pipeline's own renderer. Extracted text is not evidence here: layout is exactly what extraction discards, so a stranded block, a split table, or a near-empty page survives a clean text check.
 - Reference-fidelity UI: any web/page UI built from a concrete reference packet, including screenshots, generated Imagen/Stitch mockups, Figma exports, overview text, annotations, or source-site captures. Evidence is the full reference packet plus same-size actual captures.
 
 If the change touches both, run both capture tracks and feed both into the passes.
@@ -48,7 +49,7 @@ Before any reviewer sees an image, verify each capture yourself: the file signat
 ### Web
 
 1. Capture a REFERENCE image: the user's mock/target, generated page snapshot, Figma export, source-site capture, or known-good baseline. Save as PNG. If the user provided overview text or annotations, save them next to the image and treat them as part of the reference packet.
-2. Capture the ACTUAL rendered screenshot at the same viewport size. In Codex, when `browser:control-in-app-browser` is available and the page does not need an authenticated user browser session, use that Browser plugin first for navigation, page state inspection, and screenshots. If it is unavailable or lacks the needed capture action, use the project's configured browser tooling (the playwright, agent-browser, or dev-browser skill). Save as PNG. If none is configured or available, install [agent-browser](https://github.com/vercel-labs/agent-browser) (`npm install -g agent-browser && agent-browser install`) and capture with it — see `$SKILL_DIR/references/agent-browser-setup.md` for the full setup, including how to shoot a fixed-viewport screenshot.
+2. Capture the ACTUAL rendered screenshot at the same viewport size, driving the browser your harness actually has. Where a code cell can reach a browser (`new Bun.WebView()` on a Bun >= 1.4 kernel, otherwise `playwright-core` against the local Chrome), capture in-process: it needs no CLI and returns the PNG path directly. In Codex, `browser:control-in-app-browser` is that in-process surface — use it first unless the page needs an authenticated user browser session. Otherwise use the project's configured browser tooling (the playwright, agent-browser, or dev-browser skill). Save as PNG. If nothing is available, install [agent-browser](https://github.com/vercel-labs/agent-browser) (`bun add -g agent-browser && agent-browser install`) and capture with it — see `$SKILL_DIR/references/agent-browser-setup.md` for the full setup, including how to shoot a fixed-viewport screenshot.
 3. Run the diff and keep the JSON:
 
 ```

package/dist/tools/delegate-task/builtin-categories.d.ts

@@ -2,5 +2,7 @@ import type { CategoryConfig } from "../../config/schema";
 export declare const DEFAULT_CATEGORIES: Record<string, CategoryConfig>;
 export declare const CATEGORY_PROMPT_APPENDS: Record<string, string>;
 export declare const CATEGORY_DESCRIPTIONS: Record<string, string>;
+export declare const CATEGORY_CALLER_GUIDANCE: Record<string, string | undefined>;
 export declare const CATEGORY_PROMPT_APPEND_RESOLVERS: Record<string, (model: string | undefined) => string>;
-export declare const BUILTIN_CATEGORY_REQUIRES_MODEL: Record<string, string>;
+export declare const BUILTIN_CATEGORY_REQUIRES_MODEL: Record<string, readonly string[]>;
+export declare function builtinCategoryGateModels(categoryName: string, requirementGateModel: string | undefined): readonly string[];

package/dist/tools/delegate-task/builtin-category-definition.d.ts

@@ -3,7 +3,8 @@ export type BuiltinCategoryDefinition = {
     name: string;
     config: CategoryConfig;
     description: string;
+    callerGuidance?: string;
     promptAppend: string;
     resolvePromptAppend?: (model: string | undefined) => string;
-    requiresModel?: string;
+    requiresModel?: string | readonly string[];
 };

package/dist/tools/delegate-task/constants.d.ts

@@ -1,5 +1,5 @@
 import type { AvailableCategory, AvailableSkill } from "../../agents/dynamic-agent-prompt-builder";
-export { BUILTIN_CATEGORY_REQUIRES_MODEL, CATEGORY_DESCRIPTIONS, CATEGORY_PROMPT_APPENDS, CATEGORY_PROMPT_APPEND_RESOLVERS, DEFAULT_CATEGORIES, } from "./builtin-categories";
+export { BUILTIN_CATEGORY_REQUIRES_MODEL, builtinCategoryGateModels, CATEGORY_DESCRIPTIONS, CATEGORY_PROMPT_APPENDS, CATEGORY_PROMPT_APPEND_RESOLVERS, DEFAULT_CATEGORIES, } from "./builtin-categories";
 /**
  * System prompt prepended to plan agent invocations.
  * Instructs the plan agent to first gather context via explore/librarian agents,
@@ -7,7 +7,7 @@ export { BUILTIN_CATEGORY_REQUIRES_MODEL, CATEGORY_DESCRIPTIONS, CATEGORY_PROMPT
  * Also MANDATES dependency graphs, parallel execution analysis, and category+skill recommendations.
  */
 export declare const PLAN_AGENT_SYSTEM_PREPEND_STATIC_BEFORE_SKILLS = "<system>\nBEFORE you begin planning, you MUST first understand the user's request deeply.\n\nMANDATORY CONTEXT GATHERING PROTOCOL:\n1. Launch background agents to gather context:\n   - call_omo_agent(description=\"Explore codebase patterns\", subagent_type=\"explore\", run_in_background=true, prompt=\"<search for relevant patterns, files, and implementations in the codebase related to user's request>\")\n   - call_omo_agent(description=\"Research documentation\", subagent_type=\"librarian\", run_in_background=true, prompt=\"<search for external documentation, examples, and best practices related to user's request>\")\n\n2. After gathering context, ALWAYS present:\n   - **User Request Summary**: Concise restatement of what the user is asking for\n   - **Uncertainties**: List of unclear points, ambiguities, or assumptions you're making\n   - **Clarifying Questions**: Specific questions to resolve the uncertainties\n\n3. ITERATE until ALL requirements are crystal clear:\n   - Do NOT proceed to planning until you have 100% clarity\n   - Ask the user to confirm your understanding\n   - Resolve every ambiguity before generating the work plan\n\nREMEMBER: Vague requirements lead to failed implementations. Take the time to understand thoroughly.\n</system>\n\n<CRITICAL_REQUIREMENT_DEPENDENCY_PARALLEL_EXECUTION_CATEGORY_SKILLS>\n#####################################################################\n#                                                                   #\n#   \u2588\u2588\u2588\u2588\u2588\u2588\u2557 \u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2557 \u2588\u2588\u2588\u2588\u2588\u2588\u2557 \u2588\u2588\u2557   \u2588\u2588\u2557\u2588\u2588\u2557\u2588\u2588\u2588\u2588\u2588\u2588\u2557 \u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2557\u2588\u2588\u2588\u2588\u2588\u2588\u2557    #\n#   \u2588\u2588\u2554\u2550\u2550\u2588\u2588\u2557\u2588\u2588\u2554\u2550\u2550\u2550\u2550\u255D\u2588\u2588\u2554\u2550\u2550\u2550\u2588\u2588\u2557\u2588\u2588\u2551   \u2588\u2588\u2551\u2588\u2588\u2551\u2588\u2588\u2554\u2550\u2550\u2588\u2588\u2557\u2588\u2588\u2554\u2550\u2550\u2550\u2550\u255D\u2588\u2588\u2554\u2550\u2550\u2588\u2588\u2557   #\n#   \u2588\u2588\u2588\u2588\u2588\u2588\u2554\u255D\u2588\u2588\u2588\u2588\u2588\u2557  \u2588\u2588\u2551   \u2588\u2588\u2551\u2588\u2588\u2551   \u2588\u2588\u2551\u2588\u2588\u2551\u2588\u2588\u2588\u2588\u2588\u2588\u2554\u255D\u2588\u2588\u2588\u2588\u2588\u2557  \u2588\u2588\u2551  \u2588\u2588\u2551   #\n#   \u2588\u2588\u2554\u2550\u2550\u2588\u2588\u2557\u2588\u2588\u2554\u2550\u2550\u255D  \u2588\u2588\u2551\u2584\u2584 \u2588\u2588\u2551\u2588\u2588\u2551   \u2588\u2588\u2551\u2588\u2588\u2551\u2588\u2588\u2554\u2550\u2550\u2588\u2588\u2557\u2588\u2588\u2554\u2550\u2550\u255D  \u2588\u2588\u2551  \u2588\u2588\u2551   #\n#   \u2588\u2588\uFFFD\uFFFD  \u2588\u2588\u2551\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2557\u255A\u2588\u2588\u2588\u2588\u2588\u2588\u2554\u255D\u255A\u2588\u2588\u2588\u2588\u2588\u2588\u2554\u255D\u2588\u2588\u2551\u2588\u2588\u2551  \u2588\u2588\u2551\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2557\u2588\u2588\u2588\u2588\u2588\u2588\u2554\u255D   #\n#   \u255A\u2550\u255D  \u255A\u2550\u255D\u255A\u2550\u2550\u2550\u2550\u2550\u2550\u255D \u255A\u2550\u2550\u2580\u2580\u2550\u255D  \u255A\u2550\u2550\u2550\u2550\u2550\u255D \u255A\u2550\u255D\u255A\u2550\u255D  \u255A\u2550\u255D\u255A\u2550\u2550\u2550\u2550\u2550\u2550\u255D\u255A\u2550\u2550\u2550\u2550\u2550\u255D    #\n#                                                                   #\n#####################################################################\n\nYOU MUST INCLUDE THE FOLLOWING SECTIONS IN YOUR PLAN OUTPUT.\nTHIS IS NON-NEGOTIABLE. FAILURE TO INCLUDE THESE SECTIONS = INCOMPLETE PLAN.\n\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\u2588 SECTION 1: TASK DEPENDENCY GRAPH (MANDATORY)                    \u2588\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\nYOU MUST ANALYZE AND DOCUMENT TASK DEPENDENCIES.\n\nFor EVERY task in your plan, you MUST specify:\n- Which tasks it DEPENDS ON (blockers)\n- Which tasks DEPEND ON IT (dependents)\n- The REASON for each dependency\n\nExample format:\n```\n## Task Dependency Graph\n\n| Task | Depends On | Reason |\n|------|------------|--------|\n| Task 1 | None | Starting point, no prerequisites |\n| Task 2 | Task 1 | Requires output/artifact from Task 1 |\n| Task 3 | Task 1 | Uses same foundation established in Task 1 |\n| Task 4 | Task 2, Task 3 | Integrates results from both tasks |\n```\n\nWHY THIS MATTERS:\n- Executors need to know execution ORDER\n- Prevents blocked work from starting prematurely\n- Identifies critical path for project timeline\n\n\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\u2588 SECTION 2: PARALLEL EXECUTION GRAPH (MANDATORY)                 \u2588\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\nYOU MUST IDENTIFY WHICH TASKS CAN RUN IN PARALLEL.\n\nAnalyze your dependency graph and group tasks into PARALLEL EXECUTION WAVES:\n\nExample format:\n```\n## Parallel Execution Graph\n\nWave 1 (Start immediately):\n\u251C\u2500\u2500 Task 1: [description] (no dependencies)\n\u2514\u2500\u2500 Task 5: [description] (no dependencies)\n\nWave 2 (After Wave 1 completes):\n\u251C\u2500\u2500 Task 2: [description] (depends: Task 1)\n\u251C\u2500\u2500 Task 3: [description] (depends: Task 1)\n\u2514\u2500\u2500 Task 6: [description] (depends: Task 5)\n\nWave 3 (After Wave 2 completes):\n\u2514\u2500\u2500 Task 4: [description] (depends: Task 2, Task 3)\n\nCritical Path: Task 1 \u2192 Task 2 \u2192 Task 4\nEstimated Parallel Speedup: 40% faster than sequential\n```\n\nWHY THIS MATTERS:\n- MASSIVE time savings through parallelization\n- Executors can dispatch multiple agents simultaneously\n- Identifies bottlenecks in the execution plan\n\n\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\u2588 SECTION 3: CATEGORY + SKILLS RECOMMENDATIONS (MANDATORY)        \u2588\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\nFOR EVERY TASK, YOU MUST RECOMMEND:\n1. Which CATEGORY to use for delegation\n2. Which SKILLS to load for the delegated agent\n";
-export declare const PLAN_AGENT_SYSTEM_PREPEND_STATIC_AFTER_SKILLS = "### REQUIRED OUTPUT FORMAT\n\nFor EACH task, include a recommendation block:\n\n```\n### Task N: [Task Title]\n\n**Delegation Recommendation:**\n- Category: `[category-name]` - [reason for choice]\n- Skills: [`skill-1`, `skill-2`] - [reason each skill is needed]\n\n**Skills Evaluation:**\n- INCLUDED `skill-name`: [reason]\n- OMITTED `other-skill`: [reason domain doesn't overlap]\n```\n\nWHY THIS MATTERS:\n- Category determines the MODEL used for execution\n- Skills inject SPECIALIZED KNOWLEDGE into the executor\n- Missing a relevant skill = suboptimal execution\n- Wrong category = wrong model = poor results\n\n\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\u2588 RESPONSE FORMAT SPECIFICATION (MANDATORY)                       \u2588\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\nYOUR PLAN OUTPUT MUST FOLLOW THIS EXACT STRUCTURE:\n\n```markdown\n# [Plan Title]\n\n## Context\n[User request summary, interview findings, research results]\n\n## Task Dependency Graph\n[Dependency table - see Section 1]\n\n## Parallel Execution Graph  \n[Wave structure - see Section 2]\n\n## Tasks\n\n### Task 1: [Title]\n**Description**: [What to do]\n**Delegation Recommendation**:\n- Category: `[category]` - [reason]\n- Skills: [`skill-1`] - [reason]\n**Skills Evaluation**: [\u2705 included / \u274C omitted with reasons]\n**Depends On**: [Task IDs or \"None\"]\n**Acceptance Criteria**: [Verifiable conditions]\n\n### Task 2: [Title]\n[Same structure...]\n\n## Commit Strategy\n[How to commit changes atomically]\n\n## Success Criteria\n[Final verification steps]\n```\n\n#####################################################################\n#                                                                   #\n#   FAILURE TO INCLUDE THESE SECTIONS = PLAN WILL BE REJECTED      #\n#   BY MOMUS REVIEW. DO NOT SKIP. DO NOT ABBREVIATE.               #\n#                                                                   #\n#####################################################################\n</CRITICAL_REQUIREMENT_DEPENDENCY_PARALLEL_EXECUTION_CATEGORY_SKILLS>\n\n<FINAL_OUTPUT_FOR_CALLER>\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\u2588 SECTION 4: ACTIONABLE TODO LIST FOR CALLER (MANDATORY)          \u2588\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\nYOU MUST END YOUR RESPONSE WITH THIS SECTION.\n\n```markdown\n## TODO List (ADD THESE)\n\n> CALLER: Add these TODOs using TodoWrite/TaskCreate and execute by wave.\n\n### Wave 1 (Start Immediately - No Dependencies)\n\n- [ ] **1. [Task Title]**\n  - What: [Clear implementation steps]\n  - Depends: None\n  - Blocks: [Tasks that depend on this]\n  - Category: `category-name`\n  - Skills: [`skill-1`, `skill-2`]\n  - QA: [How to verify completion - specific command or check]\n\n- [ ] **N. [Task Title]**\n  - What: [Steps]\n  - Depends: None\n  - Blocks: [...]\n  - Category: `category-name`\n  - Skills: [`skill-1`]\n  - QA: [Verification]\n\n### Wave 2 (After Wave 1 Completes)\n\n- [ ] **2. [Task Title]**\n  - What: [Steps]\n  - Depends: 1\n  - Blocks: [4]\n  - Category: `category-name`\n  - Skills: [`skill-1`]\n  - QA: [Verification]\n\n[Continue for all waves...]\n\n## Execution Instructions\n\n1. **Wave 1**: Fire these tasks IN PARALLEL (no dependencies)\n   ```\n   task(category=\"...\", load_skills=[...], run_in_background=false, prompt=\"Task 1: ...\")\n   task(category=\"...\", load_skills=[...], run_in_background=false, prompt=\"Task N: ...\")\n   ```\n\n2. **Wave 2**: After Wave 1 completes, fire next wave IN PARALLEL\n   ```\n   task(category=\"...\", load_skills=[...], run_in_background=false, prompt=\"Task 2: ...\")\n   ```\n\n3. Continue until all waves complete\n\n4. Final QA: Verify all tasks pass their QA criteria\n```\n\nWHY THIS FORMAT IS MANDATORY:\n- Caller can directly copy TODO items\n- Wave grouping enables parallel execution\n- Each task has clear task parameters\n- QA criteria ensure verifiable completion\n</FINAL_OUTPUT_FOR_CALLER>\n\n<DELIVERABLE_ENVELOPE>\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\u2588 MANDATORY: WRAP YOUR ENTIRE PLAN IN A <plan> ENVELOPE           \u2588\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\nYour FINAL message MUST wrap the ENTIRE plan \u2014 from the title line\nthrough the closing TODO list \u2014 inside a single pair of tags:\n\n<plan>\n# [Plan Title]\n... full plan: all mandatory sections AND the TODO list ...\n</plan>\n\nRULES:\n- Emit EXACTLY ONE <plan> ... </plan> block, and only in your FINAL message.\n- Open with <plan> on its own line BEFORE the title; close with </plan>\n  on its own line AFTER the TODO list. Everything the caller needs goes inside.\n- Do NOT emit <plan> while still gathering context. Progress messages,\n  clarifying questions, and \"exploring...\" turns MUST NOT contain it \u2014 the\n  envelope is how the caller tells your real deliverable apart from those turns.\n- The caller extracts the contents of this envelope verbatim. Anything emitted\n  outside the envelope may be discarded.\n</DELIVERABLE_ENVELOPE>\n\n";
+export declare const PLAN_AGENT_SYSTEM_PREPEND_STATIC_AFTER_SKILLS = "### REQUIRED OUTPUT FORMAT\n\nFor EACH task, include a recommendation block:\n\n```\n### Task N: [Task Title]\n\n**Delegation Recommendation:**\n- Category: `[category-name]` - [reason for choice]\n- Skills: [`skill-1`, `skill-2`] - [reason each skill is needed]\n\n**Skills Evaluation:**\n- INCLUDED `skill-name`: [reason]\n- OMITTED `other-skill`: [reason domain doesn't overlap]\n```\n\nWHY THIS MATTERS:\n- Category determines the MODEL used for execution\n- Skills inject SPECIALIZED KNOWLEDGE into the executor\n- Missing a relevant skill = suboptimal execution\n- Wrong category = wrong model = poor results\n\n\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\u2588 RESPONSE FORMAT SPECIFICATION (MANDATORY)                       \u2588\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\nYOUR PLAN OUTPUT MUST FOLLOW THIS EXACT STRUCTURE:\n\n```markdown\n# [Plan Title]\n\n## Context\n[User request summary, interview findings, research results]\n\n## Task Dependency Graph\n[Dependency table - see Section 1]\n\n## Parallel Execution Graph  \n[Wave structure - see Section 2]\n\n## Tasks\n\n### Task 1: [Title]\n**Description**: [What to do]\n**Delegation Recommendation**:\n- Category: `[category]` - [reason]\n- Skills: [`skill-1`] - [reason]\n**Skills Evaluation**: [\u2705 included / \u274C omitted with reasons]\n**Depends On**: [Task IDs or \"None\"]\n**Acceptance Criteria**: [Verifiable conditions]\n\n### Task 2: [Title]\n[Same structure...]\n\n## Commit Strategy\n[How to commit changes atomically]\n\n## Success Criteria\n[Final verification steps]\n```\n\n#####################################################################\n#                                                                   #\n#   FAILURE TO INCLUDE THESE SECTIONS = PLAN WILL BE REJECTED      #\n#   BY MOMUS REVIEW. DO NOT SKIP. DO NOT ABBREVIATE.               #\n#                                                                   #\n#####################################################################\n</CRITICAL_REQUIREMENT_DEPENDENCY_PARALLEL_EXECUTION_CATEGORY_SKILLS>\n\n<FINAL_OUTPUT_FOR_CALLER>\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\u2588 SECTION 4: ACTIONABLE TODO LIST FOR CALLER (MANDATORY)          \u2588\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\nYOU MUST END YOUR RESPONSE WITH THIS SECTION.\n\n```markdown\n## TODO List (ADD THESE)\n\n> CALLER: Add these TODOs using TodoWrite/TaskCreate and execute by wave.\n\n### Wave 1 (Start Immediately - No Dependencies)\n\n- [ ] **1. [Task Title]**\n  - What: [Clear implementation steps]\n  - Depends: None\n  - Blocks: [Tasks that depend on this]\n  - Category: `category-name`\n  - Skills: [`skill-1`, `skill-2`]\n  - QA: [How to verify completion - specific command or check]\n\n- [ ] **N. [Task Title]**\n  - What: [Steps]\n  - Depends: None\n  - Blocks: [...]\n  - Category: `category-name`\n  - Skills: [`skill-1`]\n  - QA: [Verification]\n\n### Wave 2 (After Wave 1 Completes)\n\n- [ ] **2. [Task Title]**\n  - What: [Steps]\n  - Depends: 1\n  - Blocks: [4]\n  - Category: `category-name`\n  - Skills: [`skill-1`]\n  - QA: [Verification]\n\n[Continue for all waves...]\n\n## Execution Instructions\n\n1. **Wave 1**: Fire these tasks IN PARALLEL (no dependencies)\n   ```\n   task(category=\"...\", load_skills=[...], run_in_background=true, prompt=\"Task 1: ...\")\n   task(category=\"...\", load_skills=[...], run_in_background=true, prompt=\"Task N: ...\")\n   ```\n\n2. **Wave 2**: After Wave 1 completes, fire next wave IN PARALLEL\n   ```\n   task(category=\"...\", load_skills=[...], run_in_background=true, prompt=\"Task 2: ...\")\n   ```\n\n3. Continue until all waves complete\n\n4. Final QA: Verify all tasks pass their QA criteria\n```\n\nWHY THIS FORMAT IS MANDATORY:\n- Caller can directly copy TODO items\n- Wave grouping enables parallel execution\n- Each task has clear task parameters\n- QA criteria ensure verifiable completion\n</FINAL_OUTPUT_FOR_CALLER>\n\n<DELIVERABLE_ENVELOPE>\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\u2588 MANDATORY: WRAP YOUR ENTIRE PLAN IN A <plan> ENVELOPE           \u2588\n\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\u2550\n\nYour FINAL message MUST wrap the ENTIRE plan \u2014 from the title line\nthrough the closing TODO list \u2014 inside a single pair of tags:\n\n<plan>\n# [Plan Title]\n... full plan: all mandatory sections AND the TODO list ...\n</plan>\n\nRULES:\n- Emit EXACTLY ONE <plan> ... </plan> block, and only in your FINAL message.\n- Open with <plan> on its own line BEFORE the title; close with </plan>\n  on its own line AFTER the TODO list. Everything the caller needs goes inside.\n- Do NOT emit <plan> while still gathering context. Progress messages,\n  clarifying questions, and \"exploring...\" turns MUST NOT contain it \u2014 the\n  envelope is how the caller tells your real deliverable apart from those turns.\n- The caller extracts the contents of this envelope verbatim. Anything emitted\n  outside the envelope may be discarded.\n</DELIVERABLE_ENVELOPE>\n\n";
 export declare function buildPlanAgentSkillsSection(categories?: AvailableCategory[], skills?: AvailableSkill[]): string;
 export declare function buildPlanAgentSystemPrepend(categories?: AvailableCategory[], skills?: AvailableSkill[]): string;
 /**

package/dist/tools/delegate-task/openai-categories.d.ts

@@ -1,5 +1,10 @@
 import type { BuiltinCategoryDefinition } from "./builtin-category-definition";
-export declare const DEEP_CATEGORY_PROMPT_APPEND = "<Category_Context>\nYou are working on GOAL-ORIENTED AUTONOMOUS tasks.\n\nYou are NOT an interactive assistant. You are an autonomous problem-solver.\n\nBEFORE making ANY changes:\n1. Silently explore the codebase extensively (5-15 minutes of reading is normal)\n2. Read related files, trace dependencies, understand the full context\n3. Build a complete mental model of the problem space\n4. Do not ask clarifying questions - the goal is already defined\n\nYou receive a GOAL. When the goal includes numbered steps or phases, treat them as one atomic task broken into sub-steps, not as separate independent tasks. Figure out HOW to achieve it yourself. Thorough research before any action.\n\nSub-steps of ONE goal = execute all steps as phases of one atomic task.\nGenuinely independent tasks = flag and refuse, require separate delegations.\n\nApproach: explore extensively, understand deeply, then act decisively. Prefer comprehensive solutions over quick patches. If the goal is unclear, make reasonable assumptions and proceed.\n\nMinimal status updates. Focus on results, not play-by-play. Report completion with summary of changes.\n</Category_Context>";
-export declare const DEEP_CATEGORY_PROMPT_APPEND_GPT_5_5 = "<Category_Context name=\"deep\">\nYou are operating in DEEP mode. This is the category reserved for goal-oriented autonomous work on hairy problems that reward thorough exploration and comprehensive solutions.\n\nThe orchestrator chose this category because the task benefits from depth over speed. You should feel empowered to spend the time needed: five to fifteen minutes of silent exploration before the first edit is normal and correct. Rushing to implementation on a deep task is a failure mode, not a feature.\n\n# How deep mode adjusts the base behavior\n\n**Exploration budget: generous.** Read the files you need, trace dependencies both directions, fire 2-5 explore/librarian sub-agents in parallel for broader questions. Build a complete mental model before the first `apply_patch`. Exploration here is an investment, not overhead.\n\n**Goal, not plan.** You receive a GOAL describing the desired outcome. You figure out HOW to achieve it. The orchestrator deliberately did not hand you a step-by-step plan; producing one and asking for approval is not what was asked. Execute.\n\n**Atomic task treatment.** When the goal contains numbered steps or phases, treat them as sub-steps of ONE task and execute them all in this turn. Splitting them across turns is wrong unless they reveal an architectural blocker that requires the user's input. If the \"steps\" turn out to be genuinely independent tasks that should have been separate delegations, flag that in your final message and refuse the ones beyond scope.\n\n**Root cause bias.** Prefer root-cause fixes over symptom fixes. A null check around `foo()` is a symptom fix; fixing whatever causes `foo()` to return unexpected values is the root fix. Trace at least two levels up before settling on an answer. In deep mode, you have permission (and the expectation) to do the deeper fix.\n\n**Ambition scaled to context.** For brand-new greenfield work, be ambitious. Choose strong defaults, avoid AI-slop aesthetics, produce something you would be proud to hand to another senior engineer. For changes in an existing codebase, be surgical and respect the existing patterns; depth does not mean invasiveness.\n\n**Completion bar: full delivery.** \"Simplified version\", \"proof of concept\", and \"you can extend this later\" are not acceptable deliveries for a deep task. The orchestrator routed here specifically for a complete solution. If you hit a genuine blocker (missing secret, design decision only the user can make, three materially different attempts all failed), document it and return; otherwise, finish the task.\n\n**Status cadence: sparse.** The user is not on the other side of this conversation; the orchestrator is, and they will synthesize your progress. Send commentary only at meaningful phase transitions (starting exploration, starting implementation, starting verification, hitting a genuine blocker). Do not narrate every tool call; silence during focused work is expected.\n</Category_Context>";
+export declare const ULTRABRAIN_CATEGORY_PROMPT_APPEND_GPT_6_ASTRA = "<Category_Context name=\"ultrabrain\">\nThe orchestrator routed this task here because it is the one genuinely hard, logic-heavy problem in its plan, and it sent a goal rather than steps: choose the approach yourself, and let correctness outrank speed, brevity, and token cost.\n\nSuccess means:\n- every load-bearing claim cites evidence from this turn: a file and line read, a command run, a test executed;\n- every executable claim was executed: a proposed fix runs, an algorithm passes the boundary cases you enumerated, a verdict on a diff names the failing line;\n- the conclusion survived your own attempt to break it, and the answer names the strongest counter-case you looked for;\n- rejected alternatives carry the reason that decided against them, and open assumptions are stated so the orchestrator can overturn them;\n- one decision-complete recommendation, actionable without a follow-up question.\n\nWhatever that check leaves unsettled goes in the answer as an open question with what would settle it. When the goal bundles independent problems, solve the one the others depend on and return the rest as separately delegable items.\n</Category_Context>";
+export declare const DEEP_CATEGORY_PROMPT_APPEND_GPT_6_ASTRA = "<Category_Context name=\"deep\">\nThe orchestrator routed this task here for depth: one goal, one deliverable, and the time to earn it. The exploration budget is generous: read every file involved, trace callers and dependencies in both directions, and fan out explore and librarian subagents in parallel for the questions a single read wave cannot answer, until you can explain the full mechanism you are about to change; an edit made before that point is the failure this category exists to prevent.\n\n**MUST USE `deep` FOR 3D GRAPHICS, COMPUTER USE, BROWSER USE, BACKEND, LOGIC, ALGORITHMS, CAPTCHA SOLVING, AND MULTIMODAL WORK.**\n\nThe goal is the authorization. Choose how to reach it yourself, and when it lists numbered steps or phases, deliver all of them in this turn as one task; a proposal, a plan awaiting approval, a simplified version, or a proof of concept is unfinished work. When the steps turn out to be independent problems sharing no reasoning, do the one the goal centers on and return the others as separately delegable items with what you learned. A question ends your turn and hands the task back unfinished, so decide from context, record each assumption in the final message, and stop early only for a blocker you cannot route around: a missing secret, a decision only the user can make, or three materially different attempts that all failed.\n\nFix the cause: trace at least two levels above the symptom before settling, and prefer the change that makes the failure impossible over the guard that hides it. Depth means understanding the mechanism, so the diff stays as small as the fix allows; on greenfield work choose strong defaults and finish something you would hand to a senior engineer. Close with the delivered change, the evidence that it works, and the assumptions you made.\n</Category_Context>";
+export declare const UNSPECIFIED_HIGH_CATEGORY_PROMPT_APPEND_GPT_6_ASTRA = "<Category_Context name=\"unspecified-high\">\nThe orchestrator routed this task here because it spans systems or modules and fits no specialist category, so breadth of consideration is what this category buys. Before committing to an approach, survey the whole surface the change touches: every caller and consumer of what you will modify, sibling modules that implement the same pattern, the tests, docs, schemas, config, scripts, and CI that encode the current behavior, and the history of the area (git log and blame) for the reasons it is shaped this way. Fan out explore and librarian subagents in parallel when that surface is wider than one read wave covers.\n\nWeigh at least two ways to do it against what you found, choose one, and say in the final message why it won. Then deliver it across every surface you identified, so behavior stays consistent everywhere the change is observable and no caller, test, doc, schema, or config still describes the old state. A question ends your turn and hands the task back unfinished, so decide from context, record each assumption in the final message, and finish.\n</Category_Context>";
+export declare const DEEP_CATEGORY_PROMPT_APPEND = "<Category_Context>\nYou are working on GOAL-ORIENTED AUTONOMOUS tasks.\n\nYou are NOT an interactive assistant. You are an autonomous problem-solver.\n\n**MUST USE `deep` FOR 3D GRAPHICS, COMPUTER USE, BROWSER USE, BACKEND, LOGIC, ALGORITHMS, CAPTCHA SOLVING, AND MULTIMODAL WORK.**\n\nBEFORE making ANY changes:\n1. Silently explore the codebase extensively (5-15 minutes of reading is normal)\n2. Read related files, trace dependencies, understand the full context\n3. Build a complete mental model of the problem space\n4. Do not ask clarifying questions - the goal is already defined\n\nYou receive a GOAL. When the goal includes numbered steps or phases, treat them as one atomic task broken into sub-steps, not as separate independent tasks. Figure out HOW to achieve it yourself. Thorough research before any action.\n\nSub-steps of ONE goal = execute all steps as phases of one atomic task.\nGenuinely independent tasks = flag and refuse, require separate delegations.\n\nApproach: explore extensively, understand deeply, then act decisively. Prefer comprehensive solutions over quick patches. If the goal is unclear, make reasonable assumptions and proceed.\n\nMinimal status updates. Focus on results, not play-by-play. Report completion with summary of changes.\n</Category_Context>";
+export declare const DEEP_CATEGORY_PROMPT_APPEND_GPT_5_5 = "<Category_Context name=\"deep\">\nYou are operating in DEEP mode. This is the category reserved for goal-oriented autonomous work on hairy problems that reward thorough exploration and comprehensive solutions.\n\n**MUST USE `deep` FOR 3D GRAPHICS, COMPUTER USE, BROWSER USE, BACKEND, LOGIC, ALGORITHMS, CAPTCHA SOLVING, AND MULTIMODAL WORK.**\n\nThe orchestrator chose this category because the task benefits from depth over speed. You should feel empowered to spend the time needed: five to fifteen minutes of silent exploration before the first edit is normal and correct. Rushing to implementation on a deep task is a failure mode, not a feature.\n\n# How deep mode adjusts the base behavior\n\n**Exploration budget: generous.** Read the files you need, trace dependencies both directions, fire 2-5 explore/librarian sub-agents in parallel for broader questions. Build a complete mental model before the first `apply_patch`. Exploration here is an investment, not overhead.\n\n**Goal, not plan.** You receive a GOAL describing the desired outcome. You figure out HOW to achieve it. The orchestrator deliberately did not hand you a step-by-step plan; producing one and asking for approval is not what was asked. Execute.\n\n**Atomic task treatment.** When the goal contains numbered steps or phases, treat them as sub-steps of ONE task and execute them all in this turn. Splitting them across turns is wrong unless they reveal an architectural blocker that requires the user's input. If the \"steps\" turn out to be genuinely independent tasks that should have been separate delegations, flag that in your final message and refuse the ones beyond scope.\n\n**Root cause bias.** Prefer root-cause fixes over symptom fixes. A null check around `foo()` is a symptom fix; fixing whatever causes `foo()` to return unexpected values is the root fix. Trace at least two levels up before settling on an answer. In deep mode, you have permission (and the expectation) to do the deeper fix.\n\n**Ambition scaled to context.** For brand-new greenfield work, be ambitious. Choose strong defaults, avoid AI-slop aesthetics, produce something you would be proud to hand to another senior engineer. For changes in an existing codebase, be surgical and respect the existing patterns; depth does not mean invasiveness.\n\n**Completion bar: full delivery.** \"Simplified version\", \"proof of concept\", and \"you can extend this later\" are not acceptable deliveries for a deep task. The orchestrator routed here specifically for a complete solution. If you hit a genuine blocker (missing secret, design decision only the user can make, three materially different attempts all failed), document it and return; otherwise, finish the task.\n\n**Status cadence: sparse.** The user is not on the other side of this conversation; the orchestrator is, and they will synthesize your progress. Send commentary only at meaningful phase transitions (starting exploration, starting implementation, starting verification, hitting a genuine blocker). Do not narrate every tool call; silence during focused work is expected.\n</Category_Context>";
+export declare function resolveUltrabrainCategoryPromptAppend(model: string | undefined): string;
 export declare function resolveDeepCategoryPromptAppend(model: string | undefined): string;
+export declare function resolveUnspecifiedHighCategoryPromptAppend(model: string | undefined): string;
 export declare const OPENAI_CATEGORIES: BuiltinCategoryDefinition[];

package/dist/tools/delegate-task/sync-session-cleanup.d.ts

@@ -0,0 +1,3 @@
+import type { OpencodeClient } from "./types";
+export declare function cancelSyncSessionDeletion(sessionID: string): void;
+export declare function scheduleSyncSessionDeletion(client: OpencodeClient, sessionID: string, delayMs?: number): void;

package/dist/tools/delegate-task/sync-session-poller.d.ts

@@ -8,6 +8,7 @@ export declare function pollSyncSession(ctx: ToolContextWithMetadata, client: Op
     } | null | undefined;
     taskId: string | undefined;
     anchorMessageCount?: number;
+    anchorMessageID?: string;
     maxAssistantTurns?: number;
     hasActiveChildBackgroundTasks?: (sessionID: string) => boolean;
     hasPendingParentWake?: (sessionID: string) => boolean;

package/dist/tools/delegate-task/tool-description.d.ts

@@ -6,4 +6,6 @@ export interface DelegateTaskPresentation {
     categoryExamples: string;
     description: string;
 }
-export declare function createDelegateTaskPresentation(options: DelegateTaskToolOptions): DelegateTaskPresentation;
+type DelegateTaskPresentationOptions = Pick<DelegateTaskToolOptions, "availableCategories" | "availableSkills" | "userCategories">;
+export declare function createDelegateTaskPresentation(options: DelegateTaskPresentationOptions): DelegateTaskPresentation;
+export {};

package/dist/tools/delegate-task/types.d.ts

@@ -1,4 +1,5 @@
 import type { BackgroundManager } from "../../features/background-agent";
+import type { OhMyOpenCodeConfig } from "../../config";
 import type { CategoriesConfig, GitMasterConfig, BrowserAutomationProvider, AgentOverrides, SisyphusAgentConfig } from "../../config/schema";
 import type { ModelFallbackControllerAccessor } from "../../hooks/model-fallback";
 import type { LoadedSkill } from "../../features/opencode-skill-loader/types";
@@ -45,6 +46,7 @@ export interface OmoAgentClient {
     };
     readonly session: {
         readonly abort: (input: SessionPathInput) => Promise<unknown>;
+        readonly delete?: (input: SessionPathInput) => Promise<unknown>;
         readonly create: (input: {
             readonly body: Record<string, unknown>;
             readonly query?: {
@@ -119,6 +121,8 @@ export interface DelegateTaskToolOptions {
     availableCategories?: AvailableCategory[];
     availableSkills?: AvailableSkill[];
     agentOverrides?: AgentOverrides;
+    /** Reload model-bearing config at task invocation time so edits are honored without rebuilding tools. */
+    loadCurrentModelConfig?: () => Pick<OhMyOpenCodeConfig, "agents" | "categories">;
     sisyphusAgentConfig?: SisyphusAgentConfig;
     modelFallbackControllerAccessor?: ModelFallbackControllerAccessor;
     onSyncSessionCreated?: (event: SyncSessionCreatedEvent) => Promise<void>;

package/dist/tools/session-manager/directory-filter.d.ts

@@ -0,0 +1,2 @@
+export declare function normalizeSessionDirectory(directory: string): string;
+export declare function sessionDirectoriesMatch(stored: string, filter: string): boolean;

package/dist/tui.d.ts

@@ -1,4 +1,16 @@
 import type { TuiPluginModule } from "@opencode-ai/plugin/tui";
+type SidebarSlotRegistration<Node> = {
+    readonly order: number;
+    readonly slots: {
+        readonly sidebar_content: () => Node | (() => Node);
+    };
+};
+type RegisterSidebarContentSlotInput<Node> = {
+    readonly registerSlot: (registration: SidebarSlotRegistration<Node>) => void;
+    readonly requestRender: () => void;
+    readonly renderSidebar: () => Node;
+};
+export declare function registerSidebarContentSlot<Node>({ registerSlot, requestRender, renderSidebar, }: RegisterSidebarContentSlotInput<Node>): void;
 export declare function handleTuiPollError(error: unknown, reportPollError?: (error: Error) => void): void;
 declare const module: TuiPluginModule;
 export default module;