feat: add hermes-generated ops skills

skills/hermes-generated/finance-billing-ops/SKILL.md

@@ -0,0 +1,71 @@
+---
+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