sparkecoder 0.1.113 → 0.1.115

package/dist/agent/index.js

@@ -7020,6 +7020,8 @@ ${JSON.stringify(outputSchema, null, 2)}
 `;
 }
 function buildOrchestratorPromptAddendum() {
+  const platform2 = process.platform === "darwin" ? "darwin" : "other";
+  const computerUseAvailable = platform2 === "darwin";
   return `
 ## Orchestrator Mode
 
@@ -7092,9 +7094,63 @@ If the user asks "add the GitHub MCP" or "remember that I prefer Python", load t
 ### Typical flow
 
 1. Inbound event arrives (any channel).
-2. You decompose, \`spawn\` one or more workers with explicit goals.
+2. You **decompose** the request into independent sub-tasks, then \`spawn\` one worker per sub-task \u2014 in parallel \u2014 with explicit, scoped goals.
 3. Workers run autonomously. They wake you via SYSTEM events when done / failed / blocked.
 4. On each wake, you decide: notify the user (via the original channel) / spawn follow-up work / wait for more events.
+
+### Decomposition rule
+
+If a single user message contains **multiple independent asks** that don't share state, spawn **one worker per ask, all in the same turn** (parallel \`spawn\` calls). They run concurrently and finish faster. Examples of when to split:
+
+- *"Take a screenshot of the desktop AND open Calculator"*
+  \u2192 spawn \`screenshot\` worker + spawn \`open-calculator\` worker (independent).
+- *"Run the tests and also tell me what changed since yesterday"*
+  \u2192 spawn \`run-tests\` worker + spawn \`git-diff-since-yesterday\` worker.
+- *"Fix the typo in README and bump the version"*
+  \u2192 spawn \`fix-readme-typo\` worker + spawn \`bump-version\` worker.
+
+When NOT to split (keep as one worker):
+
+- The asks share state (one's output feeds the other).
+- The asks are tightly coupled (e.g. *"refactor X and run its tests"* \u2014 the tests depend on the refactor).
+- The asks are trivially small (one or two tool calls each); spawning overhead exceeds the parallelism win.
+
+### Prefer headless tools
+
+When spawning a worker, push it toward the *cheapest tool that gets the job done*:
+
+1. **Bash / file tools** for anything with a CLI (git, npm, brew, builds, tests, file editing, HTTP via curl, scripting).
+2. **agent-browser** (\`load_skill browser\`) for *anything* in a web browser \u2014 refs from \`snapshot -i\` are deterministic, ~100\xD7 cheaper in tokens than pixel coordinates, work cross-platform, and don't need any host permissions.${computerUseAvailable ? `
+3. **Computer use** is the last resort \u2014 only when the task genuinely requires a native macOS GUI app with no CLI / API equivalent (System Settings, Calculator, Finder operations that don't have CLI flags, complex cross-app drag/drop, demos where the user wants to *see* the screen).
+
+A common anti-pattern: a worker reaches for computer use because the user phrased the request visually ("open the website and click the button"). Almost always wrong \u2014 that's a job for the browser skill, not the desktop. Coach the worker in its goal text: *"Use the browser skill (\`load_skill browser\` + \`agent-browser\` with refs from \`snapshot -i\`) to open the site and click the button. Don't use computer use for browser work."*
+
+### Serialize desktop / computer-use tasks
+
+There is exactly **one** desktop, mouse, and keyboard on the host. If two or more workers both need the **\`computer\` tool** (clicking, typing, taking desktop screenshots, opening apps, switching windows), they will **fight over the same screen** \u2014 windows will steal focus from each other, screenshots will catch the wrong app, mouse clicks will land on the wrong target.
+
+**Rule**: when spawning workers, look at each one's goal:
+
+- Does it require **GUI interaction** (open an app, click, type in a window, screenshot the desktop, navigate the OS, drive a real browser/terminal window)? \u2192 mark it as a **desktop task**.
+- Does it only need **headless tools** (bash, file edits, web fetches, code analysis, git, builds, tests run non-interactively)? \u2192 it's a **headless task**.
+
+Then:
+
+- **Spawn ALL headless tasks in parallel** (in the same turn).
+- **Run desktop tasks one at a time**, even if there are multiple of them. Either:
+  - Spawn the first one now, wait for its \`worker.completed\`, then spawn the next; OR
+  - Tell the user the desktop tasks will run sequentially and pick the most important one first.
+
+Example: *"Take a screenshot of Calculator AND run the test suite AND open System Settings"*:
+- \u2713 \`screenshot-calculator\` (desktop) \u2014 spawn now
+- \u2713 \`run-tests\` (headless) \u2014 spawn now, in parallel
+- \u23F3 \`open-system-settings\` (desktop) \u2014 wait until \`screenshot-calculator\` completes, THEN spawn.
+
+Headless workers never interfere with desktop workers (they don't touch the screen), so they always run in parallel.
+
+When you spawn a **desktop worker**, include a one-liner in the goal asking it to **record the session by default** (\`screencapture -v -V <seconds> -C\` on macOS) and return the recording path in its result, *unless* the task is long-running / boring / contains sensitive content. The recording lets you (and the user) replay what actually happened on screen. When the worker reports back, mention the recording path in your reply via the original channel.` : ""}
+
+Default bias: **when in doubt, decompose**. Two workers running in parallel and reporting independently is almost always better UX than one worker doing things sequentially.
 `;
 }
 function createSummaryPrompt(conversationHistory) {