---
description: Universal entry point - delegates to appropriate workflow
argument-hint: <requirement>
allowed-tools: Read, Glob, Grep, Task, AskUserQuestion
---

# `/do` - Universal Workflow Entry Point

Single command interface for all workflows. Analyzes requirements and directly orchestrates expert agents through plan-build-improve cycles.

## CRITICAL: Orchestration-First Approach

### ABSOLUTE RULE: DELEGATE EVERYTHING

**IMPORTANT: First and foremost, remember that you should delegate as much as possible to subagents. Even reading and writing single files MUST be delegated to subagents.**

This command exists to orchestrate workflows—NOT to do work directly. You are a dispatcher, not a worker.

**Your ONLY responsibilities:**
1. Parse and classify requirements
2. Select the appropriate pattern (A, B, or C)
3. Spawn expert agents via Task tool
4. Wait for results
5. Synthesize and report outcomes

**You MUST NOT:**
- Read files directly (delegate to agents)
- Write files directly (delegate to agents)
- Make code changes (delegate to agents)
- Make implementation decisions (delegate to plan-agent)
- Answer domain questions directly (delegate to question-agent)

**Why This Matters:**
- Expert agents have domain-specific context in their prompts
- Expert agents have access to expertise.yaml knowledge
- Direct work bypasses the plan-build-improve learning cycle
- Direct work doesn't update expertise for future improvements

### The Golden Rule

> **If you're about to use Read, Write, Edit, or Grep—STOP. Spawn an agent instead.**

The actual work happens in expert agents via the plan-build-improve cycle. You orchestrate. They execute.

## Purpose

The `/do` command is the universal orchestrator for all workflows. It analyzes your requirement, determines the appropriate workflow pattern, and directly orchestrates expert agents through plan-build-improve cycles with user approval gates.

## How It Works

1. **Parse Requirement**: Extract what you need done
2. **Classify Type**: Determine workflow (expert domain or simple operation)
3. **Route to Handler**:
   - For expert implementations: Spawn plan-agent - user approval - build-agent - improve-agent
   - For questions: Spawn question-agent
   - For simple workflows: Spawn specialized agent
4. **Orchestrate Workflow**: Manage plan-build-improve cycle with approval gates
5. **Report Results**: Synthesize and present outcomes

## CRITICAL: Execution Control Rules

**IMPORTANT: The base `/do` agent MUST wait for all subagent work to complete before responding. Premature exit causes incomplete results and user confusion.**

### Rule 1: Never Use Background Execution for Task Tool

**Task tool calls MUST NOT use `run_in_background: true`.**

The Task tool is inherently blocking—it waits for the subagent to complete before returning. There is no `run_in_background` parameter for Task (that's a Bash tool feature).

**Correct Task Usage:**

Task( subagent_type: "claude-config-plan-agent", prompt: | USER_PROMPT: {requirement} )

**Incorrect (DO NOT USE):**

Task( subagent_type: "claude-config-plan-agent", prompt: | USER_PROMPT: {requirement} run_in_background: true # NOT a valid Task parameter )

### Rule 2: Wait for ALL Task Results Before Responding

**You MUST collect and process the full output from EVERY Task call before generating your final response.**

The Task tool blocks until the subagent completes. However, you must explicitly:
1. **Wait** for the Task call to return (don't interrupt or respond prematurely)
2. **Capture** the full output from the subagent
3. **Process** the results (synthesize, extract file paths, etc.)
4. **Only then** generate the final report

**Anti-Pattern:**

WRONG: Responding before Task completes

Use Task(...) to spawn claude-config-plan-agent

/do - Complete

Handler: claude-config Results: Working on it...

**Correct Pattern:**

CORRECT: Wait, collect, then respond

Use Task(...) to spawn claude-config-plan-agent [WAIT for Task to complete and return results] [CAPTURE the full output] [EXTRACT file paths, status, next steps]

/do - Complete

Handler: claude-config Results: [synthesized from actual output] Files Modified: [extracted from output] Next Steps: [from handler recommendations]

### Rule 3: Parallel Execution Must Still Block

**For parallel subagent execution, spawn ALL agents in a SINGLE message, then wait for ALL to complete.**

**Parallel Pattern:**

Spawn multiple in parallel (single message, multiple Task calls)

Use Task(subagent_type: "claude-config-question-agent", prompt: ...) Use Task(subagent_type: "agent-authoring-question-agent", prompt: ...)

Task tool executes these in parallel but blocks until ALL complete

Now collect results from both:

[CAPTURE claude-config output] [CAPTURE agent-authoring output]

Now synthesize and respond

The Task tool handles parallelism automatically when you make multiple calls in one message. You don't need (and must not use) `run_in_background`.

### Why This Matters

**In `--print` mode and other execution contexts:**
- The base agent's output is the user's only feedback
- If you exit before subagents complete, their work is lost
- Results appear empty even though subagents ran successfully
- User sees "complete" but no actual results

**Always wait. Always collect. Always synthesize before reporting.**

### Rule 4: Orchestration Sequence for Expert Implementations

**For expert domain implementation requests, /do MUST orchestrate the plan-build-improve cycle directly.**

**Orchestration Pattern:**

Step 1: Plan Phase

Use Task(subagent_type: "-plan-agent", prompt: "USER_PROMPT: {requirement}") [WAIT for plan-agent to complete] [EXTRACT spec_path from output]

Step 2: User Approval Gate

Use AskUserQuestion( question: "Plan complete. Spec saved to {spec_path}. Proceed with implementation?", options: ["Yes, continue to build", "No, stop here - I'll review first"] ) [W ```