CtrlK
BlogDocsLog inGet started
Tessl Logo

work-unit-commits

Plan commits as reviewable work units. Trigger: implementation, commit splitting, chained PRs, or keeping tests and docs with code.

62

Quality

72%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./internal/assets/skills/work-unit-commits/SKILL.md
SKILL.md
Quality
Evals
Security

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

RuleRequirement
Commit by work unitA commit represents a deliverable behavior, fix, migration, or docs unit.
Do not commit by file typeAvoid models, then services, then tests if none works alone.
Keep tests with codeTests belong in the same commit as the behavior they verify.
Keep docs with the user-visible changeDocs belong with the feature or workflow they explain.
Tell a storyA reviewer should understand why each commit exists from its diff and message.
Future PR-readyEach commit should be a candidate chained PR when the change grows.
SDD workload guardIf 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.
  • The commit message explains the outcome, not the file list.

Split Examples

Weak splitBetter work-unit split
add modelsfeat(auth): add token validation domain model and tests
add servicesfeat(auth): wire token validation into login flow
add testsTests included with each behavior commit
update docsDocs included with the user-facing change they explain

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.

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.

Commands

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

# Check recent commit style
git log --oneline -5
Repository
sergiodvillegas-art/gentle-ai
Last updated
Created

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.