Task Orchestration

Task Orchestration

Overview

Coordinate complex tasks with structured orchestration: discover requirements, spawn parallel agents, and execute multi-step workflows with validation.

When to Use

• Multi-step tasks requiring coordination or delegation
• Parallelizable workstreams
• Complex requirements discovery

Avoid when:

• The task is simple or single-file

Quick Reference

Workflow

1. Choose the orchestration mode (brainstorm, spawn, task). 2. Load the matching reference. 3. Execute with delegation and progress tracking. 4. Validate outputs and consolidate results.

Output

• Orchestration summary
• Task progress and next steps

Common Mistakes

• Spawning without clear task boundaries
• Skipping validation gates

Reference: brainstorm

/orchestrate:brainstorm - Interactive Requirements Discovery

Context Framework Note: This file provides behavioral instructions for Claude Code when users type /orchestrate:brainstorm patterns. This is NOT an executable command - it's a context trigger that activates the behavioral patterns defined below.

Triggers

• Ambiguous project ideas requiring structured exploration
• Requirements discovery and specification development needs
• Concept validation and feasibility assessment requests
• Cross-session brainstorming and iterative refinement scenarios

Context Trigger Pattern

/orchestrate:brainstorm [topic/idea] [--strategy systematic|agile|enterprise] [--depth shallow|normal|deep] [--parallel]

Usage: Type this pattern in your Claude Code conversation to activate brainstorming behavioral mode with systematic exploration and multi-persona coordination.

Behavioral Flow

1. Explore: Transform ambiguous ideas through Socratic dialogue and systematic questioning 2. Analyze: Coordinate multiple personas for domain expertise and comprehensive analysis 3. Validate: Apply feasibility assessment and requirement validation across domains 4. Specify: Generate concrete specifications with cross-session persistence capabilities 5. Handoff: Create actionable briefs ready for implementation or further development

Key behaviors:

• Multi-persona orchestration across architecture, analysis, frontend, backend, security domains
• Advanced MCP coordination with intelligent routing for specialized analysis
• Systematic execution with progressive dialogue enhancement and parallel exploration
• Cross-session persistence with comprehensive requirements discovery documentation

MCP Integration

• Sequential MCP: Complex multi-step reasoning for systematic exploration and validation
• Context7 MCP: Framework-specific feasibility assessment and pattern analysis
• Magic MCP: UI/UX feasibility and design system integration analysis
• Playwright MCP: User experience validation and interaction pattern testing
• Morphllm MCP: Large-scale content analysis and pattern-based transformation
• Codanna MCP: Cross-session persistence, memory management, and project context enhancement

Tool Coordination

• Read/Write/Edit: Requirements documentation and specification generation
• TodoWrite: Progress tracking for complex multi-phase exploration
• Task: Advanced delegation for parallel exploration paths and multi-agent coordination
• WebSearch: Market research, competitive analysis, and technology validation
• sequentialthinking: Structured reasoning for complex requirements analysis

Key Patterns

• Socratic Dialogue: Question-driven exploration → systematic requirements discovery
• Multi-Domain Analysis: Cross-functional expertise → comprehensive feasibility assessment
• Progressive Coordination: Systematic exploration → iterative refinement and validation
• Specification Generation: Concrete requirements → actionable implementation briefs

Examples

Systematic Product Discovery

/orchestrate:brainstorm "AI-powered project management tool" --strategy systematic --depth deep
# Multi-persona analysis: architect (system design), analyzer (feasibility), project-manager (requirements)
# Sequential MCP provides structured exploration framework

Agile Feature Exploration

/orchestrate:brainstorm "real-time collaboration features" --strategy agile --parallel
# Parallel exploration paths with frontend, backend, and security personas
# Context7 and Magic MCP for framework and UI pattern analysis

Enterprise Solution Validation

/orchestrate:brainstorm "enterprise data analytics platform" --strategy enterprise --validate
# Comprehensive validation with security, devops, and architect personas
# Codanna MCP for cross-session persistence and enterprise requirements tracking

Cross-Session Refinement

/orchestrate:brainstorm "mobile app monetization strategy" --depth normal
# Codanna MCP manages cross-session context and iterative refinement
# Progressive dialogue enhancement with memory-driven insights

Boundaries

Will:

• Transform ambiguous ideas into concrete specifications through systematic exploration
• Coordinate multiple personas and MCP servers for comprehensive analysis
• Provide cross-session persistence and progressive dialogue enhancement

Will Not:

• Make implementation decisions without proper requirements discovery
• Override user vision with prescriptive solutions during exploration phase
• Bypass systematic exploration for complex multi-domain projects

Process Patterns

Resilient workflow patterns for multi-step, multi-agent task execution. Use these patterns when designing workflows that must handle failures gracefully, coordinate parallel work, and maintain consistency across distributed operations.

Saga Pattern

Sagas manage long-running, multi-step processes where each step can be compensated (undone) if a later step fails.

Orchestration (Central Coordinator)

A single coordinator directs each step and decides what to do on failure.

Coordinator
  ├─ Step 1: Reserve inventory  → Compensate: Release inventory
  ├─ Step 2: Charge payment     → Compensate: Refund payment
  ├─ Step 3: Ship order          → Compensate: Cancel shipment
  └─ Step 4: Send confirmation   → Compensate: Send cancellation

When to use:

• Clear sequential dependencies between steps
• Central visibility into workflow state is required
• You need deterministic retry and compensation ordering

Trade-offs:

• Single point of failure at the coordinator
• Easier to reason about and debug
• Coordinator must be durable (persist state across restarts)

Choreography (Event-Driven)

Each participant listens for events and acts independently. No central coordinator.

InventoryService  ──(InventoryReserved)──►  PaymentService
PaymentService    ──(PaymentCharged)──────►  ShippingService
ShippingService   ──(OrderShipped)────────►  NotificationService

When to use:

• Loosely coupled services with independent lifecycles
• High throughput where central coordination is a bottleneck
• Teams own their own services end-to-end

Trade-offs:

• Harder to trace and debug across services
• Risk of implicit coupling through event schemas
• Compensation logic is distributed and harder to verify

Decision Checklist

• [ ] Are steps strictly sequential? → Orchestration
• [ ] Do services need independent scaling? → Choreography
• [ ] Is end-to-end visibility critical? → Orchestration
• [ ] Are teams autonomous with separate deploy cycles? → Choreography
• [ ] Is the failure/compensation logic complex? → Orchestration

Compensation and Rollback Strategies

Compensation Design Principles

1. Every forward step gets a compensating action defined at design time 2. Compensations run in reverse order of the original steps 3. Compensations must be idempotent (safe to retry) 4. Semantic undo, not literal undo -- refunding a charge is not the same as never charging

Compensation Table Template

Rollback Strategies

Immediate rollback: Compensate all completed steps as soon as any step fails. Best for atomic-feeling operations.

Deferred rollback: Queue compensations for later execution. Best when compensations are expensive or external (e.g., refund processing).

Partial rollback: Only compensate steps that are inconsistent. Best when some steps are independently valuable.

Failure During Compensation

• Log the compensation failure with full context
• Retry with exponential backoff
• After retry exhaustion, escalate to a dead letter queue or human operator
• Never silently swallow a failed compensation

Split/Join Patterns for Parallel Work

Static Split/Join

Fan out to a known set of parallel tasks, then wait for all to complete.

        ┌─► Task A ─┐
Start ──┼─► Task B ──┼──► Join ──► Continue
        └─► Task C ─┘

Join strategies:

• All (barrier): Wait for every branch. Use when all results are required.
• Any (race): Continue as soon as one branch completes. Use for redundant execution or fastest-wins.
• N-of-M (quorum): Wait for N of M branches. Use for consensus or fault-tolerant reads.
• Timeout with partial: Wait up to a deadline, then proceed with whatever completed. Use when partial results are acceptable.

Dynamic Split/Join

The number of parallel branches is determined at runtime (e.g., one branch per file in a directory).

Input list ──► Map (spawn one task per item) ──► Reduce (aggregate results)

Considerations:

• Set a concurrency limit to avoid resource exhaustion
• Handle individual branch failures without failing the whole fan-out
• Collect partial results and errors separately

Scatter-Gather

Broadcast a request to multiple agents, collect responses, and merge.

Use when: Multiple agents may have relevant information, and you want the union of their knowledge.

Circuit Breaker Patterns for Task Failure

States

CLOSED ──(failures exceed threshold)──► OPEN
OPEN ──(timeout expires)──► HALF-OPEN
HALF-OPEN ──(probe succeeds)──► CLOSED
HALF-OPEN ──(probe fails)──► OPEN

Configuration Template

When to Apply

• [ ] Calling an external service that may be down
• [ ] Delegating to a sub-agent that may hang or crash
• [ ] Accessing a shared resource with contention
• [ ] Any step where repeated failure wastes resources

Fallback Actions When Open

1. Return a cached/stale result 2. Use a degraded alternative path 3. Queue the work for later retry 4. Return an explicit "temporarily unavailable" signal

Idempotency in Multi-Step Workflows

Why Idempotency Matters

Retries are inevitable. Network failures, agent crashes, and timeouts all cause duplicate execution. Every step in a workflow must produce the same result whether executed once or many times.

Idempotency Techniques

Idempotency keys: Assign a unique key per operation. Before executing, check if the key was already processed.

Step execution:
1. Generate key = hash(workflow_id + step_id + input)
2. Check: has this key been processed?
   - Yes → return stored result
   - No  → execute, store result keyed by idempotency key

Natural idempotency: Design operations so re-execution is inherently safe.

• SET status = 'complete' is idempotent
• INCREMENT counter is NOT idempotent

Deduplication windows: Accept duplicate messages but deduplicate within a time window using message IDs.

Idempotency Checklist

• [ ] Every workflow step has a deterministic idempotency key
• [ ] Side effects (API calls, notifications) are guarded by deduplication
• [ ] Database writes use upsert or conditional writes
• [ ] File operations check for existing output before writing
• [ ] External calls use idempotency headers where supported
• [ ] Compensation actions are also idempotent

Reference: spawn

/orchestrate:spawn - Meta-System Task Orchestration

Triggers

• Complex multi-domain operations requiring intelligent task breakdown
• Large-scale system operations spanning multiple technical areas
• Operations requiring parallel coordination and dependency management
• Meta-level orchestration beyond standard command capabilities

Usage

/orchestrate:spawn [complex-task] [--strategy sequential|parallel|adaptive] [--depth normal|deep]

Behavioral Flow

1. Analyze: Parse complex operation requirements and assess scope across domains 2. Decompose: Break down operation into coordinated subtask hierarchies 3. Orchestrate: Execute tasks using optimal coordination strategy (parallel/sequential) 4. Monitor: Track progress across task hierarchies with dependency management 5. Integrate: Aggregate results and provide comprehensive orchestration summary

Key behaviors:

• Meta-system task decomposition with Epic → Story → Task → Subtask breakdown
• Intelligent coordination strategy selection based on operation characteristics
• Cross-domain operation management with parallel and sequential execution patterns
• Advanced dependency analysis and resource optimization across task hierarchies

MCP Integration

• Native Orchestration: Meta-system command uses native coordination without MCP dependencies
• Progressive Integration: Coordination with systematic execution for progressive enhancement
• Framework Integration: Advanced integration with SuperClaude orchestration layers

Personas (Thinking Modes)

Meta-system orchestration benefits from high-level architectural thinking:

• architect: System-wide design, component relationships, scalability patterns
• analyzer: Dependency analysis, complexity assessment, risk evaluation

Note: Spawn is meta-level - it breaks down operations and delegates to subagents. Each spawned subagent may adopt additional personas as needed.

Delegation Protocol

This command ALWAYS delegates - spawn is specifically for complex multi-domain operations requiring subagent coordination.

When spawn is triggered:

• ✅ Operations spanning >5 technical domains
• ✅ System-wide changes (>10 files or >3 directories)
• ✅ Complex dependency chains requiring careful orchestration
• ✅ Enterprise-scale operations with governance requirements

Delegation strategy: 1. Analyze: Break down operation into independent workstreams 2. Map dependencies: Identify what must be sequential vs parallel 3. Launch subagents: Use Task tool to spawn multiple subagents 4. Coordinate: Monitor progress and integrate results 5. Validate: Apply quality gates across all workstreams

Typical subagent usage:

<!-- Spawn launches multiple Task tool subagents based on decomposition -->
<function_calls>
<invoke name="Task">
  <subagent_type>Explore</subagent_type>
  <description>Analyze existing system architecture</description>
  <prompt>Explore codebase to understand current patterns...</prompt>
</invoke>
<invoke name="Task">
  <subagent_type>general-purpose</subagent_type>
  <description>Implement backend components</description>
  <prompt>Build backend services with architect guidance...</prompt>
</invoke>
<invoke name="Task">
  <subagent_type>general-purpose</subagent_type>
  <description>Implement frontend components</description>
  <prompt>Build frontend UI components...</prompt>
</invoke>
<invoke name="Task">
  <subagent_type>test-automator</subagent_type>
  <description>Generate comprehensive test suite</description>
  <prompt>Create tests covering all components...</prompt>
</invoke>
<invoke name="Task">
  <subagent_type>code-reviewer</subagent_type>
  <description>Review entire implementation</description>
  <prompt>System-wide quality and security review...</prompt>
</invoke>
</function_calls>

Tool Coordination

• Task tool: PRIMARY mechanism - spawns subagents for all workstreams
• TodoWrite: Hierarchical task breakdown at Epic → Story → Task → Subtask levels
• Read/Grep/Glob: Initial analysis (often delegated to Explore subagent)
• Direct file tools: Only for spawn's own coordination needs (not delegated work)
• Bash: System-level operations when needed for orchestration

Key Patterns

• Hierarchical Breakdown: Epic-level operations → Story coordination → Task execution → Subtask granularity
• Strategy Selection: Sequential (dependency-ordered) → Parallel (independent) → Adaptive (dynamic)
• Meta-System Coordination: Cross-domain operations → resource optimization → result integration
• Progressive Enhancement: Systematic execution → quality gates → comprehensive validation

Examples

Complex Feature Implementation

/orchestrate:spawn "implement user authentication system"
# Breakdown: Database design → Backend API → Frontend UI → Testing
# Coordinates across multiple domains with dependency management

Large-Scale System Operation

/orchestrate:spawn "migrate legacy monolith to microservices" --strategy adaptive --depth deep
# Enterprise-scale operation with sophisticated orchestration
# Adaptive coordination based on operation characteristics

Cross-Domain Infrastructure

/orchestrate:spawn "establish CI/CD pipeline with security scanning"
# System-wide infrastructure operation spanning DevOps, Security, Quality domains
# Parallel execution of independent components with validation gates

Boundaries

Will:

• Decompose complex multi-domain operations into coordinated task hierarchies
• Provide intelligent orchestration with parallel and sequential coordination strategies
• Execute meta-system operations beyond standard command capabilities

Will Not:

• Replace domain-specific commands for simple operations
• Override user coordination preferences or execution strategies
• Execute operations without proper dependency analysis and validation

Task Decomposition

Structured approaches for breaking complex work into plannable, assignable, and trackable units. Use when facing ambiguous requirements, multi-agent coordination, or work that needs dependency analysis and parallel execution planning.

Planning Methodology (Work Breakdown Structure)

Top-Down Decomposition

Start from the deliverable and recursively split until each leaf is a single assignable unit of work.

Level 0: Project / Epic
  Level 1: Feature or Milestone
    Level 2: Task (assignable, estimable)
      Level 3: Subtask (single action, <2 hours)

Decomposition Rules

1. 100% rule: Child tasks must fully account for the parent -- nothing missing, nothing extra 2. Mutual exclusivity: No overlap between sibling tasks 3. Outcome-oriented: Name tasks by what they produce, not what they do 4. Testable completion: Every task has a clear "done" definition

Work Breakdown Template

## [Epic Name]

### [Feature 1]
- [ ] Task 1.1: [Outcome] — Owner: TBD, Est: S/M/L
  - Acceptance: [How to verify]
  - Dependencies: [None | Task X.Y]
- [ ] Task 1.2: [Outcome] — Owner: TBD, Est: S/M/L

### [Feature 2]
...

Decomposition Checklist

• [ ] Every leaf task can be completed by one agent/person
• [ ] Every leaf task has a verifiable completion criterion
• [ ] No task exceeds 4 hours of estimated effort
• [ ] Dependencies between tasks are explicitly listed
• [ ] The sum of leaf tasks equals the parent deliverable

Dependency Mapping

Dependency Types

Critical Path Analysis

The critical path is the longest chain of dependent tasks. It determines the minimum project duration.

Finding the critical path: 1. List all tasks with durations and dependencies 2. Forward pass: calculate earliest start/finish for each task 3. Backward pass: calculate latest start/finish for each task 4. Slack = Latest Start - Earliest Start 5. Tasks with zero slack are on the critical path

Using the critical path:

• Prioritize critical-path tasks for resource allocation
• Add buffers to critical-path tasks, not to every task
• Monitor critical-path tasks more closely for delays
• Reassign non-critical tasks to free up critical-path resources

Blocker Identification

Proactively identify blockers before they stall work:

• [ ] External dependencies: APIs, services, or data from other teams
• [ ] Shared resources: Files, databases, or environments with contention
• [ ] Knowledge gaps: Tasks requiring expertise not yet available
• [ ] Approval gates: Reviews, sign-offs, or compliance checks
• [ ] Environment setup: Infrastructure or tooling not yet provisioned

Dependency Visualization

Task A ──► Task C ──► Task E ──► Done
Task B ──► Task C
Task B ──► Task D ──► Task E

Critical path: B → C → E (if B + C + E > A + C + E)

Task Sizing and Estimation Heuristics

T-Shirt Sizing

Estimation Guidelines

1. If it feels XL, decompose further -- XL tasks are planning failures 2. Estimate from the bottom up -- aggregate leaf task estimates, don't top-down guess 3. Include uncertainty explicitly -- "2-4 hours" is more honest than "3 hours" 4. Calibrate on completed work -- track actual vs estimated to improve over time 5. Separate effort from elapsed time -- a 2-hour task blocked for a day is still S-sized effort

Effort vs Complexity Matrix

When to Spike

Run a timeboxed investigation (spike) before estimating when:

• The technology is unfamiliar
• The approach is unclear after 10 minutes of analysis
• Multiple viable solutions exist and the trade-offs are unknown
• Integration points are undocumented

Spike output: A written recommendation with enough detail to estimate the real task.

Parallel vs Sequential Execution Decisions

Decision Framework

Can tasks run independently?
├─ Yes: Are there shared resources?
│   ├─ No  → Run in parallel
│   └─ Yes → Can we partition the resource?
│       ├─ Yes → Parallel with partitioning
│       └─ No  → Sequential (or lock-based parallel)
└─ No: Is there a data dependency?
    ├─ Yes → Sequential (respect the dependency)
    └─ No  → Check for ordering requirements
        ├─ Yes → Sequential
        └─ No  → Parallel

Parallelization Checklist

• [ ] Tasks do not read/write the same files
• [ ] Tasks do not depend on each other's output
• [ ] Combined resource usage stays within limits (CPU, memory, API rate limits)
• [ ] Failure of one task does not invalidate another's work
• [ ] Results can be merged without conflicts

Concurrency Limits

Set explicit limits to avoid resource exhaustion:

Sequential When

• Steps must be validated before proceeding (quality gates)
• Shared mutable state cannot be partitioned
• Order matters for correctness (database migrations, schema changes)
• Debugging is more important than speed (trace one path at a time)

Resource Allocation Patterns

Capability-Based Assignment

Match tasks to agents based on skills, not availability alone.

Task requires: [TypeScript, React, testing]
Agent A skills: [TypeScript, React, Node.js]     → Match: 2/3
Agent B skills: [Python, Django, testing]         → Match: 1/3
Agent C skills: [TypeScript, React, testing]      → Match: 3/3 ← Assign

Load Balancing Strategies

• Round-robin: Distribute tasks evenly. Simple but ignores task size and agent skill.
• Least-loaded: Assign to the agent with the most available capacity.
• Skill-weighted: Prefer agents whose skills best match the task, with load as a tiebreaker.
• Affinity: Prefer assigning related tasks to the same agent to reduce context switching.

Rebalancing Triggers

Reassign work when:

• An agent is blocked waiting on an external dependency
• An agent's task estimate was significantly wrong (2x+ overrun)
• A higher-priority task arrives that requires a specific agent
• An agent completes early and can absorb work from an overloaded peer

Reference: task

/orchestrate:task - Enhanced Task Management

Triggers

• Complex tasks requiring multi-agent coordination and delegation
• Projects needing structured workflow management and cross-session persistence
• Operations requiring intelligent MCP server routing and domain expertise
• Tasks benefiting from systematic execution and progressive enhancement

Usage

/orchestrate:task [action] [target] [--strategy systematic|agile|enterprise] [--parallel] [--delegate]

Behavioral Flow

1. Analyze: Parse task requirements and determine optimal execution strategy 2. Delegate: Route to appropriate MCP servers and activate relevant personas 3. Coordinate: Execute tasks with intelligent workflow management and parallel processing 4. Validate: Apply quality gates and comprehensive task completion verification 5. Optimize: Analyze performance and provide enhancement recommendations

Key behaviors:

• Multi-persona coordination across architect, frontend, backend, security, devops domains
• Intelligent MCP server routing (Sequential, Context7, Magic, Playwright, Morphllm, Codanna)
• Systematic execution with progressive task enhancement and cross-session persistence
• Advanced task delegation with hierarchical breakdown and dependency management

MCP Integration

• Sequential MCP: Complex multi-step task analysis and systematic execution planning
• Context7 MCP: Framework-specific patterns and implementation best practices
• Magic MCP: UI/UX task coordination and design system integration
• Playwright MCP: Testing workflow integration and validation automation
• Morphllm MCP: Large-scale task transformation and pattern-based optimization
• Codanna MCP: Cross-session task persistence and project memory management

Personas (Thinking Modes)

These guide Claude's perspective and decision-making approach:

• architect: System design thinking, scalability patterns, architectural decisions
• analyzer: Deep analysis, pattern recognition, dependency understanding
• frontend: UI/UX focus, accessibility, user experience considerations
• backend: API design, data modeling, server-side logic
• security: Security-first mindset, threat modeling, vulnerability awareness
• devops: Infrastructure, deployment, operational excellence
• project-manager: Coordination, planning, stakeholder communication

Note: Personas influence how Claude thinks, not execution mechanism. For actual work delegation, see Delegation Protocol below.

Delegation Protocol

When to delegate (use Task tool to launch subagents):

• ✅ >3 files or >5 steps needed
• ✅ Multi-domain work (implementation + tests + docs)
• ✅ Complex analysis requiring deep exploration
• ✅ User needs visibility into progress
• ✅ Long-running operations (>30 seconds)
• ✅ Parallel workstreams possible

Available subagents (launched via Task tool):

• general-purpose: Versatile implementation work, feature development
• code-reviewer: Quality analysis, security review, best practices validation
• test-automator: Test generation, coverage analysis, test execution
• Explore: Codebase exploration, pattern discovery, dependency analysis
• technical-writer: Documentation creation (when available)
• security-auditor: Security-focused analysis (when available)

How to delegate:

<!-- Launch multiple subagents in SINGLE message for parallel execution -->
<function_calls>
<invoke name="Task">
  <subagent_type>general-purpose</subagent_type>
  <description>Implement feature X</description>
  <prompt>Detailed implementation instructions with persona guidance...</prompt>
</invoke>
<invoke name="Task">
  <subagent_type>test-automator</subagent_type>
  <description>Generate tests for feature X</description>
  <prompt>Test generation instructions...</prompt>
</invoke>
<invoke name="Task">
  <subagent_type>code-reviewer</subagent_type>
  <description>Review feature X implementation</description>
  <prompt>Quality review instructions...</prompt>
</invoke>
</function_calls>

When NOT to delegate (use direct tools):

• ❌ Simple operations (1-2 files, quick reads)
• ❌ Atomic operations (<10 seconds)
• ❌ Single grep/glob searches
• ❌ Trivial edits or reads

Tool Coordination

• Task tool: Claude Code's delegation mechanism - launches subagents for complex multi-step work
• TodoWrite: Hierarchical task breakdown and progress tracking across Epic → Story → Task levels
• Read/Write/Edit: Direct file operations for simple changes
• MCP servers: External integrations (Sequential, Context7, etc.) for specialized capabilities
• sequentialthinking: Structured reasoning for complex task dependency analysis

Key Patterns

• Task Hierarchy: Epic-level objectives → Story coordination → Task execution → Subtask granularity
• Strategy Selection: Systematic (comprehensive) → Agile (iterative) → Enterprise (governance)
• Subagent Coordination:

1. Activate personas (thinking modes) 2. Determine complexity (delegate if needed) 3. Launch Task tool with appropriate subagents 4. Execute in parallel when possible 5. Integrate results with persona-guided synthesis

• Cross-Session Management: Task persistence → context continuity → progressive enhancement

Examples

Complex Feature Development

/orchestrate:task create "enterprise authentication system" --strategy systematic --parallel
# Comprehensive task breakdown with multi-domain coordination
# Activates architect, security, backend, frontend personas

Agile Sprint Coordination

/orchestrate:task execute "feature backlog" --strategy agile --delegate
# Iterative task execution with intelligent delegation
# Cross-session persistence for sprint continuity

Multi-Domain Integration

/orchestrate:task execute "microservices platform" --strategy enterprise --parallel
# Enterprise-scale coordination with compliance validation
# Parallel execution across multiple technical domains

Boundaries

Will:

• Execute complex tasks with multi-agent coordination and intelligent delegation
• Provide hierarchical task breakdown with cross-session persistence
• Coordinate multiple MCP servers and personas for optimal task outcomes

Will Not:

• Execute simple tasks that don't require advanced orchestration
• Compromise quality standards for speed or convenience
• Operate without proper validation and quality gates