agentleFS
xmtpxmtp/libxmtp/AGENTS.md

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. -…

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
  1. Distinctive:

    Read the relevant specs via docs/specs/README.md.

    line 5
  2. Very specific:

    Read AGENTS.md files along the path you change.

    line 7
  3. Very specific:

    Use .agents/skills/writing-typescript for TypeScript and JavaScript work.

    line 10
  4. Distinctive:

    Keep it draft, or return it to draft, while known implementation or validation work needing commits remains, including work resumed for …

    line 16
  5. Distinctive:

    Default to constants; a configuration knob needs a caller requiring a different value.

    line 21
  6. Distinctive:

    Before expanding scope to handle a speculative or extremely unlikely race or security edge case, describe how it could fail, how likely it …

    line 22
  7. Very specific:

    Run from the repository root through dev/nix-shell.

    line 28
  8. Very specific:

    Default members are apps/backend, apps/db_tools, and crates/*.

    line 43
  9. Very specific:

    Start just backend up through Nix before workspace tests.

    line 44
  10. Very specific:

    Use just backend status for worktree addresses, never assume main-checkout ports.

    line 46
  11. Very specific:

    Read .agents/skills/working-with-worktrees when creating or using another worktree.

    line 47
  12. Very specific:

    Before broad source reads, use just outline <path>.

    line 49

≈ “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

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.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.
  • Branch from origin/main; target main.
  • 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 target

Default 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.

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.