Repetitive work across multiple tools can be transformed into automation if you can document the process. That's the approach one GitHub marketing leader took to streamline event management for the company's Asia-Pacific region.

Running marketing for GitHub in Japan and Korea centers on events: recurring webinar series aimed at enterprise developers, community gatherings in Tokyo, and exclusive executive sessions in Seoul. The strategic decisions—what developers need, which topics merit their time, who should attend—are the rewarding part. What follows is a fixed sequence of mechanical tasks: duplicating landing pages, generating UTM-tagged links for each channel, drafting invitation emails, updating project boards, downloading and cleaning registrant lists each morning, and after the event concludes, exporting attendees, reformatting data for CRM upload, tagging records, and writing reports.

Each individual step is straightforward, but the sequence creates opportunities for error—pasting the wrong link, missing a day, misspelling a campaign name that 15 downstream reports depend on. The solution came from recognizing the problem through a developer's lens. The author's first career involved maintaining databases on Linux servers for enterprise customers. Though coding skills had grown rusty, the pattern was unmistakable: a pipeline begging for automation. Rather than writing code from scratch, the author documented existing runbooks and used GitHub Copilot to build the automation through conversation. Today, an event that once required manual assembly over several days sets itself up from a single GitHub Issue, screens registrants automatically each morning, and cleans up when finished.

An event is an issue

GitHub's marketing teams already followed a practice of opening one GitHub Issue per project, making it the central location for planning, discussion, and status updates. The innovation was making the issue itself execute the work.

Three GitHub primitives power the system:

  • Issue forms serve as the application interface. Instead of blank text boxes, structured fields capture event title, date, region, campaign name, and target audience. Separate forms exist for different event types—webinars, in-person events—but feed into the same machinery.
  • Labels function as switches. A label like event-setup isn't merely a tag; it's a trigger. Each automation workflow begins with a condition checking for the presence of specific labels.
  • GitHub Actions workflows are the machinery. They activate when labels are applied, extract form fields from the issue body, and execute the work.

The repository provides everything a developer needs—history, visibility, review capability, and a persistent URL for every decision—and the marketing workflow inherited these benefits at no extra cost.

One prerequisite made this possible: the event management platform exposes an API. The CRM doesn't require an API; its official CLI handles all necessary operations, and authentication occurs through the browser without configuring API keys. Whether API or CLI, the requirement remains identical: a scriptable interface. This pattern applies to any repetitive work flowing through tools offering either—event platforms, CRMs, form builders, analytics services.

A developer might object that this reinvents the wheel; marketing automation platforms exist and could handle much of this out of the box. However, the Asia-Pacific region comprises many distinct markets, and workflows shift between sub-regions and customer segments. The same webinar might run in Japanese for Tokyo one month and Korean for Seoul the next, with different segments, different CRM fields, and different lead definitions. Fitting a packaged tool to these variations requires customization budgets, consulting hours, and dependence on someone else's roadmap. Building from existing tools means workflow changes become pull requests: describe the desired change, get reviewed, and merge through the same process developers use for software. This approach proved far more flexible.

Planning an event is a conversation

The pipeline begins before any Issue exists. Opening GitHub Copilot, the author describes the intent: roughly, "I want to run a webinar about AI-assisted development in November."

A file called AGENTS.md at the repository root shapes what happens next. It's the team's runbook in plain Markdown, defining campaign naming conventions, how fiscal quarters map to dates, which time zone applies to each region, and what constitutes a good invitation email. GitHub Copilot reads it, finds a similar past event, proposes a campaign name following the established rules, drafts two invitation email versions, and asks the questions the runbook specifies.

Placing conversation at the pipeline's front was a deliberate design choice solving two problems simultaneously. Full automation sacrifices flexibility; the moment one event needs to differ slightly, a rigid pipeline has nowhere to accommodate it. Conversely, letting humans fill in everything invites mistakes. The conversation sits precisely between these extremes. GitHub Copilot adheres to the template, ensuring the Issue receives correct data in the right format. Because it's a conversation, details can be adjusted for individual events without breaking downstream machinery.

Initially, this conversation occurred in GitHub Copilot CLI within a terminal—acceptable for the author but a barrier for many others. The GitHub Copilot app moved the same conversation to a regular desktop window, lowering the entry barrier from "comfortable with a shell" to "can type."

The division of labor deserves precision because it's the entire point: GitHub Copilot drafts; the human decides. Every campaign name, email subject line, and date receives sign-off before proceeding. At the conversation's end, GitHub Copilot files the GitHub Issue with appropriate labels, and automation takes over.

One label, one event, fully staged

When the event-setup label lands on an issue, a GitHub Actions workflow activates and completes in minutes what previously consumed most of a day:

  • Duplicates a previous event on the event platform to create the new landing page
  • Generates the complete 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 teams responsible for sending emails and tracking regional marketing
  • Adds the event to project boards and populates the fields
  • Posts a summary comment on the Issue so anyone opening it sees everything in one place

Registration screening operates on a schedule rather than a label. Every morning, a cron-triggered workflow retrieves the latest registrants for all open events and shares the cleaned list. For invite-only events, it also screens the waitlist against established criteria—determining whether registrants are developers at enterprise accounts, students, or competitors seeking access to executive briefings—before approving anyone.

The most valued design decision is a single on/off switch called DRY_RUN, stored as a repository variable that every workflow checks before executing. Enabling it causes every workflow to proceed without touching external systems: no landing pages created, no issues filed elsewhere, no lists shared. For a team of marketers automating their own work, rehearsal capability is essential. DRY_RUN serves as the rehearsal switch, enabling experimentation without fear.

After the event, a slash command

Post-event work was previously the worst part: exporting attendees, reformatting columns for CRM upload, matching company names to account records, writing reports. Now it requires two commands.

/lead-upload fetches the attendee list, shapes it into the exact format the marketing operations team needs for CRM upload, files the request Issue, and closes 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 single URL where everything about that event resides.

These are GitHub Copilot agent skills, and here is the crucial point: a skill is a Markdown file. Each one is a SKILL.md—a written procedure in prose telling GitHub Copilot what to do, in what order, and what to watch for. They read like runbooks the author used to keep mentally, because that's exactly what they are.

If you can write a runbook, you can write a skill.

Skills also preserve system flexibility. No two markets in the Asia-Pacific region conduct follow-up identically. Audiences differ, segments differ, local conventions differ, and hard-coded workflows would force every market into one shape. A Markdown procedure is flexible: each market can adapt the runbook to its reality without modifying underlying machinery. This is precisely why post-event steps live in GitHub Copilot skills rather than fixed pipelines.

Skills are treated like code in one respect: new ones arrive by pull request and get reviewed before merging, with a CODEOWNERS file routing reviews to maintainers. Marketing automation with an approval process. The governance came free with the platform.

Built-in guardrails let me experiment

The author automated a workflow touching customer data and API credentials in a repository visible to the entire team while writing minimal code personally. Six months earlier, this combination would have seemed reckless. What changed was recognizing how many guardrails already existed.

Some guardrails were built intentionally: the DRY_RUN switch, a test suite running on every pull request, and code review for every change. These are standard developer practices that protect marketing work as effectively as software.

But the most important guardrails came with the platform:

  • Secret scanning with push protection. The worst-case scenario for someone in this role is accidentally committing an API token. GitHub's push protection blocks the push before the secret reaches the repository, and for GitHub's own tokens, even one that slips through gets revoked automatically.
  • GitHub Copilot's data policies. Registrant lists are business data handled by fixed scripts in fixed ways. But real work is never entirely fixed; sometimes a one-off data cut that no script anticipates is needed. Because GitHub Copilot's business plans don't retain prompts or use them for model training, such analysis can be requested directly instead of following what people across the industry quietly do: pasting business data into whatever consumer chatbot is open in another tab. The same applies to model selection: organization policy determines which models are available, not personal judgment, so even one-off experiments operate within company-decided boundaries. The safe path and the easy path aligned.

Skills enabled one more benefit, almost incidentally: because each procedure is now a named, fixed unit of work, the model can be matched to the job, selecting from the lineup the organization has approved. A fast, inexpensive model handles daily list-cleaning; a stronger one drafts campaign copy.

One honest failure worth noting: the morning screening workflow once failed silently for five days before anyone noticed the lists had gone stale. Unmonitored automation is more of a delayed time bomb. Every scheduled workflow needs a way to alert loudly so failures don't go undetected.

Start with one task

The recommendation, from one recovering manual-worker to another: identify the single most repetitive task in your week. Then verify whether the tools it touches have an API or CLI. Many do, and the discovery may surprise.

Build the smallest viable version: an issue form capturing inputs, a label meaning "go," and an Action executing one work step. Alternatively, write the runbook down as a SKILL.md and let GitHub Copilot execute it. Run it with a dry-run switch until trust builds. Expand from there.

The author didn't write the code. The author wrote down what was already known—how the work gets done—and the platform handled the rest. Whatever your version of the morning registrant list is, it's probably one written-down runbook away from doing itself.

Source: GitHub Blog