CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

paddle-usage-based-billing

Add Paddle usage-based billing (early access) to a Next.js app — early access check, usage balance units, meters, price allowances, usage events, balance gating, and `usage_balance.depleted`, using the Paddle API directly.

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

The canonical home for this skill is paddle-usage-based-billing in PaddleHQ/paddle-agent-skills

SKILL.md
Quality
Evals
Security

Quality

Content

85%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 executable code and strong validation loops, held back by monolithic structure and mild repetition of early-access caveats. Splitting reference material and one-off scripts into bundle files would improve both disclosure and token efficiency.

Suggestions

Move the one-off scripts (check-usage-billing-access.ts, setup-usage-billing.ts) into a scripts/ directory as real files and reference them, keeping SKILL.md as the workflow overview.

Move the renewals/plan-changes table, API constraints (meter rules, quantity/occurred_at windows), and pitfalls into a references/ file (e.g. reference.md) linked from a short overview section.

State the 'overage is not billed during early access (beta)' fact once in the early-access section and reference it elsewhere instead of repeating it in Steps 3, 5, and the limitations section.

DimensionReasoningScore

Conciseness

The body is dense with non-obvious, version-specific facts (early-access quirks, error codes, meter constraints) and assumes competence without padding, but the 'early access (beta)' qualifier and overage-not-billed fact are repeated several times (e.g. the 'Paddle never blocks usage' callout restated across sections), which could be trimmed.

4 / 5

Actionability

Every step ships copy-paste-ready, executable code — a complete API helper, access-check and setup scripts with run commands ('node --env-file=.env.local --import tsx scripts/<name>.ts'), SQL schema, retry/backoff logic, and webhook handling with concrete error codes to branch on.

5 / 5

Workflow Clarity

Steps 1–7 are clearly sequenced with explicit validation checkpoints: the Step 2 access check, the Step 4 backoff-retry balance confirmation, retry semantics for the outbox (network/5xx/429 vs. permanent failures), and a 7-item end-to-end 'Verify the integration' checklist covering the dedupe and overage cases.

5 / 5

Progressive Disclosure

The skill is a single ~500-line monolith: no bundle files exist and everything — full script implementations, the renewals table, API constraints, and pitfalls — is inlined in SKILL.md rather than split into scripts/ or references/ files. Structure within the file is good, but content that clearly belongs in separate files is inline.

3 / 5

Total

17

/

20

Passed

Description

71%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, jargon-appropriate description that clearly states what the skill does with concrete component names, but it omits any explicit 'when to use' trigger guidance and misses a few natural synonyms users might say. Adding a Use-when clause would round it out.

Suggestions

Append a trigger clause such as: 'Use when the user wants metered or prepaid usage limits on Paddle subscription plans — e.g. 10,000 API calls or a pool of credits per month.'

Include common user phrasings like 'metered billing', 'credits', 'pay-per-use', or 'usage limits' alongside 'usage-based billing' so the description surfaces for natural variations.

DimensionReasoningScore

Specificity

The description enumerates multiple concrete actions — 'early access check, usage balance units, meters, price allowances, usage events, balance gating, and `usage_balance.depleted`' — comprehensively covering the integration's components with no vague filler.

5 / 5

Completeness

The 'what' is explicit and concrete ('Add Paddle usage-based billing... to a Next.js app'), but there is no 'Use when...' clause or equivalent trigger guidance in the description, which caps completeness at 3 per the rubric guidelines.

3 / 5

Trigger Term Quality

Strong natural terms like 'Paddle usage-based billing', 'meters', and 'usage events', but common user phrasings such as 'metered billing', 'credits', 'pay-per-use', or 'usage limits' are absent. Good coverage overall, a few natural synonyms missing.

4 / 5

Distinctiveness Conflict Risk

The 'usage-based billing (early access)' niche with meters and usage events is clearly distinguishable, but sibling Paddle skills (catalog setup, checkout, webhooks) create minor overlap risk for generic 'Paddle billing' requests.

4 / 5

Total

16

/

20

Passed

Validation

87%

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

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (511 lines); consider splitting into references/ and linking

Warning

referenced_paths_exist

Referenced path issues: 2 missing

Warning

Total

14

/

16

Passed

Repository

PaddleHQ/paddle-agent-skills

Path

providers/cursor/plugin/skills/usage-based-billing/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.