CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

paddle-webhooks

Receive and verify Paddle webhooks in a Next.js Route Handler — signature verification, idempotency, retry semantics, and local testing.

1.08x
Quality

80%

Does it follow best practices?

Impact

100%

1.08x

1 of 3 eval scenarios. Add 2 more for a full score.

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./providers/cursor/plugin/skills/webhooks/SKILL.md

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

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.

A highly actionable, well-sequenced integration guide with real validation feedback loops and accurate, non-obvious Paddle delivery semantics. Its main weakness is repetition of the same status-code argument across three sections and two large generic MCP/CLI convention blockquotes inlined in an otherwise focused skill.

Suggestions

State the "only 2xx means delivered; pick one non-2xx for the whole catch" rule once (e.g. in Step 3) and have the pitfalls bullets reference it instead of re-arguing it twice more.

Move the generic Paddle MCP and CLI convention blockquotes into a shared reference file (they are tool-wide conventions, not webhook-specific) and keep only the webhook-relevant excerpts inline.

Deduplicate the 90-day replay/missed-events guidance between the delivery-contract section and the Common pitfalls bullet.

DimensionReasoningScore

Conciseness

The body is dense with non-obvious Paddle-specific facts and avoids explaining known concepts, but the core "only 2xx means delivered / one catch, one status" argument is repeated three times (Step 3 rules, the post-code rationale paragraph, and the first two pitfalls), the 90-day replay guidance appears twice, and the two long generic MCP/CLI convention blockquotes are only partially webhook-specific. It fits "mostly efficient but could be tightened" better than anchor 4.

3 / 5

Actionability

Fully executable throughout: a complete route handler, SDK helper, typed event-dispatch switch, an atomic guarded UPSERT SQL statement, an event-id ledger with DDL, exact CLI commands with --jq/--json flags, MCP execute snippets, and a deliberate tamper-and-restore verification procedure. Copy-paste ready and covers the common cases.

5 / 5

Workflow Clarity

Clear sequence (prerequisites → Steps 1–6 → local testing → pitfalls → verification) with explicit validation checkpoints and a genuine feedback loop: break the secret, confirm the non-2xx and failed delivery, restore, replay, and confirm success. No destructive or batch operations needing extra validation.

5 / 5

Progressive Disclosure

Well-organized single file with clear section headers, up-front "delivery contract" framing, and well-signaled pointers to sibling skills and external docs. No bundle files exist, and some inlined material (the generic Paddle MCP/CLI convention paragraphs, the event-id ledger detail) reads like reference content that could live in a separate file, which keeps it short of the "appropriately split" top anchor.

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.

A specific, distinctive description with natural trigger terms, weakened by the absence of any explicit "Use when..." trigger clause and a minor coverage gap around notification-destination setup. Adding a when-to-use clause with concrete trigger phrases would raise it to the top band.

Suggestions

Add an explicit trigger clause, e.g. "Use when building the server-side endpoint that receives Paddle webhook events, or when the user mentions Paddle webhooks, verifying webhook signatures, or webhook retry/idempotency in Next.js."

Mention creating/configuring the notification destination (a full step in the body) so the capability list is comprehensive.

Include common user phrasings like "webhook endpoint" or "webhook handler" as trigger terms.

DimensionReasoningScore

Specificity

Concrete verbs ("Receive and verify") plus four named capability areas ("signature verification, idempotency, retry semantics, and local testing") anchored to a specific stack. It omits configuring the notification destination, which the body covers as a whole step, so coverage has minor gaps rather than being comprehensive.

4 / 5

Completeness

The "what" is clear and concrete, but there is no "Use when..." clause or equivalent explicit trigger guidance, which the rubric caps at 3. The "when" is only weakly implied by naming the domain.

3 / 5

Trigger Term Quality

Includes natural phrases users would say for this task ("Paddle webhooks", "Next.js", "signature verification", "local testing"). Common variations like "webhook endpoint", "callback URL", or "webhook handler" are missing, so coverage is good but not comprehensive.

4 / 5

Distinctiveness Conflict Risk

"Paddle webhooks in a Next.js Route Handler" is a clear niche with distinct triggers; it is unlikely to fire for sibling Paddle skills (subscription-sync, checkout-web, sandbox-testing) or non-Paddle webhook work.

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

Path

providers/cursor/plugin/skills/webhooks/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.