surshar / claude-code
Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands.
Built by Anthropic · github.com/anthropics
| 1 | # Feature Development Plugin |
| 2 | |
| 3 | A comprehensive, structured workflow for feature development with specialized agents for codebase exploration, architecture design, and quality review. |
| 4 | |
| 5 | ## Overview |
| 6 | |
| 7 | 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—resulting in better-designed features that integrate seamlessly with your existing code. |
| 8 | |
| 9 | ## Philosophy |
| 10 | |
| 11 | Building features requires more than just writing code. You need to: |
| 12 | - **Understand the codebase** before making changes |
| 13 | - **Ask questions** to clarify ambiguous requirements |
| 14 | - **Design thoughtfully** before implementing |
| 15 | - **Review for quality** after building |
| 16 | |
| 17 | This plugin embeds these practices into a structured workflow that runs automatically when you use the `/feature-dev` command. |
| 18 | |
| 19 | ## Command: `/feature-dev` |
| 20 | |
| 21 | Launches a guided feature development workflow with 7 distinct phases. |
| 22 | |
| 23 | **Usage:** |
| 24 | ```bash |
| 25 | /feature-dev Add user authentication with OAuth |
| 26 | ``` |
| 27 | |
| 28 | Or simply: |
| 29 | ```bash |
| 30 | /feature-dev |
| 31 | ``` |
| 32 | |
| 33 | The command will guide you through the entire process interactively. |
| 34 | |
| 35 | ## The 7-Phase Workflow |
| 36 | |
| 37 | ### Phase 1: Discovery |
| 38 | |
| 39 | **Goal**: Understand what needs to be built |
| 40 | |
| 41 | **What happens:** |
| 42 | - Clarifies the feature request if it's unclear |
| 43 | - Asks what problem you're solving |
| 44 | - Identifies constraints and requirements |
| 45 | - Summarizes understanding and confirms with you |
| 46 | |
| 47 | **Example:** |
| 48 | ``` |
| 49 | You: /feature-dev Add caching |
| 50 | Claude: Let me understand what you need... |
| 51 | - What should be cached? (API responses, computed values, etc.) |
| 52 | - What are your performance requirements? |
| 53 | - Do you have a preferred caching solution? |
| 54 | ``` |
| 55 | |
| 56 | ### Phase 2: Codebase Exploration |
| 57 | |
| 58 | **Goal**: Understand relevant existing code and patterns |
| 59 | |
| 60 | **What happens:** |
| 61 | - Launches 2-3 `code-explorer` agents in parallel |
| 62 | - Each agent explores different aspects (similar features, architecture, UI patterns) |
| 63 | - Agents return comprehensive analyses with key files to read |
| 64 | - Claude reads all identified files to build deep understanding |
| 65 | - Presents comprehensive summary of findings |
| 66 | |
| 67 | **Agents launched:** |
| 68 | - "Find features similar to [feature] and trace implementation" |
| 69 | - "Map the architecture and abstractions for [area]" |
| 70 | - "Analyze current implementation of [related feature]" |
| 71 | |
| 72 | **Example output:** |
| 73 | ``` |
| 74 | Found similar features: |
| 75 | - User authentication (src/auth/): Uses JWT tokens, middleware pattern |
| 76 | - Session management (src/session/): Redis-backed, 24hr expiry |
| 77 | - API security (src/api/middleware/): Rate limiting, CORS |
| 78 | |
| 79 | Key files to understand: |
| 80 | - src/auth/AuthService.ts:45 - Core authentication logic |
| 81 | - src/middleware/authMiddleware.ts:12 - Request authentication |
| 82 | - src/config/security.ts:8 - Security configuration |
| 83 | ``` |
| 84 | |
| 85 | ### Phase 3: Clarifying Questions |
| 86 | |
| 87 | **Goal**: Fill in gaps and resolve all ambiguities |
| 88 | |
| 89 | **What happens:** |
| 90 | - Reviews codebase findings and feature request |
| 91 | - Identifies underspecified aspects: |
| 92 | - Edge cases |
| 93 | - Error handling |
| 94 | - Integration points |
| 95 | - Backward compatibility |
| 96 | - Performance needs |
| 97 | - Presents all questions in an organized list |
| 98 | - **Waits for your answers before proceeding** |
| 99 | |
| 100 | **Example:** |
| 101 | ``` |
| 102 | Before designing the architecture, I need to clarify: |
| 103 | |
| 104 | 1. OAuth provider: Which OAuth providers? (Google, GitHub, custom?) |
| 105 | 2. User data: Store OAuth tokens or just user profile? |
| 106 | 3. Existing auth: Replace current auth or add alongside? |
| 107 | 4. Sessions: Integrate with existing session management? |
| 108 | 5. Error handling: How to handle OAuth failures? |
| 109 | ``` |
| 110 | |
| 111 | **Critical**: This phase ensures nothing is ambiguous before design begins. |
| 112 | |
| 113 | ### Phase 4: Architecture Design |
| 114 | |
| 115 | **Goal**: Design multiple implementation approaches |
| 116 | |
| 117 | **What happens:** |
| 118 | - Launches 2-3 `code-architect` agents with different focuses: |
| 119 | - **Minimal changes**: Smallest change, maximum reuse |
| 120 | - **Clean architecture**: Maintainability, elegant abstractions |
| 121 | - **Pragmatic balance**: Speed + quality |
| 122 | - Reviews all approaches |
| 123 | - Forms opinion on which fits best for this task |
| 124 | - Presents comparison with trade-offs and recommendation |
| 125 | - **Asks which approach you prefer** |
| 126 | |
| 127 | **Example output:** |
| 128 | ``` |
| 129 | I've designed 3 approaches: |
| 130 | |
| 131 | Approach 1: Minimal Changes |
| 132 | - Extend existing AuthService with OAuth methods |
| 133 | - Add new OAuth routes to existing auth router |
| 134 | - Minimal refactoring required |
| 135 | Pros: Fast, low risk |
| 136 | Cons: Couples OAuth to existing auth, harder to test |
| 137 | |
| 138 | Approach 2: Clean Architecture |
| 139 | - New OAuthService with dedicated interface |
| 140 | - Separate OAuth router and middleware |
| 141 | - Refactor AuthService to use common interface |
| 142 | Pros: Clean separation, testable, maintainable |
| 143 | Cons: More files, more refactoring |
| 144 | |
| 145 | Approach 3: Pragmatic Balance |
| 146 | - New OAuthProvider abstraction |
| 147 | - Integrate into existing AuthService |
| 148 | - Minimal refactoring, good boundaries |
| 149 | Pros: Balanced complexity and cleanliness |
| 150 | Cons: Some coupling remains |
| 151 | |
| 152 | Recommendation: Approach 3 - gives you clean boundaries without |
| 153 | excessive refactoring, and fits your existing architecture well. |
| 154 | |
| 155 | Which approach would you like to use? |
| 156 | ``` |
| 157 | |
| 158 | ### Phase 5: Implementation |
| 159 | |
| 160 | **Goal**: Build the feature |
| 161 | |
| 162 | **What happens:** |
| 163 | - **Waits for explicit approval** before starting |
| 164 | - Reads all relevant files identified in previous phases |
| 165 | - Implements following chosen architecture |
| 166 | - Follows codebase conventions strictly |
| 167 | - Writes clean, well-documented code |
| 168 | - Updates todos as progress is made |
| 169 | |
| 170 | **Notes:** |
| 171 | - Implementation only starts after you approve |
| 172 | - Follows patterns discovered in Phase 2 |
| 173 | - Uses architecture designed in Phase 4 |
| 174 | - Continuously tracks progress |
| 175 | |
| 176 | ### Phase 6: Quality Review |
| 177 | |
| 178 | **Goal**: Ensure code is simple, DRY, elegant, and functionally correct |
| 179 | |
| 180 | **What happens:** |
| 181 | - Launches 3 `code-reviewer` agents in parallel with different focuses: |
| 182 | - **Simplicity/DRY/Elegance**: Code quality and maintainability |
| 183 | - **Bugs/Correctness**: Functional correctness and logic errors |
| 184 | - **Conventions/Abstractions**: Project standards and patterns |
| 185 | - Consolidates findings |
| 186 | - Identifies highest severity issues |
| 187 | - **Presents findings and asks what you want to do**: |
| 188 | - Fix now |
| 189 | - Fix later |
| 190 | - Proceed as-is |
| 191 | - Addresses issues based on your decision |
| 192 | |
| 193 | **Example output:** |
| 194 | ``` |
| 195 | Code Review Results: |
| 196 | |
| 197 | High Priority Issues: |
| 198 | 1. Missing error handling in OAuth callback (src/auth/oauth.ts:67) |
| 199 | 2. Memory leak: OAuth state not cleaned up (src/auth/oauth.ts:89) |
| 200 | |
| 201 | Medium Priority: |
| 202 | 1. Could simplify token refresh logic (src/auth/oauth.ts:120) |
| 203 | 2. Consider extracting OAuth config validation |
| 204 | |
| 205 | All tests pass. Code follows project conventions. |
| 206 | |
| 207 | What would you like to do? |
| 208 | ``` |
| 209 | |
| 210 | ### Phase 7: Summary |
| 211 | |
| 212 | **Goal**: Document what was accomplished |
| 213 | |
| 214 | **What happens:** |
| 215 | - Marks all todos complete |
| 216 | - Summarizes: |
| 217 | - What was built |
| 218 | - Key decisions made |
| 219 | - Files modified |
| 220 | - Suggested next steps |
| 221 | |
| 222 | **Example:** |
| 223 | ``` |
| 224 | Feature Complete: OAuth Authentication |
| 225 | |
| 226 | What was built: |
| 227 | - OAuth provider abstraction supporting Google and GitHub |
| 228 | - OAuth routes and middleware integrated with existing auth |
| 229 | - Token refresh and session integration |
| 230 | - Error handling for all OAuth flows |
| 231 | |
| 232 | Key decisions: |
| 233 | - Used pragmatic approach with OAuthProvider abstraction |
| 234 | - Integrated with existing session management |
| 235 | - Added OAuth state to prevent CSRF |
| 236 | |
| 237 | Files modified: |
| 238 | - src/auth/OAuthProvider.ts (new) |
| 239 | - src/auth/AuthService.ts |
| 240 | - src/routes/auth.ts |
| 241 | - src/middleware/authMiddleware.ts |
| 242 | |
| 243 | Suggested next steps: |
| 244 | - Add tests for OAuth flows |
| 245 | - Add more OAuth providers (Microsoft, Apple) |
| 246 | - Update documentation |
| 247 | ``` |
| 248 | |
| 249 | ## Agents |
| 250 | |
| 251 | ### `code-explorer` |
| 252 | |
| 253 | **Purpose**: Deeply analyzes existing codebase features by tracing execution paths |
| 254 | |
| 255 | **Focus areas:** |
| 256 | - Entry points and call chains |
| 257 | - Data flow and transformations |
| 258 | - Architecture layers and patterns |
| 259 | - Dependencies and integrations |
| 260 | - Implementation details |
| 261 | |
| 262 | **When triggered:** |
| 263 | - Automatically in Phase 2 |
| 264 | - Can be invoked manually when exploring code |
| 265 | |
| 266 | **Output:** |
| 267 | - Entry points with file:line references |
| 268 | - Step-by-step execution flow |
| 269 | - Key components and responsibilities |
| 270 | - Architecture insights |
| 271 | - List of essential files to read |
| 272 | |
| 273 | ### `code-architect` |
| 274 | |
| 275 | **Purpose**: Designs feature architectures and implementation blueprints |
| 276 | |
| 277 | **Focus areas:** |
| 278 | - Codebase pattern analysis |
| 279 | - Architecture decisions |
| 280 | - Component design |
| 281 | - Implementation roadmap |
| 282 | - Data flow and build sequence |
| 283 | |
| 284 | **When triggered:** |
| 285 | - Automatically in Phase 4 |
| 286 | - Can be invoked manually for architecture design |
| 287 | |
| 288 | **Output:** |
| 289 | - Patterns and conventions found |
| 290 | - Architecture decision with rationale |
| 291 | - Complete component design |
| 292 | - Implementation map with specific files |
| 293 | - Build sequence with phases |
| 294 | |
| 295 | ### `code-reviewer` |
| 296 | |
| 297 | **Purpose**: Reviews code for bugs, quality issues, and project conventions |
| 298 | |
| 299 | **Focus areas:** |
| 300 | - Project guideline compliance (CLAUDE.md) |
| 301 | - Bug detection |
| 302 | - Code quality issues |
| 303 | - Confidence-based filtering (only reports high-confidence issues ≥80) |
| 304 | |
| 305 | **When triggered:** |
| 306 | - Automatically in Phase 6 |
| 307 | - Can be invoked manually after writing code |
| 308 | |
| 309 | **Output:** |
| 310 | - Critical issues (confidence 75-100) |
| 311 | - Important issues (confidence 50-74) |
| 312 | - Specific fixes with file:line references |
| 313 | - Project guideline references |
| 314 | |
| 315 | ## Usage Patterns |
| 316 | |
| 317 | ### Full workflow (recommended for new features): |
| 318 | ```bash |
| 319 | /feature-dev Add rate limiting to API endpoints |
| 320 | ``` |
| 321 | |
| 322 | Let the workflow guide you through all 7 phases. |
| 323 | |
| 324 | ### Manual agent invocation: |
| 325 | |
| 326 | **Explore a feature:** |
| 327 | ``` |
| 328 | "Launch code-explorer to trace how authentication works" |
| 329 | ``` |
| 330 | |
| 331 | **Design architecture:** |
| 332 | ``` |
| 333 | "Launch code-architect to design the caching layer" |
| 334 | ``` |
| 335 | |
| 336 | **Review code:** |
| 337 | ``` |
| 338 | "Launch code-reviewer to check my recent changes" |
| 339 | ``` |
| 340 | |
| 341 | ## Best Practices |
| 342 | |
| 343 | 1. **Use the full workflow for complex features**: The 7 phases ensure thorough planning |
| 344 | 2. **Answer clarifying questions thoughtfully**: Phase 3 prevents future confusion |
| 345 | 3. **Choose architecture deliberately**: Phase 4 gives you options for a reason |
| 346 | 4. **Don't skip code review**: Phase 6 catches issues before they reach production |
| 347 | 5. **Read the suggested files**: Phase 2 identifies key files—read them to understand context |
| 348 | |
| 349 | ## When to Use This Plugin |
| 350 | |
| 351 | **Use for:** |
| 352 | - New features that touch multiple files |
| 353 | - Features requiring architectural decisions |
| 354 | - Complex integrations with existing code |
| 355 | - Features where requirements are somewhat unclear |
| 356 | |
| 357 | **Don't use for:** |
| 358 | - Single-line bug fixes |
| 359 | - Trivial changes |
| 360 | - Well-defined, simple tasks |
| 361 | - Urgent hotfixes |
| 362 | |
| 363 | ## Requirements |
| 364 | |
| 365 | - Claude Code installed |
| 366 | - Git repository (for code review) |
| 367 | - Project with existing codebase (workflow assumes existing code to learn from) |
| 368 | |
| 369 | ## Troubleshooting |
| 370 | |
| 371 | ### Agents take too long |
| 372 | |
| 373 | **Issue**: Code exploration or architecture agents are slow |
| 374 | |
| 375 | **Solution**: |
| 376 | - This is normal for large codebases |
| 377 | - Agents run in parallel when possible |
| 378 | - The thoroughness pays off in better understanding |
| 379 | |
| 380 | ### Too many clarifying questions |
| 381 | |
| 382 | **Issue**: Phase 3 asks too many questions |
| 383 | |
| 384 | **Solution**: |
| 385 | - Be more specific in your initial feature request |
| 386 | - Provide context about constraints upfront |
| 387 | - Say "whatever you think is best" if truly no preference |
| 388 | |
| 389 | ### Architecture options overwhelming |
| 390 | |
| 391 | **Issue**: Too many architecture options in Phase 4 |
| 392 | |
| 393 | **Solution**: |
| 394 | - Trust the recommendation—it's based on codebase analysis |
| 395 | - If still unsure, ask for more explanation |
| 396 | - Pick the pragmatic option when in doubt |
| 397 | |
| 398 | ## Tips |
| 399 | |
| 400 | - **Be specific in your feature request**: More detail = fewer clarifying questions |
| 401 | - **Trust the process**: Each phase builds on the previous one |
| 402 | - **Review agent outputs**: Agents provide valuable insights about your codebase |
| 403 | - **Don't skip phases**: Each phase serves a purpose |
| 404 | - **Use for learning**: The exploration phase teaches you about your own codebase |
| 405 | |
| 406 | ## Author |
| 407 | |
| 408 | Sid Bidasaria (sbidasaria@anthropic.com) |
| 409 | |
| 410 | ## Version |
| 411 | |
| 412 | 1.0.0 |