A conference as a system: one program that generates everything

We're running the first edition of a one-day industry meetup: [120] attendees,
[2] rooms, [12] speakers, [10] program sessions, date [fill in],
venue [fill in]. Two of us are organizing it in our spare time, no agency.

List the complete set of outputs an event like this needs, from reaching
out to speakers through the follow-up email. For each one, give:
1. What data it's derived from (program, registration list, copy
   about the event, venue map…)
2. Deadline relative to the event date (e.g. "print: D-5, because the
   printer needs 3 business days")
3. Format (web, print PDF, social image, email, slides)
4. What happens if the program changes after this output has been produced

Sort by deadline. Flag any outputs that can't be changed once printed —
I'll plan a buffer for those.

Design a program data structure for a one-day event with two rooms.
I need two entities:

Speaker: id, name, company/role, short bio (400–600 characters), photo
(filename), talk topic, abstract (500–800 characters), contact,
consent to being photographed and filmed (yes/no), consent to
publishing materials after the event (yes/no), communication status
(contacted / confirmed / materials received / complete).

Session: id, start, end, room, type (talk / workshop / panel /
break / logistics), title, list of speaker ids (can be empty or
have several), a note for the MC.

Design it as YAML files for a git repository (program.yaml plus a
speakers/ folder with one file per speaker), and show me a filled-in
example of one speaker and three sessions including a break. Explain
why it's better to keep speakers separate from sessions. Also propose
rules for which fields are required and which can be filled in later.

Here is program.yaml and the speakers/ folder [paste the contents or
let it load from the repository]. Check consistency and list every
finding with its exact location:
1. Times: do any sessions in the same room overlap? Do they run back
   to back, or are there unplanned gaps? Does the sum of durations
   match each room's start-to-end time?
2. Speakers: is anyone in two sessions that overlap or run back to
   back in different rooms (no time to walk over)? Does the program
   reference a speaker id that doesn't exist?
3. Completeness: which speakers are missing a bio, photo, abstract,
   or consents? Which sessions have no speaker even though their
   type calls for one?
4. Breaks: is there anywhere more than 120 minutes of program with
   no break?
Don't fix anything — return the list of findings, I'll fix them
myself and then we'll run the check again.

Draft a speaker outreach template for our event. Context: [first
edition of an industry meetup for whom, date, venue, 120 attendees,
2 rooms]. We can't offer a speaker fee; we offer [travel costs,
lunch, an audience made up of…, a recording of the talk, …].

Structure:
1. One sentence on why we're reaching out to this specific person —
   leave a [SPECIFIC REASON] placeholder that I'll fill in by hand
   for each one, because this sentence must never be generated
2. What the event is and who it's for (brief, no superlatives)
3. What exactly we want from the speaker: format, length, deadline
4. What we're offering — straight talk, including that there's no fee
5. A clear question at the end with a reply-by date [date]
Tone: collegial, concise, no "we would like to cordially invite."
Also prepare a version for a speaker we already know personally.

Go through the files in the speakers/ folder and return a status
report:
1. A table: speaker, status, date of last change, what's specifically
   missing (bio / photo / abstract / consents / confirmation)
2. Anyone stuck in "contacted" for more than 10 days → draft a
   reminder; polite, short, with a specific deadline after which
   we'll start looking for a replacement (phrased without any blame)
3. Anyone "confirmed" for more than 14 days with no materials →
   draft a reminder listing exactly the items still missing from them
4. Count: how many speakers are complete, how many sessions still
   have no confirmed speaker
List the draft emails for me to approve — I'll send them myself.

Write an email to a confirmed speaker requesting materials. We need:
1. A bio, 400–600 characters, third person ("Jana leads…"), focused
   on what's relevant to our audience
2. A landscape and a portrait photo, usable at [min. resolution],
   without a busy background
3. A talk title (max 60 characters, for print) and an abstract,
   500–800 characters — what the audience will take away, not an
   outline
4. Consent, worded exactly as follows: being photographed and
   filmed during the talk; publishing the slides after the event
5. Technical requirements (own laptop? audio? anything else)
Deadline: [date]. Add a line that we're happy to edit the bio and
abstract — a rough draft is fine, we want to lower the barrier to
replying.

Propose three visual directions for our event's identity: [name, field,
date, one-day meetup for 120 people]. Character of the event:
[community-driven, practical, no corporate polish — fill in your own
words]. For each direction, describe:
1. A pair of colors (specific hex codes) and why it still works in
   black-and-white print — the signage will be printed on an
   ordinary office printer
2. A pair of fonts with a free license for print
3. A visual motif that can repeat on the poster, the name badge, and
   a slide, and is simple enough for an amateur to maintain in Canva
4. One sentence on what impression the direction should create
No direction may depend on photos we don't have. Pick the one you'd
recommend for the first edition yourself, and justify it.

Using the Canva connector, build a template family for our event
based on the attached visual.md (colors, fonts, motif):
1. Portrait poster — large event name, date, venue, room for 6–8
   speaker names, a QR code (placeholder) and the website
2. A5 printed program — cover + inside spread with two columns
   (main room / workshops), program row: time, title, speaker
3. Name badge [width x height per the holders] — large first name,
   smaller last name and company, a colored stripe by role
4. A4 portrait room-door sign — room name and its session list
5. A4 landscape directional sign — an arrow and one line of text
6. 16:9 break slide — large clock, "next session starts at…"
Use bracketed placeholder text everywhere, no made-up names. Send
me links to the designs — I'll fine-tune them myself in the editor.

From the attached program.yaml, generate break-slide content, for
each room separately. One slide per break, with the text:
1. "Break until [time]"
2. "Up next in this room: [session title] — [speaker] at [time]"
3. "In the other room: [session title] — [speaker]"
4. Wi-Fi network and password, event hashtag
Add one "We're starting soon" slide for the morning and one closing
slide with thanks and a QR code to the feedback form. Return it as a
table (room, order, lines of text) — it'll be poured into the Canva
slide template. Check the times against the program and flag it if
the breaks in the two rooms don't start at the same time.

Build a simple website in the event repository (one page, static,
will run on Vercel). The key rule: all content about the program and
the speakers loads from program.yaml and the speakers/ folder at
build time — no name, time, or talk title may be hardcoded anywhere
in the website's code. Structure:
1. Intro: name, date, venue, a one-sentence "who this is for," a
   registration button [link]
2. Program: two columns by room, row = time, title, speaker; breaks
   visually distinct
3. Speakers: a card grid from speakers/ — photo, name, company,
   topic; bio and abstract on click-through
4. Practical info: address with a map, public transit, Wi-Fi, contact
Look and feel per visual.md. Speakers with no supplied photo should
show a uniform placeholder image, not a broken image icon.

Check the website against the source data before we publish it:
1. Compare the program as rendered on the website with program.yaml —
   every session, time, room, and name. List every difference.
2. Verify there's no speaker on the website whose data status is
   below "confirmed" — nobody may be published before they've
   confirmed their participation.
3. Go through every link (registration, map, contacts) and list
   where each one leads; flag broken or placeholder links.
4. Check the mobile view: people read the program on their phone
   while waiting in line for coffee — the two columns must stack.
Don't report "all good" until you've stated how many sessions and
speakers you actually compared.

Design a registration form for a one-day industry meetup (120 seats,
ticket price [amount/free]). I want the smallest possible set of
fields — for each field, write down exactly what I'll use it for
when organizing, and drop it if you can't find a use. Consider:
name, email, company/role (for the name badge), dietary restrictions,
"how did you hear about us," photography consent, anything else
typical.
Also propose:
1. Copy above the form: who processes the data, for what, how long
   we keep it, and when we delete it — plain language, not legalese
2. Behavior once capacity is reached: copy for the waitlist and a
   process for reaching out to them when a spot opens up
3. Confirmation email copy (see below)
For each point, add a note on what I shouldn't underestimate.

Prepare two emails for attendees, pulling data from program.yaml and
the event website — don't write any time or address from memory:
1. Registration confirmation: confirms the spot, date and address, a
   link to the website with the program, one sentence about data
   processing with a link, our contact. Short — five sentences.
2. Email 3 days before the event: when check-in opens and when the
   program starts (two different times, call this out), how to get
   there [public transit, parking], what to bring, Wi-Fi, hashtag, a
   link to the program, and a line about photography at the event
   with the option to opt out (see our GDPR notes).
Both: friendly tone, no exclamation points, subject line under 50
characters. Return them as templates with [NAME] fields for a mail
merge.

Build a simple check-in system for the door. Registrations live in
[a spreadsheet / Supabase]. I want:
1. A unique code and QR image generated for each registration, to be
   embedded in the pre-event email
2. An internal /checkin page (logged-in organizers only): scan the
   QR with a camera or search a name by hand, mark arrival with one
   tap, a running counter of check-ins at the top
3. Handle: a repeated scan of the same code (warn, don't double-log
   it), on-site registration (a "new registration" button with a
   minimal set of fields), works on a phone
4. Export: after the event I want a list of who showed up / didn't,
   for evaluation and follow-up
Also generate a backup alphabetical list as a PDF in case of an
outage. The page must not be publicly accessible — explain how it's
secured.

Prepare the data for printing name badges. Sources: the registration
export [paste], the speakers/ files, and the list of organizers and
volunteers [paste].
1. Standardize the format: First LAST, company/role. Fix obvious
   capitalization typos (jan novak → Jan Novak), but for ambiguous
   cases (McDonald, double surnames, names with a preposition) don't
   change anything — list them for me to decide by hand.
2. Don't fix or add diacritics or accents — a name is however the
   person wrote it themselves. Only flag suspicious cases for me
   (Novak next to Nováková).
3. Add a role column: attendee / speaker / organizer / volunteer —
   the template colors the stripe by this.
4. Drop duplicate registrations (same email) and list them.
5. Sort by last name and return a CSV for the bulk template fill,
   plus counts by role.
Don't silently fix anything in the data — list everything you change.

From program.yaml and a description of the venue [describe: entrance,
stairs, floor, two rooms, coat check, restrooms], generate:
1. Content for the room-door signs: room name, morning and afternoon
   sessions with times and speakers
2. A list of directional signs: from where to where, what text, and
   which way the arrow points — walk the attendee's path from the
   entrance to every destination and find the spots where they'd
   hesitate
3. A print checklist: every print piece, quantity, format, color or
   black-and-white, where it's printed [home printer / copy shop],
   deadline relative to the event, and who hangs it where
For each sign, also add "when to take it down" — after the event we
have to leave the venue clean.

I made this change in program.yaml: [session 07 — Jana Svobodová
cancelled, her topic replaced by Tereza Malá's from session 09; a
moderated discussion, led by Marek, now runs in session 09 in the
small room instead].
Go through the outputs inventory and list EVERY output this change
affects, split into:
1. Digital — can be regenerated right away (website, break slides,
   scheduled posts, MC notes, …): for each one, exactly what changes
   in it
2. Printed or already sent — can't be taken back (posters, the
   program, name badges, confirmed emails): for each one, propose a
   mitigation (reprint, a correction sticker, an announcement on
   site in the morning)
3. People who need to be actively told about the change (both
   affected speakers, both rooms' MCs, the person at check-in) —
   for each one, draft a short message
Don't change or send anything, just return the list to work through.

From program.yaml and the speakers/ folder, propose a posting plan
for the [6] weeks leading up to the event, for [LinkedIn and X /
fill in your channels]:
1. Speaker announcements: one at a time or in pairs, text drawn from
   the bio and abstract — not marketing copy, but one specific thing
   the audience will take away; make sure the phrasing doesn't
   repeat across posts
2. Milestones: program published, registration opens, "20 spots
   left," final week
3. Practical: a post with the program a week before the event, a
   "what we're looking forward to + practical info" post the day
   before
For each post: channel, suggested date and time, text, what image to
produce for it from the Canva template (what should be on it).
Only plan posts about speakers whose status is "confirmed" or
further along. Return it as a table for me to approve — don't
schedule anything yet.

Prepare skeleton posts for the day of the event, from program.yaml:
1. Morning: "we're starting" — with the day's program and the
   hashtag
2. An optional skeleton for each session: speaker, topic, an empty
   slot for [QUOTE OR MOMENT] — to be filled in on the spot with one
   sentence
3. Breaks: thanking partners [list], a hashtag reminder
4. Closing: thanks, an announcement of when slides and photos will
   be up, a call to "tell us what you're taking away"
Short copy, no corporate tone. Save them as drafts in Buffer, ordered
by session time — I'll publish them manually based on how the day
actually goes.

From program.yaml and speakers/, generate MC notes, for each room
separately, one sheet per session:
1. Header: start–end time, title, speaker, hard stop (when the
   discussion has to end to keep the program on schedule)
2. A 20–30 second speaker introduction: pull one specific interesting
   fact from the bio, no reading out a résumé; write it as spoken
   language (it'll be said out loud, not read)
3. Pronunciation: for names and company names an MC might stumble
   on, write a guide [I'll confirm with the speakers]
4. Three discussion questions in case of silence: drawn from the
   abstract, specific, no "what advice would you give beginners"
5. Handoff: one sentence on what comes next (next session / break
   until when / move to the other room)
At the end of every sheet: mc_note from the program, if it exists.
Print format, large type — it gets read standing up in the dark.

Prepare four versions of the post-event follow-up email. Data:
check-in records (who showed up), program.yaml, links [slides,
photo gallery, feedback form]:
1. Attendees (showed up): thanks, a link to the slides (only talks
   where the speaker consented to publication — check the consent
   field and list for me whose slides we must not publish), the
   photo gallery, the feedback form (one sentence on why and how
   long it takes), a mention of the next edition with an option to
   sign up for updates
2. Registrants who didn't show: brief, no guilt-tripping — what they
   missed (two highlights), don't send slides or the feedback form,
   offer to sign up for updates
3. Speakers: a personal thank-you with a specific moment from their
   session [I'll fill in the sentence for each one myself], a
   request for feedback on how the event was organized, info on when
   and where the slides and photos will be
4. Partners and volunteers: thanks with numbers (attendance,
   capacity filled) and a photo; for partners, offer a short summary
   for their internal communications
Return all four versions to me for editing — I'll send them within
48 hours of the event.

Evaluate the event from three sources: the feedback form export
[paste], check-in data (registered vs. showed up, "how did you hear
about us" source), and our notes from the day [paste as bullet
points, whatever we remember].
1. Numbers: attendance and capacity filled, feedback form response
   rate, rating distribution, most common registration source —
   each number with one sentence of interpretation, no charts for
   the sake of charts
2. Voices: summarize the open-ended answers into themes, with a
   mention count and one verbatim quote per theme; separate praise
   from criticism, and don't soften the criticism
3. Contradictions: where the feedback form and our own impressions
   disagree (we thought the session went well, the ratings are
   lukewarm) — just flag it, we'll draw the conclusion
4. A draft "what next time" document: keep / change / drop / try,
   each point backed by the sources above
We'll save the document in the event repository next to the program
— it's the first file we'll open when we start preparing the second
edition.

One month after the event: go through every place event-related
personal data lives, and propose a cleanup. Sources: the
registration spreadsheet/database, email templates and sent
campaigns, name-badge exports, check-in records, the feedback form,
the photo gallery, the event repository.
1. List every location, what data it holds, and what it's still for
2. Propose: delete now (dietary restrictions, name-badge exports, QR
   codes) / anonymize and keep for statistics (counts, registration
   sources, ratings with no identifying info) / keep with a reason
   (contacts who opted into updates — only those who consented;
   speaker materials for the next edition — ask them first)
3. Check that no exports containing personal data are committed in
   the repository — check the history too
4. Return a deletion checklist; I'll do the deleting by hand, not you
Outcome: after the cleanup, we can say in one sentence whose data we
hold and why.