FoxeraKnow what every dish costs before you plate it: 10 AI skills for recipe costing
portion-spec-sheet
write the spec that makes sure what's on the plate matches what's on the menu
How the two work together
Claude thinks it through. Paste the Claude prompt into Claude Code, or drop the folder into your skills folder. Claude does the judgement: what to look for, what is worth doing, what is right.
Codex gets it done. At the hand-off point Claude runs Codex on your machine with one command and passes it the Codex prompt. Codex does the mechanical part and hands the result back. Claude checks it before you see it.
No API key to set up: Claude calls the Codex you already have installed. If Codex is not installed, Claude does that half itself and tells you.
Prompt for Claude
--- name: portion-spec-sheet description: Writes the portion spec fixing exactly what a dish weighs, contains and looks like at the pass, so the menu matches what's actually served. It checks any weight, size or quantity claim against the spec, because a false quantity claim is a named offence, not a style choice. Use before any dish naming a weight, size or count goes on a menu, and whenever a spec changes. --- # The spec that makes sure the plate matches the menu Give this a dish's menu description and its actual recipe quantities. Get back a portion spec with a target weight, a tolerance, and a flag on any menu wording claiming more than the spec can reliably deliver. ## What it does 1. **Pull every quantity or weight claim from the menu wording**, verbatim: "8oz steak", "half a chicken", "6 tiger prawns". A commercial practice is misleading if it "contains false information" about "quantity" or "composition" (Consumer Protection from Unfair Trading Regulations 2008, regulation 5(2)(a), 5(4), 5(5)), even "if the information is factually correct" where it still deceives. 2. **Set the spec's target from the recipe**, not the wording; the recipe should produce the claim, never the reverse. 3. **Set a tolerance the kitchen can actually hit** (e.g. ±10g on a weighed protein), as a real figure. No tolerance means unenforceable the first time a portion is light. 4. **Flag any wording the recipe can't support.** "8oz steak" against a 180g (6.3oz) spec isn't rounding, it's a false claim. Real precedent: one venue was convicted on "four charges under the Food Safety Act and one under the Consumer Protection from Unfair Trading Regulations 2008", total cost £7,430, 13 November 2017. 5. **Record who signed the spec off and when**, so a dispute over plating has a dated answer. ## Then it checks 1. Every weight, size or count claim is listed and matched against a spec line. 2. No spec target is lower than the menu claim; any mismatch is flagged, never quietly rounded in the menu's favour. 3. A tolerance is recorded for every weighed or counted item. 4. The spec states the recipe source it was built from, so it can be re-checked if the recipe changes. 5. Every flagged mismatch names the exact wording and the exact spec figure it conflicts with. Any check fails: redo once. Failed twice: say what is wrong and stop. ## Rules - Public information only. Never invent a fact, number or quote, or a spec weight not derived from the recipe. - Anything sent in someone's name says whose name it is. - Never write menu wording to match a spec retroactively without flagging that the menu, not the kitchen, changed. - Never treat a tolerance as licence to serve below the lower bound as standard practice. - Working document for the owner to check against their recipes and menu wording, and a solicitor or trading standards adviser on a genuinely borderline claim. Not legal advice. ## Built from - Consumer Protection from Unfair Trading Regulations 2008, regulation 5, https://www.legislation.gov.uk/uksi/2008/1277/made, SI 2008/1277, read 4 November 2026: 5(2)(a), 5(4), 5(5), quantity/composition as main characteristics, step 1. - Morning Advertiser, "False menu descriptions costs venue £7K", https://morningadvertiser.co.uk/Article/2017/11/13/False-menu-descriptions-costs-venue-7K, published 13 November 2017, read 4 November 2026: a real enforcement case, step 4.
Prompt for Codex
# portion-spec-sheet ## You are given A dish's exact current menu description, verbatim. The dish's recipe, with ingredient quantities and portion yield. Any existing portion spec on file. The name and date of whoever signs off a new or changed spec. ## Produce Write into a `./portion-spec-output/` folder: 1. `menu-claims.csv`: `dish_name`, `claim_text_verbatim`, `claim_type` (`weight`, `count`, `size_descriptor`, `preparation_descriptor`), `claim_value`, `claim_unit`. One row per distinct claim found. 2. `portion-spec.csv`: `dish_name`, `spec_item`, `target_weight_or_count`, `unit`, `tolerance`, `recipe_source_ref`, `signed_off_by`, `signed_off_date`. One row per weighed or counted component. 3. `claim-vs-spec-check.csv`: `dish_name`, `claim_text_verbatim`, `claim_value`, `spec_target_value`, `supportable` (`yes` if the spec meets or exceeds the claim within normal rounding, `no` if it falls short), `gap` (the shortfall in the claim's own unit, or `none`). 4. `gaps.md` - numbered list of: every `supportable: no` row; every spec item with no tolerance; every menu claim with no matching spec item; any spec with no sign-off name or date. ## Rules - Codex extracts claims, builds the spec from the recipe, and checks one against the other. It never invents a spec target not derived from the recipe, and never adjusts a menu claim to match a spec without flagging that the menu, not the kitchen, needs to change. - Claims in `menu-claims.csv` are pulled verbatim; none summarised or paraphrased. - `supportable` is never `yes` where the spec falls below the claim; a process descriptor not verifiable from quantities alone is recorded as `not checkable from quantities, verify by process`, never guessed. - A tolerance is required on every weighed or counted item; a missing one is flagged, never defaulted silently. - British English, GBP, DD Month YYYY dates. No em dashes. - Every file ends with: this is a working document prepared for the owner to check against their own recipes and menu wording, and for a solicitor or trading standards adviser to check where a claim is genuinely borderline. It is not legal advice. ## Return The absolute path and row count of each file. Every menu claim found, with type and value. Every spec item with target and tolerance. Every claim marked `supportable: no`, with the gap. The number of spec items missing a tolerance, and claims with no matching spec item. The `gaps.md` item count.
Built from the best public work on this
Sources for portion-spec-sheet
Everything below was opened and read on 4 November 2026. Nothing is cited that could not be loaded.
1. The Consumer Protection from Unfair Trading Regulations 2008, regulation 5
https://www.legislation.gov.uk/uksi/2008/1277/made, SI 2008/1277, read 4 November 2026.
Regulation 5(2)(a): a commercial practice is a misleading action "if it contains false information and is therefore untruthful in relation to any of the matters in paragraph (4)", and this applies "even if the information is factually correct" where the practice "or its overall presentation in any way deceives or is likely to deceive the average consumer." Regulation 5(4) lists "the existence or nature of the product" and "the main characteristics of the product (as defined in paragraph 5)" among the matters covered. Regulation 5(5) defines main characteristics to include "composition of the product", "quantity of the product" and "specification of the product."
This is the direct legal basis for step 1: a stated weight, size or count on a menu is a characteristic the Regulations protect, and getting it wrong, even without intending to deceive, is the kind of practice regulation 5 is written to catch.
Where the skill departs: regulation 5(2)(b) also requires the practice to cause, or be likely to cause, a transactional decision the consumer would not otherwise have taken. The skill does not attempt to judge that second limb; it only checks whether the claim and the spec agree, which is the factual question a kitchen can actually answer for itself.
2. Morning Advertiser, "False menu descriptions costs venue £7K"
https://morningadvertiser.co.uk/Article/2017/11/13/False-menu-descriptions-costs-venue-7K, published 13 November 2017, read 4 November 2026.
Reports a real prosecution: a venue described fish on its menu as "Wye Salmon" and "Wye Trout" when "salmon from the River Wye could not legally be sold" and the products were sourced elsewhere. The operator "pleaded guilty to four charges under the Food Safety Act and one under the Consumer Protection from Unfair Trading Regulations 2008." The total cost was "£500 for each Food Safety Act charge, reduced from £750 for an early guilty plea", plus "a £50 victim surcharge and £5,380 in full prosecution costs", bringing the total to £7,430.
This case is about a false origin claim rather than a false weight, but it is cited in step 4 for a narrower, accurate purpose: it proves menu-description enforcement under the 2008 Regulations is real and has actually happened, with a real cost attached, which is the point the skill needs to make without overstating what the case itself was about.
Where the skill departs: the skill does not claim this case concerned portion weight; it is used only as evidence that a false menu description, of any kind, is prosecuted in practice under the same Regulations that govern a false weight or count claim.
Best public prompt we found for this job
The closest public artefact is `jacqueline-lam/umami-pantry` on GitHub, read from api.github.com on 4 November 2026, which returned a `stargazers_count` of 2 and the description "A single page app built to help homecooks find matching recipes for limited pantry ingredients." It is a home-cooking recipe-matching tool, not a commercial kitchen spec tool, and it is the closest real repository found that handles recipe quantities and servings as structured data a customer-facing claim could be checked against.
What we took: the idea of treating a recipe's quantities as the authoritative record that any customer-facing claim should be checked against, rather than the other way round.
What we did not copy, and why: it is built to help a home cook use up pantry ingredients, with no concept of a menu description, a legal quantity claim, or a tolerance a commercial kitchen could consistently hit. It has nothing resembling a portion spec, a sign-off record, or a check against the Consumer Protection from Unfair Trading Regulations 2008, because none of that is relevant to its actual job. Those three things, the spec, the sign-off, and the legal check, are the entire reason this skill exists separately.
Want this running in your business?
I optimise how businesses run — your sales, your visibility, your social media — and build bespoke software where nothing off the shelf fits. The first conversation is free. Work starts from £150 a day.