showmethemoney-pro

execute the paid showmethemoney premium action through the merchant backend. use when the user wants to unlock or run the protected showmethemoney capability...

Security Scan

The skill's runtime instructions align with a premium-payment flow, but it omits required runtime dependencies (StablePay primitives and a local merchant backend) and does not declare the sensitive capabilities it needs, so the package is internally inconsistent and needs clarification before use.

Purpose & Capability

The SKILL.md describes a merchant-backed premium action with StablePay-powered payments, which is coherent with the skill name. However the skill does not declare that it requires the StablePay plugin/runtime primitives (stablepay_runtime_status, stablepay_pay_via_gateway) or access to a merchant backend on http://127.0.0.1:8787. Those runtime dependencies are necessary for the described purpose but are not listed in the registry metadata (no required env, no required config paths, no primary credential). The omission makes the declared purpose and the actual runtime requirements inconsistent.

Instruction Scope

Instructions explicitly tell the agent to read stablepay_runtime_status, call a local merchant endpoint, parse a 402 x402 payment requirement, and invoke stablepay_pay_via_gateway to perform payment. These steps are narrowly scoped to the payment flow the skill claims to implement. But the instructions expect access to platform-specific runtime state and a local service; the skill gives the agent broad authority to perform on-chain/monetary actions without describing explicit consent/confirmation behavior beyond 'use StablePay' and a single retry. The SKILL.md also says 'NEVER use any hardcoded or fallback values' which tightly couples the skill to the backend response and may prevent safe defaults or user prompts.

Install Mechanism

This is an instruction-only skill with no install spec or code files, so nothing is written to disk and there are no package downloads. That low-risk delivery is consistent with the kind of platform-integrated payment flow described.

Credentials

The skill uses payment and identity data (buyer DID from stablepay_runtime_status and x402 payment details) but lists no required credentials or permissions. It implicitly requires access to the StablePay runtime (which itself likely needs credentials) and the ability to contact a local merchant backend. Asking the agent to perform payments without declaring the required credential scope (or requiring user confirmation flows) is disproportionate and should be made explicit.

Persistence & Privilege

The skill does not request always:true, does not install components, and is user-invocable only. It does not attempt to modify agent configuration or other skills. Autonomous invocation is allowed (platform default) but does not appear combined with other privileges here.

What to consider before installing

This skill implements a premium payment flow that depends on a local merchant backend and the platform's StablePay runtime, but it does not declare those dependencies or any credentials. Before installing or enabling it, ask the publisher to: (1) explicitly list required runtime primitives/plugins (stablepay_runtime_status, stablepay_pay_via_gateway) and any credentials StablePay needs; (2) confirm why the merchant backend is expected at 127.0.0.1:8787 and whether that will contact external facilitator URLs; (3) clarify user consent and confirmation steps for real payments and per-report purchases; and (4) add safeguards (prompting the user and honoring local payment limits). Do not let the skill perform payments until you trust the local backend and the StablePay integration and you understand how user confirmation is handled.

Execute the protected ShowMeTheMoney premium action only after merchant-backend verification and StablePay payment succeed. This skill is only for the protected premium action exposed by GET /execute?agent_did=<buyer_did>

Main workflow

When the user asks to use the premium ShowMeTheMoney capability:

1. Resolve the current buyer DID from stablepay_runtime_status.
2. Call the merchant backend premium endpoint:
   • GET http://127.0.0.1:8787/execute?agent_did=<buyer_did>
3. Treat the merchant backend as the source of truth.
4. If the backend returns 200, return the protected result.
5. If the backend returns 402 Payment Required:
   • Parse the x402 response from accepts[0]:
     • skill_did → from accepts[0].extra.skillDid
     • price → from accepts[0].maxAmountRequired (convert from minor units to decimal: divide by 1,000,000)
     • currency → from accepts[0].extra.currency
     • facilitator_url → from accepts[0].extra.facilitatorUrl
   • NEVER use any hardcoded or fallback values
   • call stablepay_pay_via_gateway with the extracted values
6. If payment succeeds, retry the same /execute request once.
7. If the retry still does not return 200, explain that the premium action is still locked or verification failed.

Premium action contract

Use this request for the premium action:

• method: GET
• endpoint: http://127.0.0.1:8787/execute
• required query parameter: agent_did

Optional query parameters may be used when helpful:

• q
• prompt

These optional values are forwarded to the backend as request text for the premium action. The backend should:

1. receive the premium request
2. verify purchase state via StablePay
3. return 402 when the user has not purchased the skill
4. return 200 only after verification succeeds
5. return a merchant-generated proof token in the premium result

Treat the backend response as the final authority.

Unlocked Store (Report Store)

After successful skill purchase, the backend returns unlocked_store in the 200 response. Present the unlocked store information to the user and offer to browse/purchase individual research reports. Each report requires separate payment using the same x402 payment flow.

Payment rules

When payment is required:

1. Use stablepay_pay_via_gateway.
2. Use the requirement returned by the backend when present.
3. Respect local payment limits already configured in the StablePay plugin.
4. Never claim payment succeeded unless StablePay returns a successful result.
5. Retry the premium action only once after a successful payment.