work-unit-commits

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

Updated May 24, 2026
One-click install
npx skills add https://github.com/etrigan16/v0-cipher-ar --skill work-unit-commits-etrigan16
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: work-unit-commits
Source: https://github.com/etrigan16/v0-cipher-ar/tree/main/.opencode/skills/work-unit-commits
Command: npx skills add https://github.com/etrigan16/v0-cipher-ar --skill work-unit-commits-etrigan16

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large features often become monolithic commits or PRs that reviewers cannot reasonably evaluate, and splitting work by file type produces commits that do not function independently. This Skill provides rules and checklists for splitting implementation work into coherent, reviewable commits and chained PRs. ## Core Features & Use Cases - Work Unit Commit Rules: Enforces committing by deliverable behavior rather than by file type, keeping tests and docs alongside the code they verify. - PR Size Guardrails: 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, use this Skill to split the work into commits like domain model plus tests, then login flow wiring, each independently reviewable and rollback-safe. ## Quick Start Ask the assistant to plan the commits for your current feature as reviewable work units before you start writing code.

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 behavior in the same commit so reviewers can verify it independently.

When should I use chained or stacked PRs instead of one PR?▼

Use chained PRs when the change approaches 400 changed lines of authored additions plus deletions. Build the smallest independent work unit first, verify it, then promote groups of commits into chained PR slices.

Should tests go in a separate commit from the code?▼

No. Tests belong in the same commit as the behavior they verify, and docs belong with the user-visible change they explain. Separate test or docs commits create units that cannot be reviewed or rolled back independently.

What evidence should each commit include before opening a PR?▼

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 unrelated work.

How does the 400-line limit count generated files?▼

Count authored additions plus deletions toward the 400-line threshold. Generated goldens are excluded from the authored count but must still be included in the complete snapshot identity and receipt validation.