Task Planner Consultant

An agent that creates actionable, verified task plans for software development work, producing structured plan checklists, implementation details, and ready-to-use implementation prompts based on thorough research of the codebase and requirements.

When to Use This Agent

Choose Task Planner Consultant when:

• Breaking down complex features into implementable task plans
• Creating structured implementation checklists for development teams
• Generating implementation prompts that can be fed to coding agents
• Planning multi-file changes that need careful sequencing
• Documenting implementation details before handing off to developers

Consider alternatives when:

• Implementing code directly without planning (use a development agent)
• Doing pure research without generating action plans (use a research agent)
• Creating product requirements from business needs (use a PRD agent)

Quick Start

Copy
# .claude/agents/task-planner-consultant.yml
name: Task Planner Consultant
model: claude-sonnet-4-20250514
tools:
  - Read
  - Write
  - Bash
  - Glob
  - Grep
prompt: |
  You are a task planning specialist. Create actionable task plans
  based on verified research. Write three files for each task:
  plan checklist, implementation details, and implementation prompt.
  CRITICAL: Verify research exists before creating plans. Never
  plan without understanding the current codebase state.

Example invocation:

Copy
claude --agent task-planner-consultant "Plan the implementation
  of a rate limiting system for our API. Research the current
  middleware stack, database layer, and existing auth patterns
  before creating the plan."

Core Concepts

Planning Workflow

Research → Analyze → Plan → Document → Deliver
    │          │        │       │          │
  Read code  Dependencies  Sequence  Checklist   Plan file
  Understand Risks         Order     Details     Details file
  Patterns   Blockers      Parallel  Code refs   Prompt file
  Constraints Impact       Critical  Test plan   Ready for dev

Plan Output Structure

.copilot-tracking/
├── plans/
│   └── {task-name}-plan.md        # Checklist with status tracking
├── details/
│   └── {task-name}-details.md     # Implementation specifics
└── prompts/
    └── {task-name}-prompt.md      # Ready-to-use coding prompt

Plan Checklist Format

Copy
# Plan: {Task Name}

## Prerequisites
- [ ] Research existing middleware stack
- [ ] Identify affected endpoints

## Implementation Steps
- [ ] Step 1: Create rate limiter middleware
  - File: `src/middleware/rateLimiter.ts`
  - Dependencies: none
  - Risk: low
- [ ] Step 2: Add Redis store for rate limit counters
  - File: `src/services/rateLimitStore.ts`
  - Dependencies: Step 1
  - Risk: medium (new infrastructure)
- [ ] Step 3: Wire middleware into route definitions
  - Files: `src/routes/*.ts`
  - Dependencies: Steps 1-2
  - Risk: low

## Verification
- [ ] Unit tests for rate limiter logic
- [ ] Integration test with Redis
- [ ] Load test to verify limits work under concurrency

Configuration

Parameter	Description	Default
output_dir	Plan files output directory	.copilot-tracking/
research_required	Require verified research before planning	true
detail_level	Implementation detail depth	High
include_prompt	Generate implementation prompt	true
risk_assessment	Include risk ratings per step	true
dependency_tracking	Track inter-step dependencies	true
test_plan	Include verification steps	true

Best Practices

1. Research the existing codebase before writing any plan. Read the actual files, understand the patterns in use, and verify your assumptions. A plan that assumes Express middleware when the project uses Fastify wastes everyone's time. Spend 60% of your time on research and 40% on planning. Plans built on accurate understanding of the current state succeed; plans built on assumptions fail.

2. Sequence tasks by dependency, not by difficulty. The natural temptation is to start with the easy tasks, but independent tasks should be grouped for parallel execution, and dependent tasks must be sequenced regardless of difficulty. If Step 3 depends on Step 1's output, no amount of parallelism helps. Explicitly mark dependencies so developers know which tasks can run concurrently.

3. Include specific file paths and code references in every step. "Add rate limiting to the API" is a wish. "Create src/middleware/rateLimiter.ts with a sliding window counter, wire it into src/routes/api.ts before the auth middleware" is a plan. Developers should be able to open the referenced files and start implementing without searching the codebase to figure out where things go.

4. Write the implementation prompt so a coding agent can execute it. The prompt file should contain enough context that an AI coding agent can implement the plan without additional research. Include the current file contents, the expected changes, the patterns to follow, and the test criteria. A good implementation prompt produces working code on the first attempt.

5. Assign risk ratings and mitigation strategies to each step. Not all steps carry equal risk. A new database migration is riskier than adding a log statement. Tag high-risk steps with specific mitigation strategies: "create migration branch first," "add feature flag," "run load test before merging." Risk-aware plans help teams allocate review attention where it matters most.

Common Issues

Plans become outdated as the codebase changes during implementation. Long-running implementations diverge from the original plan. Mitigate by breaking plans into small, independently deliverable chunks (each implementable in 1-2 days). Update the plan when significant codebase changes occur. Use the checklist format so completed items remain stable while remaining items can be adjusted.

Plans are too detailed, leaving no room for developer judgment. Over-specified plans feel micromanagerial and may miss better approaches that developers discover during implementation. Specify what to achieve and which files to modify, but leave implementation details flexible. "Add a sliding window rate limiter to the API middleware" tells developers what to build; specifying every variable name tells them how to type.

Research phase takes too long before any plan is produced. Set a research time budget proportional to task complexity. For a 2-day implementation task, spend no more than 2 hours researching. Start writing the plan once you understand the affected files, existing patterns, and key constraints. You don't need to understand the entire codebase—just the blast radius of the change.