work-unit-commits

Structure commits as reviewable work units for PR readiness.

2|Updated Jul 29, 2025

Search Tags:#git #code review #documentation #test strategy #pull requests #release workflow #commit splitting

Ready to run

npx skills add https://github.com/kurojs/EnderDots --skill work-unit-commits

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: work-unit-commits
Source: https://github.com/kurojs/EnderDots/tree/main/.config/opencode/skills/work-unit-commits
Command: npx skills add https://github.com/kurojs/EnderDots --skill work-unit-commits

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you avoid confusing pull requests by ensuring each commit represents a single, reviewer-friendly unit of deliverable work.

Core Features & Use Cases

Commit by work unit: Write commits that correspond to deliverable behavior, fixes, migrations, or user-relevant documentation.
Keep related changes together: Include tests with the code they verify and include docs with the user-visible change they explain.
Enable safe PR slicing: Structure commits so they can be chained or stacked into PRs, especially when changes risk becoming too large for review.

Quick Start

Load the work-unit-commits Skill before you commit, then confirm your change is one clear purpose with the right tests and docs included for that same unit.

Frequently Asked Questions about work-unit-commits

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

FAQPage Schema

How do I structure git commits to make pull requests easier to review?▼

Group changes by behavior rather than file type to create reviewable work units. Each commit should represent a single deliverable, keeping related tests and documentation aligned with the specific behavior they cover to reduce PR confusion.

What is the best way to split a large git commit for a stacked PR workflow?▼

The best way to split large git commits for stacked PRs is enforcing a future PR-ready slicing strategy. Organize commits as chained work units matching deliverable behaviors, allowing safe PR slicing when changes risk becoming too large for review.

Should I include tests and user documentation in the same commit as the code?▼

Keep tests and user documentation in the same commit as the code. Grouping related changes together ensures tests verify the code they cover and docs explain the user-visible change within that exact work unit.

Why does grouping commits by file type cause pull request confusion?▼

Grouping commits by file type causes pull request confusion because it separates related behaviors across multiple commits. Reviewers struggle when tests, docs, and implementation are detached, unlike grouping by deliverable work unit.

When do I need to use a one-commit-per-deliverable workflow?▼

Use a one-commit-per-deliverable workflow when changes risk becoming too large for review or when chaining stacked PRs. This storytelling approach ensures commits match reviewer expectations and enable safe PR slicing.