feat: add comprehensive workflow commands for development pipeline
This commit is contained in:
@@ -7,4 +7,163 @@ color: "#10B981"
|
||||
|
||||
# Code Command
|
||||
|
||||
Quick code generation for small tasks.
|
||||
Quick code generation for small, well-defined tasks following existing patterns and conventions.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Small, isolated changes
|
||||
- Bug fixes with known solution
|
||||
- Adding similar functionality to existing code
|
||||
- Refactoring small code blocks
|
||||
- Utility functions
|
||||
|
||||
## When NOT to Use
|
||||
|
||||
- New features → Use `/feature`
|
||||
- Complex bugs → Use `/debug`
|
||||
- Architecture changes → Use `/plan`
|
||||
- Large refactors → Use `/plan`
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Understand Request
|
||||
|
||||
- Parse what needs to be implemented
|
||||
- Identify the type of change:
|
||||
- New function
|
||||
- Bug fix
|
||||
- Refactor
|
||||
- Configuration
|
||||
- Test
|
||||
|
||||
### Step 2: Find Patterns
|
||||
|
||||
- Search for similar code: `grep "pattern" src/`
|
||||
- Find related files: `glob "**/related*"`
|
||||
- Read neighboring code for conventions
|
||||
- Check imports for available libraries
|
||||
|
||||
```bash
|
||||
# Find existing patterns
|
||||
grep -r "similar_function" src/
|
||||
glob "**/similar*.ts"
|
||||
```
|
||||
|
||||
### Step 3: Check Dependencies
|
||||
|
||||
- Read `package.json` / `cargo.toml` / equivalent
|
||||
- Verify required libraries exist
|
||||
- Do NOT add new dependencies without asking
|
||||
- Use existing utilities when available
|
||||
|
||||
### Step 4: Implement
|
||||
|
||||
- Follow existing code style exactly
|
||||
- Use early returns to reduce nesting
|
||||
- Handle edge cases:
|
||||
- Null/undefined inputs
|
||||
- Empty collections
|
||||
- Boundary values
|
||||
- Error conditions
|
||||
- Keep functions small and focused
|
||||
- NO comments unless explicitly requested
|
||||
|
||||
### Step 5: Test
|
||||
|
||||
- Create test if appropriate
|
||||
- Run existing tests to verify no regressions
|
||||
- Handle errors gracefully
|
||||
|
||||
## Code Style Guidelines
|
||||
|
||||
### Variable Naming
|
||||
```javascript
|
||||
const userCount = users.length;
|
||||
const isValidEmail = email.includes('@');
|
||||
const httpClient = createHttpClient();
|
||||
```
|
||||
|
||||
### Early Returns
|
||||
```javascript
|
||||
function processUser(user) {
|
||||
if (!user) return null;
|
||||
if (!user.active) return inactiveResponse();
|
||||
return processActiveUser(user);
|
||||
}
|
||||
```
|
||||
|
||||
### Error Handling
|
||||
```javascript
|
||||
function fetchData(id) {
|
||||
if (!id) throw new Error('id is required');
|
||||
|
||||
return repository.findById(id)
|
||||
.then(data => data || null)
|
||||
.catch(err => {
|
||||
logger.error('Failed to fetch', { id, error: err.message });
|
||||
throw err;
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
### Small Functions
|
||||
```javascript
|
||||
function validateUser(user) {
|
||||
if (!user.email) return false;
|
||||
if (!user.name) return false;
|
||||
return user.age >= 18;
|
||||
}
|
||||
```
|
||||
|
||||
## Implementation Checklist
|
||||
|
||||
- [ ] Follows existing patterns
|
||||
- [ ] Uses existing dependencies
|
||||
- [ ] Handles edge cases
|
||||
- [ ] Uses early returns
|
||||
- [ ] Clear naming
|
||||
- [ ] No unnecessary comments
|
||||
- [ ] No secrets hardcoded
|
||||
|
||||
## Examples
|
||||
|
||||
### Adding a Function
|
||||
```
|
||||
User: Add a function to validate email format
|
||||
|
||||
Result: Search for validation patterns, implement using existing validation utilities, handle edge cases
|
||||
```
|
||||
|
||||
### Bug Fix
|
||||
```
|
||||
User: Fix the null pointer in getUserProfile
|
||||
|
||||
Result: Locate function, identify null check missing, add defensive code
|
||||
```
|
||||
|
||||
### Small Feature
|
||||
```
|
||||
User: Add logging to the payment service
|
||||
|
||||
Result: Check existing logging library, add appropriate log statements at key points
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## Implementation Complete
|
||||
|
||||
### Changes
|
||||
- [File path]: [Description of change]
|
||||
|
||||
### Reasoning
|
||||
- [Why this approach]
|
||||
- [Pattern followed]
|
||||
|
||||
### Edge Cases Handled
|
||||
- [Case 1]: [How handled]
|
||||
- [Case 2]: [How handled]
|
||||
|
||||
### Tests
|
||||
- [Test file if created]
|
||||
```
|
||||
Reference in New Issue
Block a user