committee — one set of git conventions, for people and agents alike

What it actually changes

Every change to a codebase is saved with a one-line note saying what it was. Those notes are how anyone later works out when something broke, what shipped in a release, and whether a version is safe to upgrade to.

BeforeA week of history

update
fix
WIP
more changes
fix again
final

Six notes, no information. Nobody can tell which of these fixed the login bug, and a release note can only be written by reading every change by hand.

AfterThe same week

feat(auth): add password reset
fix(api): reject empty queries
docs: explain the retry policy
test(auth): cover expired tokens
fix(ui): keep focus after submit
refactor: split the parser

The first word says what kind of change it was, the bracket says where. Release notes, and the next version number, can now be worked out mechanically — nobody has to read the code to find out what happened.

Why it takes two layers

You could just write the rules down, or just add an automatic checker. Each one alone leaves a hole the other covers.

1

Teach the rules

A Claude Code Skill and an AGENTS.md explain the conventions to the agent — including why a given change is a fix rather than a feature. That judgment is the part no automatic checker can make.

2

Enforce the rules

Git hooks and a CI workflow reject a malformed commit or branch before it lands — whoever wrote it, person or agent. This part does not rely on anyone remembering, or complying.

Neither half is decoration. Written rules alone get followed most of the time, and "most" is not something you can put in a changelog. A checker alone only sees shape: label a bug fix as a new feature and it passes every rule, while quietly telling everyone downstream the wrong thing about what changed.

One file decides everything

The allowed commit types, branch prefixes and review labels live in a single file. Nothing else restates them, so there is no second list to keep in sync and no way for your machine and the pipeline to disagree.

.claude/git-conventions.yaml
        │
        ├──► the Skill           what Claude Code is told
        ├──► AGENTS.md           what Codex and others are told
        ├──► commitlint.config.js   the commit message check
        └──► .githooks/pre-push     the branch name check

Install

The target has to exist already and be a git repository.

Run the installer
```
git clone https://github.com/otomamaYuY/committee.git /tmp/committee
/tmp/committee/install.sh /path/to/your/repo
```
Your files are never overwritten — anything already there is listed as skipped. A repo that already routes its hooks elsewhere is detected rather than hijacked. Re-run it later and the kit refreshes only what it owns: the Skill, and the marked region of your AGENTS.md.
Install the dependencies
```
cd /path/to/your/repo
npm install   # or pnpm install / yarn install
```
This is what activates the hooks. Node 22.12 or newer.
Check the one script your teammates need

The hooks are switched on by a prepare script in package.json. If your repo already had one, the installer tells you to add that line yourself — skip it and the hooks run for exactly one person on the team, silently.

Full instructions Why it is shaped this way