Where to run it¶
Commit Check is one rule engine with several places to run it, and every one
of them reads the same cchk.toml. That is the point: the rules cannot drift
between what a developer sees locally and what is enforced on the pull request.
| Where | Catches problems | Can be bypassed | Set up |
|---|---|---|---|
| Pre-commit hook | As the message is written | Yes — --no-verify |
.pre-commit-config.yaml in each repository |
| GitHub Action | On every push and pull request, in CI | No | A workflow file in each repository |
| GitHub App | On every push and pull request, hosted | No | Install once for the organization |
| Command line | Wherever you call it: a range of commits, a CI you write yourself | — | pip install commit-check |
| MCP server | Before the commit exists, inside an AI coding agent | — | One entry in the agent's MCP config |
| Organization config | Everywhere at once | — | One shared cchk.toml, whichever of the above runs it |
Which one¶
- Every project wants a hook. It is the cheapest place to enforce commit policy: the developer finds out while they are still writing the message, not after a CI round trip.
- A policy needs a check that cannot be skipped. Anyone can pass
--no-verifyto a hook. The Action and the App run where that is not possible, and a required check keeps a violating change from merging. - More than a handful of repositories wants one config.
inherit_fromlets every repository share a base policy and override only what it genuinely needs, whichever of the above runs the checks.
App or Action?¶
| GitHub App | GitHub Action | |
|---|---|---|
| Setup | Install once for the organization | A workflow file in each repository |
| Runs on | GitHub.com | GitHub.com and GitHub Enterprise Server, any runner |
| Cost | No CI minutes | A runner per run; metered minutes on private repositories |
| Output | A check run per commit | Job summary, PR comment, result output |
| Fits | Organization-wide coverage with no per-repository work | Custom workflows, self-hosted runners, GHES |
Both read the same config and report the same rule IDs, so a team can run both: the App for coverage, the Action where a workflow needs the result.
How they combine¶
A hook gives fast feedback to people who want to follow the policy. The Action or the App is what makes it a policy. Most projects want both: the hook on every laptop, and one of the two on the pull request.
Pre-commit hook¶
Runs at commit-msg and pre-commit time on the developer's machine, fetched
by pre-commit itself, so there is nothing to install. Hooks can be skipped, by
design. Set it up →
GitHub Action¶
A workflow file in the repository, on any runner, GitHub Enterprise Server
included. Posts a job summary, can comment on the pull request, and exposes a
result output for the rest of the workflow. Set it up →
GitHub App¶
Hosted. Install it once on an organization and every repository, including ones created later, gets a Commit Check result on each commit of every push and pull request, with no workflow file and no CI minutes. Set it up →
MCP server¶
The same rules as tools for an AI coding agent, so the message is right before the commit exists. One entry in the agent's MCP settings. Set it up →
Across an organization¶
One cchk.toml in the organization's .github repository; each repository
inherits it with one line and overrides only what it must.
Set it up →