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.