event-data

Important Notes

If something is unclear, use the AskUserTool to ask for clarification. Always use the generators if possible. The generators will create a file with the correct structure, and will help you avoid formatting errors. If you do not have a parameter for the generator, do not pass it as a parameter. The generaator will create a reasonable default or TODO for someone else to fill out later. Do not delete TODO comments generated by the generator unless specifically instructed to do so.

Workflow

1. Identify the event series and event that you need to update. If the user did not provide an event series and event, use the EventLookupTool to find the correct event and EventSeriesLookupTool to find the correct event series.
2. Determine if the update can be made with a generator. If so, use the appropriate generator to make the update. If not, make the update manually in the appropriate file. The generators and how to use them are documented below.
3. Run bin/lint to confirm that the structure of the file is correct.
4. Call bin/rails db:seed:event_series[<event-series-slug>]
5. Start the dev server if needed with bin/dev to review the changes locally.
6. Take a screenshot with playwright of any pages that were affected by the update, and include the screenshots in your PR description.

Adding Event Data with the Generators

Adding a new Event

Reference the documentation in docs/ADDING_EVENTS.md if needed.

Run bin/rails g event --help to review the available parameters for the EventGenerator.

Create a command to reproduce the event.

bin/rails g event --event-series ruby-community-conference --event ruby-community-conference-winter-edition-2026 --name "Ruby Community Conference Winter Edition 2026" --venue-name "TBD" --venue-address "TBD"

Adding a talk

Review documentation in docs/ADDING_UNPUBLISHED_TALKS.md.

Run bin/rails g talk --help to review the available parameters for the TalkGenerator.

Create a command to reproduce the talk.

For example, if the user says "Create a lightning talk from Chris Hasiński, the title is Doom, and it's for the Ruby Community Conference".

bin/rails g talk --event ruby-community-conference-winter-edition-2026 --speaker "Chris Hasiński" --title "Doom" --kind lightning_talk

If the rubyevents MCP is available, and the user did not provide an event series slug and event, use the EventLookupTool to find the correct event.

Call the generator once per talk, and do not attempt to create multiple talks in one command.

Do not pass --id when adding a new talk. Talk ids follow the "firstname-lastname-event-slug" convention (enforced by bin/rails validate:videos), and the generator derives the correct id from the speakers, kind, and title, avoiding ids already taken in the file. Only pass --id to update an existing talk: the generator updates the entry with that id, and fails with a list of available ids when it doesn't exist.

Run bin/lint once all talks are added to confirm the structure.

Generating a Schedule

Load Documentation from docs/ADDING_SCHEDULES.md into context.

Call the help command and review the available parameters for the ScheduleGenerator.

bin/rails g schedule --help

Create a command to approximate the schedule provided by the user.

Modify the yaml file to match the schedule exactly.

Run bin/lint to confirm the schedule structure.

Generating a Sponsors file

Reference the documentation in docs/ADDING_SPONSORS.md if needed.

Run bin/rails g sponsors --help to review the available parameters for the SponsorsGenerator.

Create a command for each sponsor to add or update their details.

Once all sponsors are added, run bin/lint to confirm the structure of the file.

Generate a Venue file

Review Documentation from docs/ADDING_VENUES.md.

Run bin/rails g venue --help to review the available parameters for the VenueGenerator.

Create a command to reproduce the venue.

bin/rails g venue --event "sfruby-2026" --name "SF Jazz" \
  --address "201 Franklin Street San Francisco, CA 94102" \
  --website "https://www.sfjazz.org/"

Speakers

When updating speakers.yml, the structure is:

- name: "Speaker Name"
  github: "github_handle"
  slug: "speaker-slug"

Other fields are permitted, but these are the fields I want you to focus on. The GitHub handle is how we deduplicate speakers, and populate their profile, so the key should always be present. These speakers are used for talks and involvements, so if a speaker is missing, you need to create a new record for them here.

Slug convention: Prefer the speaker's GitHub handle as the slug (e.g., slug: "tenderlove" for github: "tenderlove"). Only transliterate or generate a slug from the name when the speaker has no GitHub handle.

If the GitHub is unknown:

- name: "Speaker Name"
  github: ""
  slug: "speaker-slug"

If the speaker has multiple aliases, they'll be included as aliases.

- name: "Speaker Name"
  github: "github_handle"
  slug: "speaker-slug"
  aliases:
    - name: "Other Name"
      slug: "other-slug"

To update a speaker programmatically, use Static::SpeakersFile with a rails runner:

bin/rails runner 'file = Static::SpeakersFile.new; speaker = file.find_by(github: "handle"); speaker["slug"] = "new-slug"; file.save!'