bobo-ai-cli 3.0.4 → 3.0.5

package/knowledge/skills/feature-dev.md

@@ -1,458 +1,458 @@
----
-id: "feature-dev"
-title: "Feature Development Plugin"
-category: "dev-tools"
-tags: ["feature development plugin", "overview", "philosophy", "the 7-phase workflow", "agents", "usage patterns", "best practices", "when to use this plugin", "requirements"]
-triggers: []
-dependencies: []
-source: "E:/Bobo's Coding cache/.claude/skills/feature-dev"
----
-
-# Feature Development Plugin
-
-A comprehensive, structured workflow for feature development with specialized agents for codebase exploration, architecture design, and quality review.
-
-## Overview
-
-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.
-
-## Philosophy
-
-Building features requires more than just writing code. You need to:
-
-- **Understand the codebase** before making changes
-- **Ask questions** to clarify ambiguous requirements
-- **Design thoughtfully** before implementing
-- **Review for quality** after building
-
-This plugin embeds these practices into a structured workflow that runs automatically when you use the `/feature-dev` command.
-
-## Command: `/feature-dev`
-
-Launches a guided feature development workflow with 7 distinct phases.
-
-**Usage:**
-
-```bash
-/feature-dev Add user authentication with OAuth
-```
-
-Or simply:
-
-```bash
-/feature-dev
-```
-
-The command will guide you through the entire process interactively.
-
-## The 7-Phase Workflow
-
-### Phase 1: Discovery
-
-**Goal**: Understand what needs to be built
-
-**What happens:**
-
-- 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
-
-**What happens:**
-
-- Launches 2-3 `code-explorer` agents in parallel
-- Each agent explores different aspects (similar features, architecture, UI patterns)
-- Agents return comprehensive analyses with key files to read
-- Claude reads all identified files to build deep understanding
-- Presents comprehensive summary of findings
-
-**Agents launched:**
-
-- "Find features similar to [feature] and trace implementation"
-- "Map the architecture and abstractions for [area]"
-- "Analyze current implementation of [related feature]"
-
-**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
-
-**What happens:**
-
-- Reviews codebase findings and feature request
-- Identifies underspecified aspects:
-  - Edge cases
-  - Error handling
-  - Integration points
-  - Backward compatibility
-  - Performance needs
-- Presents all questions in an organized list
-- **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?
-```
-
-**Critical**: This phase ensures nothing is ambiguous before design begins.
-
-### Phase 4: Architecture Design
-
-**Goal**: Design multiple implementation approaches
-
-**What happens:**
-
-- Launches 2-3 `code-architect` agents with different focuses:
-  - **Minimal changes**: Smallest change, maximum reuse
-  - **Clean architecture**: Maintainability, elegant abstractions
-  - **Pragmatic balance**: Speed + quality
-- Reviews all approaches
-- Forms opinion on which fits best for this task
-- Presents comparison with trade-offs and recommendation
-- **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
-- Minimal refactoring required
-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
-- Refactor AuthService to use common interface
-Pros: Clean separation, testable, maintainable
-Cons: More files, more refactoring
-
-Approach 3: Pragmatic Balance
-- New OAuthProvider abstraction
-- Integrate into existing AuthService
-- Minimal refactoring, good boundaries
-Pros: Balanced complexity and cleanliness
-Cons: Some coupling remains
-
-Recommendation: Approach 3 - gives you clean boundaries without
-excessive refactoring, and fits your existing architecture well.
-
-Which approach would you like to use?
-```
-
-### Phase 5: Implementation
-
-**Goal**: Build the feature
-
-**What happens:**
-
-- **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
-
-**Notes:**
-
-- Implementation only starts after you approve
-- Follows patterns discovered in Phase 2
-- Uses architecture designed in Phase 4
-- Continuously tracks progress
-
-### Phase 6: Quality Review
-
-**Goal**: Ensure code is simple, DRY, elegant, and functionally correct
-
-**What happens:**
-
-- Launches 3 `code-reviewer` agents in parallel with different focuses:
-  - **Simplicity/DRY/Elegance**: Code quality and maintainability
-  - **Bugs/Correctness**: Functional correctness and logic errors
-  - **Conventions/Abstractions**: Project standards and patterns
-- Consolidates findings
-- Identifies highest severity issues
-- **Presents findings and asks what you want to do**:
-  - Fix now
-  - Fix later
-  - Proceed as-is
-- 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
-
-**What happens:**
-
-- 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
-
-**When triggered:**
-
-- Automatically in Phase 2
-- Can be invoked manually when exploring code
-
-**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
-
-**When triggered:**
-
-- Automatically in Phase 4
-- Can be invoked manually for architecture design
-
-**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)
-
-**When triggered:**
-
-- Automatically in Phase 6
-- Can be invoked manually after writing code
-
-**Output:**
-
-- Critical issues (confidence 75-100)
-- Important issues (confidence 50-74)
-- Specific fixes with file:line references
-- Project guideline references
-
-## Usage Patterns
-
-### Full workflow (recommended for new features):
-
-```bash
-/feature-dev Add rate limiting to API endpoints
-```
-
-Let the workflow guide you through all 7 phases.
-
-### Manual agent invocation:
-
-**Explore a feature:**
-
-```
-"Launch code-explorer to trace how authentication works"
-```
-
-**Design architecture:**
-
-```
-"Launch code-architect to design the caching layer"
-```
-
-**Review code:**
-
-```
-"Launch code-reviewer to check my recent changes"
-```
-
-## Best Practices
-
-1. **Use the full workflow for complex features**: The 7 phases ensure thorough planning
-2. **Answer clarifying questions thoughtfully**: Phase 3 prevents future confusion
-3. **Choose architecture deliberately**: Phase 4 gives you options for a reason
-4. **Don't skip code review**: Phase 6 catches issues before they reach production
-5. **Read the suggested files**: Phase 2 identifies key files—read them to understand context
-
-## When to Use This Plugin
-
-**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
-
-## Requirements
-
-- Claude Code installed
-- Git repository (for code review)
-- Project with existing codebase (workflow assumes existing code to learn from)
-
-## 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
-
-## Tips
-
-- **Be specific in your feature request**: More detail = fewer clarifying questions
-- **Trust the process**: Each phase builds on the previous one
-- **Review agent outputs**: Agents provide valuable insights about your codebase
-- **Don't skip phases**: Each phase serves a purpose
-- **Use for learning**: The exploration phase teaches you about your own codebase
-
-## Author
-
-Sid Bidasaria (sbidasaria@anthropic.com)
-
-## Version
-
-1.0.0
+---
+id: "feature-dev"
+title: "Feature Development Plugin"
+category: "dev-tools"
+tags: ["feature development plugin", "overview", "philosophy", "the 7-phase workflow", "agents", "usage patterns", "best practices", "when to use this plugin", "requirements"]
+triggers: []
+dependencies: []
+source: "E:/Bobo's Coding cache/.claude/skills/feature-dev"
+---
+
+# Feature Development Plugin
+
+A comprehensive, structured workflow for feature development with specialized agents for codebase exploration, architecture design, and quality review.
+
+## Overview
+
+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.
+
+## Philosophy
+
+Building features requires more than just writing code. You need to:
+
+- **Understand the codebase** before making changes
+- **Ask questions** to clarify ambiguous requirements
+- **Design thoughtfully** before implementing
+- **Review for quality** after building
+
+This plugin embeds these practices into a structured workflow that runs automatically when you use the `/feature-dev` command.
+
+## Command: `/feature-dev`
+
+Launches a guided feature development workflow with 7 distinct phases.
+
+**Usage:**
+
+```bash
+/feature-dev Add user authentication with OAuth
+```
+
+Or simply:
+
+```bash
+/feature-dev
+```
+
+The command will guide you through the entire process interactively.
+
+## The 7-Phase Workflow
+
+### Phase 1: Discovery
+
+**Goal**: Understand what needs to be built
+
+**What happens:**
+
+- 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
+
+**What happens:**
+
+- Launches 2-3 `code-explorer` agents in parallel
+- Each agent explores different aspects (similar features, architecture, UI patterns)
+- Agents return comprehensive analyses with key files to read
+- Claude reads all identified files to build deep understanding
+- Presents comprehensive summary of findings
+
+**Agents launched:**
+
+- "Find features similar to [feature] and trace implementation"
+- "Map the architecture and abstractions for [area]"
+- "Analyze current implementation of [related feature]"
+
+**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
+
+**What happens:**
+
+- Reviews codebase findings and feature request
+- Identifies underspecified aspects:
+  - Edge cases
+  - Error handling
+  - Integration points
+  - Backward compatibility
+  - Performance needs
+- Presents all questions in an organized list
+- **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?
+```
+
+**Critical**: This phase ensures nothing is ambiguous before design begins.
+
+### Phase 4: Architecture Design
+
+**Goal**: Design multiple implementation approaches
+
+**What happens:**
+
+- Launches 2-3 `code-architect` agents with different focuses:
+  - **Minimal changes**: Smallest change, maximum reuse
+  - **Clean architecture**: Maintainability, elegant abstractions
+  - **Pragmatic balance**: Speed + quality
+- Reviews all approaches
+- Forms opinion on which fits best for this task
+- Presents comparison with trade-offs and recommendation
+- **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
+- Minimal refactoring required
+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
+- Refactor AuthService to use common interface
+Pros: Clean separation, testable, maintainable
+Cons: More files, more refactoring
+
+Approach 3: Pragmatic Balance
+- New OAuthProvider abstraction
+- Integrate into existing AuthService
+- Minimal refactoring, good boundaries
+Pros: Balanced complexity and cleanliness
+Cons: Some coupling remains
+
+Recommendation: Approach 3 - gives you clean boundaries without
+excessive refactoring, and fits your existing architecture well.
+
+Which approach would you like to use?
+```
+
+### Phase 5: Implementation
+
+**Goal**: Build the feature
+
+**What happens:**
+
+- **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
+
+**Notes:**
+
+- Implementation only starts after you approve
+- Follows patterns discovered in Phase 2
+- Uses architecture designed in Phase 4
+- Continuously tracks progress
+
+### Phase 6: Quality Review
+
+**Goal**: Ensure code is simple, DRY, elegant, and functionally correct
+
+**What happens:**
+
+- Launches 3 `code-reviewer` agents in parallel with different focuses:
+  - **Simplicity/DRY/Elegance**: Code quality and maintainability
+  - **Bugs/Correctness**: Functional correctness and logic errors
+  - **Conventions/Abstractions**: Project standards and patterns
+- Consolidates findings
+- Identifies highest severity issues
+- **Presents findings and asks what you want to do**:
+  - Fix now
+  - Fix later
+  - Proceed as-is
+- 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
+
+**What happens:**
+
+- 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
+
+**When triggered:**
+
+- Automatically in Phase 2
+- Can be invoked manually when exploring code
+
+**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
+
+**When triggered:**
+
+- Automatically in Phase 4
+- Can be invoked manually for architecture design
+
+**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)
+
+**When triggered:**
+
+- Automatically in Phase 6
+- Can be invoked manually after writing code
+
+**Output:**
+
+- Critical issues (confidence 75-100)
+- Important issues (confidence 50-74)
+- Specific fixes with file:line references
+- Project guideline references
+
+## Usage Patterns
+
+### Full workflow (recommended for new features):
+
+```bash
+/feature-dev Add rate limiting to API endpoints
+```
+
+Let the workflow guide you through all 7 phases.
+
+### Manual agent invocation:
+
+**Explore a feature:**
+
+```
+"Launch code-explorer to trace how authentication works"
+```
+
+**Design architecture:**
+
+```
+"Launch code-architect to design the caching layer"
+```
+
+**Review code:**
+
+```
+"Launch code-reviewer to check my recent changes"
+```
+
+## Best Practices
+
+1. **Use the full workflow for complex features**: The 7 phases ensure thorough planning
+2. **Answer clarifying questions thoughtfully**: Phase 3 prevents future confusion
+3. **Choose architecture deliberately**: Phase 4 gives you options for a reason
+4. **Don't skip code review**: Phase 6 catches issues before they reach production
+5. **Read the suggested files**: Phase 2 identifies key files—read them to understand context
+
+## When to Use This Plugin
+
+**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
+
+## Requirements
+
+- Claude Code installed
+- Git repository (for code review)
+- Project with existing codebase (workflow assumes existing code to learn from)
+
+## 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
+
+## Tips
+
+- **Be specific in your feature request**: More detail = fewer clarifying questions
+- **Trust the process**: Each phase builds on the previous one
+- **Review agent outputs**: Agents provide valuable insights about your codebase
+- **Don't skip phases**: Each phase serves a purpose
+- **Use for learning**: The exploration phase teaches you about your own codebase
+
+## Author
+
+Sid Bidasaria (sbidasaria@anthropic.com)
+
+## Version
+
+1.0.0