mirror of
https://github.com/centminmod/my-claude-code-setup.git
synced 2025-12-29 16:14:46 +00:00
Add six new slash command categories with useful developer tools
- Add /documentation category with create-readme-section command - Add /security category with security-audit and check-best-practices commands - Add /architecture category with explain-architecture-pattern command - Add /promptengineering category with convert-to-test-driven-prompt and batch-operations-prompt commands - Update README.md to document all new slash commands - Add Bash(mkdir:*) permission to settings.local.json
This commit is contained in:
George Liu
198
.claude/commands/promptengineering/batch-operations-prompt.md
Normal file
198
.claude/commands/promptengineering/batch-operations-prompt.md
Normal file
@@ -0,0 +1,198 @@
|
||||
# Batch Operations Prompt
|
||||
|
||||
Optimize prompts for multiple file operations, parallel processing, and efficient bulk changes across a codebase. This helps Claude Code work more efficiently with TodoWrite patterns.
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Basic Usage
|
||||
"Convert to batch: Update all test files to use new API"
|
||||
"Batch prompt for: Rename variable across multiple files"
|
||||
"Optimize for parallel: Add logging to all service files"
|
||||
|
||||
### Complex Operations
|
||||
"Batch refactor: Convert callbacks to async/await in all files"
|
||||
"Parallel update: Add TypeScript types to all components"
|
||||
"Bulk operation: Update import statements across the project"
|
||||
|
||||
## Instructions for Claude
|
||||
|
||||
When creating batch operation prompts:
|
||||
|
||||
1. **Identify Parallelizable Tasks**: Determine what can be done simultaneously
|
||||
2. **Group Related Operations**: Organize tasks by type and dependency
|
||||
3. **Create Efficient Sequences**: Order operations to minimize conflicts
|
||||
4. **Use TodoWrite Format**: Structure for Claude's task management
|
||||
5. **Include Validation Steps**: Add checks between batch operations
|
||||
|
||||
### Batch Prompt Structure
|
||||
|
||||
#### 1. Overview
|
||||
- Scope of changes
|
||||
- Files/patterns affected
|
||||
- Expected outcome
|
||||
|
||||
#### 2. Prerequisite Checks
|
||||
- Required tools/dependencies
|
||||
- Initial validation commands
|
||||
- Backup recommendations
|
||||
|
||||
#### 3. Parallel Operations
|
||||
- Independent tasks that can run simultaneously
|
||||
- File groups that don't conflict
|
||||
- Read operations for gathering information
|
||||
|
||||
#### 4. Sequential Operations
|
||||
- Tasks with dependencies
|
||||
- Operations that modify same files
|
||||
- Final validation steps
|
||||
|
||||
### Optimization Strategies
|
||||
|
||||
#### File Grouping
|
||||
```markdown
|
||||
## Batch Operation: [Operation Name]
|
||||
|
||||
### Phase 1: Analysis (Parallel)
|
||||
- Search for all affected files using Glob/Grep
|
||||
- Read current implementations
|
||||
- Identify patterns and dependencies
|
||||
|
||||
### Phase 2: Implementation (Grouped)
|
||||
Group A (Independent files):
|
||||
- File1.js: [specific change]
|
||||
- File2.js: [specific change]
|
||||
|
||||
Group B (Related components):
|
||||
- Component1.tsx: [change]
|
||||
- Component1.test.tsx: [related change]
|
||||
|
||||
### Phase 3: Validation (Sequential)
|
||||
1. Run linter on modified files
|
||||
2. Execute test suite
|
||||
3. Build verification
|
||||
```
|
||||
|
||||
#### TodoWrite Integration
|
||||
```markdown
|
||||
### Task List Structure
|
||||
1. Gather information (can parallelize):
|
||||
- Find all files matching pattern X
|
||||
- Read configuration files
|
||||
- Check current implementations
|
||||
|
||||
2. Batch updates (group by conflict potential):
|
||||
- Update non-conflicting files (parallel)
|
||||
- Update shared modules (sequential)
|
||||
- Update test files (parallel)
|
||||
|
||||
3. Verification (sequential):
|
||||
- Run type checking
|
||||
- Execute tests
|
||||
- Validate build
|
||||
```
|
||||
|
||||
### Conversion Examples
|
||||
|
||||
#### Original Request:
|
||||
"Update all API calls to use the new authentication header"
|
||||
|
||||
#### Batch-Optimized Version:
|
||||
```markdown
|
||||
## Batch Operation: Update API Authentication Headers
|
||||
|
||||
### Prerequisites
|
||||
- Verify new auth header format
|
||||
- Check all API call patterns in codebase
|
||||
|
||||
### Parallel Phase 1: Discovery
|
||||
Execute simultaneously:
|
||||
1. Grep for "fetch(" patterns
|
||||
2. Grep for "axios." patterns
|
||||
3. Grep for "api." patterns
|
||||
4. Read auth configuration file
|
||||
|
||||
### Parallel Phase 2: Read Current Implementations
|
||||
Read all files containing API calls (batch read):
|
||||
- src/services/*.js
|
||||
- src/api/*.js
|
||||
- src/utils/api*.js
|
||||
|
||||
### Sequential Phase 3: Update by Pattern Type
|
||||
Group 1 - Fetch calls:
|
||||
- Update all fetch() calls with new header
|
||||
- Pattern: Add "Authorization: Bearer ${token}"
|
||||
|
||||
Group 2 - Axios calls:
|
||||
- Update axios config/interceptors
|
||||
- Update individual axios calls
|
||||
|
||||
Group 3 - Custom API wrappers:
|
||||
- Update wrapper functions
|
||||
- Ensure backward compatibility
|
||||
|
||||
### Parallel Phase 4: Update Tests
|
||||
Simultaneously update:
|
||||
- Unit tests mocking API calls
|
||||
- Integration tests with auth
|
||||
- E2E test auth setup
|
||||
|
||||
### Sequential Phase 5: Validation
|
||||
1. ESLint all modified files
|
||||
2. Run test suite
|
||||
3. Test one API call manually
|
||||
4. Build project
|
||||
```
|
||||
|
||||
### Output Format
|
||||
|
||||
Generate batch prompt as:
|
||||
|
||||
```markdown
|
||||
## Batch Operation Prompt: [Operation Name]
|
||||
|
||||
### Efficiency Metrics
|
||||
- Estimated sequential time: X operations
|
||||
- Optimized parallel time: Y operations
|
||||
- Parallelization factor: X/Y
|
||||
|
||||
### Execution Plan
|
||||
|
||||
#### Stage 1: Information Gathering (Parallel)
|
||||
```bash
|
||||
# Commands that can run simultaneously
|
||||
[command 1] &
|
||||
[command 2] &
|
||||
[command 3] &
|
||||
wait
|
||||
```
|
||||
|
||||
#### Stage 2: Bulk Operations (Grouped)
|
||||
**Parallel Group A:**
|
||||
- Files: [list]
|
||||
- Operation: [description]
|
||||
- No conflicts with other groups
|
||||
|
||||
**Sequential Group B:**
|
||||
- Files: [list]
|
||||
- Operation: [description]
|
||||
- Must complete before Group C
|
||||
|
||||
#### Stage 3: Verification (Sequential)
|
||||
1. [Verification step 1]
|
||||
2. [Verification step 2]
|
||||
3. [Final validation]
|
||||
|
||||
### TodoWrite Task List
|
||||
- [ ] Complete Stage 1 analysis (parallel)
|
||||
- [ ] Execute Group A updates (parallel)
|
||||
- [ ] Execute Group B updates (sequential)
|
||||
- [ ] Run verification suite
|
||||
- [ ] Document changes
|
||||
```
|
||||
|
||||
Remember to:
|
||||
- Maximize parallel operations
|
||||
- Group by conflict potential
|
||||
- Use TodoWrite's in_progress limitation wisely
|
||||
- Include rollback strategies
|
||||
- Provide specific file patterns
|
||||
@@ -0,0 +1,147 @@
|
||||
# Convert to Test-Driven Prompt
|
||||
|
||||
Transform user requests into Test-Driven Development (TDD) style prompts that explicitly define expected outcomes, test cases, and success criteria before implementation.
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Basic Usage
|
||||
"Convert this to TDD: Add a user authentication feature"
|
||||
"Make this test-driven: Create a shopping cart component"
|
||||
"TDD version: Implement data validation for the form"
|
||||
|
||||
### Complex Scenarios
|
||||
"Convert to TDD: Refactor the payment processing module"
|
||||
"Test-driven approach for: API rate limiting feature"
|
||||
"TDD prompt for: Database migration script"
|
||||
|
||||
## Instructions for Claude
|
||||
|
||||
When converting to TDD prompts:
|
||||
|
||||
1. **Extract Requirements**: Identify core functionality from the original request
|
||||
2. **Define Test Cases**: Create specific, measurable test scenarios
|
||||
3. **Specify Expected Outcomes**: Clear success and failure criteria
|
||||
4. **Structure for Implementation**: Organize prompt for red-green-refactor cycle
|
||||
5. **Include Edge Cases**: Don't forget boundary conditions and error scenarios
|
||||
|
||||
### TDD Prompt Structure
|
||||
|
||||
#### 1. Objective Statement
|
||||
Clear, concise description of what needs to be built
|
||||
|
||||
#### 2. Test Specifications
|
||||
```
|
||||
GIVEN: [Initial state/context]
|
||||
WHEN: [Action performed]
|
||||
THEN: [Expected outcome]
|
||||
```
|
||||
|
||||
#### 3. Success Criteria
|
||||
- Specific, measurable outcomes
|
||||
- Performance requirements
|
||||
- Error handling expectations
|
||||
- Edge case behaviors
|
||||
|
||||
#### 4. Test Cases Format
|
||||
```markdown
|
||||
Test Case 1: [Descriptive name]
|
||||
- Input: [Specific input data]
|
||||
- Expected Output: [Exact expected result]
|
||||
- Validation: [How to verify success]
|
||||
|
||||
Test Case 2: [Edge case name]
|
||||
- Input: [Boundary/error condition]
|
||||
- Expected Output: [Error handling result]
|
||||
- Validation: [Error verification method]
|
||||
```
|
||||
|
||||
### Conversion Examples
|
||||
|
||||
#### Original Request:
|
||||
"Add user login functionality"
|
||||
|
||||
#### TDD Conversion:
|
||||
```markdown
|
||||
## Objective
|
||||
Implement secure user login with email/password authentication
|
||||
|
||||
## Test Specifications
|
||||
|
||||
### Test 1: Successful Login
|
||||
GIVEN: Valid user credentials exist in database
|
||||
WHEN: User submits correct email and password
|
||||
THEN: User receives auth token and is redirected to dashboard
|
||||
|
||||
### Test 2: Invalid Password
|
||||
GIVEN: Valid email but incorrect password
|
||||
WHEN: User submits login form
|
||||
THEN: Return error "Invalid credentials" without revealing which field is wrong
|
||||
|
||||
### Test 3: Non-existent User
|
||||
GIVEN: Email not in database
|
||||
WHEN: User attempts login
|
||||
THEN: Return same "Invalid credentials" error (prevent user enumeration)
|
||||
|
||||
### Test 4: Rate Limiting
|
||||
GIVEN: User has failed 5 login attempts
|
||||
WHEN: User attempts 6th login within 15 minutes
|
||||
THEN: Block attempt and show "Too many attempts" error
|
||||
|
||||
## Success Criteria
|
||||
- All tests pass
|
||||
- Password is hashed using bcrypt
|
||||
- Auth tokens expire after 24 hours
|
||||
- Login attempts are logged
|
||||
- Response time < 200ms
|
||||
```
|
||||
|
||||
### Output Format
|
||||
|
||||
Generate TDD prompt as:
|
||||
|
||||
```markdown
|
||||
## TDD Prompt: [Feature Name]
|
||||
|
||||
### Objective
|
||||
[Clear description of the feature to implement]
|
||||
|
||||
### Test Suite
|
||||
|
||||
#### Happy Path Tests
|
||||
[List of successful scenario tests]
|
||||
|
||||
#### Error Handling Tests
|
||||
[List of failure scenario tests]
|
||||
|
||||
#### Edge Case Tests
|
||||
[List of boundary condition tests]
|
||||
|
||||
### Implementation Requirements
|
||||
- [ ] All tests must pass
|
||||
- [ ] Code coverage > 80%
|
||||
- [ ] Performance criteria met
|
||||
- [ ] Security requirements satisfied
|
||||
|
||||
### Test-First Development Steps
|
||||
1. Write failing test for [first requirement]
|
||||
2. Implement minimal code to pass
|
||||
3. Refactor while keeping tests green
|
||||
4. Repeat for next requirement
|
||||
|
||||
### Example Test Implementation
|
||||
```language
|
||||
// Example test code structure
|
||||
describe('FeatureName', () => {
|
||||
it('should [expected behavior]', () => {
|
||||
// Test implementation
|
||||
});
|
||||
});
|
||||
```
|
||||
```
|
||||
|
||||
Remember to:
|
||||
- Focus on behavior, not implementation details
|
||||
- Make tests specific and measurable
|
||||
- Include both positive and negative test cases
|
||||
- Consider performance and security in tests
|
||||
- Structure for iterative TDD workflow
|
||||
Reference in New Issue
Block a user