Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add WellApp-ai/Well --skill vat-summarygit clone --depth 1 https://github.com/WellApp-ai/WellWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/wellapp-ai/well/vat-summary)<a href="https://agentmods.dev/skills/wellapp-ai/well/vat-summary"><img src="https://agentmods.dev/badge/skills/wellapp-ai/well/vat-summary.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00051 | $0.00491 |
| Opus 5 | $0.00026 | $0.00246 |
| Sonnet 5 | $0.00010 | $0.00098 |
| Haiku 4.5 | $0.00005 | $0.00049 |
Grade A, and why
vat-summary scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
VAT summary from Well
A VAT return is a byproduct of closed books, not a separate project. If the ledger is posted and correct, the figures already exist — the work is presentation. Work backward from the filing deadline and forward from the posted ledger, and surface uncertainty rather than reporting a number you're not sure of.
Build it from the posted ledger + tax rates
- Discover the schema first (see
well:querying-well-data). - Output VAT (collected on sales) — from issued
invoices/invoice_itemsand theirtax_rates, or the corresponding VATledger_accounts/journal_entriesfor the period. Group by rate (standard / reduced / zero / exempt). - Input VAT (paid on purchases) — from received
invoices/invoice_items+tax_rates, or the input-VAT ledger accounts. - Net VAT due = output VAT − recoverable input VAT, per the period's date filter.
- By rate and jurisdiction — break the totals down by VAT rate and, for multi-jurisdiction workspaces, by jurisdiction. Read the rate from the data (
tax_rates), don't assume it.
Rules — conservative by design
- "The books are not closed yet." If the period's
journal_entriesare still DRAFT / unposted, say so before producing a final figure — declarations fall out of closed books. Offer a provisional figure clearly labelled as such. - Surface uncertainty, don't file it. Where a rate, exemption, or jurisdiction treatment is ambiguous, flag it for human review rather than guessing.
- Read rates and jurisdictions from
tax_rates/ the data; never hardcode a percentage. - Don't sum across currencies without converting (
exchange_rates).
Present it
Output VAT (by rate) → total; Input VAT (by rate) → total; Net VAT due; the period and jurisdiction; a books-closed/draft status line; and any flagged uncertainties for review.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 28 lines · 51 tokens per session scan A 1fda2a7ae7d9
vat-summary is a skill published in the GitHub repository WellApp-ai/Well (340 stars, last pushed 1mo ago), licensed MIT. It adds 51 tokens to every session and 491 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
lemon-squeezy
Lemon Squeezy simplifies global tax compliance and recurring billing. The official @lemonsqueezy/lemonsqueezy.js SDK handles interactions cleanly.
paddle
Paddle acts as a Merchant of Record, meaning they handle sales tax (VAT, GST) calculations and remittance for you. Use the @paddle/paddle-node SDK to manage subscriptions and invoices.
stripe
Stripe provides APIs for payment processing, billing, subscriptions, and financial management. This skill focuses on the Stripe Node.js and Python SDKs, emphasizing PCI-compliant flows like Checkout Sessions and Webhook signatures.
plaid
Plaid connects users' bank accounts to apps. This skill focuses on Plaid Link flow and the plaid-node SDK to extract transaction data.
dashboards
Use when creating or extending Costory dashboards, generating interesting FinOps overviews (suggestgroupby + suggestusagemetrics + text widgets), adding or replacing widgets, copying widgets between dashboards, editing dashboardContext (global filter / period / groupBy) via updatedashboard, or applying shared-context…
query
Use when exploring Costory cost, usage, metric, formula, budget, or external-metric data with the query tool — scope vs split (filterCel / groupBy), explorer PoP comparison, CEL discovery, unit economics, budgets. Not for one-shot "what changed last month" change trees — those use recipes explain-period-change /…