From 8a468709f0d4e431880fd773c2e9cd145302a9c3 Mon Sep 17 00:00:00 2001 From: lucaronin Date: Fri, 20 Feb 2026 22:38:18 +0100 Subject: [PATCH] docs: enforce max 30min between commits to prevent work loss --- CLAUDE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CLAUDE.md b/CLAUDE.md index 89033c16..2db2c0ed 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -74,7 +74,7 @@ After every meaningful architectural decision or abstraction, update the relevan - **Small steps**: Build one thing at a time. Get it working, test it, commit it. Then move to the next. - **Test as you go**: Write tests alongside code, not after. If you build a frontmatter parser, test it immediately with real-world examples before moving on. - **Verify constantly**: After each meaningful change, run the relevant tests (`cargo test`, `pnpm test`). Don't stack up a bunch of code and hope it all works. -- **Commit often — small and atomic**: Each logical unit of work gets its own commit with a clear message. NEVER batch multiple features or fixes into one big commit. Examples of good atomic commits: +- **Commit often — small and atomic**: Each logical unit of work gets its own commit. **Never work for more than 20–30 minutes without committing something.** If you've been coding for 30 min and have no commit, stop and commit what you have — even if it's incomplete (use `wip:` prefix). This protects against session crashes and timeouts. NEVER batch multiple features or fixes into one big commit. Examples of good atomic commits: - `feat: update color palette and CSS variables` - `feat: restructure sidebar with collapsible sections` - `fix: editor scroll overflow`