Git Commit with Bullet-List Body

Make commits that are easy to review and safe to ship: only intended changes are included, commits are logically scoped (split when needed), and commit messages describe what changed and why. The message body must be written as a bullet list, not a paragraph.

---

Inputs to ask for (if missing)

• Single commit or multiple commits? (If unsure: default to multiple small commits when there are unrelated changes.)
• Commit style: Conventional Commits are required.
• Any rules: max subject length, required scopes.

---

Workflow (checklist)

1. Inspect the working tree before staging

   • git status
   • git diff (unstaged)
   • If many changes: git diff --stat

2. Decide commit boundaries (split if needed)

   • Split by: feature vs refactor, backend vs frontend, formatting vs logic, tests vs prod code, dependency bumps vs behavior changes.
   • If changes are mixed in one file, plan to use patch staging.

3. Stage only what belongs in the next commit

   • Prefer patch staging for mixed changes: git add -p
   • To unstage a hunk/file: git restore --staged -p or git restore --staged <path>

4. Review what will actually be committed

   • git diff --cached
   • Sanity checks: no secrets or tokens, no accidental debug logging, no unrelated formatting churn.

5. Describe the staged change in 1-2 sentences (before writing the message)

   • "What changed?" + "Why?"
   • If you cannot describe it cleanly, the commit is probably too big or mixed; go back to step 2.

6. Write the commit message

   • Use Conventional Commits (required): type(scope): short summary, then blank line, then body as a bullet list (what/why, not implementation diary). Footer (e.g. BREAKING CHANGE) if needed.
   • Subject: One line, imperative, ~50 chars or less.
   • Body: Blank line after subject, then only bullet lines; one bullet per logical change; what and why, not file names. No paragraph prose in the body.
   • Prefer an editor for multi-line messages: git commit -v.

7. Run lint, format, and verification before committing

   • Run the project's format command (e.g. npm run format, prettier --write, ruff format, cargo fmt) so staged code matches project style.
   • Run the project's lint command (e.g. npm run lint, ruff check, eslint, cargo clippy) and fix any issues.
   • Then run the smallest relevant verification (unit tests or build) before moving on.

8. Repeat for the next commit until the working tree is clean.

---

Message format

type(scope): short summary

- Bullet one: what changed and why
- Bullet two: another logical change
- Bullet three: optional detail

• Subject: One line, Conventional Commits (e.g. feat(auth):, fix(api):).
• Body: Blank line after subject, then only bullet lines. No paragraph prose in the body.
• Do not add a Co-authored-by: Cursor <...> (or similar) trailer to the commit message.

---

Body bullets: good vs bad

Good (intent, one idea per bullet):

• Add login endpoint and validate JWT in middleware
• Extend task model with priority field and migration
• Fix date formatting in report export

Bad (file names or vague):

• Changed src/auth.py
• Updated stuff in models

Infer intent from the diff and phrase each bullet as a single, clear change.

---

Committing

• Editor: git commit or git commit -v, then paste subject + blank line + bullets.
• CLI: git commit -m "Subject line" -m "- Bullet one\n- Bullet two\n- Bullet three" or a single -m with the full message if the shell preserves newlines.

---

Checklist

• Working tree inspected; commit boundaries decided
• Only intended changes staged; git diff --cached reviewed
• Change described in 1-2 sentences (what + why)
• Subject line: Conventional Commits, short, imperative
• Body is only a bullet list (no paragraph)
• Bullets describe intent, not just files
• Lint and format run (and any issues fixed); verification run; commit executed with the composed message
• No Co-authored-by Cursor trailer in the message

---

Deliverable

Provide:

• The final commit message(s)
• A short summary per commit (what/why)
• The commands used to stage/review (at minimum: git diff --cached, plus any tests run)