agentleFS
CharleneTStrainCharleneTStrain/product-ops-skills/skills/pricing-packaging-change-log/SKILL.md

pricing-packaging-change-log

Skill0 starsChanged 18 days agoMITView on GitHub

Keep a dated record of every pricing and packaging change — what changed, which plans and customers it affects, when it took effect, who approved it, and who was told — so sales, support, finance, and billing all work from the same current version. Use when someone is making or documenting a pricing change, moving a feature between plans, updating plan limits, asks "what did this plan include last year," or needs to check that a change reached every team and system.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before and after must be specific enough to check against billing.

    line 33
  2. Distinctive:

    If the effective date, who it applies to, or grandfathering isn't stated, flag it.

    line 34
  3. Distinctive:

    When asked what a plan included on a past date, read the log in date order up to that date and answer with the plan's state then, citing …

    line 57
  4. Distinctive:

    Never change prices, plans, or billing settings yourself.

    line 73

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Pricing and packaging change log

Pricing changes touch more places than almost any other change: the website, billing, contracts, sales decks, help docs, in-app limits. The log makes sure each change is recorded once and carried everywhere.

Before you start

If .agents/product-ops-context.md exists (or .claude/product-ops-context.md), read it first. Use the team, owners, tools, meetings, and metric definitions it already has, and only ask for what's missing or specific to this task. If it doesn't exist, go ahead with what you're given, and suggest running product-ops-context once so the next skill doesn't have to ask.

Step 1: Log the change

### [Short title, e.g. "Advanced reporting moves from Pro to Business"]
- **Effective date:** [date]
- **Type:** Price change / Feature moved between plans / Limit change / New plan / Plan retired / Discount or promo policy
- **What changed:**
  - Before: [plan, price, limit, or inclusion]
  - After: [plan, price, limit, or inclusion]
- **Applies to:** New customers / Existing customers at renewal / All customers immediately
- **Grandfathering:** [who keeps the old terms, and until when]
- **Approved by:** [person]
- **Reason:** [as given]
- **Source:** [link to decision, deck, or doc]

Rules:

  • Before and after must be specific enough to check against billing.
  • If the effective date, who it applies to, or grandfathering isn't stated, flag it. These are the three things that cause the most customer disputes.
  • Record the change as decided. Proposals stay out of the log until approved.

Step 2: Track the rollout

For each change, check every place it has to land:

WhereUpdated?OwnerDate
Pricing page
Billing system / plan configuration
In-app limits or feature gates
Order forms and contract templates
Sales deck and pricing calculator
Help center and plan comparison
Support macros
Internal enablement brief
Existing customer notice (if applicable)

A change isn't done until every row that applies is Yes.

Step 3: Answer "what did this plan include?"

When asked what a plan included on a past date, read the log in date order up to that date and answer with the plan's state then, citing the entries used. If the log doesn't go back far enough, say so.

The log

# Pricing and packaging change log

| Date | Change | Plans affected | Applies to | Approved by | Rollout complete? |
|---|---|---|---|---|---|

[Full entries below, newest first]

## Open rollouts
- [Change]: still missing [where] — Owner: [name]

Never change prices, plans, or billing settings yourself. This skill records and tracks.

Related skills

  • internal-enablement-brief — brief sales and support on the change
  • decision-log — record who approved it and why
  • deprecation-plan — when a plan is being retired

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.