|
37 | 37 | - Read files >500 LOC in chunks using offset/limit; never assume one read captured the whole file |
38 | 38 | - Before every edit: re-read the file. After every edit: re-read to confirm the change applied correctly |
39 | 39 | - When renaming anything, search separately for: direct calls, type references, string literals, dynamic imports, re-exports, test files — one grep is not enough |
| 40 | +- Tool results over 50K characters are silently truncated — if search returns suspiciously few results, narrow scope and re-run |
| 41 | +- For tasks touching >5 files: use sub-agents with worktree isolation to prevent context decay |
40 | 42 |
|
41 | 43 | ## JUDGMENT PROTOCOL |
42 | 44 |
|
|
50 | 52 | - Try the simplest approach first; if architecture is actually flawed, flag it and wait for approval before restructuring |
51 | 53 | - When asked to "make a plan," output only the plan — no code until given the go-ahead |
52 | 54 |
|
| 55 | +## COMPLETION PROTOCOL |
| 56 | + |
| 57 | +- **NEVER claim done with something 80% complete** — finish 100% before reporting |
| 58 | +- When a multi-step change doesn't immediately show gains, commit and keep iterating — don't revert |
| 59 | +- If one approach fails, fix forward: analyze why, adjust, rebuild, re-measure — not `git checkout` |
| 60 | +- After EVERY code change: build, test, verify, commit. This is a single atomic unit |
| 61 | +- Reverting is a last resort after exhausting forward fixes — and requires explicit user approval |
| 62 | + |
53 | 63 | ## SELF-EVALUATION |
54 | 64 |
|
55 | 65 | - Before calling anything done: present two views — what a perfectionist would reject vs. what a pragmatist would ship |
56 | 66 | - After fixing a bug: explain why it happened |
57 | 67 | - If a fix doesn't work after two attempts: stop, re-read the relevant section top-down, state where the mental model was wrong, propose something fundamentally different |
58 | 68 | - If asked to "step back" or "going in circles": drop everything, rethink from scratch |
59 | 69 |
|
| 70 | +## SELF-IMPROVEMENT |
| 71 | + |
| 72 | +- After ANY correction from the user: log the pattern to memory so the same mistake is never repeated |
| 73 | +- Convert mistakes into strict rules — don't just note them, enforce them |
| 74 | +- After fixing a bug: explain why it happened and whether anything prevents that category of bug in the future |
| 75 | + |
| 76 | +## FILE SYSTEM AS STATE |
| 77 | + |
| 78 | +The file system is working memory. Use it actively: |
| 79 | + |
| 80 | +- Write intermediate results and analysis to files in `.claude/` |
| 81 | +- Use `.claude/` for plans, status tracking, and cross-session context |
| 82 | +- When debugging, save logs and outputs to files for reproducible verification |
| 83 | +- Don't hold large analysis in context — write it down, reference it later |
| 84 | + |
60 | 85 | ## HOUSEKEEPING |
61 | 86 |
|
62 | 87 | - Before risky changes: offer to checkpoint — "want me to commit before this?" |
|
0 commit comments