Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions AGENTS.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,39 @@ This file provides working guidelines for AI coding agents (e.g., GitHub Copilot

- All changes must be submitted to the `main` branch **via a pull request**. Never push commits directly to `main`.

## Keep the README pinned to the released version

**Do this on every change, whatever you came here to do.** It is not a release-time task — the README's pre-commit snippets are the first thing a new user copies,
and a stale pin is invisible: the snippet keeps working, it just installs an older release than the README describes.

1. **Find the latest released version.**

```bash
curl -s https://pypi.org/pypi/commit-check/json | python -c "import json,sys; print(json.load(sys.stdin)['info']['version'])"
```

The [releases page](https://github.com/commit-check/commit-check/releases) answers the same question, provided you read only **published** releases.
A draft is not one, and you cannot tell by looking for a tag: a draft can be saved against a tag that already exists, and publishing to PyPI is
a separate step from publishing the GitHub release. Read the published release, or ask PyPI as above.

Both have to be true before a version can be pinned: the **tag** must exist, because that is what pre-commit resolves `rev:` against,
and **PyPI** must have the version, because that is what installs.

2. **Check every pin in the README.**

```bash
grep -n "rev: v" README.md
```

Each one must name that version. Update any that do not, in the same pull request — do not open a follow-up issue for it.

3. **Say so in the pull request description** when you moved them, so the bump is not a silent diff in an unrelated change.

The one exception is a pull request that prepares an unpublished release: there the pins are written **ahead** of the tag, on purpose, and the release is published before the pull request merges.

`.pre-commit-config.yaml` is a different case and is **not** covered by this rule. That pin is this repository running its own hooks,
and pre-commit resolves it against real tags when CI runs — so pointing it at a version that is not published yet breaks the build. Bump it only after the release exists.

## Git Rules

- **Follow the Conventional Branch spec** for branch names: `<type>/<description>` with lowercase kebab-case descriptions. Allowed types: `feature/`, `bugfix/`, `hotfix/`, `release/`, `chore/`. Example: `chore/add-agent-guidelines`.
Expand Down
6 changes: 3 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,7 @@ commit-check --message --branch
```yaml
repos:
- repo: https://github.com/commit-check/commit-check
rev: v2.12.2
rev: v2.15.0
Comment thread
coderabbitai[bot] marked this conversation as resolved.
hooks:
- id: check-message
- id: check-branch
Expand Down Expand Up @@ -196,7 +196,7 @@ commit-check --message
# In pre-commit hooks (.pre-commit-config.yaml)
repos:
- repo: https://github.com/commit-check/commit-check
rev: v2.12.2
rev: v2.15.0
hooks:
- id: check-message
args:
Expand Down Expand Up @@ -226,7 +226,7 @@ commit-check --no-force-push
# In pre-commit hooks (.pre-commit-config.yaml)
repos:
- repo: https://github.com/commit-check/commit-check
rev: v2.12.2
rev: v2.15.0
hooks:
- id: check-no-force-push
stages: [pre-push]
Expand Down