Skip to main content
Glama

RepoGrammar

Repository conventions for coding agents.

Documentation · Quickstart · Changelog · Contributing

RepoGrammar indexes repeated implementations in your repository and gives coding agents a source-backed read plan: examples of how this codebase implements a route, fixture, model, or data-access role, with the evidence behind each match. When the evidence is insufficient, it returns UNKNOWN with a recovery action.

It runs locally and exposes a pattern-first CLI and one read-only MCP tool. There are no LLM calls, API keys, embeddings, or cloud services in the analysis path. Python 3.10+ is required for the bundled Python analyzer.

Verified GitHub release baseline: 0.5.0. For current channel versions and their verification, see the publication evidence.

RepoGrammar indexing a temporary fixture repository

Recorded from a real CLI run on a fixture repository; playback is slowed for readability.

Quick start

Choose an installation route, then initialize your project → connect your agent → verify. Releases that include the one-command bootstrap can combine these steps.

Full Python project setup requires Python 3.10+ within 3.x, Git, Bash, curl, tar, and gzip. CLI-only installation does not require Python. Supported platforms are macOS arm64/x86_64, Linux x86_64 with glibc 2.35+, and Linux arm64 with glibc 2.39+. The native installer does not require Rust, Cargo, Node.js, Docker, or API keys. The npm launcher requires Node.js 18 or newer.

1. Install the CLI

Choose npm or the pinned native installer below; you do not need both.

npm

npm install -g @sioyooo/repogrammar &&
repogrammar version

The launcher downloads and verifies the matching native release on first use. It does not initialize a project or configure an agent. Continue with step 2. To pin a version, append @<version> to the package name; that version must have matching GitHub native assets.

Pinned native baseline: 0.5.0

This single block downloads the pinned installer, verifies its checksum, and installs the CLI. It does not alter coding-agent settings or index a repository. For an existing installation, review the update and PATH behavior before rerunning the installer.

(
set -eu
install_tmp="$(mktemp -d)" || exit 1
trap 'rm -rf "$install_tmp"' EXIT
cd "$install_tmp" || exit 1
curl -fsSLO https://github.com/SioYooo/RepoGrammar/releases/download/v0.5.0/install.sh || exit 1
curl -fsSLO https://github.com/SioYooo/RepoGrammar/releases/download/v0.5.0/install.sh.sha256 || exit 1
if command -v sha256sum >/dev/null 2>&1; then
  sha256sum -c install.sh.sha256 || exit 1
else
  shasum -a 256 -c install.sh.sha256 || exit 1
fi
bash install.sh --version v0.5.0 --install-cli-only --yes
) &&
export PATH="$HOME/.local/bin:$PATH" &&
repogrammar version

Add the export PATH line to ~/.zshrc or ~/.bashrc once to keep the command available in new terminals. Expected version: 0.5.0.

2. Index your project

From your project's directory:

repogrammar init

init builds the current project's index and starts background updates. There is no global repository scanner. Run init once in each project. The explicit form repogrammar init --project "$PWD" --yes does the same thing; use --no-autosync for CI or a one-shot index.

3. Connect your coding agent (optional)

repogrammar install --target auto --scope global --yes --no-telemetry

Restart the coding-agent session after connecting. Choose a specific client with --target codex, --target claude-code, or --target opencode.

4. Verify setup

From the initialized project:

command -v repogrammar
repogrammar version
repogrammar status

Check that the version and command path match the installation you chose. If the index is unavailable or stale, run repogrammar doctor and follow its recovery guidance. After restarting your agent, confirm that repogrammar_context is available in its MCP tools. Installing the CLI alone does not establish a working agent session.

One-command bootstrap

The 0.5.1 source includes --quickstart: review one plan, authorize it, then install the CLI, connect detected supported agents, index the selected Git repository, and start repository-local autosync. No agent is required for CLI/index setup. After a successful quickstart, go straight to Verify setup; the separate install, init and agent-connection steps are already handled.

Use an installer and matching binary that include the quickstart-v1 capability; the pinned 0.5.0 baseline above does not. The quickstart guide records availability, verified commands, plan preview, noninteractive execution and agent selection. The publication checklist records the artifact and installation gates for this flow.

I want to…

Guide

Install, update, or troubleshoot

Quickstart

Connect Codex

Codex setup

Connect Claude Code

Claude Code setup

Connect opencode

opencode setup

See every command

Run repogrammar help --all or read the CLI reference

Understand evidence and limits

Limitations

Remove the installation

Uninstall guide

Related MCP server: TokenLighten

When should I index again?

Situation

Action

First time in a project

repogrammar init

Normal edits while autosync is running

Nothing; updates run in the background

Autosync is stopped, or you want an immediate update

repogrammar sync

You need a full rebuild, or recovery guidance requests one

repogrammar resync

You are unsure whether the index is ready

repogrammar status; use repogrammar doctor for recovery

index remains available for compatibility. Use init to start, sync for ordinary changes, and resync to rebuild. Do not repeatedly run init after normal edits.

Usage

Find examples for an exact repository location:

repogrammar find "path/to/routes.py:7" --project "$PWD" --mode compact
repogrammar families --project "$PWD"
repogrammar sync --project "$PWD"

Start with an exact path or symbol when available. Framework-qualified queries such as FastAPI route are also supported. See the CLI reference for the complete commands and the MCP contract for coding-agent integration.

Background updates

init starts a daemon for that repository. On macOS and Linux, native file notifications coalesce edits before a sync. Idle native operation reconciles metadata periodically instead of rescanning the tree every second. Git-ignored untracked directories are pruned before fingerprint traversal, while tracked files and ignore exceptions remain visible.

If native watching fails, autosync logs the fallback and polls with bounded idle backoff. Failed syncs retry with bounded backoff even without another edit. File notifications are hints; explicit sync and query-time hashes remain the freshness authority. These changes reduce background work; no battery-life percentage is claimed.

repogrammar autosync status --project "$PWD"
repogrammar autosync stop --project "$PWD"
repogrammar autosync start --project "$PWD"

For CI or one-shot analysis, initialize with --no-autosync. See the autosync contract for intervals and recovery.

How it works

repository → local index → pattern families → examples + bounded read plan
                                └──────────→ UNKNOWN + recovery action
  • Repository conventions: find compatible implementations and their exceptions.

  • Verifiable context: every result carries provenance and freshness checks.

  • Incremental updates: native filesystem events wake autosync; changes use the existing incremental indexer. Periodic reconciliation and polling fallback handle unavailable watchers.

  • Agent integration: connect Codex, Claude Code, or opencode through MCP.

How does it differ from other code tools?

Tool or mechanism

What it contributes

Where RepoGrammar fits

grep / text search

Exact strings and source locations

Qualifies repeated implementation-family context and the source reads still required

Semantic search / RAG

Retrieves material relevant to a query; a generation layer may use it

Provides a bounded local evidence contract, without embeddings or generation in its analysis path

CodeGraph / symbol graphs

Declarations, references, and call paths

Complements graph navigation with family selection, provenance, and abstention

Static analyzers

Checks under a tool's specified semantic model

Reports bounded convention evidence and static alignment; it is not a sound whole-program analyzer

These are mechanism comparisons, not benchmark or superiority claims. Static alignment is not proof of runtime equivalence. The FastAPI/pytest fixture walkthrough shows a read plan, optional source spans, and negative cases you can reproduce.

What do UNKNOWN and a bounded read plan mean?

UNKNOWN means the requested claim lacks sufficient qualifying evidence. Its typed reason and recovery action tell the agent what remains unresolved; it does not mean the repository is incorrect. PARTIAL_CONTEXT can provide local metadata without selecting a proven family. A bounded read plan names a limited set of source locations and remaining reading obligations. Read the required source before editing; the plan does not replace that obligation. See the MCP contract and UNKNOWN policy.

Does repository code leave my machine?

RepoGrammar's analysis runs locally and makes no LLM, embedding, or cloud calls. MCP responses contain metadata by default; source spans require explicit opt-in. The coding agent receiving that response has its own data-handling policy and may send metadata or requested source to its provider. Local analysis is not a privacy guarantee for the entire agent session. Anonymous telemetry is off by default and excludes source and paths; explicit upload is separate. See the telemetry contract for local diagnostics and consent boundaries.

Scope and limitations

The official language focus is Python: FastAPI, pytest, Pydantic, and SQLAlchemy. Other languages have bounded structural or dependency-inventory capabilities; these are not full language support. The strict Top-20 qualification program remains 0/20 complete. Read the language audit for the evidence and unresolved gates.

RepoGrammar is pre-1.0. It is not a sound whole-program analyzer, and neither a syntax match nor a dependency declaration proves behavior. Dynamic dispatch, unsupported frameworks, stale indexes, and incomplete semantics can result in abstention. Read known limitations before relying on a result.

Public binary targets are macOS arm64/x86_64 and glibc Linux arm64/x86_64. Windows and musl Linux are not supported installation targets.

Use ordinary source inspection when a repository has few repeated patterns, your framework is outside the bounded scope, or an answer remains UNKNOWN. Use runtime tests or a suitable semantic analyzer when the question requires behavioral correctness, security assurance, or whole-program proof.

Development

cargo build --locked
cargo test --workspace --all-features

Read CONTRIBUTING.md and the testing policy for the full checks. Architecture and specifications live in docs/. Report bugs through GitHub Issues; report security issues according to SECURITY.md.

License

MIT.

Available Tools

1 tool
repogrammar_contextA

Read-only RepoGrammar pattern-family context. For find_analogues, explain_deviation, and check_conformance, pass the path, symbol/member id, framework role, or pattern question you have; RepoGrammar discovers candidate families internally and returns family ids as follow-up handles. Use show_family only with an exact family id. Use inspect_readiness (no target) for a bounded, source-free capability report: a summary token, per-dimension states (repository, active index, family evidence freshness, prevalence, retrieval, static alignment, providers, autosync, measurement), the top blocking-unknown mechanisms, and one executable recovery action. Add an optional target and/or within (a directory/module scope) to inspect_readiness for a bounded, source-free SCOPED queryability report over just that scope: a summary token, a resolvability verdict, scoped indexing coverage and file count, languages/providers present, resolvable family count, freshness, and one recovery action — with no source-span hydration and no family-query telemetry. Start with compact mode and do not request include_source_spans by default. Use read_plan before editing, and fall back on UNKNOWN/FALLBACK/stale/omitted/insufficient results. Do not run repogrammar stats in normal agent loops. No silent setup; run setup/resync/autosync only when user or project policy permits machine integration and repo-local analysis state.

NameRequiredDescriptionDefault
modeNo
targetNo
withinNoOptional directory/module scope. Consumed only by inspect_readiness to request a bounded, source-free scoped queryability report over that scope.
againstNoOptional comparison-family scope for explain_deviation and check_conformance: an exact family: id, framework role, or pattern that pins the single comparison family. Omitted, the comparison family is inferred from the target unit's membership or its (language, kind, role) key. Ambiguous or unmatched against abstains with candidate handles; it never false-selects.
operationYes
verbosityNoResponse field density. Additive under product-schemas.v1: `standard` (default) is the current shape, `minimal` opts into the lean shape, `full` retains every diagnostic field. Orthogonal to `mode`.
token_budgetNo
include_exceptionsNo
include_variationsNo
include_source_spansNoExplicit opt-in for bounded, line-numbered, hash-checked source spans selected from the read_plan. Defaults to false.

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations the description carries the full burden, and it discloses a lot: read-only nature, source-free behavior ('no source-span hydration and no family-query telemetry'), abstention semantics ('never false-selects', 'abstains with candidate handles'), fallback handling (UNKNOWN/FALLBACK/stale), and a setup/policy constraint ('run setup/resync/autosync only when user or project policy permits'). It omits latency/rate-limit or cost characteristics and only sketches the response envelope, but behavioral disclosure is well above average.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a long single block, but front-loaded with purpose and operation routing, and the size is defensible given five operations and ten parameters. Most sentences carry distinct operational content; the only drag is that inspect_readiness detail sits mid-paragraph before the generic defaults, slightly disrupting flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a ten-parameter, five-operation tool with no output schema, the description covers operation behavior and several return shapes (family ids as handles, summary token, per-dimension states, one recovery action), which is genuinely useful. But it leaves verbosity, token_budget, include_exceptions, and include_variations unaddressed and gives only partial guidance on how the modes interact with the responses, so it is not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 40%, so the description must compensate. It adds real meaning for mode ('Start with compact mode'), target, and within (scoped queryability report), and echoes the abstention behavior of against. However, token_budget, include_exceptions, include_variations, and verbosity are never explained in the description, leaving several parameters documented only by terse schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb+resource ('Read-only RepoGrammar pattern-family context') and the body enumerates the five operations (find_analogues, show_family, explain_deviation, check_conformance, inspect_readiness) with what each returns. An agent can distinguish the operations, though the dense prose makes the overall scope harder to grasp at a glance than a crisp statement would.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing per operation ('For find_analogues, explain_deviation, and check_conformance, pass...', 'Use show_family only with an exact family id', 'Use inspect_readiness (no target) for...'), plus defaults and exclusions ('Start with compact mode', 'do not request include_source_spans by default', 'Do not run repogrammar stats in normal agent loops', 'No silent setup'). When-to-use and when-not are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.5.1
    • First observedrepogrammar_context

TDQS

A3.7/5.0

Scored across 1 tool

Disambiguation3/5

With only one exposed tool there is no cross-tool selection risk, but that single tool internally multiplexes several distinct operations (find_analogues, explain_deviation, check_conformance, show_family, inspect_readiness, read_plan), and the boundary between them is only conveyed through a very dense prose description. An agent must parse a long block to know which mode to invoke and when, which is effectively ambiguity pushed inside one tool.

Naming Consistency4/5

The single name repogrammar_context is readable and uses a consistent snake_case prefix_noun convention. There is no pattern to violate with only one tool, but the namespace-prefixed form is coherent and predictable for any future additions.

Tool Count2/5

One tool for a surface that describes at least six distinct operations (pattern-family discovery, deviation explanation, conformance checks, family display, readiness/scoped-readiness inspection, change planning) plus setup/resync/autosync behavior is under-factored. The mega-tool approach forces mode dispatch and hidden branching, making the count too thin for the apparent scope.

Completeness3/5

The read-only analysis domain is partially covered: discovery, explanation, conformance, readiness, and planning are all reachable, and source-hydration is intentionally gated. However setup/resync/autosync are referenced only as behaviors of the same tool rather than distinct operations, and there is no explicit enumeration or listing of family ids beyond follow-up handles, leaving lifecycle steps implicit.

Maintenance

ActivityActive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    D
    quality
    D
    maintenance
    Read-only repository context explorer for coding agents. Provides repository exploration tools via CLI or MCP adapter.
    1
    GPL 3.0
  • A
    license
    Not graded
    quality
    B
    maintenance
    A local, read-only MCP server that provides AI coding agents with structural evidence about a repository, including dependency analysis and impact assessment, while naming the boundary of every answer without any LLM calls.
    21 npm
    Apache 2.0
  • A
    license
    B
    quality
    A
    maintenance
    Enables coding agents to retrieve token-budgeted, source-hashed code context from explicitly registered local repositories via read-only MCP tools, reducing broad repository crawling while providing structure, symbols, and impact slices.
    10
    MIT