What Details Should I Give a Meal Copilot for One Usable Dinner?

Give a meal copilot five pieces of context: what you have, how long you have, what you cannot or will not eat, how many people you are feeding, and which substitutions are acceptable. Then set an output rule: choose one dinner, list the ingredients and amounts, give ordered steps, and finish with any missing item or next action. Put hard constraints first and label unknowns as unknowns. That is the minimum useful request; a vague prompt leaves the copilot to decide the menu, serving size, time and substitutions on your behalf.

You do not need to write a long life story or list every ingredient in the kitchen. You do need to separate facts from preferences. “Use the cooked rice” is different from “rice would be nice”; “no peanuts” is different from “I am not in the mood for nuts”. A short, structured brief gives the reply fewer decisions to make and makes it easier for you to inspect before cooking.

The Five-to-One dinner brief

Use five input fields and one answer contract. The fields describe the real situation; the contract tells the copilot not to turn that situation into a catalogue of possibilities.

1. Stock: what is available now, what must be used, and roughly how much of it there is.
2. Clock: the total time available, the latest time dinner must be ready, and any useful equipment.
3. Boundaries: allergies, dietary requirements, ingredients you avoid, texture preferences and other non-negotiables.
4. People: number of servings, whether leftovers are wanted, and any different needs at the table.
5. Flex: which swaps are allowed, which ingredients may be bought, and what must not be substituted.
6. One-answer contract: one named dinner, the needed quantities, ordered steps, a clearly marked missing item and only the swaps that matter.

The sixth line is not another input. It is the control on the shape of the reply. If you want one dinner, say so explicitly. Ask for alternatives only when comparing alternatives is the actual job.

A useful priority order is: safety and medical constraints first; ingredients that must be used next; the time and equipment limit; serving requirements; then taste preferences and optional improvements. If two requirements collide, ask the copilot to point out the collision instead of quietly relaxing one of them.

Fill the five fields without overloading the request

1. Stock: describe ingredients by role

Start with ingredients that are genuinely available, not ingredients you hope to buy. Separate them into three groups:

• Must use: food that is already open, needs using soon, or is the reason for the request.
• Can use: items that would be convenient but are not essential.
• Not available: a likely ingredient that the dinner must not assume you have.

Add amounts when they affect the choice. “Some spinach” leaves an important question open; “one large handful of spinach” is more useful. For packaged food, include the form where it matters: cooked rice versus dry rice, tinned beans versus dried beans, fresh versus frozen vegetables. If you do not know an amount, say “amount unknown” rather than presenting a guess as fact.

Do not inventory every spice unless it changes the decision. “Basic dried herbs available” is enough for a broad seasoning boundary; a named spice matters when it is central to the flavour or excluded.

2. Clock: give a deadline, not just a cooking time

State the time from now until the meal needs to be on the table. If washing, chopping, resting or reheating has to fit inside that window, include it. Also name the equipment that is unavailable: “one hob and a microwave” is more actionable than “limited equipment”.

There is a useful distinction between a deadline and a preference:

• Hard clock: “I have 25 minutes and cannot start earlier.”
• Soft clock: “Around 25 minutes would be comfortable, but 35 is possible.”

If a component is already cooked, say so. If you want a hands-off method while doing something else, say that as a preference rather than assuming the copilot knows it.

3. Boundaries: make the non-negotiables visible

Put allergies and medically relevant dietary requirements in a separate, prominent line. Then add strong dislikes, texture limits, and practical restrictions. A copilot should not have to infer whether “I do not like dairy” means a preference or a strict avoidance rule.

Useful labels include:

• Must avoid: an allergy, intolerance or firm exclusion.
• Prefer: a taste, texture or nutrition preference that can yield if necessary.
• Must include: an ingredient or food type you want in the meal.

This distinction helps when the request is crowded. It also gives you a review list: confirm that every hard boundary appears in the proposed dinner before you start.

4. People: specify the serving job

“Dinner for the family” is not a serving instruction. Give the number of people, whether the portions should be equal, and whether leftovers are useful. If one person needs a different component, state that rather than asking for a general family meal.

Serving information also affects how you describe the stock. “Two eggs for one person” creates a different problem from “two eggs for three people”. When you want leftovers, say how many extra servings are welcome; when you do not, state “no planned leftovers”.

5. Flex: draw the substitution boundary

A swap request is only useful when the boundary is explicit. Tell the copilot what kind of change is acceptable:

• No shop: use only what is already available.
• One small purchase: name the type of item you are willing to buy.
• Allowed list: permit a substitution only from a short list.
• Role-preserving swap: replace an ingredient by function, such as a creamy element, an acid, a grain or a protein.
• Protected ingredient: do not replace the main ingredient or the item that must be used.

You can also set the number of decisions: “Choose one substitute, not a list.” If no safe or sensible swap fits, the requested answer should say that the gap remains instead of hiding it inside a complicated recipe.

Decision table: convert uncertainty into a clear line

Use this table while writing the request. It is designed to stop a missing detail from becoming an unspoken assumption.

This is a decision table, not a promise that every situation has a neat answer. Its purpose is to expose the choices you have already made, so the copilot is not forced to make them silently.

Worked Example: three requests that become cookable briefs

These examples demonstrate request design. They are not predictions of a particular recipe or a claim that a reply will be correct without checking.

Example 1: available ingredients and time

Before:

I have chicken, spinach, rice and yoghurt. What can I make tonight?

After:

Choose one dinner for two people using two chicken thighs, cooked rice, spinach and plain yoghurt. I have one frying pan and 35 minutes from now; I will not shop. Keep the seasoning mild. Give one named dinner, quantities, ordered steps and one practical next step. If the rice needs a particular treatment because it is already cooked, state that explicitly.

The revised request supplies the stock, a serving target, a hard shopping boundary, equipment, a time limit and the shape of the answer. It also turns “yoghurt” from a vague extra into an available ingredient without deciding in advance how it must be used.

Example 2: preferences and serving count

Before:

I do not eat spicy food. What is a quick dinner for me?

After:

Choose one mild dinner for one person, with no planned leftovers. Avoid chilli and peanuts. I have 25 minutes, one hob and a microwave. I would prefer a vegetable-led meal and have eggs, potatoes and frozen peas; use those if they fit, but name any missing item rather than assuming I can shop. Return one dinner with amounts, steps in order and a final check for the two exclusions.

The important change is not the extra adjectives. It is the separation of a firm avoidance from a preference, plus a defined serving job and equipment limit. “For me” is now an explicit one-person portion rather than an invitation to design a family-sized dish.

Example 3: a missing ingredient with a defined swap boundary

Before:

I want pasta but I am missing tomatoes. What can I substitute?

After:

Choose one dinner for one person using 80 g dry pasta, tinned tuna, garlic and frozen peas. Tomatoes are not available. Do not replace the tuna, do not suggest a shop and do not give a list of sauces. If the dish needs a tomato-like role, choose at most one option from lemon, plain yoghurt or stock; state which option you chose and the amount. Give one dinner, ordered steps and the next action.

This request does not ask for every possible substitute. It defines what is protected, what may change and how many alternatives are useful. If none of the permitted options fits, that conflict should be visible so you can decide whether to relax the boundary.

The reusable one-dinner request card

Copy this card and fill in only the lines that matter. Keep the labels while drafting; they make it easier to spot a missing decision.

ONE-DINNER REQUEST

Available now:
Must use:
Can use:
Amount or form details:

Time available:
Latest serving time:
Equipment available or unavailable:

Must avoid:
Preferences:
Must include:

Servings:
Leftovers wanted?:

No-shop or shopping limit:
Allowed swaps:
Protected ingredients:

Choose one dinner only.
Return the dish name, needed amounts, ordered steps,
any missing item, and one practical next action.
Do not give a menu or unrequested alternatives.

The card is deliberately plain. A copilot cannot inspect a label, cupboard or allergy list that you have not described. It is better to leave a line as “unknown” and ask for the uncertainty to be surfaced than to fill it with a confident-looking guess.

Implementation steps: from a kitchen note to a single request

Step 1: make a quick inventory

Look at the ingredients you can actually use and record the form and approximate amount of the few items that could determine the meal. Mark anything open or perishable as “must use” only if that is genuinely your priority. Do not add a wish list to the available-now line.

Step 2: set the hard limits

Write the real deadline, equipment, serving count and safety-related exclusions first. If you have several people with different needs, state the difference. Keep preferences on a separate line so a taste request does not compete invisibly with a non-negotiable restriction.

Step 3: decide the flex before asking

Choose whether the answer may include a shop, a substitute or neither. A useful boundary might be “one substitute from these three items” or “use only the listed ingredients”. If you are open to a missing staple, name the category and the maximum number of items rather than saying “anything is fine”.

Step 4: lock the output

Use the final lines of the card to request one dinner. Ask for amounts and ordered steps, but also request the next practical action: for example, whether to start preheating, thaw an ingredient or set aside a component. If you want a grocery item identified, ask for it to be labelled as missing rather than quietly added to the inventory.

Step 5: inspect the answer before cooking

Use four checks:

1. Is there one clear dinner, rather than several choices joined together?
2. Does it use the stated ingredients and serving count without assuming an unlisted item?
3. Do the timing and equipment fit the stated limits?
4. Are the exclusions, swap boundary and any uncertainty visible?

If a check fails, repair the request instead of starting over with a new problem statement. A focused follow-up can say:

Keep the chosen dinner. Do not propose alternatives. Correct only the conflict with [the time, ingredient, equipment or exclusion]. Show the revised amount and step, and identify anything I still need to verify.

That keeps the decision stable while asking for one specific correction. You still decide whether the revised instructions make sense in your kitchen.

Step 6: perform the real-world check

Before using an ingredient, check its label, condition and handling instructions. Confirm portions, allergens and cooking safety yourself. The request card improves the information you provide; it does not transfer responsibility for those checks to the copilot.

Using the brief with Chef Bento

The public Eat Easier Club page describes Chef Bento as the chat path where you tell it what you have or need and receive one concrete answer, swaps and next steps. If that is the meal copilot you are using, the five fields and the one-answer contract above match the published shape of that workflow. They are editorial guidance for composing a request, not a promise about a particular dish, suitability or response.

Start with the request card, then add one sentence about anything the card cannot express clearly. For example: “I can change the side, but not the main ingredient.” That sentence keeps the permitted change explicit. Keep the first request bounded; if the situation changes, update the affected field rather than rewriting the entire dinner problem.

Limitations

A well-specified request still has limits:

• Unknown inventory stays unknown. A request does not establish whether an item is fresh, how much is in an unopened packet or what is hidden in a prepared ingredient. Check it yourself.
• Food safety is not a formatting problem. Check allergens, labels, cross-contact concerns, storage and safe preparation independently. If a medical condition affects what you can eat, use appropriate professional guidance rather than treating a chat reply as a clearance.
• Conflicting constraints may have no convenient solution. A very short deadline, missing equipment, strict exclusions and a protected ingredient can rule out the dinner you imagined. Ask the conflict to be named; do not make the request less strict without choosing to do so.
• Portion language can be ambiguous. “One serving” is not a universal measurement. State the number of people and whether leftovers are wanted, then review the quantities against your needs.
• A single-answer format is not always the right format. It is useful when the problem is “decide tonight’s dinner”. If you are comparing methods, using up several ingredients or cooking for different preferences, request a comparison deliberately and accept that it will require more decisions.
• The brief does not verify performance. It is a way to make your inputs and desired output explicit. It cannot establish that a particular recipe, substitution, nutrition estimate or timing is correct in your circumstances.

The practical trade-off is simple: the more tightly you define the answer, the less room there is for exploration. That is helpful when decision fatigue is the problem, but it is not a reason to hide uncertainty or ignore a result that does not fit.

FAQ

What is the minimum information to include?

List the ingredients you can use, the time and equipment available, the number of servings, any hard exclusions and the permitted swap boundary. End by asking for one dinner with amounts, ordered steps and any missing item. If you know little else, say what is unknown.

Do I need exact quantities?

Not always. Rough amounts are enough to establish whether an ingredient is central or incidental, but quantities become important for serving count, a must-use item or a limited packet. When you are unsure, label the amount as approximate instead of presenting it as exact.

Should an allergy be written as a preference?

No. Put an allergy or medically relevant restriction under “must avoid”, separate from taste preferences. Then check labels and preparation conditions yourself; a clearly written request does not replace those checks.

What if I do not know what ingredients are missing?

Say what is available and ask the copilot to name one missing item only if buying is possible. If shopping is not possible, write “no shop” and provide a permitted swap list. This prevents a plausible-sounding dinner from depending on an ingredient you cannot obtain.

Why ask for one dinner instead of several ideas?

Because the task is different. A list makes you choose between menus; a one-answer contract asks the copilot to apply the stated limits and present one path. If you genuinely want comparison, request a fixed number of alternatives and specify what you will compare, such as time or equipment.

What should I do when the answer ignores one of my limits?

Do not silently accept the change. Use a narrow follow-up: keep the chosen dinner, name the missed limit, ask for the smallest revision and request the revised amount or step. Then run the four checks before cooking.

Can I reuse the same request card?

Yes, as a template, not as a permanent inventory. Update the available ingredients, time, serving count and swap boundary each time. Leave stable preferences in a separate note, but repeat safety-related exclusions in the active request so they remain visible.