CtrlK
BlogDocsLog inGet started
Tessl Logo

paddle-sandbox-testing

Test a Paddle integration end-to-end using the sandbox environment, test cards, the webhook simulator, and local tunnels — without taking real money.

66

Quality

79%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Medium

Suggest reviewing before use

Fix and improve this skill with Tessl

tessl review fix ./providers/codex/plugin/skills/sandbox-testing/SKILL.md

The canonical home for this skill is paddle-sandbox-testing in PaddleHQ/paddle-agent-skills

SKILL.md
Quality
Evals
Security

Quality

Content

88%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 unusually actionable, well-sequenced body: concrete commands, card numbers, and an explicit end-to-end verification loop with confirmation checkpoints. Its only weaknesses are minor — slight explanatory padding and an MCP API-conventions block that would sit better in a reference file.

DimensionReasoningScore

Conciseness

The body is dense and operational — tables instead of prose, key-prefix disambiguation ('pdl_sdbx_apikey_' vs 'pdl_live_apikey_'), no basic-concept explanations. Minor over-explanation could be trimmed ('This is intentional — it makes...' and some 'Why it matters' cells), keeping it just below anchor 5's every-token-earns-its-place standard.

4 / 5

Actionability

Fully executable throughout: copy-paste test card numbers with expected outcomes, a concrete .env block, runnable 'hookdeck listen 3000' commands, a complete MCP execute code sample with gotcha notes, exact dashboard navigation paths, and specific failure symptoms. Specific examples cover the common cases including decline and dunning cards.

5 / 5

Workflow Clarity

Steps 1-4 are clearly sequenced, and Step 5 is an end-to-end test loop with explicit 'Confirm:' validation checkpoints after both the pay and cancel actions, plus error-recovery guidance (verification failure diagnosed as a secret mismatch). Not a destructive or batch operation, so no validation cap applies.

5 / 5

Progressive Disclosure

A single-file skill with no bundle directory; sections are well-organized with clear headers and an external 'Related docs' section. The MCP conventions blockquote (camelCase methods, pagination, hard caps) is inline reference-style material that could live in a separate file — a minor placement gap that fits anchor 4 better than anchor 3's broadly inlined content.

4 / 5

Total

18

/

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.

A specific, well-targeted description that names concrete tools and a meaningful safety boundary, but it omits any explicit 'Use when...' trigger guidance, capping its completeness. Adding a when-clause would lift it into the top tier.

Suggestions

Add an explicit trigger clause, e.g. 'Use when verifying a Paddle integration before going live, or when the user mentions Paddle, sandbox testing, test cards, or webhook testing.'

Include natural synonym terms users are likely to say, such as 'checkout testing' or 'payments testing', to broaden trigger coverage.

Mention subscription state-change testing (renewals, cancellations, dunning) since that is a covered capability and a natural search phrase.

DimensionReasoningScore

Specificity

Names the domain and several concrete capabilities ('sandbox environment, test cards, the webhook simulator, and local tunnels'), plus the safety boundary 'without taking real money'. It stops short of anchor 5's comprehensive action coverage (no mention of subscription state changes, failure-path testing, or checkout verification), but exceeds anchor 3's 1-2 actions.

4 / 5

Completeness

The 'what' is clear and concrete (test a Paddle integration end-to-end via sandbox/test cards/simulator/tunnels), but there is no 'Use when...' clause or equivalent explicit trigger guidance — the rubric caps completeness at 3 in that case. It is not 4 because the 'when' is wholly absent rather than merely weakly implied.

3 / 5

Trigger Term Quality

Good natural keyword coverage: 'Paddle', 'sandbox', 'test cards', 'webhook simulator', 'local tunnels', 'end-to-end' are phrases users testing a Paddle integration would say. A few natural variants are missing ('checkout testing', 'test webhooks', 'payments testing'), so it sits at anchor 4 rather than 5.

4 / 5

Distinctiveness Conflict Risk

'Paddle' plus sandbox/webhook-simulator/tunnel terminology carves out a clear vendor-specific niche with distinct triggers and minimal conflict risk against generic testing or other payment-provider 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
PaddleHQ/paddle-agent-skills
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.