recipe-cost-calculator

Recipe Cost Calculator — market menu manager

This skill is a standing assistant for someone who sells baked/cooked goods at a recurring farmers market. It maintains a growing local library (SQLite) of:

• ingredients + purchase prices (cost per gram/ml/each, latest purchase wins),
• recipes (measured the way the user writes them — cups/tbsp/tsp/each),
• one or more event profiles = overhead assumptions (booth fee, labor); one is marked default and supplies the overhead baseline for every good,
• products = the standing menu: a recipe + the price you charge + your rating (high/mid/low popularity) + packaging/tags.

For each product it shows two independent signals: margin (computed from cost vs. your price) and rating (popularity you set by hand). All math runs in the bundled scripts/market_calc.py (standard-library Python, no install, no server). Never compute prices by hand.

Running the script

python3 "<skill_dir>/scripts/market_calc.py" <command> [flags]

<skill_dir> is the folder this SKILL.md lives in. Run commands from the user's working folder so the database and config resolve to their project. Full command list: references/commands.md.

Step 0 — Locate the library (do this first, every run)

The DB location is stored in .recipe-cost-calc.json in the working folder, so the user is asked only the first time.

1. Run ... where.

2. Prints a path → that's the library; continue.

3. Errors "No database configured" → first run. Ask where to keep data:

   "Where should I keep your market library? I'd suggest ./.data/ in this folder — press enter to accept, or give me another path."

   Then ... setup --db ./.data/market.db (or their path). It writes the config and an empty library; don't ask again.

Routing — pick the workflow that matches the request

This is an assistant, not a single pipeline. Identify intent and jump to the right section. When in doubt, run ... list-products to see the current menu.

The user wants to…	Go to
Price/cost a recipe, add a new good to the menu	A. Add a good
See the menu with costs, prices, margins	... list-products
Record how a good sold / set popularity	B. Rate a good
Decide what to make more/less of	... review
Log a price change or new purchase	C. Update costs
Set up / change their market overhead	D. Manage events

A. Add a good (recipe → cost → price → save)

1. Get the recipe. From a URL, fetch and extract ingredients, quantities, and yield (units it makes). If yield isn't stated, ask — cost per unit needs it. From text, parse directly.
2. Check the library. ... list-ingredients. Match each ingredient semantically ("flour" → the user's "Gluten-Free 1-to-1 Flour"). Note which have a density.
3. Fill missing ingredients. For each one not in the library:
   • Ask whether they have it and what brand (photo or description ok). Batch these questions.
   • If no brand preference, pick a product matching the recipe's character (organic / GF / vegan, inferred from their library) and say so.
   • Web-search a current price and package size. Add with add-ingredient (base unit g dry/solid, ml liquid, each count), then add-purchase with the package quantity + price. Mark estimates: --brand "(est.) Brand". Use --tags for descriptors (organic, allergen, supplier).
4. Backfill densities for anything measured by volume whose density is empty. Check references/ingredient-weights.md first; else web-search grams/cup and update-ingredient "<name>" --density-g-per-ml <g_per_cup / 236.588>.
5. Save the recipe in the units as written: ... add-recipe --name "<r>" --yield <N> --yield-unit <u> --item "<Ing>:<qty>:<unit>" ... Show ... cost-recipe "<r>" and sanity-check per-line and per-unit cost.
6. Suggest a price, then confirm what they'll charge. Run ... suggest-price "<r>" --method <markup|margin> --value <pct> to show cost (incl. default overhead) and a suggested price. The user usually rounds it to a clean number. Confirm the price they'll actually charge.
7. Create the product with that price: ... add-product --name "<good>" --recipe "<r>" --sell-price <price> [--packaging <p>] [--tags <t>] then show ... price-product "<good>" (cost / price / margin / rating).

Save the recipe automatically; confirm the sell price before creating the product. Rating starts unset — it's earned at market (workflow B).

B. Rate a good (popularity)

When the user reports how something did ("the peach cookies sold out," "nobody bought the muffins"), set the rating — your high/mid/low signal, separate from margin: ... update-product "<good>" --rating <high|mid|low>

C. Update costs (prices change)

• New/updated ingredient price: ... add-purchase ... (cost uses the latest purchase automatically; margins update everywhere).
• Change a sell price: ... update-product "<good>" --sell-price <new>.

D. Manage events (overhead baseline)

Overhead (booth fee, labor, other costs) is spread over expected units sold to get per-unit overhead, which folds into every good's cost.

• Show profiles: ... list-event-profiles (the default is marked *default*).
• Create the user's weekly market and make it the baseline: ... add-event-profile --name "<market>" --expected-units <N> [--booth-fee <$>] [--labor-hours <h>] [--labor-rate <$/h>] [--other-costs <$>] [--location <loc>] --default
• Switch baseline: ... set-default-event "<market>".
• If no default is set, goods show margin against ingredient cost only — flag this to the user and offer to set up their market.

Notes & guardrails

• The DB is the source of truth; the script keeps unit conversion and math correct. Don't replicate calculations in your head.
• Two signals, don't conflate them: margin is computed economics; rating is popularity the user reports. A high-margin good can be low-rated and vice versa — surface both.
• Don't pollute the library with non-food items; ask before adding anything that isn't really an ingredient.
• A volume→mass conversion with no density errors with the ingredient name — that's your cue to backfill its density.
• Round only when presenting or when setting a sell price the user confirms; never feed rounded numbers back into cost math.