単発プロンプトからワークフローへ：GitHub Copilot CLIでカスタムエージェントを活用する方法From one-off prompts to workflows: How to use custom agents in GitHub Copilot CLI

Developers increasingly run AI assistants directly inside the terminal, and GitHub Copilot CLI is positioning custom agents as a way to make that workflow more consistent. The core idea is straightforward but consequential: instead of typing a fresh, ad-hoc prompt every time you want help, you can define agents that already understand your project's stack, conventions, and recurring tasks. That shift, from improvised single requests to codified processes, is what makes the feature worth attention for teams that rely on the command line.

A one-off prompt is convenient but fragile. It captures intent in the moment, yet it disappears once the session ends, and the next engineer who needs the same outcome has to reconstruct the instruction from memory. Results vary depending on phrasing, context, and who is asking. Custom agents address this by letting you persist that context. You describe what an agent should know and how it should behave, and Copilot CLI applies those instructions whenever the agent is invoked. The practical payoff is repeatability: the same task produces comparable output across runs and across team members.

According to the post, custom agents let Copilot CLI understand your stack and team workflows, turning one-off terminal prompts into repeatable, reviewable processes. The emphasis on "reviewable" is notable. When an agent's behavior is defined in configuration rather than improvised, that definition can be committed to a repository, inspected in a pull request, and refined over time like any other piece of code. This brings AI-assisted terminal work closer to the norms that already govern infrastructure-as-code and scripted automation, where changes are visible and auditable rather than hidden in individual habits.

In practice, configuring an agent typically involves describing its purpose, the tools or commands it is allowed to use, and the guidelines it should follow. An agent might be scoped to a narrow job, such as running a project's test suite and summarizing failures, scaffolding a new module that matches existing patterns, or walking through a deployment checklist. By encoding knowledge about the team's preferred frameworks, directory structure, and naming conventions, the agent can produce suggestions that fit the codebase rather than generic boilerplate. This appears to be the main value proposition: reducing the gap between a model's general knowledge and a specific project's reality.

It helps to place this in the wider context of agentic developer tooling, which has expanded quickly. GitHub Copilot began as inline code completion in the editor, then grew to include chat, and more recently a coding agent capable of taking on issues and opening pull requests. Bringing comparable capabilities to the CLI matters because much of a developer's work, including builds, tests, version control, and environment management, happens in the shell. Competing and complementary tools have moved in the same direction, with Anthropic's Claude Code, OpenAI's Codex CLI, and open-source projects such as Aider all offering terminal-centric AI assistance. The notion of reusable, configurable agents is becoming a shared pattern across these products rather than a single vendor's idea.

For readers new to the space, a few prerequisite concepts make the feature easier to evaluate. An agent in this sense is a model paired with instructions and, often, permission to call tools or execute commands on your behalf. Because agents can run real commands, scoping and review become safety features, not just conveniences. Defining what an agent may and may not do limits the blast radius of a mistaken or unexpected action. Teams adopting these workflows are likely to treat agent definitions much as they treat continuous integration scripts, keeping them under version control and reviewing changes before they take effect.

The broader significance is about moving institutional knowledge out of individual heads and into shared, inspectable artifacts. A well-described agent functions as living documentation of how a team prefers to build, test, and ship. That said, custom agents are not a replacement for human judgment, and outputs still warrant verification, particularly for commands that modify systems or data. The tutorial framing of the post suggests it is aimed at practitioners ready to experiment rather than at decision-makers seeking a high-level overview. For developers already comfortable in the terminal, the appeal is concrete: less repeated prompting, more consistent results, and a path toward automation that the rest of the team can read, question, and improve.