commit-review
Skill1 starsChanged 2 months agoMITView on GitHub
Review working-tree and staged scope, validation evidence, sensitive files, unrelated changes, commit grouping, and readiness before an authorized commit. Use when the user asks for commit preparation, staged-diff review, commit splitting, or messages. Do not use to implement fixes or automatically stage, commit, amend, push, merge, reset, rebase, squash, or clean.
In this repository9 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- architecture-auditSkill
- cxpSkill
- docs-updateSkill
- safe-refactorSkill
- session-handoffSkill
- task-briefSkill
- cxpSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 15
Use when commit readiness, staged scope, file grouping, exact staging paths, or commit messages are requested.
- Distinctive: line 20
Do not use as a general code-review substitute, implementation workflow, or authorization to mutate Git state.
- Distinctive: line 36
Check for sensitive files and likely secret locations without printing values.
- Distinctive: line 41
Check the staged diff with git diff --cached --check.
- Distinctive: line 55
Never stage, commit, amend, push, merge, reset, restore, discard, rebase, squash, clean, delete, or drop stashes through this skill.
- Distinctive: line 57
Never use or recommend git add .
- Distinctive: line 58
Never print secret values or claim a check passed without evidence.
- Distinctive: line 59
Treat readiness as a review result, not authorization.
- Distinctive: line 64
Verify the proposed groups against both staged and unstaged state.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Commit Review
Purpose
Decide whether the current change is ready for one or more reviewable commits and present an exact, non-mutating commit plan.
Trigger
Use when commit readiness, staged scope, file grouping, exact staging paths, or commit messages are requested.
Do not trigger
Do not use as a general code-review substitute, implementation workflow, or authorization to mutate Git state. Do not invoke automatically at ordinary task completion unless commit preparation was requested.
Inputs
- User-approved task scope and intended commit boundaries.
- Current branch, status, staged diff, and unstaged diff.
- Validation results and required manual checks.
- Known sensitive, generated, protected, or unrelated paths.
Workflow
- Inspect the branch, complete status, staged diff, unstaged diff, and relevant base-branch scope.
- Group files or hunks by coherent purpose and identify unrelated content.
- Check for sensitive files and likely secret locations without printing values.
- Compare claimed validation with commands actually run and report gaps.
- Classify P1/P2 blockers and P3 optional findings consistently with
AGENTS.md. - Check the staged diff with
git diff --cached --check; if nothing is staged, say so and keep the review read-only. - Recommend exact
git add -- <paths>commands, commit order, and imperative messages only after the split is clear. - State readiness and request explicit authorization before any commit action.
Outputs
Return the assessment using the commit review format, including files that must remain uncommitted.
Safety
- Never stage, commit, amend, push, merge, reset, restore, discard, rebase, squash, clean, delete, or drop stashes through this skill.
- Never use or recommend
git add .orgit add ... - Never print secret values or claim a check passed without evidence.
- Treat readiness as a review result, not authorization.
- Re-plan if approved files, ordering, or messages change.
Validation
- Verify the proposed groups against both staged and unstaged state.
- Require
git diff --cached --checkand a complete staged review before an authorized commit. - Report unrun, failed, or inapplicable checks separately.
- Confirm that the plan contains only intended files and one purpose per commit.
References
AGENTS.md— authoritative Git and validation rules.docs/agents/README.md— tooling ownership.- Commit review format — required output.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

