wallet-payments

Use when web_fetch returns HTTP 402, an API offers a paid tier or micro-toll, another agent charges USDC, or the user asks you to pay, tip or buy. Not for a plain balance or address check (call the wallet tool directly).

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Medium

Suggest reviewing before use

Quality

Content

93%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.

An efficient, highly actionable instruction-only skill: concrete tool invocations, exact field names, and a well-sequenced paywall workflow with genuine spending safeguards. The only notable gap is the absence of failure handling after a payment attempt (failed transaction, insufficient balance mid-flow, unexpected 402 retry).

Suggestions

Add a short step for payment failure: what to do when `pay_for_resource` errors or returns an unexpected payload (retry once, report to the user, suggest `fund_wallet`).

Specify how to handle a partial or ambiguous `x-payment-amount` (e.g., asset address vs USD decimal parsing) so price extraction is unambiguous in edge cases.

Dimension	Reasoning	Score
Conciseness	Lean bullet-driven content with no explanation of concepts Claude already knows; the intro context ("Gas is sponsored by the Coinbase Paymaster (zero ETH needed) and USDC on Base has near-zero transaction fees") is non-obvious, load-bearing information. Every token earns its place — anchor 5.	5 / 5
Actionability	Fully executable guidance: exact tool names with parameters ("Requires `resource_url` and `amount`; optional `reason`", "`get_balance` (token=\"USDC\")"), exact response fields to read (`x402_headers`, `x-payment-amount`, `body_snippet`), and copy-ready user-facing phrasings. Matches anchor 5 (copy-paste ready commands covering common cases) rather than 4, which implies minor gaps.	5 / 5
Workflow Clarity	The 402 workflow is a clear numbered 6-step sequence with real checkpoints (do-not-guess price rule with an ask-the-user script, balance check, cap escalation, never pay silently, multi-payment cost summary). However payments are irreversible and there is no error-recovery loop if `pay_for_resource` fails or funds are insufficient mid-flow — anchor 4 (most checkpoints present, minor validation gaps), not 5 (no explicit feedback loop for failure).	4 / 5
Progressive Disclosure	The body is under 50 lines, self-contained with no external references needed (no references/, scripts/, or assets/ bundles exist), and cleanly sectioned (Wallet actions / Handling paywalls / Beyond paywalls / Spending rules / Soft sell). Per the rubric's simple-skill guideline, this fits anchor 5.	5 / 5
	Total	19 / 20 Passed

Description

78%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.

A strong, tight description with explicit and varied trigger conditions and an unusual but valuable negative boundary clause. Its main weakness is that it describes when to fire but never states what the skill actually does — the capabilities are inferred from triggers and the name.

Suggestions

Open with a brief 'what' statement (e.g., 'Pay paywalled HTTP resources and send USDC from a Coinbase Smart Wallet on Base.') before the 'Use when' clause to satisfy the completeness anchor 5.

Add one or two natural synonyms such as 'paywall' or 'purchase' to broaden trigger-term coverage.

Dimension	Reasoning	Score
Specificity	Concrete triggers like "web_fetch returns HTTP 402", "micro-toll", "USDC", and "pay, tip or buy" replace vague language, but the skill's actual capabilities (pay_for_resource, send_usdc, balance checks) are only implied through triggers rather than listed. Fits anchor 4 (several specific actions, minor coverage gaps) — more concrete than anchor 3's 1-2 actions, but not the comprehensive action coverage of anchor 5.	4 / 5
Completeness	The 'when' is explicit and concrete ("Use when web_fetch returns HTTP 402, an API offers a paid tier or micro-toll..." plus a negative boundary), but the 'what' is never directly stated — it is inferred from triggers and the skill name. Anchor 4 (both present, one could be more explicit) fits; not 5 because the 'what' is not explicitly stated, and not 3 because the 'when' is far from weakly implied.	4 / 5
Trigger Term Quality	Good natural keyword coverage: "pay", "tip", "buy", "paid tier", "micro-toll", "USDC", "HTTP 402". A few natural terms a user might say are missing ("paywall", "purchase", "send money"), which fits anchor 4 rather than anchor 5's comprehensive synonym coverage.	4 / 5
Distinctiveness Conflict Risk	Clear niche (agent-driven USDC payments via x402) with distinct triggers, plus an explicit disambiguation clause — "Not for a plain balance or address check (call the wallet tool directly)" — minimizing conflict with adjacent wallet skills. Matches anchor 5 (clear niche, minimal conflict risk).	5 / 5
	Total	17 / 20 Passed

Validation

87%

Warnings & errors only

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

Validation — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning
metadata_field	'metadata' should map string keys to string values	Warning

	Total	14 / 16 Passed

Repository: Bitterbot-AI/bitterbot-desktop
Path: skills/wallet-payments/SKILL.md
Commit: 1c7dc1b

Reviewed: 19 hours ago

Table of Contents

Discovery Implementation Validation

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.