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 instructions are mostly coherent for performing a merchant-driven premium purchase, but there are unclear/contradictory defaults and it gives the merchant backend unchecked power to dictate payment endpoints and amounts — this requires strong trust in that backend and additional safeguards.

Purpose & Capability

The skill's name and description match the runtime instructions: it calls a merchant backend and uses the StablePay flow to pay and then retry a protected /execute action. However, the SKILL.md both admonishes 'Never use hardcoded defaults' and also embeds a hardcoded merchant_backend_base_url (http://127.0.0.1:8787) and endpoint; that contradiction is unexpected and should be clarified.

Instruction Scope

Instructions require calling a local merchant backend, interpreting a 402 response, and then calling stablepay_pay_via_gateway with payment parameters supplied by the backend. That is coherent for a merchant-driven flow, but it gives the backend unilateral control over critical parameters (skill_did, price, currency, payment_endpoint). There are no explicit validation steps (e.g., require HTTPS, validate allowed gateway domains, or display payment destination to user), increasing risk that a malicious backend could direct payments to attacker-controlled endpoints.

Install Mechanism

This is instruction-only with no install spec or code files, so nothing is written to disk or downloaded. That minimizes supply-chain risk.

Credentials

The skill requests no environment variables or credentials itself and relies on StablePay plugin calls for wallet/DID/payment operations — this is proportionate to a payment workflow. That said, because the backend dictates the payment_endpoint and amounts, the design places heavy trust in that backend; absence of any declared backend configuration or validation is a notable gap.

Persistence & Privilege

The skill does not request always:true, does not modify other skills, and has no install-time persistence. Normal autonomous invocation is allowed (default), which is expected for a skill of this type.

What to consider before installing

This skill is functionally coherent for running a merchant-controlled premium purchase, but it relies entirely on the merchant backend to tell the agent what to charge and where to send payments — including the payment gateway endpoint. Before installing or enabling this skill: (1) only use it with a merchant backend you fully trust and can inspect; (2) require the backend URL to be configurable and verified (prefer HTTPS and a non-localhost production host); (3) insist on explicit validation rules (e.g., whitelist gateway domains, show the user the payment destination and amount before committing); (4) test in a sandbox environment to confirm the skill does not accept unexpected endpoints or amounts; and (5) ensure the StablePay plugin implementation is trusted and audited. The conflicting guidance about 'never hardcode defaults' vs. the embedded http://127.0.0.1:8787 default should be resolved by the publisher — treat the localhost URL as an example only, not a safe default.

Execute the protected ShowMeTheMoney premium action only after merchant-backend verification and StablePay payment succeed.

Configuration (Merchant Backend as Source of Truth)

Important: This skill does NOT define fixed prices or skill DIDs. All payment parameters are determined by the merchant backend.

• merchant_backend_base_url: http://127.0.0.1:8787
• premium_action_endpoint: /execute

The merchant backend is the ONLY source of truth for:

• skill_did - The skill identifier to pay for
• price - The amount to charge (in combination with currency)
• currency - The payment currency (USDC/USDT)
• payment_endpoint - Where to submit the payment

Never use hardcoded defaults. Always obtain these values from the backend's 402 response.

Preconditions

Before using this skill:

1. Call stablepay_runtime_status.
2. If no local wallet exists, create or bind one.
3. If no backend DID is registered, call stablepay_register_local_did.
4. If payment limits are missing, call stablepay_configure_payment_limits.

Do not require stablepay_build_payment_policy unless another workflow explicitly depends on it.

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:
   • MUST read ALL payment parameters (skill_did, price, currency, payment_endpoint) from the backend response
   • NEVER use any hardcoded or fallback values
   • call stablepay_pay_via_gateway with the exact values from the backend
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.

Important: If the merchant backend is unreachable or does not return a valid 402 response, do NOT proceed with payment. Report the backend error to the user.

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.

Expected backend behavior

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.

Success criteria

A successful premium response should include a backend-generated result such as:

• protected_result.kind = merchant-generated-proof
• protected_result.proof.display_token
• access.verified_by_backend = true

This proof token is the strongest evidence that the premium capability was unlocked through backend verification, not guessed or simulated locally.

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.

What not to use as proof of access

Never treat any of the following as proof that the premium action is unlocked:

• local plugin state
• wallet existence
• DID registration alone
• local payment policy alone
• raw Solana balance checks
• a previous purchase attempt without successful backend verification

Only the merchant backend may decide that access is unlocked.

Scope limits

This skill is only for the protected premium action exposed by:

• GET /execute?agent_did=<buyer_did>

Do not treat these routes as the main premium workflow:

• /developer/revenue
• /developer/sales
• /agent/balance
• /agent/transactions

Those are debugging or operator-facing routes, not the premium capability itself.

Safety

• Never expose private keys, mnemonic material, decrypted local state, API keys, or merchant secrets.
• Never bypass backend verification.
• Never invent payment success.
• Never claim premium access is unlocked unless the backend returns success.
• Never return fabricated proof tokens.