work-unit-commits

Plan git commits as reviewable work units with tests and docs included.

Updated Jun 5, 2026
One-click install
npx skills add https://github.com/zMynxx/bifrost-with-opencode --skill work-unit-commits-zmynxx
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: work-unit-commits
Source: https://github.com/zMynxx/bifrost-with-opencode/tree/main/.opencode/skills/work-unit-commits
Command: npx skills add https://github.com/zMynxx/bifrost-with-opencode --skill work-unit-commits-zmynxx

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 hard to review. This Skill guides you to split work into self-contained commits where each one delivers a behavior, includes its tests and docs, and stays reviewable. ## Core Features & Use Cases - Work-Unit Commit Rules: Enforces committing by deliverable behavior rather than by file type, keeping tests and docs in the same commit as the change they verify. - Commit Checklist: Provides a pre-commit checklist covering single purpose, repo coherence, rollback safety, and outcome-focused commit messages. - Chained PR Planning: Maps work units to chained or stacked PRs when a change approaches 400 changed lines, integrating with SDD Review Workload Forecasts. - Use Case: You finished a large authentication feature. Use this Skill to split it into commits like "feat(auth): add token validation domain model and tests" and "feat(auth): wire token validation into login flow", then group them into chained PRs. ## Quick Start Ask the AI to review your current uncommitted changes and propose a split into work-unit commits with Conventional Commit messages.

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 smaller commits?▼

Split by work unit, not by 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, and write a message describing the outcome rather than the file list.

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

Commit by work unit and monitor changed lines before opening the PR. When the forecast exceeds 400 lines, promote commits or groups of commits into chained PRs, where each PR is the smallest independent, verified work unit.

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 makes rollback remove verification independently from the code it covers.

What is a chained or stacked PR workflow?▼

A chained PR workflow builds the smallest independent work unit first, verifies and commits it, then stacks dependent units as follow-up PRs. Each commit remains a candidate chained PR, so large changes stay reviewable without one oversized pull request.

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 coherent and support rollback without reverting unrelated work.