Initial commit: Fresh start with current state
This commit is contained in:
209
.claude/commands/implement.md
Normal file
209
.claude/commands/implement.md
Normal file
@@ -0,0 +1,209 @@
|
||||
---
|
||||
description: Implement features or changes following best practices and project conventions
|
||||
allowed-tools: Read(*), Write(*), Edit(*), Grep(*), Glob(*), Bash(*)
|
||||
argument-hint: [feature-description]
|
||||
---
|
||||
|
||||
# Implement Command
|
||||
|
||||
Implement requested features following project conventions and best practices.
|
||||
|
||||
## Technology Adaptation
|
||||
|
||||
**Configuration Source**: [CLAUDE.md](../../CLAUDE.md)
|
||||
|
||||
Before implementing, consult CLAUDE.md for:
|
||||
- **Technology Stack**: Languages, frameworks, libraries to use
|
||||
- **Project Structure**: Where to place new code
|
||||
- **Code Style**: Naming conventions, formatting rules
|
||||
- **Testing Requirements**: Test coverage and patterns
|
||||
- **Build Process**: How to build and test changes
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Understand Requirements**
|
||||
- Parse feature description from $ARGUMENTS or ask user
|
||||
- Clarify scope and acceptance criteria
|
||||
- Identify impacted areas of codebase
|
||||
- Check for existing similar implementations
|
||||
|
||||
2. **Review Project Context**
|
||||
- Read CLAUDE.md for:
|
||||
- Technology stack and patterns
|
||||
- Code style and conventions
|
||||
- Project structure
|
||||
- Use serena MCP to analyze existing patterns
|
||||
- Use context7 MCP for framework best practices
|
||||
|
||||
3. **Plan Implementation**
|
||||
- Identify files to create/modify
|
||||
- Determine appropriate design patterns
|
||||
- Consider edge cases and error handling
|
||||
- Plan for testing
|
||||
- Check if architect agent needed for complex features
|
||||
|
||||
4. **Implement Feature**
|
||||
- Follow CLAUDE.md code style and conventions
|
||||
- Write clean, maintainable code
|
||||
- Add appropriate error handling
|
||||
- Include inline documentation
|
||||
- Follow project's architectural patterns
|
||||
- Use MCP servers for:
|
||||
- `serena`: Finding related code, refactoring
|
||||
- `context7`: Framework/library documentation
|
||||
- `memory`: Storing implementation decisions
|
||||
|
||||
5. **Add Tests**
|
||||
- Generate tests using project's test framework from CLAUDE.md
|
||||
- Cover happy paths and edge cases
|
||||
- Ensure tests are maintainable
|
||||
- Consider using test-engineer agent for complex scenarios
|
||||
|
||||
6. **Verify Implementation**
|
||||
- Run tests using command from CLAUDE.md
|
||||
- Check code style compliance
|
||||
- Verify no regressions
|
||||
- Consider using code-reviewer agent for quality check
|
||||
|
||||
7. **Document Changes**
|
||||
- Add/update inline comments where needed
|
||||
- Update relevant documentation
|
||||
- Note any architectural decisions
|
||||
|
||||
## Implementation Best Practices
|
||||
|
||||
### Code Quality
|
||||
- Keep functions small and focused (< 50 lines typically)
|
||||
- Follow Single Responsibility Principle
|
||||
- Use meaningful names from CLAUDE.md conventions
|
||||
- Add comments for "why", not "what"
|
||||
- Handle errors gracefully
|
||||
|
||||
### Testing
|
||||
- Write tests alongside implementation
|
||||
- Aim for coverage targets from CLAUDE.md
|
||||
- Test edge cases and error conditions
|
||||
- Make tests readable and maintainable
|
||||
|
||||
### Security
|
||||
- Validate all inputs
|
||||
- Never hardcode secrets
|
||||
- Use parameterized queries
|
||||
- Follow least privilege principle
|
||||
- Consider security-analyst agent for sensitive features
|
||||
|
||||
### Performance
|
||||
- Avoid premature optimization
|
||||
- Consider scalability for data operations
|
||||
- Use appropriate data structures
|
||||
- Consider optimize command if performance-critical
|
||||
|
||||
## MCP Server Usage
|
||||
|
||||
### Serena MCP
|
||||
|
||||
**Code Navigation**:
|
||||
- `find_symbol` - Locate existing patterns to follow
|
||||
- `find_referencing_symbols` - Understand dependencies and impact
|
||||
- `get_symbols_overview` - Understand file structure before modifying
|
||||
- `search_for_pattern` - Find similar implementations
|
||||
- `rename_symbol` - Safely refactor across codebase
|
||||
|
||||
**Persistent Memory** (stored in `.serena/memories/`):
|
||||
- Use `write_memory` to store implementation lessons:
|
||||
- "lesson-error-handling-[feature-name]"
|
||||
- "pattern-api-integration-[service]"
|
||||
- "lesson-performance-optimization-[component]"
|
||||
- "decision-architecture-[feature-name]"
|
||||
- Use `read_memory` to recall past implementation patterns
|
||||
- Use `list_memories` to browse lessons learned
|
||||
|
||||
### Memory MCP (Knowledge Graph)
|
||||
|
||||
**Temporary Context** (in-memory, cleared after session):
|
||||
- Use `create_entities` for features/components being implemented
|
||||
- Use `create_relations` to track dependencies during implementation
|
||||
- Use `add_observations` to document implementation decisions
|
||||
|
||||
**Note**: After implementation completes, store key lessons in Serena memory.
|
||||
|
||||
### Context7 MCP
|
||||
- Use `get-library-docs` for current framework/library documentation and best practices
|
||||
|
||||
### Other MCP Servers
|
||||
- **sequential-thinking**: For complex algorithmic problems
|
||||
|
||||
## Agent Collaboration
|
||||
|
||||
For complex features, consider delegating to specialized agents:
|
||||
- **architect**: For system design and architecture decisions
|
||||
- **test-engineer**: For comprehensive test generation
|
||||
- **security-analyst**: For security-sensitive features
|
||||
- **code-reviewer**: For quality assurance before completion
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## Implementation Complete: [Feature Name]
|
||||
|
||||
### Summary
|
||||
[Brief description of what was implemented]
|
||||
|
||||
### Files Changed
|
||||
- **Created**: [list new files]
|
||||
- **Modified**: [list modified files]
|
||||
|
||||
### Key Changes
|
||||
1. **[Change 1]**: [Description and location]
|
||||
2. **[Change 2]**: [Description and location]
|
||||
3. **[Change 3]**: [Description and location]
|
||||
|
||||
### Design Decisions
|
||||
- **[Decision 1]**: [Why this approach was chosen]
|
||||
- **[Decision 2]**: [Trade-offs considered]
|
||||
|
||||
### Testing
|
||||
- **Tests Added**: [Count and location]
|
||||
- **Coverage**: [Percentage if known]
|
||||
- **Test Command**: `[from CLAUDE.md]`
|
||||
|
||||
### How to Use
|
||||
```[language]
|
||||
[Code example showing how to use the new feature]
|
||||
```
|
||||
|
||||
### Verification Steps
|
||||
1. [Step to verify feature works]
|
||||
2. [Step to run tests]
|
||||
3. [Step to check integration]
|
||||
|
||||
### Next Steps
|
||||
- [ ] Code review (use /review or code-reviewer agent)
|
||||
- [ ] Update documentation
|
||||
- [ ] Performance testing if needed
|
||||
- [ ] Security review for sensitive features
|
||||
```
|
||||
|
||||
## Usage Examples
|
||||
|
||||
```bash
|
||||
# Implement a specific feature
|
||||
/implement Add user authentication with JWT
|
||||
|
||||
# Implement with more context
|
||||
/implement Create a payment processing service that integrates with Stripe API, handles webhooks, and stores transactions
|
||||
|
||||
# Quick implementation
|
||||
/implement Add logging to the error handler
|
||||
```
|
||||
|
||||
## Guidelines
|
||||
|
||||
- **Always** read CLAUDE.md before starting
|
||||
- **Follow** existing project patterns
|
||||
- **Test** your implementation
|
||||
- **Document** non-obvious decisions
|
||||
- **Ask** for clarification when requirements are unclear
|
||||
- **Use** appropriate agents for specialized tasks
|
||||
- **Verify** changes don't break existing functionality
|
||||
- **Consider** security implications
|
||||
Reference in New Issue
Block a user