Internet Court Skill: an open skill for agent-to-agent contracts

The gap Internet Court Skill targets: deals that fall off the happy path

Agent-to-agent commerce has working pieces. Identity and reputation registries, negotiation protocols, delegated permissions, payment rails and escrow contracts all exist as separate standards, and the README describes each of them as solving one layer while assuming everything goes right. The failure mode it names is specific: when a deal goes wrong, every layer passes the problem down the line, and no layer owns the settlement of the disagreement.

Internet Court Skill is aimed at that last step. The README states that when two agents make a deal they also agree up front how it will be settled if something goes wrong, and that this choice is written into the contract itself. The audience is therefore narrow and technical: teams building agents that hold funds, delegate permissions and transact with other agents, and who need a structure for the case where the counterparty does not deliver. A developer writing a single agent that calls an API has no use for this.

What the repository actually contains: one router, connectors, and vendored protocol skills

The architecture is a packaging decision, not a runtime. The repository layout lists four things: SKILL.md as the master skill that routes to everything else, integrations/ for the Internet Court connector and adapter skills, vendored/ for committed copies of official protocol skills, and skills-lock.json for the pinned source, hash and refresh command of each vendored skill. The README counts 91 skills across 33 owners in vendored/.

The README draws a line between first-party and vendored content. Only the master skill and the connectors are written by this project; the README states that the repo never re-implements a protocol's own skill. That is a deliberate constraint. It means the value of the repository is the routing and the connectors, plus the fact that the dependencies are committed rather than resolved at install time. skills-lock.json is the mechanism that keeps those copies honest, pinning a source and a hash per skill so a vendored copy can be traced back to the official repository it came from.

The six-layer table maps standards to directories. Layer 1 is discovery, identity and reputation, with ERC-8004 registries from chaingpt/trustless-agents and bnb-chain/bnbchain-mcp, and starknet/starknet-identity; the README notes ERC-7857 has no public skill yet. Layer 2 is negotiation via A2A, with terminalskills/a2a-protocol and openserv/openserv-multi-agent-workflows. Layer 3 covers contracts and obligations through ERC-7710, ERC-8183 and Arkhai, with metamask/smart-accounts-kit for delegations and a genlayer-erc7710 connector; ERC-8183 also has no public skill yet. Layer 4 is payment and escrow, where x402, MPP and APP appear alongside yellow/yellow-settlement-room, coinbase/agentic-wallet, chaingpt/x402, okx/okx-agent-payments-protocol, tempo/mppx, nansen/nansen-mpp-payment and privy, plus an x402-erc7710 connector. Layer 5 is execution rails. Layer 6 is verification and disputes, which the README describes as the layer Internet Court exists to add, with GenLayer dev skills, intelligent-oracle and kleros, and two GenLayer connectors; UMA has no public skill yet.

Two absences in that table are worth reading carefully. ERC-7857, ERC-8183 and UMA are named as part of the stack but have no public skill in the repository. The README is explicit about this rather than hiding it, which is a point in its favour, but it also means the six-layer picture is more complete on paper than in the vendored set.

Installing the skill and making a first contract decision

The repository is published as an Agent Skill and a Claude Code plugin, and the top-level entries include .claude-plugin/ and openclaw.plugin.json alongside SKILL.md. The README does not give a package-manager install command, so the practical first step is to clone the repository and let the agent read the master skill.

git clone https://github.com/internet-court/internet-court-skill
cd internet-court-skill
ls SKILL.md integrations vendored

After that, SKILL.md is the entry point. The README says it is the master skill and that you start there because it routes to everything below. Reading it is how you find out which connector or vendored skill handles the step you are on, rather than guessing from the directory tree.

The lockfile is the second thing to open. Each vendored skill has a pinned source, hash and refresh command, which is what lets you confirm that a copy in vendored/ still matches the official repository it came from.

cat skills-lock.json

For a first real use, the README describes the shape of the flow rather than a single command: structure the deal, hold funds safely, and agree the adjudication venue in advance. The dispute layer is where the choice is made, and the README lists GenLayer, Kleros and UMA as examples of who might judge, with connectors under integrations/ for the GenLayer paths. Because the README does not publish a step-by-step walkthrough with expected output, treat the first run as reading and selecting: pick the connector that matches your chosen venue, then follow the vendored skill for the protocol that holds the funds.

Where the vendoring model breaks down

Committing 91 skills from 33 owners into one repository buys reproducibility and costs you freshness. The pinned hash in skills-lock.json is a promise that a vendored skill matches a specific upstream state, and the README gives a refresh command per skill, but nothing in the repository documents what happens when an upstream protocol changes a skill in a way that breaks the routing in SKILL.md. There is no documented rollback, and no documented upgrade procedure beyond the per-skill refresh entry.

The second limitation is coverage. The README states plainly that not every founding member ships a public agent skill yet, and that the vendored table is the set available in the repository today. So a team that has standardized on a protocol whose skill is not vendored has to wire that protocol up itself, and the connector layer is the only first-party code that could bridge it. The README also notes that the standard is open and openly governed and that any agent can adopt it now, which is a statement about governance rather than a guarantee about the completeness of the code.

The third is scope. This is a skill for agents, not a service. There is no hosted adjudication endpoint described in the repository, no dashboard, and no runtime that watches a deal after it is signed. If your problem is detecting a breach after the fact rather than structuring the contract so a breach has a defined venue, this repository does not address it.

Internet Court Skill compared with assembling the protocol skills yourself

The obvious alternative is not another product. It is fetching the same skills from their official sources and writing your own glue. The README lists those sources directly: genlayerlabs/skills, metamask/skills, okx/onchainos-skills, near/agent-skills, keep-starknet-strange/starknet-agentic and solana-foundation/solana-dev-skill, among others. Every one of those is a public skill you could vendor into your own agent.

The difference in approach is what you get on top. Assembling them yourself gives you exactly the protocols you need at whatever version you choose, with no router in between and no lockfile to maintain. Internet Court Skill gives you a single master skill that routes across all six layers, a consistent place to express the adjudication choice, and connector skills under integrations/ that join specific pairs, such as the genlayer-erc7710 and x402-erc7710 connectors. The trade is breadth and a shared contract structure against a fixed set of pinned copies you do not control.

A second comparison is against using one protocol's skill alone. MetaMask's smart-accounts-kit covers ERC-7710 delegations, and GenLayer's skills cover intelligent contracts and testing. Neither covers the other's ground. If your deals never reach a dispute, the single-protocol path is smaller and easier to reason about, and the adjudication layer here is weight you are carrying for a case that does not occur.

Licence, maintenance and what the pins cost you

The repository carries a LICENSE file and a NOTICE.md at the top level, and the metadata records the licence as NOASSERTION, which means the licence could not be determined automatically from the repository. That matters more here than in a typical project, because the repository redistributes copies of skills published by other organizations. Each vendored skill keeps its own upstream licence, and NOTICE.md exists to track that. If you plan to redistribute the bundle or ship it inside a product, read LICENSE and NOTICE.md together and check the upstream licence for every vendored skill you actually depend on. This is a description of what the files are, not legal advice.

On maintenance, the repository is not archived and the last push was on 2026-08-19. That is recent enough that the vendored set reflects current upstream skills. The upgrade cost is the part to budget for: skills-lock.json records a source, a hash and a refresh command per vendored skill, so keeping current means re-running those refreshes and re-checking that SKILL.md still routes correctly. With 91 skills from 33 owners, that is a recurring chore proportional to how many of those skills you rely on, and the README does not describe an automated way to do it.

Editorial conclusion

Internet Court Skill suits teams already building agents that transact with other agents and that want the deal structure, the escrow path and the adjudication choice expressed in one skill rather than wired together by hand. It is the wrong tool if you only need a single protocol integration, because the vendored copies are the same public skills you would fetch from the official repositories anyway. Before adopting, read SKILL.md end to end, check skills-lock.json for the pinned source and hash of every vendored skill you plan to rely on, and confirm that the arbitration venue you want is actually covered by a connector in integrations/. The repository is not archived and the last push was on 2026-08-19, so the vendored set is recent, but the README does not document rollback or an upgrade procedure for those pins.

Frequently asked questions

Official sources

1. internet-court/internet-court-skill on GitHub
2. Issues
3. README