evgenii-studitskikhevgenii-studitskikh/Claude-Code-SaaS-Studio/.claude/skills/design-pricing/SKILL.mddesign-pricing
Skill1 starsChanged 5 months agoMITView on GitHub
Define plans/tiers, metered units, trial period, and upgrade/downgrade rules using the pricing template. Map each plan to Stripe products and prices. Drafts pricing.md then awaits approval.
In this repository22 other files it gives its agents.
- build-featureSkill
- code-reviewSkill
- compliance-checkSkill
- design-architectureSkill
- design-schemaSkill
- design-uiSkill
- helpSkill
- launch-checklistSkill
- map-flowsSkill
- qa-planSkill
- scope-checkSkill
- security-auditSkill
- setup-billingSkill
- setup-deploySkill
- setup-stackSkill
- startSkill
- studio-statusSkill
- test-setupSkill
- threat-modelSkill
- validate-ideaSkill
- write-prdSkill
- write-testsSkill
The file
Files
Design a pricing model that is both commercially sound and implementable with Stripe's product/price/subscription primitives. Non-autonomous: every tier, limit, and Stripe mapping is proposed and confirmed before being written to the spec.
Phases
- Load context — read
docs/specs/prd.mdfor the target user personas and success metrics, anddocs/specs/idea-validation.mdfor willingness-to-pay signals. If neither exists, ask the user to describe the intended audience and rough price sensitivity. - Propose tier structure — suggest 2–4 plan tiers (e.g., Free/Starter/Pro/Enterprise) with names, monthly and annual prices, and the key differentiating limits (seats, usage units, feature gates). Present the tiers as a comparison table. Ask the user to adjust before moving on.
- Define metered units and feature gates — for each tier, specify: which features are gated (boolean), which are metered (unit name, included allowance, overage price), and the upgrade trigger (what makes a user need the next tier). This informs which Stripe Price objects will be
recurringvs.metered. - Design upgrade/downgrade and trial rules — propose: trial length (days), trial-to-paid conversion behavior, proration strategy on plan changes, and what happens to data when a user downgrades below a current-usage limit. Get explicit sign-off on these rules — they have customer-experience implications.
- Map to Stripe objects — for each tier, define the Stripe Product name, Price ID naming convention (e.g.,
price_starter_monthly), billing interval, and any metered price configuration. Note that actual Stripe objects will be created in/setup-billing; this phase produces the spec only. - Write the spec — fill
.claude/templates/pricing.mdintodocs/specs/pricing.md. Underfullreview, present each section; underlean/solo, write after a single confirmation. Next step: point to/setup-billing.
Output
docs/specs/pricing.md — tier definitions, Stripe object mapping, and upgrade/downgrade rules. Writes nothing without approval.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.