From pricing-monetization
Design good-better-best packaging where each tier is fenced by a self-selection dimension (scale, use case, support, security) rather than a longer feature list, and separate core from add-ons. Reach for this when turning a feature set into tiers, when customers all pick the cheapest plan, or when tiers differ only by feature count. Pairs with value-metric-design.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pricing-monetization:packaging-and-tieringThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Packaging turns a value metric and a feature set into the plans a customer chooses
Packaging turns a value metric and a feature set into the plans a customer chooses between. Done right, customers self-select into the tier that fits them. Done wrong (tiers separated only by a longer feature list), customers learn to wait for the cheap plan to grow the feature.
Fencing is the whole game. A tier boundary must be a dimension the customer self-selects on — scale, use case, support level, or security/compliance — not just "more features." If you can't name the fence, the tier isn't a tier.
Choose 1–2 dimensions customers naturally differ on:
Features only some customers value belong as add-ons, not as a reason to spawn a fourth tier. Add-ons let you monetize the long tail without complicating the core ladder.
A visible enterprise/"contact us" tier reframes the middle as reasonable — but only with a real fence behind it (custom security, volume, SLA). "Contact us" to hide a number you haven't decided is a tell, not a strategy.
A tier table (tier × fence × included value-metric allowance × key features), the
add-on list, and the self-selection logic — i.e. why each target customer lands in
the tier you intend. Hand WTP validation of the tier prices to
willingness-to-pay-research.
npx claudepluginhub mcorbett51090/ravenclaude --plugin pricing-monetizationGuides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Enforces test-driven development: write failing test first, then minimal code to pass. Use when implementing features or bugfixes.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.