description	alwaysApply
Never git commit without explicit user instruction; user reviews before any commit	true

Commits and review (Neon Sprawl)

No commits without explicit instruction

Do not run git commit (or equivalent, e.g. committing via tools) unless the user explicitly asks—clear wording such as “commit this”, “make a commit”, or “commit with message …”.
Phrases like “implement X”, “begin work”, or “open a PR” are not implicit permission to commit.
Default after edits: leave changes uncommitted (working tree or staged only if the user asked to stage). Summarize what changed and where so the user can review in the Git / diff UI, then wait for commit instructions.

The user should review the diff before anything is committed. The agent’s job is to make the changes visible (uncommitted) and explain them; the user decides when to commit.
If the user asks to commit, use a message that matches repo conventions; still follow git workflow (branch vs main, doc-only vs code).

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. NS-17: 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.

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

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