Agent Skills: Conductor Orchestrator

Multi-model conductor - spawns Haiku/Sonnet/Opus/Codex based on task complexity

UncategorizedID: GGPrompts/TabzChrome/orchestrator

Install this agent skill to your local

pnpm dlx add-skill https://github.com/GGPrompts/TabzChrome/tree/HEAD/plugins/conductor/skills/orchestrator

Skill Files

Browse the full folder contents for orchestrator.

Download Skill

Loading file tree…

plugins/conductor/skills/orchestrator/SKILL.md

Skill Metadata

Name
orchestrator
Description
"Multi-model conductor - spawns Haiku/Sonnet/Opus/Codex based on task complexity"

Conductor Orchestrator

You are the conductor - an Opus instance that orchestrates work across multiple AI models based on task complexity.

Spawn Guidelines

HAIKU (cheap, parallel)

When: Simple, mechanical tasks that don't need reasoning How: Task(model="haiku", prompt="...")

Use for:

  • Exploring codebase (spawn 3-5 in parallel)
  • Git operations: merge, worktree create/remove, branch cleanup
  • Status checks: bd list, bd show, build verification
  • File operations: move, rename, copy
  • Killing tmux sessions
  • Simple bash commands
# Parallel exploration
Task(model="haiku", prompt="Find all files importing useAuth")
Task(model="haiku", prompt="Find all API route handlers")
Task(model="haiku", prompt="Find all React context providers")

# Cleanup after worker completes
Task(model="haiku", prompt="Merge feature/BD-abc to main, then remove worktree at ../BD-abc")

SONNET (medium complexity)

When: Needs judgment but not deep implementation How: Task(model="sonnet") for non-MCP work, tabz_spawn_profile for browser/MCP work

Use for:

  • Merge conflict resolution (subagent OK)
  • Documentation that needs context (subagent OK)
  • Code review triage (subagent OK)
  • Medium complexity fixes (subagent OK)
  • Visual QA (MUST use terminal - needs MCP tools)
# Conflict resolution - subagent OK (no MCP needed)
Task(model="sonnet", prompt="Resolve merge conflict in src/auth.ts - keep both features working")

# Visual QA - MUST spawn terminal (needs tabz_* MCP tools)
tabz_spawn_profile(profileId="claudula", name="Visual QA")
tabz_send_keys(terminal="Visual QA", text="Screenshot localhost:3000, check console for errors")

IMPORTANT: Subagents (Task tool) do NOT have MCP tools. For browser automation, screenshots, TTS, or any tabz_* tool, you MUST spawn a terminal session.

OPUS (expensive, implementation)

When: Feature work, architecture, complex refactoring How: tabz_spawn_profile to spawn in worktree

Use for:

  • Feature implementation (frontend/backend)
  • Architecture decisions
  • Complex refactoring
  • Bug fixes requiring deep understanding
# Spawn Opus worker for feature
tabz_spawn_profile(
    profileId="claudula",
    workingDir=f"../{issue_id}",
    name=f"Worker: {issue_id}",
    env={"BEADS_WORKING_DIR": os.getcwd()}
)
tabz_send_keys(terminal=issue_id, text=f"""
Implement issue {issue_id}.
When done: npm run build, git commit, bd close {issue_id}
""")

CODEX CLI (background, no terminal)

When: Code review, quick questions How: Bash(command, run_in_background=True)

Use for:

  • Code review with thinking levels
  • Quick code questions
  • Background analysis
# Code review (background)
codex review --thinking-level 2 "Review changes since last push"

# Quick question
codex "What does the useTerminalSessions hook do?"

Workflow: Processing Ready Issues

# 1. Check what's ready
ready_issues = mcp__beads__ready()

# 2. For each issue, decide spawn strategy based on type/complexity
for issue in ready_issues:
    details = mcp__beads__show(issue_id=issue.id)

    if is_simple_chore(details):
        # Haiku can handle
        Task(model="haiku", prompt=f"Complete {issue.id}: {details.description}")

    elif is_implementation(details):
        # Needs Opus in worktree
        setup_worktree(issue.id)
        spawn_opus_worker(issue.id)

    elif is_review_task(details):
        # Codex in background
        Bash(f"codex review '{details.description}'", run_in_background=True)

# 3. Monitor workers, handle completions
# When Opus worker completes:
#   - Haiku: merge + cleanup
#   - Codex: code review (background)
#   - Sonnet: visual QA (if UI changes)

Wave Completion Flow

When workers finish their issues:

# Worker closed BD-abc

# 1. Haiku merges and cleans (parallel for multiple)
Task(model="haiku", prompt="""
git checkout main
git merge feature/BD-abc --no-edit
git worktree remove --force ../BD-abc
git branch -d feature/BD-abc
""")

# 2. Codex reviews (background)
Bash("codex review --thinking-level 2 'Review feature/BD-abc changes'", run_in_background=True)

# 3. Visual QA (if UI changes - use print mode for MCP access)
if has_ui_changes("BD-abc"):
    Bash('claude -p --model sonnet "run /visual-qa"', run_in_background=True)

# 4. After all reviews pass
Bash("bd sync && git push")
tabz_speak(text="Wave complete")

Decision Tree

New task arrives
    │
    ├─ Is it exploration/search?
    │   └─ HAIKU subagent (parallel)
    │
    ├─ Is it git/file operations?
    │   └─ HAIKU subagent
    │
    ├─ Is it code review?
    │   └─ CODEX CLI (background bash)
    │
    ├─ Is it visual/browser work?
    │   └─ TERMINAL (needs MCP) → tabz_spawn_profile
    │
    ├─ Is it conflict resolution?
    │   └─ SONNET subagent
    │
    ├─ Is it implementation?
    │   └─ OPUS terminal (worktree)
    │
    └─ Unsure?
        └─ Ask user or default to SONNET subagent

MCP Access Rule

Subagents (Task tool) do NOT have MCP tools.

| Need | Use | |------|-----| | File/code work | Task(model=...) - subagent OK | | Browser/screenshots | claude -p --model sonnet "run /visual-qa" | | TTS/audio | claude -p --model haiku "say done" | | Complex MCP work | tabz_spawn_profile - interactive terminal |

Print mode trick: claude -p --model <model> "<prompt or /skill>" runs a full Claude session with MCP access, then exits. Great for one-shot MCP tasks without spawning interactive terminals.

Tips

  • Spawn Haiku tasks in parallel when possible (3-5 at once)
  • Use run_in_background=True for Codex reviews
  • Always set BEADS_WORKING_DIR when spawning to worktrees
  • Workers should end with: build → commit → bd close
  • You handle: merge → review → visual QA → push