don
/
neon-sprawl
mirror of https://github.com/ViPro-Technologies/neon-sprawl
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
neon-sprawl/.cursor/rules/commit-and-review.md

2.5 KiB
Raw Blame History

description alwaysApply
Commits at agent discretion on story work; never git push; PR text without tool boilerplate true

Commits and review (Neon Sprawl)

When the agent may commit

  • You may run git commit at your discretion while working on a Linear issue (or other ticketed work): logical checkpoints, end of a coherent change, plan-only commits on the story branch, implementation batches, test additions, etc.
  • Use judgment: small, coherent commits are easier to review than one huge dump; match linear-git-naming for message format when a ticket applies.
  • If the user is not on a story branch and the change is exploratory or ambiguous, prefer leaving the working tree uncommitted and summarizing until scope is clear—unless they asked you to commit.

Never push

  • Do not run git push, git push --force, or any command that updates remote refs. The user publishes branches and opens PRs.
  • Do not configure remotes or credentials to bypass this.

Pull request and push descriptions

  • Do not add “Made-with: Cursor”, “Generated with Cursor”, tool co-author lines, or similar AI/IDE boilerplate to PR descriptions, GitHub merge/squash commit bodies you draft, or other remote-facing narrative unless the user explicitly requests it.
  • Keep PR text to scope, verification, and project-required contract snippets (e.g. from docs/plans/).

Commit message format when a Linear issue applies

  • Any commit that is part of implementing or delivering a Linear issue or task must put the Linear issue id first in the subject line, then :, then the summary (e.g. NEO-8: persist position state in PostgreSQL).
  • Infer the key from the active branch name, the issue under discussion, or Linear context. Full rules (multi-issue commits, chore: when there is no ticket) are in linear-git-naming.

Scope

  • Applies to all commits the agent might make, including documentation-only changes (e.g. docs/plans/, docs/reviews/, README), not only application source.

Code review follow-up

When commits address feedback from a saved docs/reviews/… file, include an update to that review file: strikethrough + Done on the original Suggestions / Nits / Blocking bullets (not a separate resolved section). See planning-implementation-docs Code review follow-up and code-review-agent Resolved suggestions.