work-unit-commits

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

Updated Aug 25, 2026
One-click install
npx skills add https://github.com/CarlosWilliamsR/SketchOS --skill work-unit-commits-carloswilliamsr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: work-unit-commits
Source: https://github.com/CarlosWilliamsR/SketchOS/tree/main/.config/opencode/skills/work-unit-commits
Command: npx skills add https://github.com/CarlosWilliamsR/SketchOS --skill work-unit-commits-carloswilliamsr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large changes often become monolithic commits or PRs that reviewers cannot reasonably evaluate, and splitting by file type produces commits that do not work independently. This Skill structures commits around deliverable work units so each commit tells a coherent story and stays reviewable. ## Core Features & Use Cases - Work-Unit Commit Rules: Enforces committing by behavior or fix rather than by file type, keeping tests and docs in the same commit as the code they cover. - Review Workload Guard: Applies a 400-changed-line threshold to decide when commits should be promoted into chained or stacked PRs. - SDD Integration: Maps SDD task forecasts and delivery strategies (ask-on-risk, auto-chain, size:exception) to commit and PR slicing decisions. - Use Case: While implementing a multi-part authentication feature, split the work into commits like "add token validation domain model and tests" and "wire token validation into login flow", then group them into chained PRs once the change approaches 400 lines. ## Quick Start Ask the assistant to plan the commits for your current feature as reviewable work units before you open a pull request.

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 rather than file type: each commit should deliver one behavior, fix, migration, or docs unit that works on its own. Include the tests and docs for that unit in the same commit so reviewers understand the change from its diff and message.

When should I turn commits into chained or stacked PRs?

Promote commits into chained PRs when the total change approaches 400 changed lines, counting authored additions plus deletions. Build the smallest independent work unit first, verify it, then group commits into PR slices that each remain reviewable.

Should tests go in the same commit as the code they test?

Yes, tests belong in the same commit as the behavior they verify. Committing tests separately produces commits that do not work independently and breaks the story a reviewer reads from the diff.

What is the 400-line rule for pull requests?

The rule counts authored additions plus deletions and treats anything over 400 lines as too large for a single reviewable PR. Generated goldens are excluded from the authored count but still included in snapshot identity and receipt validation.

What evidence should a work unit include before committing?

Record the focused test command and its exact result, plus the runtime harness command or scenario and its result, or an explicit N/A with a reason. Also state the rollback boundary naming the exact files or behavior removable without touching unrelated work.