A wallet for agents. Make payments via x402, us... AGENTS.md

This AGENTS.md scopes itself to one subtree of a larger repository — the .openclaw/ directory holding an extension that bridges OpenClaw to a Python wallet backend. It is a useful counterexample to the usual whole-repo agent file: the first line declares the boundary, and everything after it is about keeping a thin TypeScript layer thin.

The architectural rule it exists to defend is that the TypeScript extension is a transport, not an authority. Wallet policy, approvals, signing rules, and chain-specific behaviour stay in Python; the extension resolves config, locates the Python package, shells out to its CLI, registers the tools with OpenClaw, and passes JSON in and out. Left unstated, that boundary is exactly the kind of thing an agent erodes one convenient reimplementation at a time — so the file states it three separate ways, and names the files that must move together whenever a schema changes.

How the file is organised

• Scope and Purpose — what the instructions cover and what lives in the tree.
• Current structure — a file-by-file map of the extension: entrypoint, plugin manifest, package metadata, and the wallet-operator skill.
• Design intent — the thin-bridge principle, spelled out as a list of the extension's jobs.
• Working rules — three subsections: keep bridge logic thin, keep schemas synchronised, and the security rules; plus the expectations for how the Python package root gets resolved.
• Editing guidance and Validation — how to make small changes safely, and which smoke tests to run afterwards.
• Common change patterns — numbered recipes for the three recurring edits: changing tool registration, changing plugin config, and changing wallet policy.

What is worth borrowing

Two ideas stand out. First, the "keep schemas synchronised" section lists the exact sibling files that must change together for each kind of edit — a cross-language contract written down where the agent will actually read it, instead of living in a maintainer's head. Second, the security rules are phrased as things never to add rather than things to remember: no secrets through plugin config, no policy decisions in TypeScript, no turning the extension into a key store. Prohibitions survive refactors better than reminders do.