work-unit-commits

Plans git commits as reviewable work units with tests, docs, and rollback boundaries.

Updated Mar 7, 2026
One-click install
npx skills add https://github.com/albersg/dotfiles --skill work-unit-commits-albersg
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: work-unit-commits
Source: https://github.com/albersg/dotfiles/tree/main/dotfiles-opencode/.opencode/skills/work-unit-commits
Command: npx skills add https://github.com/albersg/dotfiles --skill work-unit-commits-albersg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large changes often get committed by file type (models, then services, then tests), producing commits that do not work alone and PRs that exceed reviewer capacity. This Skill structures commits as self-contained work units so each change is reviewable, verifiable, and rollback-safe. ## Core Features & Use Cases - Work-Unit Commit Rules: Enforces committing by deliverable behavior rather than file type, keeping tests and docs in the same commit as the code they cover. - Chained PR Planning: Splits large features into stacked PRs when changes approach the 400-line review threshold, aligned with SDD delivery strategies. - Verification Checklist: Requires focused test results, runtime harness evidence, and explicit rollback boundaries for every commit. - Use Case: When implementing a multi-part feature like token-based authentication, split it into commits such as "add token validation domain model and tests" and "wire token validation into login flow", each independently reviewable and revertible. ## Quick Start Ask the AI to split the current uncommitted changes into reviewable work-unit commits with tests and rollback boundaries included.

Frequently Asked Questions about work-unit-commits

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I split a large feature into reviewable commits?▼

Split by work unit: each commit should deliver one behavior, fix, migration, or docs change that works on its own. Include the tests and docs for that unit in the same commit, and write a message explaining the outcome rather than the file list.

How to keep pull requests under 400 lines of changes?▼

Group work-unit commits into chained or stacked PRs when the forecast exceeds 400 authored lines. Build the smallest independent unit first, verify it, then promote groups of commits into separate PRs that chain together.

Should tests go in the same commit as the code?▼

Yes, tests belong in the same commit as the behavior they verify. Committing tests separately leaves intermediate commits that do not work alone and breaks rollback safety.

What is a chained or stacked PR workflow?▼

A chained PR workflow splits a large change into a sequence of small PRs where each builds on the previous one. Each PR is an independent work unit with its own verification, keeping reviewer cognitive load manageable.

When should I not split commits by file type?▼

Avoid splitting into commits like "add models", "add services", then "add tests" when none of them works alone. Instead, commit by deliverable behavior so the repository still makes sense after applying only that commit.