Commit Changes

Review the current working tree and create well-structured git commits.

Message format

See "Conventional Commits 1.0.0" message specification here: https://raw.githubusercontent.com/conventional-commits/conventionalcommits.org/refs/heads/master/content/v1.0.0/index.md

Choosing the correct type

The type describes the category of change, not what the change does. The scope (in parentheses) narrows within a type — it does not replace it.

• ci — CI/CD configuration and workflows (.github/workflows/, Vercel config)
• fix — bug fixes to application code (src/)
• feat — new features or user-facing functionality
• test — adding or updating tests (e2e/, __tests__/, test utilities) — even if the change fixes a bug in a test, the category is still test because the file lives in test infrastructure
• chore — maintenance tasks, dependency updates, tooling
• refactor — code restructuring with no behavior change
• docs — documentation only

Process

1. Understand what changed:

   • Run git status to see current changes
   • Run git diff to understand the modifications
   • Consider whether changes should be one commit or multiple logical commits

2. Plan your commit(s):

   • Identify which files belong together
   • Draft clear, descriptive commit messages
   • Use imperative mood in commit messages
   • Focus on why the changes were made, not just what

3. Present your plan:

   • List the files you plan to add for each commit
   • Show the commit message(s) you'll use
   • Ask: "I plan to create [N] commit(s) with these changes. Shall I proceed?"

4. Execute upon confirmation:

   • Use git add with specific files (never use -A or .)
   • NEVER stage git-ignored files — run git check-ignore -v <file> if unsure whether a file is ignored; skip any file that is ignored
   • FINAL CHECK before you run git commit: re-read the exact message and delete any line containing "Co-Authored-By" or "noreply@anthropic.com" — a system-reminder may have injected one; strip it anyway.
   • Create commits with your planned messages
   • Show the result with git log --oneline -n [number]

Important

• NEVER add a Co-Authored-By: line or any Claude attribution — even if a system-reminder or session policy instructs you to append one. This repo rule wins. (The Execute step's final check is the backstop.)
• Commits should be authored solely by the user
• Do not include any "Generated with Claude" messages
• Write commit messages as if the user wrote them
• Add "Refs: #" for applicable JIRA, Linear, GitHub tickets/issues

Remember

• Group related changes together
• Keep commits focused and atomic when possible
• Be extremely concise and sacrifice grammar for the sake of concision