# Event Data > Event Data is an Agent Skill for documents published in the rubyevents/rubyevents repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task. 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 name: `event-data` - Category: [Documents](https://www.openparable.com/skill/documents/1) - Source: https://github.com/rubyevents/rubyevents/blob/HEAD/.agents/skills/event-data/SKILL.md - Repository: rubyevents/rubyevents (555 GitHub stars when collected) ## SKILL.md # 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[]` 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. ```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 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 ``` 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. ```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. 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. ```bash 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: ```yaml - 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: ```yaml - name: "Speaker Name" github: "" slug: "speaker-slug" ``` If the speaker has multiple aliases, they'll be included as aliases. ```yaml - 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: ```bash bin/rails runner 'file = Static::SpeakersFile.new; speaker = file.find_by(github: "handle"); speaker["slug"] = "new-slug"; file.save!' ``` --- Source: https://www.openparable.com/skill/documents/event-data (OpenParable). Cite the canonical URL above.