github-copilot-cli

How the GitHub legal team used Copilot CLI to streamline their workflows (opens in new tab)

GitHub’s legal team used Copilot CLI to turn repetitive legal work into customizable internal tools without relying on traditional software engineering. By expressing workflows, standards, and policies in plain language and Markdown, lawyers built systems that improved consistency, reduced drafting time, and preserved human oversight. The post argues that domain expertise can be operationalized into useful AI tools by anyone who can clearly define a process. ## Building a Contract Drafting Style Guide - Principal Product Counsel Ngandu Kasuku created **terms-ai** to manage varied commercial agreements involving data, infrastructure, and product integrations. - The tool stores instructions, drafting resources, workflows, and reference documents in a version-controlled repository. - An internal style guide enforces plain-language drafting and replaces repetitive prompt copying with consistent guidance. - A library of approved agreements lets the tool draw on prior work for addenda and new contracts. - Sensitive agreements remain in a controlled internal environment rather than the open-source repository. - Kasuku reports cutting drafting and review time roughly in half while producing more consistent provisions. - The main insight was that AI could support a lawyer’s own judgment and working style, not merely perform isolated tasks. ## Turning Legal Workflows into Plain-Language Instructions - Online Safety Counsel Jesse Geraci began with a workflow for analyzing source code in **DMCA** notices. - Copilot instructions covered triage, code comparison, license checks, circumvention review, policy references, and report templates. - Instead of traditional programming, the workflow encoded legal reasoning through structured instruction files. - Different modes were created for clients and lawyers, including faster client analysis, escalation recommendations, deeper legal review, and arguments for both sides. - The system later grew into a desktop application supporting contract review, NDA triage, risk assessment, compliance checks, and response drafting. - Reusable skills and agents handle tasks such as intake, playbook alignment, risk scoring, evidence verification, escalation, and report assembly. - Legal teams can still customize the system through readable Markdown, while human review remains essential. ## Broader Lessons for Nontechnical Teams - Repetitive work in almost any profession can be a starting point for automation. - Clear definitions of methodology, standards, and desired outputs can substitute for extensive programming knowledge. - Teams should begin with one bottleneck, use Copilot CLI to prototype a solution, and expand based on real usage. - These tools are decision-support systems—not replacements for professional judgment. Teams can use Copilot CLI to turn their existing expertise into repeatable, transparent workflows while retaining control over sensitive data and final decisions.

GitHub Copilot CLI for Beginners: Overview of common slash commands (opens in new tab)

GitHub Copilot CLI’s slash commands provide a central way to control sessions directly from the terminal. They help users select models, manage context, inspect changes, switch projects, resume work, and control permissions. The article recommends typing `/` to explore the available commands and build a more deliberate CLI workflow. ## Slash Commands as Copilot CLI Controls - Slash commands are built-in terminal controls for: - Guiding Copilot’s behavior - Inspecting project changes - Managing conversation context - Moving between sessions and repositories - Resetting tool permissions - Typing `/` displays a scrollable list of supported commands. ## Selecting a Model - `/model` opens the list of available models. - Model information includes: - Capabilities for lightweight tasks or deeper reasoning - Availability based on the user’s plan or organization - Cost multipliers indicating relative usage cost - Choosing an appropriate model can balance speed, quality, and cost. ## Managing Context and Tokens - `/context` shows remaining tokens, system usage, and available buffer. - `/compact` summarizes the current conversation to free context space without starting over. - Copilot may compact automatically near the context limit, but users can trigger it manually when changing tasks. - `/clear` completely resets the current session. ## Resuming Previous Sessions - `/resume` lists earlier local and remote sessions. - Users can select a session to review its history and continue where they left off. ## Reviewing Changes - `/diff` displays recent modifications made during the session. - This helps users inspect and validate Copilot’s changes before proceeding. ## Switching Projects - `/cwd` changes Copilot’s current working directory. - It allows users to move between repositories or project directories without exiting the CLI. ## Resetting Permissions - `/reset-allowed-tools` removes previously granted permissions for actions such as editing files. - This is useful when switching to a repository that requires more cautious access controls. Users should start by typing `/` in Copilot CLI to discover available commands, then use commands such as `/model`, `/context`, `/compact`, `/diff`, and `/cwd` to maintain control over their coding sessions.

How we made GitHub Copilot CLI more selective about delegation (opens in new tab)

GitHub improved Copilot CLI by making subagent delegation more selective rather than treating delegation as inherently beneficial. The new orchestration policy keeps narrow tasks with the main agent, delegates broad or independent work, and encourages parallel execution instead of waiting. After full production rollout, it reduced tool failures by 23% and improved high-percentile wait times without reducing quality. ## The Cost of Unnecessary Delegation - Subagents help with complex investigations, large repositories, and parallel work, but every handoff adds tool calls, coordination, and latency. - Copilot sometimes delegated simple, well-scoped tasks that the main agent could complete directly. - Common problems included: - Repeated or overlapping repository searches. - Subagents re-discovering context already available to the main agent. - Sequential delegation that left the main agent idle. - Stale paths, incorrect relative paths, and workspace mismatches. - The result was slower execution and more tool failures for tasks that should have required only a few steps. ## How the Problem Was Identified - GitHub used LLMs to analyze complete agent trajectories rather than manually reviewing sessions. - The analysis found that delegation was frequently used for narrow, obvious, or fully described tasks. - This led to a clear target: - Keep focused discovery-and-edit work with the main agent. - Reserve subagents for broad exploration, cross-cutting tasks, or genuinely independent work. ## A More Selective Orchestration Policy - Copilot now starts with the narrowest effective workflow: - Find and read the relevant file. - Make the targeted change. - Verify the result. - Delegation becomes appropriate when additional context, uncertainty, or parallel execution creates real value. - Subagents are treated as a parallelism mechanism, not a reason for the main agent to pause. - Handoffs should clearly specify: - The user’s request. - What the main agent already knows. - Which work the subagent owns. - What result the subagent should return. ## Evaluation and Production Results - GitHub tested the change with generated regression cases and existing benchmarks before rollout. - Staff and public A/B tests measured reliability, responsiveness, subagent workload, and quality. - Production results showed: - 23% fewer tool failures per session. - 27% fewer search-tool failures. - 18% fewer edit-tool failures. - 5% lower P95 wait time. - 3% lower P75 wait time. - No quality regression. - The improvements came mainly from avoiding unnecessary subagent paths and reducing orchestration overhead, not from making individual model calls faster. Copilot CLI users can access the improvement by running `/update` and upgrading to version 1.0.42 or later. The broader recommendation is to delegate selectively: use the main agent for focused tasks and subagents only when independent context or parallel work provides meaningful leverage.

Give GitHub Copilot CLI real code intelligence with language servers (opens in new tab)

GitHub Copilot CLI can understand code far more accurately when connected to a Language Server Protocol (LSP) server. Without LSP, it relies on grep, package-directory browsing, and bytecode extraction, which can miss types, overloads, and dependencies. The LSP Setup skill automates server installation and configuration for 14 languages, giving the CLI capabilities such as type resolution, go-to-definition, and reference search. ## The Problem with Heuristic Code Understanding - Without an LSP server, Copilot CLI may: - Extract Java JAR files and grep through `.class` files. - Read installed Python packages directly. - Search through TypeScript’s `node_modules`. - These approaches use text and pattern matching rather than semantic analysis. - They often fail to correctly understand: - Generics and overloads. - Transitive types. - Compiled dependencies. - Exact method signatures and symbol relationships. - LSP requests such as `textDocument/definition` return precise source locations, resolved types, and signatures. ## How the LSP Setup Skill Works The skill automates a seven-step process: - **Language selection:** Uses `ask_user` to determine the required language. - **Operating system detection:** Identifies macOS, Linux, or Windows so it can choose the correct installation commands. - **Server lookup:** Reads curated data for 14 languages from `references/lsp-servers.md`. - **Configuration scope:** Supports: - User-wide configuration at `~/.copilot/lsp-config.json`. - Repository-specific configuration at `lsp.json` or `.github/lsp.json`. - Repository configuration takes precedence. - **Installation:** Runs the appropriate package-manager or platform-specific command, such as: - `npm install -g typescript typescript-language-server` - `brew install jdtls` - `rustup component add rust-analyzer` - **Configuration:** Adds a server under the `lspServers` object, mapping commands and file extensions to language identifiers. - **Verification:** Confirms the executable is on `PATH` and checks that the configuration is valid JSON. The skill merges new settings with existing configuration instead of overwriting other servers. It also accounts for transport differences, such as servers requiring `--stdio`. ## Supported Languages and Custom Setup - The skill provides predefined installation and configuration details for 14 languages. - If a language is not included, Copilot CLI can search for a suitable server and guide the user through manual configuration. - Each server configuration specifies: - The executable command. - Optional arguments. - File-extension mappings such as `.java` to `java`. ## Benefits After Configuration With LSP enabled, Copilot CLI can: - Resolve types across external dependencies. - Jump to definitions in third-party libraries. - Find every reference to a symbol. - Display hover documentation for functions, classes, and types. - Reduce unnecessary tool calls and avoid incorrect assumptions about APIs. - Handle larger and more complex coding tasks with IDE-like semantic understanding. ## Getting Started - Download the LSP Setup skill from the Awesome Copilot project. - Extract it into `~/.copilot/skills/`. - Restart Copilot CLI. - Ask the agent to set up LSP for a language, such as Java or Python. - Restart the CLI again, run `/lsp`, and test navigation on a dependency symbol. The practical recommendation is to configure an LSP server for each language used in a project. The setup gives Copilot CLI structured code intelligence instead of forcing it to reconstruct APIs through text searches and binary inspection.

From one-off prompts to workflows: How to use custom agents in GitHub Copilot CLI (opens in new tab)

Custom agents in GitHub Copilot CLI turn repeated terminal tasks into reusable, consistent workflows. Defined as Markdown profiles in a repository, they encode team-specific expertise, tools, standards, and safety rules instead of relying on one-off prompts. This makes workflows easier to review, version, share, and reuse across the CLI, IDE, and GitHub. ## What Custom Agents Are - A custom agent is a specialized Copilot agent configured through a Markdown file. - Its profile specifies: - Role and area of expertise - Available tools - Required standards and procedures - Guardrails and expected output formats - Teams can tailor agents to requirements such as: - WCAG accessibility standards - Formatting and testing conventions - Security and privacy policies - Review and ownership requirements - Because profiles live in the repository, they can be versioned, reviewed, and shared like code. ## Creating and Using Agents in Copilot CLI - Invoke Copilot CLI from the terminal and use the `/agent` command to select an agent. - Store the profile in the repository’s `.github/agents` directory. - Agent files use YAML frontmatter and typically end in `.agent.md`, such as `accessibility.agent.md`. - The profile defines the agent’s name, description, model, tools, instructions, scope, and guardrails. - Copilot CLI is especially suitable for these agents because it can execute scripts, call APIs, inspect repositories, and work directly with command-line tooling. ## Automating Repeated Workflows Custom agents are most useful for recurring tasks that span the terminal, IDE, and pull requests. - A security audit agent can: - Run standard checks across repositories - Group findings by Critical, High, Medium, and Low severity - Produce a pull-request-ready checklist with owners and next steps - It can use tools such as `gitleaks`, `trivy`, `semgrep`, `gh`, `git`, and `jq`. - Agents should prefer existing repository configuration files, including `.semgrep.yml`, `.trivyignore`, and `.gitleaks.toml`. - Missing security tools should be reported as coverage gaps rather than replaced with invented results. - Instructions can require secrets to be redacted, inclusive terminology, and consistent date formats. - Ownership mappings can assign findings to teams based on affected paths, using `CODEOWNERS` when available or defined defaults otherwise. Custom agents provide a practical way to capture team expertise once and apply it consistently. Start by converting a repetitive, execution-heavy task into a narrowly scoped `.github/agents` profile with explicit tools, outputs, and safety rules.

GitHub recognized as a Leader in the Gartner® Magic Quadrant™ for Enterprise AI Coding Agents for the third year in a row (opens in new tab)

GitHub argues that AI coding has made code generation easier, shifting the main bottleneck to reviewing, securing, governing, and deploying software. It presents GitHub Copilot as an agentic platform spanning the full software development lifecycle, enabling developers to assign issues to agents and focus on reviewing and approving results. Gartner named GitHub a Leader in the 2026 Magic Quadrant for Enterprise AI Coding Agents, placing it highest for ability to execute for the third consecutive year. ## The Shift from Code Generation to Software Delivery - AI coding agents are increasingly expected to handle more than writing functions. - The harder problems now involve: - Code review - Security - Governance - Testing - Deployment - GitHub describes the new workflow as “orchestrating outcomes”: developers assign work to agents, then return to steer, review, and approve it. - Gartner projects that asynchronous AI coding-agent workflows could improve engineering productivity by 30%–50% by 2028, compared with 0%–20% gains from code assistants in 2025. ## Enterprise Adoption of GitHub Copilot - Copilot is used by 140,000 organizations, nearly three times the number reported a year earlier. - Overall growth exceeded 100% year over year. - Most users work with multiple AI models. - GitHub Copilot CLI usage nearly doubled month over month. - GitHub says these figures indicate that enterprises are adopting increasingly sophisticated, agent-driven workflows. ## Gartner’s 2026 Evaluation - Gartner evaluated 12 enterprise AI coding-agent vendors according to: - Ability to execute - Completeness of vision - GitHub was positioned as a Leader and ranked highest in ability to execute. - Gartner describes Leaders as vendors combining strong execution, market-shaping vision, rapid innovation, broad software-engineering relevance, and enterprise-grade security and governance. - The report’s Leader quadrant also includes Anthropic, Cursor, and OpenAI. ## GitHub’s Claimed Differentiators - **Developer choice:** Copilot supports multiple models and providers. - **Broad availability:** It works across editors, IDEs, CLIs, and GitHub’s web, desktop, and mobile applications. - **Full-lifecycle integration:** Copilot operates across issues, pull requests, code reviews, and GitHub Actions—not only inside the editor. - **Enterprise governance:** Teams can observe, audit, and secure how AI is used in engineering workflows. ## What GitHub Plans to Build Next - GitHub says it will expand agentic workflows across more developer-facing surfaces. - Planned investments include: - Greater model choice and intelligent model routing - Deeper integrations throughout the software lifecycle - Performance improvements based on how software is actually built and maintained on GitHub GitHub’s central recommendation is to treat AI coding agents as part of an end-to-end engineering platform rather than isolated code-generation tools. The post also notes that Gartner’s recognition is not an endorsement and that its findings should be considered alongside the full research report.

Dungeons & Desktops: Building a procedurally generated roguelike with GitHub Copilot CLI (opens in new tab)

GitHub Dungeons is a terminal-based roguelike that transforms a repository into a procedurally generated dungeon. Built in Go with GitHub Copilot CLI, it uses the latest commit SHA as a seed, making each commit produce a distinct but reproducible map. The project demonstrates how AI-assisted development can let developers focus more on game design and iteration than on implementation details. ## Repository-Driven Procedural Generation - The game generates rooms, corridors, and enemies from the current codebase. - Each repository produces a structurally different dungeon. - The latest commit determines the random seed: - The same commit always creates the same map. - Code changes reshape the dungeon. - Procedural generation creates replayability by producing many layouts from a single set of rules. ## Roguelike Design - GitHub Dungeons draws on classic games such as *Rogue*. - It combines: - Procedurally generated levels - Permadeath - A text-based terminal interface - Players navigate with arrow keys, fight bugs, collect items, and search for the exit. - When the player’s HP reaches zero, the run ends and they must start over. - The Copilot CLI `/yolo` command, an alias for `/allow-all`, reinforces the game’s one-life theme. ## Building with GitHub Copilot CLI - The author began with a high-level prompt asking Copilot to build a Go-based GitHub CLI extension using BSP-generated dungeons. - The `/delegate` command sent feature requests to Copilot’s cloud-based coding agent. - Copilot worked asynchronously and returned changes through pull requests. - Example delegated work included progressively harder levels with: - More enemies - Additional health potions - The author reviewed and refined Copilot’s output, including cheat codes for invincibility. - Copilot also generated a “dungeon scribe” agent that created documentation and ASCII diagrams explaining dungeon generation. - This workflow allowed the author to concentrate on mechanics, balance, player experience, and easter eggs rather than boilerplate and scaffolding. ## Binary Space Partitioning - Binary Space Partitioning (BSP) generates the dungeon by repeatedly dividing a large area into smaller regions. - The process begins with one rectangle representing the entire map. - That space is recursively split into smaller sections, which can then be used to place rooms and connect them. - BSP suits roguelikes because it balances: - Structure, avoiding chaotic layouts - Replayability through controlled randomness - Navigation, by supporting connected maps - The technique naturally produces clean rectangular rooms while retaining variation between generated levels. GitHub Dungeons shows how repository data, classic roguelike mechanics, and AI-assisted coding can combine into a playful development experiment. Using Copilot as an implementation partner lets the developer iterate quickly while remaining focused on designing an enjoyable game.

GitHub Copilot CLI for Beginners: Interactive v. non-interactive mode (opens in new tab)

GitHub Copilot CLI offers two ways to work from the terminal: interactive mode for ongoing, collaborative sessions and non-interactive mode for quick, one-off prompts. The article recommends choosing between them based on whether you need iterative exploration or a fast answer within an existing shell workflow. Previous sessions can also be resumed in either mode. ## Interactive Mode for Collaborative Work - Start it by running `copilot`. - It is the default mode and provides a chat-like, back-and-forth experience. - Users can: - Ask questions about a project. - Review Copilot’s responses. - Ask follow-up questions. - Request actions, such as running a local server. - Copilot may request permission to trust the current folder because it needs to read or modify project files. - This mode is best for exploratory coding, troubleshooting, and tasks that require multiple steps. ## Non-Interactive Mode for Quick Prompts - Start it with `copilot -p "your prompt"`. - It produces a single response without opening a full conversational session. - Typical uses include: - Summarizing a repository. - Generating code snippets. - Running Copilot inside automated workflows. - It is designed to keep users in their normal terminal flow and is most useful when the required task is clear and narrowly defined. ## Resuming Previous Sessions - In interactive mode, enter `/resume` to select a previous session. - From the regular shell, use `copilot --resume` to open the session picker directly. - Resuming preserves the context of earlier conversations, making it easier to continue unfinished work. The practical choice is simple: use interactive mode for deeper, iterative collaboration and non-interactive mode for focused, one-shot requests.

Building an emoji list generator with the GitHub Copilot CLI (opens in new tab)

Cassidy Williams describes building an AI-powered emoji list generator during GitHub’s Rubber Duck Thursdays livestream. The terminal application converts bullet points into relevant emojis, then copies the formatted Markdown list to the clipboard with a keyboard shortcut. The project demonstrates how GitHub Copilot CLI and SDK can quickly turn a small idea into a functional open-source tool. ## The Emoji List Generator - Runs directly in the terminal. - Accepts pasted or typed bullet points. - Uses AI to replace each bullet with a relevant emoji. - Generates the result when the user presses `Ctrl + S`. - Copies the completed list to the clipboard. - Exits with `Ctrl + C`. ## Technologies Used - `@opentui/core` provides the terminal user interface. - `@github/copilot-sdk` supplies the AI functionality. - `clipboardy` handles clipboard access. ## Building the Project with Copilot CLI - Development began in Copilot CLI’s plan mode using Claude Sonnet 4.6. - A natural-language prompt described the desired Markdown emoji generator and requested integration with the Copilot SDK. - Copilot asked clarifying questions about the technology stack and libraries. - It then produced a `plan.md` file for review. - The implementation was completed with Claude Opus 4.7 only a few minutes later. ## Copilot CLI Features Demonstrated The livestream project combined several Copilot CLI capabilities: - Plan mode for outlining the implementation. - Autopilot mode for carrying out development tasks. - A multi-model workflow using different Claude models. - The `allow-all` tools flag for permissive tool access. - The GitHub MCP server for GitHub-related integrations. The finished Emoji List Generator is available as a free, open-source project, alongside documentation for the GitHub Copilot CLI and SDK.

Build a personal organization command center with GitHub Copilot CLI (opens in new tab)

Brittany Ellich built a personal organization command center to reduce the friction of switching between numerous apps. Using GitHub Copilot for planning and implementation, she created a working first version in one day. Her experience suggests that AI-assisted development makes it easier to turn everyday frustrations into practical, customized tools. ## The Problem: Digital Fragmentation - Brittany wanted to consolidate information scattered across roughly a dozen applications. - Her goal was a calm, visual workspace suited to her learning style and the way she organizes information. - The project became a personal command center for bringing disparate work and productivity tools together. ## Planning and Building with AI - Brittany uses a “plan-then-implement” workflow. - During planning, Copilot interviews her about requirements and behavior until they form a sufficiently detailed plan. - Copilot then implements the system based on that plan, reducing guesswork and making development smoother. - The first version was completed in a single day alongside her normal work. ## Her Development Workflow - She uses VS Code Agent Mode for synchronous work, generally running up to two non-competing agent workflows. - She uses Copilot Cloud Agent for asynchronous, well-scoped tasks such as bug fixes and technical-debt cleanup. - This division lets her focus personally on work requiring close oversight while agents handle lower-risk background tasks. ## Technology Stack - **Electron** for the cross-platform desktop application. - **React** for the interface, components, and state management. - **Vite** for development tooling and hot module replacement. - **Tailwind CSS** for styling. - **WorkIQ MCP and CLI** for accessing Microsoft 365 data, including calendar information. - The application also uses ElevenLabs for its voice assistant. Although Brittany had wanted to build an Electron app, she learned relatively little about Electron because Agent Mode handled most of the implementation. She later simplified the repository manually to make it suitable for public release, noting that agents tend to add code more readily than remove it. ## Getting Started The project is available as the open-source `command-center-lite` repository. Running it requires Node.js 18 or later, GitHub Copilot CLI for WorkIQ setup, a Microsoft 365 account for calendar synchronization, and an ElevenLabs account for voice features. The broader recommendation is to start building solutions for small, personal problems. AI tools can accelerate both learning and implementation, making experimentation with unfamiliar technologies far more accessible.

GitHub Copilot CLI for Beginners: Getting started with GitHub Copilot CLI (opens in new tab)

GitHub Copilot CLI brings Copilot’s agentic coding capabilities directly into the terminal, allowing developers to inspect projects, generate code, run tests, and correct errors without switching tools. The post introduces the tool, explains installation and authentication, and demonstrates how to use it for project overviews, coding tasks, and delegated work. Its central message is that Copilot CLI can preserve development flow while supporting increasingly autonomous coding workflows. ## What GitHub Copilot CLI Does - Runs Copilot from a command-line interface with context from the current repository. - Can autonomously: - Build or modify code - Run tests - Detect and correct errors - Explore project files and documentation - Lets developers review results and request follow-up changes directly in the terminal. - Can delegate well-defined tasks to the Copilot cloud agent. ## Installing Copilot CLI - The primary cross-platform installation method, assuming Node.js is available, is: ```bash npm install -g @github/copilot ``` - Users can also install it through package managers such as Homebrew or WinGet. ## First-Time Setup - Launch the tool by entering `Copilot` in the terminal. - Authenticate with GitHub using: ```plaintext /login ``` - Authentication connects the CLI to the user’s Copilot account and the read-only GitHub MCP server. - Copilot must be granted permission to access the current folder so it can inspect or modify files. - Folder permissions can apply only to the current session or be saved for future sessions. ## Common Development Tasks - **Understand an existing project** - Prompt Copilot with: ```plaintext Give me an overview of this project ``` - It examines important files and summarizes the project structure and purpose. - **Generate new code** - For example: ```plaintext Let’s add a new endpoint to return all categories ``` - Copilot reviews existing conventions, documentation, and examples before proposing or creating files. - It requests permission before making changes. - **Delegate work to the cloud agent** - A task can be sent using: ```plaintext /delegate Let’s deal with issue #14 to add the rest of the CRUD endpoints to games ``` - The cloud agent retains the current context, creates a branch, opens a draft pull request, and performs the work in the background for later review. ## What Comes Next The broader beginner series will cover interactive mode, non-interactive mode using the `-p` flag, slash commands, and MCP server integration. These features expand Copilot CLI from an interactive coding assistant into a flexible terminal-based automation tool. Copilot CLI is recommended for developers who want AI assistance without leaving the shell: install it with npm, authenticate, grant project permissions, and begin with exploratory prompts before assigning code changes or delegated tasks.

GitHub Copilot CLI combines model families for a second opinion (opens in new tab)

GitHub Copilot CLI’s experimental Rubber Duck feature adds an independent reviewer from a different AI model family to catch mistakes before they compound. When Claude models orchestrate a task, GPT-5.4 reviews plans, implementations, and tests at key checkpoints. On SWE-Bench Pro, Claude Sonnet 4.6 with Rubber Duck closed 74.7% of the performance gap with Claude Opus 4.6 alone, particularly on complex, multi-file tasks. ## The Problem with Self-Review - Coding agents typically assess a task, plan, implement, test, and iterate. - Early assumptions can create downstream dependencies and make small mistakes expensive to fix. - Self-reflection helps, but a model reviewing its own work may retain the same training biases and blind spots. ## Cross-Family Review with Rubber Duck - Rubber Duck is a focused review agent powered by a complementary model family. - Claude orchestrators currently use GPT-5.4 as the reviewer. - It produces a short list of high-value concerns, including: - Missed details - Questionable assumptions - Architectural risks - Relevant edge cases ## Evaluation Results - On SWE-Bench Pro, Sonnet 4.6 plus Rubber Duck approached the resolution rate of Opus 4.6 running alone. - Benefits were strongest for problems involving at least three files and 70 or more steps. - Sonnet plus Rubber Duck scored: - 3.8% above the Sonnet baseline on difficult tasks - 4.8% higher on the hardest tasks across three trials - Examples included detecting: - A scheduler that would start and immediately exit - A loop overwriting one dictionary key and dropping Solr facet categories - Cross-file Redis references that would silently break email confirmation flows ## When Reviews Happen Rubber Duck can be invoked automatically, reactively, or on request: - After a plan is drafted, to prevent flawed decisions from spreading. - After complex implementation work, to identify edge cases. - After tests are written but before they run, to expose coverage gaps or weak assertions. - When the primary agent is stuck or repeating an unproductive loop. - Any time the user asks Copilot to critique its work. Copilot incorporates the feedback and explains what changed. Reviews are intentionally infrequent and targeted at checkpoints where they provide the most value. ## Availability and Use Cases - Rubber Duck is available in Copilot CLI’s experimental mode through `/experimental`. - It works with Claude Opus, Sonnet, and Haiku as orchestrator models, provided the user has GPT-5.4 access. - It is especially suited to: - Complex refactors and architectural changes - High-stakes coding tasks - Test coverage review - Getting a second opinion before committing to a plan Rubber Duck is a practical way to reduce model-specific blind spots by combining different AI families. Developers can enable it experimentally in Copilot CLI and use automatic or on-demand critiques for difficult work.

Run multiple agents at once with /fleet in Copilot CLI (opens in new tab)

GitHub Copilot CLI’s `/fleet` command lets multiple subagents work on independent tasks simultaneously rather than completing everything sequentially. An orchestrator decomposes the objective, manages dependencies, dispatches agents, and verifies their results. To benefit from parallel execution, users should define clear deliverables, boundaries, dependencies, and validation requirements. ## How `/fleet` Works - Breaks a task into discrete work items and identifies dependencies. - Runs independent items in parallel as background subagents. - Waits for completed work before dispatching dependent tasks. - Verifies results and assembles the final output. - Gives each subagent its own context window while sharing the same filesystem. - Prevents direct communication between subagents; the orchestrator coordinates them. ## Getting Started - Run `/fleet <objective prompt>` interactively, such as: ```bash /fleet Refactor the auth module, update tests, and fix the related docs in docs/auth/ ``` - For terminal-based non-interactive use: ```bash copilot -p "/fleet <YOUR TASK>" --no-ask-user ``` - The `--no-ask-user` option is required when no one is available to answer prompts. ## Writing Parallelizable Prompts - Define concrete deliverables such as individual files, test suites, or documentation sections. - Avoid vague requests that make it difficult to identify independent work. - Explicitly state: - File or module ownership - Constraints, such as avoiding dependency changes - Required tests, linting, or type checks - List dependencies so the orchestrator can serialize only the necessary work while parallelizing the rest. ## Using Custom Agents - Specialized agents can be defined in `.github/agents/`. - Agent definitions may specify: - Model - Tools - Role-specific instructions - Prompts can assign different agents to different tracks, such as using a technical writer for documentation and the default agent for code. - If no model is specified, the agent uses the current default model. ## Monitoring Fleet Execution - Review the initial decomposition to ensure the task has multiple independent tracks. - Use `/tasks` to inspect active background work. - Look for progress updates from separate tracks. - If work is proceeding sequentially, ask Copilot to decompose the task first and report each track’s status and blockers. ## Avoiding File Conflicts - Subagents share a filesystem without file locking. - If two agents edit the same file, the last completed write silently overwrites the other. - Assign distinct files or directories to each track. - For shared files, use temporary outputs and merge them afterward, or impose an explicit execution order. Use `/fleet` for well-partitioned work with clear ownership and dependencies. Careful prompt structure is essential: parallelism is most effective when agents can operate independently without competing for the same files.

Join or host a GitHub Copilot Dev Days event near you (opens in new tab)

GitHub Copilot Dev Days is a global, community-led event series designed to help developers adopt AI-assisted coding in practical ways. Through live demonstrations, workshops, and hands-on exercises, the events support everyone from beginners to experienced Copilot users. GitHub encourages developers to attend local events or organize one for their own user group. ## Purpose and Audience - Events address how AI is changing software planning, coding, reviewing, and delivery. - They are open to professional developers, students, and anyone interested in improving their workflow. - Beginners learn foundational tools and best practices. - Advanced users can explore updated Copilot techniques and features. ## Event Content and Format - Sessions include live demos, practical training, and interactive workshops. - Topics may cover: - GitHub Copilot CLI - Copilot Cloud Agent - Copilot in VS Code - Visual Studio - Other supported editors - Hosts include GitHub Stars, Microsoft MVPs, GitHub Campus Experts, student ambassadors, and GitHub and Microsoft employees. - A sample agenda includes: - 30–45-minute introductory Copilot session - 30–45-minute presentation from a local developer or community leader - One-hour hands-on coding workshop - Organizers can adapt event topics and formats to their local communities. ## Event Availability - Events begin in March in cities around the world. - Dates, topics, and formats vary by location, so attendees should review individual registration pages. - Attendance also offers opportunities to meet local developers and receive food, swag, and community support. - User groups interested in hosting an event can submit an organizer request form. Developers interested in practical AI-assisted development should find a nearby GitHub Copilot Dev Day and register soon, as places are limited.

From idea to pull request: A practical guide to building with GitHub Copilot CLI (opens in new tab)

GitHub Copilot CLI helps developers move from an idea to reviewable code without leaving the terminal. The recommended workflow is to begin with intent, let Copilot propose plans and scaffolding, validate changes through tests and diffs, then move to an IDE for refinement and GitHub for collaboration. Copilot accelerates development but does not replace design judgment, code review, or user approval. ## What Copilot CLI Is—and Isn’t - It is a GitHub-aware coding agent that operates in the terminal. - Developers can describe goals in natural language and use `/plan` or `Shift + Tab` planning mode. - It proposes commands, file changes, and diffs for review before execution. - It can generate files, modify code, and explain failures. - It does not silently run commands or eliminate the need for careful design and review. ## Start with Intent - Begin by describing the application or feature rather than choosing a framework or copying a template. - For example, ask Copilot to create a small web service with a JSON endpoint and tests. - Copilot may suggest a technology stack, file structure, and setup commands. - Review these suggestions before deciding what to execute. ## Scaffold Only What You Own - Once the direction is clear, ask Copilot to create a minimal project structure. - It can generate directories, configuration, test runners, and README files. - Generated scaffolding should be treated as a starting point, not an unquestioned design. - Developers remain responsible for reviewing, editing, or discarding the result. ## Iterate from Real Failures - Run tests directly within the CLI and use the resulting output as context. - Ask Copilot to explain a failure or propose a fix with a reviewable diff. - The recommended loop is: run a command, inspect the output, ask for help, and review the proposed change. - Use `explain` when understanding is the goal and `suggest` when seeking a concrete proposal. ## Handle Mechanical Repository-Wide Changes - Copilot CLI is effective for clearly scoped, repetitive work such as renaming symbols across a repository. - It can update related tests and provide a concrete diff. - Mechanical changes are relatively easy to inspect, revert, and validate. ## Move to the IDE for Precision - The terminal is best for fast exploration, planning, scaffolding, and low-ceremony changes. - Move to an editor or IDE when refining APIs, handling edge cases, and making design decisions. - A practical division is: - **CLI:** plan, generate diffs, and move quickly. - **IDE:** refine logic and shape the implementation. - **GitHub:** commit, open pull requests, review, and collaborate. ## Finish by Shipping on GitHub - Copilot CLI can help add descriptive commits, push changes, and create pull requests. - Pull requests make the work durable through teammate review, CI testing, and asynchronous collaboration. - The workflow can also add Copilot as a reviewer. - The ultimate value comes from reaching commits and pull requests, not merely generating suggestions. Copilot CLI is most effective as a momentum tool: use it to turn intent into concrete, testable changes, while retaining human control over design, approval, and review.