- [ ] **Define your commit message standard.**
→ *Document it in the README under “Commit Style.” Require every commit to answer **What changed?** (summary) and **Why?** (motivation/rationale).*
- [ ] **Question:** What structure will you use?
→ *Adopt a simple template (e.g. one-line summary + body explaining **why** + footer for issue links) or **Conventional Commits** (`type(scope): summary`). Put the template in `/docs/commit_style.md`.*
- [ ] **Create a commit message template file.**
→ *Add `.gitmessage` (or `.github/commit_template.txt`) with headings: `What`, `Why`, `How/Notes`, `Tests`, `Refs`. Configure `git config commit.template` and note the command in the README.*
- [ ] **Conventional Commits (optional but recommended).**
→ *Define allowed `type`s (e.g. `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `build`, `ci`) and optional `scope`. Add 3–5 good examples in `/docs/commit_style.md`.*
- [ ] **Question:** How will you enforce the style?
→ *Set up tooling (e.g. `commitlint` + `husky` for Node, `pre-commit` hooks for Python, or IDE plugins). Add config files and a short install step to the README.*
- [ ] **Subject line rules.**
→ *Use imperative mood (“Add”, “Fix”, “Refactor”), keep it concise (≈50 chars), and avoid trailing period. Explain **why** in the body if not obvious.*
- [ ] **Body & footer conventions.**
→ *Wrap at ~72 chars; include the **Why** (reason, trade-offs, alternatives) and, if useful, the **How** (high-level). Link issues/MRs with `Fixes #123`, `Refs #456`.*
- [ ] **Question:** What is your commit granularity policy?
→ *Agree on “one logical change per commit,” and when to **squash** (e.g. during MR merge). Record the rule in the README.*
- [ ] **Provide examples of good vs. weak messages.**
→ *Add 2–3 contrasting examples in `/docs/commit_style.md` showing clear “what + why” vs. vague messages.*
- [ ] **Onboarding quick-check.**
→ *Open an issue “Commit Style Dry Run” where each member posts one example commit message; reviewers confirm it meets the standard.*