chore(prompts): compress /code command from 169 to 62 lines — removed redundant examples, consolidated style section, simplified workflow
This commit is contained in:
swp
@@ -1,169 +1,60 @@
|
||||
---
|
||||
description: Generates code for small tasks and hotfixes
|
||||
mode: code
|
||||
model: ollama-cloud/deepseek-v3.2
|
||||
model: openrouter/qwen/qwen3-coder:free
|
||||
color: "#10B981"
|
||||
---
|
||||
|
||||
# Code Command
|
||||
|
||||
Quick code generation for small, well-defined tasks following existing patterns and conventions.
|
||||
Quick code generation for small, well-defined tasks.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Small, isolated changes
|
||||
- Bug fixes with known solution
|
||||
- Adding similar functionality to existing code
|
||||
- Refactoring small code blocks
|
||||
- Utility functions
|
||||
- Refactoring small code blocks
|
||||
|
||||
## When NOT to Use
|
||||
|
||||
- New features → Use `/feature`
|
||||
- Complex bugs → Use `/debug`
|
||||
- Architecture changes → Use `/plan`
|
||||
- Large refactors → Use `/plan`
|
||||
- New features → `/feature`
|
||||
- Complex bugs → `/debug`
|
||||
- Architecture changes → `/plan`
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Understand Request
|
||||
1. **Understand** — identify change type (function, fix, refactor, config, test)
|
||||
2. **Search patterns** — `grep` for similar code, `glob` for related files, read neighbors for style
|
||||
3. **Check deps** — verify libraries exist in package.json; do NOT add deps without asking
|
||||
4. **Implement** — follow style exactly, use early returns, handle edge cases, NO comments unless asked
|
||||
5. **Test** — run existing tests to verify no regressions
|
||||
|
||||
- Parse what needs to be implemented
|
||||
- Identify the type of change:
|
||||
- New function
|
||||
- Bug fix
|
||||
- Refactor
|
||||
- Configuration
|
||||
- Test
|
||||
## Code Style
|
||||
|
||||
### 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;
|
||||
}
|
||||
```
|
||||
- **Naming**: `userCount`, `isValidEmail`, `httpClient`
|
||||
- **Early returns**: guard clauses first, happy path last
|
||||
- **Error handling**: validate inputs, log with context, rethrow
|
||||
- **Functions**: small, single-purpose
|
||||
- **NO comments** unless explicitly requested
|
||||
|
||||
## Implementation Checklist
|
||||
|
||||
- [ ] Follows existing patterns
|
||||
- [ ] Uses existing dependencies
|
||||
- [ ] Handles edge cases
|
||||
- [ ] Handles edge cases (null, empty, boundary, errors)
|
||||
- [ ] Uses early returns
|
||||
- [ ] Clear naming
|
||||
- [ ] No unnecessary comments
|
||||
- [ ] Clear naming, no 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]
|
||||
- `path/to/file`: [what changed]
|
||||
|
||||
### Edge Cases Handled
|
||||
- [Case 1]: [How handled]
|
||||
- [Case 2]: [How handled]
|
||||
|
||||
### Tests
|
||||
- [Test file if created]
|
||||
- [case]: [how]
|
||||
```
|
||||
Reference in New Issue
Block a user