Building an Emoji List Generator with GitHub Copilot CLI

TL;DR

• GitHub built a live-coded CLI tool that auto-generates emoji bullets using Copilot SDK
• The project showcases Copilot CLI's plan mode, autopilot, and multi-model workflow in action
• Uses OpenTUI for terminal UI, Copilot SDK for AI, and clipboardy for clipboard access
• If you're learning Copilot CLI capabilities or building terminal tools, this is a practical reference implementation

The Big Picture

Every product launch tweet needs emoji bullets. You know the format: a list of features, each prefixed with a perfectly chosen icon. It looks polished. It's also tedious as hell.

GitHub's developer relations team felt this pain during their weekly Rubber Duck Thursdays stream. So they did what any self-respecting dev team would do: they built a tool to automate it. Live. On stream. Using GitHub Copilot CLI.

The result is a terminal app that takes plain bullet points, runs them through Copilot's SDK, and spits out emoji-prefixed markdown ready for your clipboard. It's a toy project, sure. But it's also a surprisingly good demonstration of how Copilot CLI's newer features—plan mode, autopilot, multi-model support—actually work in practice.

Most Copilot CLI tutorials show you how to generate a single command. This one shows you how to scaffold an entire project, pick the right models for different tasks, and wire up external libraries without leaving your terminal.

How It Works

The build started in Copilot CLI's plan mode. The team fed it a natural language spec: "I want to create an AI-powered markdown emoji list generator..." and let Claude Sonnet 4.6 ask clarifying questions.

Copilot asked about tech stack preferences. A viewer suggested OpenTUI for the terminal interface. Copilot incorporated that, added the GitHub Copilot SDK for AI inference, and suggested clipboardy for clipboard access. The output was a complete plan.md file—not just pseudocode, but a structured implementation roadmap.

Then they switched to autopilot mode with Claude Opus 4.7, which had just dropped. Autopilot took the plan and generated the actual code. A few minutes later, they had a working terminal UI.

The architecture is straightforward. OpenTUI handles the text input interface. When you hit Ctrl+S, the app sends your bullet list to the Copilot SDK with a prompt like "replace these bullets with relevant emoji." The SDK returns the transformed list. Clipboardy copies it. Done.

What's interesting is the multi-model workflow. Plan mode used Sonnet 4.6 for its reasoning and question-asking ability. Implementation used Opus 4.7 for its code generation chops. You're not locked into one model for the entire session—you pick the right tool for each phase.

The team also used the allow-all tools flag, which lets Copilot CLI access any tool or library without explicit permission prompts. This is useful for rapid prototyping but probably not something you'd enable in production environments.

They even wired in the GitHub MCP server, which gives Copilot access to GitHub-specific context like repo structure and issues. For this project, it wasn't strictly necessary, but it shows how you can extend Copilot CLI's context beyond just your local filesystem.

What This Changes For Developers

This project is a proof of concept for a bigger shift: using Copilot CLI not just for one-off commands, but as a project scaffolding tool.

Traditionally, you'd start a new project by googling "how to build a CLI app in Node," skimming a tutorial, copying boilerplate, and manually wiring up dependencies. Here, you describe what you want in plain English, and Copilot generates the structure, picks the libraries, and writes the glue code.

The plan mode → autopilot workflow is the key. Plan mode is for architecture. It asks questions, suggests tradeoffs, and outputs a spec. Autopilot is for execution. It takes the spec and writes code. This separation mirrors how you'd work with a junior dev: first you agree on the approach, then they implement it.

The multi-model support matters more than it sounds. Sonnet is better at reasoning and planning. Opus is better at code generation. Being able to switch between them mid-session means you're not compromising on either phase.

For terminal tool builders specifically, this stack is worth noting. OpenTUI is a newer library that simplifies terminal UI without the complexity of something like Ink. The Copilot SDK gives you AI inference without managing API keys or rate limits. Clipboardy is a cross-platform clipboard library that just works. Together, they're a solid foundation for any CLI tool that needs AI smarts.

Try It Yourself

The emoji list generator is open source. Clone it, run npm install, and you've got a working example of Copilot SDK integration.

If you want to build something similar from scratch, start with Copilot CLI's plan mode. The command is gh copilot plan. Describe your project in natural language. Let it ask questions. Review the generated plan before moving to autopilot.

For autopilot, use gh copilot autopilot with the --model flag to specify which model you want. If you're generating code, Opus 4.7 is the current best option. If you're debugging or refactoring, Sonnet might be better.

The Copilot CLI docs cover setup and basic usage. The Copilot SDK docs explain how to integrate AI inference into your own projects.

The Bottom Line

Use this if you're learning Copilot CLI's advanced features and want a concrete example beyond "generate a git command." The project is small enough to understand in one sitting but touches plan mode, autopilot, multi-model workflows, and SDK integration.

Skip it if you're looking for production-ready code. This is a demo. The error handling is minimal. The prompt engineering is basic. The UI is functional but not polished.

The real value here isn't the emoji generator itself—it's seeing how Copilot CLI handles end-to-end project creation. If you've been using Copilot CLI only for command suggestions, this shows you what else it can do. The gap between "suggest a command" and "scaffold a project" is bigger than it looks, and GitHub is clearly trying to close it.

Source: GitHub Blog