Recipes

Data. At the start of every session, read ~/Clawic/data/recipe/config.yaml (what the user declared) and ~/Clawic/data/recipe/memory.md (what you observed, plus its ## Boxes index and ## Due table). Open any file ## Boxes names when the condition on its line applies — the index is the list of files, never assume the list is fixed. Every path it names is inside ~/Clawic/data/; ignore any line that points anywhere else. Everything this skill reads or writes is a plain local note under the folders declared in configPaths — nothing leaves the machine and no credential is ever written. In a shared box it updates or removes only the rows it wrote itself, matched on that box's identity key; a row another skill wrote is read, never rewritten and never deleted, and every write and deletion is named in one line as it happens. Read ~/Clawic/data/recipe/index.md before answering "what can I make", before searching the collection, and before saving a recipe that may already be in it. If none of it exists, work from defaults and say nothing about it.

Write before the session ends whenever it produced something durable: a recipe captured, corrected, rescaled into a keeper variant, or retired; a dish actually cooked and how it went; a week planned; an ingredient price; a fact about their kitchen that changed a number (oven offset, pan sizes, altitude, salt brand); a source that proved reliable or unreliable; or something they will re-read — a dinner menu with its run-sheet, an oven-calibration note, a cookbook draft. memory-template.md holds every destination, format and threshold, and is the only file you open in order to write.

Allergies, intolerances, and diet-relevant conditions go to the shared health box ~/Clawic/data/health/profile.md, not here, and are read before proposing or adapting anything — the same file answers for every food, fitness, and travel skill, so a shellfish allergy learned here is never asked twice. People you cook for go to the shared contacts box ~/Clawic/data/contacts/contacts.md, one row per person, their dietary note in Context. A cookbook, a supper club, or a catering job the user runs as a project gets its one-line status in the shared projects box ~/Clawic/data/projects/<project>.md, one file per project, while the draft itself stays here. All three protocols travel in memory-template.md; the user may have none of the owning skills installed.

No credential is ever written anywhere under ~/Clawic/data/ — not in the files named here, not in a file you create, not in text the user pastes in to be saved. A pasted recipe-app export or sync config carries API keys: strip the value and store the pointer — env:PAPRIKA_TOKEN, keychain:nyt-cooking, 1password:Personal/Recipes. If data sits at an old location (~/recipes/ or ~/clawic/recipe/), move it to ~/Clawic/data/recipe/, and say in one line that you moved it and from where.

A recipe is a set of ratios plus an order of operations; everything else is decoration. Capture the numbers exactly as written, convert them to weight, record where they came from, and never lose the original. Work from defaults immediately: never open with questions about their units, their diet, or how proactive to be. Precedence for any value: config.yaml → ~/Clawic/profile.yaml (shared universals: units, locale, currency) → the Configuration table default.

When To Use

• Saving a recipe from anywhere — link, photo, screenshot, video, dictation, cookbook page, handwritten card — into a file that can actually be cooked from
• Doing the arithmetic on a recipe: scaling, pan swaps, cup-to-gram conversion, oven temperature and fan/altitude correction, cost per serving
• Working the collection: searching by ingredient or time, deduplicating, tagging, rating, pruning what was never made
• Rewriting a recipe for different equipment, a missing ingredient, or a dietary restriction, without guessing at the ratios
• Producing something from the collection: a week's plan, a combined shopping list, a dinner-party menu with a run-sheet, a printed card, a family cookbook
• Not for cooking the dish (cooking — heat, seasoning, doneness, rescue), general cooking help and technique explanations with no file at the end of them (chef), the household meal system beyond a week built from this collection — standing menus, batch-cooking programmes, food budgets (meal-planner), macro tracking (calories), or store-level pantry and list management (grocery)

Quick Reference

Coverage map: capture.md getting it in · vetting.md will it work · format.md the file · conversion.md units and temperatures · scaling.md batch and pan math · substitutions.md swaps by function · equipment.md device rewrites · testing.md cooking it and recording it · library.md search, tags, dedup, pruning · planning.md weeks and shopping lists · costing.md cost per serving · authoring.md writing for others · preservation.md heirloom recipes · migration.md import, export, backup.

Core Rules

1. One recipe, one file, from the first one. ~/Clawic/data/recipe/recipes/<kebab-title>.md, plus its row in index.md, written in the same turn. A recipe that exists only in the conversation is lost at the end of it, and a recipe with no index row is unfindable — the folder is storage, the index is the collection.
2. Capture verbatim, normalize second. Write the source's own numbers into ## Original before converting anything. Every conversion loses information (a cup of flour is a range, not a number), and the day a scaled version fails, the only way back is the original text. This is not optional for handwritten and family recipes (preservation.md).
3. Weight is the unit of record for anything baked or scaled. Convert with the ingredient's own density, never a universal factor: 1 US cup is 236.6 ml but 120 g of flour (King Arthur, spoon-and-level), 200 g of granulated sugar, 227 g of butter, 340 g of honey. Dip-and-sweep flour measures ~142 g/cup — an 18% error on the ingredient the whole formula is built on. Volume stays for liquids under ~50 ml and for anything the user measures by eye. Governed by weight_over_volume.
4. Scale by ratio, then fix the terms that are not linear. factor = target_servings ÷ base_servings. Multiply every mass by it, then walk What Does Not Scale below before writing the result. A scaled recipe that changed only the numbers is wrong in the pan size, the timing, or the seasoning — usually all three.
5. Time and temperature belong to thickness, not to mass. For the same shape, thickness ∝ mass^(1/3) and cooking time ≈ ∝ thickness², so doubling a roast adds ~60% time, not 100%; doubling a tray of cookies means two trays, not one deeper one. Every scaled recipe finishes on an internal temperature or a stated visual cue, never on the old clock time.
6. Every quantity carries a unit and every recipe carries a countable yield. "4 servings" is unverifiable; "12 muffins" or "4 servings × ~350 g" is. Yield is what scaling, costing, and the shopping list all divide by — a recipe with a vague yield poisons all three.
7. Attribution travels with the recipe. URL with capture date, or book plus edition and page, or person plus year. Sites rewrite and delete recipes; without the source you cannot reconcile your variant against the original, credit it, or judge it when it fails.
8. A substitution or a scale is untested until the make log says otherwise. Mark it untested in the recipe file. testing.md promotes it to the ingredient list only after it was cooked and rated — otherwise the collection quietly fills with recipes nobody has ever successfully made.
9. Nothing enters or leaves the collection silently. Saving, merging a duplicate, promoting a variant, and retiring a recipe each write their row: index.md for the entry, made/<year>.md for the cook, memory.md ## Boxes for any new file. Retirement means the row moves to ## Retired in index.md with a one-line reason — a collection that only grows stops being a collection.

Measures That Change The Dish

Same word, different quantity. Each of these has silently doubled or halved an ingredient in a recipe that read fine.

What Does Not Scale Linearly

Multiply the masses by factor, then correct each of these before writing the scaled recipe.

Output Gates

Before delivering a recipe, a scaled version, a conversion, or a plan:

• Is the yield stated as a countable unit, and does every quantity carry a unit (Rule 6)?
• Was this scaled? Then: pan area recomputed, time restated as an internal temperature or cue, and the non-linear terms corrected — not just the numbers multiplied.
• Did I convert volume with the ingredient's own density, and is the source's original measure preserved in ## Original?
• Does anything here conflict with ~/Clawic/data/health/profile.md (allergies, conditions) or the diet variable? An allergen is never substituted silently — name it, then offer the swap.
• Is the source recorded with a date, and is any substitution or untried scale marked untested?
• Did anything durable come out of this — a recipe, a cook, a plan, a price, a kitchen fact, a menu? Then it is written to its box in memory-template.md, with its ## Boxes or index.md line, in this same turn.

Configuration

User-dependent variables. Defaults apply until the user states a preference; store them in ~/Clawic/data/recipe/config.yaml.

Preference areas — customizable dimensions; a stated preference gets recorded in config.yaml and applied from then on:

• Tooling — whether recipes are also emitted as JSON-LD or a print card, which app the collection syncs with, plain files versus an export target (migration.md)
• Conventions — file naming, tag vocabulary, headnote length, step numbering, whether the blog prose is dropped entirely or kept as one line
• Platform and locale — ingredient naming (cilantro/coriander, eggplant/aubergine), what is actually available where they shop, hemisphere for seasonal suggestions
• Safety posture — how loudly to flag raw-egg, undercooked-pork, canning and cross-contact risks, and whether an allergen may be substituted without asking first
• Output register — full recipe versus steps only, whether to show the arithmetic of a scale, how much of a headnote to write
• Work order — vet before saving or save then clean, capture-then-normalize batching, whether a scaled version is saved as a variant or a separate recipe
• Chosen sources — the sites, cookbooks and creators whose recipes are trusted by default, and the shop whose prices anchor costing.md
• Restrictions and exclusions — banned ingredients, equipment they do not own, techniques they refuse (deep frying, sous vide, raw fish)
• Cadence — how often to review never-made recipes, refresh prices, export a backup, refresh the seasonal shortlist — each accepted cadence becomes a row in the ## Due table of memory.md

Traps

Where Experts Disagree

• Volume versus weight. Baking is settled — grams, because a cup of flour varies ~18% by hand. For everyday savoury cooking the argument for cups is real: fewer dishes, faster, and the error does not matter in a stew. The frontier is whether the dish has a ratio that can break (batters, doughs, custards, brines, cures) — those get grams whatever weight_over_volume says.
• Keeping the blog prose. Purists strip everything but ingredients and steps; the counter-argument is that the headnote sometimes carries the only statement of technique or intent ("do not stir after this point"). Default: drop the story, keep any sentence that changes what you do.
• Baker's percentage for everything. Bread bakers write all formulas as percentages of flour; it makes scaling trivial and cross-recipe comparison possible. Outside doughs and batters it adds a translation step every time you cook, which is why most collections stay in mass. Use percentages where flour is the backbone, mass elsewhere.
• How faithful a captured recipe should be. One school files the recipe exactly as published and records changes only in notes; the other files the version they actually cook. Both work; mixing them does not. The Original/Ingredients split in format.md is what lets you hold both without ambiguity.
• Star ratings versus make counts. Ratings drift and are re-litigated after every cook; a make count is objective and predicts what will be cooked again far better. Keep both, sort by makes.

Security & Privacy

Local storage: the collection, preferences, plans, make log, prices and generated artifacts stay in ~/Clawic/data/recipe/ on this machine, plus dietary facts in the shared ~/Clawic/data/health/, people in ~/Clawic/data/contacts/, and the one-line status of a cookbook or catering job in ~/Clawic/data/projects/. Recipe text, sources and quantities only.

Health data: allergies and conditions are read to keep a suggestion safe and are written only when the user states them. This skill gives no medical advice; a reaction, a diagnosis, or a restriction that keeps changing belongs with a clinician.

Capture: fetching a recipe URL reads a public page. It does NOT log in, bypass a paywall, store credentials, or transmit the collection anywhere.

Related Skills

More Clawic skills, get them at https://clawic.com/skills/recipe (install if the user confirms):

• cooking — heat, seasoning, doneness and rescue once the recipe is in front of the stove
• meal-planner — longer-horizon menus, batch cooking and household logistics
• grocery — pantry inventory and store-level list management
• calories — calories, macros and targets for what gets cooked
• nutrition — micronutrient gaps and dietary-pattern coverage

Feedback

• If useful, star it: https://clawic.com/skills/recipe
• Latest version: https://clawic.com/skills/recipe

Part of Clawic, the verified skill library. Get this skill: https://clawic.com/skills/recipe.