SuperCharge Claude Code v1.0.0 - Complete Customization Package

Features: - 30+ Custom Skills (cognitive, development, UI/UX, autonomous agents) - RalphLoop autonomous agent integration - Multi-AI consultation (Qwen) - Agent management system with sync capabilities - Custom hooks for session management - MCP servers integration - Plugin marketplace setup - Comprehensive installation script Components: - Skills: always-use-superpowers, ralph, brainstorming, ui-ux-pro-max, etc. - Agents: 100+ agents across engineering, marketing, product, etc. - Hooks: session-start-superpowers, qwen-consult, ralph-auto-trigger - Commands: /brainstorm, /write-plan, /execute-plan - MCP Servers: zai-mcp-server, web-search-prime, web-reader, zread - Binaries: ralphloop wrapper Installation: ./supercharge.sh
2026-01-22 15:35:55 +00:00
commit 7a491b1548
1013 changed files with 170070 additions and 0 deletions
--- a/plugins/marketplaces/claude-plugins-official/plugins/feature-dev/README.md
+++ b/plugins/marketplaces/claude-plugins-official/plugins/feature-dev/README.md
@@ -0,0 +1,412 @@
+# 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