Alex: Welcome back. Challenge 16 is the Capstone Project, and it is the point where the workshop becomes a real contribution path.

Jamie: I like that word, path, because this one is not only about making one file and being done. It asks you to choose work that could actually help a repository.

Alex: Exactly. You choose Accessibility Agents, GLOW, or another meaningful repository, then prepare an agentic contribution. That could be an agent, a prompt, a custom instructions file, a skill, a workflow, an issue template, documentation, or even a strong contribution issue.

Jamie: And just to be clear on the title, this challenge is called Capstone Project.

Alex: Right. It unlocks after Challenge 15, at the same time as Bonus Challenges A through E. You can work on the capstone first, pick a bonus first, or move between them, but the bonus challenges are a structured path, not leftover extras.

---

Jamie: Before someone starts, what should they have ready?

Alex: You should understand the fork, branch, commit, push, and pull request workflow from earlier work. You should have VS Code ready for Day 2, and GitHub Copilot or Copilot Free active if you are testing agent behavior. If you joined Day 2 without Day 1, the Day 2 Quick Start is there to confirm your tools and baseline skills.

Jamie: This also connects back to the agent discovery work from Challenge 15, right?

Alex: Yes. Challenge 15 is browse-first: you explore the Accessibility Agents catalog and match agents to skills you have already practiced. You are not required to fork that repository just to complete Challenge 15.

Jamie: So the catalog is something learners browse and evaluate, not a fixed list they have to memorize.

Alex: Exactly. Accessibility Agents is a living catalog, so examples and inventory snapshots can change over time. The stable habit is to inspect the current repository, read the instructions, and ask whether you understand the manual skill the agent is meant to support.

---

Jamie: So when I open Challenge 16, the first real decision is where my contribution belongs.

Alex: Yes. The three recommended paths are Accessibility Agents, GLOW, or another repository you care about. A meaningful repository is one where you can explain who benefits, what workflow improves, and why your change fits.

Jamie: What questions help someone choose without getting stuck in options?

Alex: Ask: who would benefit if this were merged? Does the repository already use agents, prompts, instructions, skills, templates, or automation? Can you make one small, useful change? Can you fork it, open a branch, or at least prepare a review-ready draft? And can you set boundaries so the contribution does not overreach?

Jamie: Accessibility Agents sounds like the most direct route for an agent file.

Alex: It is a strong default because the repository is organized around agents, prompts, instructions, skills, and accessibility workflows. It is also the path where the Challenge 16 autograder can check an agent file for valid YAML frontmatter plus Responsibilities and Guardrails sections.

Jamie: And GLOW is a different kind of fit.

Alex: GLOW stands for Guided Layout and Output Workflow. It focuses on document accessibility and large-print production across surfaces like web, desktop tooling, command line workflows, VS Code agent tooling, and a Word add-in path. Good GLOW contributions might help users choose between Audit, Fix, Template, Export, and Convert workflows, or improve prompts, release-note review, documentation, or safety notes.

Jamie: What if someone has a personal project or a community project they already care about?

Alex: That can work too. The repository should be real, the contribution should be small enough to review, and the evidence should explain the mission, responsibilities, guardrails, and next steps. A project-specific custom instructions file, an accessible contribution guide, an issue template, or a maintainer workflow prompt can all be valid.

---

Jamie: The challenge asks for a mission statement. What makes that more than a slogan?

Alex: A good mission statement names the audience, the help being offered, and the reason it matters. For example: "Help workshop students navigate Git Going with GitHub challenges by explaining concepts and suggesting next steps without completing the work for them." That one sentence already gives reviewers a scope.

Jamie: And then the contribution can be several different asset types.

Alex: Right. You might create or improve an agent file, prompt, slash command, custom instructions file, skill, workflow update, issue template, documentation page, or issue triage plan. The capstone is about useful agentic work, not about forcing every learner into the same file type.

Jamie: I want to slow down on responsibilities and guardrails, because those words come up a lot.

Alex: Responsibilities are the tasks the contribution is designed to handle. Guardrails are the limits, safety checks, and refusal rules that keep it from doing the wrong thing. If your asset involves automation or AI assistance, those two sections tell reviewers how it should behave.

Jamie: Can you give a concrete example?

Alex: The reference solution uses a sample agent called Workshop Buddy. Its metadata includes a name, a description, and a tools list. Its responsibilities include answering workshop questions, pointing students to the right chapter, explaining Git and GitHub in beginner-friendly language, suggesting next steps when someone is stuck, and reminding people about accessibility best practices.

Jamie: And its limits are just as important as its helpfulness.

Alex: Yes. It should guide, not solve. It should not make repository changes directly, should not provide answers to challenge evidence prompts, should not access external services or APIs, and should be honest when a question is outside the workshop scope.

Jamie: The example interactions make that easy to hear. If a student asks what conflict markers are, the agent explains them. If a student asks it to write the PR description that proves their work, it refuses and helps them think through what to include.

---

Alex: Once you have a path and a mission, you need a workspace. The quickest browser route is Codespaces: choose the repository, select the Code button, choose the Codespaces tab, let the environment load, and create or update one focused file in the Explorer.

Jamie: Then if it involves an agent or automation, add the responsibilities and guardrails before opening anything for review.

Alex: Exactly. From there, create a branch, commit, and submit a pull request when you have access. If you do not have access, you can still save a branch, draft issue, or contribution plan.

Jamie: What about the local VS Code path?

Alex: Fork the chosen repository when fork-based contribution is possible. Then use the Command Palette with Git: Clone, using Ctrl+Shift+P on Windows or Linux, or Cmd+Shift+P on Mac. After cloning, create a branch such as capstone/your-username, use the Explorer to focus the parent folder, and use the arrow keys to move through files.

Jamie: And Source Control is where the Git work happens in VS Code.

Alex: Right. Open Source Control with Ctrl+Shift+G, or Cmd+Shift+G on Mac. Stage the files, write a clear commit message, publish the branch, and open the pull request through the GitHub Pull Requests extension if that is your workflow.

Jamie: Some people are faster at the command line.

Alex: That is fine too. With GitHub CLI, you can fork and clone a repository with a command like gh repo fork OWNER/REPO --clone, then create a branch with git checkout -b capstone/your-username. After editing, use git add ., commit with a message like "Prepare capstone contribution", push the branch, and run gh pr create.

Jamie: And if a pull request is not possible during the workshop, that is not a dead end.

Alex: Correct. Challenge 16 accepts a PR, a branch, a draft issue, or a contribution plan when it is review-ready and explains who it helps, what it does, and how it stays safe.

---

Jamie: If someone does choose the agent-file route, what does the file need to look like?

Alex: An agent file usually ends with .agent.md. The exact folder depends on the project, but examples include a community agents folder or a .github/agents folder. At the top, you include YAML frontmatter between lines of three hyphens, with fields like name, description, and tools.

Jamie: YAML frontmatter is just metadata, right?

Alex: Yes, metadata that tools can read. Keep it simple: a name, a one-sentence description, and a tools list such as tools: ["codebase"] or tools: []. After that, add the visible Markdown content, including the agent title, Responsibilities, and Guardrails.

Jamie: That explains why spacing and punctuation matter there.

Alex: They do. YAML is picky, so quoted strings and simple lists can save frustration. If your capstone includes an agent, the sample agent-file template in the docs is a safe starting point.

Jamie: How does the autograder fit into this?

Alex: The autograder only validates the Accessibility Agents path when you submit an .agent.md file. It checks for valid YAML frontmatter and the two required sections: Responsibilities and Guardrails. GLOW and other repository paths are reviewed by facilitators using the same ideas: mission, responsibilities, guardrails, and review readiness.

---

Jamie: After the file exists, how should learners test it?

Alex: If it is an agent, test it with Copilot Chat or the agent surface your project supports. Ask a realistic question, read the response, and check whether it stays in scope, asks clarifying questions when needed, avoids unsafe actions, and gives output a maintainer could review.

Jamie: So testing is not just "did it answer." It is "did it behave like the file says it should behave."

Alex: Exactly. If you wrote a prompt or slash command, run a sample and save the result or describe it. If you wrote documentation, an issue template, or a contribution plan, test the reader experience: can someone follow it, find the next action, and understand the boundaries?

Jamie: What if the learner cannot run the tool locally?

Alex: Then document how it should be tested. A review-ready draft can include expected inputs, expected outputs, risk areas, and what a reviewer should check. That is much stronger than saying "untested" with no context.

Jamie: I like that this keeps the door open for careful drafts, not only perfect finished work.

---

Alex: When you prepare the pull request or evidence, make it easy for a reviewer to understand the work. Include the mission, who it helps, what changed, how you tested it, and the responsibilities and guardrails.

Jamie: The Workshop Buddy example has a nice PR description pattern.

Alex: It explains the new agent, then names design decisions: guide without solving, stay scoped to the workshop, and keep accessibility awareness present. Its checklist confirms YAML frontmatter with name and description, the Responsibilities section, the Guardrails section, and example interactions showing both help and boundaries.

Jamie: And the Challenge 16 issue asks for evidence in a pretty practical format.

Alex: Yes. Share the repository you chose, the repository URL or fork, the contribution type, your mission statement, the PR, branch, or plan URL, the responsibilities, the guardrails, and what you reviewed in a peer or peer-simulation contribution.

Jamie: What should that peer review look for?

Alex: Check clarity, scope, responsibilities, guardrails, and usefulness to the target repository. If you cannot review a real classmate's capstone, use the peer-simulation PR and explain what you would check before calling the work ready for review.

---

Jamie: Once feedback comes in, what is the healthiest way to respond?

Alex: Thank the reviewer, ask a clarifying question if something is unclear, and make small commits that are easy to inspect. If you disagree with feedback, explain the design tradeoff calmly and tie it back to the mission and guardrails.

Jamie: And if the work is still a draft?

Alex: Say what kind of feedback you want. You might ask whether the scope is small enough, whether the guardrails are strong enough, or whether the contribution fits the repository's workflow.

Jamie: What does a solid capstone need to satisfy?

Alex: A real repository, a clear mission, useful responsibilities, sensible guardrails, and review-ready evidence. Work that goes beyond the basics usually includes examples, local testing notes, a tight scope, and alignment with how the project already works.

Jamie: And if someone gets stuck at the end?

Alex: If you do not know which repository to choose, start with Accessibility Agents for the most direct agent-building route, or choose GLOW or another repository if you already see a useful contribution there. If you do not know what to contribute, pick one small improvement: an agent, prompt, instructions file, issue template, or documentation page. If you cannot open a PR, submit a review-ready contribution plan instead.

Jamie: And if the autograder fails?

Alex: Check that you are on the Accessibility Agents .agent.md path, that the YAML frontmatter is valid, and that the file includes Responsibilities and Guardrails as sections. For GLOW or another repository, make sure the written evidence clearly explains the same criteria, because a facilitator will review it.

Jamie: Then the final action is to post the link or plan in the Challenge 16 issue and activate Close issue.

Alex: Yes. And that is a real milestone: you have completed Git Going with GitHub and prepared work that can continue beyond the classroom.