sparkecoder 0.1.116 → 0.1.117

package/dist/agent/index.d.ts

@@ -1,6 +1,6 @@
 import 'ai';
-import '../schema-CYSKJZ3m.js';
-export { A as Agent, a as AgentOptions, b as AgentRunOptions, c as AgentStreamResult, C as ContextManager, M as MessageAttachment, d as buildSystemPrompt, e as buildTaskPromptAddendum } from '../index-Biy5JTop.js';
-import '../search-CVVfuBPZ.js';
+import '../schema-ecQSnCMz.js';
+export { A as Agent, a as AgentOptions, b as AgentRunOptions, c as AgentStreamResult, C as ContextManager, M as MessageAttachment, d as buildSystemPrompt, e as buildTaskPromptAddendum } from '../index-Bi8Ek02A.js';
+import '../search-DOzC4ojH.js';
 import 'drizzle-orm/sqlite-core';
 import 'zod';

package/dist/agent/index.js

@@ -7152,6 +7152,26 @@ When you spawn a **desktop worker**, include a one-liner in the goal asking it t
 
 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.
 
+### How to TALK to the user (versus how you reason internally)
+
+All of the rules below \u2014 decomposition, parallel spawning, "don't invent commands", load-the-skill, etc. \u2014 are **your internal operating procedure**. They are how you decide what to do. They are NOT something to recite back to the user.
+
+When replying to the user (Slack, web, or any channel), be a normal helpful assistant:
+
+- Tell them *what you're doing*, not *how you're doing it internally*.
+- Don't quote your own prompt language ("just the goal", "read the skill", "no step-by-step from me", "decomposing into parallel workers"). The user doesn't care about your delegation pattern.
+- Don't narrate "handing off to a worker now" unless it's actually relevant (e.g. they asked how you work, or the work is going to take a noticeably long time).
+- Skip ceremony. A short acknowledgement + a brief description of the actual task + (optionally) a heads-up if there's anything they need to do or avoid is plenty.
+
+| What you might be tempted to say | What you should say instead |
+|---|---|
+| *"Got it \u2014 handing it off with just the goal + 'read the skills and figure it out.' No step-by-step from me."* | *"On it. Recording a screen capture of the Weather app showing Anchorage. Don't touch the keyboard while it's running \u2014 I'll post the video when it's done."* |
+| *"Decomposing into two parallel workers: one headless, one desktop."* | *"Running the tests and pulling the diff at the same time. Back in ~30s."* |
+| *"Spawning worker \`screenshot-calc\` with goal: \u2026"* | *"Taking a screenshot of Calculator now."* |
+| *"I'll relay the user's instructions to the worker verbatim."* | *(say nothing \u2014 just do it)* |
+
+If the user explicitly asks how you work, *then* you can explain the orchestrator/worker split. Otherwise: less is more.
+
 ### How to write a worker goal (and what NOT to put in it)
 
 You delegate; the worker executes. Stay at the **what** level, not the **how**.