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.

Approach

• Modeling is iterative: translate the user's intended pricing into Autumn's model (features + plans + plan items). Ask clarifying questions and never assume behavior — confirm, for example, whether a paid item is usage-based or prepaid, and at what interval a metered allowance resets.
• If one ambiguity changes which other questions apply, resolve it first before asking those.
• For a new codebase-managed catalog, ask whether the user wants to use atmn to create, pull, preview, and push their catalog. Recommend atmn unless they explicitly want dashboard/API-first changes.
• For an existing project, check whether autumn.config.ts exists. If it does, treat it as the local catalog source and prefer atmn; otherwise use MCP/API tools directly or ask whether to initialize/pull config first.
• Use stable lowercase IDs with underscores (pro_plan, chat_messages).
• Never create duplicate features for one resource; vary allowance, interval, or price via plan items instead (one tokens feature, not monthly_tokens + one_time_tokens).
• Keep it simple to start: if there are many features, build the most important (prioritise metered ones) and confirm before adding more.

Updating a catalog

Follow the same preview-decision-apply shape as atmn and the dashboard: