internet-court

# 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:

```text
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.

```text
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:

```text
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 met, or scoped terms both sides sign. Hard limits
  exist, but there is no neutral party to decide a contested outcome. Load
  `vendored/metamask/smart-accounts-kit/skill.md` for permission mechanics, or
  the layer-3/4 escrow skills for locked-funds deals.
- **Adjudicated** — Guarded, plus an independent review path with signed
  evidence that can decide a contested outcome and enforce the consequence:
  release or refund escrow, constrain or revoke the granted authority, and
  write the verdict back to reputation. Load
  `integrations/genlayer-intelligent-contracts/SKILL.md` for the review
  interface and `integrations/genlayer-erc7710-connector/SKILL.md` for
  enforcement.

Match the l