Build automated billing systems for recurring payments, invoicing, subscription lifecycle, and dunning management. Use when implementing subscription billing, automating invoicing, or managing recurring payment systems.
74
63%
Does it follow best practices?
Impact
92%
1.64xAverage score across 3 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/payment-processing/skills/billing-automation/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that clearly articulates specific capabilities (billing systems, invoicing, subscription lifecycle, dunning), includes natural trigger terms users would employ, and provides an explicit 'Use when' clause. It is well-scoped to a distinct domain with minimal conflict risk.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'automated billing systems', 'recurring payments', 'invoicing', 'subscription lifecycle', and 'dunning management' — these are all distinct, concrete capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (build automated billing systems for recurring payments, invoicing, subscription lifecycle, dunning management) and 'when' (explicit 'Use when implementing subscription billing, automating invoicing, or managing recurring payment systems'). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'subscription billing', 'invoicing', 'recurring payments', 'dunning management', 'billing systems'. These cover the main terms a user would naturally use when requesting this type of work. | 3 / 3 |
Distinctiveness Conflict Risk | The description carves out a clear niche around subscription billing, dunning, and recurring payment systems. Terms like 'dunning management' and 'subscription lifecycle' are highly specific and unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a massive, verbose reference document that dumps hundreds of lines of semi-executable code inline without clear structure or progressive disclosure. It explains concepts Claude already understands (what billing cycles are, what proration means) and provides boilerplate class implementations that Claude can generate from much more concise specifications. The code depends on undefined modules and has incomplete implementations, reducing its actionability.
Suggestions
Reduce to a concise overview (under 100 lines) with key patterns and gotchas that Claude wouldn't already know, moving detailed implementations to separate reference files (e.g., DUNNING.md, PRORATION.md, TAX.md)
Remove the 'Core Concepts' section entirely - Claude knows what billing cycles, subscription states, and proration are
Make the Quick Start use a real library (e.g., Stripe's actual API) instead of a fictional 'billing' module, or clearly frame it as a custom implementation pattern
Add explicit validation checkpoints for financial operations: idempotency keys, double-charge prevention, reconciliation steps, and testing/verification guidance
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~400+ lines. Explains basic concepts Claude already knows (subscription states, what proration is, what dunning is). The 'Core Concepts' section is entirely unnecessary preamble. Much of the code is boilerplate that Claude can generate on its own - full class implementations for Invoice, TaxCalculator, etc. don't add unique value. | 1 / 3 |
Actionability | Code examples are fairly concrete but not truly executable - they depend on undefined imports (from billing import BillingEngine), undefined helper functions (generate_id, generate_invoice_number, send_email), and incomplete implementations (to_pdf with just 'pass'). The Quick Start uses a fictional 'billing' module that doesn't exist. | 2 / 3 |
Workflow Clarity | The billing cycle processing shows a clear sequence (check due date → generate invoice → attempt payment → handle success/failure), and dunning has a retry flow. However, there are no explicit validation checkpoints, no error recovery guidance for the implementer, and no verification steps for critical financial operations like ensuring idempotency or handling race conditions. | 2 / 3 |
Progressive Disclosure | Monolithic wall of code with no references to external files. All content is inline - the tax calculation, invoice generation, usage billing, proration, and dunning sections could each be separate reference files. No navigation aids or cross-references exist. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (538 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
27a7ed9
Table of Contents
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.