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 Jira story (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 jira-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.

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.

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/).

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

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