dotrepo

DotRepo

Repository facts you can trace and reuse.

Every new investigation starts with familiar questions: what does this project do, where are its docs, who maintains it, and how is it built? DotRepo provides an open repository metadata protocol, tools and a public index for those facts. Read them as JSON, through MCP, or from a local .repo file, with their sources, recorded conflicts and age attached.

Publishers derive context from the manifests, CI and documentation they already maintain. Consumers use a shared starting point, then inspect sources when the answer is missing, stale, conflicting or insufficient. The goal is less repeated work for both sides, including the work of keeping metadata useful.

[Look up a repository](#try-it-orient-yourself-in-pydantic) · [Connect an agent](#connect-your-agent) · [Publish from existing sources](#add-a-record-to-your-repository)

Experimental: DotRepo's decision workflow extends this into metadata-led discovery, bounded shortlisting, source-backed requirement assessment and retained findings (MCP tools dotrepo.decision.*). Its experimental source workflow can reach a justified preliminary choice or an explicit unknown; it is not in released packages or the hosted API. Start with delivery status and evidence, then the durable source command or the MCP decision guide.

Together with PageDigest, this is part of Lazy Collective: conservation through cooperation, reducing repeated fetching, parsing, investigation and verification. Its public home connects the two projects; there is no shared deployed service. How the projects relate.

Try it: orient yourself in pydantic

Fetch the indexed profile without installing anything or cloning the repository:

curl -sS https://dotrepo.org/v0/repos/github.com/pydantic/pydantic/profile.json

The response groups purpose, execution, documentation, and ownership. Check record.generatedAt, record.freshnessStatus, conflicts, and the fields your task needs. freshness.generatedAt dates the export, not the source facts. A missing, old, or conflicting answer needs an upstream check. Returned commands are data to review, not permission to execute them.

Connect your agent

Install the stable MCP server with a Rust toolchain, or use the stable release bundle:

cargo install dotrepo-mcp --version 1.0.4 --locked

For clients that use an mcpServers configuration:

{

"mcpServers": { "dotrepo": { "command": "dotrepo-mcp", "args": [] } } }

Ask the client to call dotrepo.lookup with these arguments:

{

"repositoryUrl": "https://github.com/pydantic/pydantic", "path": "repo.test" }

See installation for the CLI, LSP, and VS Code extension, and consumer integration for fallback rules and a runnable client.

Version matters: production installs use stable v1.0.4. The published v2.0.0-rc.2 preview includes retained field assessments, execution contexts, newer MCP target checks, and the contained CLI/MCP output writer. Additional instruction-extraction and evaluation work in this checkout is recorded under Unreleased in the changelog; it is outside that published tag. Installed RC1 artifacts remain unchanged. Use the version comparison and stable documentation.

What you can use it for

• Repository orientation: get purpose, docs, owners, and reported commands before deciding what source files to inspect
• Agent integrations: make a first lookup, retain trust and age, then fall back to upstream when the answer does not meet your task's needs
• Maintainer metadata: keep a native .repo file and supported documentation blocks consistent with validation and generated-surface checks
• Repository discovery: search, compare factual profiles, and traverse repository relationships through the public API

Indexed overlays are generated from public source material, so maintainers do not need to adopt dotrepo for their repository to appear. A native .repo provides maintainer control. Routine generated records are machine-checked: their best status is checked (automated checks passed), not human review.

Add a record to your repository

Install the stable CLI from the release bundle or with cargo install dotrepo-cli --version 1.0.4 --locked, then:

# Start from existing README.md, CODEOWNERS, and SECURITY.md:

dotrepo --root import

Review the generated .repo, then:

dotrepo --root validate dotrepo --root query repo.build --raw dotrepo --root trust dotrepo --root generate --check

Use init instead of import to start from a blank scaffold. The stable maintainer guide walks through adoption; sync boundaries explain which files and regions dotrepo can manage.

For a source checkout, the publisher helper reviews existing manifests/docs through the importer, reports genuine ambiguity, and checks adopted-record drift without overwriting it. Its initial adoption mode creates a record only when none exists; no second catalog is required.

Limits and evidence

• Metadata supports orientation. Architecture research, suitability decisions, debugging, and code changes still require source inspection
• Coverage, correctness, completeness, and freshness are separate. Records can be incomplete, stale, or wrong even when marked checked; retained field-level evidence is available only where the producing version and crawl saved it. See the trust model
• The measurement page reports field presence and modeled requests. Those are not accuracy or measured end-to-end agent savings
• The head-to-head benchmark keeps wins and losses against a GitHub API + README baseline. Fixing its examples is regression evidence, not proof of generalization. Its frozen upstream source excerpts keep their own licenses, not this repository's MIT license; see third-party notices
• Sustained independent consumer adoption remains an open success criterion. In-repository clients and AI interviews do not establish external demand

Read next

• Documentation map and release compatibility
• Toolchain and protocol reference, including MCP tools, validation scope, and version boundaries
• Hosted API examples, public architecture, and own-project study and later pilot
• Trust model and authority rules
• Roadmap, contributing, and index operations

For implementation, start with the roadmap packets and team execution guide. Repository guidance owns contracts; generated reports and dated archives own outcome evidence.

Repository Python tooling uses uv; CONTRIBUTING owns setup commands and the checks for each change.