|
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 | + |
| 63 | +## FILE SYSTEM AS STATE |
| 64 | + |
| 65 | +The file system is working memory. Use it actively: |
| 66 | + |
| 67 | +- Write intermediate results and analysis to files in `.claude/` |
| 68 | +- Use `.claude/` for plans, status tracking, and cross-session context |
| 69 | +- When debugging, save logs and outputs to files for reproducible verification |
| 70 | +- Don't hold large analysis in context — write it down, reference it later |
| 71 | + |
| 72 | +## SELF-IMPROVEMENT |
| 73 | + |
| 74 | +- After ANY correction from the user: log the pattern to memory so the same mistake is never repeated |
| 75 | +- Convert mistakes into strict rules — don't just note them, enforce them |
| 76 | +- After fixing a bug: explain why it happened and whether anything prevents that category of bug in the future |
| 77 | + |
53 | 78 | ## SELF-EVALUATION |
54 | 79 |
|
55 | 80 | - Before calling anything done: present two views — what a perfectionist would reject vs. what a pragmatist would ship |
|
0 commit comments