Learn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry.
Learn how to build with generative AI.
Change how you work with GitHub Copilot.
Everything developers need to know about LLMs.
Machine learning tips, tricks, and best practices.
Explore the capabilities and benefits of AI code generation and how it can improve your developer experience.
Resources for developers to grow in their skills and careers.
Insights and best practices for building apps.
Tips & tricks to grow as a professional developer.
Improve how you use GitHub at work.
Learn how to move into your first professional role.
Stay current on what’s new (or new again).
Learn how to start building, shipping, and maintaining software with GitHub.
Get an inside look at how we’re building the home for all developers.
Discover how we deliver a performant and highly available experience across the GitHub platform.
Explore best practices for building software at scale with a majority remote team.
Get a glimpse at the technology underlying the world’s leading AI-powered developer platform.
Learn how we build security into everything we do across the developer lifecycle.
Find out what goes into making GitHub the home for all developers.
Our engineering and security teams do some incredible work. Let’s take a look at how we use GitHub to be more productive, build collaboratively, and shift security left.
Explore how to write, build, and deploy enterprise software at scale.
Automating your way to faster and more secure ships.
Guides on continuous integration and delivery.
Tips, tools, and tricks to improve developer collaboration.
DevOps resources for enterprise engineering teams.
How to integrate security into the SDLC.
Learn why Gartner positioned GitHub as a Leader for the second year in a row.
Keep up with what’s new and notable from inside GitHub.
An inside look at news and product updates from GitHub.
The latest on GitHub’s platform, products, and tools.
Insights into the state of open source on GitHub.
The latest policy and regulatory changes in software.
Data-driven insights around the developer ecosystem.
Older news and updates from GitHub.
Learn how to use retrieval-augmented generation (RAG) to capture more insights.
Spotlighting open source maintainers.
How open source is driving positive change.
Explore open source games on GitHub.
Organizations worldwide are incorporating open source methodologies into the way they build and ship their own software.
Stay up to date on everything security.
Demystifying supply chain security.
Updates from the GitHub Security Lab.
Helpful tips on securing web applications.
Learn about core challenges in DevSecOps, and how you can start addressing them with AI and automation.
If you can write down how you do your work, you can automate it. Here’s what I did to support GitHub’s APAC marketing team.
I run marketing for GitHub in Japan and Korea, and events are the heartbeat of it: a recurring webinar series for enterprise developers, community meetups in Tokyo, invite-only executive sessions in Seoul. What does a developer in this market actually need right now? Which topics are worth an hour of their time, and who should be in the room? I’d happily spend all day on those questions.
What follows the decisions is another matter. Once an event is greenlit, a fixed sequence begins:
While none of these tasks are hard on their own, they’re an opportunity to paste the wrong link, skip a day, or misspell a campaign name that 15 downstream reports depend on.
Here’s the thing: I used to be an engineer. My first career was keeping databases alive on Linux servers for enterprise customers. While my coding may be rusty, I can still see a pipeline begging to be automated. This is where I put GitHub Copilot：https://github.com/features/copilot to use and where you could too in your own work.
So I didn’t write the code. I wrote down my runbooks, handed them to GitHub Copilot, and grew the automation in conversation. Today, an event I used to assemble by hand over a couple of days sets itself up from a single GitHub Issue, screens its own registrants every morning, and cleans up after itself when it’s over.
This post walks through how that works, and why I think anyone whose job involves repetitive work across tools that offer any scriptable way in (an API, or even just a CLI) can do the same.
I can’t claim the foundational idea as my own. Marketing teams at GitHub already had a habit of opening one GitHub Issue per project. This becomes the place where the plan, the discussion, and the status live together. The issue was already our unit of work. What I did was make the issue do the work.
Three GitHub primitives carry the whole system:
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, and it has nothing to do with events specifically: our event management platform exposes an API . Our CRM doesn’t even need one; its official CLI covers everything we do, and 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, an analytics service, the pattern in this post applies to you.
A developer reading this may already be composing the obvious objection: isn’t this reinventing the wheel? 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, and 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.
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’s 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, and then, 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 itself a design decision, and 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’s 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：https://github.com/features/copilot/cli, in a terminal. That was fine for me, but “open a terminal” is a barrier for many people I’d love to bring into this workflow. With the GitHub Copilot app：https://github.com/features/ai/github-app, the same conversation now happens in a regular desktop window. The barrier to entry dropped from “comfortable with a shell” to “can type.”
Scan to open this article