These rules cover pull requests, issues, @-mentions, and commit trailers. Some respond directly to agent traffic, such as unsolicited pull requests and duplicate issues.
State who may open, post, or push something and what review steps come first. Include the rules for commit and pull-request text.
The no-force-push rule explains that changes will be squashed at merge and reviewers need to see follow-up commits. It gives a concrete reason to keep the branch history intact.
CLAUDE.mdL35–38
Source excerpt starting at line 35.
35- When pushing updates to the PR, make sure to never force push. Create as many36 commits as you need, all of them get squashed when the PR is merged, so there37 is no need to rewrite history. This also allows reviewers to see the38 incremental changes you made in response to feedback.
The guide requires an uppercase description, prohibits scopes, and classifies factory changes as chore. It points to the enforcing workflow and supplies example titles.
AGENTS.mdL15–19
Source excerpt starting at line 15.
15Key rules:1617- Description must start with an uppercase letter18- Scopes are not allowed19- A change for apps/factory should always be marked `chore:`
The contribution guidance connects each push to paid automated review. It asks for local iteration followed by a batch push, making the reason for the cadence visible.
AGENTS.mdL65
Source excerpt starting at line 65.
65- **Do not push after every commit.** Pushes to open PRs trigger automated reviews that cost money. Commit locally as you go, and only push when the work is complete (or the user asks for feedback on work in progress). When in doubt, ask before pushing