I manage marketing for GitHub across Japan and Korea, where events drive the strategy. We host recurring webinars for enterprise developers, community meetups in Tokyo, and invite-only executive sessions in Seoul. I spend my days deciding which topics deserve an hour of a developer’s time and who should attend. The work after the decision is where the real labour begins.
Once an event is approved, a fixed sequence follows:
- Duplicate a landing page on our event platform.
- Generate UTM-tagged links for each channel.
- Draft the invitation email and file a request with the sending team.
- Add the event to two project boards.
- Download and clean the registrant list every morning until the event to update stakeholders.
- After the event, export attendees, reshape the list for a CRM upload, tag records, and write a report.
These tasks are simple individually. Together they create opportunities to paste the wrong link, skip a day, or misspell a campaign name that affects 15 downstream reports.
I used to be an engineer. My first career involved keeping databases alive on Linux servers for enterprise customers. My coding skills may be rusty, but I still see a pipeline begging for automation. This is where I use GitHub Copilot and where you can too.
I did not write the code. I wrote down my runbooks, handed them to GitHub Copilot, and grew the automation in conversation. Today, an event that used to take me a couple of days sets itself up from a single GitHub Issue. It screens its own registrants every morning and cleans up after itself when it is over.
This post explains the process. It applies to anyone whose job involves repetitive work across tools that offer a scriptable way in, whether that is an API or a command line interface.
An event is an issue
Marketing teams at GitHub already opened one GitHub Issue per project. This became the place where the plan, discussion, and status lived. The issue was the unit of work. I made the issue do the work.
Three GitHub primitives carry the whole system:
- Issue forms are the application form. An issue form presents structured fields: event title, date, region, campaign name, target audience. We have one form per event type, such as webinars and in-person events, and they feed the same machinery.
- Labels are the switches. A label like
event-setupis not a tag, it is a trigger. Each automation workflow starts with a condition that runs only when that label is present. - Actions are the machinery. GitHub Actions workflows fire when labels land, parse the form fields out of the issue body, and go do the work.
Everything a repository gives developers, it gave my marketing workflow for free: history, visibility, review, and a URL for every decision.
One thing made this possible: our event management platform exposes an API. Our CRM does not even need one; its official CLI covers everything we do. I never configured an API key for it because the CLI signs in through the browser and handles authentication from there. API or CLI, the requirement is the same: a scriptable way in. If your repetitive work runs through a tool that offers either an event platform, a CRM, a form builder, or an analytics service, the pattern in this post applies to you.
A developer reading this may already be composing the obvious objection. Marketing automation platforms exist, and a good one might have covered some of this out of the box. But APAC is less one market than a collection of very different ones. Even within my own team, workflows shift with each sub-region and each segment. The same webinar might run in Japanese for Tokyo one month and in Korean for Seoul the next, with different segments, different fields in the CRM, and a different definition of a good lead. Getting a packaged tool to absorb all of those variations means customization budgets, consulting hours, and waiting on someone else’s roadmap. Building it ourselves, from the tools already at hand, means a workflow change is a pull request. I describe what I want, a reviewer checks it, and it lands on the main branch through exactly the process developers use to change software.
Planning an event is a conversation
The pipeline starts before the Issue exists. I open GitHub Copilot and say, roughly: “I want to run a webinar about AI-assisted development in November.”
What happens next is shaped by a file called AGENTS.md at the root of our repository. It is our team runbook, written in plain Markdown, that defines how we name campaigns, how fiscal quarters map to dates, which time zone each region uses, and what a good invitation email looks like. GitHub Copilot reads it, finds a similar past event, proposes a campaign name that follows our naming rules, drafts two versions of the invitation email, and asks me the questions the runbook says to ask.
Putting a conversation at the front of the pipeline was a design decision. It solved two problems at once. Automate everything, and you lose flexibility. The day you want this one event to be slightly different, a rigid pipeline has no place to say so. But if you let humans fill in everything, you get mistakes. The conversation sits exactly between the two. GitHub Copilot follows the template, so the data that lands in the Issue is the right data in the right format. And because it is a conversation, I can bend the details for this one event without breaking the machinery downstream.
When we started, this conversation happened in GitHub Copilot CLI, in a terminal. That was fine for me, but “open a terminal” is a barrier for many people I would love to bring into this workflow. With the GitHub Copilot app, the same conversation now happens in a regular desktop window. The barrier to entry dropped from “comfortable with a shell” to “can type.”
I want to be precise about the division of labor because it is the whole point: GitHub Copilot drafts; I decide. Every campaign name, every email subject line, every date gets my sign-off before anything moves. At the end of the conversation, GitHub Copilot files the GitHub Issue with the right labels, and that is when the machines take over.
One label, one event, fully staged
The moment the event-setup label lands on the issue, a GitHub Actions workflow picks it up and does, in a few minutes, what used to take me the better part of a day:
- Duplicates a past event on our event platform to create the new landing page
- Generates the full set of UTM-tagged URLs: one per channel, consistently formatted, every time
- Produces the invitation email as a Word document and commits it to the repository
- Opens request Issues with the teams that send emails and track regional marketing
- Adds the event to our project boards and fills in the fields
- Posts a summary comment back on the Issue, so the next human who opens it sees everything in one place
Registration screening runs on a schedule instead of a label. Every morning, a cron-triggered workflow fetches the latest registrants for every open event and shares the cleaned-up list. For invite-only events, it also screens the waitlist against our criteria (is this registrant a developer at an enterprise account, a student, or a competitor who would very much like to attend our executive briefing?) before anyone gets approved.
The design decision I am most proud of is a single on/off switch called DRY_RUN, stored as a setting (in GitHub terms, a repository variable) that every workflow checks before it runs. Flip it on, and every workflow goes through the motions without touching any external system: no landing pages created, no issues filed in other repositories, no lists shared. When you are a team of marketers automating your own job, you need a way to rehearse. DRY_RUN is the rehearsal switch, and it is the reason I was never afraid to experiment.
After the event, a slash command
Post-event work used to be the worst part: exporting attendees, reformatting columns for the CRM upload, matching company names against account records, and writing the report. Now it is two commands.
/lead-upload fetches the attendee list, shapes it into the exact format our marketing operations team needs for a CRM upload, files the request Issue, and closes out the tracking issues. /event-report pulls attendance metrics and survey results and posts a report as a comment on the event’s Issue, back to the one URL where everything about this event lives.
These are GitHub Copilot agent skills. A skill is a Markdown file. Each one is a SKILL.md: a written procedure, in prose, that tells GitHub Copilot what to do, in what order, and what to watch out for. Mine read like the runbooks I used to keep in my head because that is what they are.
If you can write a runbook, you can write a skill.
Skills are also what keeps the system flexible. No two markets in the Asia/Pacific region run their follow-up identically. Audiences differ, segments differ, local conventions differ, and a hard-coded workflow would force every market into one shape. A procedure written in Markdown is flexible: each market can adapt the runbook to its own reality without touching the machinery underneath. That is precisely why the post-event steps live in GitHub Copilot skills rather than in fixed pipelines.
We treat skills like code in one respect: new ones arrive by pull request and get reviewed before they are merged, with a CODEOWNERS file routing the review to a maintainer. Marketing automation with an approval process. The governance came free with the platform, too.
What it means
This approach removes the manual steps that cause errors in repetitive tasks. It allows marketers to build custom workflows for specific regions without waiting for a vendor to update their software. The system remains flexible because the logic lives in readable documents rather than locked code. Review processes ensure safety without slowing down the ability to adapt to local needs.
