|
2 | 2 |
|
3 | 3 | This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. |
4 | 4 |
|
| 5 | +## Behavioral Guidelines |
| 6 | + |
| 7 | +Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed. |
| 8 | + |
| 9 | +**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment. |
| 10 | + |
| 11 | +## 1. Think Before Coding |
| 12 | + |
| 13 | +**Don't assume. Don't hide confusion. Surface tradeoffs.** |
| 14 | + |
| 15 | +Before implementing: |
| 16 | +- State your assumptions explicitly. If uncertain, ask. |
| 17 | +- If multiple interpretations exist, present them - don't pick silently. |
| 18 | +- If a simpler approach exists, say so. Push back when warranted. |
| 19 | +- If something is unclear, stop. Name what's confusing. Ask. |
| 20 | + |
| 21 | +## 2. Simplicity First |
| 22 | + |
| 23 | +**Minimum code that solves the problem. Nothing speculative.** |
| 24 | + |
| 25 | +- No features beyond what was asked. |
| 26 | +- No abstractions for single-use code. |
| 27 | +- No "flexibility" or "configurability" that wasn't requested. |
| 28 | +- No error handling for impossible scenarios. |
| 29 | +- If you write 200 lines and it could be 50, rewrite it. |
| 30 | + |
| 31 | +Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify. |
| 32 | + |
| 33 | +## 3. Surgical Changes |
| 34 | + |
| 35 | +**Touch only what you must. Clean up only your own mess.** |
| 36 | + |
| 37 | +When editing existing code: |
| 38 | +- Don't "improve" adjacent code, comments, or formatting. |
| 39 | +- Don't refactor things that aren't broken. |
| 40 | +- Match existing style, even if you'd do it differently. |
| 41 | +- If you notice unrelated dead code, mention it - don't delete it. |
| 42 | + |
| 43 | +When your changes create orphans: |
| 44 | +- Remove imports/variables/functions that YOUR changes made unused. |
| 45 | +- Don't remove pre-existing dead code unless asked. |
| 46 | + |
| 47 | +The test: Every changed line should trace directly to the user's request. |
| 48 | + |
| 49 | +## 4. Goal-Driven Execution |
| 50 | + |
| 51 | +**Define success criteria. Loop until verified.** |
| 52 | + |
| 53 | +Transform tasks into verifiable goals: |
| 54 | +- "Add validation" → "Write tests for invalid inputs, then make them pass" |
| 55 | +- "Fix the bug" → "Write a test that reproduces it, then make it pass" |
| 56 | +- "Refactor X" → "Ensure tests pass before and after" |
| 57 | + |
| 58 | +For multi-step tasks, state a brief plan: |
| 59 | +``` |
| 60 | +1. [Step] → verify: [check] |
| 61 | +2. [Step] → verify: [check] |
| 62 | +3. [Step] → verify: [check] |
| 63 | +``` |
| 64 | + |
| 65 | +Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification. |
| 66 | + |
| 67 | +--- |
| 68 | + |
| 69 | +**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes. |
| 70 | + |
5 | 71 | ## Development Setup |
6 | 72 |
|
7 | 73 | ```bash |
|
0 commit comments