Finance billing ops

Skill Lukk17/agent-standards/.agents/skills/finance-billing-ops

One git checkout drops a shared AI coding setup (skills, subagents, MCP servers, OpenSpec scaffolding) into any project, across Claude Code, Kilo, OpenCode, Codex, and Copilot.

Install

npx -y skills add Lukk17/agent-standards --skill finance-billing-ops

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Evidence-first revenue, pricing, refunds, team-billing, and billing-model truth workflow for ECC. Use when the user wants a sales snapshot, pricing comparison, duplicate-charge diagnosis, or code-backed billing reality instead of generic payments advice.

SKILL.md

3.8 KB, as published. Nobody here has run it

Finance Billing Ops

Use this when the user wants to understand money, pricing, refunds, team-seat logic, or whether the product actually behaves the way the website and sales copy imply.

This is broader than customer-billing-ops. That skill is for customer remediation. This skill is for operator truth: revenue state, pricing decisions, team billing, and code-backed billing behavior.

Skill Stack

Pull these ECC-native skills into the workflow when relevant:

customer-billing-ops for customer-specific remediation and follow-up
research-ops when competitor pricing or current market evidence matters
market-research when the answer should end in a pricing recommendation
github-ops when the billing truth depends on code, backlog, or release state in sibling repos
verification-loop when the answer depends on proving checkout, seat handling, or entitlement behavior

When to Use

user asks for Stripe sales, refunds, MRR, or recent customer activity
user asks whether team billing, per-seat billing, or quota stacking is real in code
user wants competitor pricing comparisons or pricing-model benchmarks
the question mixes revenue facts with product implementation truth

Guardrails

distinguish live data from saved snapshots
separate:
- revenue fact
- customer impact
- code-backed product truth
- recommendation
do not say "per seat" unless the actual entitlement path enforces it
do not assume duplicate subscriptions imply duplicate value

Workflow

1. Start from the freshest billing evidence

Prefer live billing data. If the data is not live, state the snapshot timestamp explicitly.

Normalize the picture:

paid sales
active subscriptions
failed or incomplete checkouts
refunds
disputes
duplicate subscriptions

2. Separate customer incidents from product truth

If the question is customer-specific, classify first:

duplicate checkout
real team intent
broken self-serve controls
unmet product value
failed payment or incomplete setup

Then separate that from the broader product question:

does team billing really exist?
are seats actually counted?
does checkout quantity change entitlement?
does the site overstate current behavior?

3. Inspect code-backed billing behavior

If the answer depends on implementation truth, inspect the code path:

checkout
pricing page
entitlement calculation
seat or quota handling
installation vs user usage logic
billing portal or self-serve management support

4. End with a decision and product gap

Report:

sales snapshot
issue diagnosis
product truth
recommended operator action
product or backlog gap

Output Format

SNAPSHOT
- timestamp
- revenue / subscriptions / anomalies

CUSTOMER IMPACT
- who is affected
- what happened

PRODUCT TRUTH
- what the code actually does
- what the website or sales copy claims

DECISION
- refund / preserve / convert / no-op

PRODUCT GAP
- exact follow-up item to build or fix

Pitfalls

do not conflate failed attempts with net revenue
do not infer team billing from marketing language alone
do not compare competitor pricing from memory when current evidence is available
do not jump from diagnosis straight to refund without classifying the issue

Verification

the answer includes a live-data statement or snapshot timestamp
product-truth claims are code-backed
customer-impact and broader pricing/product conclusions are separated cleanly

Gives 0 of the 12 instructions most ship operate skills give

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-06

document a rollback plan before deploymentin 40 of 779, across 21 files
create an annotated git tagin 21 of 779, across 20 files
Run the test suitein 20 of 779
update the changelogin 20 of 779, across 18 files
verify deployment health after launchin 19 of 779, across 10 files
clean up feature flags after full rolloutin 18 of 779, across 10 files
verify the working tree is cleanin 18 of 779
test both feature flag statesin 17 of 779, across 9 files
Make database migrations backward-compatiblein 16 of 779, across 8 files
set up error monitoring before launchin 15 of 779, across 7 files
monitor metrics at each rollout stagein 14 of 779, across 5 files
create a github releasein 14 of 779

Said here and by no other author read

pull relevant native skills into the workflow
prefer live billing data over snapshots
state the snapshot timestamp if data is not live
classify customer-specific incidents first
inspect the code path for implementation truth
separate customer impact from product truth

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.