GitHub details an issue-driven workflow for marketing events

In a GitHub Blog post published September 11, 2026, Tomoko Tanaka describes using Copilot, Issues and Actions to automate event operations for GitHub’s marketing work in Japan and Korea. The central idea is to make an issue both the event’s coordination record and the structured input to operational workflows. Read Tanaka’s account.

From conversation to repeatable jobs

In Tanaka’s setup, Copilot reads an AGENTS.md repository runbook containing campaign-naming rules, regional time zones and invitation conventions. It proposes campaign names, drafts invitation emails and asks questions specified by the runbook.

Issue forms capture fields such as event title, date, region and target audience. Labels such as event-setup trigger Actions workflows, which parse those fields from the issue body. Tanaka describes setup automation that generates channel-specific tracking links, produces an invitation document, opens request issues and updates project boards. A separate scheduled workflow fetches and cleans registration lists each morning. Planning and workflow details.

Post-event work uses custom Copilot agent skills expressed as Markdown procedures. Tanaka’s /lead-upload skill prepares attendee data for the marketing operations team and files a CRM-upload request. Her /event-report skill posts attendance metrics and survey results to the event issue. The distinction matters: the described lead-upload step prepares data and requests downstream work rather than promising direct CRM ingestion. Follow-up procedures.

Review and rehearsal still need monitoring

Tanaka reports a test suite that runs on every pull request, code review for every change and a shared DRY_RUN repository variable. She says every workflow checks that variable and, when it is enabled, rehearses without changing external systems. New skills also arrive through pull requests, with CODEOWNERS routing review to a maintainer.

Those controls did not eliminate operational failures. Tanaka says the morning screening workflow once failed silently for five days before anyone noticed that its lists were stale. Her recommendation is to give scheduled workflows a way to raise an alert when something goes wrong. Guardrails and the reported failure.

For adopters, review, rehearsal, retry safety and monitoring should be separate checks. Test whether rerunning a job duplicates requests, verify that every external-write path honors the dry-run setting, and make stale scheduled output visible to an owner.

A workflow pattern to adapt

The account describes Tanaka’s implementation using existing tools. She reports connecting to an event platform through its API and using her CRM’s official CLI. Scriptable access is therefore a prerequisite to check before reproducing this approach. Integration requirements.

The useful architectural distinction is between flexible planning and repeatable execution: a conversational runbook accommodates event-specific choices, while structured issue fields give automated jobs explicit inputs. Start with one bounded task, then add downstream steps alongside retry checks and failure alerts.