Git Commit, Push & PR

Context

• Current git status: !git status
• Current git diff (staged and unstaged changes): !git diff HEAD
• Current branch: !git branch --show-current
• Main branch: !git rev-parse --verify main 2>/dev/null && echo main || echo master
• Recent commits: !git log --oneline -10

Your task

Review the changes in the repo and ship them as a pull request in one go.

Step 1 — Analyze changes and plan commits

Before committing, analyze git status and git diff HEAD to identify logically distinct groups of changes. Group by feature or concern — for example:

• New files that form a self-contained module → one commit
• Modifications to an existing file that depend on the new module → separate commit
• Config or tooling changes → separate commit

Print a short commit plan (list of planned commits with the files in each) so the grouping is visible.

Step 2 — Commit

• Create one commit per logical group identified above. Stage only the files for that group using explicit file names (never git add -A; never stage .env or credential files).
• Write a clean, descriptive commit message for each commit using conventional commits style.
• End every commit message with: Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
• Use a HEREDOC to pass the commit message for correct formatting.

Step 3 — Push

• If the current branch is main or master, create a new feature branch first (use a descriptive name based on the changes).
• Push the branch to origin with -u to set upstream tracking.

Step 4 — Pull Request

• Create a PR using gh pr create targeting the main branch.
• Keep the PR title short (under 70 characters), using conventional commit style.
• Use a HEREDOC for the PR body with this format:

## Summary
<1-3 bullet points describing the changes>

## Test plan
- [ ] <testing checklist items>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Step 5 — Report

• Print the PR URL so the user can see it.

Rules

• Do all steps in as few messages as possible. Parallelize independent tool calls.
• Do not read or explore code beyond what git provides in the context above.
• Do not use interactive git flags (-i).
• Never force-push or amend existing commits.
• If a pre-commit hook fails, fix the issue and create a NEW commit (do not amend).