Agent Skills
› Gentleman-Programming/gentle-ai
› work-unit-commits
work-unit-commits
GitHub指导如何按可审查的工作单元规划代码提交,确保测试与文档随功能一同提交,维持清晰的提交历史并支持链式 PR。
Trigger Scenarios
实现新功能时的提交拆分
准备 PR 前的代码整理
将大变更转换为链式或堆叠 PR
Install
npx skills add Gentleman-Programming/gentle-ai --skill work-unit-commits -g -y
SKILL.md
Frontmatter
{
"name": "work-unit-commits",
"license": "Apache-2.0",
"metadata": {
"author": "gentleman-programming",
"version": "1.0"
},
"description": "Plan commits as reviewable work units. Trigger: implementation, commit splitting, chained PRs, or keeping tests and docs with code."
}
When to Use
Load this skill when deciding what belongs in each commit or PR.
Use it for:
- Splitting a feature into reviewable work.
- Preparing commits before opening a PR.
- Turning a large change into chained or stacked PRs.
- Keeping reviewer cognitive load healthy.
- Applying SDD tasks without accidentally producing a PR above 400 changed lines.
Critical Rules
| Rule | Requirement |
|---|---|
| Commit by work unit | A commit represents a deliverable behavior, fix, migration, or docs unit. |
| Do not commit by file type | Avoid models, then services, then tests if none works alone. |
| Keep tests with code | Tests belong in the same commit as the behavior they verify. |
| Keep docs with the user-visible change | Docs belong with the feature or workflow they explain. |
| Tell a story | A reviewer should understand why each commit exists from its diff and message. |
| Future PR-ready | Each commit should be a candidate chained PR when the change grows. |
| SDD workload guard | If SDD tasks forecast a >400-line change, group commits into chained PR slices before implementation. |
Work Unit Checklist
Before committing, confirm:
- The commit has one clear purpose.
- The repo still makes sense after applying only this commit.
- Tests or docs for this unit are included when relevant.
- Rollback is reasonable without reverting unrelated work.
- Focused test command and exact result are recorded.
- Runtime harness command/scenario and exact result are recorded, or explicit
N/Aexplains why no runtime boundary exists. - Rollback boundary names the exact files/behavior removable without unrelated work.
- The commit message explains the outcome, not the file list.
Split Examples
| Weak split | Better work-unit split |
|---|---|
add models |
feat(auth): add token validation domain model and tests |
add services |
feat(auth): wire token validation into login flow |
add tests |
Tests included with each behavior commit |
update docs |
Docs included with the user-facing change they explain |
PR Relationship
Use work-unit commits as the foundation for chained PRs:
- Build the smallest independent work unit.
- Include verification for that unit.
- Commit it with a Conventional Commit message.
- If the PR approaches 400 changed lines, promote commits or groups of commits into chained PRs.
ODD Relationship
Organic Driven Development (ODD) closes every substantial task with a work-unit commit on the feature branch:
- Every ODD task closes with at least one work-unit commit, branch first when on the default branch, with tests and docs alongside the behavior and a Conventional Commit message.
- The native review candidate is that commit, or the PR slice it belongs to when review is deferred, against the previous reviewed boundary. It is never a TODO checkbox and never the accumulated feature branch.
- The running authored line count from work-unit commits feeds the delivery-strategy vocabulary:
ask-on-risk,auto-chain,single-pr,exception-ok. - Count authored additions plus deletions for the
>400threshold. Exclude generated goldens from that authored count, but include every generated file in complete snapshot identity and receipt validation. - The ODD feature document records the commit identity as evidence and, once a delivery strategy applies, the chosen chain strategy and slice boundaries (which commits each PR holds).
Each ODD work unit should map cleanly to a commit or PR with:
- clear start state,
- clear finished state,
- verification in the same unit,
- rollback that does not remove unrelated work.
Its implementation evidence MUST include:
- Focused test command and exact result.
- Runtime harness command/scenario and exact result, or explicit
N/Awith reason. - Rollback boundary stated independently of commit creation; uncommitted work units still require it.
- When fixing a bounded review ledger, group atomic work units inside the single correction transaction; work-unit count never creates another fix budget.
Commands
# Review the story before committing
git diff --stat
git diff --cached --stat
# Check recent commit style
git log --oneline -5
Version History
- e8c9f59 Current 2026-09-28 01:18
- e01b114 2026-07-25 07:00


