RepoCanon
Generate repo-specific AI context for Codex, Claude Code, Copilot, and Cursor.
Turn any repository into canonical AI-readable project context.
RepoCanon is a Python CLI that analyzes a local codebase and generates project-specific instruction files for AI coding tools from a single internal repo model.
Instead of manually maintaining separate context for different tools, RepoCanon infers your repo’s structure, commands, conventions, and boundaries, then generates outputs such as:
AGENTS.mdCLAUDE.md- Copilot repository instructions
- Cursor project rules
The goal is simple: make AI coding tools behave like they already understand your repo.
Why RepoCanon
AI coding tools are useful, but they usually guess:
- where things live
- how the repo is structured
- which commands to run
- what patterns are preferred
- what boundaries should not be crossed
RepoCanon reduces that guesswork by turning repo-specific knowledge into maintainable instruction files.
What it does
RepoCanon:
- analyzes a local repository
- detects languages, frameworks, commands, and topology
- infers conventions and architectural boundaries
- builds a normalized project model
- generates tool-specific AI context files from that model
RepoCanon is deterministic-first. It does not require an LLM to work.
Supported targets
- Codex via
AGENTS.md - Claude Code via
CLAUDE.md - GitHub Copilot via
.github/copilot-instructions.md(and optional path-scoped files) - Cursor via
.cursor/rules/*.mdc
Installation
pip install repocanon
Requires Python 3.11+.
Quickstart
# 1. Analyze the current repo and persist a normalized model.
repocanon analyze .
# 2. Inspect what was inferred and how confident RepoCanon is.
repocanon audit .
# 3. Preview generated outputs without touching the filesystem.
repocanon preview .
# 4. Write the generated files into the repo (defaults to all targets).
repocanon generate .
You can also generate one or more specific targets:
repocanon generate . -t agents
repocanon generate . -t claude -t copilot
repocanon list-targets # see what's available
Need machine-readable output? Append --json to analyze, audit, or diff.
Need to undo? repocanon clean . (or scope it with -t copilot) removes only
RepoCanon-authored files (those that carry the generator header marker).
Example outputs
A real run produces files like:
AGENTS.md
CLAUDE.md
.cursor/rules/project-overview.mdc
.cursor/rules/commands-and-validation.mdc
.cursor/rules/code-style-and-conventions.mdc
.cursor/rules/architecture-boundaries.mdc
.github/copilot-instructions.md
.github/instructions/tests.instructions.md
See docs/samples/ for sample generated files from the bundled fixture repos.
How it works
RepoCanon has three layers:
1. Repo analysis
It scans the local repo and extracts:
- languages
- frameworks
- package managers
- commands
- configs
- directory structure
- file patterns
2. Convention inference
It infers patterns such as:
- test layout (centralized vs colocated)
- frontend/backend split
- monorepo structure (apps/packages/libs/services)
- architectural boundaries
- naming conventions
- preferred libraries
- common anti-pattern risks (e.g. editing existing migrations)
3. Target generation
It maps one normalized project model into tool-specific outputs.
That means the same repo understanding can be reused across multiple AI coding tools.
Design principles
- deterministic first
- local-first (no telemetry, no network calls)
- tool-agnostic core
- small, readable outputs
- no generic filler — every section is grounded in repo facts
- explicit uncertainty when confidence is low
- human-editable generated files (sections between
<!-- repocanon:manual:* -->markers survive regeneration)
Commands
repocanon analyze [PATH]
Analyze the repository and write a normalized model to:
.repocanon/project-model.json
repocanon generate [PATH]
Generate output for the selected targets (defaults to all).
Useful flags:
-t, --target— repeat to pick targets (agents,claude,copilot,cursor, orall)--dry-run— render and report without writing or persisting the model--output-dir— write into a sibling directory (path-traversal-safe)--force— replace files even if RepoCanon would otherwise preserve manual edits
repocanon preview [PATH]
Print generated output to the terminal without writing files. Same -t flag as generate.
repocanon list-targets
List every target the current build supports.
repocanon clean [PATH]
Delete RepoCanon-authored files for the selected targets. Files without the
RepoCanon header marker (i.e. anything you wrote yourself) are skipped. Pair
with --dry-run to see what would happen.
repocanon audit [PATH]
Show inferred conventions, rationale, and confidence levels. Pass --json to
emit the audit as JSON for piping into other tools.
repocanon diff [PATH]
Compare the current repo scan with the saved model and report meaningful changes
(specific commands added/removed, package list deltas, structural fingerprint
changes). Pass --json for a machine-readable diff.
repocanon init [PATH]
Create a local RepoCanon config file at .repocanon/config.toml.
Configuration
RepoCanon stores project config in:
.repocanon/config.toml
Example:
[project]
name = "my-repo"
[scan]
include = ["src/**", "app/**", "packages/**"]
exclude = ["node_modules/**", ".next/**", "dist/**", "build/**"]
[generate]
targets = ["agents", "claude", "copilot", "cursor"]
safe_overwrite = true
Architecture overview
repocanon/
├── analyzer/ # deterministic repo scanning + inference
├── models/ # Pydantic v2 project model
├── generators/ # one module per AI target
├── output/ # writers, preview, diff
├── report/ # audit + summary tables
└── cli.py # Typer entry point
The analyzer is a straight pipeline: file inventory → manifest parsing → framework/package-manager detection → command extraction → topology + conventions → final ProjectModel. Generators only consume that model — they never touch the filesystem.
Limitations
RepoCanon is inference-based. It can detect a lot, but not everything.
It may be less accurate when:
- the repo is highly unconventional
- conventions are implicit rather than visible in files
- commands live outside standard manifests
- architecture is unclear from structure alone
When confidence is low, RepoCanon says so rather than inventing detail.
Roadmap
- more framework detectors (Django, Rails, .NET, Spring, etc.)
- stronger monorepo inference (Bazel, Pants, Nx graph)
- better path-scoped output generation
- safer merge/update behavior for edited generated files
- optional LLM-assisted summarization (off by default)
- additional target formats
Why not just write these files manually?
You can. But in practice:
- they drift out of date
- they are inconsistent across tools
- they are often generic
- they rarely reflect the actual repo structure
RepoCanon keeps those files grounded in the codebase.
How RepoCanon maps one repo model to multiple AI coding tools
RepoCanon is intentionally a many-to-one-to-many pipeline:
repo files ─┐ ┌─► AGENTS.md (Codex)
├─► analyzer ─► ProjectModel ──┼─► CLAUDE.md (Claude Code)
manifests ─┘ ├─► copilot-instructions (Copilot)
└─► .cursor/rules/*.mdc (Cursor)
The analyzer collapses everything it sees into a single normalized ProjectModel (Pydantic v2). That model is the only thing target generators read; they never touch the filesystem. This gives RepoCanon two important properties:
- One source of truth. Languages, frameworks, commands, conventions, anti-patterns, and architecture boundaries all live in one place. Adding a new target means writing a new generator that consumes the same model — not re-implementing detection.
- Idiomatic outputs per tool. Each generator picks the parts of the model that make sense for its target and renders them in that tool's idiom: a verbose AGENTS.md for Codex, a terse CLAUDE.md for Claude Code, a repo-wide instructions file (plus optional path-scoped ones) for Copilot, and a small set of focused
.mdcrule files for Cursor.
The same model also powers audit, diff, and preview, so you can verify what RepoCanon inferred before any file is written.
Contributing
Contributions are welcome. See CONTRIBUTING.md for local setup, tests, and development workflow.
License
MIT
Metadata
Release files for repocanon 0.2.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| repocanon-0.2.1.tar.gz | 57.3 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| repocanon-0.2.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 123.9 kB
Release files / repocanon-0.2.1.tar.gz
| Download URL | repocanon-0.2.1.tar.gz |
|---|---|
| Size | 57.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
8b84f91a381f882c34d731a796d4339badf32bf17ee7ffb65118ee5ad2e77eba
|
|
BLAKE2b-256 checksum How to use checksums |
a495bd37b7e7776fd26f28af3207ae05d380f1a0a936020a27135ec5fffd3193
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
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 May 9, 2026.
Transparency logRelease files / repocanon-0.2.1-py3-none-any.whl
| Download URL | repocanon-0.2.1-py3-none-any.whl |
|---|---|
| Size | 66.6 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
9fe53c9f4c8b50fbe03f4fe46401e179038016b45e03c6ec2fb3a2b4c12e9dc1
|
|
BLAKE2b-256 checksum How to use checksums |
ccf6bcc44a345f18b20e86a97cfa375eea31f64f3467dab17b0d080821b4ab69
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
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 May 9, 2026.
Transparency log