marmot-protocolmarmot-protocol/mdk/docs/AGENTS.md

mdk

AGENTS.md69 starsChanged 8 days agoMITView on GitHub

Docs guidance for agents. Use marmot-architecture/index.md as the entry point. The overview/ pages are the current orientation set. The further-context/ pages are deeper background and may contain older exploratory wording. The Marmot protocol specification lives in github.com/marmot-protocol/marmot. Use it for implementation-neutral Marmot protocol text. Keep repository and engine-specific notes in marmot-architecture/ or crate docs. required-features.md is the protocol boundary principles document. Treat it as a high-level constraint, not an implementation checklist. - Put plans in GitHub issues, not in docs/:…

Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,542 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- integrations/AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- blast-radiusSkill
- broSkill
- formal-verificationSkill
- land-changeSkill
- review-localSkill
- test-auditSkill
- verify-mdkSkill

The file

We split this AGENTS.md into the rules it gives an agent

12 rules. About 0 are common, 3 are distinctive, and 9 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
Use marmot-architecture/index.md as the entry point.
line 7
Very specific:
Put plans in GitHub issues, not in docs/: PR sequences, extraction briefs, roadmaps and step lists.
line 28
Very specific:
Update updated: dates in front matter when changing a dated architecture page.
line 32
Very specific:
Keep spec-like language in marmot-architecture/cgka-engine-spec.md, marmot-architecture/cgka-engine-canonicalization-contract.md, and …
line 33
Very specific:
Keep overview docs short. Move long rationale into further-context/.
line 35
Very specific:
When changing code behavior, update marmot-architecture/overview/current-state.md if the public status changed.
line 36
Very specific:
Keep observability guidance current in marmot-architecture/overview/observability.md when tracing/logging policy changes.
line 37
Very specific:
When a protocol rule graduates from exploratory architecture text, link to the matching document in github.com/marmot-protocol/marmot …
line 39
Very specific:
Follow ../release.md#release-documentation.
line 50
Distinctive:
Do not move release tags for documentation added after publication.
line 53
Distinctive:
Do not label lower-level APIs deprecated without actual source deprecation evidence.
line 55
Distinctive:
After doc changes, run:
line 59

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

AGENTS.md

AGENTS.md - docs

Docs guidance for agents.

Current docs

Use marmot-architecture/index.md as the entry point. The overview/ pages are the current orientation set. The further-context/ pages are deeper background and may contain older exploratory wording.

The Marmot protocol specification lives in github.com/marmot-protocol/marmot. Use it for implementation-neutral Marmot protocol text. Keep repository and engine-specific notes in marmot-architecture/ or crate docs.

required-features.md is the protocol boundary principles document. Treat it as a high-level constraint, not an implementation checklist.

Layout

marmot-architecture/ - architecture, contracts, and diagnostics; see marmot-architecture/AGENTS.md.
integration/ - versioned client integration guides (<version>.md), README.md index, and TEMPLATE.md.
release/ - concise per-version release notes plus wn-homebrew.md (Homebrew tap checklist).
quic-broker-deployment.md - marmot-quic-broker sidecar deployment.
external-signer-accounts.md - accounts whose Nostr key is held by a host external signer.
explorations-of-multi-device.md - exploratory, non-normative multi-device notes.
learnings.md - historical log kept for archaeology only; do not treat as current contract.

Editing rules

Put plans in GitHub issues, not in docs/: PR sequences, extraction briefs, roadmaps and step lists. A change that spans several PRs gets a tracking issue holding its plan and a checklist of its PRs. Docs describe how the system works and why it is shaped that way; when a planned change lands, update the docs that describe the result. The older *-plan.md pages predate this rule; do not start new ones.
Update updated: dates in front matter when changing a dated architecture page.
Keep spec-like language in marmot-architecture/cgka-engine-spec.md, marmot-architecture/cgka-engine-canonicalization-contract.md, and marmot-architecture/distributed-convergence.md.
Keep overview docs short. Move long rationale into further-context/.
When changing code behavior, update marmot-architecture/overview/current-state.md if the public status changed.
Keep observability guidance current in marmot-architecture/overview/observability.md when tracing/logging policy changes.
When a protocol rule graduates from exploratory architecture text, link to the matching document in github.com/marmot-protocol/marmot instead of copying the rule into multiple docs.

Client integration and release documentation

../crates/marmot-uniffi/README.md is the current client integration entry point; its method reference and the C symbol reference enumerate all exports. Versioned integration/<version>.md guides explain the exact upgrade delta, while release/<version>.md remains concise. Starting with 0.10.2, each release requires both, with reciprocal links and an entry in integration/README.md.

Follow ../release.md#release-documentation. Verify behavior against the named tags, separate required adoption from optional features and automatic fixes, include platform ownership/lifecycle examples and concrete validation, and state any remaining limitations. Do not move release tags for documentation added after publication; mark those guides as supplements and use a merged documentation commit URL when publishing release links. Do not label lower-level APIs deprecated without actual source deprecation evidence.

Verification

After doc changes, run:

rg -n \
  "TODO|TBD|open question|future SQLite|production storage|retry-deferred|AlreadyAtEpoch.*Peel" \
  docs \
  --glob '!AGENTS.md'

Review matches before deciding whether they are stale.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free