Skill v1.0.1
currentAutomated scan100/100+4 new
name: delegate description: Split work across subagents with explicit contracts, interfaces, and merge strategies. Use when parallelizing tasks, distributing workload, or orchestrating multi-agent workflows. argument-hint: "[task] [agent] [constraints]" disable-model-invocation: false user-invocable: true allowed-tools: Read, Grep context: fork agent: explore metadata: version: "1.0.1"
Intent
Delegate a complex task to one or more subagents by defining clear contracts, input/output interfaces, and strategies for merging results. Ensure coordinated execution with conflict resolution.
Success criteria:
- Task decomposed into delegatable subtasks
- Each subtask has explicit contract (inputs, outputs, constraints)
- Interface between tasks is well-defined
- Merge strategy handles conflicts and failures
- Dependencies between subtasks are clear
Compatible schemas:
schemas/output_schema.yaml
Inputs
| Parameter | Required | Type | Description | |
|---|---|---|---|---|
task | Yes | object | The overall task to delegate | |
agent | Yes | string | Target agent | |
constraints | No | object | Global constraints (timeout, resource limits) | |
fresh_context | No | boolean | Start the delegate without this agent's context, e.g. for an independent review (Standard v1.1 delegation@1) | |
model_family | No | string | Model family the delegate should run on (delegation@1) | |
role | No | string | Role the delegate takes, e.g. reviewer (delegation@1) | |
read_only | No | boolean | The delegate may read but must not change anything (delegation@1); the host attests it in effective.read_only |
Inputs not listed here are outside the capability's contract: a workflow step that binds them gets W604 (STANDARD v1.1 §5.5).
The host reports the settings it actually used as effective in the output; a review quorum (quorum@1, on constrain) relies on them. With wait (wait@1) the step delegates, then waits for that delegate's result, which the output carries as result; a retry delegates again.
Procedure
1) Analyze task: Understand the overall objective
- Identify the goal and success criteria
- Determine if task is parallelizable
- Identify shared state or resources
- Assess complexity and scope
2) Decompose into subtasks: Break into delegatable units
- Each subtask should be independently executable
- Minimize dependencies between subtasks
- Identify natural parallelization boundaries
- Use
decomposecapability patterns
3) Define contracts: Specify expectations for each subtask
- Input: what data/context each subtask receives
- Output: what each subtask must produce
- Constraints: limits on time, resources, scope
- Verification: how to check subtask completion
4) Design interfaces: Specify data flow between subtasks
- Format of inputs and outputs
- Required fields and optional extensions
- Error formats and status codes
- Handoff protocols
5) Plan merge strategy: How to combine results
- Handle successful completions
- Resolve conflicts between subtask outputs
- Aggregate partial results
- Determine final output format
6) Handle failures: Define recovery behavior
- What happens if a subtask fails
- Retry policies and limits
- Fallback strategies
- Partial result handling
7) Establish coordination: Define execution order
- Parallel vs sequential execution
- Dependency ordering
- Synchronization points
- Progress tracking
Output Contract
Return a structured object:
accepted: boolean # Whether the target agent accepted the tasktask_id: string # Delegated task IDagent: string # Assigned agent (the `agent` input)effective: # Delegation settings actually used, as attested by the hostfresh_context: booleanmodel_family: stringrole: stringread_only: booleanresult: object | null # The delegate's result (with its sender) when the step waits for it (wait@1)delegation:task: string # Original task descriptiondelegated_to: array # List of agents/subtasksstatus: pending | running | completed | failedsubtasks:- id: string # Subtask identifieragent: string # Assigned agentcontract:inputs: object # What subtask receivesoutputs: object # What subtask must produceconstraints: object # Limits and requirementsverification: string # How to verify completiondependencies: array[string] # Subtask IDs this depends onstatus: pending | running | completed | failedresult: object | null # Subtask output when completeinterfaces:- from: string # Source subtaskto: string # Destination subtaskformat: object # Data format specificationrequired_fields: array[string]merge_plan:strategy: first_wins | consensus | aggregate | customconflict_resolution: string # How to handle conflictsfinal_output_format: object # Expected merged resultfailure_handling:policy: abort | continue | retrymax_retries: integerfallback: string | nullhandoff_context:- key: string # Context keyvalue: object # Shared context dataconfidence: 0..1evidence_anchors: ["task:analysis", "agent:capability"]assumptions: []
Field Definitions
| Field | Type | Description | |
|---|---|---|---|
accepted | boolean | Whether the target agent accepted the task | |
task_id | string | Identifier of the delegated task | |
agent | string | The agent the task was assigned to | |
effective | object | Settings the host actually used (fresh_context, model_family, role, read_only); a review quorum relies on them | |
result | object | The delegate's result, with its sender (and sender_identity under identity@1), when the step waits for it; otherwise null | |
delegation | object | Overall delegation summary | |
subtasks | array | Individual subtask definitions with contracts | |
interfaces | array | Data flow between subtasks | |
merge_plan | object | Strategy for combining results | |
failure_handling | object | Recovery policies | |
handoff_context | array | Shared context for all subtasks | |
confidence | number | 0.0-1.0 based on delegation clarity | |
evidence_anchors | array | References supporting delegation design | |
assumptions | array | Explicit assumptions about agents/capabilities |
Examples
Example 1: Parallel Code Review
agent names who receives the task: here a review pool that fans it out to the agents the task lists.
Input:
agent: "review-pool"task:description: "Review pull request #123 for security, performance, and style"agents:- id: "security-agent"capabilities: ["security-analysis", "vulnerability-detection"]- id: "perf-agent"capabilities: ["performance-analysis", "profiling"]- id: "style-agent"capabilities: ["lint", "style-check"]constraints:timeout: "10m"max_issues_per_category: 20
Output:
accepted: truetask_id: "deleg-pr123-review"agent: "review-pool"effective:fresh_context: falserole: "reviewer"read_only: trueresult: null # Step does not wait; subtasks are still pendingdelegation:task: "Review pull request #123"delegated_to: ["security-agent", "perf-agent", "style-agent"]status: pendingsubtasks:- id: "security-review"agent: "security-agent"contract:inputs:pr_number: 123files: ["src/**/*.ts"]focus: "security"outputs:issues: "array of {severity, file, line, description}"summary: "string"passed: "boolean"constraints:timeout: "5m"max_issues: 20verification: "issues array is valid, severity in [low, medium, high, critical]"dependencies: []status: pendingresult: null- id: "perf-review"agent: "perf-agent"contract:inputs:pr_number: 123files: ["src/**/*.ts"]focus: "performance"outputs:issues: "array of {severity, file, line, description}"metrics: "object with timing estimates"passed: "boolean"constraints:timeout: "5m"max_issues: 20verification: "issues array is valid, metrics object present"dependencies: []status: pendingresult: null- id: "style-review"agent: "style-agent"contract:inputs:pr_number: 123files: ["src/**/*.ts"]focus: "style"outputs:issues: "array of {severity, file, line, description}"passed: "boolean"constraints:timeout: "3m"max_issues: 20verification: "issues array is valid"dependencies: []status: pendingresult: nullinterfaces:- from: "all_subtasks"to: "merge"format:issues: "array"passed: "boolean"required_fields: ["issues", "passed"]merge_plan:strategy: aggregateconflict_resolution: "Combine all issues, AND passed flags"final_output_format:all_issues: "array (combined)"passed: "boolean (all must pass)"summary: "string (generated)"failure_handling:policy: continuemax_retries: 1fallback: "Return partial results with failed subtask noted"handoff_context:- key: "repository"value: { "owner": "org", "repo": "project" }- key: "base_branch"value: "main"confidence: 0.9evidence_anchors:- "task:pr-review-decomposition"- "agent:security-agent:has-security-analysis"assumptions:- "All agents have access to repository"- "PR #123 exists and is accessible"
Evidence pattern: Task analysis informed decomposition, agent capabilities matched to subtasks.
Example 2: Sequential Data Pipeline
Input:
agent: "pipeline-runner"task:description: "Process customer data: validate, enrich, and store"agents:- id: "validator"- id: "enricher"- id: "persister"merge_strategy: "sequential"
Output:
accepted: truetask_id: "deleg-batch-2024-01-15"agent: "pipeline-runner"effective:fresh_context: falseread_only: falseresult: nulldelegation:task: "Process customer data pipeline"delegated_to: ["validator", "enricher", "persister"]status: pendingsubtasks:- id: "validate-data"agent: "validator"contract:inputs:data: "raw customer records"outputs:valid_records: "array of validated records"invalid_records: "array with error reasons"constraints:schema: "customer_v2"verification: "All valid_records match schema"dependencies: []status: pendingresult: null- id: "enrich-data"agent: "enricher"contract:inputs:records: "${validate-data.valid_records}"outputs:enriched_records: "array with added fields"constraints:enrich_fields: ["company_size", "industry"]verification: "All records have enrich_fields populated"dependencies: ["validate-data"]status: pendingresult: null- id: "store-data"agent: "persister"contract:inputs:records: "${enrich-data.enriched_records}"outputs:stored_count: "integer"storage_location: "string"constraints:destination: "customer_db"verification: "stored_count matches input count"dependencies: ["enrich-data"]status: pendingresult: nullinterfaces:- from: "validate-data"to: "enrich-data"format:records: "array of customer objects"required_fields: ["id", "name", "email"]- from: "enrich-data"to: "store-data"format:records: "array of enriched customer objects"required_fields: ["id", "name", "email", "company_size", "industry"]merge_plan:strategy: customconflict_resolution: "N/A - sequential pipeline"final_output_format:processed: "integer"stored: "integer"errors: "array"failure_handling:policy: abortmax_retries: 0fallback: nullhandoff_context:- key: "batch_id"value: "batch-2024-01-15"confidence: 0.85evidence_anchors:- "task:pipeline-stages"assumptions:- "Enrichment service is available"- "Database has capacity for new records"
Verification
- [ ] All subtasks have complete contracts
- [ ] Dependencies form a valid DAG
- [ ] Interfaces are compatible between connected subtasks
- [ ] Merge strategy handles all expected outputs
- [ ] Failure handling is defined
Verification tools: Read (for contract validation)
Safety Constraints
mutation: falserequires_checkpoint: falserequires_approval: falserisk: medium
Capability-specific rules:
- Never delegate without explicit contracts
- Ensure all subtasks have verification criteria
- Define failure handling before delegation
- Validate interface compatibility
- Do not delegate tasks requiring approval without noting it
Composition Patterns
Commonly follows:
plan- Delegation is often part of plan execution (REQUIRES plan)decompose- Break task before delegatingprioritize- Order subtasks by importance
Commonly precedes:
synchronize- Merge results from delegated subtasksverify- Check all subtasks completed correctlyaudit- Record delegation and outcomes
Anti-patterns:
- Never delegate without failure handling
- Never delegate mutating tasks without noting safety requirements
- Avoid circular dependencies between subtasks
Workflow references:
- See
reference/composition_patterns.md#enrichment-pipelinefor parallel delegation