A restaurant as a system: one menu that everything else is derived from

Work on the folder business-ulipa. It has everything I've gathered
about our bistro: recipes, old menus and weekly menus in Word,
photos, the logo, old flyers, Facebook posts, and review screenshots.

Take an inventory:
1. List what's in the folder, by category, with file counts
2. For the weekly menus in Word, describe their structure (what
   repeats: soup, 2-3 mains, dessert?) and whether the structure
   is consistent
3. For dish photos, estimate how many are usable (sharp, dish
   recognizable) and how many aren't — just an estimate for now,
   we'll sort them later
4. List what's missing: a vector logo? dish descriptions? a
   current price list?
5. Propose a folder structure to reorganize all of this into

Don't move or delete anything, I'm waiting for your proposal.

In the folder business-ulipa/texts there are our Facebook posts
from the past year, the about-us copy from the website, and a few
review replies. In the reviews folder there are screenshots of
guest reviews.

Create a file voice.md:
1. Who we are, what guests call us, and what they appreciate about
   us according to reviews (quote guests' actual phrasing — "just
   like grandma's", "honest portions")
2. Tone: 4-5 traits, each with a sample sentence (e.g. warm but
   not overfamiliar; formal or informal address with guests?)
3. Vocabulary: how we refer to things ourselves — which word do we
   use for "soup"? "daily menu" or "lunch"? How we write dish names
4. Banned phrases: corporate and marketing filler that doesn't
   belong to us ("culinary experience", "premium quality")
5. Three "not like this / like this" pairs: a post about a new
   menu, a reply to a positive review, a reply to a critical review

Base this on our actual writing, not on some general idea of what
a bistro sounds like. Where you're not sure, ask me instead of
guessing.

Go through voice.md and act like someone starting tomorrow to write
our posts and review replies: ask me the questions the document
doesn't answer. I'm mainly interested in:
- how we announce unpleasant news: closed due to illness, a price
  increase, a dish sold out halfway through lunch
- how we respond to an unfair review (a guest complains about
  something that didn't happen)
- how much humor a post can carry, and how much a review reply can
- what we never promise (speed? dietary substitutions on the spot?)
Ask me one question at a time and work the answers straight into
the document.

In the folder business-ulipa/old-menus there are Word files of
weekly menus from the past three months, and a PDF of the standing
menu.

1. Convert the standing menu into a file standing-menu.yaml with
   the structure: name, description, price, allergens (numbers per
   the EU list, ONLY IF they're given in the source menu — never
   fill them in by guessing; mark missing ones TODO-ALLERGENS),
   tags, photo (leave empty for now)
2. From the weekly menus, build a template week-TEMPLATE.yaml: soup
   of the week plus two to three dishes for each day, same fields
3. List the inconsistencies you found during conversion: the same
   dish with different prices across different weeks, different
   spellings of the same name, dishes with no allergens
4. Propose a list of tags that make sense for our offering
   (vegetarian, gluten-free, classic, seasonal…) — I'll approve it
   before you use it

Copy prices over exactly, character for character; don't round
anything.

Set up a private git repository ulipa-menu with the structure:
- standing-menu.yaml (add the converted standing menu)
- weekly/ (files week-YYYY-WW.yaml will be added here over time)
- week-TEMPLATE.yaml (weekly menu template)
- voice.md (from phase 1)
- photos/ (selected dish photos, named per the photo field in the
  menu)
- README.md: what the repository is for, and the rule that the
  menu changes ONLY here — anyone who wants to change a price or a
  dish changes this repository, everything else is derived

Add a .gitignore for working files and exports. Before the first
commit, show me the complete file list — I'll check that there are
no recipes, cost calculations, or anything internal in there. Those
don't belong in this repository.

Check the file weekly/week-2026-34.yaml against these rules:
1. Every dish has a name, price, and allergens (an empty list [] is
   fine too — it means "checked, no allergens"; a MISSING field is
   an error)
2. Prices are whole numbers in a reasonable range for a lunch menu
3. Allergens are numbers 1-14, nothing else
4. Tags only from the approved list in standing-menu.yaml
5. A dish that's also on the standing menu has the SAME price there
   — if not, report the difference; it's either a typo or a
   forgotten price change
6. Compare dishes against past weeks: same dish, different price or
   different allergens than last time — flag it for manual review
Return the result as a checklist: what passed, what didn't, what
you recommend fixing. Don't fix anything yourself.

Here's a transcript of a voice message with next week's menu
[paste the transcript, or the recording itself]: "...Monday we'll
have a grilled chicken steak with roasted potatoes, and then sour
lentils with egg, soup all week is the tomato one... Tuesday, the
pork with dumpling and cabbage..."

Convert it into week-2026-35.yaml following the template
week-TEMPLATE.yaml:
1. Clean up dish names and descriptions into menu-ready form
   (following the style of standing-menu.yaml — natural, but not
   stiff)
2. Prices: where I didn't state a price, use the price of the same
   dish from previous weeks and FLAG it with a question mark for
   confirmation; leave a new dish with no price and a TODO
3. Allergens: DO NOT FILL IN. Put TODO-ALLERGENS on every dish and
   generate a checklist for the kitchen
4. List what was missing from the dictation (I may have skipped
   Thursday)

Show me the result to review, don't save it anywhere yet.

Build a weekly lunch menu template in Affinity for our bistro:
A4 portrait, cut after printing into two A5 table stands. Take the
logo and colors from the folder business-ulipa/graphics, and the
tone from voice.md.

Layout: a header with the logo and the week's validity dates, a
"soup of the week" block, then five days — day, two to three
dishes, each with name, description, price, and allergen numbers in
parentheses after the description. Footer: "Numbers indicate
allergens — full list available from staff" and a QR code (I'll
have it generated later, leave space for it for now).

Fill the text as a trial run with data from weekly/week-2026-34.yaml,
so I can see real, longer dish names instead of "Lorem ipsum." Show
me a preview and wait for feedback. Once I approve the template,
save it as the source file menu-template.af — that's the one we'll
just fill in every week from now on.

Open menu-template.af and fill it with data from
weekly/week-2026-35.yaml. Don't retype anything by hand — pull the
names, descriptions, prices, and allergens straight from the file.
If some text doesn't fit the space reserved for it, don't change
the font size or the text — list it for me, I'll shorten the
description in the source and we'll regenerate.
Show me a preview, and once I approve, export menu-week-35.pdf for
home printing (A4, regular printer) and
menu-week-35-web.pdf (lightweight, for email).

Build a simple website with our bistro's menu. Requirements:
1. Static page, no database: at build time it loads standing-menu.yaml
   and the newest file from weekly/, and renders them
2. Order: the week's validity dates, soup, the days, then the
   standing menu; for each dish, name, description, price, allergen
   numbers, tags as small icons (vegetarian, gluten-free)
3. Mobile first: large type, no popup bars, fast loading; I'll view
   the page in a phone preview
4. At the bottom, a legend spelling out allergens 1-14 in full, plus
   opening hours
5. Deploy on Vercel; every change in the ulipa-menu repository
   triggers an automatic regeneration of the page
First describe to me how you'll build it, and show a design
proposal — colors and typeface from business-ulipa/graphics.

From weekly/week-2026-35.yaml and voice.md, prepare three posts
for this week:
1. Monday morning: the whole weekly menu — clearly laid out by day,
   soup at the top, prices next to dishes; a short intro in our
   tone, no "culinary experience"
2. Wednesday: one dish as the star of the day [I'll pick one, or
   suggest based on what's most photogenic — see the photos folder]
3. Friday: a weekend invitation — coffee and cakes, looser tone
For each post: text for Facebook, a shorter version for Instagram,
a suggestion for which photo from photos/ to use (only real photos
of real dishes — never suggest a generated image of food), and 2-3
local hashtags. Go easy on emoji, so it still sounds like us.
These are drafts — don't publish anything, I'll review and edit.

Schedule the approved posts from the previous step through Buffer:
the Monday one for today at 9:30 AM, the Wednesday one for
Wednesday at 10:30 AM, the Friday one for Friday at 3:00 PM, on
our bistro's Facebook and Instagram channels. Before scheduling,
show me the final form of each: text, channel, time, photo.
Schedule them as drafts in the queue — I'll confirm publication in
Buffer myself. Don't change or delete anything else in the account.

From weekly/week-2026-35.yaml, standing-menu.yaml, and the recipes
in the recipes/ folder, prepare a one-page staff cheat sheet for
this week:
- for each dish: allergens BY NUMBER AND WORD (7 — milk), one
  sentence explaining "what it is" for a guest who doesn't know the
  dish, and a note on substitutions (can it be made without cream?
  can the side be swapped?)
- highlight what's vegetarian and what's gluten-free
- at the bottom, the three most common guest questions and answers
  (what's the tartar sauce made of, is the soup thickened with
  flour…)
Format: one A4 page, large type, printed for the back-of-house
board.
For allergens and substitutions, work EXCLUSIVELY from the recipes
and the data in the source — where a recipe is missing, write
"ASK THE KITCHEN," don't guess anything.
Before we print the cheat sheet, the kitchen reviews it and signs
off on it.

Monday routine for bistro U Lípy. There's a new menu dictation in
the folder (recording-2026-35.m4a). Go through the steps in order
and stop for approval after each one:
1. Convert the dictation into weekly/week-2026-35.yaml following
   the template; leave allergens as TODO-ALLERGENS and give me a
   checklist for the kitchen
2. Once I've filled in allergens and prices, run source validation
   (field completeness, prices against past weeks and the standing
   menu) and show me the result
3. Once approved, commit to ulipa-menu with the message "menu week 35"
4. Fill menu-template.af and export a PDF for printing
5. Prepare three social posts following the established pattern
   (Monday menu, Wednesday dish of the day, Friday weekend)
6. Generate the staff cheat sheet
Never skip an approval step, even if the result looks obvious.

Change in weekly/week-2026-35.yaml: on Thursday, replace [roast
duck] with the dish [chicken thigh in paprika sauce, bread
dumpling], price [8]. The kitchen supplies allergens — here's their
confirmation: [1, 3, 7].
Then:
1. Commit the change with the message "Thursday: duck replaced,
   delivery didn't arrive" (the website regenerates itself)
2. Regenerate the print PDF with just the fix, I'll print new
   inserts
3. Regenerate the staff cheat sheet
4. Suggest a short social post about whether to announce the
   change — I'll decide based on how many people were asking about
   the duck
Finish with a list of every place that now has the new version, and
which ones need a manual step (print, the chalkboard).

From the recipes in the recipes/ folder and the new menu
weekly/week-2026-35.yaml, prepare an allergen checklist for the
kitchen:
- for each dish, list the ingredients from the recipe, and next to
  each a CANDIDATE allergen with a question mark (cream → 7?, bread
  dumpling → 1, 3?)
- add a blank line "other allergens I don't see in the recipe" — the
  kitchen fills in what never made it into the written recipe
  (seasoning, oil, breading)
- format: a table on A4, a "confirmed" column for a signature
Put this explicitly in the header: "Draft from recipes — only valid
once confirmed by the kitchen. Allergens are not entered into the
menu without a signature."
For dishes with no recipe, leave the whole row blank — no guessing
based on the dish's name.

Check allergen consistency across all outputs:
1. Compare the allergens in weekly/week-2026-35.yaml and
   standing-menu.yaml against what's in the exported print PDF and
   on the menu website — every dish must show identical numbers
2. Verify that the allergen legend (numbers → names) is the same
   and complete (1-14) on the website and on the cheat sheet
3. Find dishes whose allergens changed compared to last week and
   list them separately — staff should actively be told about
   those changes
4. Find suspicious combinations for manual review: a fried dish
   with no 1 (breading?), a cream soup with no 7, a dish with a
   dumpling and no 3
Return a report: matches, mismatches, suspicions. Don't change
anything.

In the folder photos-unsorted there are about 200 dish photos from
the past six months. Go through them and:
1. Sort them: usable (sharp, dish recognizable, tolerable light) /
   fixable (good photo, bad crop or exposure) / discard
2. For the usable and fixable ones, identify which dish from our
   menu is in each (compare against the names in
   standing-menu.yaml and old weekly menus), and suggest renaming
   to dish-name.jpg
3. List dishes from the menu that have no photo at all — that's the
   shot list for coming weeks
4. Don't delete or rename anything until I approve the proposal

Here are our five best dish photos [attach them]. Propose one
consistent editing recipe that turns them into a visually
coherent set: crop (a consistent aspect ratio for the website and
for Instagram), exposure, color temperature (our window-light
photos run cool/blue — how much should that be pulled back?),
contrast, and optionally light sharpening. Describe the recipe as
steps that can be repeated on every future photo.
IMPORTANT — the boundaries of editing: brightness, color, crop,
removing distracting background AROUND the plate — yes; anything
that changes the food itself (adding ingredients, enlarging the
portion, "improving" how the dish looks, generating steam that
wasn't there) — no. The photo has to show the dish exactly as we
serve it.
Apply the recipe to these five photos and show me before/after.

Here are new reviews from our bistro's Google profile [paste the
text, including star ratings]. Based on voice.md, draft a reply to
each:
- positive: thank them SPECIFICALLY for what the reviewer mentioned
  (the dish, the service, the cake), no generic phrases; one or two
  sentences is fine
- mixed: thank them for the praise, address the criticism
  specifically — what we'll do about it, no excuses
- critical: no defensiveness, no irony; acknowledge what can
  honestly be acknowledged, explain without dodging what can be
  explained, and offer them my direct contact
For each draft, add a risk rating: where you're not sure about the
context (does it mention a specific shift? a specific person?),
flag it — there I need to know what actually happened before I
reply.
These are drafts. Don't send anything.

This review is bothering me because I think it's unfair [paste the
review and MY take on what actually happened]. Help me reply in a
way I won't regret a week from now:
1. First, tell me how a stranger with no background is likely to
   read this review — what it implies to them about our business
2. Draft a reply that: doesn't dispute the guest's experience,
   states our side of it factually WITHOUT assigning blame, and
   closes with a direct invitation to resolve it; stay in
   voice.md, but dial down the humor
3. List what from my take on the situation does NOT belong in the
   public reply (internal details, anything about other guests,
   legal threats)
I'll let the reply sit until tomorrow and send it myself.

Here are all the reviews from the past three months [paste them, or
point to the folder]. Turn them into an operational overview:
1. What gets praised repeatedly (dishes by name, service, ambience)
   — ranked by frequency
2. What gets criticized repeatedly — same thing; separate one-off
   incidents from patterns (three mentions of "long wait on
   Tuesdays" is a pattern)
3. Which dishes from the menu get mentioned in reviews and which
   never do — compare against standing-menu.yaml
4. Suggest a maximum of three concrete actions: what to feed back
   into the menu (the source!), what into operations, what to
   ignore
No marketing optimism — I want to know what isn't working.

I'm getting ready for a standing-menu price change. Here's
standing-menu.yaml, and here are notes on how much our key
ingredients have gone up over the past six months [paste actual
figures — purchases, not estimates].
1. Propose three price-change options: cautious (only dishes where
   margin dropped the most), moderate, and full; list the changes
   per dish for each
2. Round to prices that look natural on a menu
3. For each option, describe how it will read to a regular who's
   been coming for lunch for years — what will jump out at them
4. Check the menu's internal logic: soup shouldn't cost more than a
   small main, keep desserts below the mains
I'll pick the option and scope — then prepare the change to
standing-menu.yaml as one proposal to review, not dish by dish.

You have read-only access to the spreadsheet reservations-ulipa.
Every day at 9:00 AM, prepare a summary for today:
1. Reservations sorted by time: time, name, party size, note (cake?
   high chair? celebration?)
2. Flag conflicts: two reservations for the same table, a
   reservation bigger than our largest table (8), a reservation for
   a time we're closed — that's usually a typo in the date
3. A running total of seats booked for lunch against capacity (30)
   — if reservations are blocking more than half, note it, so
   staff hold back some free tables for walk-ins
Don't write anything into the spreadsheet — logging a new
reservation is done by whoever answered the phone. Send me the
summary and it gets printed at the bar.

Do a security review of our menu and reservation system:
1. List who has what access to the ulipa-menu repository and to
   shared folders (the reservations spreadsheet, photos) — flag
   access nobody has used in over 3 months, and people who no
   longer work here
2. Check that the repository connected to the website contains no
   recipes, cost calculations, or personal data — go through the
   commit history too
3. Verify the backup situation: when was the last one, and could
   Monday's printed menu be restored from it?
4. List connected connectors and AI access (Buffer, the photo
   editor, spreadsheets) and what permissions each has — what's
   broader than it needs to be?
Return findings ranked by severity, with a suggested fix. Don't
change anything without approval.