docs: refine commit message guidelines

- Allow bullet points for distinct subsections or components
- Focus on functional changes rather than business impact
- Clarify when to use bullets vs single descriptions

Author: steviec

.claude/commands/commit.md

@@ -21,8 +21,10 @@ Handle the complete commit workflow:
    - Use conventional commit format: `<type>: <description>`
    - Types: feat, fix, docs, style, refactor, test, chore
    - Keep description concise (under 50 chars), focus on purpose/benefit
-   - Add body only if needed to explain WHY (1-2 sentences max)
+   - Add body only if needed to explain WHY or list distinct subsections
+   - Use bullet points for multiple logical components or subsections
    - NEVER mention specific files, methods, classes, or implementation details
+   - Focus on user/business impact, not technical implementation
 
 3. **Handle pre-commit hooks**:
    - Attempt commit to trigger lefthook checks

commit-examples.md

@@ -0,0 +1,48 @@
+# Commit Message Examples
+
+## Good Examples with Subsections
+
+### Multiple Related Features
+
+```
+feat: enhance eval testing capabilities
+
+- Remove json-schema scorer (doesn't serve realistic use case)
+- Add auto-fixing pre-commit hooks
+- Improve commit message guidelines
+```
+
+### Different Areas of Impact
+
+```
+fix: resolve authentication and validation issues
+
+- Fix token validation logic
+- Update error handling for expired sessions
+- Improve user feedback for auth failures
+```
+
+### Single Focused Change
+
+```
+feat: implement auto-fixing pre-commit hooks
+
+Pre-commit hooks now automatically fix and re-stage formatting and linting issues.
+```
+
+## Bad Examples (Too Technical)
+
+```
+feat: implement auto-fixing pre-commit hooks
+
+- Add stage_fixed: true to format and lint commands in lefthook.yml
+- Update runJsonSchemaScorer method in EvalTestRunner class
+- Modify test-config.json schema validation
+```
+
+## Guidelines
+
+- Use bullets when there are 2+ distinct logical subsections
+- Each bullet should describe a user-facing change or benefit
+- Avoid implementation details (file names, method names, etc.)
+- Focus on WHAT the user gets, not HOW it's implemented