Copilot Chat in the IDE and on GitHub

Completions answer the question "what comes next?". Many tasks need a conversation instead: "what does this file do?", "why does this test fail?", "how would I add caching here?". On May 26 Priya moved the series to Copilot Chat, the conversational side of Copilot, and to the places it appears: the code editor, GitHub.com, GitHub Mobile and the terminal through Copilot CLI. Dmitri had used chat mostly as a search box. By the end of the session he was using it to explain, fix, test and plan, and he had learned which answers to trust least.

Chat in the editor

In Visual Studio Code, chat opens in a side panel, in a quick chat box, or inline inside the file you are editing. The panel is for longer conversations; inline chat, opened with Ctrl+I (Cmd+I on a Mac), is for a change to the code in front of you, such as "add input checking to this function", and shows the result as a proposed edit you accept or discard. Other supported editors offer similar panels and inline chat with their own keys.

The editor's chat panel offers modes that set how much Copilot may do. In ask mode it answers questions and proposes code that you copy or apply yourself. In edit-style modes it proposes changes to the files you name, which you review as a set of differences before accepting. In agent mode it can decide which files to read and change, run terminal commands and tests, and repeat until the goal is met, asking for approval before actions such as running a command; lesson 5 covers agent mode. Mode names and the exact list change between versions, so check your editor, but the idea of choosing how much autonomy to give is stable.

Slash commands, participants and context references

Chat understands three kinds of shorthand. Slash commands name a common task. Chat participants, written with @, direct the question to a specialist that knows about a particular area. Context references, written with # or added with an attach button, put specific files, selections or other material into the prompt. They save typing, and, more importantly, they tell Copilot what to look at instead of leaving it to guess.

Chat history and starting fresh

Within one conversation, chat sends earlier questions and answers back to the model with each new request, so follow-up questions such as "now make it handle empty lines" work. History also has a cost: an earlier wrong assumption carries forward, and a long conversation uses more of the model's context window and more credits for heavier models. Priya's rule was one conversation per task. When the topic changes, start a new chat or use /clear, so that old context does not leak into a new question.

Chat on GitHub.com

On GitHub.com, Copilot Chat opens from the Copilot icon at the top of most pages and from buttons on files, issues and pull requests. It can answer questions about a repository's code, summarize an issue thread, explain a file you are viewing, help write an issue, or explain a failed Actions run. On pull requests, Copilot can write a pull request summary: a description of what changed and why, drafted from the diff, which the author edits before posting. Code review, which is different, is covered in lesson 6.

GitHub.com also offers Copilot Spaces, collections of files, notes, issues and instructions that a person or team curates for a topic, so that chat answers from that chosen material rather than from whatever it happens to find. Priya created a space called "TrailCheck data format" with the format specification, the parser and three example reports, and shared it with the web team. Questions asked in the space were answered from those sources, which made answers more consistent.

GitHub Mobile

GitHub Mobile includes Copilot Chat for questions about repositories, issues and pull requests on a phone or tablet. It is handy for reading and triage away from a desk, for example asking for a summary of a pull request before approving a small change. It is not a place for careful code review, and by default chats on GitHub.com and in GitHub Mobile are kept for a limited time, unlike editor chats; lesson 8 explains the difference.

Copilot CLI

Copilot CLI brings Copilot to the terminal. It is a separate program, installed with a package manager, that you start in a project folder and talk to in plain language. It can explain a command, suggest the right one for a task, write a short script, read and change files in the folder, and run commands, asking for approval before it uses a tool that changes anything. It can be used interactively, as a conversation, or programmatically, by passing a single request on the command line, for example in a script. An earlier GitHub CLI extension offered command suggestions and explanations; it has been replaced by the newer standalone tool, which is the one the current study guide describes.

# start an interactive session in the project folder
cd trailcheck
copilot

# example requests typed into the session
> explain what the build script in package.json does
> find every place we read reports/*.csv and list them
> write a shell command that counts reports filed in May 2027

Rosa was cautious about the CLI because it can run commands. Priya showed the approval prompts: before running a command or editing a file, the CLI says what it intends to do and waits for yes, yes for the rest of the session, or no. The team agreed to answer yes one step at a time in shared repositories and never to approve commands they could not read.

Dmitri used the CLI that afternoon to write a one-line command that counted trail reports by condition for the Moncton office's weekly summary. He checked the command's output against a count he did by hand for one day before trusting it for the week.

Checking a chat answer

Chat answers sound authoritative, which makes their errors easy to miss. Priya gave Dmitri three checks. First, verify claims against the code: if chat says a function is called in three places, search for it. Second, run proposed code before relying on it, especially commands. Third, ask for sources: when chat refers to documentation or a library behaviour, open the official page. She also showed the feedback buttons, thumbs up and down on each response, which send feedback to GitHub and are part of how the product improves; they do not change the answer you were given.

Limits worth knowing

Chat has limits that the exam expects you to know. Its view of a project is limited by the context window and by what it searches. It may not know about library versions or features released after its model was trained. Answers vary: asking the same question twice can give different responses. Heavier models use more credits, and organization policies can restrict which models and features are available. Chat can also be wrong with great confidence, which is why responsibility stays with the person.

Chat for learning a codebase

One of chat's most valuable uses is orientation. When Lena joined in March she spent her first days reading trailcheck to understand how it fitted together. With chat she could ask "where does a trail report go from the moment it is submitted to the moment it appears on the site?", get a walk-through naming the files involved, and then open each file to check. Priya encouraged this kind of question because it is easy to verify: every claim names a file or function you can look at. She discouraged questions such as "is this code good?", which invite confident opinions that are hard to check and easy to over-trust.

Chat is also useful for explaining things that are not code at all but sit next to it: a build log, an error message, a configuration file, a regular expression someone wrote years ago. Selecting the text and using /explain usually gives a clear first reading. For anything that matters, such as a security setting or a deployment step, the official documentation is still the source of truth, and the habit of opening it after reading Copilot's explanation catches most errors.

Applying code from chat

Chat answers often contain code blocks with buttons to copy the code, insert it at the cursor, or apply it to the file as a proposed edit. Applying an edit shows the change as a difference you can accept or reject, which is safer than pasting, because you see exactly what will change, including lines removed. Priya's rule was to apply rather than paste whenever the editor offers it, and to run the tests after accepting any change from chat. When chat proposes changes to several files, review each file's difference separately; it is easy to accept a set of changes because the first one looked right.