|
1 | | -## Principles |
2 | | -<!-- rule-id: R-0001, added: 2026-01-01, trigger: founding rule --> |
| 1 | +# Workflow Orchestration |
3 | 2 |
|
4 | | -- Point out issues, blind spots, and risks directly. No flattery. |
5 | | -- If unclear, ask. Don't proceed on assumptions. |
6 | | -- Provide recommendations with ratings (⭐1-5) and reasoning. |
| 3 | +## 1. Plan Mode Default |
| 4 | +- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions) |
| 5 | +- If something goes sideways, STOP and re-plan immediately – don't keep pushing |
| 6 | +- Use plan mode for verification steps, not just building |
| 7 | +- Write detailed specs upfront to reduce ambiguity |
7 | 8 |
|
8 | | -## Delegation |
9 | | -<!-- rule-id: R-0002, added: 2026-01-01, trigger: founding rule --> |
10 | 9 |
|
11 | | -| Scope | Action | |
12 | | -|-------|--------| |
13 | | -| Simple (≤5 lines, 1 file) | Execute directly | |
14 | | -| Medium (multiple files, research needed) | Delegate to Task agent | |
15 | | -| Large (new feature, refactor) | Multiple agents in parallel | |
| 10 | +## 2. Subagent Strategy |
| 11 | +- Use subagents liberally to keep main context window clean |
| 12 | +- Offload research, exploration, and parallel analysis to subagents |
| 13 | +- For complex problems, throw more compute at it via subagents |
| 14 | +- One task per subagent for focused execution |
16 | 15 |
|
17 | | -## Plan Mode |
18 | | -<!-- rule-id: R-0013, added: 2026-02-23, trigger: Boris Cherny best practices analysis --> |
19 | 16 |
|
20 | | -- Enter plan mode for tasks with 3+ steps or architectural decisions |
21 | | -- If unexpected issues arise during implementation, STOP immediately and re-plan |
| 17 | +## 3. Self-Improvement Loop |
| 18 | +- After ANY correction from the user: update `tasks/lessons.md` with the pattern |
| 19 | +- Write rules for yourself that prevent the same mistake |
| 20 | +- Ruthlessly iterate on these lessons until mistake rate drops |
| 21 | +- Review lessons at session start for relevant project |
22 | 22 |
|
23 | | -## Forbidden |
24 | | -<!-- rule-id: R-0003, added: 2026-01-01, trigger: founding rule --> |
25 | 23 |
|
26 | | -- Committing secrets (.env, credentials, secrets) |
27 | | -- Direct push to main/master without confirmation |
28 | | -- Deleting files without permission |
| 24 | +## 4. Verification Before Done |
| 25 | +- Never mark a task complete without proving it works |
| 26 | +- Diff behavior between main and your changes when relevant |
| 27 | +- Ask yourself: "Would a staff engineer approve this?" |
| 28 | +- Run tests, check logs, demonstrate correctness |
29 | 29 |
|
30 | | -## Debugging rule |
31 | | -<!-- rule-id: R-0004, added: 2026-01-01, trigger: founding rule --> |
32 | 30 |
|
33 | | -- Before coding a fix, trace the full data-flow end-to-end: |
34 | | - UI -> state -> query/params -> compute -> render |
35 | | -- Don't "patch symptoms". Show the chain and prove where the value changes. |
36 | | -- When fixed, verify with: (1) reproduction steps, (2) a targeted test, (3) typecheck/build. |
| 31 | +## 5. Demand Elegance |
| 32 | +- For non-trivial changes: pause and ask "is there a more elegant way?" |
| 33 | +- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution" |
| 34 | +- Skip this for simple, obvious fixes – don't over-engineer |
| 35 | +- Challenge your own work before presenting it |
37 | 36 |
|
38 | | -## Quality Gate |
39 | | -<!-- rule-id: R-0014, added: 2026-02-23, trigger: Boris Cherny best practices analysis --> |
40 | 37 |
|
41 | | -- Before completing a task, ask yourself: "Would a staff engineer approve this change?" |
42 | | -- If NO, do not mark as complete — improve it first |
| 38 | +## 6. Autonomous Bug Fixing |
| 39 | +- When given a bug report: just fix it. Don't ask for hand-holding |
| 40 | +- Point at logs, errors, failing tests – then resolve them |
| 41 | +- Zero context switching required from the user |
| 42 | +- Go fix failing CI tests without being told how |
43 | 43 |
|
44 | | -## Session exit |
45 | | -<!-- rule-id: R-0005, added: 2026-01-01, trigger: founding rule --> |
46 | 44 |
|
47 | | -- Before we end, always output: |
48 | | - 1) What changed (files) |
49 | | - 2) Remaining TODOs |
50 | | - 3) Commands for me to run |
51 | | - 4) Risks/assumptions |
| 45 | +--- |
52 | 46 |
|
53 | | -## SubAgent |
54 | | -<!-- rule-id: R-0006, added: 2026-01-01, trigger: founding rule --> |
| 47 | +## Task Management |
| 48 | +1. Plan First: Write plan to `tasks/todo.md` with checkable items |
| 49 | +2. Verify Plan: Check in before starting implementation |
| 50 | +3. Track Progress: Mark items complete as you go |
| 51 | +4. Explain Changes: High-level summary at each step |
| 52 | +5. Document Results: Add review section to `tasks/todo.md` |
| 53 | +6. Capture Lessons: Update `tasks/lessons.md` after corrections |
55 | 54 |
|
56 | | -Always cite sources. If unverified, state "unverified". |
57 | 55 |
|
58 | | -## Workflow |
59 | | -<!-- rule-id: R-0007, added: 2026-01-01, trigger: founding rule --> |
| 56 | +--- |
60 | 57 |
|
61 | | -- Use built-in EnterWorktree for file changes (not manual git worktree commands) |
62 | | -- For extensions, see `/claude-code-guide` |
63 | | -- Resume named sessions: `claude --resume <name>` |
64 | | -- Use `/rewind` to undo recent changes |
65 | | -- Use `/memory` to manage persistent context |
66 | | -- Use `/keybindings` to view/edit keyboard shortcuts |
67 | | - |
68 | | - |
69 | | -## Content Guidelines |
70 | | -<!-- rule-id: R-0009, added: 2026-01-01, trigger: founding rule --> |
71 | | - |
72 | | -- OK: Use Claude to articulate your own experiences more clearly |
73 | | -- NG: Use Claude to fabricate experiences |
74 | | - |
75 | | -## Governance |
76 | | -<!-- rule-id: R-0010, added: 2026-02-22, trigger: Boris Cherny philosophy implementation --> |
77 | | - |
78 | | -- If test/build/lint failures recur 3 times, propose a rule via governance-proposer |
79 | | -- Run `/governance-review` monthly to audit rule freshness |
80 | | -- All CLAUDE.md rules must have provenance: `<!-- rule-id: XX, added: YYYY-MM-DD, trigger: description -->` |
81 | | - |
82 | | -## Self-Improvement Loop |
83 | | -<!-- rule-id: R-0012, added: 2026-02-23, trigger: Boris Cherny best practices analysis --> |
84 | | - |
85 | | -- When corrected by the user, immediately record the pattern in auto memory |
86 | | -- Record: what was wrong, the correct pattern, and a prevention rule |
87 | | -- Check memory at session start to leverage past lessons |
88 | | - |
89 | | -## Simplification |
90 | | -<!-- rule-id: R-0011, added: 2026-02-22, trigger: Boris Cherny philosophy implementation --> |
91 | | - |
92 | | -- Single module: `/simplify-pipeline` |
93 | | -- Multiple modules: `/refactor-swarm` |
94 | | -- Simplification must not change behavior. Behavior changes are a separate task |
| 58 | +## Core Principles |
| 59 | +- Simplicity First: Make every change as simple as possible. Impact minimal code. |
| 60 | +- No Laziness: Find root causes. No temporary fixes. Senior developer standards. |
| 61 | +- Minimal Impact: Changes should only touch what's necessary. Avoid introducing bugs. |
0 commit comments