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.
• Closing an ODD task with a work-unit commit.

Critical Rules

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/scenario and exact result are recorded, or explicit N/A explains why no runtime boundary exists.
• Rollback boundary names the exact files/behavior removable without unrelated work.
• The commit message explains the outcome, not the file list.

Split Examples

PR Relationship

Use work-unit commits as the foundation for chained PRs:

1. Build the smallest independent work unit.
2. Include verification for that unit.
3. Commit it with a Conventional Commit message.
4. 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 on auto-chain, require size:exception on over-budget single-pr, or record accepted size:exception on exception-ok.
• Count authored additions plus deletions for the >400 threshold. Exclude generated goldens from that authored count, but include every generated file in complete snapshot identity and receipt validation.
• Splitting is bounded: after one honest slicing pass, if no cohesive work-unit split fits the budget, stop and report the smallest honest count with a size:exception recommendation. 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.

Its implementation evidence MUST include:

• Focused test command and exact result.
• Runtime harness command/scenario and exact result, or explicit N/A with reason.
• Rollback boundary stated independently of commit creation; uncommitted work units still require it.
• When fixing a bounded review ledger, group atomic work units inside the single correction transaction; work-unit count never creates another fix budget.

ODD Relationship

Organic Driven Development (ODD) closes every substantial task with a work-unit commit on the feature branch, not only SDD tasks:

• Every ODD task closes with at least one work-unit commit, branch first when on the default branch, with tests and docs alongside the behavior and a Conventional Commit message.
• The native review candidate is that commit, or the PR slice it belongs to when review is deferred, against the previous reviewed boundary. It is never a TODO checkbox and never the accumulated feature branch.
• The running authored line count from work-unit commits feeds the same delivery-strategy vocabulary as SDD: ask-on-risk, auto-chain, single-pr, exception-ok.
• The ODD feature document records the commit identity as evidence and, once a delivery strategy applies, the chosen chain strategy and slice boundaries (which commits each PR holds).

Commands

bashCopy code
# Review the story before committing
git diff --stat
git diff --cached --stat

# Check recent commit style
git log --oneline -5