neon-sprawl/.cursor/rules/commit-and-review.md

description	alwaysApply
Commits at agent discretion; push only when user asks; gh pr create with NEO-* title when opening PRs; 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 unless the user explicitly asks to publish (e.g. “push”, “push the branch”, “open a PR” / “create a PR” when the branch is not yet on origin). In those cases you may run a normal git push -u origin HEAD (or the named branch) so the remote exists—still never --force to rewrite published history.
• 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/).

Opening a PR when the user asks

When the user asks to open, create, or file a pull request (or clearly wants one opened for the current branch):

1. Use the GitHub CLI — Run gh pr create (not only a browser /pull/new/... link). That way you control the title and avoid GitHub’s default, which title-cases the branch name and turns NEO-25 into Neo 25.
2. Title — --title must begin with the Linear issue key in canonical form: NEO-123: (see linear-git-naming: uppercase team prefix, hyphen, issue number), then a short human summary. Example: NEO-25: InteractableDescriptor list / fetch-driven client.
3. Infer the key — In order: the current branch’s leading segment (e.g. NEO-25-my-slug → NEO-25); the matching docs/plans/{KEY}-implementation-plan.md on the branch; Linear MCP / issue in chat; or ask the user if ambiguous.
4. Body — Pass --body or --body-file with scope, how to verify (dotnet test, manual QA path, etc.), and pointers to docs/plans/ when useful.
5. Upstream — If gh pr create fails because the branch is not on origin, push first (only as allowed under Never push above—i.e. the same user message asked to open the PR or explicitly to push).
6. Fallback — If gh is missing or not authenticated (gh auth status), tell the user and optionally still give the pull/new/... URL, with an explicit reminder to edit the title so it starts with NEO-123: (not Neo 123).

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.