npm - oh-my-opencode - Versions diffs - 5.0.0-beta.40 → 5.0.0-beta.43 - Mend

oh-my-opencode 5.0.0-beta.40 → 5.0.0-beta.43

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (139) hide show

package/dist/skills/ultimate-browsing/ATTRIBUTION.md CHANGED Viewed

@@ -103,7 +103,7 @@ SOFTWARE.
 ## 4. agent-browser (vercel-labs) — Tier-2 CDP automation CLI (runtime dependency)
 The Tier-2 automation CLI is **agent-browser**, installed at runtime via `npm`
-(`npm i -g agent-browser`). No agent-browser source is vendored in this repository.
+(`bun add -g agent-browser`). No agent-browser source is vendored in this repository.
 - Source: https://github.com/vercel-labs/agent-browser
 - Pinned runtime version: **0.34.0** (documented in `references/chrome-stealth.md`;

package/dist/skills/ultimate-browsing/SKILL.md CHANGED Viewed

@@ -1,13 +1,13 @@
 ---
 name: ultimate-browsing
-description: "Escalation skill for blocked or hard-to-reach web access — load it when a normal browse/fetch is blocked (WAF, 403, Cloudflare, JS-only render, login-gated, or a platform a generic fetcher cannot read). Tiered router: TIER 1 insane-search (headless extraction + WAF bypass via curl_cffi TLS impersonation, yt-dlp, Jina Reader, public APIs, Playwright real-Chrome fallback); TIER 1.5 agent-reach (platform-native readers for Chinese and social platforms: Xiaohongshu, Douyin, Weibo, Bilibili, V2EX, WeChat, plus Twitter/Reddit/LinkedIn/GitHub); TIER 2 Chrome stealth (CloakBrowser stealth Chromium + agent-browser CDP for clicks, forms, screenshots, video, cookie login). Triggers: blocked site, bypass bot detection, cloudflare/WAF bypass, scrape, stealth browser, import cookies, fill form, screenshot, play youtube, xiaohongshu, douyin, weibo, bilibili, v2ex, wechat article, podcast transcript. NOT for simple searches (use web-search) or plain fetches (use webfetch)."
+description: "Reaches web pages a plain fetch cannot: renders JS, drives clicks and forms, captures screenshots, holds a login, and gets past WAF blocks through platform-native readers and stealth Chrome. Use for any page work beyond retrieving static text."
 ---
 # Ultimate Browsing
-Escalation web access for tasks a normal browse or fetch cannot complete. Reach for this skill the moment a page is blocked (WAF / 403 / Cloudflare), needs JS rendering, hides behind a login, or lives on a platform a generic fetcher cannot read. Escalate only when the cheaper tier cannot do the job:
+Web access for everything a plain fetch cannot finish: a page that renders in JS, a click or a form, a screenshot, a login that must persist across pages, or a host that blocks generic fetchers (WAF / 403 / Cloudflare). Start at the cheapest tier that can do the job and climb only when it cannot:
-**Tier 1 — insane-search** (headless extraction + WAF bypass) -> **Tier 1.5 — agent-reach** (platform-native APIs, esp. Chinese platforms) -> **Tier 2 — Chrome stealth** (real interaction via CloakBrowser + agent-browser).
+**Tier 1 — insane-search** (headless extraction + WAF bypass) -> **Tier 1.5 — agent-reach** (platform-native APIs, esp. Chinese platforms) -> **Tier 2 — a real browser**: 2a a code-driven kernel browser, 2b Chrome stealth (CloakBrowser + agent-browser) when the page fights back.
 ## PHASE 0 — ROUTE FIRST (MANDATORY)
@@ -23,11 +23,11 @@ User request
   +- podcast transcript / stock forum ----------------- TIER 1.5 agent-reach
   +- Twitter feed / LinkedIn profile / GitHub via CLI - TIER 1.5 agent-reach
   |
-  +- Tier 1/1.5 returned empty or partial ------------- TIER 2  Chrome stealth
-  +- click / fill form / scroll / interact ------------ TIER 2  Chrome stealth
-  +- screenshot / render / play video ----------------- TIER 2  Chrome stealth
-  +- login session across pages / inject cookies ------ TIER 2  Chrome stealth
-  +- test web app / QA / dogfood ---------------------- TIER 2  Chrome stealth
+  +- Tier 1/1.5 returned empty or partial ------------- TIER 2  2a kernel browser -> 2b stealth
+  +- click / fill form / scroll / interact ------------ TIER 2  2a kernel browser -> 2b stealth
+  +- screenshot / render / play video ----------------- TIER 2  2a kernel browser -> 2b stealth
+  +- login session across pages / inject cookies ------ TIER 2  2b Chrome stealth (profile + cookies)
+  +- test web app / QA / dogfood ---------------------- TIER 2  2a kernel browser -> 2b stealth
   |
   +- simple search query ------------------------------ NOT this skill (use web-search)
 ```
@@ -80,10 +80,25 @@ curl -s "https://www.v2ex.com/api/topics/hot.json"            # V2EX public API
 Routing table, per-platform auth (set `TWITTER_*` env vars, `gh auth login`, a transcription key — only if you have access), rate-limit notes, and known version quirks are in [references/agent-reach/README.md](references/agent-reach/README.md).
-## Tier 2 — Chrome stealth (real interaction)
+## Tier 2 — a real browser (real interaction)
 **When**: real interaction is needed (clicks, forms, screenshots, video, persistent login), or Tier 1/1.5 failed.
+### Tier 2a — kernel browser (default)
+Drive the page from the code cell you are already in, with no CLI process and no open CDP port. On a Bun >= 1.4 runtime that is `new Bun.WebView()` (`navigate`, `click`, `type`, `evaluate`, `screenshot`, raw `cdp`); elsewhere it is `playwright-core`/`puppeteer-core` against the local Chrome. Snapshots and screenshots come back in-process, so this is the cheapest way to answer "what does the page actually render".
+```js
+await using view = new Bun.WebView({ width: 1280, height: 800 })
+await view.navigate(url)
+const title = await view.evaluate("document.title")
+await view.screenshot({ path: "/tmp/page.png" })
+```
+Climb to 2b when the site detects automation (Turnstile, FingerprintJS, "unusual traffic"), when the flow needs a persistent logged-in profile or injected cookies, or when the kernel browser cannot reach the page at all.
+### Tier 2b — Chrome stealth (blocked or logged-in pages)
 CloakBrowser is a stealth Chromium with source-level fingerprint patches that passes Cloudflare Turnstile, FingerprintJS, BrowserScan, and 30+ detectors; agent-browser is the CDP automation CLI that drives it. Both are runtime-installed tools (not vendored here). Full setup, version pins, launch flow, cookie login, and cross-platform notes are in [references/chrome-stealth.md](references/chrome-stealth.md).
 NEVER clear cookies, cache, or site data (`Network.clearBrowserCookies`, `Storage.clearCookies`, `chrome.browsingData.remove`, "clear browsing data") on the user's real/main browser profile — it wipes their logged-in state everywhere. If the task needs that profile's login state, clone the profile directory first (`rsync -a <profile>/ <tmp-clone>/`) and launch CloakBrowser / agent-browser with the clone as the user-data-dir; run any clearing on the clone only.

package/dist/skills/ultimate-browsing/references/chrome-stealth.md CHANGED Viewed

@@ -17,22 +17,24 @@ CloakBrowser (stealth Chromium) <- CDP port 9242 -> agent-browser CLI
 CloakBrowser runs in a dedicated Python venv. Cross-platform: macOS, Linux, and Windows all supported by both tools (use the venv path convention for your OS).
+The venv lives at a fixed path so every session reuses one stealth-Chromium download instead of creating a new venv per working directory, and every command below calls its interpreter by absolute path — no `activate` step to forget.
 ```bash
 # CloakBrowser (MIT wrapper source; separate binary license, pin 0.5.7):
-uv venv .cloak-venv --python 3.13
-# macOS/Linux: source .cloak-venv/bin/activate    Windows: .cloak-venv\Scripts\activate
-uv pip install "cloakbrowser==0.5.7"
-python -c "import cloakbrowser; cloakbrowser.ensure_binary()"   # downloads stealth Chromium on first import
+VENV="$HOME/.agents/cloak-venv"          # Windows: %USERPROFILE%\.agents\cloak-venv
+uv venv "$VENV" --python 3.13
+uv pip install --python "$VENV/bin/python" "cloakbrowser==0.5.7"
+"$VENV/bin/python" -c "import cloakbrowser; cloakbrowser.ensure_binary()"   # downloads stealth Chromium on first import
 # agent-browser (Apache-2.0, pin 0.34.0):
-npm i -g agent-browser@0.34.0 && agent-browser install
+bun add -g agent-browser@0.34.0 && agent-browser install
 agent-browser --version   # 0.34.0
 ```
 Verify CloakBrowser:
 ```bash
-python -c "import cloakbrowser; print(cloakbrowser.__version__, cloakbrowser.CHROMIUM_VERSION, cloakbrowser.binary_info()['installed'])"
+"$VENV/bin/python" -c "import cloakbrowser; print(cloakbrowser.__version__, cloakbrowser.CHROMIUM_VERSION, cloakbrowser.binary_info()['installed'])"
 # -> 0.5.7  <chromium-version>  True
 ```
@@ -41,8 +43,9 @@ python -c "import cloakbrowser; print(cloakbrowser.__version__, cloakbrowser.CHR
 NEVER clear cookies, cache, or site data (`Network.clearBrowserCookies`, `Storage.clearCookies`, `chrome.browsingData.remove`, "clear browsing data") on the user's real/main browser profile — it wipes their logged-in state everywhere. If you need that profile's login state, clone it first (`rsync -a <profile>/ <tmp-clone>/`) and launch with the clone as the user-data-dir; run any clearing on the clone only.
 ```bash
-# 1. Launch CloakBrowser with CDP on :9242 (background). With the venv active:
-python -c "import asyncio,cloakbrowser; asyncio.run(cloakbrowser.launch_async(headless=False, stealth_args=True, args=['--remote-debugging-port=9242']))" &
+# 1. Launch CloakBrowser with CDP on :9242 (background). cloakbrowser lives only in the venv,
+#    so call its interpreter by absolute path — this works in any shell, activated or not:
+"$HOME/.agents/cloak-venv/bin/python" -c "import asyncio,cloakbrowser; asyncio.run(cloakbrowser.launch_async(headless=False, stealth_args=True, args=['--remote-debugging-port=9242']))" &
 # 2. CloakBrowser launches tabless -> agent-browser would say "No page found".
 #    Open the first tab via CDP before any agent-browser command:
@@ -119,6 +122,6 @@ lsof -ti:9242 | xargs kill -9
 # agent-browser can't connect:
 curl -s http://127.0.0.1:9242/json/version | head -5   # empty -> CloakBrowser not running
 # Update either tool:
-uv pip install --upgrade "cloakbrowser==0.5.7" && python -c "import cloakbrowser; cloakbrowser.ensure_binary()"
-npm i -g agent-browser@0.34.0
+uv pip install --python "$HOME/.agents/cloak-venv/bin/python" --upgrade "cloakbrowser==0.5.7" && "$HOME/.agents/cloak-venv/bin/python" -c "import cloakbrowser; cloakbrowser.ensure_binary()"
+bun add -g agent-browser@0.34.0
 ```

package/dist/skills/ulw-execute/SKILL.md CHANGED Viewed

@@ -1,6 +1,6 @@
 ---
 name: ulw-execute
-description: "Execute a Prometheus work plan with Boulder state, evidence ledger updates, worktree discipline, parallel subagents, and Stop-hook continuation. Use after planning when the user says ulw-execute, execute plan, continue plan, resume plan, or asks to run a .omo/plans plan."
+description: "Executes a written Prometheus work plan with Boulder state, evidence ledger, worktree discipline, and parallel subagents. Use when the user says ulw-execute or asks to run a .omo/plans plan."
 ---
 ## ABSOLUTE RULE: YOU ARE AN ORCHESTRATOR — NEVER THE IMPLEMENTER

package/dist/skills/ulw-plan/SKILL.md CHANGED Viewed

@@ -1,6 +1,6 @@
 ---
 name: ulw-plan
-description: "ACTIVATES ONLY on an explicit user request for the ulw-plan workflow: the user themselves saying ulw-plan, ulw plan, /skill:ulw-plan, or asking in their own words for a work plan before coding. NEVER self-activates: a bare ulw/ultrawork run, an agent-side routing decision, or reading this file is not a request, and the plan-gated reviewers (metis/momus) stay locked without a user request plus a written .omo/plans plan file. 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, ulw plan, plan this, make a plan, plan before coding, interview me, break this down, start planning, plan mode."
+description: "Explore-first planning consultant that writes one decision-complete work plan before coding. Use only on an explicit user request for the ulw-plan workflow or a plan before implementation; it never self-activates on a bare ulw run."
 metadata:
   short-description: Explore-first planning consultant that waits for your okay before planning
 ---

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

@@ -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' in any prefix form, any 'ulw' research wording including combined invocations like 'mass ulw research', '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
@@ -175,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):
@@ -381,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/SKILL.md CHANGED Viewed

@@ -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, terminal, and paginated-document surfaces. 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, PDF page check, deck review, blank or near-empty page, wrong page break."
+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
@@ -49,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 CHANGED Viewed

@@ -4,4 +4,5 @@ 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 CHANGED Viewed

@@ -6,5 +6,5 @@ export type BuiltinCategoryDefinition = {
     callerGuidance?: string;
     promptAppend: string;
     resolvePromptAppend?: (model: string | undefined) => string;
-    requiresModel?: string;
+    requiresModel?: string | readonly string[];
 };

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

@@ -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 CHANGED Viewed

@@ -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[];