Tune prompts

README.md

@@ -48,10 +48,10 @@ bunx oh-my-opencode-slim@latest install
 ### V2 Background-Orchestration Beta
 
 V2 changes the orchestrator from the default execution worker into a scheduler:
-it plans work, dispatches specialists as background tasks, polls their status,
-then reconciles results before continuing. This requires OpenCode's native
-background subagent support, so beta users must start OpenCode with the
-experimental flag enabled.
+it plans work, dispatches specialists as background tasks, receives completion
+events from OpenCode or checks status only when needed, then reconciles results
+before continuing. This requires OpenCode's native background subagent support,
+so beta users must start OpenCode with the experimental flag enabled.
 
 ```bash
 bunx oh-my-opencode-slim@beta install

src/agents/orchestrator.ts

@@ -173,7 +173,7 @@ Review available agents and lane rules.
 - Brief user on delegation goal before each call
 - For trivial conversational answers or tiny mechanical edits, direct execution is allowed when scheduling overhead would clearly dominate
 - Record task IDs, state, and advisory ownership/dependency labels
-- Poll/wait for terminal results with \`task_status(wait: true, timeout_ms: ...)\`
+- Do not immediately wait after spawning independent background tasks unless the next step truly depends on their result
 - Reconcile results, resolve conflicts, and gate dependent lanes
 
 **File operations rules:**
@@ -199,11 +199,23 @@ Balance: respect dependencies, avoid parallelizing what must be sequential, and
 - Delegated specialists should be launched as background tasks whenever work can run independently: use \`task(..., background: true)\`.
 - A dispatch returns a task/session ID immediately; it does not mean completion.
 - Track each task ID with specialist, objective, state, and any advisory ownership/dependency labels from the dispatch plan.
-- Continue orchestration while tasks run: planning, scheduling independent lanes, preparing synthesis, and asking needed user questions.
-- Poll or wait with \`task_status(wait: true, timeout_ms: ...)\` before consuming outputs or starting dependent work.
+- Background completion is event/hook-driven: when a background task finishes, OpenCode injects a follow-up message with the terminal result.
+- Continue orchestration while tasks run only when useful: planning, scheduling independent lanes, preparing synthesis, or asking needed user questions.
+- If no useful independent work remains, stop after a brief status response; do not call \`task_status\` just to wait. OpenCode will resume you when the background completion event arrives.
+- Use \`task_status(wait: true, timeout_ms: ...)\` only when you actively need a result before a dependent step or final response and no completion event has arrived yet.
 - Parallel background tasks are allowed only when their write scopes do not conflict.
 - Final response requires relevant tasks to be terminal and reconciled.
 
+### Background Job Discipline
+- Every background task owns its declared lane until terminal.
+- Do not duplicate, undermine, or race a running lane.
+- After dispatch, classify the next step:
+  1. independent: continue,
+  2. dependent: wait/poll,
+  3. no useful independent work: stop and let hook-driven completion resume.
+- Before editing files or spawning another writer, compare against running job scopes.
+- Never finalize work that depends on unresolved background jobs.
+
 ### Session Reuse
 - Smartly reuse an available specialist session - context reuse saves time and tokens
 - When too much unrelated, and really needed, start a fresh session with the specialist

src/config/constants.ts

@@ -93,7 +93,7 @@ export const FALLBACK_FAILOVER_TIMEOUT_MS = 15_000;
 export const DEFAULT_MAX_SUBAGENT_DEPTH = 3;
 
 // Workflow reminders
-export const PHASE_REMINDER_TEXT = `!IMPORTANT! Scheduler workflow: plan lanes/dependencies → dispatch background specialists → track task IDs → poll task_status → reconcile terminal results → verify. Do not consume running-job output or advance dependent work. !END!`;
+export const PHASE_REMINDER_TEXT = `!IMPORTANT! Scheduler workflow: plan lanes/dependencies → dispatch background specialists → track task IDs → wait for hook-driven completion or use task_status only when needed → reconcile terminal results → verify. Do not consume running-job output or advance dependent work. !END!`;
 
 // Tmux pane spawn delay (ms) — gives TmuxSessionManager time to create pane
 export const TMUX_SPAWN_DELAY_MS = 500;