Alex: Welcome back. Challenge 13 is called AI as Your Copilot, and the main idea is simple: use GitHub Copilot to improve documentation, then decide whether the suggestion deserves to stay.

Jamie: I like that wording, because it does not say, let the AI take over. It says, use it, inspect it, and keep your own judgment in charge.

Alex: Exactly. Copilot can be a writing partner, a code explainer, a command helper, and sometimes a creative spark. But it can also be confidently wrong, too wordy, or unaware of the workshop context.

Jamie: So the win is not just getting a nicer paragraph. The win is being able to say what you asked, what Copilot offered, and why you accepted, changed, or rejected it.

Alex: Yes. In this challenge, that evaluation is part of the work. You are practicing AI-assisted contribution without handing away responsibility for the final change.

---

Jamie: Before someone starts, what needs to be working in VS Code?

Alex: You need VS Code open with your Learning Room repository available locally. Current VS Code builds include built-in AI features, so you usually do not need a separate Copilot Chat extension, but your GitHub account still needs Copilot access.

Jamie: And access can vary, right? Some people have Copilot Free, some have student access, and some are in an organization where an admin controls it.

Alex: Right. Copilot Free is available to individual developers with monthly limits, verified students may have the GitHub Copilot Student plan, and enterprise or organization access depends on policy. If you are unsure, check your Copilot settings on GitHub, review the Copilot plans page, or ask a facilitator before burning time troubleshooting.

Jamie: There is also billing language in the chapter. Do learners need to panic about that?

Alex: No panic. The workshop keeps prompts short and focused on documentation tasks. The important practical note is that GitHub Copilot is moving to usage-based billing on June 1, 2026, and features like chat, CLI, cloud agent, Spaces, Spark, and third-party coding agents use GitHub AI Credits, while code completions and next edit suggestions are not billed in AI Credits for paid plans.

Jamie: So if Copilot is missing, first update VS Code, then look for the Copilot status item, or use the Command Palette.

Alex: Yes. Open the Command Palette with Ctrl+Shift+P, or Cmd+Shift+P on Mac. You can run commands like Chat: Open Chat, Inline Chat: Start in Editor, or Chat: Open Agents Window if a shortcut does not work with your keyboard layout or assistive technology setup.

---

Alex: The assigned Challenge 13 issue starts in the same file from the code review challenge: docs/code-review-sample.md. Open it from the Code tab if you need to orient yourself, then open that same file locally in VS Code.

Jamie: So we are not asking Copilot to invent a whole new project. We are asking it to improve a real workshop document that already exists.

Alex: Exactly. Select a paragraph or section that could be clearer, or choose an issue you noticed during Challenge 12. Then start Copilot from the Copilot icon, the shortcut your setup supports, or the Command Palette.

Jamie: The prompt can be plain, right? Something like, improve the clarity of this paragraph for beginners.

Alex: That is a good starting point. You might also ask, suggest a better heading for this section, or rewrite this paragraph for someone new to pull requests. The key is to keep the request focused enough that you can evaluate the result.

Jamie: And once it suggests something, the options are accept, modify, or reject.

Alex: Yes. Accept means the suggestion is accurate, clearer, in the right tone, and accessible. Modify means Copilot helped, but you need to tighten it, remove extra claims, or make it fit the document. Reject means the original is better, or the AI introduced a problem.

---

Jamie: What makes a prompt good for documentation work?

Alex: A good prompt gives context, states the audience, names the task, and adds constraints. For example, instead of saying, make this better, say, rewrite this README paragraph for beginning GitHub contributors, keep the tone welcoming, avoid jargon, and do not add new facts.

Jamie: That last part matters. If Copilot adds new facts, now you have to verify them.

Alex: Exactly. Chapter 16 gives several useful patterns: contextual rewrite, generate with constraints, review and improve, accessibility audit, and draft from an outline. All of them work best when you tell Copilot what material to use and what not to invent.

Jamie: Can learners use inline suggestions too, or should they only use chat?

Alex: They can use both. Inline suggestions are the ghost text that appears while you type in the editor. You can accept a suggestion, open the full suggestions panel with Ctrl+Enter, or accept part of it word by word with Ctrl+Right Arrow, and on Mac that is usually Cmd+Right Arrow.

Jamie: Ghost text can be noisy with a screen reader, though.

Alex: It can. NVDA, JAWS, and VoiceOver users may want to adjust announcement settings, use Accessible View, or temporarily disable inline suggestions if they are interrupting concentration. You can disable them for the current language, turn them off through the Copilot status item or Command Palette, or change the setting more permanently in VS Code settings.

---

Jamie: Chat feels easier to review because the answer is in one place. How do you recommend opening it?

Alex: The current default shortcut in VS Code is Ctrl+Alt+I for the Chat view, but shortcuts can vary. The reliable fallback is the Command Palette command Chat: Open Chat. Once it opens, the panel is usually a sidebar with controls near the top, the conversation history, the response area, and the input box.

Jamie: And chat has modes now, not just one text box.

Alex: Right. Ask mode is best when you want an explanation or advice. Edit mode is better when you want Copilot to propose changes. Agent mode lets Copilot take more initiative, including planning work and requesting terminal commands, so it needs closer supervision.

Jamie: What about models? The chapter mentions choosing a model and auto selection.

Alex: For this workshop, do not get stuck comparing models. Use the default or auto selection unless a facilitator tells you otherwise. The bigger skill is asking a focused question and reading the result carefully.

Jamie: And if the response streams by too fast?

Alex: Use Accessible View. In VS Code, Alt+F2, or Option+F2 on Mac, opens the response in a plain text buffer that is easier to read, search, and copy from. That is useful for chat answers, inline suggestions, and code blocks, especially when the response is long.

---

Jamie: Chapter 16 also talks about Copilot Edits, Agent mode, the Agents window, and Next Edit Suggestions. How much of that is required for this challenge?

Alex: The assigned challenge can be completed with a focused documentation edit, so you do not need the advanced features. But it helps to know what they are, because they may appear in your VS Code interface.

Jamie: So Copilot Edits is for bigger changes?

Alex: Yes. Copilot Edits can propose changes across one or more files. If you use it, pay attention to the working set, then review the diff file by file so you know exactly what changed before you accept anything.

Jamie: And Agent mode is the one where Copilot may try to drive the work.

Alex: Correct. Agent mode can plan steps and ask permission to run terminal commands. Never approve a command just because it sounds official. Read it, ask what it does if needed, and reject anything that modifies files, installs packages, or contacts services in a way you do not understand.

Jamie: What is the VS Code Agents window for?

Alex: In newer VS Code builds, the Agents window can show available agents and related chat experiences. The safety advice is the same: keep the task small, inspect proposed changes, and do not share secrets, tokens, private keys, or personal data in prompts.

Jamie: And Next Edit Suggestions?

Alex: Those suggest likely follow-up edits after you make a change. They can be convenient for repeated documentation cleanup, but still treat each suggestion as a draft, not a decision.

---

Jamie: What if someone wants to use Copilot outside VS Code?

Alex: On GitHub.com, Copilot Chat can answer questions about a repository, an issue, code, or general programming topics, depending on your access. In the browser editor, you may also see a Copilot or Copilot actions button when editing a file. If you do not see it, use the VS Code method instead.

Jamie: There are also pull request features, right?

Alex: Yes. Copilot can help draft pull request summaries and may offer code review assistance on GitHub.com. Those are helpful starting points, but you still need to read the PR, confirm the summary is true, and make sure comments are fair and specific.

Jamie: And the command line option is GitHub CLI with Copilot?

Alex: Right. If the gh-copilot extension is installed, you can ask for command suggestions, like how to create an issue with multiple labels, or ask it to explain a command such as git merge --squash. Treat suggested commands with extra care, because command-line mistakes can change files or repository history.

Jamie: The chapter also compares custom instructions and custom agents. Those sound similar, but they are not the same thing.

Alex: Custom instructions are standing guidance that Copilot should follow, such as documentation style, accessibility standards, commit message format, tone, keyboard navigation expectations, WCAG 1.3.1 checks for info and relationships, and design system rules. They can live in places like .github/copilot-instructions.md, depending on the feature and support level.

Jamie: So instructions guide every response, while agents handle a more specific workflow.

Alex: Exactly. A custom agent can be built for a particular kind of task, while instructions provide the baseline behavior. Good instructions are concrete and team-specific; weak instructions are vague, generic, or so broad that Copilot cannot tell what to do.

---

Alex: Now comes the most important habit: evaluate every suggestion before it enters your repository.

Jamie: The challenge gives five questions. Is it factually correct? Is it clearer? Does it keep the tone? Is it accessible? Did the AI add content I did not ask for?

Alex: Yes. If a suggestion is factually wrong, reject it. If it is not clearer, keep the original. If the tone is off, modify or reject. If it introduces an accessibility issue, fix it or reject it.

Jamie: The common mistakes are very real: fake links, fancy language, lost context, and accessibility regressions.

Alex: Exactly. A fake link can look convincing but lead nowhere. Over-complicated language can turn a beginner-friendly paragraph into a wall of buzzwords. Lost context might make the answer drift into unrelated Python or machine learning content. Accessibility regressions include images without alt text, complex tables where a list would be clearer, or color used as the only way to communicate meaning.

Jamie: Can you give an example of a good Copilot interaction?

Alex: Sure. Suppose you ask Copilot to review alt text in docs/welcome.md for screen reader users. It notices an image with alt text that only says screenshot and suggests something more descriptive, like Learning Room repository Code tab showing the file list with README.md, docs folder, and .github folder.

Jamie: That is better because it says what the image communicates, not just that an image exists.

Alex: Right, but you still evaluate it. Maybe Copilot's version is too long, so you shorten it. Maybe the image is decorative, in which case empty alt text could be more appropriate. You check the purpose of the image, then decide.

Jamie: And when facts are involved, use current references, not Copilot's confidence.

Alex: Yes. Use official Copilot documentation, VS Code Copilot documentation, GitHub Accessibility guides, Copilot plan and billing pages, the custom instructions support reference, custom agent documentation, model selection documentation, and the Copilot changelog when you need current details.

---

Jamie: Once the documentation edit is ready, what does the repository need to show?

Alex: Save the final version of docs/code-review-sample.md, then stage, commit, and push it on a non-default branch. A typical commit message is docs: improve code-review-sample clarity with Copilot assistance.

Jamie: And the autograder is not judging whether the AI wrote the perfect paragraph.

Alex: Correct. The automated check verifies that a commit exists on a non-default branch. The human learning evidence is in your Challenge 13 issue, where you describe what you asked Copilot, what it suggested, how you evaluated it, one thing it got right, and one thing it got wrong or needed help with.

Jamie: There is also a peer simulation check. Compare the Copilot result with the peer-simulation PR, or with a real buddy if one is available, and ask whether the document actually improved.

Alex: Yes. And if your cohort asks you to bring in the workshop review bot, mention @gandalf-bot in a commit message or PR comment so the change can be audited. Follow your assigned issue first, then any facilitator-specific directions.

Jamie: What are the common stuck points?

Alex: If Copilot is not available, confirm access and sign-in, and ask a facilitator about alternatives. If controls are missing, update VS Code, reload the window, and use the Command Palette. If chat responses are hard to hear, use Accessible View. If every suggestion seems good, make the task harder, such as asking for a rewrite for a screen reader user, then inspect whether the answer really helps.

Jamie: So Challenge 13 is a documentation contribution, a Copilot practice round, and a judgment exercise all at once.

Alex: Exactly. Use Copilot to help you write or review. Keep the parts that are accurate, clear, accessible, and useful. Change or reject the rest, and leave a clear record of how you decided.