libxmtp
AGENTS.md127 starsChanged 11 days agoMITView on GitHub
Rust MLS workspace; platform SDKs live in sdks/. - Read the relevant specs via docs/specs/README.md. Approved specs win over code, plans, and XIPs. For reviews, read REVIEW.md. - Read AGENTS.md files along the path you change. Keep shared rules in the nearest common parent, local constraints here, and detailed procedures in linked docs. Update instructions when commands change. CLAUDE.md is only @AGENTS.md. - Use .agents/skills/writing-typescript for TypeScript and JavaScript work. - For agent instruction changes, use the writing-agent-docs skill. -…
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,439 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 repository21 other files it gives its agents.
- docs/AGENTS.mdAGENTS.md
- .github/workflows/AGENTS.mdAGENTS.md
- nix/AGENTS.mdAGENTS.md
- proto/AGENTS.mdAGENTS.md
- sdks/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/workflows/CLAUDE.mdCLAUDE.md
- nix/CLAUDE.mdCLAUDE.md
- proto/CLAUDE.mdCLAUDE.md
- sdks/CLAUDE.mdCLAUDE.md
- authoring-specsSkill
- check-ciSkill
- checking-spec-complianceSkill
- reviewing-specsSkill
- smoke-checkSkill
- working-with-nixSkill
- working-with-worktreesSkill
- writing-agent-docsSkill
- writing-rustSkill
- writing-rust-testsSkill
- writing-typescriptSkill
The file
We split this AGENTS.md into the rules it gives an agent
12 rules. About 0 are common, 4 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 5
Read the relevant specs via docs/specs/README.md.
- Very specific: line 7
Read AGENTS.md files along the path you change.
- Very specific: line 10
Use .agents/skills/writing-typescript for TypeScript and JavaScript work.
- Distinctive: line 16
Keep it draft, or return it to draft, while known implementation or validation work needing commits remains, including work resumed for …
- Distinctive: line 21
Default to constants; a configuration knob needs a caller requiring a different value.
- Distinctive: line 22
Before expanding scope to handle a speculative or extremely unlikely race or security edge case, describe how it could fail, how likely it …
- Very specific: line 28
Run from the repository root through dev/nix-shell.
- Very specific: line 43
Default members are apps/backend, apps/db_tools, and crates/*.
- Very specific: line 44
Start just backend up through Nix before workspace tests.
- Very specific: line 46
Use just backend status for worktree addresses, never assume main-checkout ports.
- Very specific: line 47
Read .agents/skills/working-with-worktrees when creating or using another worktree.
- Very specific: line 49
Before broad source reads, use just outline <path>.
≈ “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.
Files
libxmtp
Rust MLS workspace; platform SDKs live in sdks/.
- Read the relevant specs via docs/specs/README.md. Approved specs win over code, plans, and XIPs. For reviews, read REVIEW.md.
- Read
AGENTS.mdfiles along the path you change. Keep shared rules in the nearest common parent, local constraints here, and detailed procedures in linked docs. Update instructions when commands change.CLAUDE.mdis only@AGENTS.md. - Use
.agents/skills/writing-typescriptfor TypeScript and JavaScript work. - For agent instruction changes, use the writing-agent-docs skill.
- Branch from
origin/main; targetmain. - Open every agent-created PR as a draft, even if the initial changes appear complete. Mark it ready in a later step only when the scoped work and local validation are complete and no agent or helper is editing, preparing, or pushing further commits. Keep it draft, or return it to draft, while known implementation or validation work needing commits remains, including work resumed for later review feedback.
- Spec requirement changes need an approved Ref plan before implementation;
routine docs, CI, and tooling changes do not. Required plans describe public
sdks/*type changes; update the plan if new surface emerges. - Default to constants; a configuration knob needs a caller requiring a different value.
- Before expanding scope to handle a speculative or extremely unlikely race or security edge case, describe how it could fail, how likely it is, and the added complexity. Get the user's agreement before implementing that extra complexity.
Commands
Run from the repository root through dev/nix-shell; never run cargo, pnpm,
./gradlew, or swift outside Nix. Prefer Just recipes. For Cargo options without
one, use dev/nix-shell 'dev/agent-run cargo <command> ...'.
For shell diagnostics and runtime maintenance, read Nix guidance.
dev/nix-shell 'just' # discover recipes
dev/nix-shell 'just check crate <name>'
dev/nix-shell 'just test crate <name>'
dev/nix-shell 'just test workspace -p <name> <args>' # nextest filters/options
dev/nix-shell 'just lint'
dev/nix-shell 'just version check' # SDK and CLI mirrors
dev/nix-shell 'just version set <version>' # shared Cargo targetDefault members are apps/backend, apps/db_tools, and crates/*; other apps need explicit checks.
Start just backend up through Nix before workspace tests; client tests need its
node, not only the databases. Backend database tests use just backend test.
Use just backend status for worktree addresses, never assume main-checkout ports.
Read .agents/skills/working-with-worktrees when creating or using another worktree.
Before broad source reads, use just outline <path>; for a known symbol use
just show <file> <name> (both through Nix). Fall back to rg for missed symbols;
use Serena for Rust references/types. See agent tools for
setup and output recovery (XMTP_RTK=0).
For CI results, use just ci-status <pr> / just ci-failures <job> through Nix
and .agents/skills/check-ci, never raw log fetches.
Tests
- Rust tests use
#[xmtp_common::test(unwrap_try = true)]; dependency-cycle exceptions are documented locally. - Prove every new test fails: break the behavior or restore the weaker implementation, run it and observe failure, then restore the code and pass.
- Tooling/CI checks and service troubleshooting: dev/README.md.
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
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.

