القائمة
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.
| name | finance-billing-ops |
| description | 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. |
| origin | ECC |
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.
Pull these ECC-native skills into the workflow when relevant:
customer-billing-ops for customer-specific remediation and follow-upresearch-ops when competitor pricing or current market evidence mattersmarket-research when the answer should end in a pricing recommendationgithub-ops when the billing truth depends on code, backlog, or release state in sibling reposverification-loop when the answer depends on proving checkout, seat handling, or entitlement behaviorPrefer live billing data. If the data is not live, state the snapshot timestamp explicitly.
Normalize the picture:
If the question is customer-specific, classify first:
Then separate that from the broader product question:
If the answer depends on implementation truth, inspect the code path:
Report:
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
Instinct-based learning system that observes sessions via hooks, creates atomic instincts with confidence scoring, and evolves them into skills/commands/agents. v2.1 adds project-scoped instincts to prevent cross-project contamination.
Orchestrate building a brand-new feature end to end — research, plan, TDD implementation, review, and gated commit — by delegating each phase to the matching ECC agent. Use when adding a capability that does not exist yet.
Orchestrate bootstrapping a working MVP from a design or spec document — ingest the doc, plan thin vertical slices, scaffold the first end-to-end slice, then TDD-implement, review, and gated commit. Use to turn an SDD/PRD into a running starting point.
Orchestrate altering an existing, working feature to new desired behavior — update its tests to the new spec, change the implementation to match, review, and gated commit. Use when behavior is not broken but should be different.
Orchestrate fixing a bug — reproduce it as a failing regression test, fix to green, review, and gated commit — by delegating each phase to the matching ECC agent. Use when existing behavior is broken or wrong.
Shared orchestration engine for the orch-* skill family. Defines the gated Research-Plan-TDD-Review-Commit pipeline, the size classifier, the agent map, and the two human gates that the orch-* operation skills delegate to. Not usually invoked directly.