billing-automation
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 well-crafted skill description that clearly communicates specific capabilities (billing systems, invoicing, subscription lifecycle, dunning) and provides explicit trigger guidance via a 'Use when...' clause. The domain-specific terminology like 'dunning management' and 'subscription lifecycle' makes it highly distinctive and unlikely to conflict with other skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'automated billing systems', 'recurring payments', 'invoicing', 'subscription lifecycle', and 'dunning management'. These are distinct, concrete capabilities. | 3 / 3 |
Completeness | Clearly answers both what ('Build automated billing systems for recurring payments, invoicing, subscription lifecycle, and dunning management') and when ('Use when implementing subscription billing, automating invoicing, or managing recurring payment systems') with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'subscription billing', 'invoicing', 'recurring payments', 'dunning management', 'billing systems'. These are terms developers naturally use when building payment infrastructure. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly occupies a distinct niche around subscription billing and dunning management. Terms like 'dunning', 'subscription lifecycle', and 'recurring payments' are highly specific and unlikely to conflict with general payment or e-commerce 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 excessively verbose, dumping hundreds of lines of illustrative but non-executable code that Claude could generate from much shorter guidance. It explains concepts Claude already understands (what proration is, what dunning means, common billing intervals) and provides boilerplate class definitions rather than focusing on tricky edge cases, gotchas, or project-specific conventions that would actually add value. The content would benefit enormously from being condensed to key patterns and decision points, with detailed implementations split into referenced files.
Suggestions
Reduce to ~50-80 lines focusing on key architectural decisions, edge cases, and gotchas (e.g., idempotency, race conditions in billing, timezone handling for billing anchors) rather than full class implementations Claude can generate.
Remove the 'Core Concepts' section entirely - Claude knows what billing cycles, subscription states, and proration are.
Split detailed implementations (dunning, tax, proration, usage billing) into separate referenced files, keeping only a concise overview with links in the main skill.
Add explicit validation checkpoints: verify invoice totals before charging, ensure idempotent payment processing, validate tax calculations, and include error recovery workflows for partial failures.
| 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 definitions with obvious methods like mark_paid(), to_html() with inline HTML templates, and tax rate lookup tables add little instructional value. | 1 / 3 |
Actionability | Code examples are structured and show concrete patterns, but they reference undefined imports ('from billing import BillingEngine'), undefined helper functions (generate_id, generate_invoice_number, send_email), and incomplete implementations (to_pdf with just 'pass', validate_vat_number with 'pass'). The code is illustrative rather than truly executable or copy-paste ready. | 2 / 3 |
Workflow Clarity | The billing cycle processing method 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 beyond the dunning retry, and no verification steps for critical operations like ensuring idempotency of charges or validating invoice totals before charging. | 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 management could each be separate reference files. There's no navigation structure or signposting to help find specific sections quickly. | 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 | |
- Repository
- wshobson/agents
- Commit
91fe43e
- 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.