菜单
Use when about to commit, merge, or push — runs verification (tests, typecheck, lint), confirms focus, and checks sibling hygiene (docs, tests, docstrings) BEFORE the commit lands, so "user said commit" doesn't bypass quality
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | gating-commits |
| description | Use when about to commit, merge, or push — runs verification (tests, typecheck, lint), confirms focus, and checks sibling hygiene (docs, tests, docstrings) BEFORE the commit lands, so "user said commit" doesn't bypass quality |
"User said commit" is not authorization to skip verification. The honest baseline from agents is: do git triage, draft a message, stage, commit — no test/typecheck/lint in between. This skill changes the default to verify first, commit second.
Core principle: A commit is a promise that what's in it works. Don't ship that promise on faith.
git commit for any reasonRun these BEFORE staging or committing. Stop at the first failure.
package.json, pyproject.toml, Makefile, .github/workflows/, or CLAUDE.md. Typical targets:
npm test, pytest, go test ./..., cargo testtsc --noEmit, mypy, pyrightnpm run lint, ruff check, golangci-lint runrepo-hygiene:keeping-docs-fresh run?repo-hygiene:testing-new-code run?repo-hygiene:writing-docstrings apply?git diff --stat HEAD. Are all changes related to the stated commit purpose? If unrelated changes snuck in, split them.git add .) and commit with a clear message.| Check | Sufficient evidence |
|---|---|
| Tests pass | Test command output: 0 failures, exit 0 |
| Types clean | Type-checker output: 0 errors |
| Lint clean | Linter output: 0 errors (warnings: use judgment) |
| Build succeeds | Build command exits 0 |
"Looks fine," "should pass," and "I'm confident" do not count.
Tell the user explicitly:
"I don't see test/lint/typecheck commands in this repo. I can commit as-is, or set up a minimal check first. Which do you want?"
Defer to the user. Silent skipping is the failure mode.
Fix foo when bar, not Fixed foo or Fixing foo)| Mistake | Fix |
|---|---|
| "User said commit" → commit | Authorization ≠ verification |
| Tests only, not types | Linter ≠ compiler ≠ test runner; check each |
git add . blanket stage | Stage specific files |
| "Tests failed but they're unrelated" | Either fix or split into a separate commit that flags the breakage |
| Giant diff, multiple unrelated changes | Split. One logical change per commit. |
| Skipping doc/test sibling checks | Re-read the trigger list above |
--no-verify to bypass pre-commit hooks | Investigate why the hook is firing; don't bypass |
git commit without fresh test/lint/typecheck output in context--no-verifyUse when the user asks to "clean up", "apply repo-hygiene to", or "fix the hygiene of" an existing codebase — orchestrates the other hygiene skills in a phased, reviewable order rather than firing a 200-file mega-diff
Use when changing a public API surface — renamed export, changed signature/return type, new or removed flag/route/env var, schema migration, deprecation — before committing, so README, docs/, CHANGELOG, and inline references stay coherent with the code
Use when about to add lines to an existing source file, when a single file passes ~400 lines, or when proposing where to put new code — prevents files from sprawling into multi-concern god-modules
Use when starting substantive work in an unfamiliar repo, before diving into task-specific grep or edits — especially when the task touches business logic, public API, build, or infra, or you don't yet know the repo's purpose, stack, conventions, or layout
Use when adding or modifying business logic, branching code, public API, or fixing a bug in a repo using repo-hygiene — tests for the new code paths must exist before the change is committed, not "later" or "if the user asks"
Use when starting any conversation in a repo — establishes the repo-hygiene skill set and the moments each sub-skill applies