work-unit-commits

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

Updated Jul 10, 2026
One-click install
npx skills add https://github.com/AD-Paladins/beaconator-web --skill work-unit-commits-ad-paladins
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: work-unit-commits
Source: https://github.com/AD-Paladins/beaconator-web/tree/main/.config/opencode/skills/work-unit-commits
Command: npx skills add https://github.com/AD-Paladins/beaconator-web --skill work-unit-commits-ad-paladins

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 are too big to review. This Skill guides you to split work into self-contained commits that tell a story and stay under reviewable size limits. ## Core Features & Use Cases - Work Unit Commit Rules: Each commit represents one deliverable behavior, fix, migration, or docs unit, with tests and docs kept alongside the code they verify. - Chained PR Planning: When a change approaches 400 changed lines, commits are grouped into chained or stacked PR slices following SDD delivery strategies. - Verification Checklist: Every unit records a focused test command with exact result, a runtime harness scenario or explicit N/A, and a rollback boundary naming removable files. - Use Case: While implementing a multi-task feature, use this Skill to decide what belongs in each commit so a reviewer understands why each change exists and any single commit can be rolled back without touching unrelated work. ## Quick Start Ask the assistant to split the current uncommitted changes into reviewable work-unit commits with tests included and a rollback boundary for each.

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, not by file type: each commit should deliver one behavior, fix, migration, or docs unit that makes sense on its own. Include the tests and docs for that unit in the same commit so the reviewer understands why it exists.

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

Build the smallest independent work unit first, verify it, and commit it with a Conventional Commit message. When the change approaches 400 authored additions plus deletions, promote commits or groups of commits into chained PRs.

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 produces commits that do not work alone and breaks the story a reviewer reads from the diff.

What is a chained or stacked PR workflow?▼

A chained PR workflow turns a large change into a sequence of small dependent PRs, each built from work-unit commits. Each PR is independently reviewable and mergeable, keeping reviewer cognitive load low.

When should I not split a change into multiple commits?▼

Avoid splitting when the resulting commits cannot stand alone, such as separating models, services, and tests that only work together. A commit must leave the repository in a sensible state and allow rollback without reverting unrelated work.