task-commander

---
name: task-commander
description: Multi-agent orchestration — Claude manages ACP agents (Codex, OpenCode, Kimi, Pi) for complex tasks
triggers:
  - "/task-commander"
  - "/commander"
  - "/orchestrate-task"
disable-model-invocation: true
---

# Task Commander — Multi-Agent Orchestration Brain

> You are the manager. You plan, dispatch, monitor, and verify. You never do the work yourself. Every agent gets a self-contained prompt with zero context bleeding. Every workflow ends with COMP PROVE verification.

## Core Philosophy

Task Commander treats Claude as an orchestration layer that coordinates ACP (Agent Communication Protocol) agents through Agency Orchestrator workflows or Claude Peers. You decompose complex tasks into a DAG of focused sub-tasks, assign each to the most capable agent, monitor progress, handle failures, and synthesize results.

**Three Laws of Task Commander:**
1. **Self-contained prompts.** Every agent receives everything it needs. No implicit context, no "you know what I mean," no references to prior conversation.
2. **Verify everything.** Agent output is untrusted until it passes COMP PROVE.
3. **Fail fast, recover faster.** Circuit breakers catch flaky agents. Reassignment keeps momentum.

---

## Priority-Based Agent Allocation

Task complexity determines how many agents you deploy and what coordination pattern you use.

### Priority Scale

| Priority | Complexity | Agent Count | Pattern | Example |
|----------|-----------|-------------|---------|---------|
| P0 | Trivial fix | 1 | Direct dispatch | Fix a typo, update a version |
| P1 | Simple task | 1 | Direct dispatch | Add a config option, write a test |
| P2 | Focused feature | 1 | Direct dispatch with verification | Implement a single endpoint |
| P3 | Multi-file feature | 2 | Sequential pipeline | Add auth to 3 routes |
| P4 | Cross-concern feature | 2-3 | Parallel + merge | Frontend + backend + tests |
| P5 | Complex feature | 3 | DAG with dependencies | New module with DB, API, UI |
| P6 | System feature | 3-4 | Full DAG | Multi-service feature |
| P7 | Architecture change | 4-5 | Phased DAG | Database migration + code changes |
| P8 | Major refactor | 4-6 | Multi-phase DAG | Rewrite a subsystem |
| P9 | System redesign | 5-6 | Multi-phase + review gates | Redesign core architecture |
| P10 | Platform migration | 6+ | Multi-phase + rollback + verification | Full platform migration |

### Allocation Decision Tree

```
1. Can one agent do this in <30 minutes?
   YES -> P0-P2: Direct dispatch to best-fit agent
   NO  -> Continue

2. Are there independent parallel tracks?
   YES -> P4-P5: Parallel dispatch + merge step
   NO  -> P3: Sequential pipeline

3. Are there more than 3 phases with dependencies?
   YES -> P6-P8: Full DAG with Agency Orchestrator
   NO  -> Stay at P4-P5

4. Does failure require rollback across services?
   YES -> P9-P10: Multi-phase with rollback tests
   NO  -> Stay at current level
```

### Scope Assessment Checklist

To determine scope, answer these questions and sum the scores:

| Question | Score |
|----------|-------|
| How many files need to change? | 1-5: +1, 5-20: +3, 20+: +5 |
| How many independent subtasks? | 1: +0, 2-3: +2, 4+: +4 |
| Does it need different expertise? (security, perf, testing) | No: +0, Yes: +2 per domain |
| Can subtasks run in parallel? | No: +0, Partially: +1, Fully: +2 |
| Is there risk requiring rollback? | No: +0, Yes: +2 |

Sum: 0-2 = P0-P2, 3-5 = P3-P5, 6-8 = P6-P8, 9+ = P9-P10.

---

## Agent Capability Matrix

Match task types to agent strengths. This matrix determines which agent receives which sub-task.

| Agent Type | Model | Strengths | Best For | Cost Tier |
|------------|-------|-----------|----------|-----------|
| **Planner** | Opus | Deep reasoning, architecture, trade-off analysis | Planning, design review, complex decisions | $$$ |
| **Builder** | Sonnet | Code generation, implementation, refactoring | Feature code, API endpoints, migrations | $$ |
| **Tester** | Sonnet | Test design, edge case coverage, assertion quality | Unit tests, integration tests, E2E suites | $$ |
| **Reviewer** | Opus | Critical analysis, security awareness, pattern detection | Code review, security audit, quality gate | $$$ |
| **Researcher** | Sonnet | Broad search, synthesis, documentation analysis | Codebase analysis, dependency evaluation, prior art | $$ |
| **Worker** | Haiku | Fast execution, mechanical tasks, high throughput | Formatting, renaming, bulk edits, boilerplate | $ |
| **Codex** | Codex | Autonomous coding, PR creation, long context | Isolated features, bug fixes, file-scoped tasks | FREE |
| **OpenCode** | Various | Multi-model, configurable, open-source friendly | Flexible tasks, secondary implementation, scaffolding | $ |
| **Kimi** | Kimi | Long context window, document analysis | Research, large file analysis, documentation review | $ |
| **Pi** | Pi | Conversational, creative, user-facing tone | Copywriting, UX review, naming, marketing copy | $ |
| **Ollama** | Local | Free, private, zero latency for small tasks | Quick checks, formatting, simple transforms, validation | FREE |

### Agent Selection Rules

1. **Use the cheapest agent that can succeed.** Haiku for mechanical work, Sonnet for standard dev, Opus only for decisions and reviews.
2. **Never use Opus for implementation.** Opus plans and reviews. Sonnet and below implement.
3. **Codex for isolated features.** If the task has clear boundaries and existing tests, Codex can handle it autonomously at zero cost.
4. **Free fleet first.** Try Ollama, HuggingFace workers, Cloudflare workers before paid agents.
5. **Parallel agents must not share files.** If two agents might edit the same file, serialize them or split the file.
6. **Diverse perspectives for reviews.** Use agents from different providers for review tasks to avoid blind spots.
7. **Every agent above P2 gets a reviewer.** The reviewer is always a different agent type than the builder.

---

## Self-Contained Prompt Construction

Every agent dispatch includes a complete, self-contained prompt. This is non-negotiable. Context bleeding is the #1 cause of multi-agent workflow failures.

### Prompt Template

```markdown
## Mission
{{one_sentence_objective}}

## Context
- Project: {{project_name}} at {{project_path}}
- Language: {{language}} | Framework: {{framework}}
- Relevant files:
  - {{file_path_1}}: {{brief_description}}
  - {{file_path_2}}: {{brief_description}}

## Input Artifacts
{{output_from_upstream_tasks — full content, not references}}

## Task
1. {{step_1_with_specific_action}}
2. {{step_2_with_specific_action}}
3. {{step_3_with_specific_action}}

## Constraints
- Do NOT modify: {{protected_files}}
- Do NOT install new dependencies without documenting why
- Do NOT change public API signatures unless the plan specifies it
- Stay within scope — note adjacent issues but do not fix them

## Output Format
{{exactly_what_to_produce — files, reports, test results}}

## Verification
Before reporting completion:
- [ ] {{check_1}}
- [ ] {{check_2}}
- [ ] {{check_3}}

## Deliverable
Return: {{file paths changed, test results, summary of work done}}
```

### Anti-Patterns (Never Do These)

| Anti-Pattern | Why It Fails | Fix |
|-------------|-------------|-----|
| "Fix the auth" | Agent has no idea what auth system, what's broken, or what "fixed" means | Include file paths, error messages, expected behavior |
| "Continue from where we left off" | Agent has zero prior session context | Include full state and all prior outputs |
| "You know the codebase" | Agent knows nothing until you provide file paths and signatures | List every relevant file with descriptions |
| Sending full conversation history | Agent gets confused by irrelevant details, context bleeds | Extract only the relevant artifacts and decisions |
| "See the plan for details" | Plan is in a different agent's context | Inline the plan content directly in the prompt |

---

## Circuit Breaker Pattern

Agents fail. Network drops, hallucinations, infinite loops, wrong approach. Circuit breakers catch these and keep the workflow moving.

### Failure Detection Signals

| Signal | Meaning | Immediate Action |
|--------|---------|--------|
| Agent reports "I'm stuck" or "I can't do this" | Honest capability failure | Reassign with more context or different agent type |
| Agent produces empty or malformed output | Silent failure | Retry once with enhanced prompt, then reassign |
| Agent modifies wrong files or out-of-scope files | Scope violation | Revert changes via git, reassign with stricter constraints |
| Agent exceeds time budget (timeout) | Runaway task or infinite loop | Kill the agent, simplify the task, reassign |
| Agent output fails verification gate | Quality failure | One retry with specific feedback on what failed, then reassign |
| Agent reports "done" but tests fail | False positive completion | Reassign to a different agent type entirely |
| Agent cost exceeds per-task budget | Inefficient execution | Kill, switch to cheaper agent, simplify prompt |

### Circuit Breaker State Machine

```
CLOSED (normal operation)
    |
    v  [first failure]
HALF-OPEN (one retry with enhanced prompt — add failure feedback, more context)
    |
    v  [second failure on same task]
OPEN (reassign to different agent type — Builder->Codex, Worker->Builder, etc.)
    |
    v  [replacement agent also fails]
BLOCKED (escalate to human — see BLOCKED Status section)
```

### Reassignment Matrix

When circuit breaker opens, select the replacement agent:

| Failed Agent | First Replacement | Second Replacement |
|-------------|-------------------|-------------------|
| Builder (Sonnet) | Codex | OpenCode |
| Worker (Haiku) | Builder (Sonnet) | Codex |
| Codex | Builder (Sonnet) | OpenCode |
| Researcher (Sonnet) | Builder (Sonnet) with explicit file paths | Kimi |
| Tester (Sonnet) | Tester (Haiku) with simpler assertions | Builder as tester |
| Reviewer (Opus) | Reviewer (Sonnet) | Builder as reviewer |

### Reassignment Protocol

1. **Revert** any partial changes the failed agent made (`git checkout -- .` or restore from checkpoint)
2. **Diagnose** why the agent failed:
   - Insufficient context? Add more file content and examples to the prompt
   - Wrong agent type? The task needs different capabilities
   - Task too complex? Break it into 2-3 smaller sub-tasks
   - Environmental issue? Fix the environment (missing dependency, wrong path)
3. **Rewrite** the prompt addressing the diagnosed failure mode
4. **Reassign** to the replacement agent from the matrix above
5. **If the replacement also fails** -> BLOCKED status, escalate to human

---

## BLOCKED Status and Human Escalation

Some tasks cannot be completed autonomously. Recognizing this early saves time and money.

### BLOCKED Triggers

- Circuit breaker opens on the same task for 2 different agent types
- Task requires a decision that was not specified in the original brief
- Task requires access credentials not available to agents
- Task involves destructive operations (production deploys, data deletion, force push)
- Conflicting requirements discovered during execution
- Cost ceiling would be exceeded to complete the remaining work
- Agent discovers the original plan is fundamentally flawed

### Escalation Report Format

```markdown
## BLOCKED: {{task_id}}

**Workflow:** {{workflow_name}}
**Step:** {{step_number}}/{{total_steps}}
**Blocked since:** {{timestamp}}
**Cost spent so far:** ${{amount}}

### What Was Attempted
1. {{agent_type_1}} ({{model_1}}) tried: {{approach_1}}
   Failed because: {{specific_failure_reason_1}}
2. {{agent_type_2}} ({{model_2}}) tried: {{approach_2}}
   Failed because: {{specific_failure_reason_2}}

### Root Cause Analysis
{{why_both_agents_failed — is it a context problem, capability gap, or task definition issue?}}

### Options for Human
A. {{option_a}} — estimated cost: ${{X}}, time: {{Y min}}
B. {{option_b}} — estimated cost: ${{X}}, time: {{Y min}}
C. Provide additional context: {{what_specific_information_would_help}}
D. Cancel this task and skip to next step (downstream impact: {{description}})
E. Abort the entire workflow

**Recommendation:** Option {{X}} because {{reasoning}}
```

---

## COMP PROVE Verification Phase

Every workflow ends with COMP PROVE. No task is marked complete until it passes all four checks. This is the quality gate between "agent said it's done" and "it's actually done."

### The Four Checks

| Check | Question | How to Verify |
|-------|----------|---------------|
| **Completeness** | Did we build everything requested? | Diff deliverables against the original requirements list. Every requirement maps to a deliverable. No orphan requirements. |
| **Correctness** | Does it work and do the right thing? | Run tests. Manual smoke test for UI changes. Check edge cases. Verify no regressions via `git diff`. |
| **Coverage** | Are edge cases handled? Is there test coverage? | Check test coverage percentage (target: 80%+). Review boundary conditions. Verify error paths are tested. |
| **Confidence** | How confident are we in this delivery? | Rate HIGH/MEDIUM/LOW. Document any uncertainty. Flag anything that needs human review before shipping. |

### COMP PROVE Report Template

```markdown
## COMP PROVE: {{task_name}}

### Completeness
- [x] Requirement 1: {{description}} -> Delivered in {{file}}
- [x] Requirement 2: {{description}} -> Delivered in {{file}}
- [ ] Requirement 3: {{description}} -> NOT delivered, reason: {{why}}

### Correctness
- Tests passing: {{X}}/{{Y}} ({{percentage}}%)
- TypeScript errors: {{count}}
- Lint errors: {{count}}
- Manual verification: {{PASS|FAIL|SKIPPED}} — {{notes}}

### Coverage
- Test coverage: {{X}}%
- Edge cases tested: {{list}}
- Error paths tested: {{list}}
- Missing coverage: {{list_of_untested_paths}}

### Confidence: {{HIGH|MEDIUM|LOW}}
**Rating:** {{rating}}
**Reasoning:** {{why_this_rating}}
**Flagged for human review:** {{specific_items_or_none}}
**Would I mass-deploy this?** {{yes_or_no_and_why}}
```

### Verification Actions by Confidence

| Confidence | Action | Human Involvement |
|------------|--------|-------------------|
| HIGH | Ship it. Mark complete. Create commit. | None required |
| MEDIUM | Flag specific concerns. Deliverable is functional but has known gaps. | Human reviews flagged items before shipping |
| LOW | Do not ship. Escalate immediately. Identify what would raise confidence to MEDIUM. | Human must intervene |

---

## Cost Management

Every workflow has a cost ceiling. Exceeding it triggers a pause and human review. Silent cost overruns are a workflow failure.

### Cost Ceiling Configuration

| Workflow Type | Default Ceiling | Override Env Var |
|--------------|----------------|-----------------|
| P0-P2 quick fixes | $0.50 | `TC_COST_CEILING` |
| P3-P5 standard features | $2.00 | `TC_COST_CEILING` |
| P6-P8 complex features | $5.00 | `TC_COST_CEILING` |
| P9-P10 major workflows | $10.00 | `TC_COST_CEILING` |
| Overnight batch | $15.00 | `TC_COST_CEILING` |

### Cost Tracking Protocol

1. **Estimate before dispatch.** Calculate expected cost per agent: model tier x estimated input/output tokens.
2. **Track during execution.** Sum agent costs as they report completion.
3. **Alert at 80%.** When cumulative cost hits 80% of ceiling, evaluate remaining work.
4. **Hard stop at 100%.** Pause the workflow immediately. Report what completed and what remains.
5. **Never exceed ceiling silently.** The human must explicitly raise the ceiling to continue.

### Cost Estimation Reference

| Agent Type | Model | Typical Cost/Task | Notes |
|------------|-------|-------------------|-------|
| Planner | Opus | $0.30-0.80 | Large context for planning |
| Builder | Sonnet | $0.15-0.50 | Varies by implementation size |
| Tester | Sonnet | $0.10-0.30 | Test generation is focused |
| Reviewer | Opus | $0.20-0.60 | Deep analysis of code |
| Researcher | Sonnet | $0.10-0.40 | Search-heavy tasks |
| Worker | Haiku | $0.02-0.10 | Mechanical tasks |
| Codex | Codex | $0.00 | Free tier |
| Ollama | Local | $0.00 | Free, local inference |

### Cost Optimization Strategies

1. **Free fleet first** — Route simple tasks to Ollama, Codex, HuggingFace, Cloudflare workers
2. **Haiku for workers** — Use Haiku instead of Sonnet for boilerplate, formatting, validation
3. **Parallel = faster = cheaper** — Parallel execution reduces wall-clock time and total session cost
4. **Early termination** — If a verification gate fails, stop downstream tasks immediately
5. **Cache task outputs** — If a task's input has not changed since last run, reuse the previous output
6. **Right-size prompts** — Trim unnecessary context from prompts to reduce input tokens

---

## Integration with Claude Peers

For real-time multi-instance coordination, Task Commander uses Claude Peers (built-in MCP server).

### Spawning Pattern

```
1. Commander calls set_summary("Task Commander: orchestrating {{workflow_name}} — {{N}} agents")
2. Commander calls list_peers(scope: "machine") to discover available instances
3. For each task in the DAG:
   a. Identify an available peer or note that a new instance is needed
   b. send_message(peer_id, self_contained_prompt)
   c. Record mapping: peer_id -> task_id
4. Poll with check_messages() for completion reports
5. When a dependency resolves, dispatch the next task to an available peer
6. Collect all results and run COMP PROVE
```

### Peer Message Protocol

**Task Assignment (Commander -> Agent):**
```
TASK_COMMANDER_ASSIGN
TASK_ID: {{id}}
WORKFLOW: {{workflow_name}}
STEP: {{step_number}}/{{total_steps}}
DEPENDS_ON: [{{completed_task_ids}}]
COST_BUDGET: ${{per_task_budget}}
TIMEOUT: {{minutes}}m
---
{{self_contained_prompt}}
```

**Task Report (Agent -> Commander):**
```
TASK_COMMANDER_REPORT
TASK_ID: {{id}}
STATUS: COMPLETE | FAILED | BLOCKED
DURATION: {{minutes}}m
COST: ${{amount}}
FILES_CHANGED: [{{paths}}]
---
{{deliverable_summary_or_failure_report}}
```

**Status Check (Commander -> Agent):**
```
TASK_COMMANDER_PING
TASK_ID: {{id}}
---
Report your current status and estimated time remaining.
```

---

## Integration with Agency Orchestrator

For complex DAG workflows defined in YAML, Task Commander uses the Agency Orchestrator MCP server.

### Workflow Execution Flow

```
1. Analyze the task and decompose into a DAG
2. Select or create workflow YAML (see workflows/ directory)
3. Call create_workflow MCP tool with the YAML
4. Call run_workflow to begin execution
5. Monitor with get_workflow_status (poll every TC_STATUS_INTERVAL seconds)
6. On task completion, call get_task_output for each finished task
7. Feed outputs to downstream tasks as they become ready
8. On failure, invoke circuit breaker protocol
9. Run COMP PROVE on aggregated results
```

### Available MCP Tools

| Tool | Purpose |
|------|---------|
| `create_workflow` | Register a new workflow from YAML definition |
| `run_workflow` | Execute a registered workflow |
| `get_workflow_status` | Check progress of a running workflow |
| `list_workflows` | List all registered workflows |
| `cancel_workflow` | Stop a running workflow |
| `get_task_output` | Retrieve output from a specific completed task |

---

## Handoff Protocol

When agents pass work products between DAG steps, they follow a strict handoff protocol to prevent information loss.

### Handoff Package Structure

```markdown
## Handoff: {{source_task_id}} -> {{target_task_id}}

### Artifacts Produced
- {{file_path_1}}: {{what_this_file_contains_and_why}}
- {{file_path_2}}: {{what_this_file_contains_and_why}}

### Key Decisions Made
- {{decision_1}}: {{what_was_decided}} because {{reasoning}}
- {{decision_2}}: {{what_was_decided}} because {{reasoning}}

### Warnings for Next Agent
- {{assumption_or_shortcut_taken}}
- {{edge_case_not_handled_and_why}}

### Verification Commands
{{commands_the_next_agent_should_run_to_validate_input}}
```

### Handoff Rules

1. **Artifacts over descriptions.** Pass file paths and content, not prose about what was done.
2. **Decisions are permanent.** Once an agent makes an architectural decision, all downstream agents respect it.
3. **Warnings are mandatory.** If an agent took a shortcut or made an assumption, it must be documented in the handoff.
4. **Verification is runnable.** The handoff includes shell commands the next agent can execute to validate the input.
5. **No forward references.** A handoff never assumes what the next agent will do. It only describes what was produced.

---

## Failure Recovery and Rollback

When a workflow fails mid-execution, Task Commander follows a structured recovery process.

### Recovery Procedure

```
1. HALT — Stop all running agents immediately
2. ASSESS — Identify what completed successfully vs what failed
3. CHECKPOINT — Commit all completed work: git commit -m "task-commander: checkpoint before recovery"
4. DIAGNOSE — Determine failure category:
   a. Agent capability issue -> Reassign to different agent type
   b. Task specification issue -> Rewrite the prompt with more context
   c. Environmental issue -> Fix environment (dependency, path, permission), retry
   d. Fundamental design issue -> Escalate to human (BLOCKED)
5. DECIDE — Retry failed step from checkpoint OR rollback to last known-good state
6. EXECUTE — Run the recovery action
7. RESUME — Continue the workflow from the recovery point
```

### Rollback Procedure

```
1. Identify the last known-good checkpoint: git log --oneline | grep "task-commander: checkpoint"
2. Create a recovery branch: git checkout -b recovery-{{workflow_name}}-{{timestamp}}
3. Revert to checkpoint: git reset --hard {{checkpoint_sha}}
4. Document what was lost and what needs to be redone
5. Adjust the workflow YAML to address the failure mode
6. Re-execute from the checkpoint
```

### Checkpoint Strategy

- **Before every DAG step:** `git commit -m "task-commander: checkpoint before {{step_name}}"`
- **After every successful step:** `git commit -m "task-commander: {{step_name}} complete"`
- **On failure:** preserve the failed state in a branch (`task-commander-failed-{{step}}`) before reverting
- **Checkpoint frequency for overnight runs:** every 10 minutes or every completed sub-task, whichever is more frequent

---

## Status Reporting

Task Commander provides structured status reports at configurable intervals and on demand.

### Status Report Format

```markdown
## Task Commander Status: {{workflow_name}}
**Priority:** P{{N}} | **Started:** {{time}} | **Elapsed:** {{duration}}
**Cost:** ${{spent}} / ${{ceiling}} ({{percentage}}%)
**Circuit breakers:** {{open_count}} open / {{total_tasks}} tasks

### DAG Progress
| Step | Agent | Status | Duration | Cost | Notes |
|------|-------|--------|----------|------|-------|
| plan | planner (opus) | COMPLETE | 3m | $0.45 | |
| scaffold | builder (codex) | RUNNING | 2m | $0.12 | 65% est. |
| implement | builder (sonnet) | PENDING | - | - | waiting on scaffold |
| test | tester (haiku) | PENDING | - | - | waiting on implement |
| review | reviewer (opus) | PENDING | - | - | waiting on implement + test |

### Active Agents
- **builder-1** (Codex): Scaffolding database schema — estimated 65% complete
- **researcher-1** (Sonnet): Analyzing existing patterns — waiting for search results

### Issues
- {{issue_description_or_none}}

### Cost Projection
Spent: ${{current}} | Remaining estimate: ${{remaining}} | Total: ${{projected}}
Ceiling: ${{ceiling}} | Status: {{NORMAL|WARNING|CRITICAL}}

### ETA
Estimated completion: {{time}} ({{remaining_minutes}} minutes from now)
```

---

## Workflow Directory

Pre-built workflow YAML files in `workflows/`:

| Workflow | File | Steps | When to Use |
|----------|------|-------|-------------|
| Feature Build | `feature-build.yml` | plan -> scaffold -> implement -> test -> review | Building new features end-to-end |
| Bug Investigation | `bug-investigation.yml` | reproduce -> isolate -> fix -> verify -> regression-test | Finding and fixing bugs systematically |
| Deep Code Review | `code-review-deep.yml` | security-scan -> type-check -> logic-review -> perf-review -> synthesize | Thorough multi-perspective code review |
| Deep Research | `research-deep.yml` | parallel-search (3) -> synthesize -> verify-claims -> report | Research requiring multiple angles |
| Overnight Batch | `overnight-batch.yml` | checkpoint -> execute-queue -> verify-each -> summary -> notify | Autonomous long-running batch tasks |
| Migration | `migration.yml` | audit -> plan -> scaffold -> migrate -> verify -> rollback-test | Technology or codebase migrations |

### Custom Workflow Schema

```yaml
name: my-workflow
description: What this workflow accomplishes
scope: P3-P10
cost_ceiling: 5.00

agents:
  agent_name:
    model: opus|sonnet|haiku|codex
    role: "What this agent does in this workflow"

dag:
  - step: step_name
    agent: agent_name
    prompt: |
      Self-contained prompt with all context.
    depends_on: []
    timeout_minutes: 5
    retries: 2
    verification: |
      - [ ] Check 1
      - [ ] Check 2
```

---

## Quick Reference

### Starting a Workflow

1. Receive task -> assess complexity -> assign priority (P0-P10)
2. Select workflow from `workflows/` or construct ad-hoc DAG
3. Map agents to tasks using the capability matrix
4. Write self-contained prompts for each step
5. Set cost ceiling based on priority tier
6. Present plan to human (auto-proceed for P0-P2)
7. Execute via Claude Peers or Agency Orchestrator
8. Monitor progress, handle failures with circuit breakers
9. Run COMP PROVE on final output
10. Report results with full cost breakdown

### Commands

| Command | Action |
|---------|--------|
| `/task-commander` | Launch Task Commander |
| `/commander` | Alias for task-commander |
| `/orchestrate-task` | Alias for task-commander |

### Related Skills

| Skill | How It Integrates |
|-------|-------------------|
| `dispatching-parallel-agents` | Foundation for parallel dispatch patterns |
| `agency-orchestrator` | YAML-based DAG workflow engine (MCP server) |
| `claude-peers-bible` | Real-time multi-instance communication |
| `delegation-templates` | Structured prompt templates for agent dispatch |
| `overnight-runner` | Long-running autonomous workflows |
| `model-route` | Cost-optimal model selection per task |
| `context-budget` | Context window management during orchestration |
| `strategic-compact` | Context preservation between phases |
| `confidence-check` | Pre-execution confidence assessment |
| `four-question-validation` | Post-implementation verification (feeds COMP PROVE) |

### Environment Variables

| Variable | Default | Purpose |
|----------|---------|---------|
| `TC_COST_CEILING` | `2.00` | Default cost ceiling in dollars |
| `TC_CIRCUIT_BREAKER_THRESHOLD` | `2` | Failures before reassignment |
| `TC_STATUS_INTERVAL` | `60` | Seconds between status report polls |
| `TC_CHECKPOINT_ENABLED` | `1` | Enable automatic git checkpoints |
| `TC_MAX_PARALLEL_AGENTS` | `6` | Maximum concurrent agents |
| `TC_AUTO_PROCEED_THRESHOLD` | `2` | Max priority level for auto-proceed (no human approval) |