Skip to main content
The Feature Development Plugin provides a systematic 7-phase approach to building new features. Instead of jumping straight into code, it guides you through understanding the codebase, asking clarifying questions, designing architecture, and ensuring quality.

​
Overview

Building features requires more than just writing code. This plugin embeds these practices into a structured workflow:
  • Understand the codebase before making changes
  • Ask questions to clarify ambiguous requirements
  • Design thoughtfully before implementing
  • Review for quality after building
Philosophy: Better-designed features that integrate seamlessly with your existing code.

​
Command: /feature-dev

Launches a guided feature development workflow with 7 distinct phases.

​
Usage

With a feature description: 
/feature-dev Add user authentication with OAuth
Or let the command ask interactively: 
/feature-dev

​
The 7-Phase Workflow

​
Phase 1: Discovery

Goal: Understand what needs to be built
  • Clarifies the feature request if it’s unclear
  • Asks what problem you’re solving
  • Identifies constraints and requirements
  • Summarizes understanding and confirms with you
Example: 
You: /feature-dev Add caching
Claude: Let me understand what you need...
        - What should be cached? (API responses, computed values, etc.)
        - What are your performance requirements?
        - Do you have a preferred caching solution?

​
Phase 2: Codebase Exploration

Goal: Understand relevant existing code and patterns
1

Launch Explorers

Launches 2-3 code-explorer agents in parallel to explore different aspects
2

Comprehensive Analysis

Agents return analyses with key files to read
3

Deep Understanding

Claude reads all identified files to build deep understanding
4

Present Findings

Comprehensive summary of findings with file references
Example Output: 
Found similar features:
- User authentication (src/auth/): Uses JWT tokens, middleware pattern
- Session management (src/session/): Redis-backed, 24hr expiry
- API security (src/api/middleware/): Rate limiting, CORS

Key files to understand:
- src/auth/AuthService.ts:45 - Core authentication logic
- src/middleware/authMiddleware.ts:12 - Request authentication
- src/config/security.ts:8 - Security configuration

​
Phase 3: Clarifying Questions

Goal: Fill in gaps and resolve all ambiguities
  • Reviews codebase findings and feature request
  • Identifies underspecified aspects:
    • Edge cases
    • Error handling
    • Integration points
    • Backward compatibility
    • Performance needs
  • Waits for your answers before proceeding
Example: 
Before designing the architecture, I need to clarify:

1. OAuth provider: Which OAuth providers? (Google, GitHub, custom?)
2. User data: Store OAuth tokens or just user profile?
3. Existing auth: Replace current auth or add alongside?
4. Sessions: Integrate with existing session management?
5. Error handling: How to handle OAuth failures?
This phase ensures nothing is ambiguous before design begins. Answer thoughtfully!

​
Phase 4: Architecture Design

Goal: Design multiple implementation approaches
1

Launch Architects

Launches 2-3 code-architect agents with different focuses:
  • Minimal changes: Smallest change, maximum reuse
  • Clean architecture: Maintainability, elegant abstractions
  • Pragmatic balance: Speed + quality
2

Review Approaches

Reviews all approaches and forms opinion on which fits best
3

Present Comparison

Shows trade-offs and provides recommendation
4

Ask for Choice

Asks which approach you prefer
Example Output: 
I've designed 3 approaches:

Approach 1: Minimal Changes
- Extend existing AuthService with OAuth methods
- Add new OAuth routes to existing auth router
Pros: Fast, low risk
Cons: Couples OAuth to existing auth, harder to test

Approach 2: Clean Architecture
- New OAuthService with dedicated interface
- Separate OAuth router and middleware
Pros: Clean separation, testable, maintainable
Cons: More files, more refactoring

Approach 3: Pragmatic Balance
- New OAuthProvider abstraction
- Integrate into existing AuthService
Pros: Balanced complexity and cleanliness
Cons: Some coupling remains

Recommendation: Approach 3

Which approach would you like to use?

​
Phase 5: Implementation

Goal: Build the feature
  • Waits for explicit approval before starting
  • Reads all relevant files identified in previous phases
  • Implements following chosen architecture
  • Follows codebase conventions strictly
  • Writes clean, well-documented code
  • Updates todos as progress is made
Implementation only starts after you approve. Uses architecture from Phase 4 and patterns from Phase 2.

​
Phase 6: Quality Review

Goal: Ensure code is simple, DRY, elegant, and functionally correct
1

Launch Reviewers

Launches 3 code-reviewer agents in parallel:
  • Simplicity/DRY/Elegance: Code quality and maintainability
  • Bugs/Correctness: Functional correctness and logic errors
  • Conventions/Abstractions: Project standards and patterns
2

Consolidate Findings

Identifies highest severity issues
3

Present and Ask

Shows findings and asks what you want to do:
  • Fix now
  • Fix later
  • Proceed as-is
4

Address Issues

Addresses issues based on your decision
Example Output: 
Code Review Results:

High Priority Issues:
1. Missing error handling in OAuth callback (src/auth/oauth.ts:67)
2. Memory leak: OAuth state not cleaned up (src/auth/oauth.ts:89)

Medium Priority:
1. Could simplify token refresh logic (src/auth/oauth.ts:120)
2. Consider extracting OAuth config validation

All tests pass. Code follows project conventions.

What would you like to do?

​
Phase 7: Summary

Goal: Document what was accomplished
  • Marks all todos complete
  • Summarizes:
    • What was built
    • Key decisions made
    • Files modified
    • Suggested next steps
Example: 
Feature Complete: OAuth Authentication

What was built:
- OAuth provider abstraction supporting Google and GitHub
- OAuth routes and middleware integrated with existing auth
- Token refresh and session integration
- Error handling for all OAuth flows

Key decisions:
- Used pragmatic approach with OAuthProvider abstraction
- Integrated with existing session management
- Added OAuth state to prevent CSRF

Files modified:
- src/auth/OAuthProvider.ts (new)
- src/auth/AuthService.ts
- src/routes/auth.ts
- src/middleware/authMiddleware.ts

Suggested next steps:
- Add tests for OAuth flows
- Add more OAuth providers (Microsoft, Apple)
- Update documentation

​
Agents

​
code-explorer

Purpose: Deeply analyzes existing codebase features by tracing execution paths Focus Areas:
  • Entry points and call chains
  • Data flow and transformations
  • Architecture layers and patterns
  • Dependencies and integrations
  • Implementation details
Output:
  • Entry points with file:line references
  • Step-by-step execution flow
  • Key components and responsibilities
  • Architecture insights
  • List of essential files to read

​
code-architect

Purpose: Designs feature architectures and implementation blueprints Focus Areas:
  • Codebase pattern analysis
  • Architecture decisions
  • Component design
  • Implementation roadmap
  • Data flow and build sequence
Output:
  • Patterns and conventions found
  • Architecture decision with rationale
  • Complete component design
  • Implementation map with specific files
  • Build sequence with phases

​
code-reviewer

Purpose: Reviews code for bugs, quality issues, and project conventions Focus Areas:
  • Project guideline compliance (CLAUDE.md)
  • Bug detection
  • Code quality issues
  • Confidence-based filtering (only reports high-confidence issues ≥ 80)
Output:
  • Critical issues (confidence 75-100)
  • Important issues (confidence 50-74)
  • Specific fixes with file:line references
  • Project guideline references

​
Usage Patterns

/feature-dev Add rate limiting to API endpoints
Let the workflow guide you through all 7 phases.

​
Manual Agent Invocation

You can also invoke agents manually: 
"Launch code-explorer to trace how authentication works"
"Launch code-architect to design the caching layer"
"Launch code-reviewer to check my recent changes"

​
Best Practices

Use Full Workflow

For complex features, the 7 phases ensure thorough planning

Answer Thoughtfully

Phase 3 clarifying questions prevent future confusion

Choose Deliberately

Phase 4 gives you architecture options for a reason

Don't Skip Review

Phase 6 catches issues before they reach production

​
When to Use

Use for:
  • New features that touch multiple files
  • Features requiring architectural decisions
  • Complex integrations with existing code
  • Features where requirements are somewhat unclear
Don’t use for:
  • Single-line bug fixes
  • Trivial changes
  • Well-defined, simple tasks
  • Urgent hotfixes

​
Troubleshooting

​
Agents Take Too Long

Issue: Code exploration or architecture agents are slow Solution:
  • This is normal for large codebases
  • Agents run in parallel when possible
  • The thoroughness pays off in better understanding

​
Too Many Clarifying Questions

Issue: Phase 3 asks too many questions Solution:
  • Be more specific in your initial feature request
  • Provide context about constraints upfront
  • Say “whatever you think is best” if truly no preference

​
Architecture Options Overwhelming

Issue: Too many architecture options in Phase 4 Solution:
  • Trust the recommendation—it’s based on codebase analysis
  • If still unsure, ask for more explanation
  • Pick the pragmatic option when in doubt

​
Plugin Information

Author: Sid Bidasaria ([email protected])
Version: 1.0.0

Build docs developers (and LLMs) love

Get started for freeTalk to us