mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-03-30 13:43:26 +08:00
72 lines
4.1 KiB
Markdown
72 lines
4.1 KiB
Markdown
---
|
|
name: finance-billing-ops
|
|
description: Evidence-first Stripe sales, billing incident, and team-pricing workflow for Hermes. Use when pulling sales, investigating duplicate charges or failed payments, checking whether team billing is real in code, or benchmarking pricing.
|
|
metadata:
|
|
hermes:
|
|
tags: [generated, finance, billing, stripe, pricing, workflow, verification]
|
|
---
|
|
|
|
# Finance Billing Ops
|
|
|
|
Use this when the user asks about Stripe sales, refunds, failed payments, duplicate charges, org or team billing behavior, pricing strategy, or whether the product logic matches the marketing copy.
|
|
|
|
## Skill Stack
|
|
|
|
Pull these imported skills into the workflow when relevant:
|
|
- `market-research` for competitor pricing, billing models, and sourced market context
|
|
- `deep-research` or `exa-search` when the answer depends on current public pricing or enforcement behavior
|
|
- `search-first` before inventing a Stripe, billing, or entitlement path
|
|
- `eval-harness` mindset for exact status reporting and separating proof from inference
|
|
- `agentic-engineering` and `plankton-code-quality` when the answer depends on checked-in ECC billing or entitlement code
|
|
|
|
## When To Use
|
|
|
|
- user says `pull in stripe data`, `any new sales`, `why was he charged`, `refund`, `duplicate charge`, `team billing`, `per seat`, or similar
|
|
- the question mixes revenue facts with product truth, for example whether team or org billing is actually implemented
|
|
- the user wants a pricing comparison against Greptile or similar competitors
|
|
|
|
## Workflow
|
|
|
|
1. Start with the freshest revenue evidence available:
|
|
- if a live Stripe pull exists, refresh it first
|
|
- otherwise read `/Users/affoon/.hermes/workspace/business/stripe-sales.md` and `/Users/affoon/.hermes/workspace/business/financial-status.md`
|
|
- always report the snapshot timestamp if the data is not live
|
|
2. Normalize the revenue picture before answering:
|
|
- separate paid sales, failed attempts, successful retries, `$0` invoices, refunds, disputes, and active subscriptions
|
|
- do not treat a transient decline as lost revenue if the same checkout later succeeded
|
|
- flag any duplicate subscriptions or repeated checkouts with exact timestamps
|
|
3. For a customer billing incident:
|
|
- identify the customer email, account login, subscription ids, checkout sessions, payment intents, and timing
|
|
- determine whether extra charges are duplicates, retries, or real extra entitlements
|
|
- if recommending refunds or consolidation, explain what product value the extra charges did or did not unlock
|
|
4. For org, seat, quota, or activation questions:
|
|
- inspect the checked-in billing and usage code before making claims
|
|
- verify checkout quantity handling, installation vs user usage keys, unit-count handling, seat registry or member sync, and quota stacking
|
|
- inspect the live pricing copy too, so you can call out mismatches between marketing and implementation
|
|
5. For pricing and competitor questions:
|
|
- use `market-research`, `deep-research`, or `exa-search` for current public evidence
|
|
- separate sourced facts from inference, and call out stale or incomplete pricing signals
|
|
6. Report in layers:
|
|
- current sales snapshot
|
|
- customer-impact diagnosis
|
|
- code-backed product truth
|
|
- recommendation or next action
|
|
7. If the user wants fixes after diagnosis:
|
|
- hand the implementation path to `agentic-engineering` and `plankton-code-quality`
|
|
- keep the evidence trail so copy changes, refunds, and code changes stay aligned
|
|
|
|
## Pitfalls
|
|
|
|
- do not claim `new sales` without saying whether the data is live or a saved snapshot
|
|
- do not mix failed attempts into net revenue if the payment later succeeded
|
|
- do not say `per seat` unless the code actually enforces seat behavior
|
|
- do not assume extra subscriptions increase quotas without verifying the entitlement path
|
|
- do not compare competitor pricing from memory when current public sources are available
|
|
|
|
## Verification
|
|
|
|
- the answer includes a snapshot timestamp or an explicit live-pull statement
|
|
- the answer separates fact, inference, and recommendation
|
|
- code-backed claims cite file paths or code areas
|
|
- customer-impact statements name the exact payment or subscription evidence they rely on
|