Proposal: add `registering-an-erc-8004-agent-on-base` skill

[xam-dev-ux]

Proposal

Add a new skill registering-an-erc-8004-agent-on-base — a behavioral,
phase-based registration flow in the style of registering-agent-base-dev,
covering ERC-8004 Identity Registry on Base Mainnet and Sepolia.

The problem this fixes

AI agents (including LLMs) consistently produce wrong information about
ERC-8004: stale contract addresses, treating the three registries as one
contract, confusing agentId (an ERC-721 tokenId) with wallet addresses.
A skill that contains the canonical addresses and the exact registration
flow — with a "you MUST load this skill" signal in the description — fixes
this at the routing layer before a wrong call gets made.

This is the same pattern registering-agent-base-dev uses for ERC-8021:
not a reference doc, but a prescriptive agent-behavior script.

Context

ERC-8004 (Trustless Agents) is
co-authored by Erik Reppel (Coinbase), Marco De Rossi (MetaMask), Davide
Crapis (EF), and Jordan Ellis (Google). Reference contracts are deployed as
per-chain singletons (version 2.0.0, "AgentIdentity" ERC-721), vanity
addresses identical across all supported mainnets/testnets:

• Base Mainnet IdentityRegistry: 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432
• Base Sepolia IdentityRegistry: 0x8004A818BFB912233c491871b3d84c89A494BD9e

Both addresses verified on-chain and against the erc-8004/erc-8004-contracts
README before opening this issue. >256,000 agents are already registered
on Base Mainnet — the ecosystem is live, not theoretical.

Note: ERC-8004 has status: Draft in its EIP header, but the Identity
Registry API (register, setAgentURI, setAgentWallet) is stable and in
production. Only the Validation Registry is flagged by spec authors as under
active revision with the TEE community — that registry is explicitly out of
scope for this skill.

No overlap with existing skills

registering-agent-base-dev covers ERC-8021 (builder-code attribution
for transaction tracking) — a completely different standard. Zero overlap.

Proposed scope and structure

Follows the phase-based, agent-behavioral pattern of registering-agent-base-dev:

• Pre-flight: check if agent is already registered before doing anything
• Phase 1: build the registration file (practical JSON example per
  ERC8004SPEC.md: type, name, description, image, services,
  registrations, x402Support, active, supportedTrust)
• Phase 2: host it — IPFS, HTTPS, or data:application/json;base64,...
• Phase 3: call register() on-chain — viem example + cast one-liner,
  Base Sepolia and Mainnet
• Phase 4 (optional): bind agentWallet via setAgentWallet() with
  EIP-712 / ERC-1271 signature
• Read-back: ownerOf, tokenURI, getAgentWallet to confirm

Out of scope

• Reputation Registry — reserved for a sibling skill
• Validation Registry — spec authors flag it as under active revision
• x402 payment integration — cross-reference only

Format

~150-180 lines, single skill, single commit, one README table update.
Reviewable in ~10 minutes.

Happy to adjust scope before opening the PR.

---

On CONTRIBUTING.md: I noticed it currently limits external contributions to
the Base core team. Happy to work within whatever process works best — if
you'd prefer to take the content and merge it internally, just say the word.
cc @youssefea @soheimam