Expert Task Bot

Your agent for decomposing complex tasks into well-defined, manageable subtasks — breaking down large engineering projects into actionable work items with clear dependencies, estimates, and success criteria.

When to Use This Agent

Choose Expert Task Bot when:

• Decomposing a large feature into sprint-ready tasks
• Breaking down a technical initiative into phased milestones
• Creating task hierarchies with clear dependencies and ordering
• Estimating effort and identifying critical path for project delivery
• Converting vague requirements into concrete, actionable work items

Consider alternatives when:

• You need detailed implementation plans with code — use a planner agent
• You need architecture design — use an architect agent
• You need to create Jira tickets — use an Atlassian agent

Quick Start

Copy
# .claude/agents/task-bot.yml
name: Expert Task Bot
model: claude-sonnet
tools:
  - Read
  - Glob
  - Grep
  - Bash
description: Task decomposition agent for breaking complex projects into actionable, estimated, dependency-mapped work items

Example invocation:

claude "Break down 'Add multi-language support to our app' into tasks — include frontend i18n, backend translation API, CMS integration, and QA for RTL languages"

Core Concepts

Task Decomposition Hierarchy

Epic: Multi-language Support
├── Story: Frontend i18n Framework
│   ├── Task: Install and configure react-i18next
│   ├── Task: Extract all hardcoded strings to translation files
│   ├── Task: Implement language switcher component
│   └── Task: Add RTL layout support for Arabic/Hebrew
├── Story: Backend Translation API
│   ├── Task: Design translation data model
│   ├── Task: Create translation CRUD endpoints
│   └── Task: Implement translation caching layer
├── Story: CMS Integration
│   └── ...
└── Story: QA and Testing
    └── ...

Task Quality Criteria

Criterion	Description	Example
Specific	Clear scope boundaries	"Extract strings from Header component"
Measurable	Has completion criteria	"All 150 strings extracted and rendering from JSON"
Achievable	Completable in 1-3 days	Not "Implement i18n" but "Configure i18next"
Relevant	Contributes to the parent goal	Each task advances multi-language support
Time-bounded	Has an effort estimate	"2-3 hours" or "1 story point"

Configuration

Parameter	Description	Default
decomposition_depth	Breakdown level (epic-story, epic-story-task, full)	epic-story-task
estimation_unit	Effort units (hours, story-points, t-shirt)	story-points
include_dependencies	Map task dependencies	true
include_risks	Flag risky or uncertain tasks	true
output_format	Output (markdown, csv, json, jira-format)	markdown

Best Practices

1. Decompose until each task is completable in 1-3 days. If a task takes more than 3 days, it's too large and should be split further. Small tasks provide frequent progress signals, reduce risk, and make estimation more accurate.

2. Map dependencies explicitly. For each task, note what it depends on (blocked-by) and what it enables (blocks). This reveals the critical path and helps sprint planning avoid blocked work items.

3. Identify and flag uncertain tasks as spikes. When you can't estimate a task because the approach is unknown, create a time-boxed spike task (e.g., "Spike: evaluate RTL CSS framework options — 4 hours") before the implementation task.

4. Include non-obvious tasks. Testing, documentation, migration scripts, monitoring setup, and deployment configuration are real work that's often omitted from task breakdowns. Include them explicitly so they're planned and tracked.

5. Validate decomposition against the codebase. Read the relevant code before finalizing tasks. A task like "add i18n to Header" might need to be split into "add i18n to Header" and "refactor Header string props" if the component structure doesn't support easy string extraction.

Common Issues

Tasks are decomposed too finely, creating overhead. Twenty 30-minute tasks create more coordination overhead than five 3-hour tasks. Find the sweet spot — granular enough to track progress, coarse enough to avoid excessive ceremony.

Dependencies create a sequential chain with no parallelism. When every task depends on the previous one, the critical path equals the total path. Look for tasks that can run in parallel (frontend and backend work, documentation and testing) and reorganize to maximize parallel execution.

Task estimates are consistently wrong. Estimates improve with calibration. Track actual vs estimated time for completed tasks, and adjust future estimates based on your team's velocity multiplier. If tasks consistently take 2x longer, your estimates need a 2x adjustment.