Stripe Dunning, Seats, and Portal Fixes

What it does

/billing-fix is a Cursor slash command. Type it in chat to run a saved workflow: Stripe Dunning, Seats, and Portal Fixes.

Fixes billing edge cases after Stripe checkout exists. Does not change live prices without confirmation.

Failed cards, proration, seats, customer portal. Unlike a skill, a command is something you invoke on purpose. The agent does not decide to run /billing-fix for you.

Why it exists

Founders retype the same multi-step prompt until it rots. /billing-fix exists so the pipeline, all 4 steps of it, is a file in .cursor/commands, versioned with the repo.

It ships in the Engineering Kit. It is wired to Billing & Dunning Engineer (billing-engineer), Transactional Notifications Engineer (notifications-engineer), and Third-Party Integration Lead (integration-engineer). Required skills: Billing Dunning, Seats & Portal; Stripe Subscriptions & Webhook Handling; SaaS Architecture Patterns & Multi-Tenancy.

When to use it

• Use for payment_failed, bad proration, seat math, or a broken customer portal.
• Use /billing-fix when you want that pipeline, not a freeform chat. If you only need one step, use a narrower command or a single agent.
• Start a new chat. Do not run this command in a thread that just wrote marketing copy.

When not to use it

• Do not run /billing-fix as a substitute for reading the diff. The command produces files; you still gate them.
• Do not chain it into a 40-turn chat. Fresh context is part of the design.
• Do not run it if you have not filled CURSOR.md. The pipeline will invent a stack.

Example workflow

1. billing-engineer maps the Stripe event to current handlers
2. Patch webhook + data model idempotently
3. notifications-engineer drafts dunning copy if missing
4. Write docs/billing/fix and a test for the event

Example usage

Type this in Cursor chat: /billing-fix invoice.payment_failed should email and retry, not silent churn

The command file tells the session which agents to adopt and which skills to read. You should see phase headers, not a single dump of code.

If a phase fails its gate, stop. Do not add 'just continue'.

Example output

• Expected artifact: docs/billing/fix-....md
• Expected artifact: src/app/api/webhooks/stripe/route.ts

Best practices

• Keep the prompt specific. /billing-fix invoice.payment_failed should email and retry, not silent churn is the shape: object, constraint, and outcome.
• Let the listed agents work in order: billing-engineer → notifications-engineer → integration-engineer.
• Save outputs in the repo. Chat-only answers evaporate.
• Engineering commands should leave tests or an audit note, not only implementation files.

Common mistakes

• Typing /billing-fix with no object ('do the thing'). The pipeline will guess.
• Re-running the command in the same chat after a failed gate instead of fixing the failing file.
• Editing the command file to skip review so it 'goes faster'.
• Skipping the Billing Dunning, Seats & Portal skill that the command depends on.