Feature Dev Dispatcher

Dispatch feature development through a structured multi-phase workflow covering discovery, clarification, architecture design, implementation, testing, and code review.

When to Use This Command

Run this command when...

• You are starting a new feature and want a disciplined process that asks clarifying questions before writing any code
• The feature has ambiguities or edge cases that need to be identified and resolved before implementation begins
• You want Claude to follow a phased approach: understand first, design second, implement third, test fourth
• You need comprehensive test coverage generated alongside the feature code
• You want an implementation that reads the codebase deeply before making architectural decisions

Quick Start

Copy
# .claude/commands/feature-dev-dispatcher.md
---
name: Feature Dev Dispatcher
description: Multi-phase feature development with discovery and clarification
command: true
---
Implement this feature using a phased approach: $ARGUMENTS

Phase 1 - Discovery: Read codebase, identify patterns
Phase 2 - Clarification: Ask about ambiguities and edge cases
Phase 3 - Architecture: Design the solution
Phase 4 - Implementation: Write the code
Phase 5 - Testing: Create comprehensive tests
Phase 6 - Review: Self-review and polish

Copy
# Invoke the command
claude "/feature-dev-dispatcher implement real-time notifications via WebSockets"

# Expected output
# > Phase 1: Scanning codebase for messaging patterns...
# > Found: EventEmitter base, Redis pub/sub, existing SSE endpoint
# > Phase 2: Questions identified:
# >   - Should notifications persist to database or be ephemeral?
# >   - What authentication mechanism for WebSocket connections?
# >   - Maximum concurrent connections per user?
# > [Awaiting answers before proceeding...]

Core Concepts

Concept	Description
Phased Execution	Six distinct phases prevent premature coding before understanding requirements
Clarification Gate	Pauses to ask specific questions rather than making assumptions about behavior
Agent Delegation	Launches sub-agents for discovery, reads their file lists to build deep context
TodoWrite Tracking	Uses built-in todo system to track progress across all phases
Self-Review	Final phase reviews implementation for consistency, edge cases, and code quality

Feature Dev Dispatch Flow
=========================

  [Discovery] --> [Clarification] --> [Architecture] --> [Implement]
       |                |                   |                 |
  Read codebase    Ask questions       Design solution    Write code
  Map patterns     Wait for answers    Plan components    Follow design
  List key files   Resolve ambiguity   Define interfaces  Track todos
                                                              |
                                            [Review] <-- [Testing]
                                               |             |
                                          Self-review    Unit tests
                                          Polish code    Integration
                                          Final check    Coverage

Configuration

Parameter	Description	Default	Example	Required
$ARGUMENTS	Feature description with requirements and constraints	none	"add OAuth2 login with Google"	Yes
skip_clarification	Bypass the question-asking phase	false	true	No
test_coverage_target	Minimum code coverage percentage for generated tests	80	90	No
review_depth	Thoroughness of the self-review phase	standard	"deep", "quick"	No
phase_limit	Maximum number of phases to execute before pausing	6	4	No

Best Practices

1. Answer clarification questions thoroughly -- The dispatcher pauses at Phase 2 to ask about ambiguities. Detailed answers here prevent rework later and lead to more accurate implementations.

2. Provide context about existing integrations -- Mention related systems in your arguments. "Add notifications, we already use Redis for caching and have a WebSocket library installed" helps the discovery phase converge faster.

3. Use for medium-to-large features -- Simple one-file changes do not benefit from six phases. Reserve this dispatcher for features spanning three or more files or requiring new architectural patterns.

4. Review the architecture phase output -- After Phase 3, the dispatcher presents its planned architecture. This is the cheapest point to redirect the approach before code is written.

5. Track progress with external tools -- Combine with the log or report commands to push phase completion data to Linear, Jira, or GitHub Issues for team visibility.

Common Issues

Dispatcher asks too many questions: If Phase 2 generates an overwhelming number of clarifications, your initial description may be too vague. Provide more specific requirements upfront to reduce ambiguity.

Discovery phase misses relevant files: Large monorepos can cause the discovery agent to overlook files in distant directories. Add directory hints in your arguments: "check src/services/notifications/ and packages/shared/events/."

Implementation diverges from architecture: Occasionally the coding phase makes decisions that contradict the Phase 3 design. Review the todo list after Phase 4 and compare against the architecture plan to catch inconsistencies early.