|
| 1 | +# AI Agent Guidelines |
| 2 | + |
| 3 | +Last updated: 2026-05-29 |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## Always-Active Instructions |
| 8 | + |
| 9 | +> These apply to EVERY interaction, automatically. |
| 10 | +
|
| 11 | +### Working Discipline |
| 12 | + |
| 13 | +> Behavioral guidelines to reduce common LLM coding mistakes. Bias toward caution over speed; for trivial tasks, use judgment. |
| 14 | +
|
| 15 | +#### 1. Think Before Coding |
| 16 | + |
| 17 | +**Don't assume. Don't hide confusion. Surface tradeoffs.** |
| 18 | + |
| 19 | +Before implementing: |
| 20 | + |
| 21 | +- Read existing code and understand patterns before proposing changes. |
| 22 | +- State your assumptions explicitly. If uncertain, ask. |
| 23 | +- If multiple interpretations exist, present them — don't pick silently. |
| 24 | +- If a simpler approach exists, say so. Push back when warranted. |
| 25 | +- If something is unclear, stop. Name what's confusing. Ask. |
| 26 | + |
| 27 | +#### 2. Simplicity First |
| 28 | + |
| 29 | +**Minimum code that solves the problem. Nothing speculative.** |
| 30 | + |
| 31 | +- No features beyond what was asked. |
| 32 | +- No abstractions for single-use code. |
| 33 | +- No "flexibility" or "configurability" that wasn't requested. |
| 34 | +- No error handling for impossible scenarios. |
| 35 | +- If you write 200 lines and it could be 50, rewrite it. |
| 36 | + |
| 37 | +Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify. |
| 38 | + |
| 39 | +#### 3. Surgical Changes |
| 40 | + |
| 41 | +**Touch only what you must. Clean up only your own mess.** |
| 42 | + |
| 43 | +When editing existing code: |
| 44 | + |
| 45 | +- Don't "improve" adjacent code, comments, or formatting. |
| 46 | +- Don't refactor things that aren't broken. |
| 47 | +- Match existing style, even if you'd do it differently. |
| 48 | +- If you notice unrelated dead code, mention it — don't delete it. |
| 49 | + |
| 50 | +When your changes create orphans: |
| 51 | + |
| 52 | +- Remove imports/variables/functions that YOUR changes made unused. |
| 53 | +- Don't remove pre-existing dead code unless asked. |
| 54 | + |
| 55 | +The test: Every changed line should trace directly to the user's request. |
| 56 | + |
| 57 | +#### 4. Goal-Driven Execution |
| 58 | + |
| 59 | +**Define success criteria. Loop until verified.** |
| 60 | + |
| 61 | +Transform tasks into verifiable goals: |
| 62 | + |
| 63 | +- "Add validation" → "Write tests for invalid inputs, then make them pass" |
| 64 | +- "Fix the bug" → "Write a test that reproduces it, then make it pass" |
| 65 | +- "Refactor X" → "Ensure tests pass before and after" |
| 66 | + |
| 67 | +For multi-step tasks, state a brief plan: |
| 68 | + |
| 69 | +``` |
| 70 | +1. [Step] → verify: [check] |
| 71 | +2. [Step] → verify: [check] |
| 72 | +3. [Step] → verify: [check] |
| 73 | +``` |
| 74 | + |
| 75 | +Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification. |
| 76 | + |
| 77 | +#### 5. Report What Was Done |
| 78 | + |
| 79 | +After completing work, state what changed and why — not just that it's done. |
| 80 | + |
| 81 | +--- |
| 82 | + |
| 83 | +**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. |
| 84 | + |
| 85 | +### Multi-Agent Safety Rules |
| 86 | + |
| 87 | +- **Never** create/apply/drop git stash entries unless explicitly requested |
| 88 | +- **Never** edit files in `node_modules/`, `vendor/`, or other dependency directories |
| 89 | +- **Always** work on a dedicated branch when running concurrent agents |
| 90 | +- **Never** force-push or rebase shared branches from an agent session |
| 91 | +- **Verify** no other agent is modifying the same files before making changes |
| 92 | + |
| 93 | +--- |
0 commit comments