From 5cac45acb1895bd7dfd8361e321c2264ed419701 Mon Sep 17 00:00:00 2001
From: swp <swp@example.com>
Date: Sat, 4 Apr 2026 00:12:47 +0100
Subject: [PATCH] =?UTF-8?q?chore(prompts):=20compress=20/code=20command=20?=
 =?UTF-8?q?from=20169=20to=2062=20lines=20=E2=80=94=20removed=20redundant?=
 =?UTF-8?q?=20examples,=20consolidated=20style=20section,=20simplified=20w?=
 =?UTF-8?q?orkflow?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .kilo/commands/code.md | 151 ++++++-----------------------------------
 1 file changed, 21 insertions(+), 130 deletions(-)

diff --git a/.kilo/commands/code.md b/.kilo/commands/code.md
index 48cc0e9..281999c 100644
--- a/.kilo/commands/code.md
+++ b/.kilo/commands/code.md
@@ -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]
 ```
\ No newline at end of file