work-unit-commits

1## When to Use
2 
3Load this skill when deciding what belongs in each commit or PR.
4 
5Use it for:
6 
7- Splitting a feature into reviewable work.
8- Preparing commits before opening a PR.
9- Turning a large change into chained or stacked PRs.
10- Keeping reviewer cognitive load healthy.
11- Applying SDD tasks without accidentally producing a PR above 400 changed lines.
12 
13## Critical Rules
14 
15| Rule | Requirement |
16|------|-------------|
17| Commit by work unit | A commit represents a deliverable behavior, fix, migration, or docs unit. |
18| Do not commit by file type | Avoid `models`, then `services`, then `tests` if none works alone. |
19| Keep tests with code | Tests belong in the same commit as the behavior they verify. |
20| Keep docs with the user-visible change | Docs belong with the feature or workflow they explain. |
21| Tell a story | A reviewer should understand why each commit exists from its diff and message. |
22| Future PR-ready | Each commit should be a candidate chained PR when the change grows. |
23| SDD workload guard | If SDD tasks forecast a >400-line change, group commits into chained PR slices before implementation. |
24 
25## Work Unit Checklist
26 
27Before committing, confirm:
28 
29- [ ] The commit has one clear purpose.
30- [ ] The repo still makes sense after applying only this commit.
31- [ ] Tests or docs for this unit are included when relevant.
32- [ ] Rollback is reasonable without reverting unrelated work.
33- [ ] Focused test command and exact result are recorded.
34…