copilot-cli

A guide to slash commands in the GitHub Copilot app (opens in new tab)

Slash commands in the GitHub Copilot app provide quick, context-aware shortcuts for planning work, challenging decisions, automating implementation, and reviewing ideas. Unlike CLI commands, which manage terminal-oriented concerns such as directories and working paths, app commands focus on multi-session workflows and agent behavior. The post presents slash commands as a way to work faster while staying focused in the Copilot app. ## What Slash Commands Are - Type `/` in the chat composer to open an autocomplete menu of commands available in the current context. - The app manages project context visually, so commands such as `/add-dir` and `/cwd`—common in the CLI—are unnecessary. - Some commands, including `/clear` and `/model`, work in both the CLI and the app. - App-specific commands emphasize session navigation, project management, and controlling Copilot’s working mode. ## Planning Work with `/plan` `/plan` helps users think through a task before implementation and switches the session into Plan mode. - Break down new features by identifying files, components, dependencies, and implementation steps. - Prepare large refactors with an incremental migration strategy and risk assessment. - Investigate bugs by exploring possible causes and creating a diagnostic and repair plan. - Example: `/plan I need to add two-factor authentication to our application. Help me break down the work involved, identify what files need to change, and outline an implementation approach.` ## Challenging Ideas with `/spar` `/spar` acts as a critical reviewer, questioning assumptions and highlighting risks, tradeoffs, and edge cases. - Pressure-test architecture decisions such as using Redis for caching. - Compare alternatives like REST versus GraphQL or synchronous versus asynchronous processing. - Review database and infrastructure migration plans for rollout risks. - Evaluate proposed performance optimizations for hidden costs or unintended effects. ## Implementing with `/autopilot` `/autopilot` turns a high-level goal into an implementation workflow and switches the session into Autopilot mode. - Ask Copilot to implement features, update files, and modify tests. - Use it for multi-step maintenance work, including dependency upgrades, refactoring, and documentation updates. - Example tasks include adding CSV report exports or upgrading a React project while addressing breaking changes and running the test suite. ## Reviewing Ideas with `/rubber-duck` `/rubber-duck` provides an independent perspective for thinking through problems and debugging. The article introduces it as a more useful alternative to explaining an issue to a pet, but the supplied text ends before describing its full capabilities or examples. Use `/plan` to clarify the work, `/spar` to test the approach, and `/autopilot` to carry out the implementation. These commands complement the app’s visual workflow by making common Copilot interactions immediately accessible from the chat composer.

Better tools made Copilot code review worse. Here’s how we actually improved it. (opens in new tab)

Copilot code review became more expensive and less effective after GitHub replaced its specialized exploration tools with shared `grep`, `glob`, and `view` tools. The tools themselves worked correctly, but their general-purpose instructions encouraged broad repository browsing rather than focused pull request investigation. After rewriting the instructions around diff-first review workflows, GitHub achieved roughly 20% lower average review cost without reducing review quality. ## Why the Tool Migration Regressed - Copilot code review previously used specialized tools for: - Listing directories - Searching files and directories - Reading code - These tools often returned matching lines along with surrounding context, which suited earlier models that made fewer tool calls and needed more context per request. - GitHub migrated to the shared Unix-inspired tools used by Copilot CLI and other products: - `glob` replaced `list_dir` - `grep` replaced `search_file` and `search_dir` - `view` replaced `read_code` - The migration aimed to reduce duplicated implementations and let improvements benefit multiple Copilot products. - Offline benchmarks showed higher review costs and fewer useful comments after the migration. ## Repository Browsing Instead of Pull Request Review - Execution traces showed the agent: - Searching broadly - Guessing file paths - Reading large sections of code - Finding more things to search - Carrying unnecessary context into later reasoning - This workflow is reasonable for a coding assistant asked to understand an unfamiliar repository. - It is inefficient for code review, where the agent should begin with the pull request diff and investigate a specific potential problem. - Excessive tool output increases token usage because returned file contents remain in the agent’s context window. - Broad exploration can also make the review less focused by mixing relevant evidence with unrelated code. ## The Difference Between Coding and Reviewing - A coding assistant may need to map a large area of a repository before editing code safely. - A reviewer typically asks targeted questions based on the diff, such as: - Where is the changed function called? - Is a modified configuration key used elsewhere? - Does a similar test or helper already exist? - What is the smallest code range needed to understand the behavior? - Copilot code review has a narrower objective: - Start from the pull request diff - Determine whether the change introduced a real issue - Gather only the evidence needed to confirm or dismiss that issue - The shared tools were designed for broader interactive workflows, so their instructions unintentionally encouraged the wrong behavior in the review agent. ## Instructions Were the Real Fix - GitHub concluded that changing tools was not enough; the agent’s workflow instructions also had to change. - The revised instructions emphasized: - Diff-first investigation - Targeted searches - Minimal surrounding context - Narrow evidence gathering - Avoiding unnecessary repository-wide exploration - With these workflow changes, the shared tools became more effective for review rather than merely reproducing their coding-assistant behavior. - The result was approximately 20% lower average review cost while preserving review quality. The practical lesson is that tool quality cannot be evaluated separately from the instructions and workflow guiding an agent. Shared tools can work well across products, but each use case needs instructions that match its task—in this case, focused, evidence-driven pull request review rather than broad repository exploration.

Agent-driven development in Copilot Applied Science (opens in new tab)

The post describes how Tyler McGoffin used GitHub Copilot to automate the intellectual work of analyzing coding-agent evaluation trajectories. This led to `eval-agents`, a tool designed to let researchers create, share, and run specialized agents. By making coding agents the primary contributors, the team rapidly added 11 agents, four skills, and workflow support while learning new approaches to prompting, architecture, and collaboration. ## The Motivation: Automating Evaluation Analysis - McGoffin analyzes coding-agent performance using benchmarks such as TerminalBench2 and SWEBench-Pro. - Each benchmark task produces a trajectory: a large JSON record of the agent’s thoughts and actions. - Reviewing hundreds or thousands of trajectories can involve hundreds of thousands of lines of data. - Copilot initially helped identify patterns, reducing the amount of material requiring manual inspection from hundreds of thousands of lines to a few hundred. - The repetitive nature of this process inspired `eval-agents`, which automates parts of the analysis itself. ## Project Goals The project was designed around three objectives: - Make agents easy for others to share and use. - Make authoring new agents straightforward. - Make coding agents the primary mechanism for contributing to the project. The third goal had the greatest architectural impact. Using Copilot to build the tool also made the repository easier for teammates to understand, extend, and collaborate on. ## An Agent-First Development Setup McGoffin’s development environment consisted of: - Copilot CLI as the coding agent. - Claude Opus 4.6 as the model. - VS Code as the IDE. - The Copilot SDK for creating agents, registering tools and skills, and accessing existing MCP servers. This setup allowed the project to reuse Copilot’s existing agent infrastructure instead of implementing those capabilities from scratch. ## Prompting Strategies - Agents perform best when treated like capable engineers rather than simple code generators. - Effective prompts are conversational, detailed, and explicit about assumptions. - Planning mode should be used before implementation mode, especially for complex tasks. - McGoffin used stream-of-consciousness descriptions to explain problems and collaborate with Copilot on possible solutions. - For example, a discussion about preventing agents from weakening regression tests led to protected test areas and human-controlled contract-test-like guardrails. - The broader lesson is that agents benefit from many of the same practices as human engineers: context, dialogue, planning, and clear constraints. ## Architectural Strategies An agent-first codebase makes maintainability work especially valuable: - Refactoring names and file structures improves the repository’s understandability. - Documentation gives agents the context needed to implement features consistently. - Additional tests expose and prevent recurring mistakes. - Removing dead code helps keep agents from copying outdated or irrelevant patterns. - Work that was traditionally postponed—cleanup, documentation, and test improvements—becomes foundational when agents are responsible for much of the implementation. ## Rapid Team Collaboration Applying these principles enabled substantial development in a short period: - Five people contributed to the project for the first time. - The team created 11 agents and four skills. - They introduced eval-agent workflows for structured streams of scientific reasoning. - In under three days, the changes amounted to approximately 28,858 added and 2,884 removed lines across 345 files. ## Practical Recommendation Teams adopting agent-driven development should invest first in clear architecture, documentation, tests, and conversational planning practices. Agents become substantially more effective when the repository provides strong context and guardrails, allowing developers to focus less on repetitive implementation and more on directing, reviewing, and improving the overall system.

What’s new with GitHub Copilot coding agent (opens in new tab)

GitHub Copilot coding agent is becoming more capable at handling delegated development work from issue to pull request. Recent updates let users choose models, receive self-reviewed and security-checked changes, apply team-specific workflows through custom agents, and move tasks between the cloud and local CLI without losing context. Together, these features aim to reduce cleanup and make background coding tasks more reliable. ## Model selection for different tasks - The Agents panel now includes a model picker. - Users can choose faster models for routine work, stronger models for complex refactoring or integration tests, or let GitHub select automatically. - Model selection is currently available to Copilot Pro and Pro+ users; Business and Enterprise support is planned. ## Self-review before pull requests - Copilot coding agent now runs Copilot code review on its own changes before opening a pull request. - It incorporates feedback and improves the patch, such as simplifying overly complex code. - Users can inspect the review and iteration steps in the task logs before reviewing the resulting pull request. ## Integrated security checks - The agent performs code scanning, secret scanning, and dependency vulnerability checks during its workflow. - Vulnerable dependencies, exposed API keys, and other risky patterns can be identified before a pull request is created. - These code-scanning capabilities are provided without requiring a separate GitHub Advanced Security subscription for this workflow. ## Custom agents for team processes - Teams can define specialized agents in `.github/agents/`. - Custom agents can enforce repeatable procedures, such as benchmarking code before and after a performance change. - Agents can be shared across an organization or enterprise to standardize development practices. - The article describes a custom performance agent that achieved a 99% improvement on a targeted lookup function. ## Cloud and local CLI handoff - Cloud coding-agent sessions can be continued locally with their branch, logs, and context intact. - Users can select “Continue in Copilot CLI” and run the provided command in a terminal. - Pressing `&` in the CLI delegates work back to the cloud without restarting the task. GitHub recommends using these features to match models and workflows to each task, while reviewing the agent’s logs and pull requests. Planned capabilities include private mode, planning before coding, and tasks that produce summaries or reports instead of pull requests.