Choosing the Right Pricing Model with PRD Skills

Where this fits

You're building an AI assistant that drafts product requirements. Halfway through a v0.3 conversation, the user asks, "What should we charge for this?" Without structured context, the agent guesses. The prd-v03-pricing-model skill steps in at that exact moment, consuming the competitive landscape (CFD-) and product type (BR-) entries already collected in v0.2, then producing concrete pricing rules, tier boundaries, and positioning notes that feed straight into the PRD's commercial model section.

Why agents benefit

• Context-aware pricing recommendations: Instead of generic "try freemium" advice, the agent uses the product type and competitor data to justify a specific model—usage-based, tiered, or value-metric.
• Validation built in: The skill checks willingness-to-pay signals from competitive research, so the agent flags overpriced tiers before the user commits.
• Structured output for downstream workflows: It emits BR- entries that follow the same convention as other v0.3 outputs, meaning moat articulation and KPI tracking can consume pricing data without re-parsing.
• Trigger discipline: It only activates on pricing-related requests, so the agent doesn't derail a planning conversation with unsolicited monetization chatter.
• Reduced hallucination risk: Because it requires prior v0.2 artifacts, the skill forces the agent to ground pricing decisions in actual researched context rather than invented benchmarks.

Practical scenarios

Freemium vs. paid for a dev tool

The user is describing a CLI utility that wraps internal APIs. The agent notices the product type is "developer infrastructure" and competitor data shows most tools succeed with a free tier plus usage-based overage. The skill recommends a freemium structure, tier boundaries at team size thresholds, and a validation note pointing to a competitor's pricing page.

Re-pricing an existing SaaS product

A user says, "We're losing deals on the mid-tier plan." The agent pulls the CFD entries showing the main competitor charges 30% less with nearly identical features. The skill outputs revised tier boundaries, a grandfathering rule for existing customers, and a competitive positioning note that highlights the trade-off between margin and adoption.

Validating a willingness-to-pay hypothesis

The user asks, "Can we charge per seat or per active user?" The skill checks the BR- product type entry—if it's workflow collaboration, per-seat is common; if it's automation, usage-based is more defensible. It then generates a simple pricing rule matrix with caveats for when per-active-user makes sense.

Add it to your agent workflow

Install the skill into your agent's toolkit:

npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v03-pricing-model

After installation, direct your agent to run v0.2 mapping first, then ask something like: "Based on the competitive landscape, what's the best pricing model for our product type?" The agent will read the required BR- and CFD- entries and respond with structured pricing recommendations that you can drop into the PRD. For related skills and community notes, see the skill page.

Compare before adopting

Before committing, compare this skill against alternatives on three axes:

• Quality signals: Does the README clearly define inputs, outputs, and allowed tools? This one does—it names the required artifact types and trigger phrases—so you know exactly when it will fire.
• Maintenance freshness: The skill depends on v0.2 artifacts and a broader PRD workflow. Check if the repository and its companion skills are updated together; stale companion skills will break the pipeline.
• Workflow fit: It only makes sense if you're already using the PRD-driven context engineering convention. For a free-standing pricing agent, a lighter prompt or a dedicated pricing API might be simpler.

Why it is worth tracking

The repository has 182 stars and a clear author-led structure, which suggests real adoption among agents solving product workflows. The skill is worth tracking because pricing decisions are notoriously under-specified in generated PRDs; having a deterministic skill that consumes earlier context and outputs structured rules is a strong pattern. Evaluate it when your agent needs to move from generic feature generation to commercially coherent product documents.