Skip to main content

repo-standards

repo-standards measures pull-request review size without executing repository code. Its repository rules are available for review but remain disabled until individually approved and explicitly activated by a consumer.

Where rules belong

  • Exact tracked-tree facts—filenames, placement, topology, migrations, pull-request size, ownership, delivery/GitHub state, and repository-wide API/document sets—belong here.
  • Source and configuration semantics for Python, TypeScript, SQL, Terraform/HCL, Markdown, YAML, JSON, and shell belong in sarj-ai/code-standards.
  • If a path alone is sufficient to produce the finding, use Repo Standards. If source content is necessary, use Code Standards.

After a rule is approved, activate its stable ID in .repo-standards/repository.toml:

enabled_rules = ["repository/artifacts/bespoke-iac-verifiers"]

The locked Repo Standards release supplies the current reviewed implementation. Manifests never select historical rule versions; --enable-rule <rule-id>@<version> remains available only for legacy manifests and calibration runs.

Run it

Use the current release without installing it:

uvx --from repo-standards repo-standards pull-request size . --base origin/main

For a persistent user installation:

uv tool install repo-standards
repo-standards pull-request size . --base origin/main

Upgrade with uv tool upgrade repo-standards. Automation should pin the package version or the GitHub Action's full commit SHA.

Pull-request commit policy

pull-request commits is strict by default and defaults to five non-merge pull-request commits. A pull request above that limit passes only when every commit subject begins with the complete, exact ASCII series (1/N) through (N/N) , unless a trusted transition exemption is verified. Indices must be unique, totals must match the actual commit count, and zero-padded or partial markers do not pass.

Authoritative GitHub CI must fetch complete history and pass the event payload as a file. Repo Standards reads the exact direct PR base/head objects, refs, and numeric repository identities; it never uses the synthetic merge commit in GITHUB_SHA. Exit status 1 means the history violates policy; 2 means required evidence was incomplete.

repo-standards pull-request commits . --github-event "$GITHUB_EVENT_PATH"

Local hooks use checked-in configuration and remain deliberately advisory because history may be shallow or stale and pre-commit runs before the pending commit exists. --quiet suppresses only a completed pass; findings and incomplete analysis remain visible. pre-push closes the normal one-commit feedback lag, while exact CI remains authoritative.

repo-standards pull-request commits . --advisory --quiet

When a series is not intentional, prefer one reviewable commit:

git rebase -i "$(git merge-base origin/dev HEAD)"

Configure local base discovery, commit-message enforcement, and narrowly scoped promotion/synchronization transitions in schema 6. Strict CI reads this TOML from the exact PR base commit, so a PR cannot raise its own limit or grant itself an exemption. Each transition also requires the exact destination, a same-repository PR, an immutable source-SHA branch suffix equal to the PR head, and proof that the head remains in the configured source ancestry. Protect automation branch namespaces so only the promotion app can create or update them.

schema_version = 6

[commit_message]
enforcement = "strict" # default in schema 6; use "observe" only for measured migrations

[pull_request.commit_history]
advisory_base_ref = "dev"
# maximum_commits = 5

[[pull_request.commit_history.transitions]]
id = "dev-preview"
source_ref = "dev"
base_ref = "preview"
head_prefix = "automation/promote-dev-"
# sha_prefix_length = 12

Repeat an explicit table for every trusted edge. Repo Standards rejects ambiguous prefixes, unsafe refs, duplicate IDs, and more than 64 transitions. Missing configuration keeps the strict five-commit default and grants no transition exemptions. Existing explicit evidence and JSON transition flags remain supported for non-GitHub providers and migration from 5.9.

Stacked PRs are evaluated against each PR's direct base, never the whole stack base. The composite Action reports merge_group as explicitly not applicable because a merge-queue commit aggregates already-evaluated PRs; keep the containing required workflow enabled for merge_group so GitHub still receives its required status. The explicit edited activity ensures retargeting always re-evaluates the new exact base.

Commit-message policy

Schema 6 enables Managed Conventional Header v1 by default. It checks only the first physical line; bodies, trailers, punctuation, prose, and language remain untouched. Valid headers use [(i/N) ][TICKET] type(scope)!: description, where the numbering and ticket prefixes and scope are optional. Types are the fixed Conventional Commits set: build, chore, ci, docs, feat, fix, perf, refactor, revert, style, and test.

The commit-msg hook safely repairs only unambiguous type casing and structural whitespace. It never guesses intent or rewrites prose. Semantic findings fail with a short actionable diagnostic, so a developer or coding agent can update the message and retry.

repo-standards commit-message .git/COMMIT_EDITMSG --fix-safe

Authoritative PR CI validates every direct base-to-head non-merge commit using the policy from the exact base object. A cryptographically attested promotion or synchronization transition bypasses inherited legacy messages; branch names, actors, bots, and forks never grant an exemption.

Pull-request commits Action and pre-commit hook

After a full-history checkout, use the dedicated Action inside an existing required job. Pin the release to its complete immutable commit SHA.

on:
  pull_request:
    types: [opened, synchronize, reopened, edited]
  merge_group:
    types: [checks_requested]

- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
  with:
    fetch-depth: 0
    persist-credentials: false
- uses: sarj-ai/repo-standards/pull-request-commits@FULL_RELEASE_COMMIT_SHA # v5.11.0

The published repo-standards-pull-request-commits hook runs in advisory mode at pre-commit and pre-push. The repo-standards-commit-message hook runs at commit-msg, applies bounded safe normalization, and then enforces the header. Consumers that already lock Repo Standards may invoke the same commands from their existing hook manager to avoid a duplicate environment.

GitHub Action

The Action measures size only. It enables no repository lint rules and needs no inputs on a pull_request event.

name: Pull-request size

on:
  pull_request:

permissions:
  contents: read

jobs:
  size:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
        with:
          fetch-depth: 0
          persist-credentials: false
      - uses: sarj-ai/repo-standards@bb839628f620be1a6e6c67eea6b5b12ba750e13e # v5.11.1

The Action emits counted, excluded, and total line counts plus canonical JSON. Tests are recognized across Python, JavaScript/TypeScript, Go, JVM, Android, Xcode/Swift, .NET, Ruby, and Bats conventions. Mark generated or machine-owned artifacts in the trusted base revision:

path/to/generated/** pr-size-excluded

Thresholds, labels, comments, and approval requirements remain consumer policy. Use pull_request, never pull_request_target; this metric is not a security gate.

Safety model

  • Repository contents come from one exact Git tree.
  • Workflow YAML and API descriptions are parsed as inert data.
  • Missing required evidence produces an inconclusive result rather than a false pass.
  • Advisory commit-history analysis reports incomplete evidence without blocking local commits.
  • The linter has no autofix or repository mutation mode.

Development

uv sync --locked
uv run pytest
uv run ruff check .
uv run basedpyright
uvx --no-config --isolated --python 3.14 \
  --from sarj-standards-bootstrap==2.0.0 \
  code-standards check --trust-repository-code

Build the same wheel and source distribution used by publishing:

uv build --no-sources

Releases are reconcilable. The protected workflow independently repairs a missing PyPI publication or GitHub Release from the same verified source revision.

Release files for repo-standards 5.11.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for repo-standards 5.11.1
File Size Uploaded
repo_standards-5.11.1.tar.gz 114.3 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for repo-standards 5.11.1
File Interpreter ABI Platform
repo_standards-5.11.1-py3-none-any.whl Python 3 none any Details

Total release size: 247.1 kB

Release files / repo_standards-5.11.1.tar.gz

Download URL repo_standards-5.11.1.tar.gz
Size 114.3 kB
Tags Source
SHA-256 checksum
How to use checksums
79b6fe64280af250bce8a7931e83df1f11195ba403ddf01a592d468da3d8cc85
BLAKE2b-256 checksum
How to use checksums
d1265c23fc148e40a22b103e8c99429c50a5ff3697b307365e0400aa92a3e3f4
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 4, 2026.

Transparency log

Release files / repo_standards-5.11.1-py3-none-any.whl

Download URL repo_standards-5.11.1-py3-none-any.whl
Size 132.8 kB
Tags Python 3
SHA-256 checksum
How to use checksums
e4bb123fae3ac180b1ae61b3b6031e914c686ee820f8271ac2460b50403c3335
BLAKE2b-256 checksum
How to use checksums
47cd1dd379e659b3375fe4bebab4120aef4aea2a3e46d414b68062e2f6350d91
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 4, 2026.

Transparency log

Release history Release notifications | RSS feed

6.1.2

2 release files

6.1.1

2 release files

6.1.0

2 release files

6.0.1

2 release files

6.0.0

2 release files

5.17.0

2 release files

5.16.8

2 release files

5.16.7

2 release files

5.16.6

2 release files

5.16.5

2 release files

5.16.4

2 release files

5.16.3

2 release files

5.16.2

2 release files

5.16.1

2 release files

5.16.0

2 release files

5.15.0

2 release files

5.14.1

2 release files

5.14.0

2 release files

5.13.2

2 release files

5.13.1

2 release files

5.13.0

2 release files

5.12.0

2 release files

This release

5.11.1 This release

2 release files

5.9.0

2 release files

5.8.0

2 release files

5.7.0

2 release files

5.6.1

2 release files

5.6.0

2 release files

5.5.3

2 release files

5.5.2

2 release files

5.5.1

2 release files

5.5.0

2 release files

5.4.1

2 release files

5.4.0

2 release files

5.3.1

2 release files

5.3.0

2 release files

5.2.1

2 release files

5.2.0

2 release files

5.1.0

2 release files

5.0.1

2 release files

5.0.0

2 release files

4.0.2

2 release files

4.0.1

2 release files

4.0.0

2 release files

3.0.2

2 release files

3.0.1

2 release files

3.0.0

2 release files

2.0.0

2 release files

1.0.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page