dsh-batch-subagents

DSH Batch Subagents

Use the bundled scripts/dsh-batch-agents.mjs controller. Resolve the script path relative to this SKILL.md and invoke it with node.

Operating contract

• Keep Codex as the commander and final reviewer. DSH workers may inspect, edit, and test only inside their isolated worktrees.
• Never merge, cherry-pick, or apply a worker patch to the main workspace automatically. Review the Markdown report and patch first, then make approved changes through the normal Codex editing workflow.
• Prefer independent, bounded tasks with explicit deliverables. Avoid giving multiple workers overlapping implementation ownership.
• The controller serializes headless execution for workers sharing one DSH_HOME, including workers from separate runs, because current DSH profiles share mutable startup state. On Windows it also clamps each batch to one active worker. A batch may still contain many independent tasks; they wait durably for the shared profile slot.
• A Git repository with a valid HEAD is required. If the current folder is not one, locate the intended nested repository or ask the user which repository to use. Do not silently snapshot a large non-Git directory.
• Worktrees are based on committed HEAD; uncommitted main-workspace changes are not copied. Surface the dirty-worktree warning from the report before judging results.
• Keep run artifacts until the user has reviewed them. cleanup removes only isolated worktrees and preserves reports and patches.

Duration-aware execution

Estimate a duration range before launching every DSH task or batch. Use the scope, prior similar runs, or a small representative check as the basis, and tell the user the estimate before launch.

• 10 minutes or less: Keep the work in the current turn. Use --foreground only when synchronous completion is useful, follow yielded execution with bounded waits, and give concise progress updates at least every 60 seconds.
• More than 10 minutes, or a range crossing 10 minutes: Launch without --foreground so the controller remains durable. Record the run directory, task IDs, start time, estimate range, and next check near the lower end of the expected completion window. End the active turn after launch unless useful independent work remains.
• Always pass a real controller deadline with --task-timeout-seconds. The deadline covers worktree preparation, waiting for the shared DSH profile lock, and agent execution.
• At the scheduled check, read status --json first. If state has not changed, do not open logs or emit repeated updates. Read REVIEW.md, reports, patches, and log tails only for completion, failure, stale state, or a meaningful checkpoint.
• Never create a tight wait/status polling loop for a long batch. If recurring monitoring is explicitly requested or the estimate is highly uncertain, use one monitor at an appropriate interval rather than keeping the active turn open.
• Treat unchanged external state as normal. A running task is not blocked or failed merely because it exceeded a conversational turn.