Recipes

I want a persisted artifact or interactive UI in chat to manage product cost live using the Atlas connector.
Here's what I need it to do:
- Shows my product catalogue, with a way to switch between outlets/menus (I likely have more than one, and the combined catalogue may be large).
- Lets me view and edit each product's cost/COGS, with price, margin $, and margin % calculated automatically, and flags anything missing a cost.
- Pushes my edits back to Atlas directly rather than just storing them locally in the artifact.
- Comes with a daily automated check that alerts me if any product is missing a COGS value.
Before building, verify your assumptions against my actual data and tools rather than guessing — check the real shape of tool responses, confirm which items are genuine products versus modifiers/options, and reconcile any counts you pull. Ask me if anything about my setup is ambiguous.

I have the Atlas plugin connected. Set up a reusable Product Cost / COGS Manager workflow for my Atlas account.
What I need:
- Start by listing my outlets and menus from Atlas. Ask me which outlet/menu to manage if the correct scope is unclear.
- Inspect the actual tool responses before designing the workflow. Do not assume the documented schema exactly matches the backend.
- Reconcile catalogue counts across the selected outlet and menu.
- Treat products placed directly inside menu sections or subsections as genuine sellable menu products.
- Exclude modifier choices, options and components—even if they also appear as item or product records.
- Flag outlet-linked products that are not actually present on the selected menu separately.
For each genuine menu product, show:
- Product name
- SKU
- Atlas product ID
- Menu section
- Selling price
- Current COGS/cost
- Margin amount: price minus COGS
- Margin percentage: margin divided by price
- Status: current, missing COGS or pending change
Editing and syncing:
- Let me provide COGS edits individually or as a batch in this conversation.
- Interpret monetary values in the product's currency and convert them to minor currency units for Atlas.
- Before writing, show a concise change summary with old cost, new cost, new margin amount and new margin percentage.
- After I approve, update each product in Atlas using update_product with cost_cents.
- Important: if cost_cents is absent from the published update_product schema, do not immediately conclude that writes are unsupported. The Atlas backend may still accept it. Safely verify this using a no-op write of an existing cost value before reporting a limitation.
- Never change price, tags, modifier groups or other product fields when only updating COGS.
- After every write, read the products again from Atlas and verify the stored values.
- Report any partial failures clearly and do not claim a product was updated unless verification succeeds.
Interface:
- Present the catalogue as a compact, searchable table in ChatGPT.
- Allow filtering by menu section, missing COGS and pending changes.
- If you create a persisted visual interface, do not imply that its buttons can call Atlas directly unless the interface genuinely has authenticated connector access.
- If direct connector access is unavailable inside the interface, keep edits in a pending queue and generate a structured sync request that I can submit through this ChatGPT conversation.
Automated check:
- Ask me what time and timezone the daily check should run.
- Create a daily automation that reads the selected Atlas menu, excludes modifiers/options/components, and checks genuine menu products for missing cost_cents.
- Notify me only when at least one genuine menu product is missing COGS.
- In an alert, include outlet, menu, total genuine products checked, number missing, product name, SKU, product ID, section and selling price.
- If no genuine product is missing COGS, do not notify me.
Before building or changing anything, verify the outlet, menu, product-versus-modifier rules, catalogue counts, cost read shape and cost write behaviour against my actual Atlas data and tools.

I want a tool to manage allergen and dietary flags for my menu items in Atlas.
Here's what I need it to do:
- Show me all the products on any of my menus in one place. If my outlet has more than one menu, let me switch between them without starting over.
- Let me mark which allergens (gluten, dairy, shellfish, etc.) and other flags like alcohol apply to each item.
- Check for existing allergen tags and ensure that new tag additions are formatted consistently.
- Save my changes straight back into Atlas as product tags the moment I make them.
- Let me search or filter to quickly find items that do (or don't) have a specific flag.
I want this to be something I can reopen anytime and it should always show my current menu data, not a snapshot from when it was built.

Act as my live Atlas Allergen & Dietary Flag Manager inside ChatGPT.
Use the connected Atlas plugin as the source of truth. Do not build or redirect me to a standalone website—the workflow must remain in ChatGPT so reads and writes use my authenticated Atlas connection.
Start by:
1. Listing my Atlas menus.
2. Asking which menu I want to manage, unless I already named one.
3. Fetching every product on that menu, handling pagination if necessary.
4. Showing a compact, readable view containing:
- Product name
- Product ID or SKU
- Current allergen and dietary product tags
- Items with no managed flags
Support natural-language requests such as:
- "Refresh"
- "Show products with gluten"
- "Show products without any allergen flags"
- "Add crustacean to Shrimp aglio olio"
- "Remove fish from Chicken teriyaki skewers"
- "Switch to another menu"
When I ask to add or remove a flag:
1. Resolve the exact product. Ask me to choose if the name is ambiguous.
2. Re-fetch that product immediately before writing.
3. Read its complete current product_tags list.
4. Add or remove only the requested tag.
5. Preserve every unrelated product tag.
6. Call the Atlas product-update action with the complete updated product_tags list.
7. Re-fetch the product after writing.
8. Report whether the saved Atlas value was verified.
Never overwrite the entire tag list using only the allergen tags shown in the conversation. Tags such as cake, promotional tags, or other operational tags must be preserved.
Use Atlas's existing exact tag names whenever they already exist. Display friendly labels, but write the canonical value. Examples:
- Gluten → allergen-gluten
- Milk/dairy → allergen-milk
- Egg → allergen-egg
- Fish → allergen-fish
- Crustacean → allergen-crustacean
- Shellfish → allergen-shellfish, only if this is actually the merchant's established tag
- Peanut → allergen-peanut
- Tree nuts → allergen-tree-nuts
- Soy → allergen-soy
- Sesame → allergen-sesame
- Alcohol → allergen-alcohol
- Vegetarian → dietary-vegetarian
- Vegan → dietary-vegan
Do not silently treat "crustacean" and "shellfish" as interchangeable. If the requested label does not have an established Atlas tag, ask me which canonical tag to use before writing.
Do not infer or add allergens from product names, descriptions, or ingredients unless I explicitly ask you to review and suggest possible missing flags. Suggestions must be presented for approval and must not be written automatically.
If an Atlas response is plain text rather than structured JSON, parse it carefully and continue; do not assume the action failed solely because the response format differs from its description.
A refresh must always make a new Atlas read. Never present cached or embedded data as current.
After each successful edit, respond concisely in this format:
Updated and verified in Atlas.
[Product name] now has:
- [tag]
- [tag]
If the write or verification fails, clearly distinguish:
- Write failed
- Write succeeded but verification failed
- Product could not be resolved
Do not claim an update succeeded unless the post-write Atlas read confirms it.

I want to be able to manage my cross-sell rules across my menus in Atlas and clearly identify products that do not trigger a cross-sell.
Here's what I want it to do:
- Show me every existing cross-sell group at a glance: what triggers it, what it promotes, and whether it's active, filtered by menu. If my outlet has more than one menu, let me switch between them.
- Flag any item on my menu that isn't currently triggering an active cross-sell group, so nothing gets missed.
- Let me reassign an item from one group to another (or unassign it) by dragging and dropping it, without me having to look up IDs myself.
- Let me create a brand-new group by picking which items should trigger it and which items it should promote.
- Let me activate or deactivate a group. If there's no delete tool available for this, deactivating is the right substitute — don't try to force a hard delete.
A few things to watch for while building this:
- Probe each tool once in chat and look at the actual response shape before wiring it into the artifact — don't assume it matches the schema description word for word.
- If a call ever returns plain text instead of clean JSON (e.g. it looks like a raw object dump rather than JSON), write a small parser for that format instead of assuming JSON.parse will work.
- Make tool calls one at a time rather than firing several at once, and retry a couple of times on failure. Backends like this can be flaky under concurrent requests and throw unrelated-looking errors when hit with parallel calls — spacing calls out avoids most of that.
- Keep it as a persisted, live artifact rather than a static one-time render, since group membership changes over time and I'll want to check back on it.

I have the Atlas plugin connected. Help me manage cross-sell rules across my Atlas menus.
Start by reading my actual Atlas setup. Do not assume outlet, menu, product, or cross-sell IDs.
What I need:
- Let me choose an outlet and menu.
- Show every cross-sell group relevant to that menu.
- For each group, show: its internal group name, whether it is active, the products that trigger it, and the products it promotes.
- Clearly identify menu products that do not trigger any active cross-sell group.
- Let me search and filter products, especially uncovered products.
- Let me draft these operations without manually finding IDs: move a triggering product between groups, unassign a triggering product, activate or deactivate a group, create a new group by selecting triggering and promoted products.
- Cross-sell group names are internal identifiers. Do not describe or treat them as customer-facing labels. Customers see the promoted products, not the group name.
- Do not hard-delete groups. If no supported deletion tool exists, deactivate them.
Tool-handling requirements:
1. Probe each required Atlas read tool once and inspect its real response before building the workflow.
2. Atlas may return Ruby-style object dumps such as {:key=>value} instead of valid JSON. If that happens, parse the returned format rather than using JSON.parse directly.
3. Make Atlas calls sequentially, not concurrently.
4. Retry failed read or idempotent update calls up to two times with a short delay.
5. Do not automatically retry a non-idempotent group-creation call if the result is uncertain, because that could create a duplicate.
6. Resolve all product and group IDs internally from their names.
7. When changing a group's triggering or promoted products, remember that the Atlas update tool may treat those arrays as full replacements. Preserve every existing member that should remain.
8. After applying changes, re-read the affected groups from Atlas and report exactly what was verified.
Artifact and editing workflow:
- If ChatGPT can create an interactive artifact that directly calls the Atlas tools, use it.
- If a hosted website cannot call the Atlas connector, do not pretend its controls save to Atlas.
- In that case, create a draft-mode cross-sell planner: initialise it using the latest Atlas data retrieved in chat; allow local drag-and-drop reassignment, unassignment, activation changes, and new-group drafting; keep the draft in browser storage so it survives a refresh on that device; maintain a consolidated pending-change list; provide a reliable "Copy changes for ChatGPT" button; also display the generated instruction as selectable text in case clipboard access is blocked; clearly label the site as draft mode and state that Atlas has not changed yet.
- The copied instruction must include the outlet, menu, internal group names, product names, and all intended operations—never require the user to copy IDs.
When I paste a change list back into the conversation:
1. Parse the complete list.
2. Show me a concise summary of what will change.
3. Ask for confirmation only if the instruction is ambiguous, destructive, or conflicts with current Atlas data.
4. Otherwise, apply the changes sequentially.
5. Re-read Atlas and verify the final trigger membership, promoted products, and active status.
6. Clearly distinguish successful changes, skipped changes, and failures.
Begin by listing my available outlets and menus, then open the most likely active menu while still giving me a menu selector.

I want help planning and setting up modifiers across my menu — things like meal deals, add-ons, "make it a meal" upgrades, sides, extras, or drink pairings. I may not know exactly what's best, so I'd like you to advise, not just execute.
What I'm looking for from you:
- Understand my menu first, then suggest add-on ideas that fit it — where there's a natural upsell, what to pair, and roughly how to price it so it feels like value for diners and stays profitable.
- Ask me about my goals (higher average order value, moving slow items, simplifying choices, etc.) and tailor recommendations to them.
- Walk me through the trade-offs — flat price vs tiered, required vs optional, discounted bundle vs full price — and recommend a default.
How I want to work:
1. Ask me what you need to know before proposing anything.
2. Create an artifact or visualise the UI in chat with your proposed add-ons: the diner flow, the options, and the pricing — so I can see it before anything changes.
3. Let me react and adjust in the artifact or UI in chat, and refine the plan with me.
4. Once I'm happy, apply it to my live menu and tidy up any existing messy or inconsistent setups so everything stays clean.
5. Keep the artifact in sync with what's actually live, and flag anything I should check on the diner-facing menu afterwards.
Don't change anything on my menu until I've reviewed and confirmed.

I have the Atlas plugin connected. Help me plan, review, and implement modifiers across my menu.
My goal is to increase basket size and average order value through sensible upsells such as meal upgrades, sides, extras, desserts, drink pairings, and bundles. I may not know what will work best, so advise me rather than asking me to define every pairing.
Follow this workflow:
1. Understand my goals
Ask which outlet or menu to work on and what I want to optimise for, such as: increasing average order value, increasing the number of items per order, improving cross-sell uptake, moving slower-selling items, promoting particular products, or simplifying ordering.
Also ask whether I prefer full-price add-ons, discounted bundles, or for you to recommend the best approach.
2. Inspect Atlas before recommending anything
Use the Atlas tools to read: outlets and menus, current products and prices, existing modifier and cross-sell groups, active and inactive rules, relevant order history, products commonly purchased together, and current average order value and items per order, where available.
Probe the relevant tools and examine their actual response shapes instead of relying solely on their schema descriptions.
Keep outlet-specific products separate from merchant-wide test, legacy, or unrelated configurations.
3. Identify the strongest basket-building opportunities
Look for natural ordering moments such as: main → side, main → drink, coffee → dessert, cocktail → sharing snack, single item → meal upgrade, multiple complementary items → bundle, checkout → final add-on.
Prioritise pairings that: feel relevant to the diner's current selection, add another item to the basket with little decision friction, have evidence of being purchased together, use existing products where possible, avoid presenting too many choices, and are likely to produce a meaningful increase in basket value.
Do not recommend add-ons merely because the products exist. Explain why each one is likely to increase uptake or order value.
4. Recommend a plan
For each proposal, show: triggering products, exact diner-facing prompt, promoted products, current item prices, potential basket-value increase, whether the choice is optional or required, minimum and maximum selections, whether pricing is full price, discounted, or tiered, why the pairing should increase basket size, and the Atlas configuration required.
Where historical data is available, include: current attachment or co-purchase signals, typical basket-value increase, relevant product popularity, and a reasonable uptake hypothesis.
Clearly distinguish measured results from estimates or hypotheses.
5. Explain the commercial trade-offs
Walk me through: flat versus tiered pricing, optional versus required selections, full-price convenience versus discounted bundles, one strong recommendation versus several choices, product-page prompts versus checkout prompts, and higher add-on value versus lower-friction entry pricing.
Recommend a default based on my stated AOV goal.
6. Create a review artifact before changing Atlas
Present the proposal as a simple planning artifact, not a marketing website. Prefer: expandable drill-downs for each trigger, a plain pricing and basket-impact table, a list of proposed Atlas changes, and a clear "Draft — nothing live has changed" status.
Show the literal prompts and choices diners would encounter so I can visualise the real ordering experience.
Let me request changes in ordinary language and keep refining the artifact.
7. Require approval
Do not create, update, activate, deactivate, or reassign anything in Atlas until I explicitly say something equivalent to: "Approve and apply." Reviewing the artifact alone does not count as approval.
8. Apply the approved plan
After approval: re-read the affected Atlas records to avoid overwriting newer changes, update suitable existing groups instead of creating duplicates, create new groups only when necessary, activate or deactivate groups as approved, preserve unrelated groups and products, and do not hard-delete anything unless Atlas supports it and I explicitly request deletion.
For non-idempotent creation calls, check for an existing matching group before creating anything. Do not blindly retry after an uncertain response.
9. Verify and synchronise
After writing: read every affected group back from Atlas; verify its label, active state, triggers, promoted products and descriptions; report exactly what succeeded or failed; update the artifact from "Draft" to "Live"; keep the artifact consistent with the verified Atlas configuration; flag anything I should check on the diner-facing menu; and suggest which AOV and attachment metrics to review after launch.
Clearly state which sales channels support the cross-sells. Do not imply that Atlas-owned cross-sells automatically appear on third-party platforms such as GrabFood or Foodpanda. GrabFood also does not support deep nested modifiers.
Start by asking only the questions that would materially change your recommendation. Do not make any menu changes yet.