CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

x402-erc7710

Design and implement demos combining x402 HTTP payments with ERC-7710 smart contract delegations and ERC-7715 wallet permission requests for subscriptions, bounded agent budgets, recurring spend, pay-per-use APIs, and agentic commerce.

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

High

Do not use without reviewing

Fix and improve this skill with Tessl

tessl review fix ./integrations/x402-erc7710/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

81%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a well-organized, highly actionable operational guide with concrete code, addresses, and explicit validation checkpoints across clearly sequenced workflows, clearing the destructive/batch validation bar. Its main weaknesses are minor over-explanation in the protocol primer and inlined detail that could be moved to reference files.

Suggestions

Trim the "Core Model" protocol primer to only what is non-obvious (ERC-7710 is draft, x402 retry path) and remove repeated boundary restatements across modes to tighten conciseness toward 5.

Move the "Signed Evidence Pattern" and "Periodic GenLayer Control" sections into a reference file (e.g., `references/evidence-and-review.md`) with one-line pointers from SKILL.md to push progressive_disclosure toward 5.

Add one complete executable script (e.g., a policy-validation or receipt-verification snippet) alongside the `AgentSpendPolicy` type to lift actionability from concrete guidance to fully copy-paste-ready.

DimensionReasoningScore

Conciseness

The body is dense, operational, and mostly assumes Claude's competence (e.g., numbered modes, guardrails, checklists) with only minor over-explanation in the "Core Model" section explaining x402/ERC-7710/ERC-7715; it is not 5 because that protocol primer and some repeated boundary restatements could be trimmed further.

4 / 5

Actionability

It provides a concrete, copy-paste-ready `AgentSpendPolicy` TypeScript type, specific addresses (e.g., `0x7AB80AE93246108bd1e80b8215c5F1147Ca56af0`), exact validation rules ("0x plus 64 hex characters"), and concrete routes/prices; it stops short of 5 because there are no complete executable scripts, only a type definition plus inline operational guidance.

4 / 5

Workflow Clarity

Multiple clearly sequenced processes (Discovery-First 1-5, Adjudicated Setup 1-5, Execution flow 1-10, Implementation Checklist 1-10) carry explicit validation checkpoints ("Validate receipt proofs before advancing", tx-hash format checks, "Do not mark a step complete until...") and feedback loops for this payment/wallet-permission skill, satisfying the destructive/batch validation requirement.

5 / 5

Progressive Disclosure

SKILL.md is a well-sectioned overview with a clearly signaled, one-level-deep reference to `references/demo-blueprints.md` (a real file), but a fair amount of detail (Signed Evidence Pattern, Periodic GenLayer Control, Other Demo Ideas) is inlined that could be split out, leaving minor organization gaps short of 5.

4 / 5

Total

17

/

20

Passed

Description

70%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is specific and highly distinctive, clearly naming the combined protocols and target use cases, but it lacks an explicit "Use when..." trigger clause, which caps completeness at 3. Adding natural-language trigger guidance would lift the weakest dimension.

Suggestions

Append an explicit trigger clause such as "Use when building demos where an agent pays for HTTP resources via x402 within a bounded ERC-7710/ERC-7715 delegated permission." to satisfy the missing "when" and raise completeness.

Broaden trigger-term coverage with natural synonyms users might say (e.g., "HTTP 402 payments", "micropayments", "delegated agent spending", "per-request payments") to push trigger_term_quality toward 5.

Vary the action vocabulary beyond "design and implement" (e.g., "scaffold, configure, and validate") to give specificity more distinct concrete actions.

DimensionReasoningScore

Specificity

"Design and implement demos" names two concrete actions and the description binds three specific standards (x402, ERC-7710, ERC-7715) to five concrete use cases, giving several specific actions with only minor coverage gaps; it falls short of 5 because the action vocabulary is essentially limited to design/implement rather than a richer set of distinct operations.

4 / 5

Completeness

The "what" is clearly stated ("Design and implement demos combining x402 HTTP payments with ERC-7710... for subscriptions, bounded agent budgets..."), but there is no "Use when..." clause or equivalent explicit trigger guidance, so per the rubric completeness is capped at 3 with only weakly implied "when".

3 / 5

Trigger Term Quality

It surfaces good keyword coverage with natural domain phrases such as "subscriptions", "recurring spend", "pay-per-use APIs", and "agentic commerce" alongside the necessary protocol jargon; it is not 5 because common synonyms and variations (e.g., "micropayments", "HTTP 402", "delegated spending") are absent.

4 / 5

Distinctiveness Conflict Risk

The intersection of x402 HTTP payments, ERC-7710 delegations, and ERC-7715 permission requests is a clear, narrow niche with distinct triggers and minimal overlap risk with other skills.

5 / 5

Total

16

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

internet-court/internet-court-skill

Path

integrations/x402-erc7710/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.