Autumn Catalog

Catalog

Before using this skill, first load the autumn-concepts skill — it defines Autumn's data model — features, plans, plan items, balances — which every modeling decision builds on.

STRICT RULES — re-read before every config write

1. Amounts are in major units (e.g. dollars), never minor units (cents). $180/month is amount: 180. $0.01 per credit is amount: 0.01. If any amount you wrote is 100× the user's number, it is wrong.
2. Never invent a price, limit, or plan name — a missing number is a question.
3. One definition per real thing. One feature per resource, one child plan per license pattern (parents customize their license, never get their own copy), one add-on per offer (sizes are tiers, not plans).

Building, or iterating on a live catalog? What matters is whether customers are on these plans — not whether a config file exists. Still setting up (even across sessions, with a half-built autumn.config.ts) → the workflow below; edit the draft freely. Already running Autumn with customers, now changing prices/plans → that's an update with real stakes (versioning, migrations, grandfathering) — read references/catalog-update.md first. Unsure → check for customers (atmn pull / the org) or ask.

Turning pricing into a catalog is two jobs:

• Shape — decide the structure: which plans exist, what's a variant, what's an add-on, where balances live. Decided by relationships in their pricing, not by amounts.
• Fill — put in the numbers and per-item details, then write and validate the config.

Do Shape fully before Fill. Take numbers whenever the user mentions them, but never chase numbers during Shape — the one exception is "is this the same on every plan?", which is a structure question.

Progress (what the user sees)

Copy this checklist into your first message and keep it up to date. It is the only structure the user ever sees — never say "step", "pass", "decide", or "fork" to them. If you skip an item, say why in one line.

• 1 Your plans and prices
• 2 What's included in each plan
• 3 How billing behaves (signup, trials, limits)
• 4 Licenses — paid seats, workspaces, projects (if any)
• 5 Structure agreed
• 6 Config written and checked

How to ask

• One topic per message. Two questions at most, and only if both belong to that topic. Never mix topics in one message.
• If one ambiguity changes which other questions apply, resolve it first before asking those.
• Attach your guess to each question — "does the trial need a card? I'd guess no" — a wrong guess gets corrected faster than a blank gets answered.
• Assert the obvious instead of asking. "500 messages a month" resets monthly — state it as an assumption, don't ask. Questions are only for facts that change the structure and can't be guessed.
• Skip anything they already told you. A good message to answer is a nod, not homework.
• Never announce what you'll do next ("once I get those three, I'll restate…") — just work the current topic.
• The restate (step 5) is the safety net: wrong assumptions get caught there cheaply, which is what makes fewer questions safe.

Shape: collect, then decide

Work the four steps below in order, one at a time — each says when it's done. While collecting, make only the small calls each step allows; leave the big ones (marked ↦ Decide) for after.

Step 1 — Plans

• What are the plans? ("Free, Pro $20/mo, Growth $50/mo")
• Free tier? → a plan with no price that every new customer starts on automatically.
• Anything bought alongside a plan rather than instead of it (packs, extra storage)? → note it ↦ Decide (add-on).
• Enterprise tier? Ask. If it exists, model the base enterprise plan in the catalog, and tell the user: custom terms per customer (special prices, custom limits) are applied later when attaching, not modeled here.

Done when you can list every plan they sell, including free, add-ons, and enterprise.

Step 2 — What each plan includes

Have them describe what they charge for or limit, in their own words. Pick a type per feature:

Note top-ups ("buy more when you run out", "auto-recharge") ↦ Decide (top-up placement).

Step 3 — How billing behaves

This step usually means explaining Autumn to the user in plain words. Do.

• Signup: every new customer automatically gets the default plan — usually the free one. One default per group. A default can carry no prices at all — a "$0" plan with paid items (per-seat charges, prepaid packs) is a paid plan, not a default. If every plan bills something, there is no default; customers subscribe.
• Trials: ask "does the trial need a card?" (guess from their motion — PLG usually no). Card → free_trial on the paid plan. No card → a separate free trial plan (pro_trial: no price, the paid plan's items, auto-enabled when everyone starts on it); the paid plan stays untouched, since a default plan can never be paid. For trial modeling details — trial-behavior on plans, read references/plan.md in the autumn-concepts skill.
• What is a plan attached to? The customer, or each thing they own (workspace, project, site)? "Pro is $200 per workspace" → attached per entity. Pin this down — it changes everything downstream.
• Who uses each metered feature? The customer as a whole, or each entity? If entities: one shared balance or separate ones? "Shared across…" → shared ↦ Decide (balances).

Done when you know what attaches where, who consumes what, and how trials and signup work.

Step 4 — Licenses

Triggered whenever the customer pays per unit of some entity — seats, workspaces, projects, sites, members: "each X is $10/month", "comes with 3 X". When you see one, always ask: what does one X come with? Never skip this because the user didn't say "seat". For modeling a license — the concept: child plan, license link, customize, read references/licenses.md in the autumn-concepts skill.

• Nothing of its own ("$10 per seat", just a count) → a per-unit priced item on the plan. No entities. The common case.
• The unit gets something of its own ("each seat gets 100 credits", "every workspace has its own allowance") → a license: a small plan of its own that the parent plan hands out per unit.
• Units must be assigned, reassigned, or sit empty → also licenses. Rare — confirm they need it.

For deciding between a per-unit item, licenses, and entity-attached plans for a countable paid unit, read references/fork-licenses.md.

Before deciding: restate

Only after your questions are answered — never announce it in advance, and never restate facts nobody has confirmed yet. One short message: the plans, what's metered, what attaches where, who shares what. Let the user correct it. A wrong fact here is much cheaper than a wrong structure later.

If the user gave you everything up front and you asked nothing, skip the separate restate — the structure message (checklist item 5) does that job.

Decide

Resolve these with all facts in hand. Each has a default — when the facts genuinely don't settle it, show both options in one line each and ask.

Variant or separate plan? A variant can change the price, swap items in or out, and change the trial — nothing else.

• "Pro monthly / Pro annual, same features" → variant. (Annual usually still resets allowances monthly — billing and reset intervals are independent. Confirm.)
• Volume buckets/tiers — one question decides: is each bucket the subscription itself (→ a variant per bucket) or a purchase on top of one (→ a prepaid item)?
• Different features per tier → separate plans. One plan per tier is normal, not a smell.

For deciding whether volume buckets/tiers are variants of the plan or one prepaid volume-tiered item — the tells, the trap, when variants are forced, read references/fork-variants.md.

Add-on, or part of the plan? Two independent questions: is the purchase priced/bundled per plan (→ item on each plan) or one offer across plans (→ one add-on plan, sizes as tiers on its prepaid item)? And does a plan exist at the level its balance is shared at (→ item there) or are all plans entity-attached (→ a customer-level add-on is forced)? Auto-recharge needs the prepaid item to exist — add it in Shape, it's structural.

For modeling packs, top-ups, or any purchase bought on top of a plan — add-on vs plan item, and what level it sits at, read references/fork-addon.md.

Where do balances and purchases live? The rule: purchases and balance at the customer; usage tracking and caps at the entity. Grants "shared across…" entities → pooled (pooled: true on the item); separate per-entity balances → no pooling; overage stays on the entity's plan either way.

For deciding where balances and purchases live — pooled grants, per-entity balances, customer-level packs, overage placement, read references/fork-pooled.md.

Groups? Can one customer hold two plans at once from different lines (a support plan AND a sales plan)? → one group per line. Within a group, attaching a plan replaces the current one; that's what makes upgrades work.

One-off? "Lifetime deal", "one-time pack" → a plan with a one-off price: single invoice, no subscription, balances never reset.

Check

Compare the structure against the shapes in references/cases.md. If their pricing matches a known shape but your structure differs, either say why or fix it.

Shortcuts that are usually wrong — catch yourself before Show:

For checking the derived structure against known-good shapes, read references/cases.md.

Show

Present the structure in the "Showing the catalog" format below — the same one used for every catalog display, catalog inside a fenced code block. Numbers you don't have yet stay open, never invented: write the line without them ("AI messages per month — amount TBD"). Structure notes go in parentheses on the line they describe. The whole message:

Here's the structure I'd build:

```
Features: AI credits (credit system — chat and image messages draw from it) · SSO (on/off)

Free — no price, everyone starts here
  - 100 AI credits per month
Pro — $20/month, or annual (same features)
  - AI credits per month — amount TBD
  - SSO
Credit pack (add-on) — price TBD, shared across all workspaces
```

I assumed: credits reset monthly, no rollover. Anything wrong?

List every assumption. Get a clear yes — "sounds good" without reading is not a yes. But if the user already told you to go ahead without review ("no need to ask", "just build it"), show the structure and keep going — don't stop to wait. If a late fact changes the structure, redo the affected decision, update the structure, and show what changed in one line.