docs(skills): add git-commits skill

Document Conventional Commits style and one-commit-per-concern splitting for this project.

.agents/skills/git-commits/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: git-commits
+description: Write Git commit messages for this project using Conventional Commits, splitting work into one commit per concern. Use when staging changes, writing or amending commit messages, or deciding how to break a set of changes into commits.
+---
+
+# Git Commits
+
+Use this skill whenever you write a commit message or decide how to group changes into commits.
+
+## Commit message style: Conventional Commits
+
+Every commit message must follow the Conventional Commits format:
+
+```
+<type>(<optional scope>): <description>
+
+<optional body>
+
+<optional footer(s)>
+```
+
+### Types
+
+- `feat`: a new feature
+- `fix`: a bug fix
+- `docs`: documentation only
+- `style`: formatting, whitespace, or other changes that do not affect behavior
+- `refactor`: a code change that neither fixes a bug nor adds a feature
+- `perf`: a performance improvement
+- `test`: adding or correcting tests
+- `build`: changes to the build system or dependencies
+- `ci`: changes to CI configuration and scripts
+- `chore`: other changes that do not modify source or tests
+- `revert`: revert a previous commit
+
+### Rules
+
+- Use the imperative mood in the description ("add", not "added" or "adds").
+- Keep the description lowercase and do not end it with a period.
+- Limit the subject line to 50 characters where practical; never exceed 72.
+- Add a scope in parentheses when it clarifies the area of change, e.g. `fix(parser): ...`.
+- Separate the subject from the body with a blank line.
+- Use the body only when it adds useful information; do not restate the subject.
+- Wrap the body at 72 characters.
+- Reference issues in the footer when relevant, e.g. `Closes #123`.
+- Mark breaking changes with `!` after the type/scope (e.g. `feat(api)!: ...`) and explain them in a `BREAKING CHANGE:` footer.
+
+## Separate commits by concern
+
+Do not bundle unrelated changes into a single commit. Split work so that each commit represents one logical concern:
+
+- One type of change per commit (a feature and its unrelated refactor are separate commits).
+- Keep formatting-only changes separate from behavior changes.
+- Keep test additions separate from the implementation they cover when they are independently meaningful, but do not split so finely that a commit is not self-contained.
+- Each commit should build and pass tests on its own where feasible.
+- Stage files selectively (e.g. `git add -p`, `git add <path>`) to isolate concerns rather than committing everything at once.
+
+When a set of changes spans multiple concerns, propose the split to the user before committing.
+
+## Workflow
+
+1. Inspect what changed with `git --no-optional-locks status` and `git --no-pager diff`.
+2. Group the changes by concern.
+3. For each group, stage only the relevant files or hunks.
+4. Write a Conventional Commits message for that group.
+5. Repeat until all changes are committed.
+
+Do not commit or create branches unless the user explicitly asks.