Feature Dev — 7-Phase Structured Feature Development
Systematic Feature Workflow with Parallel Agents
Guides feature development through 7 structured phases using 3 specialized agents — a code explorer for codebase analysis, a code architect for design, and a code reviewer for quality assurance — with parallel exploration and iterative refinement.
🎯 7-Phase Workflow🔎 Parallel Exploration🏗️ Architecture Design✅ Quality Review
📚 What is this & why does it exist?
Feature Dev enforces a disciplined approach to building features in large codebases. Rather than diving straight into coding, it mandates understanding the existing code first (via parallel code-explorer agents), designing the architecture explicitly (via code-architect), implementing in small focused steps, and reviewing quality (via code-reviewer with Opus). Each phase produces artifacts that feed the next, preventing the “just hack it in” anti-pattern.
💡 Real-world analogy
Imagine building an addition to a house. You wouldn't start hammering immediately. First, you survey the existing structure (Phase 1-2: code-explorer scouts the codebase). Then an architect draws blueprints (Phase 3-4: code-architect designs the solution). Next, contractors build it phase by phase (Phase 5: implementation). Finally, a building inspector verifies everything is up to code (Phase 6-7: code-reviewer checks quality). Feature Dev is that building process for software.
Architecture
flowchart TB
subgraph Phase1_2["Phase 1-2: Discovery"]
P1["Phase 1: Understand Request"] --> P2["Phase 2: Explore Codebase"]
P2 --> EX1["code-explorer ×3"]
end
subgraph Phase3_4["Phase 3-4: Design"]
EX1 --> P3["Phase 3: Architecture Design"]
P3 --> ARCH["code-architect"]
ARCH --> P4["Phase 4: Implementation Plan"]
end
subgraph Phase5["Phase 5: Build"]
P4 --> P5["Phase 5: Implementation"]
P5 --> CODE["Write Code"]
end
subgraph Phase6_7["Phase 6-7: Review"]
CODE --> P6["Phase 6: Quality Review"]
P6 --> REV["code-reviewer"]
REV --> P7["Phase 7: Polish & Commit"]
end
Key Components
| Component | File | Role |
|---|---|---|
feature-dev | commands/feature-dev.md | Main command — accepts feature description, orchestrates 7 phases |
code-explorer | agents/code-explorer.md | Codebase analysis agent (Sonnet model), uses Read/Grep/Glob tools |
code-architect | agents/code-architect.md | Architecture design agent (Sonnet model), produces implementation blueprints |
code-reviewer | agents/code-reviewer.md | Quality review agent (Opus model), checks logic, tests, and edge cases |
plugin.json | .claude-plugin/plugin.json | Plugin manifest registering command and agents |
README.md | README.md | Usage guide with examples and phase descriptions |
Agent Configuration Details
| Agent | Model | Tools | Parallel Count |
|---|---|---|---|
code-explorer | Sonnet | Read, Grep, Glob, LS, Bash (read-only) | Up to 3 parallel instances |
code-architect | Sonnet | Read, Grep, Glob, Write (design docs only) | 1 instance |
code-reviewer | Opus | Read, Grep, Glob, Bash (test runner) | 1 instance |
Workflow Example
Basic Usage
The /feature-dev command accepts a natural-language feature description and guides the entire development process through 7 structured phases.
# Start a feature development workflow
/feature-dev "Add JWT authentication to the API layer"
# With more specific description
/feature-dev "Implement rate limiting middleware with Redis backend, \
supporting per-user and per-endpoint limits"
# The command will automatically:
# 1. Parse your request into requirements
# 2. Launch 3 parallel code-explorers
# 3. Design architecture via code-architect
# 4. Create implementation plan
# 5. Write the code
# 6. Review with code-reviewer (Opus)
# 7. Polish and prepare commit
Phase Output Artifacts
Phase 2: Exploration Report
Each code-explorer instance produces a focused report:
- Relevant file inventory with descriptions
- Existing patterns that should be followed
- Dependencies and import chains
- Test patterns used in the project
Phase 3: Architecture Blueprint
The code-architect produces a structured design:
- Component diagram with interfaces
- Data flow between new and existing modules
- API surface area (functions, types, exports)
- Migration path for existing code
Phase 6: Quality Report
The code-reviewer (Opus) produces findings:
- Logic correctness analysis
- Edge cases and error handling gaps
- Test coverage assessment
- Performance and security observations
Explorer Assignment Strategies
| Explorer Instance | Focus Area | Search Pattern |
|---|---|---|
| Explorer 1 | Domain patterns | Searches for similar features, existing implementations, and domain models |
| Explorer 2 | Infrastructure | Analyzes routing, middleware, configuration, and deployment patterns |
| Explorer 3 | Testing patterns | Reviews test structure, fixtures, mocks, and assertion patterns |
Data Flow
sequenceDiagram
participant Dev as Developer
participant Cmd as /feature-dev
participant EX as code-explorer (x3)
participant AR as code-architect
participant RV as code-reviewer
participant Git as Git
Dev->>Cmd: /feature-dev "Add user auth"
Note over Cmd: Phase 1: Parse request
Cmd->>Cmd: Read CLAUDE.md guidelines
Note over Cmd: Phase 2: Explore codebase
par Parallel Exploration
Cmd->>EX: Explore auth patterns
Cmd->>EX: Explore API routes
Cmd->>EX: Explore test patterns
end
EX-->>Cmd: Exploration reports
Note over Cmd: Phase 3: Design
Cmd->>AR: Design architecture
AR-->>Cmd: Architecture blueprint
Note over Cmd: Phase 4: Plan
Cmd->>Cmd: Break into implementation steps
Note over Cmd: Phase 5: Implement
Cmd->>Cmd: Write code (Edit, Write tools)
Note over Cmd: Phase 6: Review
Cmd->>RV: Review implementation
RV-->>Cmd: Quality report + suggestions
Note over Cmd: Phase 7: Polish
Cmd->>Git: git diff (verify changes)
Cmd-->>Dev: Summary + commit message
Design Patterns Enforced
The feature-dev workflow encourages several design patterns through its phased approach:
| Pattern | Phase | How It's Enforced |
|---|---|---|
| Understand Before Coding | 1-2 | Exploration must complete before any code is written |
| Design Before Build | 3-4 | Architecture blueprint required before implementation begins |
| Small Focused Changes | 5 | Implementation plan breaks work into discrete, reviewable steps |
| Review Before Ship | 6-7 | Opus-powered review catches issues before commit |
| Convention Conformity | All | CLAUDE.md guidelines consulted at every phase |
Error Recovery
If any phase fails or produces insufficient results:
- Explorer failure: Re-run with adjusted search patterns and expanded scope
- Architect rejection: Return to Phase 2 with additional exploration questions
- Reviewer findings: Loop back to Phase 5 to address issues, then re-review
- Build failures: Diagnose with Bash tool, fix, and re-verify before Phase 7
Interactions
| Module | Interface | Data Exchanged |
|---|---|---|
| Git | git diff | Tracks changes made during implementation phase |
| CLAUDE.md | File read | Project coding standards and conventions |
| Claude Code Tools | Read, Grep, Glob | Codebase exploration and analysis |
| Claude Code Tools | Edit, Write | Code implementation during Phase 5 |
| Claude Code Tools | Bash | Running tests, builds, and linters during review |
Phase Reference
Detailed Phase Breakdown
Each phase has specific entry criteria, activities, and exit deliverables that gate progression to the next phase.
| Phase | Name | Agent | Output |
|---|---|---|---|
| 1 | Understand Request | Main | Parsed requirements, success criteria |
| 2 | Explore Codebase | code-explorer ×3 | Exploration reports, pattern analysis |
| 3 | Architecture Design | code-architect | Design document with component diagram |
| 4 | Implementation Plan | Main | Ordered list of implementation steps |
| 5 | Implementation | Main | Working code changes |
| 6 | Quality Review | code-reviewer | Quality report, bug findings, suggestions |
| 7 | Polish & Commit | Main | Final diff, commit message, summary |
Configuration Reference
Agent Model Selection
Model selection follows a cost-quality optimization: Sonnet handles high-volume exploration and design tasks efficiently, while Opus is reserved for the single code-reviewer pass where reasoning depth has the highest impact on finding subtle bugs.
| Parameter | Default | Description |
|---|---|---|
explorer.model | sonnet | Model for code-explorer agents (cost-efficient analysis) |
architect.model | sonnet | Model for code-architect (design quality) |
reviewer.model | opus | Model for code-reviewer (highest quality review) |
explorer.parallel | 3 | Number of parallel code-explorer instances |
explorer.tools | Read,Grep,Glob,LS,Bash | Tools available to explorer agents |
architect.tools | Read,Grep,Glob,Write | Tools available to architect agent |
reviewer.tools | Read,Grep,Glob,Bash | Tools available to reviewer agent (includes test runner) |
Directory Map
Source tree for Feature Dev
feature-dev/
├── .claude-plugin/plugin.json ← Plugin manifest
├── README.md ← Usage guide and examples
├── commands/
│ └── feature-dev.md ← 7-phase orchestration command
└── agents/
├── code-explorer.md ← Codebase analysis (Sonnet, parallel)
├── code-architect.md ← Architecture design (Sonnet)
└── code-reviewer.md ← Quality review (Opus)