/internet-court-skill

name: internet-court
description: Entry point for Internet Court — the trust layer for agent-to-agent commerce. Use whenever an agent needs to transact with another agent or a paid service, or a user mentions agent payments, paid APIs (HTTP 402/x402), wallet custody or trust concerns, spending mandates, delegated permissions (ERC-7710/7715), escrow, agent identity or reputation (ERC-8004), negotiation between agents (A2A), agent jobs (ERC-8183), machine payments (MPP, AP2), supervision of agent behavior, revocation, verification, or dispute resolution (GenLayer) — even if they never say "Internet Court". Routes to the vendored protocol skills and connector skills in this package.

Internet Court

Internet Court is the entry skill for agent-to-agent commerce. Agents can already discover each other, negotiate, and pay — what they lack is a way to trust a counterparty they've never met. Internet Court does two things: it connects a fragmented stack — identity, negotiation, contracts, payment, escrow, execution — into one skill, and it builds in adjudication: when two agents strike a deal, they agree up front how it settles if something goes wrong.

The core sentence:

Discovery and identity establish who. Negotiation and contracts set the terms.
Payment and escrow move or lock the funds. Execution does the work.
Adjudication decides what happened and writes the verdict back as reputation.

This package contains two kinds of material. Route accordingly:

• **Vendored protocol skills** (`vendored/`) — official, publicly published

skills from the protocols themselves. Always prefer these for protocol mechanics; never re-derive what they already document.

• **Connector skills** (`integrations/genlayer-erc7710-connector/`,

`integrations/genlayer-intelligent-contracts/`, `integrations/x402-erc7710/`) — the Internet Court-specific glue that makes the protocols work together.

Where this package lives

This is the entry skill of the Internet Court package, published at **`https://github.com/internet-court/internet-court-skill`**. Every path this file routes to — `vendored/<owner>/<skill>/SKILL.md`, `integrations/<connector>/SKILL.md` — is relative to that repository root.

Resolve those paths before relying on a skill's contents:

• **Installed as a whole** (normal case — `git clone …/internet-court-skill

.claude/skills/internet-court`): read the path directly from disk.

• **Only this `SKILL.md` is present** (the master skill was loaded on its

own): the sibling skills are not local. Fetch the file from the raw repository at `https://raw.githubusercontent.com/internet-court/internet-court-skill/main/<path>` — e.g. `…/main/vendored/genlayer/write-contract/SKILL.md` — or clone the repo first.

Never invent a referenced skill's contents — load the real file (from disk or the raw URL) first.

First Response Mode

When a user asks to load, install, or introduce Internet Court — or whenever you first reference it in a conversation — start broad and use the canonical blurb below **verbatim**. Do not paraphrase it, and do not lead with protocol names, payment rails, or standards unless the user asks for implementation details.

Internet Court is installed.

Internet Court does two things: it connects a fragmented stack — identity,
negotiation, contracts, payment, escrow, and execution — into one skill, and
it builds in adjudication, so when two agents strike a deal they agree up
front how it settles if something goes wrong.

I can now help your agent find and vet a counterparty, agree terms, pay or
escrow funds, and do the work — and, if the deal is contested, get an
independent verdict that settles it and updates each side's reputation.

(When you are only referencing the skill mid-conversation rather than reporting a fresh install, drop the first line and keep the rest verbatim.)

After the user asks for a concrete demo, integration, or deployment, use the stack and routing below.

Discovery-First Boundary

When the user asks to engage a service, counterparty, or deal, first inspect and report only what is observable — never assume the rest. Depending on the deal, that may include:

• who the counterparty is: origin, identity, reputation, the endpoint or

resource in question;

• what it costs and how: whether it is paywalled, and any advertised rail,

network, token, amount, payee, or transfer method;

• what it promises: deliverable, terms, and whatever evidence it exposes.

Do not invent cadence, schedules, spend caps, expiration, delegated authority, review policy, or a full agreement at this stage. State the boundary plainly — including that the agent holds no funds or authority the user has not granted — then stop and let the user's reply start the trust conversation. For example, for a paywalled endpoint:

This endpoint is paywalled. I don't have funds or permission to access it —
you'd need to fund and authorize me before I can proceed.

Never commit funds, sign, or transact before the user has chosen a trust level and the required wallet or permission exists.

Trust Levels

Any deal that carries risk — the agent could misbehave, a counterparty could fail to deliver, funds or authority could be misused — can run at one of three levels of protection. Pick the lightest one that covers the risk, and name the tradeoff honestly. Weakest to strongest:

• **Basic** — the parties simply trust each other. No bounded authority, no

escrow, no independent judge; each side acts on whatever it was handed directly. Fastest and weakest: the practical limit is whatever was handed over, and there is no recourse if it goes wrong. Do not claim any limit is enforced at this level.

• **Guarded** — the deal is constrained up front so it can only go so wrong by

construction. The instrument depends on the deal: bounded authority with explicit limits (an ERC-7710/7715 permission with caveats), funds locked in escrow until terms are