# Event Data > Guide for handling event data. Use when asked to update event data such as CFPs, Talks, Schedule, Sponsors, Involvements, or Videos. Use when updating any file in the /data/ directory. - Skill: `rubyevents/event-data` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add rubyevents/event-data` - Raw SKILL.md: https://api.skillmd.com/api/skills/rubyevents/event-data/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: rubyevents (https://skillmd.com/u/rubyevents) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/rubyevents/event-data --- # Important Notes If something is unclear, use the AskUserTool to ask for clarification. **Always use the generators of MCP tools 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 generator 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. **NEVER generate content, titles, links, or descriptions.** Pass no value for those parameters, and the generator will create a TODO for someone else to fill out later. # Workflow - [ ] Identify the event slug that you need to update. - [ ] If the user did not provide an event slug, use the EventLookupTool to find the correct event. - [ ] 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. - [ ] If you were unable to make the change with a generator or MCP, leave a comment in the PR description explaining why you were unable to use the generator or MCP. - [ ] Each generator has a rubyevents MCP tool associated with it. You can use the MCP tools in place of the generators. - [ ] Run `bin/rails validate:all` to confirm that the structure of the file is correct. - [ ] Run `yerba apply` to lint the yaml files. - [ ] Call `bin/rails db:seed:event_series[]` to populate the database with the updated event data. - [ ] Start the dev server with `bin/dev` to review the changes locally. - [ ] Commit the changes. - [ ] Take a screenshot with playwright of any pages that were affected by the update. - [ ] Create a PR on the rubyevents/rubyevents repo using the .github/pull_request_template.md and include the screenshots in your PR description using the gh-image extension for GH. # Adding Event Data with the Generators ## Adding a new Event **Events must be created first** 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. ```bash 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 new CFP Run `bin/rails g cfp --help` to review the available parameters for the CfpGenerator. Create a command to reproduce the CFP. ```bash bin/rails g cfp --event wnb-rb-meetup --name "WNB.rb Meetup Talk Proposal" --open-date "2026-08-17" --link "https://docs.google.com/forms/d/e/1FAIpQLSdmOJxLdSdy74mXYxsr6ZRRhTN95Yxnq2B6n5mhUoGkVmDUGA/viewform" ``` If you create a CFP, capture a screenshot from http://localhost:3000/events//cfps after the changes are seeded. ## 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". ```bash bin/rails g talk --event ruby-community-conference-winter-edition-2026 --speaker "Chris Hasiński" --title "Doom" --kind lightning_talk ``` 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. If you create talks, capture a screenshot from http://localhost:3000/events//talks after the changes are seeded. ## Removing a talk `bin/rails validate:videos` fails when a talk id disappears from a `videos.yml`, because a vanished id is usually an unrecorded rename and production still knows the talk under the old id. - **Renamed?** Keep the previous id on the renamed entry as `old_id` so its record is migrated on the next seed. `bin/rails talk_ids:backfill_old_ids` writes it for you. - **Removed on purpose?** List the id under `removed_talk_ids` in the event's `event.yml` (it lives there because `videos.yml` has a sequence root and cannot hold a top-level key): ```yaml # data/kaigi-on-rails/kaigi-on-rails-2026/event.yml removed_talk_ids: - "dave-thomas-kaigi-on-rails-2026" ``` ## Generating a Schedule Load Documentation from docs/ADDING_SCHEDULES.md into context. Call the help command and review the available parameters for the ScheduleGenerator. ```bash 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. If you create a schedule capture a screenshot from http://localhost:3000/events//schedule after the changes are seeded. ## 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. If you create a sponsor capture a screenshot from http://localhost:3000/events//sponsors after the changes are seeded. ## 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. ```bash bin/rails g venue --event "sfruby-2026" --name "SF Jazz" \ --address "201 Franklin Street San Francisco, CA 94102" \ --website "https://www.sfjazz.org/" ``` If you create a venue capture a screenshot from http://localhost:3000/events//venue after the changes are seeded. ## Speakers When updating speakers.yml, the structure is: ```yaml - name: "Speaker Name" github: "github_handle" slug: "speaker-name" ``` 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:** 1. Prefer the speaker's parameterized name as the slug (e.g., `slug: "chris-hasinski"` for `name: "Chris Hasiński"`). 2. If the name cannot be parameterized cleanly, use the speaker's GitHub handle as the slug (most common with Japanese names, eg. "河野十行", slug: "jugyo"). 3. Only transliterate when the speaker has no GitHub handle. If the GitHub is unknown: ```yaml - name: "Speaker Name" github: "" slug: "speaker-name" ``` If the speaker has multiple aliases, they'll be included as aliases. ```yaml - name: "Speaker Name" github: "github_handle" slug: "speaker-name" aliases: - name: "Other Name" slug: "other-name" ``` To update a speaker programmatically, use `Static::SpeakersFile` with a rails runner: ```bash bin/rails runner 'file = Static::SpeakersFile.new; speaker = file.find_by(name: "Speaker Name"); speaker["github"] = "github-handle"; file.save!' ```