myceliatrix / scrape-recipe.txt

Last active 1 month ago

Like 0

Revision 5eaae307e0c1f87720bbcec172676f3047bcb222

parse-recipe-ingredients.txt · 6.9 KiB · Text Raw

Parse each ingredient string into structured ingredient components.

You will receive a list containing one or more ingredient strings.

You must return exactly one parsed ingredient for every input ingredient, in the same order. Never merge, split, remove, reorder, or add ingredients.

## Core requirements

* Preserve all meaningful information from the original ingredient string.
* Every part of the input must either be represented in a structured field, included in the note field, or intentionally consumed by a documented normalization or conversion.
* Do not invent missing quantities, units, foods, preparations, brands, or notes.
* When part of an ingredient cannot be parsed confidently, preserve the uncertain text in the note field instead of discarding it.
* If the entire ingredient is too ambiguous to parse reliably, place the complete original string in the note field and leave the other fields empty.
* Return valid structured output only, with no explanations or commentary.

## Parsing rules

Separate each ingredient into the available components, including:

* quantity
* unit
* food or ingredient name
* note or preparation text

Examples:

* `3 potatoes (roughly chopped)`
  quantity: `3`
  food: `potatoes`
  note: `roughly chopped`

* `2 tbsp olive oil, plus more for frying`
  quantity: `2`
  unit: `tablespoon`
  food: `olive oil`
  note: `plus more for frying`

* `1 large onion, finely diced`
  quantity: `1`
  food: `onion`
  note: `large; finely diced`

## Quantity rules

* Parse integers, decimals, vulgar fractions, written fractions, and mixed numbers.
* Normalize equivalent quantities where practical:

* `½` → `0.5`
  * `1 1/2` → `1.5`
  * `one` → `1`
* For quantity ranges, use the lower value:

* `3–5` → `3`
  * `1 to 2` → `1`
  * `about 4–6` → `4`, with `about` preserved in the note when relevant
* Preserve approximate wording such as `about`, `approximately`, `roughly`, or `around` in the note field.
* Convert recognized grouped quantities when the conversion is unambiguous:

* `2 dozen eggs` → quantity: `24`, food: `eggs`
* Do not preserve the original grouped unit after it has been fully consumed by a conversion.
* Do not calculate quantities that require assumptions about package size, ingredient density, or serving size.

## Unit rules

Recognize common unit names, abbreviations, spelling variants, singular forms, plural forms, and multilingual variants.

The parser may recognize many equivalent forms, but it must normalize the final output to the preferred forms below.

### Preferred output forms

For metric units, always use these abbreviations in the final unit field:

- `mg`
- `g`
- `kg`
- `ml`
- `l`

For common kitchen units, use these abbreviations in the final unit field:

- `tsp`
- `tbsp`

For other count-based or descriptive units, use a concise singular word:

- `pinch`
- `dash`
- `sprig`
- `clove`
- `can`
- `jar`
- `bottle`
- `package`
- `packet`
- `sachet`
- `cube`
- `bunch`
- `bundle`
- `slice`
- `piece`
- `stick`
- `unit`

Do not output long metric names such as:

- `millilitre`
- `millilitres`
- `milliliter`
- `gram`
- `grams`
- `kilogram`
- `litre`

Normalize them to their preferred abbreviations instead.

Examples:

- `200 millilitres whipping cream`  
  quantity: `200`  
  unit: `ml`  
  food: `whipping cream`

- `400 grams halloumi`  
  quantity: `400`  
  unit: `g`  
  food: `halloumi`

- `1 kilogram potatoes`  
  quantity: `1`  
  unit: `kg`  
  food: `potatoes`

- `2 tablespoons olive oil`  
  quantity: `2`  
  unit: `tbsp`  
  food: `olive oil`

- `1 teaspoon salt`  
  quantity: `1`  
  unit: `tsp`  
  food: `salt`

### Recognition mappings

Normalize common variants as follows:

- `mg`, `milligram`, `milligrams` → `mg`
- `g`, `gram`, `grams` → `g`
- `kg`, `kilogram`, `kilograms` → `kg`
- `ml`, `millilitre`, `millilitres`, `milliliter`, `milliliters` → `ml`
- `l`, `litre`, `litres`, `liter`, `liters` → `l`
- `tsp`, `teaspoon`, `teaspoons` → `tsp`
- `tbsp`, `tbs`, `tablespoon`, `tablespoons` → `tbsp`

Use lowercase abbreviations exactly as written above.
Do not add periods to abbreviations.
Do not pluralize abbreviated units.
Do not include temperature units such as `°C` in ingredient unit fields unless the ingredient string itself genuinely represents a temperature value.
Do not mistake ingredient names, package descriptions, or preparation words for units.
If an unrecognized unit is present, preserve it only when it is clearly a unit. Otherwise place the uncertain text in the note field.

## Notes rules

Place preparation instructions, condition, optionality, alternatives, and extra qualifiers in the note field.

This includes text such as:

* finely chopped
* roughly chopped
* divided
* softened
* melted
* at room temperature
* for serving
* for garnish
* plus extra
* to taste
* optional
* drained
* rinsed
* peeled
* seeded
* crushed

Text in parentheses should normally be placed in the note field unless it is clearly part of the ingredient name.

Examples:

* `400 g tomatoes (drained)` → note: `drained`
* `1 can coconut milk (400 ml)` → keep `400 ml` in the note unless the schema has a dedicated package-size field
* `1 tsp salt, or to taste` → note: `or to taste`

Combine multiple note fragments clearly and without duplication.

## Multilingual rules

* Respect the grammar, word order, inflection, singular and plural forms, and unit conventions of the source language.
* Recognize grammatical variations and common abbreviations in multiple languages.
* Do not force English grammar onto non-English ingredient strings.
* Preserve the original language unless translation is explicitly requested.
* Correct only clear typographical mistakes; do not rewrite wording merely because it is unfamiliar.

## Ambiguity and lossless handling

* Prefer partial, lossless parsing over confident guessing.
* If quantity is clear but unit is uncertain, preserve the uncertain unit text in notes.
* If food is clear but preparation wording is ambiguous, keep the food and place the ambiguous remainder in notes.
* If a token could reasonably belong to more than one field and context does not resolve it, preserve it in notes.
* Never silently drop words, punctuation that carries meaning, package sizes, alternatives, or preparation details.
* Never duplicate the same source text across multiple fields unless duplication is required by the output schema.

## Output integrity

* Return the same number of ingredient objects as input strings.
* Preserve the exact input order.
* Do not combine repeated ingredients.
* Do not split one ingredient string into multiple ingredient objects.
* Do not add ingredients that are implied by instructions or recipe context.
* Ensure every output object corresponds directly to exactly one input string.
* Before returning the result, normalize every recognized unit to the exact preferred output form defined in the Unit rules.
* The final unit field must not contain plural forms or long-form metric unit names when a preferred abbreviation exists.

1	Parse each ingredient string into structured ingredient components.
2
3	You will receive a list containing one or more ingredient strings.
4
5	You must return exactly one parsed ingredient for every input ingredient, in the same order. Never merge, split, remove, reorder, or add ingredients.
6
7	## Core requirements
8
9	* Preserve all meaningful information from the original ingredient string.
10	* Every part of the input must either be represented in a structured field, included in the note field, or intentionally consumed by a documented normalization or conversion.
11	* Do not invent missing quantities, units, foods, preparations, brands, or notes.
12	* When part of an ingredient cannot be parsed confidently, preserve the uncertain text in the note field instead of discarding it.
13	* If the entire ingredient is too ambiguous to parse reliably, place the complete original string in the note field and leave the other fields empty.
14	* Return valid structured output only, with no explanations or commentary.
15
16	## Parsing rules
17
18	Separate each ingredient into the available components, including:
19
20	* quantity
21	* unit
22	* food or ingredient name
23	* note or preparation text
24
25	Examples:
26
27	* `3 potatoes (roughly chopped)`
28	quantity: `3`
29	food: `potatoes`
30	note: `roughly chopped`
31
32	* `2 tbsp olive oil, plus more for frying`
33	quantity: `2`
34	unit: `tablespoon`
35	food: `olive oil`
36	note: `plus more for frying`
37
38	* `1 large onion, finely diced`
39	quantity: `1`
40	food: `onion`
41	note: `large; finely diced`
42
43	## Quantity rules
44
45	* Parse integers, decimals, vulgar fractions, written fractions, and mixed numbers.
46	* Normalize equivalent quantities where practical:
47
48	* `½` → `0.5`
49	* `1 1/2` → `1.5`
50	* `one` → `1`
51	* For quantity ranges, use the lower value:
52
53	* `3–5` → `3`
54	* `1 to 2` → `1`
55	* `about 4–6` → `4`, with `about` preserved in the note when relevant
56	* Preserve approximate wording such as `about`, `approximately`, `roughly`, or `around` in the note field.
57	* Convert recognized grouped quantities when the conversion is unambiguous:
58
59	* `2 dozen eggs` → quantity: `24`, food: `eggs`
60	* Do not preserve the original grouped unit after it has been fully consumed by a conversion.
61	* Do not calculate quantities that require assumptions about package size, ingredient density, or serving size.
62
63	## Unit rules
64
65	Recognize common unit names, abbreviations, spelling variants, singular forms, plural forms, and multilingual variants.
66
67	The parser may recognize many equivalent forms, but it must normalize the final output to the preferred forms below.
68
69	### Preferred output forms
70
71	For metric units, always use these abbreviations in the final unit field:
72
73	- `mg`
74	- `g`
75	- `kg`
76	- `ml`
77	- `l`
78
79	For common kitchen units, use these abbreviations in the final unit field:
80
81	- `tsp`
82	- `tbsp`
83
84	For other count-based or descriptive units, use a concise singular word:
85
86	- `pinch`
87	- `dash`
88	- `sprig`
89	- `clove`
90	- `can`
91	- `jar`
92	- `bottle`
93	- `package`
94	- `packet`
95	- `sachet`
96	- `cube`
97	- `bunch`
98	- `bundle`
99	- `slice`
100	- `piece`
101	- `stick`
102	- `unit`
103
104	Do not output long metric names such as:
105
106	- `millilitre`
107	- `millilitres`
108	- `milliliter`
109	- `gram`
110	- `grams`
111	- `kilogram`
112	- `litre`
113
114	Normalize them to their preferred abbreviations instead.
115
116	Examples:
117
118	- `200 millilitres whipping cream`
119	quantity: `200`
120	unit: `ml`
121	food: `whipping cream`
122
123	- `400 grams halloumi`
124	quantity: `400`
125	unit: `g`
126	food: `halloumi`
127
128	- `1 kilogram potatoes`
129	quantity: `1`
130	unit: `kg`
131	food: `potatoes`
132
133	- `2 tablespoons olive oil`
134	quantity: `2`
135	unit: `tbsp`
136	food: `olive oil`
137
138	- `1 teaspoon salt`
139	quantity: `1`
140	unit: `tsp`
141	food: `salt`
142
143	### Recognition mappings
144
145	Normalize common variants as follows:
146
147	- `mg`, `milligram`, `milligrams` → `mg`
148	- `g`, `gram`, `grams` → `g`
149	- `kg`, `kilogram`, `kilograms` → `kg`
150	- `ml`, `millilitre`, `millilitres`, `milliliter`, `milliliters` → `ml`
151	- `l`, `litre`, `litres`, `liter`, `liters` → `l`
152	- `tsp`, `teaspoon`, `teaspoons` → `tsp`
153	- `tbsp`, `tbs`, `tablespoon`, `tablespoons` → `tbsp`
154
155	Use lowercase abbreviations exactly as written above.
156	Do not add periods to abbreviations.
157	Do not pluralize abbreviated units.
158	Do not include temperature units such as `°C` in ingredient unit fields unless the ingredient string itself genuinely represents a temperature value.
159	Do not mistake ingredient names, package descriptions, or preparation words for units.
160	If an unrecognized unit is present, preserve it only when it is clearly a unit. Otherwise place the uncertain text in the note field.
161
162	## Notes rules
163
164	Place preparation instructions, condition, optionality, alternatives, and extra qualifiers in the note field.
165
166	This includes text such as:
167
168	* finely chopped
169	* roughly chopped
170	* divided
171	* softened
172	* melted
173	* at room temperature
174	* for serving
175	* for garnish
176	* plus extra
177	* to taste
178	* optional
179	* drained
180	* rinsed
181	* peeled
182	* seeded
183	* crushed
184
185	Text in parentheses should normally be placed in the note field unless it is clearly part of the ingredient name.
186
187	Examples:
188
189	* `400 g tomatoes (drained)` → note: `drained`
190	* `1 can coconut milk (400 ml)` → keep `400 ml` in the note unless the schema has a dedicated package-size field
191	* `1 tsp salt, or to taste` → note: `or to taste`
192
193	Combine multiple note fragments clearly and without duplication.
194
195	## Multilingual rules
196
197	* Respect the grammar, word order, inflection, singular and plural forms, and unit conventions of the source language.
198	* Recognize grammatical variations and common abbreviations in multiple languages.
199	* Do not force English grammar onto non-English ingredient strings.
200	* Preserve the original language unless translation is explicitly requested.
201	* Correct only clear typographical mistakes; do not rewrite wording merely because it is unfamiliar.
202
203	## Ambiguity and lossless handling
204
205	* Prefer partial, lossless parsing over confident guessing.
206	* If quantity is clear but unit is uncertain, preserve the uncertain unit text in notes.
207	* If food is clear but preparation wording is ambiguous, keep the food and place the ambiguous remainder in notes.
208	* If a token could reasonably belong to more than one field and context does not resolve it, preserve it in notes.
209	* Never silently drop words, punctuation that carries meaning, package sizes, alternatives, or preparation details.
210	* Never duplicate the same source text across multiple fields unless duplication is required by the output schema.
211
212	## Output integrity
213
214	* Return the same number of ingredient objects as input strings.
215	* Preserve the exact input order.
216	* Do not combine repeated ingredients.
217	* Do not split one ingredient string into multiple ingredient objects.
218	* Do not add ingredients that are implied by instructions or recipe context.
219	* Ensure every output object corresponds directly to exactly one input string.
220	* Before returning the result, normalize every recognized unit to the exact preferred output form defined in the Unit rules.
221	* The final unit field must not contain plural forms or long-form metric unit names when a preferred abbreviation exists.

scrape-recipe.txt · 14 KiB · Text Raw

Extract recipe data from the provided webpage content and return a single JSON object conforming to the schema.org `Recipe` format.

Schema reference: https://schema.org/Recipe

The input may contain HTML, extracted text, metadata, navigation, advertisements, comments, unrelated page content, or duplicated recipe information. Identify and extract only the actual recipe.

Do not invent, infer, or add information that is not supported by the source. If the source does not contain enough information to identify a usable recipe, return an empty JSON object: `{}`.

## Extraction rules

- Prefer the recipe author’s actual content over surrounding page text, SEO text, advertisements, comments, related-recipe links, or other unrelated page content.
- Remove duplicated content caused by responsive layouts, print views, metadata, repeated page sections, or multiple representations of the same recipe.
- Do not include navigation labels, button text, subscription prompts, promotional text, advertisements, comments, or unrelated commentary.
- Do not treat labels such as `Step 1`, `Step 2`, `Method`, or `Instructions` as separate instruction steps when they contain no cooking action.
- Instruction steps must contain actual instruction text.
- Remove redundant step-number prefixes such as `Step 1:`, `1.`, `01 —`, or similar because step ordering is already represented by the JSON structure.
- Preserve the meaning of useful instruction section headings, but never return them as standalone instruction steps.
- Do not create empty instruction sections or empty instruction steps.
- Preserve the original ordering of ingredients, ingredient sections, and instructions.
- Keep ingredient quantities, units, preparation notes, alternatives, package sizes, and optional markers associated with the correct ingredient.
- Extract preparation time, cooking time, total time, yield, servings, temperatures, ratings, and nutritional information only when explicitly present in the source.
- Prefer explicit values from the main recipe over values inferred from prose, comments, related content, or calculations.
- When several representations of the recipe exist, prefer complete structured recipe data and verify it against the visible recipe content.

## Recipe normalization

Normalize the recipe before returning the JSON.

- Convert US customary measurements to sensible metric measurements.
- Prefer grams, kilograms, millilitres, litres, and degrees Celsius.
- Preserve practical kitchen units such as teaspoons and tablespoons when they are clearer than very small metric quantities.
- Preserve count-based quantities where appropriate, such as `2 eggs`, `1 onion`, `3 cloves garlic`, or `1 can tomatoes`.
- Convert Fahrenheit cooking temperatures to Celsius.
- Round conversions to sensible cooking values.
- Avoid false precision such as `236.588 ml`, `28.3495 g`, or similar values that are impractical in a kitchen.
- Use quantities that are practical to measure using normal kitchen equipment.
- Do not change quantities that are already expressed using sensible metric or practical kitchen units.
- Do not convert culturally meaningful, product-specific, package-based, or count-based units when conversion would make the ingredient less clear.
- Keep all converted quantities internally consistent across ingredients and instructions.
- When a converted quantity also appears in the instructions, use the same normalized value and unit in both places.

## Ingredient formatting and unit normalization

Normalize every string in `recipeIngredient` before returning the JSON.

Ingredient strings should be concise, natural, and suitable for display in a recipe application.

### Preferred unit output

Use these exact abbreviations for metric units:

- milligram → `mg`
- gram → `g`
- kilogram → `kg`
- millilitre or milliliter → `ml`
- litre or liter → `l`

Use these exact abbreviations for common kitchen units:

- teaspoon → `tsp`
- tablespoon → `tbsp`

Use lowercase abbreviations exactly as written.

Do not:

- add periods to unit abbreviations
- pluralize abbreviated units
- output long-form metric unit names when a preferred abbreviation exists
- mix long-form and abbreviated versions of the same unit within one recipe

Examples:

- `200 millilitres whipping cream` → `200 ml whipping cream`
- `390 grams chopped tomatoes` → `390 g chopped tomatoes`
- `1 kilogram potatoes` → `1 kg potatoes`
- `2 tablespoons tomato purée` → `2 tbsp tomato purée`
- `1 teaspoon salt` → `1 tsp salt`
- `500 milligrams saffron` → `500 mg saffron`

### Unit recognition

Recognize and normalize common spelling variants, abbreviations, singular forms, plural forms, and regional variants.

Normalize these forms:

### Count-based and descriptive units

Preserve concise count-based or descriptive units as words when they are appropriate, including:

- egg
- onion
- clove
- can
- jar
- bottle
- package
- packet
- sachet
- cube
- bunch
- bundle
- sprig
- slice
- piece
- stick
- pinch
- dash

Use natural singular or plural grammar for these units.

Examples:

- `4 cloves garlic`
- `2 cans chopped tomatoes`
- `1 bunch parsley`
- `3 slices bread`
- `1 pinch salt`

Do not rewrite natural count-based ingredients into artificial units such as `4 units garlic cloves`.

### Practical conversions

Preserve teaspoons and tablespoons when they remain practical and clear.

Examples:

- `1 tbsp olive oil` should remain `1 tbsp olive oil`
- `2 tsp paprika` should remain `2 tsp paprika`
- Do not convert `1 tsp salt` into `5 ml salt`
- Do not convert `2 tbsp oil` into `30 ml oil` unless the source or recipe context clearly benefits from metric volume

For larger US customary quantities, convert to sensible metric units.

Examples:

- `1 cup water` → approximately `240 ml water`
- `2 cups flour` → a sensible weight in grams only when the ingredient and conversion are unambiguous
- `1 lb potatoes` → approximately `450 g potatoes`
- `8 oz cream cheese` → approximately `225 g cream cheese`

Do not perform weight-to-volume or volume-to-weight conversions when ingredient density is uncertain.

### Fractions and ranges

- Preserve practical fractions for teaspoons and tablespoons when they are clear, such as `½ tsp` or `1½ tbsp`.
- Decimal quantities may be used when they improve consistency, such as `0.5 kg`.
- For converted metric values, prefer practical rounded numbers.
- Preserve quantity ranges when the source gives a meaningful range, such as `2–3 tbsp water`.
- Do not collapse a meaningful ingredient range unless the target schema requires a single value.
- Do not create false precision when converting fractions.

### Ingredient text

- Keep ingredient preparation notes associated with the ingredient.
- Preserve meaningful qualifiers that define the ingredient, such as `smoked paprika`, `dark soy sauce`, `full-fat coconut milk`, or `self-raising flour`.
- Preserve optional markers and serving notes, such as `optional`, `for garnish`, `for serving`, or `to taste`.
- Do not move preparation notes into separate ingredients.
- Do not split one source ingredient into several ingredient strings.
- Do not merge separate source ingredients.
- Preserve the original ingredient ordering.

Examples:

- `400 g tomatoes, drained`
- `2 tbsp olive oil, plus extra for frying`
- `1 large onion, finely chopped`
- `½ tsp red pepper flakes, optional`
- `salt and freshly ground black pepper, to taste`

## Instruction normalization

Normalize `recipeInstructions` before returning the JSON.

### Required behavior

- Every final `HowToStep` must contain at least one concrete action that a cook can perform.
- Never return a `HowToStep` whose text consists only of a title, label, section heading, phase name, or step number.
- Standalone headings must not appear as separate instruction entries.
- Do not create separate steps merely to preserve the source page’s visual structure.
- Do not preserve heading punctuation such as trailing colons.
- The final instruction list must contain only meaningful cooking actions.
- Preserve the original cooking order.

Examples of forbidden heading-only steps include:

- `Season Chicken`
- `Sear the Chicken`
- `Sauté Garlic`
- `Add Lemon and Spices`
- `Bake the Chicken`
- `Garnish and Serve`
- `To serve`
- `Serving`
- `For serving`
- `Make the sauce`
- `Prepare the filling`
- `Method`
- `Instructions`
- `Step 1`

### Heading handling

When a heading is immediately followed by an instruction:

- Omit the heading if the following instruction is clear without it.
- Merge the heading naturally into the following instruction if it adds useful context.
- Never return the heading as its own `HowToStep`.

Examples:

Input:

`Season Chicken:`

`Pat the chicken thighs dry, then season with salt and pepper.`

Output:

`Pat the chicken thighs dry, then season with salt and pepper.`

Input:

`Make the sauce:`

`Add the garlic, lemon juice, and stock to the pan.`

Output:

`To make the sauce, add the garlic, lemon juice, and stock to the pan.`

Input:

`Garnish and Serve:`

`Top with parsley and lemon slices, then serve.`

Output:

`Top with parsley and lemon slices, then serve.`

### Step consolidation

- Merge adjacent fragments when one contains only a heading and the next contains the actual instruction.
- Merge very short preparatory actions into the following instruction when they are directly related and doing so improves readability.
- Do not split a coherent cooking action into multiple steps merely because the source uses separate visual blocks.
- Do not over-merge unrelated cooking actions into excessively long steps.
- Prefer a concise sequence of meaningful steps over many tiny fragments.
- The final instruction list should normally contain fewer steps than the raw source when the source separates headings from their instructions.

### Temperature and unit consistency

- Use Celsius in instructions.
- When the source gives both Fahrenheit and Celsius, retain only the sensible Celsius value unless both are needed for clarity.
- Use normalized unit abbreviations consistently in instructions when quantities are repeated.
- Do not use long-form metric unit names in instructions when the preferred abbreviation is clearer.

Examples:

- `Bake at 375°F (190°C)` → `Bake at 190°C`
- `Add 200 millilitres cream` → `Add 200 ml cream`
- `Stir in 2 tablespoons olive oil` → `Stir in 2 tbsp olive oil`

### Final instruction validation

Before returning the JSON, inspect every instruction step.

For each step, verify:

1. It contains a concrete action a cook can perform.
2. It contains more than only a heading, label, phase name, or step number.
3. It does not duplicate information already represented by another step.
4. It is not empty or whitespace-only.
5. It is not merely explanatory text without an actionable instruction.
6. Its quantities, units, and temperatures use the same normalized forms as the ingredients.

If a step fails these checks, merge it with the appropriate adjacent step or remove it.

## Language rules

- If the source recipe is not in English, translate all recipe text into English.
- Translate the title, description, ingredient names, ingredient notes, section headings, instructions, yield text, and relevant recipe metadata.
- Preserve proper nouns, brand names, geographical names, and culturally specific dish names when translating them would make the recipe less precise or less recognizable.
- Use clear, natural cooking English rather than literal word-for-word translation.
- After translation, apply all unit normalization and abbreviation rules to the translated recipe.
- Do not leave untranslated unit names when a preferred English abbreviation exists.

## Image rules

- If the source contains a clear primary image of the finished recipe, include it in the `image` field.
- Prefer the main recipe hero image or the highest-quality image that clearly depicts the completed dish.
- Ignore logos, author portraits, advertisements, icons, social media images, decorative backgrounds, unrelated gallery images, and tracking pixels.
- Prefer image URLs found in recipe structured data, Open Graph metadata, Twitter Card metadata, or the main recipe content.
- When multiple versions of the same image are available, choose the largest practical image rather than a thumbnail or low-resolution preview.
- If the source provides an image array, select the best single primary image for the finished dish rather than returning multiple images.
- The `image` field must contain either:
  - an absolute URL string, for example: `"https://example.com/images/recipe.jpg"`
  - or an `ImageObject` containing an absolute `url` property, for example: `{ "@type": "ImageObject", "url": "https://example.com/images/recipe.jpg" }`
- Use only the `image` field.
- Do not use `thumbnail`, `thumbnailUrl`, `contentUrl`, or other image fields.
- Do not use relative URLs unless they can be resolved unambiguously against the webpage URL.
- Do not use embedded base64 data, data URIs, blob URLs, local file paths, or temporary browser-generated URLs.
- Do not invent, rewrite, guess, or repair an image URL.
- If no suitable recipe image is present, omit the `image` field.

## Final validation

Before returning the JSON, verify all of the following:

1. The output is a single valid schema.org `Recipe` JSON object.
2. Every ingredient from the source is represented once and in the original order.
3. Every recognized metric or kitchen unit uses the preferred abbreviation.
4. No ingredient uses long-form metric units such as `grams`, `millilitres`, or `kilograms`.
5. Ingredient quantities are practical and do not contain false precision.
6. Instruction quantities and temperatures are consistent with the normalized ingredients.
7. No instruction step consists only of a heading, label, or step number.
8. The image, when present, is a valid absolute URL or an `ImageObject` with an absolute `url`.
9. Unsupported fields are omitted rather than guessed.
10. No information has been invented.

Correct any violations before returning the final JSON.

## Output rules

- Return only the final JSON object.
- Do not include Markdown, explanations, comments, warnings, or code fences.
- Ensure the JSON is valid and syntactically complete.
- Omit unsupported optional fields rather than guessing their values.
- Use an empty object only when no usable recipe can be extracted.

1	Extract recipe data from the provided webpage content and return a single JSON object conforming to the schema.org `Recipe` format.
2
3	Schema reference: https://schema.org/Recipe
4
5	The input may contain HTML, extracted text, metadata, navigation, advertisements, comments, unrelated page content, or duplicated recipe information. Identify and extract only the actual recipe.
6
7	Do not invent, infer, or add information that is not supported by the source. If the source does not contain enough information to identify a usable recipe, return an empty JSON object: `{}`.
8
9	## Extraction rules
10
11	- Prefer the recipe author’s actual content over surrounding page text, SEO text, advertisements, comments, related-recipe links, or other unrelated page content.
12	- Remove duplicated content caused by responsive layouts, print views, metadata, repeated page sections, or multiple representations of the same recipe.
13	- Do not include navigation labels, button text, subscription prompts, promotional text, advertisements, comments, or unrelated commentary.
14	- Do not treat labels such as `Step 1`, `Step 2`, `Method`, or `Instructions` as separate instruction steps when they contain no cooking action.
15	- Instruction steps must contain actual instruction text.
16	- Remove redundant step-number prefixes such as `Step 1:`, `1.`, `01 —`, or similar because step ordering is already represented by the JSON structure.
17	- Preserve the meaning of useful instruction section headings, but never return them as standalone instruction steps.
18	- Do not create empty instruction sections or empty instruction steps.
19	- Preserve the original ordering of ingredients, ingredient sections, and instructions.
20	- Keep ingredient quantities, units, preparation notes, alternatives, package sizes, and optional markers associated with the correct ingredient.
21	- Extract preparation time, cooking time, total time, yield, servings, temperatures, ratings, and nutritional information only when explicitly present in the source.
22	- Prefer explicit values from the main recipe over values inferred from prose, comments, related content, or calculations.
23	- When several representations of the recipe exist, prefer complete structured recipe data and verify it against the visible recipe content.
24
25	## Recipe normalization
26
27	Normalize the recipe before returning the JSON.
28
29	- Convert US customary measurements to sensible metric measurements.
30	- Prefer grams, kilograms, millilitres, litres, and degrees Celsius.
31	- Preserve practical kitchen units such as teaspoons and tablespoons when they are clearer than very small metric quantities.
32	- Preserve count-based quantities where appropriate, such as `2 eggs`, `1 onion`, `3 cloves garlic`, or `1 can tomatoes`.
33	- Convert Fahrenheit cooking temperatures to Celsius.
34	- Round conversions to sensible cooking values.
35	- Avoid false precision such as `236.588 ml`, `28.3495 g`, or similar values that are impractical in a kitchen.
36	- Use quantities that are practical to measure using normal kitchen equipment.
37	- Do not change quantities that are already expressed using sensible metric or practical kitchen units.
38	- Do not convert culturally meaningful, product-specific, package-based, or count-based units when conversion would make the ingredient less clear.
39	- Keep all converted quantities internally consistent across ingredients and instructions.
40	- When a converted quantity also appears in the instructions, use the same normalized value and unit in both places.
41
42	## Ingredient formatting and unit normalization
43
44	Normalize every string in `recipeIngredient` before returning the JSON.
45
46	Ingredient strings should be concise, natural, and suitable for display in a recipe application.
47
48	### Preferred unit output
49
50	Use these exact abbreviations for metric units:
51
52	- milligram → `mg`
53	- gram → `g`
54	- kilogram → `kg`
55	- millilitre or milliliter → `ml`
56	- litre or liter → `l`
57
58	Use these exact abbreviations for common kitchen units:
59
60	- teaspoon → `tsp`
61	- tablespoon → `tbsp`
62
63	Use lowercase abbreviations exactly as written.
64
65	Do not:
66
67	- add periods to unit abbreviations
68	- pluralize abbreviated units
69	- output long-form metric unit names when a preferred abbreviation exists
70	- mix long-form and abbreviated versions of the same unit within one recipe
71
72	Examples:
73
74	- `200 millilitres whipping cream` → `200 ml whipping cream`
75	- `390 grams chopped tomatoes` → `390 g chopped tomatoes`
76	- `1 kilogram potatoes` → `1 kg potatoes`
77	- `2 tablespoons tomato purée` → `2 tbsp tomato purée`
78	- `1 teaspoon salt` → `1 tsp salt`
79	- `500 milligrams saffron` → `500 mg saffron`
80
81	### Unit recognition
82
83	Recognize and normalize common spelling variants, abbreviations, singular forms, plural forms, and regional variants.
84
85	Normalize these forms:
86
87	- `mg`, `milligram`, `milligrams` → `mg`
88	- `g`, `gram`, `grams` → `g`
89	- `kg`, `kilogram`, `kilograms` → `kg`
90	- `ml`, `millilitre`, `millilitres`, `milliliter`, `milliliters` → `ml`
91	- `l`, `litre`, `litres`, `liter`, `liters` → `l`
92	- `tsp`, `teaspoon`, `teaspoons` → `tsp`
93	- `tbsp`, `tbs`, `tablespoon`, `tablespoons` → `tbsp`
94
95	### Count-based and descriptive units
96
97	Preserve concise count-based or descriptive units as words when they are appropriate, including:
98
99	- egg
100	- onion
101	- clove
102	- can
103	- jar
104	- bottle
105	- package
106	- packet
107	- sachet
108	- cube
109	- bunch
110	- bundle
111	- sprig
112	- slice
113	- piece
114	- stick
115	- pinch
116	- dash
117
118	Use natural singular or plural grammar for these units.
119
120	Examples:
121
122	- `4 cloves garlic`
123	- `2 cans chopped tomatoes`
124	- `1 bunch parsley`
125	- `3 slices bread`
126	- `1 pinch salt`
127
128	Do not rewrite natural count-based ingredients into artificial units such as `4 units garlic cloves`.
129
130	### Practical conversions
131
132	Preserve teaspoons and tablespoons when they remain practical and clear.
133
134	Examples:
135
136	- `1 tbsp olive oil` should remain `1 tbsp olive oil`
137	- `2 tsp paprika` should remain `2 tsp paprika`
138	- Do not convert `1 tsp salt` into `5 ml salt`
139	- Do not convert `2 tbsp oil` into `30 ml oil` unless the source or recipe context clearly benefits from metric volume
140
141	For larger US customary quantities, convert to sensible metric units.
142
143	Examples:
144
145	- `1 cup water` → approximately `240 ml water`
146	- `2 cups flour` → a sensible weight in grams only when the ingredient and conversion are unambiguous
147	- `1 lb potatoes` → approximately `450 g potatoes`
148	- `8 oz cream cheese` → approximately `225 g cream cheese`
149
150	Do not perform weight-to-volume or volume-to-weight conversions when ingredient density is uncertain.
151
152	### Fractions and ranges
153
154	- Preserve practical fractions for teaspoons and tablespoons when they are clear, such as `½ tsp` or `1½ tbsp`.
155	- Decimal quantities may be used when they improve consistency, such as `0.5 kg`.
156	- For converted metric values, prefer practical rounded numbers.
157	- Preserve quantity ranges when the source gives a meaningful range, such as `2–3 tbsp water`.
158	- Do not collapse a meaningful ingredient range unless the target schema requires a single value.
159	- Do not create false precision when converting fractions.
160
161	### Ingredient text
162
163	- Keep ingredient preparation notes associated with the ingredient.
164	- Preserve meaningful qualifiers that define the ingredient, such as `smoked paprika`, `dark soy sauce`, `full-fat coconut milk`, or `self-raising flour`.
165	- Preserve optional markers and serving notes, such as `optional`, `for garnish`, `for serving`, or `to taste`.
166	- Do not move preparation notes into separate ingredients.
167	- Do not split one source ingredient into several ingredient strings.
168	- Do not merge separate source ingredients.
169	- Preserve the original ingredient ordering.
170
171	Examples:
172
173	- `400 g tomatoes, drained`
174	- `2 tbsp olive oil, plus extra for frying`
175	- `1 large onion, finely chopped`
176	- `½ tsp red pepper flakes, optional`
177	- `salt and freshly ground black pepper, to taste`
178
179	## Instruction normalization
180
181	Normalize `recipeInstructions` before returning the JSON.
182
183	### Required behavior
184
185	- Every final `HowToStep` must contain at least one concrete action that a cook can perform.
186	- Never return a `HowToStep` whose text consists only of a title, label, section heading, phase name, or step number.
187	- Standalone headings must not appear as separate instruction entries.
188	- Do not create separate steps merely to preserve the source page’s visual structure.
189	- Do not preserve heading punctuation such as trailing colons.
190	- The final instruction list must contain only meaningful cooking actions.
191	- Preserve the original cooking order.
192
193	Examples of forbidden heading-only steps include:
194
195	- `Season Chicken`
196	- `Sear the Chicken`
197	- `Sauté Garlic`
198	- `Add Lemon and Spices`
199	- `Bake the Chicken`
200	- `Garnish and Serve`
201	- `To serve`
202	- `Serving`
203	- `For serving`
204	- `Make the sauce`
205	- `Prepare the filling`
206	- `Method`
207	- `Instructions`
208	- `Step 1`
209
210	### Heading handling
211
212	When a heading is immediately followed by an instruction:
213
214	- Omit the heading if the following instruction is clear without it.
215	- Merge the heading naturally into the following instruction if it adds useful context.
216	- Never return the heading as its own `HowToStep`.
217
218	Examples:
219
220	Input:
221
222	`Season Chicken:`
223
224	`Pat the chicken thighs dry, then season with salt and pepper.`
225
226	Output:
227
228	`Pat the chicken thighs dry, then season with salt and pepper.`
229
230	Input:
231
232	`Make the sauce:`
233
234	`Add the garlic, lemon juice, and stock to the pan.`
235
236	Output:
237
238	`To make the sauce, add the garlic, lemon juice, and stock to the pan.`
239
240	Input:
241
242	`Garnish and Serve:`
243
244	`Top with parsley and lemon slices, then serve.`
245
246	Output:
247
248	`Top with parsley and lemon slices, then serve.`
249
250	### Step consolidation
251
252	- Merge adjacent fragments when one contains only a heading and the next contains the actual instruction.
253	- Merge very short preparatory actions into the following instruction when they are directly related and doing so improves readability.
254	- Do not split a coherent cooking action into multiple steps merely because the source uses separate visual blocks.
255	- Do not over-merge unrelated cooking actions into excessively long steps.
256	- Prefer a concise sequence of meaningful steps over many tiny fragments.
257	- The final instruction list should normally contain fewer steps than the raw source when the source separates headings from their instructions.
258
259	### Temperature and unit consistency
260
261	- Use Celsius in instructions.
262	- When the source gives both Fahrenheit and Celsius, retain only the sensible Celsius value unless both are needed for clarity.
263	- Use normalized unit abbreviations consistently in instructions when quantities are repeated.
264	- Do not use long-form metric unit names in instructions when the preferred abbreviation is clearer.
265
266	Examples:
267
268	- `Bake at 375°F (190°C)` → `Bake at 190°C`
269	- `Add 200 millilitres cream` → `Add 200 ml cream`
270	- `Stir in 2 tablespoons olive oil` → `Stir in 2 tbsp olive oil`
271
272	### Final instruction validation
273
274	Before returning the JSON, inspect every instruction step.
275
276	For each step, verify:
277
278	1. It contains a concrete action a cook can perform.
279	2. It contains more than only a heading, label, phase name, or step number.
280	3. It does not duplicate information already represented by another step.
281	4. It is not empty or whitespace-only.
282	5. It is not merely explanatory text without an actionable instruction.
283	6. Its quantities, units, and temperatures use the same normalized forms as the ingredients.
284
285	If a step fails these checks, merge it with the appropriate adjacent step or remove it.
286
287	## Language rules
288
289	- If the source recipe is not in English, translate all recipe text into English.
290	- Translate the title, description, ingredient names, ingredient notes, section headings, instructions, yield text, and relevant recipe metadata.
291	- Preserve proper nouns, brand names, geographical names, and culturally specific dish names when translating them would make the recipe less precise or less recognizable.
292	- Use clear, natural cooking English rather than literal word-for-word translation.
293	- After translation, apply all unit normalization and abbreviation rules to the translated recipe.
294	- Do not leave untranslated unit names when a preferred English abbreviation exists.
295
296	## Image rules
297
298	- If the source contains a clear primary image of the finished recipe, include it in the `image` field.
299	- Prefer the main recipe hero image or the highest-quality image that clearly depicts the completed dish.
300	- Ignore logos, author portraits, advertisements, icons, social media images, decorative backgrounds, unrelated gallery images, and tracking pixels.
301	- Prefer image URLs found in recipe structured data, Open Graph metadata, Twitter Card metadata, or the main recipe content.
302	- When multiple versions of the same image are available, choose the largest practical image rather than a thumbnail or low-resolution preview.
303	- If the source provides an image array, select the best single primary image for the finished dish rather than returning multiple images.
304	- The `image` field must contain either:
305	- an absolute URL string, for example: `"https://example.com/images/recipe.jpg"`
306	- or an `ImageObject` containing an absolute `url` property, for example: `{ "@type": "ImageObject", "url": "https://example.com/images/recipe.jpg" }`
307	- Use only the `image` field.
308	- Do not use `thumbnail`, `thumbnailUrl`, `contentUrl`, or other image fields.
309	- Do not use relative URLs unless they can be resolved unambiguously against the webpage URL.
310	- Do not use embedded base64 data, data URIs, blob URLs, local file paths, or temporary browser-generated URLs.
311	- Do not invent, rewrite, guess, or repair an image URL.
312	- If no suitable recipe image is present, omit the `image` field.
313
314	## Final validation
315
316	Before returning the JSON, verify all of the following:
317
318	1. The output is a single valid schema.org `Recipe` JSON object.
319	2. Every ingredient from the source is represented once and in the original order.
320	3. Every recognized metric or kitchen unit uses the preferred abbreviation.
321	4. No ingredient uses long-form metric units such as `grams`, `millilitres`, or `kilograms`.
322	5. Ingredient quantities are practical and do not contain false precision.
323	6. Instruction quantities and temperatures are consistent with the normalized ingredients.
324	7. No instruction step consists only of a heading, label, or step number.
325	8. The image, when present, is a valid absolute URL or an `ImageObject` with an absolute `url`.
326	9. Unsupported fields are omitted rather than guessed.
327	10. No information has been invented.
328
329	Correct any violations before returning the final JSON.
330
331	## Output rules
332
333	- Return only the final JSON object.
334	- Do not include Markdown, explanations, comments, warnings, or code fences.
335	- Ensure the JSON is valid and syntactically complete.
336	- Omit unsupported optional fields rather than guessing their values.
337	- Use an empty object only when no usable recipe can be extracted.