chore: make CLAUDE.md rules more concise - #31892
Conversation
Greptile SummaryThis PR condenses two verbose instructions in
Confidence Score: 5/5Documentation-only change with no effect on production code; safe to merge. The change is limited to CLAUDE.md and only touches developer-facing instructions. The core staging-first requirement is preserved in both simplified paragraphs. The one nuance that was removed (the partial-staging/over-tightening footgun) is an edge case that would at worst cause a local CI mismatch rather than production impact. No files require special attention.
|
| Filename | Overview |
|---|---|
| CLAUDE.md | Simplified two developer workflow instructions; the core staging requirement is preserved, but the explanation of why partial staging causes budget over-tightening is removed. |
Reviews (1): Last reviewed commit: "chore: make CLAUDE.md rules more concise" | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| Don't hesitate to use values in .env to get needed API keys and other secrets, as long as you never add them to conversation history, commit them, or include them in GitHub issues / PRs | ||
|
|
||
| Run tests before you commit. Also, run `make pre-commit` right before each commit, which generates types (as needed) and formats/lints your code. Any errors found must be fixed. For `make pre-commit` to work properly you must stage your changes first (git add): it reports CI red or green based on what would happen if you committed your staged changes, but it runs the linters over the working tree, so any unstaged edits to tracked files or untracked files are folded into the result and will skew it away from what CI (which only sees your commit) would report | ||
| Run tests before you commit. Also, after you stage your changes and before you commit, run `make pre-commit`, which generates types (as needed) and formats/lints your code. Any errors found must be fixed |
There was a problem hiding this comment.
make lint-budget-update
The removed text explained a subtle footgun: if you have more linting fixes in the working tree than you actually plan to commit, make lint-budget-update will tighten the budget based on the full working-tree count, but CI will only see the committed subset — causing it to go red. The new text says "stage your changes" (which implies staging everything you have), but omits the instruction to stage only the fixes you're committing. An agent or developer with half-committed fixes could reliably fail CI without understanding why.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
2 participants
Cut out unneeded bloat in the CLAUDE.md