Start a fresh conversation. Replace the highlighted placeholders.
Use gentle-ai-work-unit-commits to inspect [working-tree scope] and propose logical commit boundaries plus Conventional Commit messages under [repository scope/style rules and selected delivery strategy]. Keep each behavior with its tests/docs and an independent rollback story. Forecast authored additions plus deletions against [review budget, default 400], make one honest slicing pass, and report irreducible overages under destination policy. Do not compress code or remove meaningful content to fit. Return each unit's start/end state and verification; do not stage or commit.
Required inputs
[working-tree scope]
[repository scope/style rules and selected delivery strategy]
[review budget, default 400]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: gentle-ai-work-unit-commitsdescription: "Plan commits as reviewable work units. Trigger: implementation, commit splitting, chained PRs, or keeping tests and docs with code."license: Apache-2.0metadata: author: gentleman-programming version: "1.0"
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.
Committing ODD work in reviewable slices of about 400 authored 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, honor the selected delivery_strategy. On chaining paths only, group commits into chained PR slices before implementation. For explicit single-pr or exception-ok, keep one PR, report the review load, and follow the destination repository's documented contribution/size policy; selection alone does not accept an exception.
Budget is not code-golf
Never shrink a diff by deleting comments, blank lines, docs, or tests, or by compressing code, to fit the review budget (400 by default, or the session review_budget_lines). Slice by work unit or report the overage.
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.
The commit message explains the outcome, not the file list.
Split Examples
Weak split
Better work-unit split
add models
feat(auth): add token validation domain model and tests
add services
feat(auth): wire token validation into login flow
add tests
Tests included with each behavior commit
update docs
Docs included with the user-facing change they explain
PR Relationship
Use work-unit commits as the foundation for chained PRs:
Build the smallest independent work unit.
Include verification for that unit.
Commit it with a Conventional Commit message.
If the PR approaches 400 changed lines, promote commits or groups of commits into chained PRs.
SDD Relationship
When sdd-tasks produces a Review Workload Forecast:
Low risk: keep work-unit commits inside one PR.
Medium risk: commit by work unit and monitor changed lines before PR creation.
High risk: follow SDD delivery_strategy — ask on ask-on-risk, auto-slice with the cached chain choice on auto-chain, follow the destination repository's documented contribution/size policy on over-budget single-pr, or record an explicitly accepted policy exception on exception-ok. A single-PR selection does not itself accept an exception.
size:exception is a Gentle-owned repository policy, not a universal label requirement. Never request, create, or add the label for generic users unless the destination policy uses it; preserve its maintainer acceptance and protected-label authorization gates.
Splitting is bounded: after one honest slicing pass, if no cohesive work-unit split fits the budget, stop and report the smallest honest count and rationale. Recommend an exception only where destination policy provides it. Do not iterate shrinking the code to reach the number.
Each SDD work unit should map cleanly to a commit or PR with:
clear start state,
clear finished state,
verification in the same unit,
rollback that does not remove unrelated work.
ODD Relationship
ODD commits work units in reviewable slices of about 400 authored changed lines, not one commit per task:
A slice holds one or more whole tasks with their tests and docs; the last slice closes the feature.
A unit whose Risk line names a high-risk item gets its own commit, so native review takes it alone.
The native review candidate is that commit, or the PR slice it belongs to when review is deferred, evaluated against the previous reviewed boundary.
The running authored line count from work-unit commits feeds the same delivery-strategy vocabulary as SDD.
The feature document records the commit that holds each task and, once a delivery strategy applies, the slice boundaries.
Commands
# Review the story before committing
git diff --stat
git diff --cached --stat
# Check recent commit style
git log --oneline -5
gentle-ai-work-unit-commits by Gentleman-Programming · The Skill Leaderboard