work-unit-commits

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