diff --git a/.github/instructions/astro.instructions.md b/.github/instructions/astro.instructions.md
index 26e3c0a6..186f00bc 100644
--- a/.github/instructions/astro.instructions.md
+++ b/.github/instructions/astro.instructions.md
@@ -20,4 +20,4 @@ This is a docs wrapper. Don't add interactive framework islands (Svelte, React,
## Building and verifying
-After changing `astro.config.mjs` or anything under `website/src/`, build and verify the site with the [`build-and-verify-docs`](../skills/build-and-verify-docs/SKILL.md) skill. Its page-count invariant is the tripwire for unexpected routed pages: Starlight emits each of the 36 workshop routes for the root language and five configured locales, then adds the legacy redirect, for 217 built `index.html` pages excluding the 404 page. If the count changes without a corresponding route or locale change, check the locale layout under `docs/` and the underscore-directory exclude in `src/content.config.ts`.
+After changing `astro.config.mjs` or anything under `website/src/`, build and verify the site with the [`build-and-verify-docs`](../skills/build-and-verify-docs/SKILL.md) skill. Its page-count invariant is the tripwire for unexpected routed pages: Starlight emits each of the 40 workshop routes for the root language and five configured locales, then adds the legacy redirect, for 241 built `index.html` pages excluding the 404 page. If the count changes without a corresponding route or locale change, check the locale layout under `docs/` and the underscore-directory exclude in `src/content.config.ts`.
diff --git a/.github/instructions/markdown.instructions.md b/.github/instructions/markdown.instructions.md
index 78714542..3a9db1b0 100644
--- a/.github/instructions/markdown.instructions.md
+++ b/.github/instructions/markdown.instructions.md
@@ -142,7 +142,7 @@ Use Markdown image syntax with paths relative to the Markdown file:
## Path conventions
-- Per-path lessons: `cli/`, `vscode/`, `cloud/`, `app/`. Files are numbered by lesson order: `1-installing.md`, `2-custom-instructions.md`, etc.
+- Per-path lessons: `cli/`, `vscode/`, `cloud/`, `app/`. Files are numbered by lesson order: `1-install-copilot-cli.md`, `3-custom-instructions.md`, etc.
- Support images live in `_images/` directories and are excluded from routing by `website/src/content.config.ts`.
## Cross-repo links
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 43ed097c..1777f30c 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -14,11 +14,10 @@
## Verification
-
+
-- [ ] `cd website && rm -rf dist && npm run build` succeeds (target: 36 routes × 6 locales + 1 redirect = 217 built pages excluding 404; build reports 218 HTML files including 404, or note any intentional change)
-- [ ] Lychee link check passes:
- `mkdir -p /tmp/lychee-root && ln -sfn $PWD/website/dist /tmp/lychee-root/copilot-workshops && lychee --offline --no-progress --root-dir /tmp/lychee-root 'website/dist/**/*.html'`
+- [ ] `cd website && npm run check:all && rm -rf dist && npm run build` succeeds (target: 40 routes × 6 locales + 1 redirect = 241 built pages excluding 404; build reports 242 HTML files including 404, or note any intentional change)
+- [ ] Lychee link check passes: `mkdir -p /tmp/lychee-root && ln -sfn $PWD/website/dist /tmp/lychee-root/copilot-workshops && lychee --offline --no-progress --root-dir /tmp/lychee-root 'website/dist/**/*.html'`
- [ ] External GitHub URLs that I changed have been clicked manually (lychee runs offline)
## Screenshots
diff --git a/.github/skills/build-and-verify-docs/SKILL.md b/.github/skills/build-and-verify-docs/SKILL.md
index f2453bbd..582e337a 100644
--- a/.github/skills/build-and-verify-docs/SKILL.md
+++ b/.github/skills/build-and-verify-docs/SKILL.md
@@ -35,15 +35,15 @@ Open . Lesson content lives in the rep
Run all three. Don't commit if any fails.
-### 1. Build (clean)
+### 1. Type-check and build (clean)
```bash
-cd website && rm -rf dist && npm run build
+cd website && npm run check:all && rm -rf dist && npm run build
```
### 2. Page-count invariant
-The workshop has 36 distinct route slugs. Starlight emits each route for the English root locale and the five configured localized routes, using English fallback content when a translation is unavailable. The built site therefore contains $36 \times 6 = 216$ workshop routes plus the one legacy redirect (`/shared/0-prereqs/`, authored as a full-HTML redirect page at `website/src/pages/shared/0-prereqs.astro`). The expected count is 217 `index.html` files when excluding the 404 page. Astro reports 218 HTML files because it includes the 404 page.
+The workshop has 40 distinct route slugs. Starlight emits each route for the English root locale and the five configured localized routes, using English fallback content when a translation is unavailable. The built site therefore contains $40 \times 6 = 240$ workshop routes plus the one legacy redirect (`/shared/0-prereqs/`, authored as a full-HTML redirect page at `website/src/pages/shared/0-prereqs.astro`). The expected count is 241 `index.html` files when excluding the 404 page. Astro reports 242 HTML files because it includes the 404 page.
```bash
# distinct route slugs in the English root locale (docs/README.md + docs//*.md)
@@ -61,14 +61,14 @@ find website/dist -name index.html | grep -v 404 | wc -l
### 2b. Translations actually render (not silent English fallback)
-The build and the page-count above are **blind to which content actually renders** — a mis-nested or wrongly-identified locale tree still emits 217 pages served from English fallback. Assert that a known translated page carries translated text and the right `lang` attribute:
+The build and the page-count above are **blind to which content actually renders** — a mis-nested or wrongly-identified locale tree still emits 241 pages served from English fallback. Assert that a known translated page carries translated text and the right `lang` attribute:
```bash
grep -o '[^<]*' website/dist/es-es/app/2-add-star-rating/index.html # Spanish title
grep -o 'lang="[^"]*"' website/dist/es-es/app/2-add-star-rating/index.html | head -1 # lang="es-ES"
```
-The Spanish title should read `Lección 2 - Ejecutar tu primera sesión de agente`, not the English string. Spot-check a second locale (e.g. `ja-jp` -> `lang="ja-JP"`).
+The Spanish title should match the translated `title` in `docs/es-es/app/2-add-star-rating.md`, not the English string. Check the changed CLI pages as well, and spot-check another locale (e.g. `ja-jp` -> `lang="ja-JP"`).
### 3. Link check (lychee, offline)
@@ -86,8 +86,9 @@ Lychee runs offline and won't catch broken **external** GitHub URLs. When you ch
`.github/workflows/pages.yml` runs on PRs and on push to `main`. It runs **only**:
1. `npm ci`
-2. `npm run build` (Astro build) — must succeed
-3. lychee offline link check against `website/dist/` — must pass
+2. `npm run check:all` (Astro and TypeScript checks) — must succeed
+3. `npm run build` (Astro build) — must succeed
+4. lychee offline link check against `website/dist/` — must pass
After a push to `main`, `pages.yml` deploys `website/dist` to GitHub Pages. Browser validation and content-alignment analysis are separate optional/safety-net workflows, not part of the Pages build job.
@@ -109,7 +110,7 @@ When in doubt, `grep -rn "" --include='*.md' .` (excluding `node_modul
```bash
# from repo root
-cd website && rm -rf dist && npm run build && cd ..
+cd website && npm run check:all && rm -rf dist && npm run build && cd ..
mkdir -p /tmp/lychee-root && ln -sfn "$PWD/website/dist" /tmp/lychee-root/copilot-workshops \
&& lychee --offline --no-progress --root-dir /tmp/lychee-root 'website/dist/**/*.html'
```
diff --git a/.github/skills/check-content-alignment/SKILL.md b/.github/skills/check-content-alignment/SKILL.md
index 9fbbaf54..ab6479db 100644
--- a/.github/skills/check-content-alignment/SKILL.md
+++ b/.github/skills/check-content-alignment/SKILL.md
@@ -26,7 +26,7 @@ There are three recurring kinds of duplication in this repo. Most alignment gaps
- The "**Approve and run workflows**" step (appears in `cloud/5-iterating.md` and `vscode/6-iterating.md`).
- Shared prerequisites, MCP-setup, and recap blurbs.
2. **Parallel concepts across harnesses.** The same idea is taught up to four times, once per harness: `cli/`, `vscode/`, `app/`, and `cloud/`. A conceptual change (how MCP works, what a custom instruction is, how an agent proposes changes, the description of the Tailspin Toys demo app) often needs the same correction in the sibling lessons of the other harnesses.
-3. **Cross-references and shared facts.** Reference-style links to a renamed/retitled lesson, lesson numbers in prose, the published URL shape (`/cli/3-generating-code/`), the demo-app repo URL (`github.com/github-samples/tailspin-toys/...`), tool/library names, and screenshots referenced from multiple pages.
+3. **Cross-references and shared facts.** Reference-style links to a renamed/retitled lesson, lesson numbers in prose, the published URL shape (`/cli/4-build-filtering/`), the demo-app repo URL (`github.com/github-samples/tailspin-toys/...`), tool/library names, and screenshots referenced from multiple pages.
## Procedure
@@ -69,7 +69,7 @@ grep -rn "Approve and run workflows" docs --include='*.md'
grep -rln "custom instruction" docs/cli docs/vscode docs/app docs/cloud --include='*.md'
# Find cross-references to a page you renamed/retitled
-grep -rn "2-custom-instructions" docs --include='*.md'
+grep -rn "4-build-filtering" docs --include='*.md'
```
Exclude the file(s) you already changed from the candidate list.
diff --git a/.github/workflows/pages.yml b/.github/workflows/pages.yml
index 2e853b76..3f1cffaf 100644
--- a/.github/workflows/pages.yml
+++ b/.github/workflows/pages.yml
@@ -2,7 +2,7 @@ name: Build and deploy workshop site
# Builds the Astro + Starlight site under `website/` (sourcing lesson Markdown from
# `docs/`) and deploys to GitHub Pages on pushes to main. Every push and pull
-# request runs a build-only validation pass plus a link check, so the build can
+# request runs type-check, build, and offline link validation, so this job can
# serve as a required status check on any PR.
on:
diff --git a/AUTHORING.md b/AUTHORING.md
index bd8cefb1..13a644dc 100644
--- a/AUTHORING.md
+++ b/AUTHORING.md
@@ -15,8 +15,8 @@ copilot-workshops/
│ ├── cli/ ← Copilot CLI lessons (0-prerequisites.md + numbered exercises)
│ ├── vscode/ ← VS Code lessons (0-prerequisites.md + numbered exercises)
│ ├── cloud/ ← Cloud agent lessons (0-prerequisites.md + numbered exercises)
-│ ├── app/ ← GitHub Copilot app lessons (setup folded into Exercise 1)
-│ ├── es-es/ ja-jp/ ... ← Translated locale trees (currently the app harness)
+│ ├── app/ ← GitHub Copilot app lessons (setup 0–1, core modules 2–10)
+│ ├── es-es/ ja-jp/ ... ← Translated App and CLI locale trees
│ └── _images/ ← Screenshots and diagrams (shared across locales)
├── website/ ← Optional Astro + Starlight publisher
│ ├── astro.config.mjs ← Site URL, base path, locales, sidebar
@@ -31,7 +31,7 @@ copilot-workshops/
### Add a new lesson
-1. **Pick a path and number.** Lessons live under `docs/{cli,vscode,app,cloud}/N-name.md`. `N` is the next available integer in that path; the number drives the URL slug (`/cli/3-generating-code/`).
+1. **Pick a path and number.** Lessons live under `docs/{cli,vscode,app,cloud}/N-name.md`. `N` is the next available integer in that path; the number drives the URL slug (`/cli/4-build-filtering/`).
2. **Create the file** with frontmatter:
```markdown
---
@@ -44,8 +44,8 @@ copilot-workshops/
3. **Write the body.** Use Markdown and GitHub admonition syntax (`> [!NOTE]`) for callouts. See **Style essentials** below.
4. **Add prev/next navigation.** Define `[previous-lesson]` and `[next-lesson]` reference links at the bottom of the page, pointing at the adjacent lessons in the same path:
```markdown
- [previous-lesson]: ../2-custom-instructions/
- [next-lesson]: ../4-mcp/
+ [previous-lesson]: ../3-custom-instructions/
+ [next-lesson]: ../5-agent-skills/
```
Then surface them in the body using **the same style as the other lessons in your path** — don't mix styles within a path:
- **Woven into prose** (common in the CLI path): end the lesson with a sentence like ``the next step is to [create the PR][next-lesson]``.
@@ -60,7 +60,7 @@ copilot-workshops/
```
The first lesson in a path omits `[previous-lesson]`; the last omits `[next-lesson]`.
5. **Register in the sidebar.** Open `website/astro.config.mjs` and add an entry to the appropriate `items: []` block. The sidebar is *manually* maintained — order in the file is the order learners see.
-6. **Preview and verify, then open a PR.** Preview locally and run the verification sequence before committing — see [Building and verifying](#building-and-verifying) below. CI runs the Astro build and the lychee link check; both must pass.
+6. **Preview and verify, then open a PR.** Preview locally and run the verification sequence before committing — see [Building and verifying](#building-and-verifying) below. CI runs type checks, the Astro build, and the lychee link check; all must pass.
### Landing pages (folder `README.md`)
@@ -85,7 +85,7 @@ When you add a new harness or locale landing, name it `README.md` and set its `s
### Edit an existing lesson
-1. **Find the file** under `docs/` (use the published URL as a hint — `/cli/3-generating-code/` lives at `docs/cli/3-generating-code.md`).
+1. **Find the file** under `docs/` (use the published URL as a hint — `/cli/4-build-filtering/` lives at `docs/cli/4-build-filtering.md`).
2. **Edit the Markdown.** Same conventions apply — see **Style essentials** below.
3. **Preview** with `npm run dev` in `website/`.
4. **Commit, PR, merge.**
@@ -112,11 +112,11 @@ The site runs at .
**Verify** before committing:
-1. **Build** — `cd website && rm -rf dist && npm run build`. Must succeed.
-2. **Page-count invariant** — Starlight emits 36 workshop routes for English and each of the five configured locales, then adds the legacy redirect. This equals 217 built `index.html` pages when excluding the 404 page; the build reports 218 HTML files including the 404 page.
+1. **Type-check and build** — `cd website && npm run check:all && rm -rf dist && npm run build`. Must succeed.
+2. **Page-count invariant** — Starlight emits 40 workshop routes for English and each of the five configured locales, then adds the legacy redirect. This equals 241 built `index.html` pages when excluding the 404 page; the build reports 242 HTML files including the 404 page.
3. **Link check** — lychee (offline) against the built `website/dist/`. Catches broken internal links/images.
-**What CI enforces vs. what you run locally:** CI (`pages.yml`) runs the **build** and the **lychee** link check on every PR. It does not run browser validation or the content-alignment agentic workflow as part of the Pages build job. After merge to `main`, `pages.yml` deploys the site to GitHub Pages.
+**What CI enforces vs. what you run locally:** CI (`pages.yml`) runs **`check:all`**, the **build**, and the **lychee** link check on every PR. It does not run browser validation or the content-alignment agentic workflow as part of the Pages build job. After merge to `main`, `pages.yml` deploys the site to GitHub Pages.
**Consistency pass.** When a change renames a file or folder, adds or removes a skill or instruction file, touches duplicated prose, or changes how the build works, also sweep for stale references — the structure trees and cross-doc pointers in `README.md`, `AUTHORING.md`, and `.github/copilot-instructions.md` aren't checked by the Astro build. The [`build-and-verify-docs`](./.github/skills/build-and-verify-docs/SKILL.md) skill has the full checklist, and the `check-content-alignment` skill plus `.github/workflows/content-alignment.md` help catch prose that needs aligned updates.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 64292b5f..f22877a7 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -24,10 +24,11 @@ If you want to **author or edit content**, start with [`AUTHORING.md`](./AUTHORI
CI (`pages.yml`) must be green on your PR. It runs:
+- **Type checks** — `npm run check:all` (Astro and TypeScript checks).
- **`pages.yml` build** — `npm run build` (Astro site build).
- **Lychee** — offline link check of the built `website/dist/`.
-Before you push, run the full local verification sequence described in [AUTHORING.md → Building and verifying](./AUTHORING.md#building-and-verifying): clean build, page-count check, and lychee link check.
+Before you push, run the full local verification sequence described in [AUTHORING.md → Building and verifying](./AUTHORING.md#building-and-verifying): type checks, clean build, page-count check, and lychee link check.
## Commit messages
diff --git a/README.md b/README.md
index 38c04eb2..a1cb3773 100644
--- a/README.md
+++ b/README.md
@@ -22,7 +22,7 @@ For PR/CI rules, see **[CONTRIBUTING.md](./CONTRIBUTING.md)**.
- **`docs/`** — **Lesson source (plain Markdown). Edit here.** Browsable directly on github.com, no build required.
- `README.md` — Workshop landing page (also the published site's home via `slug: index`).
- `cli/`, `vscode/`, `cloud/`, `app/` — Per-harness lessons (Copilot CLI / VS Code / cloud agent / GitHub Copilot app). Each codespace-based harness opens with its own `0-prerequisites.md` setup lesson, and a folder `README.md` (routed via a `slug:` matching the folder) is its landing page.
- - `es-es/`, `ja-jp/`, `ko-kr/`, `pt-br/`, `zh-cn/` — Translated locale trees (currently the app harness).
+ - `es-es/`, `ja-jp/`, `ko-kr/`, `pt-br/`, `zh-cn/` — Translated App and CLI locale trees.
- `_images/` — Screenshots and diagrams (shared across all locales).
- **`website/`** — Optional Astro + Starlight site that publishes `docs/` to GitHub Pages. Only needed to self-host or preview the rendered site.
- `astro.config.mjs` — Site URL, base path, `locales` block, sidebar.
@@ -49,7 +49,7 @@ The site runs at .
## Verification
-Before opening a PR, build the site and run the full verification sequence — clean build, page-count check, and offline link check (lychee). The canonical commands live in **[AUTHORING.md → Building and verifying](./AUTHORING.md#building-and-verifying)** and the [`build-and-verify-docs`](./.github/skills/build-and-verify-docs/SKILL.md) skill. CI (`pages.yml`) runs the build and the lychee link check.
+Before opening a PR, run the full verification sequence — type checks, clean build, page-count check, and offline link check (lychee). The canonical commands live in **[AUTHORING.md → Building and verifying](./AUTHORING.md#building-and-verifying)** and the [`build-and-verify-docs`](./.github/skills/build-and-verify-docs/SKILL.md) skill. CI (`pages.yml`) runs `check:all`, the build, and the lychee link check.
## License
diff --git a/docs/README.md b/docs/README.md
index 56ff3ad5..72fed219 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -3,7 +3,7 @@ title: "Hands-on with GitHub Copilot's agents"
slug: index
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
The recent additions to the capabilities of GitHub Copilot provide powerful tools to the developer across the entire software development lifecycle (SDLC). This includes working with issues and pull requests on GitHub, interacting with external services, and of course code creation. This lab explores the functionality, providing real-world use cases and tips on how to get the most out of the tools.
@@ -23,11 +23,11 @@ GitHub Copilot inside **Visual Studio Code** and GitHub Codespaces. Work with Co
### 💻 [Copilot CLI](cli/)
-**GitHub Copilot CLI** — an agentic assistant that runs in your terminal. Install it, connect MCP servers, generate code with plan mode, and build your own skills, custom agents, and slash commands, all from the command line.
+**GitHub Copilot CLI** — an agentic assistant that runs in your terminal. After setup, follow nine core modules: ship a star-rating quick win, establish instructions, plan and build filtering, create a quality-checks skill, validate through Playwright MCP, create a QA agent, and merge the feature. Finish with CLI controls and a wrap-up. The flow has three pull-request milestones.
### 🤖 [Copilot App](app/)
-The **GitHub Copilot app** — a desktop application built on Copilot CLI. Run parallel agent sessions, switch session modes, collaborate on canvases, and manage GitHub issues and pull requests natively — including **Agent Merge**, which shepherds a pull request through rebases, review feedback, CI fixes, and merge.
+The **GitHub Copilot app** — a desktop application built on Copilot CLI. Follow the same setup and nine core modules through the star-rating, instructions, filtering, skill, MCP, QA, and feature-PR workflow, using the app's isolated sessions and **Agent Merge**. Create and merge a repository-backed canvas as the fourth pull-request milestone, then wrap up.
### ☁️ [Copilot Cloud Agent](cloud/)
diff --git a/docs/app/0-prerequisites.md b/docs/app/0-prerequisites.md
index 7e9a4050..9e3c47c5 100644
--- a/docs/app/0-prerequisites.md
+++ b/docs/app/0-prerequisites.md
@@ -15,18 +15,18 @@ In this lesson, you will:
## Install Node.js
-Several lessons ask an agent to build features and run the Tailspin Toys test suite locally, which needs **[Node.js][nodejs]** — the only runtime the project requires. Install version **22 or newer**; the current **LTS** release is a safe choice.
+Several lessons ask an agent to build features and run the Tailspin Toys test suite locally, which needs **[Node.js][nodejs]**. Use **Node.js 22.13 or later**, and confirm the supported version in your checkout's `package.json` and README.
The simplest option on every platform is the official installer:
1. In your operating system, open a terminal window using Windows Terminal, macOS terminal, or whatever you typically use.
-2. Run the following command to confirm you have at least Node.js 22 or higher installed:
+2. Run the following command to confirm you have Node.js 22.13 or later installed:
```shell
node --version
```
-3. If you see `v22` or a higher number, you can skip to the next section!
+3. If the reported version is at least `v22.13.0` and supported by the project, you can skip to the next section.
> [!TIP]
> You only need to complete these steps if you don't have Node installed, or you need to update.
@@ -41,10 +41,10 @@ The simplest option on every platform is the official installer:
node --version
```
-9. You should see `v22.x.x` or higher.
+9. Confirm the reported version is at least `v22.13.0` and supported by the project.
-> [!TIP]
-> Prefer containers? If you have **[Docker][docker]**, you can use the repository's [dev container][dev-containers] instead of installing Node.js locally — it bundles Node for you. You don't need both.
+> [!IMPORTANT]
+> This App path uses local worktrees. A runtime installed only in a container is not available to those local sessions. Each worktree also needs the project dependencies and Playwright Chromium for E2E checks. Follow the learner repository's README when preparing a worktree, and review any installation request before approving it.
## Set up the lab repository
@@ -64,6 +64,8 @@ You'll work against your own copy of the Tailspin Toys project. Create it now fr
> [!NOTE]
> When you create your repository from the template, a backlog of GitHub issues is created for you automatically. You'll work from these issues throughout the workshop — there's nothing to file yourself.
+Use a fresh copy of the revised template: it includes repository instructions, application code, tests, and an existing canvas extension, but no supplied custom agents or skills. You will create your own quality-checks skill and QA profile during the workshop. If you use an older copy, inspect existing customizations rather than overwrite them.
+
## Summary and next steps
You're set up! You installed Node.js so the project can build and test on your machine, and you created your own copy of the Tailspin Toys repository from the template.
@@ -79,7 +81,5 @@ Next, you'll install the GitHub Copilot app, connect the repository you just cre
[next-lesson]: ../1-install-copilot-app/
[nodejs]: https://nodejs.org/
[node-download]: https://nodejs.org/en/download
-[docker]: https://www.docker.com/products/docker-desktop/
-[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
[template-repository]: https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-template-repository
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
diff --git a/docs/app/1-install-copilot-app.md b/docs/app/1-install-copilot-app.md
index ee3f52c4..ab768c91 100644
--- a/docs/app/1-install-copilot-app.md
+++ b/docs/app/1-install-copilot-app.md
@@ -41,23 +41,23 @@ To use the GitHub Copilot app the first step, as you might imagine, is to instal
With your project connected, take a moment to learn your way around. The app organizes everything into a few areas in the sidebar:
-- **Sessions** — where agents do their work. Each session runs in its own isolated workspace, so you can run several at once without their changes colliding. You'll start your first session in the next lesson.
+- **Sessions** — where agents do their work. For this workshop, choose a **new working tree** so each PR milestone has an isolated checkout and branch. Other workspace choices exist, but are not used here.
- **Quick chats** — lightweight conversations for questions and brainstorming that don't need a branch or workspace of their own. You'll try one at the end of this lesson.
- **My work** — your issues and pull requests, surfaced through the app's **native GitHub integration**. From here you can browse and filter issues and pull requests, check CI status, start a session from an issue, and review pull requests — all without leaving the app.
-- **Automations** — saved agent tasks that run on a schedule or on demand. You'll create one near the end of the harness.
+- **Customize** — discover and manage MCP servers, skills, and canvases. You'll use it to configure Playwright MCP.
+- **Automations** — saved agent tasks that run on a schedule or on demand. The wrap-up links to these as a next step, not another workshop exercise.
### Find your seeded backlog
Because the app integrates with GitHub natively, the work waiting in your repository shows up right inside the app. When you created your repository from the template, a backlog of issues was filed for you — let's confirm it's there.
1. Select **My work** in the sidebar.
-2. The template seeded eight issues in your backlog. This harness focuses on the following three — confirm you can see them:
+2. Find these issues by title rather than assuming their issue numbers:
- Allow users to filter games by category and publisher
- Update our repository coding standards
- - Implement pagination on the game list page
-3. Select an issue to read its details. Each issue is also a launch point for an agent session — you'll start work from these issues later in the harness.
+3. Select an issue to read its details. Each issue is also a launch point for an agent session — you'll start work from these issues later in the harness. Other backlog issues provide context for the canvas, not another implementation task.
> [!NOTE]
> The list of items in My work is automatically filtered to only display items from the repositories you've added to Copilot app. Want to see work items from other repos? Add them to the app!
@@ -84,7 +84,13 @@ Congratulations! You've installed the GitHub Copilot app, connected your project
- get oriented in the workspace and find your seeded backlog in **My work**.
- use a quick chat to ask a fast, throwaway question.
-Next, you'll start your first agent session and make your first change to the project — showing a star rating on the game cards. Continue to [Lesson 2 - Running your first agent session][next-lesson].
+## Keep PR milestones separate
+
+You will merge four PRs: star ratings; instructions with a small demonstration; filtering with the skill, QA profile, and tests; then the triage canvas. Use one branch per PR milestone. Lessons 4–8 stay in the same filtering session, worktree, and branch, with checkpoint commits rather than extra PRs.
+
+A new App worktree can start from stale local state. Before each new milestone edits files, fetch the repository and fast-forward the new session branch to the latest `origin/main`. The next lessons show this explicitly. Do not stack branches, cherry-pick earlier work, or switch an active filtering session to another branch.
+
+Next, you'll start your first agent session and make your first change to the project — showing a star rating on the game cards. Continue to [Lesson 2 - Add star ratings: a quick win][next-lesson].
## Resources
@@ -92,7 +98,7 @@ Next, you'll start your first agent session and make your first change to the pr
- [Getting started with the GitHub Copilot app][getting-started]
- [Working with agent sessions in the GitHub Copilot app][agent-sessions]
-[ex0]: ../0-prerequisites/
+[previous-lesson]: ../0-prerequisites/
[next-lesson]: ../2-add-star-rating/
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
diff --git a/docs/app/8-review.md b/docs/app/10-review.md
similarity index 50%
rename from docs/app/8-review.md
rename to docs/app/10-review.md
index 5de4f1ba..9a308d11 100644
--- a/docs/app/8-review.md
+++ b/docs/app/10-review.md
@@ -1,44 +1,43 @@
---
-title: "Lesson 8 - Review and next steps"
-description: "Recap the GitHub Copilot app harness, automate recurring work, and explore where to go next."
+title: "Lesson 10 - Wrap-up and next steps"
+description: "Recap the nine core App modules, four PR milestones, and reusable quality workflow, then explore further resources."
authors:
- geektrainer
-lastUpdated: 2026-07-09
+lastUpdated: 2026-09-11
---
Over the last several lessons, you took a feature from idea to merge with the GitHub Copilot app, including:
- connecting a repository and orienting to the app's workspace and your seeded backlog.
- starting sessions from a direct task and from issues, and using Plan and Autopilot modes to control how the agent works.
-- guiding the agent with custom instructions and a reusable skill.
+- guiding the agent with custom instructions, then asking it to create a reusable skill with shell scripts that you inspected and ran for lint, unit tests, end-to-end tests, and type checks.
- testing your work with the Playwright MCP server in a real browser.
+- creating and selecting a QA custom agent to assess requirements, coverage, skill-script results, and browser evidence.
- collaborating with the agent on a shared canvas.
-- shipping changes up a ladder of merge automation — from merging on github.com yourself to letting **Agent Merge** land a pull request.
+- explicitly merging the early PRs yourself, then authorizing **Agent Merge** within the feature and canvas PR workflows.
-Let's automate some recurring work, talk through best practices, and look at where to go next.
+Setup Lessons 0–1 led into nine core modules, Lessons 2–10. Take a moment to review the artifacts and where to go next; this wrap-up does not launch another hands-on task.
-## Automate recurring work
+## What you shipped
-The app can run agents for you on a schedule or on demand through **automations** — great for routine tasks like triaging new issues or recapping recent activity. Let's create a simple, non-destructive one.
+The workshop has four PR milestones, each on its own branch from updated `main`:
-1. Select **Automations** in the sidebar, then select **New automation**.
-2. Give it a name, such as `Recap my recent work`.
-3. Choose a trigger. **Manual** lets you run it on demand; **On a schedule** runs it automatically; **When an issue is created** reacts to new issues. Choose **Manual** for this lesson.
-4. Enter a read-only prompt so the automation can't change anything, for example:
+1. **Star ratings:** display the existing `starRating` and an explicit unrated state on game cards.
+2. **Instructions and demonstration:** add the documentation convention and verify its effect on a small real code change.
+3. **Filtering and quality workflow:** implement the issue, create the shell-bundled `quality-checks` skill and QA profile, and include the associated tests.
+4. **Repository-backed triage canvas:** share a board that adds issue context without automatically implementing another feature.
- ```plaintext
- Summarize the pull requests merged in this repository over the last week, and list any issues still open in the backlog.
- ```
+Lessons 4–8 used the same filtering session, worktree, and branch. Checkpoint commits preserved progress within PR 3; skills, MCP configuration, and QA did not need separate feature branches. Each later milestone began only after the earlier PR merged and the fresh session branch was updated from `origin/main`.
-5. Pick the project (your Tailspin Toys repository) and create the automation.
-6. Run it on demand to see the result.
+## Different kinds of verification
-> [!TIP]
-> Automations can run locally or in the cloud. Enable **Run in the cloud** and pick the **Tools** an automation may use when you want it to run unattended on a schedule. Keep scheduled automations scoped and non-destructive until you trust their output.
+The early features used existing npm checks. Filtering added your manual browser inspection. The skill made the four checks repeatable through bundled scripts, MCP added direct agent browser observations, and QA combined requirements and coverage with final verification. The PR reused QA evidence only while it applied to the submitted revision.
+
+Tests added should close genuine gaps; a QA run that needs no new tests can be correct. Missing tools, skipped checks, and failures are visible blockers, not passes. Review code and evidence before authorizing merge, and refresh affected evidence after changes.
## Best practices
-When using any AI tool, the infrastructure around it drives the quality of what you get out. Instructions files, skills, and custom agents all played a part in this workshop — invest in them and reuse them across sessions.
+When using any AI tool, the infrastructure around it drives the quality of what you get out. You created instructions, a skill, and a QA profile in this workshop — review them and reuse them across sessions. Custom agents define specialist roles and instructions, with available tools governed by configuration and harness permissions; skills package reusable task instructions, executable scripts, and supporting resources loaded on demand. A custom agent can execute scripts too, including those bundled with a skill. Confirm actual script execution and custom-agent selection rather than relying on a convincing description.
Match the **mode and model** to the task. Use **Plan** to think through an approach before building, **Interactive** to stay in the loop on focused changes, and **Autopilot** only for well-scoped, isolated tasks. Choose a faster model for routine edits and a more capable model with higher reasoning effort for complex work.
@@ -49,6 +48,7 @@ Context still matters as much as infrastructure. Clearly describing *what* you w
You've covered the core workflow. A few more features worth a look:
- **Quick chats** for fast, throwaway questions that don't need a full session.
+- [**Automations**][using-automations] for recurring or on-demand tasks such as summarizing recent work. Review the schedule, permissions, and scope before adopting one; creating an automation is a next step, not part of this workshop.
- **Rubber duck** to talk through a problem and get high-signal feedback before you build.
- [**Custom agents**][custom-agents] to package a role, its tools, and its instructions for repeatable, specialized work.
- [`/chronicle`][chronicle] to generate a narrative of what happened in a session.
@@ -60,7 +60,7 @@ You've covered the core workflow. A few more features worth a look:
The best way to improve with any tool is to keep using it! Use it for production code, for hobby code, for the little app you've had in mind for years but never got around to building. Share your learnings with your team, and learn from theirs. And, as always, explore the documentation.
-If you'd like to explore more of the GitHub Copilot ecosystem, check out the [VS Code harness](../../vscode/), the [Copilot CLI harness](../../cli/), or the [Cloud agent harness](../../cloud/).
+If you'd like to explore more of the GitHub Copilot ecosystem, check out the [VS Code harness][vscode-harness], the [Copilot CLI harness][cli-harness], or the [Cloud agent harness][cloud-harness].
## Resources
@@ -71,6 +71,10 @@ If you'd like to explore more of the GitHub Copilot ecosystem, check out the [VS
- [Working with canvas extensions][canvas-docs]
- [About cloud and local sandboxes][sandboxes]
+[previous-lesson]: ../9-canvases/
+[vscode-harness]: ../../vscode/
+[cli-harness]: ../../cli/
+[cloud-harness]: ../../cloud/
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
[customize]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/app/2-add-star-rating.md b/docs/app/2-add-star-rating.md
index 0ac7a9e3..345b3497 100644
--- a/docs/app/2-add-star-rating.md
+++ b/docs/app/2-add-star-rating.md
@@ -1,5 +1,5 @@
---
-title: "Lesson 2 - Running your first agent session"
+title: "Lesson 2 - Add star ratings: a quick win"
description: "Start your first agent session in the GitHub Copilot app, make a small change to the game cards, and merge it as your first pull request."
authors:
- geektrainer
@@ -22,7 +22,7 @@ Each game in Tailspin Toys can have a star rating, and it already appears on the
## Anatomy of a session
-A **session** is a conversation with an agent that runs in its own isolated workspace. Every session gets a **dedicated git worktree and branch**, which is what lets you run several sessions at once — one adding a feature, another fixing a bug — without their changes colliding. Your sessions appear in the sidebar grouped by repository; select any one to switch to it.
+A **session** is a conversation with an agent. In this workshop you choose a **new working tree**, giving the session a dedicated checkout and branch. This isolates each PR milestone without a separate branch for every lesson. Your sessions appear in the sidebar grouped by repository; select any one to switch to it.
Inside a session you'll see three things: the **conversation** with the agent, the agent's **tool activity** as it explores and edits files, and the list of **changed files** with their diffs.
@@ -36,16 +36,20 @@ Let's start a new session to begin exploring the project and implementing our fe
-4. Use the following prompt to request the change:
+4. Choose a **new working tree** and **Interactive** mode below the prompt box. Use the following prompt to request the change:
```plaintext
- On the game cards, show each game's star rating. The Game type already includes a starRating field — it's a number out of 5, or null when a game hasn't been rated yet. Display it on each card in src/components/GameCard.astro, and when starRating is null show "No rating yet" instead. Keep the change small and don't restructure the card layout.
+ Before editing, identify this checkout and branch, confirm it is a clean new worktree, fetch origin, and fast-forward this session branch to origin/main. Confirm HEAD matches origin/main. Stop and explain if it is dirty, diverged, or cannot be updated; do not reset or discard work.
+
+ On the game cards, show each game's star rating. The Game type already includes a starRating field — it's a number out of 5, or null when a game hasn't been rated yet. Display it on each card in src/components/GameCard.astro, and when starRating is null show "No rating yet" instead. Keep the change small and don't restructure the card layout or change the data model.
+
+ Follow repository instructions, add or update appropriate tests, and run the relevant existing npm checks. Inspect prerequisites and ask before installing anything. Report the changed files and check results, then stop for my review. Do not commit, push, open a pull request, or implement another feature.
```
> [!NOTE]
> Notice how the prompt contained the name of the file for Copilot to update. While it's not required at all to specify which files Copilot should include in its work, pointing it in the right direction both helps Copilot quickly generate code and reduce token usage.
-5. Select Enter to send the prompt to Copilot.
+5. Press Enter to send the prompt to Copilot.
Copilot app begins work by first creating a new worktree, an isolated copy of the project. It then explores the project, locating the necessary files to update to add the new feature. It will then create the necessary code. You've now added a new feature with Copilot app!
@@ -76,7 +80,9 @@ All AI-generated changes deserve a review before they're merged, even small ones
## Check the changes
-Of course we shouldn't just read the code and assume it works. We should visually test everything as well! To do so we'll need to start the app from the terminal, then confirm everything works. Fortunately there's a terminal built into Copilot app!
+Review the agent's automated check results before opening a browser. Confirm that tests cover a numeric `starRating` and the `null` fallback, using the project's existing npm scripts rather than a skill that does not exist yet. A missing prerequisite or skipped check is not a pass.
+
+Then inspect the app manually using the session's built-in terminal. Identify the worktree before starting the server, and do not reuse a server belonging to another checkout.
1. In the review panel on the right side of Copilot app, select **Terminal**. If there is no **Terminal** button, select the **+** (labeled as **Open in panel**), then select **Terminal**.
@@ -89,26 +95,30 @@ Of course we shouldn't just read the code and assume it works. We should visuall
```
3. Once the server starts (this will just take a moment), open a browser window.
-4. Navigate to http://localhost:4321.
-5. You should now see star ratings on all the games on the landing page!
+4. Open the local URL printed by the server, normally `http://localhost:4321`. If the port is occupied, identify the owner instead of stopping an unrelated process.
+5. Confirm rated game cards display their value out of five. Where unrated data is available, confirm **No rating yet** appears; otherwise use the automated test to verify the null case rather than claiming you observed it.
6. Return to the terminal window.
-7. Select Ctrl+C to stop the dev server.
+7. Press Control+C (Mac) or Ctrl+C (Windows/Linux) to stop the dev server you started.
## Open and merge your first pull request
-Your change looks good — now it's time to ship it! You'll ask the agent to open a pull request, then review and merge it yourself on github.com. For now we'll manage this manually. In an upcoming lesson we'll explore how Copilot can handle some of the work for you automatically.
+Your change looks good — now it's time to ship PR 1. First authorize the commit and PR separately from implementation:
+
+```plaintext
+Review the full diff for the star-rating change and its tests, summarize the verification, and commit the reviewed changes on this session branch. Push the branch and create a pull request targeting main using the repository's PR template. Do not merge it.
+```
-1. In the upper right hand corner, select **Create PR**.
+1. Follow the created PR link in the session. If the app presents a **Create PR** confirmation, select it to approve the request rather than creating a second PR.
2. If prompted, select **Sign in with your browser** and follow the prompts to authenticate.
3. Copilot gets to work on creating the PR.
-Once the PR is created, Copilot will monitor any workflows on the repository that need to run. After a few moments, the button in the upper right will change to **Ready to merge**. This will be your indication your PR is ready to merge!
+Once the PR is created, inspect the full PR diff and the checks in **My work**. Read the learner repository's workflow results; wait for required checks and reviews, and resolve failures before merging. **Ready to merge** is not a substitute for reviewing the change or your local evidence.
4. Select the **PR** bubble just above chat to open your PR in the review pane to see your pull request. You can review the PR as needed here.
5. Once ready, select **Ready to merge**.
6. Select **Merge pull request** on the new dialog window to merge your pull request!
-You've now pushed a new feature to the website!
+Confirm PR 1 is merged into `main` before continuing. Merging the learner repository does not by itself deploy a website. The next lesson starts a fresh worktree and updates it from `origin/main` so it includes this PR.
## Summary and next steps
@@ -118,7 +128,7 @@ You've started your first agent session and shipped your first change! Specifica
- directed the agent to make a small, focused change to the game cards.
- reviewed the change in the workspace diff view.
- ran the app locally to confirm the star rating in the browser.
-- opened a pull request and merged it yourself on github.com.
+- opened PR 1, reviewed its checks, and explicitly merged it.
Next, you'll use the app to add a custom instructions standard to the repository — starting from one of the issues in your backlog. Continue to [Lesson 3 - Guiding Copilot with custom instructions][next-lesson].
@@ -129,6 +139,7 @@ Next, you'll use the app to add a custom instructions standard to the repository
- [Managing issues and pull requests with the GitHub Copilot app][managing-issues-prs]
[prior-lesson]: ../1-install-copilot-app/#install-and-configure-the-github-copilot-app
+[previous-lesson]: ../1-install-copilot-app/
[next-lesson]: ../3-custom-instructions/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
diff --git a/docs/app/3-custom-instructions.md b/docs/app/3-custom-instructions.md
index 4711afd4..1963fe11 100644
--- a/docs/app/3-custom-instructions.md
+++ b/docs/app/3-custom-instructions.md
@@ -1,9 +1,9 @@
---
title: "Lesson 3 - Guiding Copilot with custom instructions"
-description: "Use the GitHub Copilot app to add a custom instructions standard to your repository, starting from an issue in your backlog and merging the change as a pull request."
+description: "Add a documentation standard, demonstrate it on a small existing helper or component, and merge both as the second pull request."
authors:
- geektrainer
-lastUpdated: 2026-07-09
+lastUpdated: 2026-09-11
---
Context is key when working with generative AI. If a task needs to be done a particular way — or there's background information Copilot should know — you want that context available. One of the most powerful tools for this is [instruction files][instruction-files], which describe not just *what* code you want but *how* it should be structured. In this lesson you'll add a documentation standard to your repository, and you'll do it the way you'll do most work from here on: starting from an issue in your backlog and letting the agent make the change.
@@ -12,15 +12,17 @@ In this lesson, you will:
- explore how repository instructions and path-scoped instruction files reach the agent.
- start a session from the instructions issue in your backlog.
-- ask the agent to add a documentation standard to `.github/copilot-instructions.md`.
-- review the change and merge it as a pull request.
+- ask the agent to add a focused documentation standard to the appropriate repository instruction files.
+- demonstrate the standard with a small real code change, validate it, and merge PR 2.
## Scenario
As any good dev shop, Tailspin Toys has a set of guidelines and requirements for development practices. These include:
-- Documentation should be added to code in the form of TSDoc doc comments.
-- Formatting should be documented and enforced through linting.
+- Comments should explain intent and non-obvious decisions rather than restate code.
+- Exported functions in `db/` and `src/lib/` should document their purpose, parameters, and return values with TSDoc/JSDoc, including an injectable `db` argument where present.
+- Reusable Astro components should document their `Props` contracts, and comments should stay current when related code changes.
+- Existing formatting and lint guidance should be preserved.
Through the use of instruction files you'll ensure Copilot has the right information to perform the tasks in alignment with the practices highlighted.
@@ -28,13 +30,13 @@ Through the use of instruction files you'll ensure Copilot has the right informa
Custom instructions allow you to provide context and preferences to Copilot, so that it can better understand your coding style and requirements. This is a powerful feature that can help you steer Copilot to get more relevant suggestions and code snippets. You can specify your preferred coding conventions, libraries, and even the types of comments you like to include in your code. You can create instructions for your entire repository, or for specific types of files for task-level context.
-There are two types of instructions files:
+The project uses two kinds of instruction files:
- `.github/copilot-instructions.md`, a single instruction file sent to Copilot for **every** request for the repository. This file should contain project-level information — context relevant for most chat or CLI requests sent to Copilot. This could include the tech stack being used, an overview of what's being built, best practices, and other global guidance.
- `.github/instructions/*.instructions.md` files can be created for specific tasks or file types. You can use them to provide guidelines for particular languages (like TypeScript or Astro), or for tasks like creating a UI component or a new set of unit tests.
> [!NOTE]
-> Copilot supports other standards to bring in instructions guidance through AGENTS.md, CLAUDE.md and GEMINI.md, allowing you to ensure Copilot always has the right context.
+> Other instruction formats and support vary by harness. Consult the [custom instructions support reference][custom-instructions-support] before relying on a particular format.
### Best practices for managing instructions files
@@ -74,49 +76,55 @@ Take a moment to read the instruction files this repository ships with — there
11. Finally, open `.github/instructions/drizzle.instructions.md` and scroll to the bottom. Note the links to other instruction files (like `unit-tests.instructions.md`) and existing files in the project. This lets you break larger instruction sets into smaller, reusable files, and point Copilot at examples to follow when generating code. (Paths there are relative to the instruction file rather than the repo root.)
> [!NOTE]
-> The **Code formatting requirements** section in `copilot-instructions.md` documents the project's coding standards, but it doesn't yet require in-code documentation. In the next steps, you'll add rules for TSDoc doc comments and file comment headers.
+> Compare the existing guidance with the actual coding-standards issue before adding rules. This lesson focuses on intent-based comments, exported data-layer function documentation, and Astro `Props` contracts, not blanket file headers or comments that restate code.
## Start from the instructions issue
-In the previous lesson you started a session from a direct prompt. Most work, however, starts with an issue. Let's create a new session based off an issue filed to update the instructions files, then make the request for the update.
+Confirm PR 1 is merged before creating this session. Start a fresh worktree for PR 2; do not continue on the star-rating branch. Most work starts with an issue, so use the coding-standards issue to supply the requirements.
> [!NOTE]
> Because instructions files have a large impact on the code generated by Copilot, care should be taken in ensuring they clearly guide Copilot. Having Copilot create a first version, like you'll do in this lesson is a great approach, followed by a review by you to ensure the updates meet your requirements.
1. Select **My work** in the sidebar
2. Select the issue titled **Update our repository coding standards** to open the issue.
-3. Select **New session** in the upper right to start a new session based on the issue.
+3. Select **New session** in the upper right, choose a **new working tree**, and select **Interactive** mode.
-4. Use the following prompt to request Copilot update the instructions files to meet the requirements documented in the issue:
+4. Use the following prompt. Updating the new session branch before editing makes the latest merged `main` the actual starting point, even if the app's local checkout was stale:
- ```plaintext
- Following this issue, make the updates to the instructions files in this project to meet the requirements documented. Don't create the PR quite yet!
- ```
+ ```plaintext
+ Before editing, identify this checkout and branch, confirm it is a clean new worktree, fetch origin, and fast-forward this session branch to origin/main. Confirm HEAD matches origin/main and includes the merged star-rating PR. Stop if it is dirty, diverged, or missing that merge; do not reset, discard work, or create another branch.
+
+ Read the issue "Update our repository coding standards" and the existing repository instructions. Add a focused documentation convention: explain intent rather than mechanics; document exported functions in db/ and src/lib/ with TSDoc/JSDoc covering purpose, parameters, returns, and injectable db arguments where present; document reusable Astro components' Props contracts; and keep comments current when related code changes.
+
+ Put each rule in the appropriate existing instruction file without duplication or contradictions, and link to or summarize the updated standard in README. Preserve existing formatting and lint guidance. Do not require blanket file headers, migrate formatting tools, rewrite documentation across the application, or implement filtering. Show me the instruction diff, then stop for review. Do not create a skill or agent, commit, push, or create a PR.
+ ```
Copilot will make the updates!
## Review the change
-Let's both read through the updates Copilot made, but also ask it to provide an example of the code it will now generate based on the updated instructions.
+Read the updated guidance, then demonstrate its effect on a real file. A proposed snippet alone does not show that repository instructions affected a code change.
1. Select **Changes** in the upper right to open the code changes.
-2. Review the updated instructions file. Confirm it has the guidelines about adding documentation and comments to the code.
+2. Review the updated instruction files and README reference. Confirm the rules match the issue's comment philosophy, exported-function documentation, and component contracts without inventing a blanket file-header requirement.
> [!NOTE]
> Because AI is probabilistic rather than deterministic, the exact text will vary.
-3. Use the following prompt to ask Copilot to create an example of the code it will now generate:
+3. After reviewing the instructions, request a bounded demonstration in this same session:
+
+ ```plaintext
+ Demonstrate the updated documentation convention on one small existing exported TypeScript helper in db/ or src/lib/, or one reusable Astro component. Inspect the repository to choose a suitable existing file; do not assume a publishers helper exists. Make a small behavior-preserving readability improvement and apply the relevant function-documentation or Props-contract guidance. Explain non-obvious intent without adding comments that merely restate code.
- ```plaintext
- Do not make any updates, but show me what the code would look like. Based on the new instructions, if I asked Copilot to create a new library component to return all Publishers what would that code look like?
- ```
+ Keep the change bounded to that demonstration and any directly relevant tests. Do not implement filtering or create a new feature. Run the relevant existing npm checks, report what changed and how the instruction affected the code, and stop for review. Ask before installing anything. Do not commit, push, or create a PR.
+ ```
-4. Review the code Copilot proposes. Note the TSDoc doc comments and the file header comment it includes — exactly what the updated instructions ask for.
+4. Review the actual file diff, not only the chat response. Check that the documentation explains the real behavior and that the readability change preserves it. Review the relevant test, lint, and type-check results; resolve failures before continuing.
You've now updated the instructions files in the project and seen the impact it will have!
@@ -124,17 +132,23 @@ You've now updated the instructions files in the project and seen the impact it
Instructions files become assets in the repository, meaning they're shared with the rest of the team. Let's create a PR with our work, just like we would any other asset!
-1. In the upper right hand corner, select **Create PR**.
+First authorize the reviewed instructions and demonstration together:
+
+```plaintext
+Review the full diff for the coding-standard instructions, README reference, and bounded code demonstration, including any related tests. Summarize the verification and commit these reviewed changes on this session branch. Push the branch and create one pull request targeting main, using the repository's PR template and linking the coding-standards issue. Describe this as a partial contribution unless every issue acceptance criterion is satisfied; do not use closing keywords for incomplete work. Do not merge it.
+```
+
+1. Follow the PR link in the session. If the app presents a **Create PR** confirmation, select it without creating a duplicate PR.
2. If prompted, select **Sign in with your browser** and follow the prompts to authenticate.
3. Copilot gets to work on creating the PR.
-Once the PR is created, Copilot will monitor any workflows on the repository that need to run. After a few moments, the button in the upper right will change to **Ready to merge**. This will be your indication your PR is ready to merge!
+Inspect the full PR diff in **My work**, including both the instruction and code changes. Review the learner repository's CI results and any required reviews. Resolve failures before selecting **Ready to merge**; CI does not replace the demonstration or your review.
4. Select **Ready to merge**.
5. Select **Merge pull request** on the new dialog window to merge your pull request!
> [!NOTE]
-> With the standard merged into your default branch, it becomes part of the project for everyone — and for every new session. When you start the filtering session in the next lesson from an up-to-date default branch, the agent will follow this standard automatically. You'll see the TypeScript it generates include TSDoc doc comments without being asked — a small but real demonstration of instructions shaping generated code.
+> Confirm PR 2 is merged into `main` before beginning filtering. A new worktree alone does not guarantee current code: in Lesson 4 you will fetch and fast-forward the fresh session branch to `origin/main`, then verify both earlier merges are present before planning.
## Summary and next steps
@@ -142,10 +156,10 @@ You explored how the app picks up context from instruction files, then used a se
- explored the repository's `copilot-instructions.md` and path-scoped `*.instructions.md` files.
- started a session from the instructions issue in your backlog.
-- asked the agent to add a documentation standard to `.github/copilot-instructions.md`.
-- reviewed the change and merged it as a pull request.
+- asked the agent to add focused documentation rules to the appropriate instruction files and reference them from README.
+- inspected the standard's effect on a real code change, validated the result, and merged both as PR 2.
-Next, you'll build the filtering feature in a fresh session — and watch it pick up the standard you just merged. Continue to [Lesson 4 - Building a feature with Autopilot][next-lesson].
+Next, you'll build the filtering feature in a fresh session — and check that it follows the standard you just merged. Continue to [Lesson 4 - Build filtering with Plan and Autopilot][next-lesson].
## Resources
@@ -154,6 +168,7 @@ Next, you'll build the filtering feature in a fresh session — and watch it pic
- [Best practices for creating custom instructions][instructions-best-practices]
- [Awesome Copilot — a collection of instruction files and other resources][awesome-copilot]
+[previous-lesson]: ../2-add-star-rating/
[next-lesson]: ../4-build-filtering/
[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/app/4-build-filtering.md b/docs/app/4-build-filtering.md
index 328b1edd..6b2053b7 100644
--- a/docs/app/4-build-filtering.md
+++ b/docs/app/4-build-filtering.md
@@ -1,186 +1,122 @@
---
-title: "Lesson 4 - Building a feature with Autopilot"
-description: "Use Plan and Autopilot modes in the GitHub Copilot app to build a static, client-side filtering feature, watch it inherit your documentation standard, and verify it with an agent skill."
+title: "Lesson 4 - Build filtering with Plan and Autopilot"
+description: "Plan filtering from its issue, explicitly approve Autopilot, validate with the existing npm checks and a manual browser visit, and save a checkpoint."
authors:
- geektrainer
-lastUpdated: 2026-07-13
+lastUpdated: 2026-09-11
---
-We've made a couple of small updates to our project thus far. But more robust changes require a more robust process. Fortunately, the GitHub Copilot app is built to work with our existing flow, ensuring we build the right things the right way. This is the first of three lessons where you will follow a typical development process, starting by using an issue to generate a new feature and an agent skill to run the validation tests and linters.
+You have merged star ratings and the documentation standard with its code demonstration. Now build the filtering feature. This is the start of one larger PR milestone: keep this same session, worktree, and branch through Lessons 4–8.
In this lesson, you will:
-- start a fresh session from the filtering issue.
-- use **Plan** mode to plan the feature, then **Autopilot** to build it.
-- confirm the generated code follows the documentation standard you merged earlier.
-- verify your work with the project's `quality-checks` skill.
+- start from updated `main` and read the actual filtering issue.
+- resolve requirements in **Plan** mode before explicitly approving **Autopilot**.
+- review filtering and tests, then run the four existing npm checks.
+- visit the feature manually in a browser and save a checkpoint.
-## Scenario
+The skill, MCP validation, QA profile, and feature PR come in later modules. Do not create them during this implementation step.
-The home page lists every game, but visitors can't narrow the list down. The filtering issue asks you to let them filter games by **category** and **publisher**. Let's use Copilot to implement that functionality.
-
-## Background
+## Session modes
-Introducing AI coding agents to your development flow doesn't change the fundamentals. If anything, they become even more important! Most developers follow a flow that resembles:
+The mode selector below the prompt controls the agent's autonomy:
-1. Open a filed issue with details of what needs to be done.
-2. Create a plan of what needs to be built.
-3. Build and review the code.
-4. Run the tests to validate the code.
-5. Manually validate the new functionality.
-6. Create a pull request (PR).
-7. Once the code has been reviewed and the continuous integration process succeeds, merge the code.
+- **Interactive** keeps you involved as the agent works and requests input.
+- **Plan** prepares a plan for review before implementation.
+- **Autopilot** implements and iterates autonomously within the approved scope and permissions.
-> [!NOTE]
-> Depending on your team and organization, the exact specifics will vary. But most will be a variation on the theme listed above.
+Plan first, make approval explicit, then return to Interactive before creating reusable customizations.
-By sticking to this standard approach you ensure the code generated by AI meets the requirements set forth, and goes through the same vetting process as code written by hand.
+## Start from updated main
-## Session modes
+Confirm PR 1 and PR 2 are merged on GitHub. Create a fresh worktree for filtering rather than continuing either earlier branch.
-The **session mode** controls how much autonomy the agent has. You can set it from the dropdown below the prompt field and change it at any time:
+1. Select **My work** and find **Allow users to filter games by category and publisher** by title. Open it and copy its actual URL; issue numbers vary between repositories.
+2. Select **New session** and choose a **new working tree**. Keep **Interactive** mode for the baseline update.
-- **Interactive**: You and the agent work together. The agent suggests changes and waits for your input before proceeding.
-- **Plan**: The agent creates a plan first. You review and approve the plan before the agent executes it.
-- **Autopilot**: The agent works fully autonomously—writing code, running tests, and iterating without waiting for input.
+ 
-## Plan the filtering feature
+3. Send this setup request before planning or editing:
-The best time to catch a potential issue is before any code is written, and the best way to do that is a bit of planning in advance. By planning with Copilot you'll ask Copilot to generate a set of steps and document the approach it will take. You can then review the plan, make any suggestions you might have to improve it, before letting Copilot generate the code based on the plan.
-
-Let's open the issue, start a new session, and create a plan by switching into plan mode and making the request.
+ ```plaintext
+ Prepare this fresh filtering session without implementing anything. Identify the checkout and branch, confirm the worktree is clean, fetch origin, and fast-forward this session branch to origin/main. Confirm HEAD matches origin/main and includes the merged star-rating and coding-standards PRs.
-1. Select **My work** from the navigation tab.
-2. Select the issue titled **Allow users to filter games by category and publisher**.
-3. Select **New session** in the upper right.
+ Stop and explain if the checkout is dirty, diverged, or missing either merge. Do not reset or discard work, switch branches, create another branch, or edit application files. Report the baseline revision.
+ ```
- 
+4. Check the reported baseline. Fetching alone does not update the worktree: the current session branch must be fast-forwarded and its `HEAD` must match the fetched `origin/main` before work begins.
-4. Select Shift+Tab until the mode displays **Plan**.
+## Plan the filtering feature
- 
+Switch the mode selector to **Plan**. Replace the issue placeholder below with the URL you copied.
-5. Send the following prompt. The filtering issue is already in this session's context because you started from it:
+```plaintext
+Plan the filtering feature from this issue: . Read its full acceptance criteria and the repository instructions, then inspect the current static Astro application and its existing data-access helpers and tests. Do not implement yet.
- ```plaintext
- Plan the work based on the requirements documented in the issue. Please ask any clarifying questions you might have as you build the plan.
- ```
+Cover multiple-category selection, publisher filtering, combined category and publisher filtering, suitable data-access helpers, accessible controls, and unit and end-to-end coverage required by the issue. Ask me to resolve unspecified behavior, such as how multiple categories combine, clearing filters, and empty results, rather than silently invent requirements. Do not introduce a server API unless the requirements and existing architecture justify it.
-6. The agent may ask follow-up questions as it builds the plan. Answer them based on how you'd build the feature.
+Propose a bounded implementation and verification plan that follows the repository documentation convention and adds or updates the necessary unit and end-to-end tests. After confirming the commands in package.json, plan to run npm run lint, npm run test:unit, npm run test:e2e, and npm run typecheck:all using the existing project tooling. Record the issue URL and my approved clarifications in the plan so I can reuse them for QA.
-> [!NOTE]
-> Because Copilot is probabilistic, the exact follow-up questions Copilot asks will vary. In fact, it might not ask any questions! This is perfectly normal.
+Include these execution safeguards in the plan before I approve it: identify the checkout and server under test; inspect prerequisites before running checks; ask before installing software, dependencies, or browsers; do not reuse another worktree's server; stop only servers you started; and report other port conflicts rather than stopping unrelated processes. Missing prerequisites and skipped checks must be reported as blockers, not passes.
-7. Once completed, Copilot will offer a plan summary. Review the plan. You should see it propose building queries, adding filter controls, and of course tests. Provide feedback to refine it if you'd like — the agent will incorporate your suggestions into a new version.
+Include this implementation boundary in the plan: after I explicitly approve Autopilot, implement only the agreed filtering feature and its tests in this same worktree and branch, run the four checks, report the implementation and all check results including failures or blockers, then stop for my review and manual browser check. Do not create skills or custom agents, configure MCP, change branches, commit, push, or open a PR during implementation. The manual browser check and checkpoint commit happen later under my separate direction.
-## Build it with Autopilot
+For now, stay in Plan mode and stop with the plan for my review. Do not implement, create skills or custom agents, configure MCP, change branches, commit, push, or open a PR.
+```
-With the plan created, let's let Copilot build the implementation!
+Answer any clarifying questions and review the plan against the issue. Look for the data-access changes, accessible controls, and tests rather than accepting a UI-only implementation. Save the actual issue URL and approved clarifications from the plan for Lessons 6 and 7; use `none` when no extra criteria were needed.
-1. In the list of options in the **Plan summary** dialog, select the option closest to **Approve and implement with autopilot**.
+Before approving, confirm the plan itself contains the four checks, documentation convention, prerequisite and server safeguards, same-worktree/branch requirement, and the stop after implementation and verification. It must prohibit later skills, agents, MCP setup, commits, pushes, and PRs during implementation. If any boundary is missing, request a revised plan while still in **Plan** mode and inspect the revision before approving.
-Copilot will begin work on the implementation!
+## Explicitly approve Autopilot
-> [!NOTE]
-> If Copilot doesn't automatically start creating the necessary code, you can prompt it to do so by using a prompt like "Go ahead and start building out the plan!".
->
-> Creating the necessary updates will take several minutes. The agent edits and creates files, writes and runs tests, and iterates. Now's a good time to reflect on what you've explored so far, or to enjoy a beverage.
+Only after the reviewed plan contains your requirements and all execution boundaries, select **Approve and implement with autopilot** in the plan approval controls, or the equivalent explicit Autopilot option shown in your version. Confirm the mode indicator shows **Autopilot**.
-## Review the changes
+Approval can start execution immediately. All implementation scope, safety rules, and stop boundaries must therefore be in the reviewed plan before you approve; do not rely on adding them in a follow-up message after execution starts.
-All AI-generated code needs review before it's merged. Let's both review the code and run the site to ensure everything looks good.
+Autopilot can write code and tests and iterate on failures, but this permission is not permission to complete later workshop modules. A missing prerequisite is a blocker to resolve with approval, not a passed check.
-1. Select **Changes** in the upper right to open the code changes.
+## Review and verify the implementation
- 
+1. Open **Changes** and inspect the filtering implementation and tests.
+2. Compare the result with the issue and approved clarifications, including multiple categories and publisher combinations. Check that new or modified helpers follow the documentation standard from Lesson 3.
+3. Inspect actual command output for all four npm checks. These run directly now because you have not created the quality-checks skill yet.
+4. Resolve failures and rerun affected checks before accepting the implementation. Playwright's E2E configuration builds and serves a preview and can reuse a local server; make sure the tested server belongs to this worktree, not an earlier lesson.
-2. Review the changes. You should see new TypeScript and Astro files, and test files. Notice the new helper functions include TSDoc doc comments and a file header comment — the documentation standard you merged in Lesson 3, applied automatically without being asked.
-3. In the review panel on the right side of Copilot app, select **Terminal**. If there is no **Terminal** button, select the **+** (labeled as **Open in panel**), then select **Terminal**.
+## Check the feature manually
- 
+Return the session to **Interactive** mode before manual review and keep it there for Lesson 5.
-4. Enter the following command in the terminal window to start the web app's dev server:
+1. Open **Terminal** in this session's review panel. If needed, select **+**, then **Terminal**.
+2. Confirm the terminal is in the filtering worktree and run:
```shell
npm run dev
```
-5. Once the server starts (this will just take a moment), open a browser window.
-6. Navigate to http://localhost:4321.
-7. You should now see filters available on the landing page!
-8. If anything doesn't look right, you can ask Copilot to make the updates!
-9. Once satisfied, return to the terminal window.
-10. Select Ctrl+C to stop the dev server.
+3. Open the URL printed by this server in your browser, normally `http://localhost:4321`. If the port is occupied, identify its owner instead of stopping an unrelated process or assuming the existing server contains your changes.
+4. Exercise category selection, publisher selection, and their combination against the approved behavior. Check keyboard access and the agreed clearing and empty-result behavior.
+5. If anything fails, request a focused correction, review the diff, rerun affected automated checks, and repeat the relevant browser checks.
+6. Return to the terminal and press Control+C (Mac) or Ctrl+C (Windows/Linux) to stop the server you started. Confirm it stopped before the next module's E2E run.
-## Verify your work with the quality-checks skill
+This is your manual browser observation. Agent-driven browser observation through MCP comes in Lesson 6.
-You could eyeball the diff and call it done, but the team has a defined quality bar — and a repeatable way to check it.
+## Save a checkpoint
-**Agent skills** let you give Copilot guidance on how to perform repeatable tasks like running tests, generating builds, or creating pull requests. A skill is a folder of instructions, scripts, and resources that the agent can load on demand. [Agent Skills is an open standard][agent-skills-repo] used by a range of agents, so the same skill works across Copilot Chat in agent mode, Copilot cloud agent, Copilot CLI, and the GitHub Copilot app.
+After reviewing the changes and verification, authorize a local commit:
-Skills live in the `.github/skills` folder of a project, or globally in `~/.copilot/skills`. Each skill is a folder containing a `SKILL.md` file with YAML frontmatter (a `name` and a `description`) followed by the markdown instructions:
-
-```yaml
----
-name: quality-checks
-description: Run the project's test suites and linter to verify code changes are ready to commit, push, or merge.
----
+```plaintext
+Review the current diff and create a checkpoint commit for the filtering implementation and its tests. Keep this same filtering branch and worktree. Do not create skills or agents, configure MCP, push, or open a pull request.
```
-Skills can also include subfolders with scripts, assets, and reference material. The full structure is covered in the [agent skills specification][agent-skills-spec].
-
-> [!TIP]
-> Skills are loaded dynamically. The agent decides which skill applies based on the `description` field — a clear, scenario-specific description is the difference between a skill that gets used and one that gets ignored.
-
-## Explore the quality-checks skill
-
-Let's explore the skill to see what it does.
-
-1. If the review panel is not already visible, open it by selecting **Toggle review panel** in the upper right.
-
- 
-
-2. Select the **+** to add a new item to the review panel.
-3. Select **File**.
-4. Search for `SKILL.md`.
-5. Select `SKILL.md .github/skills/quality-checks` from the list of files to open it.
-6. Note the `name` and `description`. The description tells the agent *when* to use it — whenever code changes need to be tested, linted, or verified before a commit, push, or merge.
-7. Read through the skill. Notice it documents which script runs which suite (unit tests, Playwright end-to-end tests, ESLint), in what order, and how to debug common failures — so the agent runs the checks the team's way instead of guessing.
-
-## Run the checks
-
-In the same filtering session, ask the agent to verify the work. You won't name the skill — the agent will match it from your request.
-
-1. Return to Copilot app.
-2. Directly call the skill by using the slash command `/quality-checks` and select Enter.
-3. Following the skill, the agent runs the unit tests, the linter, and the end-to-end tests, and reports the results. If anything fails, ask it to fix the issue and run the checks again until everything is green.
-4. **Keep this session open.** In the next lesson you'll add the Playwright MCP server and use it to see the filtering feature working in a real browser.
-
-## Summary and next steps
-
-You built a real feature end to end and verified it against the team's bar! Specifically, you:
-
-- started a fresh session from the filtering issue on an up-to-date project.
-- used Plan mode to plan the feature and Autopilot to build it.
-- confirmed the generated helper followed the documentation standard you merged in Lesson 3.
-- verified your work with the `quality-checks` skill.
-
-Next, you'll connect the Playwright MCP server and ask the agent to explore your filtering feature in a real browser. Continue to [Lesson 5 - Testing with the Playwright MCP server][next-lesson].
+This checkpoint is part of PR 3, not a separate PR. Stay in **Interactive** mode in the same session for [Lesson 5 - Create and use a quality-checks skill][next-lesson].
## Resources
- [Working with agent sessions in the GitHub Copilot app][agent-sessions]
-- [About Agent Skills][about-agent-skills]
-- [Customizing the GitHub Copilot app][customize-app]
- [About cloud and local sandboxes for GitHub Copilot][sandboxes]
-[ex0]: ../0-prerequisites/
-[ex2]: ../2-add-star-rating/
-[ex3]: ../3-custom-instructions/
-[next-lesson]: ../5-mcp-playwright/
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
diff --git a/docs/app/5-agent-skills.md b/docs/app/5-agent-skills.md
new file mode 100644
index 00000000..d500802a
--- /dev/null
+++ b/docs/app/5-agent-skills.md
@@ -0,0 +1,93 @@
+---
+title: "Lesson 5 - Create and use a quality-checks skill"
+description: "Ask Copilot to create reusable shell-bundled quality checks, inspect the skill, and execute it on the filtering branch."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Your filtering feature is implemented and checked with the existing npm commands. Now you'll package those checks as a reusable **agent skill**. Stay in the same filtering session and branch through Lessons 4–8; this lesson does not create a pull request.
+
+In this lesson, you will:
+
+- return to **Interactive** mode before creating customizations.
+- ask Copilot to create and then stop for inspection of `quality-checks`.
+- execute all four checks through its bundled scripts and prove a single-file test argument selects only that file.
+- checkpoint the skill alongside the filtering feature.
+
+## Instructions, scripts, and resources
+
+Skills package reusable task instructions, executable scripts, and supporting resources that an agent loads on demand. Custom agents define specialist roles, instructions, and available tools. These are complementary: a custom agent can execute scripts, including those bundled with a skill.
+
+A repository skill lives in `.github/skills//SKILL.md`, with `name` and `description` frontmatter and Markdown instructions. Scripts and other resources live beside it. You'll ask Copilot to generate `.github/skills/quality-checks/SKILL.md` and its bundled scripts, rather than copy a prebuilt answer. The [Agent Skills specification][skill-spec] describes the format.
+
+Copilot uses a discovered skill's description to decide when to load it. Don't assume a new skill is immediately discovered in an already open session; the run section includes an explicit-read fallback. A portable format does not remove shell or project prerequisites.
+
+## Create the skill
+
+Switch the filtering session back to **Interactive** mode using the mode selector before sending the prompt. Keep the current checkout and branch. If you started with an older template that already has this skill, inspect and extend it rather than overwrite your customizations.
+
+```plaintext
+Create .github/skills/quality-checks/SKILL.md and four scripts wrapping npm run lint, npm run test:unit, npm run test:e2e, and npm run typecheck:all. Read package.json, README, test configuration, and repository instructions first.
+
+Detect this environment. Create ONLY Bash .sh scripts for macOS/Linux/WSL OR PowerShell .ps1 scripts for native Windows; ask if uncertain. Do not create both. Keep wrappers limited to resolving the repository root from their own location, verifying this project's package.json there, and invoking npm. Fail clearly for an invalid root. Support any working directory and paths with spaces. Preserve output and failure exit codes, including PowerShell native failures. Insert npm's -- exactly once; callers supply tool arguments directly without another --. No port or process management.
+
+Give SKILL.md name/description frontmatter, instructions to run all four wrappers, prerequisites, troubleshooting, and portable examples including one existing unit-test file. Every Bash example must invoke bash explicitly; never bypass PowerShell execution policy. Explain Playwright server reuse: stop only servers you actually started; otherwise ask.
+
+Only create the skill and necessary scripts. Do not run checks or probes, install anything, change application code, commit, or open a PR. Stop for inspection.
+```
+
+## Inspect the skill
+
+1. Open **Changes** to review the generated files. You can also use the review panel's **+**, **File**, then search for `SKILL.md` or the script filenames.
+2. Check that `name` and `description` describe the skill and when it applies. Read the instructions, not just the metadata.
+3. Confirm the execution sequence actually invokes bundled scripts under `.github/skills/quality-checks/` for lint, unit tests, E2E, and type checking.
+4. Inspect each wrapper for script-relative root resolution and an explicit check that the derived directory contains this checkout's intended `package.json`. A command that succeeds because npm searches ancestor directories does not prove the root is correct. Check quoted paths, argument forwarding, visible output, and failure exits; PowerShell must propagate native npm failures.
+5. Check the documented single-unit-test-file example. The wrapper inserts npm's `--` separator, so callers pass target-tool arguments directly without another separator. Keep reusable instructions free of machine-specific absolute checkout paths. Ask Copilot to correct gaps before running anything.
+6. Keep the scripts limited to root/manifest validation and running the existing npm checks. Port and process decisions belong in SKILL.md, not shell process-management code. Confirm that only servers actually started by the agent may be stopped; a matching working directory or process name does not establish ownership. The delivered files should contain only the skill, required wrappers, and any needed shared helper, without temporary probe or debug files.
+
+> [!NOTE]
+> Current Tailspin Toys requires Node.js 22.13 or later, project dependencies, and Playwright Chromium for E2E checks. Confirm prerequisites in your checkout's README and `package.json`. Missing prerequisites or a blocked PowerShell execution policy need an approved resolution, not an automatic installation, policy bypass, or silent switch to direct npm.
+
+## Run the skill
+
+Confirm the development server from the previous lesson has stopped. Playwright builds and serves a preview for E2E, but its local configuration can reuse a server on port `4321`. A server from another checkout is not valid evidence for your feature.
+
+If the app offers `/quality-checks`, select it to explicitly invoke the discovered skill and include the request below. If it is not discovered, send the same request directly in this session; reading the skill is a supported fallback for this exercise.
+
+```plaintext
+Read .github/skills/quality-checks/SKILL.md and follow its instructions to validate the filtering feature in this checkout. First inspect each wrapper's code to verify that it derives the directory containing this checkout's intended package.json and explicitly fails for an invalid root, rather than relying on npm's ancestor-package discovery. Do not move, rename, delete, or modify repository files to simulate failures. Actually run its bundled scripts for lint, unit tests, end-to-end tests, and type checks. Also run the documented single-unit-test-file example, passing target-tool arguments directly because the wrapper owns npm's -- separator. Verify from the test runner's results that ONLY the named file ran, and report that filename and the executed test-file count. Echoing arguments or returning exit code 0 alone is not proof of correct selection.
+
+Report each script invocation and result, including failures, skipped checks, or missing prerequisites. Do not silently substitute direct npm commands for an unusable skill script. Identify the checkout and server under test, stop only servers you started, and ask before installing anything or stopping another process. Do not change application code, change branches, commit, push, or open a pull request.
+```
+
+Inspect the tool calls and output. All four scripts must actually execute; a description of the checks or a skipped check is not a pass. For the single-file example, compare the requested filename with the runner's actual file results and reported count: only that file should run. Echoed arguments or exit code 0 are insufficient if other files also ran. A failure is useful evidence: correct the skill or resolve the setup blocker with approval, then rerun the affected checks. Don't stop unrelated processes or force a port conflict away.
+
+## Save a checkpoint
+
+Once you have reviewed the skill and its results, authorize a local checkpoint:
+
+```plaintext
+Review the current diff and create a checkpoint commit for the quality-checks skill files only. Keep the existing filtering branch. Do not push or create a pull request.
+```
+
+The skill files will accompany filtering, the QA profile, and associated tests in the feature PR in Lesson 8. Continue in this same session to [Lesson 6 - Validate functionality with Playwright MCP][next-lesson].
+
+## More skill examples
+
+These community examples are references, not additional tasks. Review their prerequisites and behavior before adopting them:
+
+- [Contribution workflow: `make-repo-contribution`][contribution-example].
+- [Requirements documents: `prd`][prd-example].
+- [Diagrams and a bundled export script: `drawio`][drawio-example].
+- [Browser testing: `webapp-testing`][browser-example].
+
+The upstream contribution example is named `make-repo-contribution`; older Tailspin templates used a different name, `make-contribution`. This workshop does not depend on either contribution skill.
+
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/app/5-mcp-playwright.md b/docs/app/5-mcp-playwright.md
deleted file mode 100644
index 202d83bd..00000000
--- a/docs/app/5-mcp-playwright.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: "Lesson 5 - Testing with the Playwright MCP server"
-description: "Add the Playwright MCP server to the GitHub Copilot app and ask the agent to manually test your filtering feature in a real browser."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-In the previous lesson you created and verified the filtering feature with the project's automated test suite. Tests automate validation of code, but allowing the agent to confirm behavior is powerful. It allows an agent to respond to issues it sees in the actual UI it's creating. Let's explore how MCP allows access to external capabilities to AI agents, and add the Playwright MCP server to allow Copilot to interact with the site you're building directly.
-
-In this lesson, you will:
-
-- understand what Model Context Protocol (MCP) is and how the GitHub Copilot app uses it.
-- add the Playwright MCP server from the app settings.
-- ask the agent to drive a browser and explore your filtering feature.
-
-## Scenario
-
-While unit and end-to-end tests are important, validating updates to the UI requires actually interacting with the UI. You want to allow Copilot to use the website you're working on as a user would to further automate how changes are made, providing more confidence the updates perform as expected.
-
-## What is Model Context Protocol (MCP)?
-
-[Model Context Protocol (MCP)][mcp-blog-post] provides AI agents with a way to communicate with external tools and services. By using MCP, AI agents can communicate with external tools and services in real-time. This allows them to access up-to-date information (using resources) and perform actions on your behalf (using tools).
-
-These tools and resources are accessed through an MCP server, which acts as a bridge between the AI agent and the external tools and services. The MCP server is responsible for managing the communication between the AI agent and the external tools (such as existing APIs or local tools like NPM packages). Each MCP server represents a different set of tools and resources that the AI agent can access.
-
-A couple of popular existing MCP servers are:
-
-- **[GitHub MCP Server](https://github.com/github/github-mcp-server)**: This server provides access to a set of APIs for managing your GitHub repositories. It allows the AI agent to perform actions such as creating new repositories, updating existing ones, and managing issues and pull requests.
-- **[Playwright MCP Server][playwright-mcp-server]**: This server provides browser automation capabilities using Playwright. It allows the AI agent to perform actions such as navigating to web pages, filling out forms, and clicking buttons.
-
-There are many other MCP servers available that provide access to different tools and resources. GitHub hosts an [MCP registry](https://github.com/mcp) to enhance discoverability and contributions to the ecosystem.
-
-> [!CAUTION]
-> Treat MCP servers as you would any other dependency in your project. Before using an MCP server, carefully review its source code, verify the publisher, and consider the security implications. Only use MCP servers that you trust and be cautious about granting access to sensitive resources or operations.
-
-## Add the Playwright MCP server
-
-You add and manage MCP servers from the app settings. The app includes a catalog of popular servers, so the [Playwright MCP server][playwright-mcp-server] is just a couple of clicks away.
-
-1. Select Ctrl+, to open the Copilot app settings page.
-2. Select **MCP servers**.
-3. In the search dialog, type `Playwright`.
-4. Select **Playwright** from the list of **Popular MCP servers**.
-5. Select **Add server** to add it to the list of available MCP servers.
-6. Select Esc to close the settings dialog.
-
-You've now added the Playwright MCP server!
-
-## Ask Copilot to explore the feature via Playwright
-
-Let's ask Copilot to test the feature manually by using the Playwright MCP server.
-
-1. Use the following prompt to ask Copilot to validate the new functionality:
-
- ```plaintext
- Start the dev server then use the Playwright MCP server to validate the functionality you just added exists. Use the details in the issue to ensure the newly added behavior matches the specs.
- ```
-
-Copilot will launch a browser through the Playwright MCP server, walk through each step, and report back what it found. You'll actually see it open a browser on your system to perform the tasks!
-
-2. Read its summary against the acceptance criteria in the issue. If something looks off, ask follow-up questions or send it back to fix the code before you open a pull request.
-3. Leave this session open as we're going to close it out in the next lesson!
-
-Copilot has now also validated the functionality in the browser by exploring the feature like a user would.
-
-## Summary and next steps
-
-Congratulations, you used the Playwright MCP server to explore your feature in a real browser from the GitHub Copilot app! To recap, you:
-
-- learned what Model Context Protocol (MCP) is and how the app makes MCP tools available.
-- added the Playwright MCP server from the app settings.
-- asked the agent to drive a browser and explore your filtering feature.
-
-Your feature is built, verified, and seen working. Now it's time to ship it — using **Agent Merge** to open and merge the pull request for you. Continue to [Lesson 6 - Merging with Agent Merge][next-lesson].
-
-## Resources
-
-- [What the heck is MCP and why is everyone talking about it?][mcp-blog-post]
-- [Microsoft Playwright MCP Server][playwright-mcp-server]
-- [Configuring MCP servers in the GitHub Copilot app][customize-app]
-
-[next-lesson]: ../6-agent-merge/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/app/6-agent-merge.md b/docs/app/6-agent-merge.md
deleted file mode 100644
index 55aff8bb..00000000
--- a/docs/app/6-agent-merge.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: "Lesson 6 - Merging with Agent Merge"
-description: "Open the filtering pull request, review it in My work, and let Agent Merge fix what's blocking it and merge it for you — the top rung of the merge-automation ladder."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-Your filtering feature is built, verified, and seen working in a browser. The last step is to merge it. You've merged twice already in this harness — both times you opened the pull request and merged it yourself on github.com. This time you'll let the app do the heavy lifting with **Agent Merge**, which shepherds a pull request through its whole lifecycle from inside the app.
-
-In this lesson, you will:
-
-- learn what Agent Merge is and how it automates the merge lifecycle.
-- enable Agent Merge on your filtering session.
-- watch it create the pull request, run CI, and merge when everything is green.
-
-## Scenario
-
-Over the last few modules you've explored various levels of automation, from creating code to allowing Copilot to validate a UI directly. To further speed development, Tailspin Toys would like to see if there's a way pull requests that have been vetted and validated can automatically be merged.
-
-## Introducing Agent Merge
-
-**Agent Merge** allows automation of the last mile of landing a pull request via Copilot app. When you enable it, the app's session reads your pull request, addresses what's blocking it — fixing failing CI checks, responding to review comments, rebasing when needed — and merges it as soon as GitHub allows. It runs in the background, survives app restarts, and turns itself off once your pull request is merged.
-
-Up to this point you've been the one clicking **Merge pull request** on github.com. Agent Merge shifts that responsibility to the agent so you can move on to the next task while it shepherds the PR through to completion. You still review and approve the work — the agent just handles the mechanical finish line.
-
-## Use Agent Merge to manage the PR
-
-You've reviewed the code manually, run tests, and even allowed Copilot to validate the UI. Now it's time to merge the new code into the codebase! Let's allow agent merge to shepherd the PR through continuous integration (CI) and to merge.
-
-1. Return to the session you had open from the previous module where you were adding filtering functionality.
-2. In the upper right-hand corner, select the dropdown next to **Create PR**.
-3. Select **Agent merge** to enable agent merge.
-
- 
-
-4. The button text now changes to **Agent merge**.
-5. Select the **Agent merge** button to start the agent merge process.
-
-Copilot app then begins the process of creating and managing the PR! It starts by exploring the project to determine how best to create a PR, followed by creating the new PR.
-
-After a few moments, you'll notice Copilot starts work again, looking at the PR conditions - the CI process of running all the tests on your repository. It will report back status on any reviews left by other team members, any checks that need to run (the CI process), and if the PR is mergeable.
-
-6. Allow agent merge to merge the pull request by selecting the dropdown next to **Agent merge** then **Merge pull request**.
-
- 
-
-7. Once all CI processes are green (meaning the tests passed), Copilot will merge the pull request!
-
-## Summary and next steps
-
-You've automated several parts of the development process, including generating code, testing and validating code, and now the pull request process. You:
-
-- learned what Agent Merge is and how it automates the merge lifecycle.
-- enabled Agent Merge on your filtering session.
-- watched it create the pull request, run CI, and merge when everything was green.
-
-Next, you'll explore **canvases** — a richer way to plan and visualize work with the agent. Continue to [Lesson 7 - Planning with canvases][next-lesson].
-
-## Resources
-
-- [Managing issues and pull requests with the GitHub Copilot app][managing-issues-prs]
-- [About the GitHub Copilot app][about-copilot-app]
-
-[next-lesson]: ../7-canvases/
-[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
diff --git a/docs/app/6-mcp-playwright.md b/docs/app/6-mcp-playwright.md
new file mode 100644
index 00000000..df028912
--- /dev/null
+++ b/docs/app/6-mcp-playwright.md
@@ -0,0 +1,90 @@
+---
+title: "Lesson 6 - Validate functionality with Playwright MCP"
+description: "Configure Playwright MCP through Customize and observe filtering in a browser in the existing feature worktree."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+In the previous lesson you packaged and ran the project's checks through your quality-checks skill. Now give the agent access to a browser so it can observe the filtering UI directly. Stay in the same filtering session, worktree, and branch. This lesson adds browser evidence, not another feature, full test-suite run, or PR.
+
+In this lesson, you will:
+
+- understand what Model Context Protocol (MCP) is and how the GitHub Copilot app uses it.
+- add the Playwright MCP server through **Customize**.
+- ask the agent to drive a browser and explore your filtering feature.
+
+## Scenario
+
+While unit and end-to-end tests are important, validating updates to the UI requires actually interacting with the UI. You want to allow Copilot to use the website you're working on as a user would to further automate how changes are made, providing more confidence the updates perform as expected.
+
+## What is Model Context Protocol (MCP)?
+
+[Model Context Protocol (MCP)][mcp-blog-post] provides AI agents with a way to communicate with external tools and services. By using MCP, AI agents can communicate with external tools and services in real-time. This allows them to access up-to-date information (using resources) and perform actions on your behalf (using tools).
+
+These tools and resources are accessed through an MCP server, which acts as a bridge between the AI agent and the external tools and services. The MCP server is responsible for managing the communication between the AI agent and the external tools (such as existing APIs or local tools like NPM packages). Each MCP server represents a different set of tools and resources that the AI agent can access.
+
+A couple of popular existing MCP servers are:
+
+- **[GitHub MCP Server](https://github.com/github/github-mcp-server)**: This server provides access to a set of APIs for managing your GitHub repositories. It allows the AI agent to perform actions such as creating new repositories, updating existing ones, and managing issues and pull requests.
+- **[Playwright MCP Server][playwright-mcp-server]**: This server provides browser automation capabilities using Playwright. It allows the AI agent to perform actions such as navigating to web pages, filling out forms, and clicking buttons.
+
+There are many other MCP servers available that provide access to different tools and resources. GitHub hosts an [MCP registry](https://github.com/mcp) to enhance discoverability and contributions to the ecosystem.
+
+> [!CAUTION]
+> Treat MCP servers as you would any other dependency in your project. Before using an MCP server, carefully review its source code, verify the publisher, and consider the security implications. Only use MCP servers that you trust and be cautious about granting access to sensitive resources or operations.
+
+## Add the Playwright MCP server
+
+The current [App customization documentation][customize-app] uses **Customize** in the sidebar for MCP discovery and management. MCP servers configured for your repositories or Copilot CLI can already be available in the App; inspect installed servers before adding a duplicate.
+
+1. Select **Customize** in the sidebar.
+2. Select **MCP**, then check **Installed** for an existing Playwright server.
+3. If needed, find **Playwright** among the available servers, or use the custom-server flow documented by the publisher.
+4. Review the publisher, configuration, and any installation prompts before approving them. Follow the prompts to add the server; organization policy or missing prerequisites can block setup.
+5. Return to the existing filtering session, keeping **Interactive** mode. Confirm Playwright MCP browser tools are available before asking for validation. Do not create a new feature worktree as a setup workaround.
+
+If setup fails, resolve the configuration or permission issue rather than accepting a claim that the agent browsed without tools. Browser visibility depends on the server configuration; actual tool activity and observations are the evidence.
+
+## Ask Copilot to explore the feature via Playwright
+
+Use the actual issue URL and approved clarifications saved in Lesson 4. Stop any manual dev server from earlier lessons before the agent starts its own. It must identify the checkout and server it is testing.
+
+1. Use the following prompt to ask Copilot to validate the new functionality:
+
+ ```plaintext
+ Use the configured Playwright MCP server to observe the filtering feature against this issue: . These are my approved planning clarifications: . Stay in this filtering worktree and branch.
+
+ Identify the checkout, start its dev server, and use actual browser tools to exercise the required multiple-category selection, publisher filtering, combined filtering, accessible controls, and any agreed clearing or empty-result behavior. Report observations against the criteria, including failures or blocked checks. Do not claim behavior you did not observe.
+
+ This step is browser observation, not another full automated test run. Do not change application code, tests, skills, or agent profiles, commit, push, or create a PR. Report missing MCP tools or prerequisites as blocked and ask before installing anything. Do not reuse another checkout's server or stop unrelated processes. Stop only the server you started when finished.
+ ```
+
+Inspect the Playwright MCP tool calls, the URL under test, and the reported browser observations. A narrative based only on source code or earlier E2E results does not demonstrate MCP.
+
+2. Read the summary against the issue and approved clarifications. If there is a defect, authorize a focused fix separately, review the changed diff, and repeat relevant automated checks and browser observations. Evidence from before the fix is not proof of the resulting revision.
+3. Confirm the agent stopped its own server. Keep this filtering session open and remain in **Interactive** mode before creating the QA profile in Lesson 7.
+
+This stage establishes direct observation, not a replacement for automated coverage. A failure or blocked observation remains visible for QA.
+
+## Summary and next steps
+
+Congratulations, you used the Playwright MCP server to explore your feature in a real browser from the GitHub Copilot app! To recap, you:
+
+- learned what Model Context Protocol (MCP) is and how the app makes MCP tools available.
+- configured the Playwright MCP server through **Customize**.
+- asked the agent to drive a browser and explore your filtering feature.
+
+Next, bring the requirements, browser observations, coverage, and skill together with a specialist profile. Continue in this same session to [Lesson 7 - Create and use a QA agent][next-lesson]. Do not create the feature PR yet.
+
+## Resources
+
+- [What the heck is MCP and why is everyone talking about it?][mcp-blog-post]
+- [Microsoft Playwright MCP Server][playwright-mcp-server]
+- [Configuring MCP servers in the GitHub Copilot app][customize-app]
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
+[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/app/7-canvases.md b/docs/app/7-canvases.md
deleted file mode 100644
index 223552db..00000000
--- a/docs/app/7-canvases.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: "Lesson 7 - Planning with canvases"
-description: "Create a shared, agent-driven canvas in the GitHub Copilot app to plan and track your work alongside the agent."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-So far you've directed agents through chat. But a lot of work doesn't live in a conversation — it lives on a board, in a document, or on a checklist. **Canvases** give you and the agent a shared surface for exactly that kind of work, right inside the app. In this lesson you'll create a simple canvas to plan and track the backlog you've been working through.
-
-In this lesson, you will:
-
-- understand what a canvas is and when to use one.
-- create a shared Kanban board canvas to triage your backlog.
-- save the canvas to your repository and merge it for the team.
-- open the canvas in a new session and start work from it.
-
-## Scenario
-
-Looking at a list of issues can be rather daunting, even in the best of times. Tailspin Toys' developers have been looking for a tool that would allow them to quickly triage issues, and begin work on them in Copilot app.
-
-## What is a canvas?
-
-A [canvas][canvas-docs] is a shared, interactive surface for a work artifact — a plan, a triage board, a release checklist, a dashboard, or a document. While chat is great for describing intent and reasoning through ambiguity, most work happens on a *surface*. Canvases let you collaborate with the agent directly on that surface.
-
-Canvases are **bidirectional**: the agent can update the canvas while it works, and you can edit the same surface yourself. When you create a canvas, the agent builds it based on your prompt and workflow, and you can ask it to add, remove, or revise capabilities as you go. Once created, a canvas opens in the app's right side panel.
-
-Some common examples include:
-
-- **Markdown canvases** for planning your day and prioritizing issues and pull requests.
-- **Agentic kanban boards** where people and agents add cards and move work across columns.
-- **Issue triage boards** that summarize top issues and recurring themes for a repository.
-
-## Why use a canvas?
-
-Reach for a canvas when a task needs structure, iteration, and verification, and a chat alone isn't enough. A canvas lets you:
-
-- ground the agent's work in an actual artifact that fits your workflow.
-- steer or correct work directly on the shared surface, then let the agent continue from your changes.
-- inspect progress as visible changes to an artifact, not just chat responses.
-
-## Create a canvas to track your work
-
-You've shipped a lot: the star rating, the documentation standard, and the filtering feature are all merged. But there's still items on the backlog. Let's create the canvas to help quickly triage the work.
-
-1. Return to (or open) the GitHub Copilot app.
-2. Select the **Home screen**.
-3. Ensure `tailspin-toys` is selected for the repo.
-4. In the prompt box, use the following prompt to create our canvas that meets our needs:
-
- ```plaintext
- Create a basic Kanban board canvas that allows me to quickly triage work. Highlight the three issues which are most likely to need attention right now, with the remainder in a second section down below. The top three cards should include a description of the issue's content and a justification of why they're at the top of the list. Each issue should have a button that allows me to add it to the current context for the current session so I can get to work on it straightaway.
- ```
-
-Copilot will get to work on creating the canvas!
-
-> [!NOTE]
-> This will take a few minutes for it to do so. Because this is a complicated task, you might not be satisfied with the first version. You can continue to prompt to build the tool of your dreams!
-
-## Save the canvas and merge it to the repository
-
-Canvases can become assets in the repository, just like instructions files and skills. Let's ask Copilot to add it to our repository and merge it so the whole team can use it.
-
-1. In the same session, ask Copilot to save the canvas to the repository by using the following prompt:
-
- ```plaintext
- Let's save this canvas definition to the repository so I can share it with my development team
- ```
-
-2. Once Copilot has saved the canvas files, select the dropdown next to **Create PR** in the upper right-hand corner.
-3. Select **Agent merge** to enable agent merge.
-
- 
-
-4. The button text now changes to **Agent merge**.
-5. Select the **Agent merge** button to start the agent merge process.
-
-Copilot app begins the process of creating and managing the PR. It starts by exploring the project to determine how best to create a PR, then creates it.
-
-After a few moments, you'll notice Copilot starts work again, looking at the PR conditions — the CI process of running all the tests on your repository. It will report back status on any reviews left by other team members, any checks that need to run (the CI process), and if the PR is mergeable.
-
-6. Allow agent merge to merge the pull request by selecting the dropdown next to **Agent merge** then **Merge pull request**.
-
- 
-
-7. Wait for all CI processes to pass (go green). Once they do, Copilot will merge the pull request automatically!
-
-You've now created a new shared canvas for your team!
-
-## Work in the canvas
-
-With the canvas created, let's start a new session and put it to work!
-
-1. Inside the Copilot app, start a new session by selecting **New session** next to **tailspin-toys**.
-2. Ask Copilot to open the triage canvas by using the following prompt:
-
- ```plaintext
- Open the triage issues canvas
- ```
-
-3. You should notice the canvas you built is now open in this new session!
-4. Select **Add to current context** on one of the issues that's of most interest to you.
-5. Copilot gets to work on the issue!
-
-You've now used a canvas you created to streamline the development process.
-
-## Summary and next steps
-
-You created a shared surface where you and the agent can collaborate! You:
-
-- learned what canvases are and when to use them.
-- created a shared Kanban triage board canvas with the agent.
-- saved and merged the canvas to your repository with Agent Merge.
-- opened the canvas in a new session and used it to start work.
-
-With your backlog tracked, take a step back to review everything you've built and where to go next. Continue to [Lesson 8 - Review and next steps][next-lesson].
-
-## Resources
-
-- [Working with canvas extensions in the GitHub Copilot app][canvas-docs]
-- [Canvases on Awesome Copilot][awesome-copilot-canvases]
-- [About the GitHub Copilot app][about-copilot-app]
-
-[next-lesson]: ../8-review/
-[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
-[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
diff --git a/docs/app/7-qa-agent.md b/docs/app/7-qa-agent.md
new file mode 100644
index 00000000..5c397f89
--- /dev/null
+++ b/docs/app/7-qa-agent.md
@@ -0,0 +1,73 @@
+---
+title: "Lesson 7 - Create and use a QA agent"
+description: "Create a requirements-first QA profile that combines test coverage, the quality-checks skill, and direct browser evidence."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+You've run repeatable checks and explored filtering through Playwright MCP. Now create a **QA custom agent** to bring the requirements, coverage, and browser evidence together. Keep the filtering session, checkout, and branch; the feature PR comes in Lesson 8.
+
+## Create the QA profile
+
+Stay in **Interactive** mode. A profile defines a specialist's role and instructions; a skill packages reusable task instructions, scripts, and resources. The QA agent will use your skill and configured MCP tools rather than replace them.
+
+Send this prompt, then inspect the definition before running it:
+
+```plaintext
+Create a reusable QA custom agent in .github/agents/qa.agent.md. First inspect the repository instructions, package.json, test configuration, and .github/skills/quality-checks/SKILL.md. Give the profile valid YAML frontmatter with the name QA and a description explaining when to use it. Do not pin a model or add a tools list; inherit the harness's available tools and permissions. Create only the agent definition, then stop so I can inspect it before running it.
+
+In the agent's instructions, require every QA task to start from the issue and any approved acceptance criteria supplied by the user. Treat these requirements as the source of truth, not the implementation. Ask when requirements are missing or ambiguous. Inspect the feature and existing tests, and map each criterion to suitable automated coverage and observable behavior.
+
+Require direct browser validation through the configured Playwright MCP server and execution of lint, unit tests, end-to-end tests, and type checks through the existing quality-checks skill and its bundled scripts. Read the skill explicitly if it has not been automatically discovered. Report missing skills, MCP tools, prerequisites, or access as blocked; do not silently substitute another workflow or label skipped checks as passes. Identify the checkout and server under test, avoid reusing another worktree's server, stop only servers the agent started, and ask before any installation or stopping another process.
+
+Allow the QA agent to add the smallest necessary tests for genuine coverage gaps, following repository instructions; no additional tests is valid when coverage is already adequate. Do not weaken assertions, disable failing tests, change acceptance criteria to match the code, or modify application code without my approval. After changes, rerun affected checks and complete final verification of the resulting revision. Require a concise report mapping criteria to evidence and pass/fail/blocked status, listing tests added or explaining why none were needed, reporting all four check results, and identifying unresolved defects. GO requires all required checks and evidence; otherwise report NO-GO with the reason. Do not change branches, commit, push, open or merge PRs, or create additional agents or skills during QA.
+```
+
+## Inspect the profile
+
+Open `.github/agents/qa.agent.md` in **Changes** or the file review panel. `description` is required; this lesson also supplies the readable `name` of `QA`. Confirm there is no pinned `model` or invented tool list. Omitting `tools` inherits available tools; it does not bypass harness permissions. Production profiles can restrict tools deliberately.
+
+Confirm the instructions start with requirements, require actual MCP browser activity and skill scripts, allow only justified test additions, and report blockers truthfully. Neither a specialist profile nor a skill requires a separate context window or orchestration of other agents.
+
+## Run QA against the issue
+
+The run prompt is for the selected **QA** custom agent, not the default agent reading a profile. Keep the same filtering checkout and branch.
+
+1. In the current session, open the agent picker in the prompt box, or enter `/agent`, as described in the [app customization documentation][customize-app].
+2. Select **QA** and verify that the app visibly identifies **QA** as the active agent before sending the run prompt.
+3. If **QA** is not listed or you cannot confirm it is active, pause and ask your facilitator while retaining this worktree and branch. Do not create a new feature session, invent a reload sequence, or substitute a request for the default agent to read `qa.agent.md`.
+
+The documented picker is available during a session, but discovery of a newly created repository profile can depend on your app version. Do not treat writing the file as proof of activation.
+
+Replace both placeholders with the actual filtering issue URL and the clarifications approved in Lesson 4, or `none` when the issue is complete. Do not rely on the previous agent's memory.
+
+```plaintext
+Verify the filtering feature against this issue: . These are the additional acceptance criteria I approved during planning: .
+
+Validate behavior with the Playwright MCP server, inspect test coverage, add tests only for missing coverage, and run validation through the quality-checks skill. Report evidence, check results, and blockers. Do not change application code without my approval, create a commit, or open a pull request.
+```
+
+## Review the evidence
+
+Check the report against the issue: each criterion needs appropriate automated coverage and observable behavior. Inspect actual Playwright MCP tool activity, the checkout/server identity, and all four skill-script results. Browser checks and automated E2E must not reuse a stale server or another checkout.
+
+Review any added tests: they should close genuine gaps without weakening assertions. No new tests is correct when coverage is adequate. A blocked or failed **NO-GO** verdict is a valid outcome, not permission to skip evidence.
+
+If QA identifies an application defect, approve a focused fix separately and rerun affected checks and browser observations on the resulting revision. Missing prerequisites or tools need an explicit resolution. Do not treat older evidence as proof of changed code.
+
+## Save a checkpoint
+
+When QA has finished, keep its report, the issue URL, approved clarifications, and tested revision available. In the same session, use the documented agent picker to return to the ordinary Copilot agent and confirm **QA** is no longer selected. Keep the same checkout and branch; do not start another feature session or reload the worktree. If you cannot find the ordinary-agent choice, pause and ask your facilitator rather than issuing commit instructions to QA.
+
+When you have reviewed the profile, any test changes, and the resulting evidence, send the checkpoint request to the ordinary agent with that QA context:
+
+```plaintext
+Review the current diff and create a checkpoint commit for the QA agent definition and any approved test changes. Stay on the existing filtering branch. Do not push or open a pull request.
+```
+
+Continue to [Lesson 8 - Create and merge the feature PR][next-lesson] with the filtering feature, skill, QA profile, tests, and current verification evidence.
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/app/8-create-pull-request.md b/docs/app/8-create-pull-request.md
new file mode 100644
index 00000000..e9c24660
--- /dev/null
+++ b/docs/app/8-create-pull-request.md
@@ -0,0 +1,89 @@
+---
+title: "Lesson 8 - Create and merge the feature PR"
+description: "Review filtering, the skill, QA profile, and tests together, create PR 3, and explicitly authorize Agent Merge."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Your filtering implementation, quality-checks skill, QA profile, and associated tests are checkpointed on one branch. Review them together and use the current QA evidence to prepare PR 3. You have already explicitly merged the star-rating and instructions PRs. This time you'll use **Agent Merge** within the PR workflow, not as a separate feature or branch.
+
+In this lesson, you will:
+
+- learn what Agent Merge is and how it automates the merge lifecycle.
+- inspect the full feature PR and verification evidence.
+- authorize Agent Merge only after review, and confirm the PR is merged.
+
+## Scenario
+
+Over the last few modules you've explored various levels of automation, from creating code to allowing Copilot to validate a UI directly. To further speed development, Tailspin Toys would like to see if there's a way pull requests that have been vetted and validated can automatically be merged.
+
+## Introducing Agent Merge
+
+**Agent Merge** allows automation of the last mile of landing a pull request via Copilot app. When you enable it, the app's session reads your pull request, addresses what's blocking it — fixing failing CI checks, responding to review comments, rebasing when needed — and merges it as soon as GitHub allows. It runs in the background, survives app restarts, and turns itself off once your pull request is merged.
+
+Up to this point you've selected **Merge pull request** yourself. Agent Merge can take on that responsibility, but its ability to edit code and merge still needs your explicit authorization. Review its allowed actions and the work before granting merge permission.
+
+## Review the complete milestone
+
+Stay in the filtering session from Lessons 4–7. Check the full branch diff against `main`, not just the latest checkpoint: it should contain filtering, `.github/skills/quality-checks/SKILL.md`, the bundled scripts, `.github/agents/qa.agent.md`, and the associated tests.
+
+Use the agent picker to return from **QA** to the general Copilot agent before requesting commits or PR actions, and keep **Interactive** mode. The QA profile's job was verification, not shipping. Changing the selected agent must not change the filtering session, checkout, or branch.
+
+This workshop deliberately combines feature work and reusable quality infrastructure in one PR. A production team might split those concerns; here, checkpoint commits preserve reviewable steps without stacked branches or extra PRs.
+
+Review Lesson 7's QA report. Reuse its evidence only if it covers the final revision being submitted, with all four checks and the relevant browser observations completed. If code changes, conflicts, or CI fixes alter what was tested, rerun affected checks and browser observations and update the evidence. A failed or blocked **NO-GO** report is not merge approval.
+
+Once the diff and evidence are ready, send:
+
+```plaintext
+Review the full filtering branch diff against main, including the filtering feature, quality-checks skill and scripts, QA agent definition, and associated tests. Summarize the issue criteria, approved clarifications, and current QA evidence. Reuse verification only if it still applies to the final revision; report stale, missing, or failing evidence before proceeding.
+
+If the reviewed changes and verification are ready, commit any remaining approved milestone changes, push this branch, and create one feature PR targeting main using the repository's PR template and the actual filtering issue URL. Keep the checkpoint history on this branch. Do not use a contribution skill, create another branch or PR, or merge yet.
+```
+
+Open the PR in **My work** and inspect **Files changed**, its description, reviews, and check results. Inspect Tailspin Toys' own workflow files and required checks; do not assume every local check or browser observation runs in CI. The workshop publisher's Astro build and link checker belong to another repository and do not validate this feature.
+
+## Use Agent Merge to manage the PR
+
+After reviewing the existing PR, configure Agent Merge in this same session. Do not create a second PR.
+
+1. Return to the filtering session and confirm it is linked to PR 3.
+2. Open the PR action dropdown in the upper right-hand corner. Before a PR exists, it is next to **Create PR**; the label can change once a PR is linked.
+3. Select **Agent merge** to enable agent merge.
+4. Review the available permissions, including **Address reviews**, **Fix CI failures**, **Resolve conflicts**, and **Merge pull request**. Leave merge permission off while findings or verification are unresolved.
+5. Before starting it, send the following scope and authorization, then select **Agent merge**:
+
+ ```plaintext
+ Manage this existing filtering PR with Agent Merge. Address review or CI blockers only within this PR's scope. Do not weaken tests or requirements, and ask before unrelated changes or installations. Any change to the tested revision requires updated relevant checks and browser evidence; do not treat older QA results as proof of changed code.
+
+ Do not merge until I explicitly enable Merge pull request after reviewing the final diff and evidence. Do not create another PR or begin the canvas task.
+ ```
+
+6. Review any follow-up changes and updated results. When the final diff is approved, required CI and reviews pass, and QA evidence applies to that revision, explicitly authorize merging by selecting the dropdown next to **Agent merge**, then **Merge pull request**.
+
+ 
+
+7. Confirm GitHub shows PR 3 as **Merged**, not merely mergeable or queued. Agent Merge does not bypass repository protections or missing permissions; resolve those blockers before continuing.
+
+Only after that merge should you start the canvas milestone. Lesson 9 creates a fresh worktree and fast-forwards its session branch to the latest `origin/main` so the canvas begins with the complete merged feature.
+
+## Summary and next steps
+
+You've automated several parts of the development process, including generating code, testing and validating code, and now the pull request process. You:
+
+- learned what Agent Merge is and how it automates the merge lifecycle.
+- reviewed the complete filtering, skill, QA-profile, and test diff as PR 3.
+- reused current QA evidence, inspected CI, and explicitly authorized Agent Merge.
+
+Next, you'll explore **canvases** — a richer way to plan and visualize work with the agent. Continue to [Lesson 9 - Create a triage canvas][next-lesson].
+
+## Resources
+
+- [Managing issues and pull requests with the GitHub Copilot app][managing-issues-prs]
+- [About the GitHub Copilot app][about-copilot-app]
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-canvases/
+[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
diff --git a/docs/app/9-canvases.md b/docs/app/9-canvases.md
new file mode 100644
index 00000000..72a8f0fe
--- /dev/null
+++ b/docs/app/9-canvases.md
@@ -0,0 +1,148 @@
+---
+title: "Lesson 9 - Create a triage canvas"
+description: "Create and review a repository-backed triage canvas, merge PR 4, and reopen it to add issue context without starting another feature."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+So far you've directed agents through chat. But a lot of work doesn't live in a conversation — it lives on a board, in a document, or on a checklist. **Canvases** give you and the agent a shared surface for exactly that kind of work, right inside the app. In this lesson you'll create a simple canvas to plan and track the backlog you've been working through.
+
+In this lesson, you will:
+
+- understand what a canvas is and when to use one.
+- create a shared Kanban board canvas to triage your backlog.
+- save the canvas to your repository and merge it for the team.
+- reopen the canvas and add issue context without implementing another feature.
+
+## Scenario
+
+Looking at a list of issues can be daunting. Tailspin Toys' developers want a tool to triage issues and add their details to a session's context. Adding context is not authorization to implement an issue; this exercise ends with a reusable board, not a fifth PR.
+
+## What is a canvas?
+
+A [canvas][canvas-docs] is a shared, interactive surface for a work artifact — a plan, a triage board, a release checklist, a dashboard, or a document. While chat is great for describing intent and reasoning through ambiguity, most work happens on a *surface*. Canvases let you collaborate with the agent directly on that surface.
+
+Canvases are **bidirectional**: the agent can update the canvas while it works, and you can edit the same surface yourself. When you create a canvas, the agent builds it based on your prompt and workflow, and you can ask it to add, remove, or revise capabilities as you go. Once created, a canvas opens in the app's right side panel.
+
+Some common examples include:
+
+- **Markdown canvases** for planning your day and prioritizing issues and pull requests.
+- **Agentic kanban boards** where people and agents add cards and move work across columns.
+- **Issue triage boards** that summarize top issues and recurring themes for a repository.
+
+## Why use a canvas?
+
+Reach for a canvas when a task needs structure, iteration, and verification, and a chat alone isn't enough. A canvas lets you:
+
+- ground the agent's work in an actual artifact that fits your workflow.
+- steer or correct work directly on the shared surface, then let the agent continue from your changes.
+- inspect progress as visible changes to an artifact, not just chat responses.
+
+## Create a canvas to track your work
+
+Confirm PR 3 has merged. The star rating, documentation standard, filtering feature, quality skill, and QA profile must all be on `main` before starting the canvas. Use a fresh session and one branch for this final PR milestone.
+
+1. Return to (or open) the GitHub Copilot app.
+2. Select the **Home screen**.
+3. Ensure `tailspin-toys` is selected for the repo.
+4. Choose a **new working tree** and **Interactive** mode. Send this baseline request before creating any files:
+
+ ```plaintext
+ Prepare this fresh canvas session without implementing anything. Confirm this is a clean new worktree, fetch origin, and fast-forward the current session branch to origin/main. Report the checkout, branch, and matching HEAD and origin/main revisions. Verify the filtering PR is merged and the filtering feature, quality-checks skill, and QA profile are present.
+
+ Stop if the checkout is dirty, diverged, or missing the prior merge. Do not reset, discard work, switch branches, or create another branch. Stop after reporting the baseline.
+ ```
+
+5. Check the baseline report, then request the repository-backed canvas:
+
+ ```plaintext
+ Create a basic repository-backed Kanban triage canvas for this repository using the App's supported canvas-extension workflow. Save its definition under .github/extensions/ so the team can reuse it. Inspect existing extensions and preserve them; do not overwrite the supplied database explorer.
+
+ Read the current open issues. Highlight the three most likely to need attention, with the remainder below. Include each highlighted issue's title, content summary, URL, and a justification for its priority. Treat the ranking as a suggestion, not an instruction to change issues.
+
+ Give every card an Add to current context action that attaches the issue details to this session only. It must not start implementation, create sessions or branches, change issue state, or create PRs. Keep the canvas bounded and keyboard-accessible.
+
+ Show me the generated files and open the canvas for inspection. Do not change application code, commit, push, or create a PR. Ask before installing anything or adding dependencies.
+ ```
+
+Copilot creates the canvas files and opens the shared surface. Review the generated extension before trusting its actions; it is executable repository content, not just a picture.
+
+> [!NOTE]
+> If the first version needs work, request focused improvements within the triage scope. Do not turn this exercise into implementing one of the backlog issues.
+
+## Inspect and exercise the canvas
+
+1. Open **Changes** and confirm the canvas definition is repository-backed under `.github/extensions/`, not saved only for your user or session. Check that existing extensions and application files are unchanged.
+2. Compare the board with the actual open issues and assess the ranking explanations.
+3. Check that cards and controls are readable and usable with a keyboard.
+4. Select **Add to current context** for an issue and confirm only its details enter the conversation. No implementation or issue-state change should start.
+5. Review any corrections and ask Copilot to run the applicable existing validation for the files changed. Record results and blockers, rather than assuming an interactive surface is correct because it opened.
+
+## Save the canvas and merge it to the repository
+
+The canvas is already a repository asset. Commit and submit only the reviewed canvas work as PR 4:
+
+1. In the same session, send:
+
+ ```plaintext
+ Review the repository-backed triage canvas diff and its validation evidence. Commit the approved canvas files on this session branch, push it, and create one PR targeting main using the repository's PR template. Describe the canvas behavior and how we verified that adding an issue only adds context. Do not merge yet or implement a backlog issue.
+ ```
+
+2. Review the full PR diff and checks in **My work**. Confirm it contains the canvas, not unrelated application work.
+3. In the same canvas session, open the PR action dropdown and select **Agent merge**. Review its allowed actions and keep **Merge pull request** off until you approve the final result.
+4. Set the scope before starting Agent Merge:
+
+ ```plaintext
+ Manage this existing canvas PR with Agent Merge. Address only in-scope review and CI blockers; ask before unrelated changes or installations. If the canvas changes, repeat its affected validation and update the evidence. Do not merge until I explicitly enable Merge pull request after review. Do not implement backlog issues or create another PR.
+ ```
+
+5. Select **Agent merge** and review any follow-up changes. Inspect the learner repository's actual CI checks and resolve failures; CI is not a replacement for exercising the canvas.
+
+6. When the final diff and current evidence are approved and required checks and reviews pass, explicitly allow Agent Merge to merge by selecting its dropdown, then **Merge pull request**.
+
+ 
+
+7. Confirm GitHub shows PR 4 as **Merged** before continuing.
+
+You've now created a new shared canvas for your team!
+
+## Reopen the canvas without starting another feature
+
+Reopen the repository-backed canvas in the same canvas session after its PR is merged. This is an inspection step, not another branch or PR milestone.
+
+1. Return to the canvas session, keep **Interactive** mode, and close the canvas panel if it is still open.
+2. Send:
+
+ ```plaintext
+ Reopen the repository's triage canvas in this same session. I will add an issue to context to inspect its details only. Do not edit files, implement the issue, change its state, create another session or branch, commit, push, or open a PR.
+ ```
+
+3. Confirm the saved canvas opens again without regenerating its definition.
+4. Select **Add to current context** on one of the issues that's of most interest to you.
+5. Confirm the selected issue's details appear in context without starting implementation. Stop there: the workshop has four PR milestones, not five.
+
+You've now used a canvas you created to streamline the development process.
+
+## Summary and next steps
+
+You created a shared surface where you and the agent can collaborate! You:
+
+- learned what canvases are and when to use them.
+- created a shared Kanban triage board canvas with the agent.
+- saved and merged the canvas to your repository with Agent Merge.
+- reopened the merged canvas and added issue context without launching another feature.
+
+With your backlog tracked, take a step back to review everything you've built and where to go next. Continue to [Lesson 10 - Wrap-up and next steps][next-lesson].
+
+## Resources
+
+- [Working with canvas extensions in the GitHub Copilot app][canvas-docs]
+- [Canvases on Awesome Copilot][awesome-copilot-canvases]
+- [About the GitHub Copilot app][about-copilot-app]
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
+[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
diff --git a/docs/app/README.md b/docs/app/README.md
index 0f424ef9..2c07a60b 100644
--- a/docs/app/README.md
+++ b/docs/app/README.md
@@ -3,12 +3,14 @@ slug: app
title: "GitHub Copilot app"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
The **[GitHub Copilot app](https://docs.github.com/copilot/concepts/agents/github-copilot-app)** is a desktop application built on Copilot CLI that brings agent-driven development into a single, focused workspace. It adds parallel agent sessions, switchable session modes, shared canvases, and native GitHub issue and pull request management — including **Agent Merge**, which shepherds a pull request through rebases, review feedback, CI fixes, and merge.
-Across these lessons you'll install the app and set up your project, then get oriented in the app's workspace and the backlog the template seeded for you. You'll start with a small change — adding a star rating — then add a custom instructions standard from an issue, build a filtering feature in an isolated agent session, and verify it with a reusable skill. You'll add the Playwright MCP server to explore the feature in a real browser, then climb a ladder of merge automation that ends with **Agent Merge** landing your pull request. Finally you'll collaborate on a shared canvas and automate recurring work — a complete loop from idea to merged feature.
+Setup Lessons 0–1 prepare your project and App workspace. The nine core modules, Lessons 2–10, begin with a star-rating quick win and a documentation convention demonstrated in real code. Then you'll plan and build filtering, create and execute a shell-bundled quality-checks skill, observe the feature through Playwright MCP, and create a QA custom agent to assess requirements and coverage. You'll review the complete feature PR and authorize Agent Merge, then create and merge a shared triage canvas.
+
+The workshop has four PR milestones: star ratings; instructions with their demonstration; filtering with the skill, QA profile, and tests; then the canvas. Start each milestone from updated `main`, using one branch per PR rather than one per module. Lessons 4–8 stay in the same filtering session, worktree, and branch. Reopening the canvas adds issue context without launching another feature or fifth PR. Automations are linked as a next step, not an additional exercise.
## Lessons
@@ -16,13 +18,15 @@ Across these lessons you'll install the app and set up your project, then get or
|--------|-------|-------------|
| [0. Prerequisites][ex0] | Setup | Install Node.js and create your copy of the Tailspin Toys project |
| [1. Install the Copilot app][ex1] | Setup | Install the app, connect your project, and get oriented in the workspace |
-| [2. Running your first agent session][ex2] | First change | Start a session and ship a small change as your first pull request |
-| [3. Guiding Copilot with custom instructions][ex3] | Context | Add a documentation standard from an issue and merge it |
-| [4. Building a feature with Autopilot][ex4] | Core Feature | Use Plan and Autopilot to build filtering, then verify it with a skill |
-| [5. Testing with Playwright MCP][ex5] | External Tools | Add the Playwright MCP server and explore your feature in a browser |
-| [6. Merging with Agent Merge][ex6] | Merge | Let Agent Merge fix and land your filtering pull request |
-| [7. Planning with canvases][ex7] | Collaboration | Create a shared canvas to plan and track your work |
-| [8. Review and next steps][ex8] | Summary | Automate recurring tasks and explore what's next |
+| [2. Add star ratings: a quick win][ex2] | First change | Display existing ratings and the null fallback, then merge PR 1 |
+| [3. Guide Copilot with custom instructions][ex3] | Context | Add a documentation standard and a real demonstration, then merge PR 2 |
+| [4. Build filtering with Plan and Autopilot][ex4] | Implementation | Approve the plan, implement and check filtering, and checkpoint |
+| [5. Create and use a quality-checks skill][ex5] | Repeatable checks | Create, inspect, and execute bundled shell scripts |
+| [6. Validate functionality with Playwright MCP][ex6] | Browser observation | Configure MCP through Customize and inspect filtering behavior |
+| [7. Create and use a QA agent][ex7] | Requirements and coverage | Select a specialist profile and gather final verification evidence |
+| [8. Create and merge the feature PR][ex8] | Review and merge | Review filtering, the skill, QA profile, and tests, then authorize Agent Merge for PR 3 |
+| [9. Create a triage canvas][ex9] | Collaboration | Share a repository-backed canvas in PR 4 and add issue context |
+| [10. Wrap-up and next steps][ex10] | Summary | Review the workflow, artifacts, and further resources |
## Prerequisites
@@ -50,9 +54,11 @@ Before attending this workshop, please ensure you have:
[ex2]: 2-add-star-rating/
[ex3]: 3-custom-instructions/
[ex4]: 4-build-filtering/
-[ex5]: 5-mcp-playwright/
-[ex6]: 6-agent-merge/
-[ex7]: 7-canvases/
-[ex8]: 8-review/
+[ex5]: 5-agent-skills/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-canvases/
+[ex10]: 10-review/
[install-git]: https://github.com/git-guides/install-git
[callout-student-plan-education]: https://github.com/education/students
diff --git a/docs/cli/0-prerequisites.md b/docs/cli/0-prerequisites.md
index b75cccb2..eb67805b 100644
--- a/docs/cli/0-prerequisites.md
+++ b/docs/cli/0-prerequisites.md
@@ -2,7 +2,7 @@
title: "Exercise 0: Prerequisites"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
Before you start the Copilot CLI exercises, you need to get everything ready. You'll create your own copy of the Tailspin Toys repository and spin up a [codespace][codespaces], whose integrated terminal you'll use to install and run Copilot CLI in the next exercise.
@@ -11,6 +11,8 @@ Before you start the Copilot CLI exercises, you need to get everything ready. Yo
To create a copy of the repository for the code you'll create, you'll make an instance from the [template][template-repository]. The new instance will contain all of the necessary files for the lab, and you'll use it as you work through the exercises.
+Use a fresh template copy. It includes repository instructions, application code, tests, and CI, but no supplied custom agents or skills. You'll create those assets yourself. If you are returning to an older copy, inspect existing customizations before changing them; do not overwrite your own work.
+
1. In a new browser window, navigate to the GitHub repository for this lab: `https://github.com/github-samples/tailspin-toys`.
2. Create your own copy of the repository by selecting the **Use this template** button on the lab repository page. Then select **Create a new repository**.
@@ -26,6 +28,9 @@ To create a copy of the repository for the code you'll create, you'll make an in
> **Your backlog is ready**
>
> When you create your repository from the template, a backlog of GitHub issues is created for you automatically. You'll work from these issues throughout the workshop — there's nothing to file yourself.
+
+Wait for the issue-bootstrap workflow to finish, then check the **Issues** tab for **Allow users to filter games by category and publisher** and **Update our repository coding standards**. Use their actual titles and URLs in the lessons, not assumed issue numbers. If the backlog is missing, inspect the workflow result before proceeding.
+
## Creating a codespace
Next up, you'll use a codespace to complete the lab exercises.
@@ -49,6 +54,8 @@ The creation of the codespace will take several minutes, although it's still far
> [!NOTE]
> This workshop is built to run inside a codespace or local [dev container][dev-containers]. Both ensure the environment has all the necessary prerequisites installed for a smooth experience. If you'd prefer to run it locally, open the cloned repository in VS Code and select **Reopen in Container** when prompted — VS Code will build the same dev container the codespace uses.
+Once your codespace is ready, [Exercise 1][next-lesson] will open its terminal and check the repository, runtime, and authentication before installing Copilot CLI.
+
## Summary
Congratulations, you have created a copy of the lab repository! You also began the creation process of your codespace, which you'll use when you begin working with Copilot CLI.
diff --git a/docs/cli/1-install-copilot-cli.md b/docs/cli/1-install-copilot-cli.md
index 722b8516..89188725 100644
--- a/docs/cli/1-install-copilot-cli.md
+++ b/docs/cli/1-install-copilot-cli.md
@@ -2,7 +2,7 @@
title: "Exercise 1 - Installing GitHub Copilot CLI"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
[GitHub Copilot CLI][about-copilot-cli] is a powerful agentic coding assistant that runs in your terminal, enabling you to explore codebases, generate code, run commands, and interact with external tools - all from the command line. It allows you to offload tasks, request changes, and stay in the zone. The first step, as you might imagine, is to install the tool! Fortunately this can be done using tools you're already familiar with.
@@ -21,10 +21,25 @@ Your team is starting to use AI agents to work through a growing backlog. Copilo
Before installing Copilot CLI, you need to open a terminal window in your codespace.
-1. Return to your codespace if you're not already there.
+1. Return to your codespace and wait for its setup to finish.
2. Open a terminal window by pressing Ctrl+\`.
3. You should see a terminal panel appear at the bottom of your VS Code window.
+## Confirm the learner environment
+
+In the codespace terminal, confirm you are in your own Tailspin Toys repository, not the workshop-content repository. Read its `README.md` and `package.json` for setup and check commands. Current Tailspin Toys requires Node.js 22.13 or later, project dependencies, and Playwright Chromium for E2E testing.
+
+```bash
+pwd
+git remote -v
+node --version
+gh auth status
+```
+
+GitHub CLI (`gh`) will help inspect PRs and CI. If authentication is missing, use `gh auth login` and follow its browser instructions. Confirm your account can push branches and create and merge PRs in this repository; organizational policies may require another reviewer. Resolve missing prerequisites using the repository setup instructions before starting code changes, and review any installation before authorizing it.
+
+The CLI runs against the checkout where you start it; starting a conversation does not automatically create an isolated worktree. This workshop uses one branch per PR milestone. You'll merge star ratings and the instructions demonstration first, then keep the same filtering branch through Exercises 4–8.
+
## Install Copilot CLI
You can install Copilot CLI through [npm][install-npm], [WinGet][install-winget], and [Homebrew][install-homebrew]. Since GitHub Codespaces come with Node.js pre-installed you'll use npm to install Copilot CLI.
@@ -35,7 +50,7 @@ You can install Copilot CLI through [npm][install-npm], [WinGet][install-winget]
node --version
```
- You should see version 22 or higher (e.g., `v22.x.x`).
+ Tailspin Toys requires version 22.13 or higher, even if the CLI's own requirement differs. Follow the learner repository's setup instructions if your version is too old.
2. Install Copilot CLI globally in the codespace using npm:
@@ -51,8 +66,8 @@ You can install Copilot CLI through [npm][install-npm], [WinGet][install-winget]
You should see the version number displayed (e.g., `v1.0.XX`).
-> [!TIP]
-> If you encounter permission errors, you may need to use `sudo npm install -g @github/copilot` on some systems. However, this shouldn't be necessary in GitHub Codespaces.
+> [!NOTE]
+> If installation fails with a permission error, inspect your npm configuration or ask your workshop leader for help rather than rerun an unfamiliar command with elevated privileges.
## Authenticate with GitHub
@@ -85,22 +100,39 @@ Now that you're at the Copilot CLI prompt for the first time, let's trust this w
2. For this workshop, select **Yes, and remember this folder for future sessions** since you'll be working in this repository throughout.
3. Ask Copilot a simple question to verify it's working:
- ```
+ ```plaintext
What files are in this project?
```
4. Copilot should explore the repository and provide a summary of the project structure.
5. Try the `/help` command to see available slash commands:
- ```
+ ```text
/help
```
-6. Exit Copilot CLI by entering the following command in the terminal. We will return back to Copilot CLI in a future exercise!
+6. Exit this session by entering the following command at the Copilot prompt. You'll start a fresh session for the first change.
+ ```text
+ /exit
```
- exit
- ```
+
+## Understand modes and permissions
+
+Copilot CLI works in the directory and Git branch where you launch it. Trusting a directory lets it use repository context; it is not the same as approving every tool action. Review permission requests for file changes, shell commands, and GitHub operations.
+
+Start the code exercises from your learner repository root with:
+
+```bash
+copilot --enable-all-github-mcp-tools
+```
+
+The GitHub MCP server is built in. This flag exposes its full tool set for issue and PR work; authentication, repository permissions, and tool approvals still apply. It does not authorize a commit or PR on its own.
+
+Use Shift+Tab to cycle between standard **Interactive**, **Plan**, and **Autopilot** modes. Check the mode indicator before sending a request. You'll stay Interactive for the early changes, plan filtering before building it, and explicitly return to Interactive before creating and reviewing customizations.
+
+> [!CAUTION]
+> Mode and permission settings are different. Autopilot continues working autonomously; `--allow-all` and its alias `--yolo` grant all tool, path, and URL permissions. This workshop does not require starting every session with unrestricted permissions. Review the scope before granting access, even inside a codespace.
## Summary and next steps
@@ -111,7 +143,7 @@ Congratulations! You've successfully installed and authenticated GitHub Copilot
- trust a directory for Copilot CLI to work with.
- verify the installation is working correctly.
-Now that Copilot CLI is installed, let's give Copilot some project context. Continue to [Exercise 2 - Custom instructions with CLI][next-lesson].
+Now that Copilot CLI is installed, make a small, reviewable change in [Exercise 2 - Add star ratings: a quick win][next-lesson].
## Resources
@@ -120,7 +152,7 @@ Now that Copilot CLI is installed, let's give Copilot some project context. Cont
- [Using Copilot CLI][using-copilot-cli]
[previous-lesson]: ../0-prerequisites/
-[next-lesson]: ../2-custom-instructions/
+[next-lesson]: ../2-add-star-rating/
[install-copilot-cli]: https://docs.github.com/copilot/how-tos/set-up/install-copilot-cli
[install-npm]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-npm-all-platforms
[install-winget]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-winget-windows
diff --git a/docs/cli/10-review.md b/docs/cli/10-review.md
new file mode 100644
index 00000000..7203a4a7
--- /dev/null
+++ b/docs/cli/10-review.md
@@ -0,0 +1,67 @@
+---
+title: "Exercise 10 - Wrap-up and next steps"
+description: "Review the shared development workflow, reusable artifacts, and three CLI pull-request milestones."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+You've used Copilot CLI to move from a small change to a planned feature with reusable verification. Setup in Exercises 0–1 prepared your environment; the nine core modules in Exercises 2–10 taught a complete development workflow.
+
+## Review the three PR milestones
+
+| Milestone | Merged outcome | Review habit |
+| --- | --- | --- |
+| PR 1: star ratings | Existing `starRating` displayed on game cards, including `No rating yet` for `null` | Keep the change bounded and verify both cases |
+| PR 2: custom instructions | A focused documentation convention and a small real-code demonstration | Check that instructions improve actual code, not just chat examples |
+| PR 3: filtering and verification | Filtering, the quality-checks skill, QA profile, and associated tests | Review all checkpoints, current QA evidence, and CI before merging |
+
+The first two PRs merged before the next milestone began from updated `main`. Exercises 4–8 shared one branch and checkout. Checkpoint commits preserved progress without creating a PR for every module. The controls exercise did not launch another feature or PR.
+
+## Review the shared artifacts
+
+These are the same core outcomes as the [Copilot app workshop][app-workshop], reached through a terminal interface:
+
+- **Repository instructions** explain project context and standards; path-scoped instructions add detail for relevant files.
+- **The filtering implementation and tests** satisfy the issue and the clarifications you approved during planning.
+- **The quality-checks skill** packages reusable instructions and actual shell scripts that run the project's four checks.
+- **Playwright MCP configuration** supplies browser tools for direct observation. In this CLI flow it lives in user configuration rather than the feature PR.
+- **The QA custom agent** defines a reusable role that starts from requirements, checks coverage, uses the skill and browser tools, and reports truthful results.
+- **PR and verification evidence** connects the reviewed changes to test results, browser observations, limitations, and CI.
+
+A skill is more than a list of commands, and a profile is more than a filename. You inspected generated assets, confirmed actual execution, and selected the custom agent before relying on its report.
+
+## Keep the validation purposes distinct
+
+Planning clarified the requirements before implementation. Autopilot carried out that bounded plan; returning to Interactive restored deliberate review points before customization authoring.
+
+The implementation used existing npm checks before any skill existed. The skill exercise proved its bundled scripts and argument forwarding worked. MCP demonstrated direct browser interaction rather than repeating a full suite. QA combined criteria, coverage, browser evidence, and all four skill-driven checks. The PR reused current QA results while CI checked the submitted revision.
+
+Failures and blockers are useful outcomes. Missing browser tools, skipped tests, stale servers, or an unresolved requirement mean **NO-GO**, not permission to lower the standard. Test additions are justified by real gaps; adding no tests is correct when existing coverage is adequate.
+
+## Carry these habits forward
+
+- Give Copilot the issue, the reason for the change, and clear boundaries.
+- Review plans before approving autonomous work.
+- Inspect generated instructions, skills, and profiles before running them.
+- Know which checkout, branch, server, and revision a result describes.
+- Use the smallest justified correction and refresh evidence after changes.
+- Keep installations, destructive actions, sharing, and PR merges explicit.
+
+## Continue learning
+
+The [Copilot app workshop][app-workshop] reaches the shared outcomes through its graphical interface and adds a canvas milestone. The [VS Code workshop][vscode-workshop] and [Cloud agent workshop][cloud-workshop] explore other ways to work with agents.
+
+Use [Awesome Copilot][awesome-copilot] to find instruction, skill, and custom-agent examples. The [skill examples in Exercise 5][skill-examples] include contribution workflows, requirements documents, diagrams, and browser testing. Review prerequisites and behavior before adopting community content.
+
+For everyday reference, consult the [CLI command reference][cli-reference], [agent skills documentation][agent-skills], and [custom-agent documentation][custom-agents]. Keep experimenting on bounded tasks and share only reviewed material through approved channels.
+
+[previous-lesson]: ../9-slash-commands/
+[app-workshop]: ../../app/
+[vscode-workshop]: ../../vscode/
+[cloud-workshop]: ../../cloud/
+[skill-examples]: ../5-agent-skills/#more-skill-examples
+[awesome-copilot]: https://github.com/github/awesome-copilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
+[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
+[custom-agents]: https://docs.github.com/copilot/concepts/agents/copilot-cli/about-custom-agents
diff --git a/docs/cli/2-add-star-rating.md b/docs/cli/2-add-star-rating.md
new file mode 100644
index 00000000..6249f942
--- /dev/null
+++ b/docs/cli/2-add-star-rating.md
@@ -0,0 +1,83 @@
+---
+title: "Exercise 2 - Add star ratings: a quick win"
+description: "Display existing game ratings, review and validate the change, and merge your first pull request."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Start with a small change you can understand and verify. Tailspin Toys already stores each game's `starRating` and shows it on the details page. You'll display that existing value on the game cards, including a clear message when a game has no rating.
+
+In this exercise, you will:
+
+- request a focused change in an Interactive CLI session.
+- inspect the diff and verify rated and unrated cards.
+- commit, open, review, and merge PR 1.
+
+## Start the first milestone
+
+From your learner repository root, confirm the working tree is clean, update `main`, and create a branch. If `git status` shows unexpected changes, resolve them before switching; do not discard them.
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-star-rating
+copilot --enable-all-github-mcp-tools
+```
+
+Trust the repository when prompted. Check that you are in **Interactive** mode and use `/model` to inspect the available models or select **Auto**. Review tool approvals as they appear.
+
+## Request the change
+
+Send this prompt:
+
+```plaintext
+On the game cards, show each game's star rating. The Game type already includes a starRating field — it's a number out of 5, or null when a game hasn't been rated yet. Display it on each card in src/components/GameCard.astro, and when starRating is null show "No rating yet" instead. Keep the change small and don't restructure the card layout.
+
+Inspect and follow the repository instructions. Use the existing data model; do not add a rating API, new schema, or unrelated feature. Add or update appropriate tests for the rated and unrated cases. Do not commit, push, or open a pull request yet.
+```
+
+Copilot should inspect the existing type and component before editing. Read its tool activity as well as its final response. A confident summary is not evidence that the implementation is correct.
+
+## Review and validate
+
+1. Enter `/diff` and inspect every changed file in your editor or the diff view.
+2. Confirm the card uses the existing `starRating`, displays a value out of 5, and shows `No rating yet` for `null`. A truthiness check alone can incorrectly treat a numeric zero as unrated.
+3. Check that the change preserves the card layout and gives the rating a meaningful text label rather than relying only on a star symbol or color.
+4. Ask Copilot to verify the change using the existing checks:
+
+ ```plaintext
+ Inspect package.json and the test configuration, then run lint, type checks, and the existing unit or E2E tests appropriate to this card change. Verify both numeric ratings and the null fallback; report the exact commands and results, including any missing coverage or blocked checks. Do not install anything, change branches, commit, push, or open a PR.
+ ```
+
+5. Review the command output and any test changes. Resolve failures before shipping; ask before installing missing prerequisites.
+
+To observe the card in a browser, open a second terminal in this same checkout and run:
+
+```bash
+npm run dev
+```
+
+Open the forwarded port in your codespace's **Ports** panel. Inspect rated cards on the home page. If the current seed data has no unrated example, require an automated fixture covering `null`; do not claim you observed an unrated card. Stop your development server with Ctrl+C in its terminal before E2E checks or leaving the exercise. Playwright's automated tests must not reuse a server from another checkout.
+
+## Create and merge PR 1
+
+After reviewing the change and passing checks, authorize this milestone separately:
+
+```plaintext
+Review the current diff and check results. Commit only the reviewed star-rating change and its tests, push the current branch, and create a pull request into main using this repository's PR template if one exists. Include the change summary and actual verification results. Do not merge the PR or start another task.
+```
+
+Open the returned PR URL. Inspect **Files changed** and the check results, not just the agent's summary. Review the workflow definitions in your Tailspin repository when interpreting CI; CI does not replace your browser observation. Address any failures and reverify changed code.
+
+When the PR meets the repository's review and check requirements, select **Merge pull request** and confirm the merge on GitHub. If branch protection requires another reviewer, wait for that approval. Confirm the PR is **Merged** before continuing.
+
+Exit the Copilot session with `/exit`. In the next exercise, you'll update local `main` before creating the instructions branch; do not start it from this unmerged feature branch.
+
+## Summary and next steps
+
+You've completed the first cycle: a bounded prompt, reviewed code, verification evidence, and a merged PR. Next, [guide Copilot with custom instructions][next-lesson] and demonstrate a documentation convention in a second small PR.
+
+[previous-lesson]: ../1-install-copilot-cli/
+[next-lesson]: ../3-custom-instructions/
diff --git a/docs/cli/2-custom-instructions.md b/docs/cli/2-custom-instructions.md
deleted file mode 100644
index e1bfab7d..00000000
--- a/docs/cli/2-custom-instructions.md
+++ /dev/null
@@ -1,229 +0,0 @@
----
-title: "Exercise 2 - Custom instructions (Copilot CLI)"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-[← Previous lesson: Installing Copilot CLI][previous-lesson] · [Next lesson: Generating code with CLI →][next-lesson]
-
-Context is key when working with generative AI. If a task needs to be done a particular way — or there's background information Copilot should know — you want to make sure that context is available. There are several tools available to you to help Copilot, which we'll explore throughout this workshop. We're going to start with [instruction files][instruction-files], which are typically focused on how the code itself should be structured. This helps Copilot understand not just *what* code you want but *how* it should be structured.
-
-In this exercise, you will:
-
-- explore how project-specific context, coding guidelines, and documentation standards reach Copilot through repository custom instructions and path-scoped instruction files,
-- generate the first data slice for filtering (a publishers helper) with the *current* instructions in place,
-- add a new repository-wide standard to `.github/copilot-instructions.md`,
-- run a follow-up prompt and watch the regenerated code adopt the new standard,
-- commit the instruction updates and helper so the next exercise can build on them.
-
-> [!CAUTION]
-> Generated code may diverge from some of the standards you set. Copilot is non-deterministic. The goal is to see the *trend* in behavior change after updating the instructions, not to match output character-for-character.
-
-## Instruction files
-
-### Scenario
-
-As any good dev shop, Tailspin Toys has a set of guidelines and requirements for development practices. These include:
-
-- The data layer always needs unit tests.
-- UI should be in dark mode and have a modern feel.
-- Documentation should be added to code in the form of TSDoc doc comments.
-- A block of comments should be added to the head of each file describing what the file does.
-
-Through the use of instruction files you'll ensure Copilot has the right information to perform the tasks in alignment with the practices highlighted.
-
-### Custom instructions
-
-Custom instructions allow you to provide context and preferences to Copilot, so that it can better understand your coding style and requirements. This is a powerful feature that can help you steer Copilot to get more relevant suggestions and code snippets. You can specify your preferred coding conventions, libraries, and even the types of comments you like to include in your code. You can create instructions for your entire repository, or for specific types of files for task-level context.
-
-There are two types of instructions files:
-
-- `.github/copilot-instructions.md`, a single instruction file sent to Copilot for **every** request for the repository. This file should contain project-level information — context relevant for most chat or CLI requests sent to Copilot. This could include the tech stack being used, an overview of what's being built, best practices, and other global guidance.
-- `.github/instructions/*.instructions.md` files can be created for specific tasks or file types. You can use them to provide guidelines for particular languages (like TypeScript or Astro), or for tasks like creating a UI component or a new set of unit tests.
-
-> [!NOTE]
-> When working in your IDE, instructions files are only used for code generation in Copilot Chat — not for code completions or next-edit suggestions.
->
-> Copilot Chat, Copilot CLI and Copilot cloud agent use both repository-level and `*.instructions.md` files (with `applyTo` front matter) when generating code.
->
-> Finally, Copilot [supports instructions files using other standards][custom-instructions-support], including AGENTS.md and CLAUDE.md files.
-
-### Best practices for managing instructions files
-
-A full conversation about creating instructions files is beyond the scope of the workshop. However, the examples provided in the sample project show a representative approach. At a high level:
-
-- Keep instructions in `copilot-instructions.md` focused on project-level guidance, such as a description of what's being built, the structure of the project, and global coding standards.
-- Use `*.instructions.md` files to provide specific instructions for file types (unit tests, Astro components, the data layer), or for specific tasks.
-- Use natural language. Keep guidance clear. Provide examples of how code should (and shouldn't) look.
-
-There isn't one specific way to create instructions files, just as there isn't one specific way to use AI. You will find through experimentation what works best for your project.
-
-> [!TIP]
-> Every project using GitHub Copilot should have a robust collection of instruction files. As you explore the ones in this project, you may notice there are files for numerous types of tasks, including [UI updates][ui-instructions] and [Astro][astro-instructions].
->
-> Copilot can also help generate instruction files for you. Each surface exposes this differently (for example, **Configure Chat → Generate Agent Instructions** in VS Code, or `/init` in Copilot CLI) — the lesson for the surface you're on will call it out where it's relevant.
->
-> Looking for templates or a starting point? Explore [awesome-copilot][awesome-copilot], a repository full of instruction files, custom agents, and other resources.
-
-## Explore the custom instructions files in this project
-
-Take a moment to read the instruction files this repository ships with — there's one core `copilot-instructions.md` and a collection of `*.instructions.md` files for various tasks. Open these in your editor or the GitHub web UI.
-
-1. Open `.github/copilot-instructions.md`.
-2. Explore the file, noting the brief description of the project plus sections such as **Agent notes**, **Code standards**, **Scripts**, and **Repository Structure**. Under **Code standards**, note the nested **GitHub Actions Workflows** guidance. These are applicable to any interactions you'd have with Copilot.
-3. Open the `.github/instructions` folder and look around. Note there are instructions for Astro files, the Drizzle data layer, tests, and more.
-4. Open `.github/instructions/unit-tests.instructions.md`. Note the `applyTo` field at the top — this sets a glob (relative to the repo root) that determines which files the instructions apply to. Here, any TypeScript test file (for example, one matching `**/*.test.ts`) will match.
-5. Note the instructions specific to creating unit tests for this project.
-6. Finally, open `.github/instructions/drizzle.instructions.md` and scroll to the bottom. Note the links to other instruction files (like `unit-tests.instructions.md`) and existing files in the project. This lets you break larger instruction sets into smaller, reusable files, and point Copilot at examples to follow when generating code. (Paths there are relative to the instruction file rather than the repo root.)
-
-> [!NOTE]
-> The **Code formatting requirements** section in `copilot-instructions.md` documents the project's coding standards, but it doesn't yet require in-code documentation. In the next steps, you'll add rules for TSDoc doc comments and file comment headers.
-## Create a branch
-
-You'll be making code changes, so create a branch to work in.
-
-1. From your codespace terminal, create and switch to a new branch:
-
- ```bash
- git checkout -b update-custom-instructions
- ```
-
-2. Confirm Copilot CLI is installed and authenticated:
-
- ```bash
- copilot --version
- ```
-
- If the command isn't found or you haven't logged in, return to [Exercise 1 - Installing GitHub Copilot CLI](../1-install-copilot-cli/).
-
-## Use Copilot CLI *before* updating the instructions
-
-To see the impact of custom instructions, start by generating code with the current instructions in place. Later, you'll update the file and run a follow-up prompt.
-
-> [!CAUTION]
-> `--yolo` enables full automatic permissions (`--allow-all-tools`, `--allow-all-paths`, and `--allow-all-urls`). Use it only in an isolated environment like a Codespace or VM, and never alias it as your default for day-to-day development. See [Allowing and denying tool use][allow-all-warning] for details.
-
-Running Copilot CLI from the **repository root** ensures it picks up `.github/copilot-instructions.md` automatically. `--enable-all-github-mcp-tools` turns on the read/write GitHub MCP tools so Copilot can read your backlog and open pull requests later in the workshop.
-
-1. Return to your codespace. If you closed it, navigate to your repository on GitHub.com, select **Code** > **Codespaces**, then reopen your existing codespace.
-2. Return to your open Copilot CLI session. If the terminal is closed or you exited Copilot CLI, open a terminal by selecting Ctrl+\`, then start it from the repository root by running `copilot --yolo --enable-all-github-mcp-tools`. Trust the project folder if prompted, then run `/models` and select **Auto**.
-3. At the Copilot CLI prompt, ask it to generate the publishers helper that the filtering UI will use:
-
- ```plaintext
- Create a new data-access helper at src/lib/publishers.ts to return a list of all publishers. It should return the name and id for all publishers. Do not run the tests yet.
- ```
-
-4. Copilot CLI will explore the project, propose a plan, and write the file in this `--yolo` session. Monitor the changes in your terminal output, then review in your editor.
-5. Open the generated `src/lib/publishers.ts` in your editor.
-6. Notice the helper is a typed function that takes a `db` client as its first argument and returns a typed array of publishers — that's coming from the data-layer conventions in `.github/instructions/drizzle.instructions.md` (which applies to `src/lib/*.ts`).
-7. Notice the generated code **is missing** TSDoc doc comments and a file-level comment header.
-
-> [!CAUTION]
-> Copilot is probabilistic — there's a chance it'll add doc comments even without being told. If that happens, that's fine; the *consistency* improvement after the instruction update is still the takeaway.
-
-## Add a new repository standard
-
-As highlighted previously, `.github/copilot-instructions.md` is designed to provide project-level information to Copilot. Let's ensure repository coding standards are documented to improve code suggestions.
-
-1. Re-open `.github/copilot-instructions.md`.
-2. Locate the **Code formatting requirements** section, which should be near line 27. Note how it documents the project's coding standards — but it has no rule yet for in-code documentation, which is why the generated helper had no doc comments.
-3. Add the following lines of markdown right below the existing standards to instruct Copilot to add file comment headers and TSDoc doc comments:
-
- ```markdown
- - Every exported function should have a TSDoc comment describing its purpose, parameters, and return value.
- - Before imports or any code, add a comment block to the file that explains its purpose.
- ```
-
-4. Save `copilot-instructions.md`.
-
-> [!TIP]
-> As you saw in the previous lesson, instruction files can be created at the repository level (`.github/copilot-instructions.md`) for global guidance, or as `*.instructions.md` files for specific languages, file types, or tasks. The repository-level file is the right home for project-wide standards like the doc comment rule you just added.
-## Re-run the prompt and observe the change
-
-Now that the instructions have a doc comment rule, ask Copilot CLI to update the publishers file you just generated. The same standards directive will steer the rewrite.
-
-1. Send `/clear` in your Copilot CLI session to start with a clean conversation.
-2. Send the following prompt:
-
- ```plaintext
- Update src/lib/publishers.ts to follow the latest documentation conventions in .github/copilot-instructions.md.
- ```
-
-3. Let the edit complete, then reopen `src/lib/publishers.ts`.
-4. Notice that the file now opens with a comment block similar to:
-
- ```typescript
- /**
- * Publisher data-access helpers for the Tailspin Toys Crowd Funding platform.
- * Provides functions to retrieve publisher information from the database.
- */
- ```
-
-5. Notice that the generated function now includes a TSDoc comment similar to:
-
- ```typescript
- /**
- * Returns a list of all publishers with their id and name.
- *
- * @param db - The Drizzle database client.
- * @returns A promise that resolves to an array of publisher objects.
- */
- ```
-
-6. Keep this updated file in place. It's the first data slice you'll build on in the next exercise.
-
-## Commit and push this first filtering slice
-
-1. In your terminal, verify the changed files:
-
- ```bash
- git status
- ```
-
-2. Stage the instruction update and the helper:
-
- ```bash
- git add .github/copilot-instructions.md src/lib/publishers.ts
- ```
-
-3. Commit the changes:
-
- ```bash
- git commit -m "Add doc comment standards and publishers helper foundation"
- ```
-
-4. Push the branch:
-
- ```bash
- git push -u origin update-custom-instructions
- ```
-
-## Summary and next steps
-
-You explored how Copilot picks up context from instruction files in this project, then used Copilot CLI to:
-
-- generate a publishers data-access helper foundation for filtering with the *existing* instructions,
-- add a new repository-wide standard to `.github/copilot-instructions.md`,
-- run a follow-up prompt and watch the regenerated code adopt the new standard,
-- commit and push both the instructions update and the helper foundation.
-
-Next, you'll apply these instructions while implementing backlog work in [the generating-code exercise][next-lesson].
-
-## Resources
-
-- [Instruction files for GitHub Copilot customization][instruction-files]
-- [Best practices for creating custom instructions][instructions-best-practices]
-- [5 tips for writing better custom instructions for Copilot][copilot-instructions-five-tips]
-- [Awesome Copilot — a collection of instruction files and other resources][awesome-copilot]
-
-[previous-lesson]: ../1-install-copilot-cli/
-[next-lesson]: ../3-generating-code/
-[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
-[instructions-best-practices]: https://docs.github.com/enterprise-cloud@latest/copilot/using-github-copilot/coding-agent/best-practices-for-using-copilot-to-work-on-tasks#adding-custom-instructions-to-your-repository
-[copilot-instructions-five-tips]: https://github.blog/ai-and-ml/github-copilot/5-tips-for-writing-better-custom-instructions-for-copilot/
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-[ui-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/ui.instructions.md
-[astro-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/astro.instructions.md
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[custom-instructions-support]: https://docs.github.com/copilot/reference/custom-instructions-support
diff --git a/docs/cli/3-custom-instructions.md b/docs/cli/3-custom-instructions.md
new file mode 100644
index 00000000..0d7b9649
--- /dev/null
+++ b/docs/cli/3-custom-instructions.md
@@ -0,0 +1,109 @@
+---
+title: "Exercise 3 - Guide Copilot with custom instructions"
+description: "Add a focused documentation convention, demonstrate it on existing code, and merge the second pull request."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Context helps Copilot understand not just *what* to build but *how* your team expects code to be written. You'll add a focused documentation convention, observe its effect on real code, and merge the instructions and demonstration together as PR 2.
+
+In this exercise, you will:
+
+- explore repository-wide and path-scoped instructions.
+- add a documentation standard without implementing filtering early.
+- demonstrate the standard on a small existing helper or component.
+- validate and merge the instructions milestone.
+
+## Explore the instructions
+
+The repository already contains two useful kinds of instructions:
+
+- `.github/copilot-instructions.md` supplies repository-wide context, such as the stack, structure, and common practices.
+- `.github/instructions/*.instructions.md` supplies scoped guidance. An `applyTo` frontmatter glob identifies the files the instructions apply to.
+
+Open these files in your editor:
+
+1. Read `.github/copilot-instructions.md` and locate the current coding and verification standards.
+2. Explore `.github/instructions/`, including the Astro, data-layer, and test guidance.
+3. In `unit-tests.instructions.md`, inspect the `applyTo` pattern and the testing conventions.
+4. In `drizzle.instructions.md`, inspect the data-access patterns and references to examples.
+
+Keep repository-wide instructions concise, place file-specific detail in the relevant scoped file, and avoid conflicting copies of the same rule. [GitHub's instruction support reference][instruction-support] explains which instruction formats each harness supports.
+
+> [!NOTE]
+> Instructions influence generation; they do not guarantee compliance. Your review will check both the instruction text and its effect on code. If Copilot already produces good comments, the lesson is about making the convention explicit and repeatable, not forcing a before-and-after failure.
+
+## Start from merged PR 1
+
+Confirm the star-rating PR is merged. From the learner repository terminal, start the next milestone from updated `main`:
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c update-custom-instructions
+copilot --enable-all-github-mcp-tools
+```
+
+If the working tree is not clean or the pull fails, resolve that state before continuing. Stay in **Interactive** mode.
+
+In the repository's **Issues** tab, find **Update our repository coding standards** and copy its actual URL. The issue provides the broader context: explain intent, document exported data-layer functions and component contracts, and keep comments current. This exercise takes a bounded documentation slice, not a repository-wide refactor or a promise to complete every issue criterion.
+
+## Add the documentation convention
+
+Replace the placeholder with the actual issue URL and send:
+
+```plaintext
+Read this coding-standards issue for context: . Inspect the existing repository and scoped instructions. Add a focused documentation convention: explain intent rather than restating code, document exported functions in db/ and src/lib/ with TSDoc/JSDoc covering purpose, parameters, and return values, document reusable Astro component Props contracts, and keep comments current when related code changes.
+
+Put each rule in the appropriate existing instruction file and avoid duplication or contradictions. Preserve the existing formatting and linting standards; link to or summarize the documentation convention in README where appropriate. Limit this change to the documentation standard, not a formatting-tool migration or repository-wide rewrite. Do not create a skill or agent, implement filtering, commit, push, or open a PR. Stop so I can inspect the instructions before the demonstration.
+```
+
+Inspect the diff. The convention should encourage useful comments, not demand a boilerplate header on every file or comments that merely repeat obvious code. Ask for corrections before proceeding.
+
+## Demonstrate the convention on real code
+
+Choose a small existing exported helper or reusable component after inspecting the repository. It does not need to be a publisher helper, and there is no requirement that `src/lib/publishers.ts` already exists.
+
+Send:
+
+```plaintext
+Using the updated instructions, select one small existing exported helper or reusable Astro component that would benefit from clearer documentation. Apply the convention directly to that file without changing runtime behavior or adding filtering functionality. Explain which instruction guided the change, and stop before committing or opening a PR.
+```
+
+Open the actual changed file. For a helper, check that the comments accurately describe its parameters, return value, and any injected database argument. For a component, check that its `Props` contract is documented. Confirm the explanation matches the code rather than just looking for a comment block.
+
+> [!TIP]
+> An illustrative snippet in the chat is not the demonstration: inspect a real repository change. If the selected code already meets the convention, choose another small existing target where an improvement is justified rather than add redundant comments.
+
+## Validate and merge PR 2
+
+Ask Copilot to validate the reviewed changes:
+
+```plaintext
+Review the instruction changes and the small documentation demonstration. Confirm runtime behavior is unchanged. Inspect package.json, run npm run lint and npm run typecheck:all, and run affected existing tests where the code change warrants them. Report exact commands and results. Do not install anything, create a skill, commit, push, or open a PR yet.
+```
+
+Resolve failures and inspect the final diff. Then authorize the milestone:
+
+```plaintext
+Commit only the reviewed documentation instructions, directly related README update, and small code demonstration. Push the current branch and create a PR into main following the repository's PR template. Include the verification results and reference the coding-standards issue as a partial contribution; do not use a closing keyword unless every issue criterion is actually satisfied. Do not merge or start filtering.
+```
+
+Open the PR URL, inspect **Files changed**, and review CI. After all required checks and reviews pass, merge on GitHub and confirm PR 2 is **Merged**. Exit the CLI session with `/exit`. Do not start the next milestone until this PR is merged.
+
+## Summary and next steps
+
+Your documentation convention and a real demonstration are now on `main`. Next, you'll [build filtering with Plan and Autopilot][next-lesson] in a fresh branch based on that merged state.
+
+## Resources
+
+- [Adding repository custom instructions][repository-instructions] explains repository-wide and path-scoped guidance.
+- [Awesome Copilot][awesome-copilot] offers examples to review and adapt, not blindly adopt.
+
+[previous-lesson]: ../2-add-star-rating/
+[next-lesson]: ../4-build-filtering/
+[instruction-support]: https://docs.github.com/copilot/reference/custom-instructions-support
+[repository-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
+[awesome-copilot]: https://github.com/github/awesome-copilot
diff --git a/docs/cli/3-generating-code.md b/docs/cli/3-generating-code.md
deleted file mode 100644
index 7a71d1f2..00000000
--- a/docs/cli/3-generating-code.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: "Exercise 3 - Adding project features with GitHub Copilot CLI"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-As you might expect, the core tasks you'll perform with GitHub Copilot CLI is to add features, functionality, and code to a project. Let's take one of the issues from your backlog and ask Copilot to help us implement it.
-
-## Scenario
-
-The time has come to complete filtering in the project. You already have the filtering issue in your backlog and a foundation helper from the previous exercise. Let's have Copilot retrieve the issue details, account for existing work, and build the remaining functionality.
-
-In this exercise, you will:
-
-- utilize plan mode to generate a plan for implementing the filtering functionality.
-- generate the code necessary to add filtering to the website with Copilot.
-
-By the end of this exercise, you will have added new functionality to the project.
-
-## Utilize plan mode
-
-One of the best uses of AI is planning. Oftentimes you'll have a good concept of what you want to build, but just need to bounce some ideas off of something. AI tools can help you crystalize your thoughts by asking you follow up questions and working through different pitfalls or missing components. To support this process, Copilot CLI offers a plan mode. Additionally, that time you spend planning will help Copilot generate code that best matches the requirements set forth.
-
-You'll start the process of creating the new functionality by utilizing plan mode in Copilot CLI.
-
-1. Return to your codespace. If you closed it, navigate to your repository on GitHub.com, select **Code** > **Codespaces**, then reopen your existing codespace.
-2. Return to your open Copilot CLI session. If the terminal is closed or you exited Copilot CLI, open a terminal by selecting Ctrl+\`, then start it from the repository root by running `copilot --yolo --enable-all-github-mcp-tools`. Trust the project folder if prompted, then run `/models` and select **Auto**.
-3. Enter the following prompt into Copilot CLI to create a plan based on the filtering issue:
-
- ```
- /plan Retrieve the issue on the repository related to adding filtering. We already added a publishers helper in src/lib/publishers.ts, so treat that as existing work and plan the remaining updates (games filtering logic, UI, and tests).
- ```
-
-4. Copilot may ask follow-up questions as it builds out its plan. As those arise, answer them based on how you'd build out the functionality.
-5. Once the plan is generated, review the blueprint. You should notice it recommends remaining changes across the data layer and UI, as well as generating tests.
-6. Copilot CLI will offer you the ability to provide additional feedback to the plan. You can cursor down to the indicated section, then type your suggestions. Copilot will incorporate your suggestions into a new version of the plan.
-7. Once you're satisfied, select the option provided by Copilot to begin work building the new feature!
-
-> [!NOTE]
-> Because Copilot is probabilistic, the exact text and options provided will vary. But you will notice an option to begin building that will read something similar to:
->
-> `Yes, and switch to autopilot mode`.
->
-> Copilot may offer you the option to enable [autopilot mode](https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot), as shown in the example above. Autopilot mode allows Copilot CLI to work through a task without waiting for your input after each step. Once you give the initial instruction, Copilot CLI works through each step autonomously until it determines the task is complete. As we are running in a contained environment, we're OK running autopilot and allowing all tools.
-
-8. Copilot will get to work generating the files!
-
-> [!NOTE]
-> This operation will likely take several minutes. You will see Copilot edit and create files, update and generate tests, and run all of the tests to ensure everything succeeds. Now's a good time to reflect on what you've explored thus far, or to enjoy a beverage.
-
-## Review the code
-
-All AI code needs to be reviewed before being merged into production. Let's take the time now to explore the files Copilot created and modified in implementing the new feature.
-
-1. Use Copilot CLI to display the "diff" or code changes by using the following command in Copilot CLI:
-
- ```
- /diff
- ```
-
-2. Note the files changed. Use your arrow keys to switch left and right to view the different files. You should see updates to files such as the games listing page (where the new filter controls and client-side filtering live) and `src/lib/games.ts`, plus tests like `games.test.ts`. You may also see updates to `publishers.ts` if Copilot refines your existing helper to align with the full implementation.
-
-## Summary and next steps
-
-You've now added filtering functionality to the website with the help of Copilot CLI! Specifically, you:
-
-- utilized plan mode to generate a plan for implementing the filtering functionality.
-- generated the code necessary to add filtering to the website with Copilot.
-
-Of course, the next step from here is to make sure it works. Let's [test your feature with the Playwright MCP server][next-lesson] before we open a pull request.
-
-## Resources
-
-- [Using Copilot CLI][using-copilot-cli]
-- [About Copilot CLI][about-copilot-cli]
-- [Context management in Copilot CLI][context-management]
-
-[previous-lesson]: ../2-custom-instructions/
-[next-lesson]: ../4-mcp/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
diff --git a/docs/cli/4-build-filtering.md b/docs/cli/4-build-filtering.md
new file mode 100644
index 00000000..24be0402
--- /dev/null
+++ b/docs/cli/4-build-filtering.md
@@ -0,0 +1,102 @@
+---
+title: "Exercise 4 - Build filtering with Plan and Autopilot"
+description: "Agree filtering requirements, approve an implementation plan, validate the code, and checkpoint on the feature branch."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Now build the larger feature: let users filter games by category and publisher. You'll plan before coding, explicitly authorize **Autopilot**, review and test the implementation, and save a checkpoint. This exercise does not create the skill, QA agent, or feature PR.
+
+## Start the filtering milestone
+
+Confirm PRs 1 and 2 are merged. In your learner repository terminal:
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-game-filtering
+copilot --enable-all-github-mcp-tools
+```
+
+Continue only with a clean working tree and a successful update from `main`. Exercises 4–8 use this same branch and checkout. Later checkpoint commits will add the skill and QA profile; do not create a branch per exercise.
+
+## Retrieve the actual issue
+
+Find **Allow users to filter games by category and publisher** in your repository's **Issues** tab and copy its URL. Do not assume the template's filename or an issue number identifies the issue in your copy.
+
+The current issue requires:
+
+- selecting one or more categories.
+- filtering by publisher and combining that with categories.
+- data-access helpers in `src/lib/` that support both filters.
+- accessible controls with keyboard navigation, appropriate ARIA, visible focus states, and `data-testid` attributes.
+- Vitest unit coverage for helpers and Playwright E2E coverage for filtering behavior.
+
+Read the live issue as the source of truth. Keep its URL and any clarifications you approve available for the QA prompt in Exercise 7.
+
+## Plan before coding
+
+Use Shift+Tab to select **Plan** mode, or begin with `/plan`. Replace the issue placeholder and send:
+
+```plaintext
+Plan the filtering feature described in this issue: . Read the issue, repository instructions, existing data-access helpers, UI, and tests before proposing changes. Treat the current checkout as the baseline; do not assume a publisher helper has already been created.
+
+Cover multiple-category selection, publisher filtering, their combination, data-access support, accessible controls, and unit/E2E coverage. Ask me to clarify unspecified behavior such as how multiple categories combine, clearing filters, and empty results; record the decisions with the approved plan. Preserve the static Astro architecture rather than introducing an unnecessary server API.
+
+Plan implementation on the current branch, including the required unit and E2E tests, and verification with npm run lint, npm run test:unit, npm run test:e2e, and npm run typecheck:all. Inspect prerequisites and server ownership first; report blockers rather than install software or stop unrelated processes.
+
+Include these execution boundaries in the plan: after I approve it, implement only the filtering feature and required tests, run the checks, then stop so I can review. Do not create the quality-checks skill, a QA agent, or other later workshop artifacts. Do not change branches, commit, push, or open or merge a PR.
+
+Do not edit application code or begin implementation until I approve the plan.
+```
+
+Answer the follow-up questions. Do not add hidden acceptance criteria later: save the agreed answers with the issue URL so the implementation, browser checks, and QA can all use the same requirements.
+
+Review the plan for data-layer and UI changes, tests, accessible controls, and the documentation convention you merged. Confirm it explicitly includes all four checks, the stop-for-review boundary, and the prohibitions on later workshop artifacts, branch changes, commits, pushes, and PR operations. Ask for revisions before approval if any limit or criterion is missing or it proposes work outside the issue.
+
+## Explicitly approve Autopilot
+
+Only after the plan includes the reviewed scope and execution boundaries, use the plan approval option to **Accept plan and build on autopilot**. If your version presents different wording, explicitly select the option that switches to **Autopilot**, then check the mode indicator. Approval starts execution of the bounded plan; do not rely on a later prompt to add limits after work has begun.
+
+> [!CAUTION]
+> Autopilot controls continued work, not just tool permissions. Review the permissions dialog before choosing. Full permissions allow tool, path, and URL access; limited permissions may block actions that require approval. A codespace is not permission to expose secrets or change unrelated resources. Resolve blocked access deliberately rather than treating skipped checks as passing.
+
+Monitor the work and command results. Autopilot may pause at a continuation limit or report a blocker before completing the plan. Review that state before authorizing it to continue, preserving the same scope.
+
+## Return to Interactive and review
+
+When implementation stops, use Shift+Tab to return to **Interactive** mode before sending any further prompts. Autopilot can remain active after a task; do not assume it switched back.
+
+Enter `/diff` and inspect all changed files. Compare the implementation with the issue and your approved clarifications:
+
+- Can users select multiple categories, filter by publisher, and combine them as agreed?
+- Do the data-access helpers actually support the filters rather than only changing the UI?
+- Do controls have meaningful labels, keyboard support, visible focus, and stable test identifiers?
+- Do tests assert behavior, including the agreed clearing and empty-result cases, without weakening existing assertions?
+- Does the code follow the documentation convention and preserve the static app's architecture?
+
+Review evidence for all four npm checks. You have not created `quality-checks` yet, so these checks run directly. Playwright's E2E configuration builds and serves a preview; stop only a development server you started before running the suite so it cannot reuse stale content. A port conflict or missing browser is a blocker to resolve, not a reason to kill another process or claim a pass.
+
+Request focused corrections if needed, rerun affected checks, and ensure the final implementation has complete verification. Direct browser observation comes in Exercise 6; it has a different purpose from this automated verification.
+
+## Save the implementation checkpoint
+
+Once the diff and results are satisfactory, authorize a local checkpoint:
+
+```plaintext
+Review the current diff and verification results. Create a checkpoint commit containing only the reviewed filtering implementation and its tests. Keep the current filtering branch and checkout. Do not push, open a PR, or create the skill or QA agent yet.
+```
+
+Record the tested revision and keep the issue URL and approved clarifications. Stay **Interactive** and continue in this same checkout to [Exercise 5 - Create and use a quality-checks skill][next-lesson].
+
+## Resources
+
+- [Autopilot mode and permissions][autopilot] explains autonomous continuation and switching back to Interactive.
+- [Copilot CLI command reference][cli-reference] lists current mode controls and commands.
+
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
+[autopilot]: https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/cli/4-mcp.md b/docs/cli/4-mcp.md
deleted file mode 100644
index 35bc2649..00000000
--- a/docs/cli/4-mcp.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title: "Exercise 4 - Testing your feature with the Playwright MCP server"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-You just generated the filtering feature with Copilot CLI. Before you open a pull request, you should confirm it works in the browser. Rather than click through the app yourself, you'll connect the **Playwright MCP server** and let Copilot drive a real browser to test the feature for you.
-
-In this exercise, you will:
-
-- understand what Model Context Protocol (MCP) is and how MCP servers extend Copilot CLI.
-- add the Playwright MCP server to Copilot CLI.
-- ask Copilot to use it to manually test your filtering feature in a browser.
-
-## What is Model Context Protocol (MCP)?
-
-[Model Context Protocol (MCP)](https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/) provides AI agents with a way to communicate with external tools and services. By using MCP, AI agents can communicate with external tools and services in real-time. This allows them to access up-to-date information (using resources) and perform actions on your behalf (using tools).
-
-These tools and resources are accessed through an MCP server, which acts as a bridge between the AI agent and the external tools and services. The MCP server is responsible for managing the communication between the AI agent and the external tools (such as existing APIs or local tools like NPM packages). Each MCP server represents a different set of tools and resources that the AI agent can access.
-
-A couple of popular existing MCP servers are:
-
-- **[GitHub MCP Server](https://github.com/github/github-mcp-server)**: This server provides access to a set of APIs for managing your GitHub repositories. It allows the AI agent to perform actions such as creating new repositories, updating existing ones, and managing issues and pull requests.
-- **[Playwright MCP Server](https://github.com/microsoft/playwright-mcp)**: This server provides browser automation capabilities using Playwright. It allows the AI agent to perform actions such as navigating to web pages, filling out forms, and clicking buttons.
-
-There are many other MCP servers available that provide access to different tools and resources. GitHub hosts an [MCP registry](https://github.com/mcp) to enhance discoverability and contributions to the ecosystem.
-
-> [!CAUTION]
-> With regard to security, treat MCP servers as you would any other dependency in your project. Before using an MCP server, carefully review its source code, verify the publisher, and consider the security implications. Only use MCP servers that you trust and be cautious about granting access to sensitive resources or operations.
-
-> [!NOTE]
-> The [GitHub MCP server][github-mcp-server] is **built in** to Copilot CLI — it's already available without any setup, which is how Copilot has been reading and writing to your repository throughout the workshop. In this exercise you'll add a *second* server, Playwright, to give Copilot a browser.
-
-## Add the Playwright MCP server
-
-The quickest way to add a server is the interactive `/mcp add` command. You'll register the [Playwright MCP server][playwright-mcp-server], which gives Copilot a browser it can control.
-
-1. Return to your codespace. If you closed it, navigate to your repository on GitHub.com, select **Code** > **Codespaces**, then reopen your existing codespace.
-2. Return to your open Copilot CLI session. If the terminal is closed or you exited Copilot CLI, open a terminal by selecting Ctrl+\`, then start it from the repository root by running `copilot --yolo --enable-all-github-mcp-tools`. Trust the project folder if prompted, then run `/models` and select **Auto**.
-3. In your Copilot CLI session, enter:
-
- ```text
- /mcp add
- ```
-
-4. A configuration form appears. Use Tab to move between fields and fill it in as follows:
-
- - **Server Name**: `playwright`
- - **Server Type**: select **Local** (also labelled **STDIO**)
- - **Command**: `npx @playwright/mcp@latest --headless`
- - **Tools**: leave as `*` to allow all of the server's tools
-
-5. Press Ctrl+S to save. The server is added and available immediately — no restart required.
-
-The `--headless` flag tells Playwright to run the browser without a visible window, which is required inside a codespace where there's no desktop to display it. Behind the scenes, this writes the server to your `~/.copilot/mcp-config.json` file:
-
-```json
-{
- "mcpServers": {
- "playwright": {
- "type": "local",
- "command": "npx",
- "args": ["@playwright/mcp@latest", "--headless"],
- "tools": ["*"]
- }
- }
-}
-```
-
-6. Confirm the server is registered and active by listing your MCP servers:
-
- ```text
- /mcp show
- ```
-
-7. You should see `playwright` listed alongside the built-in `github` server.
-
-> [!NOTE]
-> The Tailspin Toys project already uses Playwright for its end-to-end tests, so the browser Playwright needs is typically already installed. If Copilot later reports that a browser is missing, have it run `npx playwright install chromium` and try again.
-
-## Start the website
-
-The Playwright MCP server needs a running app to test against. Start the Astro dev server in a **separate** terminal so it keeps running while you work in Copilot CLI.
-
-1. Open a new terminal in your codespace by selecting Ctrl+\`.
-2. Start the website:
-
- ```bash
- npm run dev
- ```
-
-3. Leave this terminal running. Once you see the `Astro server: http://localhost:4321` banner, the app is ready.
-
-## Test the filtering feature
-
-Return to your Copilot CLI session and ask Copilot to test the feature.
-
-The [Playwright MCP server][playwright-mcp-server] gives Copilot a real browser to drive. Instead of you clicking through the app to check your work, the agent can open a page, navigate, apply filters, and read the result back to you — then summarize what it saw. It's the fastest way to confirm a feature behaves the way you expect without leaving the conversation.
-
-Under the hood, the Playwright MCP server works from the page's [accessibility tree][playwright-mcp-server] rather than screenshots. That means the agent reasons over structured, labelled elements (buttons, links, list items) the same way assistive technology does — so a quick functional check doubles as a light accessibility sanity check.
-
-With the server connected and the app running, ask Copilot to exercise the filtering feature you just built:
-
-```text
-Using the Playwright MCP server, open a browser to the running app at http://localhost:4321 and verify the new game filtering feature:
-
-1. Go to the games page and note how many games are listed.
-2. Apply a category filter and confirm the list updates to only show games in that category.
-3. Clear it, then apply a publisher filter and confirm the list updates to that publisher.
-4. Combine a category and a publisher filter and confirm the results respect both.
-
-Report what you observe at each step, and call out anything that does not behave as expected.
-```
-
-Copilot will launch a browser through the Playwright MCP server, walk through each step, and report back what it found. Read its summary against the acceptance criteria in the issue — if something looks off, ask follow-up questions or send it back to fix the code before you open a pull request.
-
-> [!NOTE]
-> The app needs to be running at `http://localhost:4321` for this test. If you stopped the dev server, start it again before sending the prompt. The first time Copilot uses the Playwright MCP server it may need to download a browser — if it reports a missing browser, have it run `npx playwright install chromium` and try again.
-
-## Summary and next steps
-
-Congratulations, you used the Playwright MCP server to manually test your feature with Copilot CLI! To recap, you:
-
-- learned what Model Context Protocol (MCP) is and how MCP servers extend Copilot CLI.
-- added the Playwright MCP server with `/mcp add`.
-- asked Copilot to drive a browser and verify your filtering feature before shipping it.
-
-Now that you've confirmed the feature works, you can continue to the next exercise, where you'll [open a pull request with the help of an agent skill][next-lesson].
-
-## Resources
-
-- [What the heck is MCP and why is everyone talking about it?][mcp-blog-post]
-- [Microsoft Playwright MCP Server][playwright-mcp-server]
-- [Adding MCP servers for Copilot CLI][cli-add-mcp]
-- [GitHub MCP Server][github-mcp-server]
-
-[previous-lesson]: ../3-generating-code/
-[next-lesson]: ../5-agent-skills/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[github-mcp-server]: https://github.com/github/github-mcp-server
-[cli-add-mcp]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
diff --git a/docs/cli/5-agent-skills.md b/docs/cli/5-agent-skills.md
index 5eecd846..56c4f2c1 100644
--- a/docs/cli/5-agent-skills.md
+++ b/docs/cli/5-agent-skills.md
@@ -1,105 +1,93 @@
---
-title: "Exercise 5 - Using agent skills"
+title: "Exercise 5 - Create and use a quality-checks skill"
+description: "Ask Copilot to create reusable shell-bundled quality checks, inspect the skill, and execute it on the filtering branch."
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
-Doing app development often involves repeatable tasks like generating builds, running tests, or creating pull requests. **Agent skills** let you give Copilot — and other AI agents — guidance on how to perform those tasks. A skill is a folder of instructions, scripts, and resources that the agent can load on demand. [Agent Skills is an open standard][agent-skills-repo] used by a range of agents, so the same skill can work across Copilot Chat in agent mode, Copilot cloud agent, Copilot CLI, and the GitHub Copilot app.
+Your filtering feature is implemented and checked with the existing npm commands. Now you'll package those checks as a reusable **agent skill**. Stay in the same filtering session and branch through Exercises 4–8; this exercise does not create a pull request.
-Let's explore how a skill can ensure pull requests follow the specifications set forth by our team.
+In this exercise, you will:
-## Scenario
+- return to **Interactive** mode before creating customizations.
+- ask Copilot to create and then stop for inspection of `quality-checks`.
+- execute all four checks through its bundled scripts and prove a single-file test argument selects only that file.
+- checkpoint the skill alongside the filtering feature.
-The team has a set of requirements for pull requests (PR):
+## Instructions, scripts, and resources
-- clear commit messages, with files grouped logically.
-- all tests must pass before a PR is created.
-- each PR must contain the following sections:
- - a description of why the changes were made.
- - an overview of the files changed.
- - snippets of important code blocks.
- - details of the changes made grouped together.
+Skills package reusable task instructions, executable scripts, and supporting resources that an agent loads on demand. Custom agents define specialist roles, instructions, and available tools. These are complementary: a custom agent can execute scripts, including those bundled with a skill.
-As the team is using Copilot to generate code and PRs, it wants to ensure the AI tools follow these requirements.
+A repository skill lives in `.github/skills//SKILL.md`, with `name` and `description` frontmatter and Markdown instructions. Scripts and other resources live beside it. You'll ask Copilot to generate `.github/skills/quality-checks/SKILL.md` and its bundled scripts, rather than copy a prebuilt answer. The [Agent Skills specification][skill-spec] describes the format.
-In this exercise you will:
+Copilot uses a discovered skill's description to decide when to load it. Don't assume a new skill is immediately discovered in an already open session; the run section includes an explicit-read fallback. A portable format does not remove shell or project prerequisites.
-- explore an existing skill for creating pull requests.
-- learn how skills are utilized by the AI agent.
-- create a PR which matches the guidelines with the help of the skill.
+## Create the skill
-## Creating agent skills
+Return to **Interactive** mode before sending the prompt. Keep the current checkout and branch. If you started with an older template that already has this skill, inspect and extend it rather than overwrite your customizations.
-Skills live in the `.github/skills` folder of a project, or globally in `~/.copilot/skills`. Each skill is a folder containing a `SKILL.md` file with YAML frontmatter (a `name` and a `description`) followed by the markdown instructions:
+```plaintext
+Create .github/skills/quality-checks/SKILL.md and four scripts wrapping npm run lint, npm run test:unit, npm run test:e2e, and npm run typecheck:all. Read package.json, README, test configuration, and repository instructions first.
-```yaml
----
-name: make-contribution
-description: All changes to code must follow the guidance documented in the repository. Before any issue is filed, branch is made, commits generated, or pull request (or PR) created, a search must be done to ensure the right steps are followed. Whenever asked to create an issue, commit messages, to push code, or create a PR, use this skill so everything is done correctly.
----
-```
+Detect this environment. Create ONLY Bash .sh scripts for macOS/Linux/WSL OR PowerShell .ps1 scripts for native Windows; ask if uncertain. Do not create both. Keep wrappers limited to resolving the repository root from their own location, verifying this project's package.json there, and invoking npm. Fail clearly for an invalid root. Support any working directory and paths with spaces. Preserve output and failure exit codes, including PowerShell native failures. Insert npm's -- exactly once; callers supply tool arguments directly without another --. No port or process management.
-Skills can also include subfolders with scripts, assets, and reference material. The full structure is covered in the [agent skills specification][agent-skills-spec].
+Give SKILL.md name/description frontmatter, instructions to run all four wrappers, prerequisites, troubleshooting, and portable examples including one existing unit-test file. Every Bash example must invoke bash explicitly; never bypass PowerShell execution policy. Explain Playwright server reuse: stop only servers you actually started; otherwise ask.
-> [!TIP]
-> Skills are loaded dynamically. The agent decides which skill applies based on the `description` field — a clear, scenario-specific description is the difference between a skill that gets used and one that gets ignored.
+Only create the skill and necessary scripts. Do not run checks or probes, install anything, change application code, commit, or open a PR. Stop for inspection.
+```
-## Executing skills
+## Inspect the skill
-Skills are loaded dynamically when the agent determines they're necessary. The decision of what skills to use is driven by the description in the `SKILL.md` file. As such, it's important to have clear descriptions which define the use case for the skill.
+1. Open `.github/skills/quality-checks/SKILL.md` and its bundled scripts in your editor, and inspect the diff.
+2. Check that `name` and `description` describe the skill and when it applies. Read the instructions, not just the metadata.
+3. Confirm the execution sequence actually invokes bundled scripts under `.github/skills/quality-checks/` for lint, unit tests, E2E, and type checking.
+4. Inspect each wrapper for script-relative root resolution and an explicit check that the derived directory contains this checkout's intended `package.json`. A command that succeeds because npm searches ancestor directories does not prove the root is correct. Check quoted paths, argument forwarding, visible output, and failure exits; PowerShell must propagate native npm failures.
+5. Check the documented single-unit-test-file example. The wrapper inserts npm's `--` separator, so callers pass target-tool arguments directly without another separator. Keep reusable instructions free of machine-specific absolute checkout paths. Ask Copilot to correct gaps before running anything.
+6. Keep the scripts limited to root/manifest validation and running the existing npm checks. Port and process decisions belong in SKILL.md, not shell process-management code. Confirm that only servers actually started by the agent may be stopped; a matching working directory or process name does not establish ownership. The delivered files should contain only the skill, required wrappers, and any needed shared helper, without temporary probe or debug files.
-## Exploring the PR skill
+> [!NOTE]
+> Current Tailspin Toys requires Node.js 22.13 or later, project dependencies, and Playwright Chromium for E2E checks. Confirm prerequisites in your checkout's README and `package.json`. Missing prerequisites or a blocked PowerShell execution policy need an approved resolution, not an automatic installation, policy bypass, or silent switch to direct npm.
-Because Tailspin Toys has a set of requirements for creating PRs, they created a skill to help AI tools be able to generate PRs which follow these guidelines. Let's explore the skill to understand what it'll do.
+## Run the skill
-1. Open `.github/skills/make-contribution/SKILL.md`.
-2. Note the name and description. Notice how the description highlights the scenario in which it should be used, which is whenever a request is made to create a pull request or committing code.
-3. Read through the skill. Notice the rules are defined about how branches should be created, commits generated, and the contents of the pull request.
+Confirm the development server from the previous exercise has stopped. Playwright builds and serves a preview for E2E, but its local configuration can reuse a server on port `4321`. A server from another checkout is not valid evidence for your feature.
-## Using the skill
+If Copilot CLI offers `/quality-checks`, select it to explicitly invoke the discovered skill and include the request below. If it is not discovered, send the same request directly in this session; reading the skill is a supported fallback for this exercise.
-As highlighted previously, skills are automatically invoked by Copilot CLI. As a result, all we need to do is ask Copilot to create a PR!
+```plaintext
+Read .github/skills/quality-checks/SKILL.md and follow its instructions to validate the filtering feature in this checkout. First inspect each wrapper's code to verify that it derives the directory containing this checkout's intended package.json and explicitly fails for an invalid root, rather than relying on npm's ancestor-package discovery. Do not move, rename, delete, or modify repository files to simulate failures. Actually run its bundled scripts for lint, unit tests, end-to-end tests, and type checks. Also run the documented single-unit-test-file example, passing target-tool arguments directly because the wrapper owns npm's -- separator. Verify from the test runner's results that ONLY the named file ran, and report that filename and the executed test-file count. Echoing arguments or returning exit code 0 alone is not proof of correct selection.
-1. Return to your codespace. If you closed it, navigate to your repository on GitHub.com, select **Code** > **Codespaces**, then reopen your existing codespace.
-2. Return to your open Copilot CLI session. If the terminal is closed or you exited Copilot CLI, open a terminal by selecting Ctrl+\`, then start it from the repository root by running `copilot --yolo --enable-all-github-mcp-tools`. Trust the project folder if prompted, then run `/models` and select **Auto**.
-3. Ask Copilot to create a PR by using the following prompt:
+Report each script invocation and result, including failures, skipped checks, or missing prerequisites. Do not silently substitute direct npm commands for an unusable skill script. Identify the checkout and server under test, stop only servers you started, and ask before installing anything or stopping another process. Do not change application code, change branches, commit, push, or open a pull request.
+```
- ```
- Can you please create a pull request for me!
- ```
+Inspect the tool calls and output. All four scripts must actually execute; a description of the checks or a skipped check is not a pass. For the single-file example, compare the requested filename with the runner's actual file results and reported count: only that file should run. Echoed arguments or exit code 0 are insufficient if other files also ran. A failure is useful evidence: correct the skill or resolve the setup blocker with approval, then rerun the affected checks. Don't stop unrelated processes or force a port conflict away.
-4. Copilot will acknowledge the request. After a few moments, you'll notice Copilot will indicate it's utilizing the **make-contribution** skill.
-5. Copilot will then follow the instructions in the skill. It will start by running the tests, then create a branch, commits, and eventually the PR.
-6. Once the PR is created, return to your repository and open the PR. Note the sections follow the guidelines set forth in the skill, matching the requirements the team put forth.
-7. Before moving to the next exercise, reset your local workspace to a fresh branch from `main` so your accessibility work stays separate from this filtering PR:
+## Save a checkpoint
- ```bash
- git checkout main
- git pull
- git checkout -b accessibility-cli
- ```
+Once you have reviewed the skill and its results, authorize a local checkpoint:
-## Summary and next steps
+```plaintext
+Review the current diff and create a checkpoint commit for the quality-checks skill files only. Keep the existing filtering branch. Do not push or create a pull request.
+```
-With the help of an agent skill, you created a new PR which matches documented requirements! You:
+The skill files will accompany filtering, the QA profile, and associated tests in the feature PR in Exercise 8. Continue in this same checkout to [Exercise 6 - Validate functionality with Playwright MCP][next-lesson].
-- explored an existing skill for creating pull requests.
-- learned how skills are utilized by the AI agent.
-- created a PR which matches the guidelines with the help of the skill.
+## More skill examples
-Skills are perfect for tasks, but for more robust operations we want to take advantage of [custom agents][next-lesson], which we'll explore next!
+These community examples are references, not additional tasks. Review their prerequisites and behavior before adopting them:
-## Resources
+- [Contribution workflow: `make-repo-contribution`][contribution-example].
+- [Requirements documents: `prd`][prd-example].
+- [Diagrams and a bundled export script: `drawio`][drawio-example].
+- [Browser testing: `webapp-testing`][browser-example].
-- [About Agent Skills][about-agent-skills]
-- [Agent Skills Specification][agent-skills-spec]
-- [Agent Skills Repository][agent-skills-repo]
-- [Agent Skills on awesome-copilot][awesome-copilot-skills]
+The upstream contribution example is named `make-repo-contribution`; older Tailspin templates used a different name, `make-contribution`. This workshop does not depend on either contribution skill.
-[previous-lesson]: ../4-mcp/
-[next-lesson]: ../6-custom-agents/
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[awesome-copilot-skills]: https://github.com/github/awesome-copilot/tree/main/skills
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/cli/6-custom-agents.md b/docs/cli/6-custom-agents.md
deleted file mode 100644
index e7f81dce..00000000
--- a/docs/cli/6-custom-agents.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: "Exercise 6 - Custom agents with GitHub Copilot CLI"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-## What are custom agents?
-
-[Custom agents][custom-agents-concept] in GitHub Copilot allow you to create specialized AI assistants tailored to specific tasks or domains within your development workflow. By defining agents through markdown files in the `.github/agents` folder of your repository, you can provide Copilot with focused instructions, best practices, coding patterns, and domain-specific knowledge that guide it to perform particular types of work more effectively. Teams can codify their expertise into reusable agents — an accessibility agent that enforces [WCAG][wcag] compliance, a security agent that follows secure coding practices, or a testing agent that maintains consistent test patterns.
-
-Custom agents are defined by markdown files in the `.github/agents` folder of your project, or globally in `~/.copilot/agents`. Each file has YAML frontmatter with at least a `name` and `description`, followed by a markdown prompt that defines the agent's behavior, expertise, and instructions.
-
-### Custom agents compared with agent skills
-
-There's some logical overlap between custom agents and [agent skills][agent-skills-concept]. Both are primarily defined with markdown files and tell an AI how to perform operations. The cleanest way to separate them: a **custom agent** is the worker, and **skills** are tools.
-
-Custom agents have their own context window and are built to orchestrate skills (and even other agents) as part of doing their work. In this lab, the accessibility custom agent reviews and updates the site against accessibility guidelines; as part of that work it could call skills such as a pull-request workflow skill or one that runs and manages tests.
-
-> [!NOTE]
-> There's no single "right" way to author a custom agent. As with anything in AI, test and iterate to find what works for your environments and scenarios.
-
-## Scenario
-
-Many web applications fall short of being accessible to all users, and the website you're working in is no exception. You'll use a custom agent to identify and resolve accessibility shortcomings.
-
-Tailspin Toys is committed to ensuring their crowdfunding platform is accessible to all users, regardless of their visual abilities or preferences. Recent user feedback has highlighted that some users find the current dark theme difficult to read due to insufficient contrast between text and background colors. To address this accessibility concern, the design team has requested the implementation of a high-contrast mode that users can toggle on and off.
-
-Because accessibility is critical, you want to ensure this is implemented as quickly as possible. You're going to utilize a custom agent to generate the functionality.
-In this exercise, you will:
-
-- explore custom agents.
-- enable a custom agent and assign it a task using Copilot CLI.
-
-## Reviewing the accessibility custom agent
-
-A custom agent has already been created for you for accessibility. Let's review the contents to understand how it will guide Copilot.
-
-1. Open `.github/agents/accessibility.md`.
-2. Note the YAML frontmatter with the `name` and `description` fields.
-
-> [!CAUTION]
-> The frontmatter with `name` and `description` is required for custom agents.
-
-3. From there, scan and review the next sections which highlight:
- - Core responsibilities when generating code for an accessible website.
- - Best practices for accessibility.
- - Code examples for HTML, CSS, and JavaScript.
- - A list of common pitfalls and mistakes.
-## Using a custom agent in Copilot CLI
-
-You can start a custom agent in Copilot CLI by using the `/agent` command. Let's perform an accessibility pass on our website.
-
-1. Return to your codespace. If you closed it, navigate to your repository on GitHub.com, select **Code** > **Codespaces**, then reopen your existing codespace.
-2. Return to your open Copilot CLI session. If the terminal is closed or you exited Copilot CLI, open a terminal by selecting Ctrl+\`, then start it from the repository root by running `copilot --yolo --enable-all-github-mcp-tools`. Trust the project folder if prompted, then run `/models` and select **Auto**.
-3. Bring up the list of agents by typing `/agent` in the prompt window in Copilot CLI and selecting Enter.
-4. Select the **Accessibility agent** from the list of available agents.
-5. Use the following prompt to ask the accessibility agent to perform a review and generate fixes for the accessibility backlog item:
-
- ```
- Perform an accessibility review of the site. Pull the related issue down from the repository for details. Implement a high-contrast mode toggle that persists the user's preference across page reloads. Ensure there are e2e tests for any updates made to the project. Then create a PR with the updates.
- ```
-
-6. Copilot gets to work on the task! It will start by retrieving the issue, then performing the review, generating updates, and finally creating the PR. You should also notice when it creates the PR it utilizes the skill focused on PRs for the project.
-
-> [!NOTE]
-> This process will likely take a few minutes. It's a good time to reflect on everything you've learned, enjoy a beverage, or sneak ahead to the next module which talks about some additional commands available to you in Copilot CLI.
-
-## Summary and next steps
-
-This lesson explored [custom agents][custom-agents] in GitHub Copilot, specialized AI assistants tailored to specific tasks and domains. With custom agents you can codify your team's expertise and standards into reusable agents that guide Copilot to perform particular types of work more effectively.
-
-You explored these concepts:
-
-- how custom agents are defined.
-- using a custom agent in Copilot CLI.
-
-Next up, let's explore [some slash commands][next-lesson] to learn some additional tricks with Copilot CLI.
-
-## Resources
-
-- [Custom agents][custom-agents]
-- [Creating custom agents for a repository][creating-custom-agents]
-- [Custom agents on awesome-copilot][awesome-copilot-agents]
-- [Preparing to use custom agents in your organization][org-custom-agents]
-- [Preparing to use custom agents in your enterprise][enterprise-custom-agents]
-
-[previous-lesson]: ../5-agent-skills/
-[next-lesson]: ../7-slash-commands/
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[creating-custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/create-custom-agents
-[awesome-copilot-agents]: https://github.com/github/awesome-copilot/tree/main/agents
-[org-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-organization/prepare-for-custom-agents
-[enterprise-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/prepare-for-custom-agents
-[custom-agents-concept]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
-[agent-skills-concept]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[wcag]: https://www.w3.org/WAI/standards-guidelines/wcag/
diff --git a/docs/cli/6-mcp-playwright.md b/docs/cli/6-mcp-playwright.md
new file mode 100644
index 00000000..9384b9e9
--- /dev/null
+++ b/docs/cli/6-mcp-playwright.md
@@ -0,0 +1,83 @@
+---
+title: "Exercise 6 - Validate functionality with Playwright MCP"
+description: "Connect a browser through MCP and compare observed filtering behavior with the issue and approved plan."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Your filtering implementation and quality-checks skill already have automated verification. Now give Copilot a browser and ask it to observe the feature directly. This exercise demonstrates **Model Context Protocol (MCP)** interaction, not another full test-suite run.
+
+Stay in **Interactive** mode on the same filtering checkout and branch. MCP configuration does not start a new feature milestone.
+
+## What MCP adds
+
+[MCP][mcp-overview] connects an agent to external tools and context through servers. The built-in GitHub MCP server lets Copilot work with issues and PRs. The [Playwright MCP server][playwright-mcp] gives it browser tools for opening pages, inspecting accessible elements, navigating, and interacting with controls.
+
+The browser's accessibility snapshot helps the agent identify controls, but it does not prove complete accessibility compliance. Compare actual actions and observations with the issue's requirements rather than accept a generic “looks good.”
+
+> [!CAUTION]
+> Treat an MCP server like a project dependency: review the publisher, source, permissions, and any package download before enabling it. Organization policies may restrict which servers can run. Do not put credentials in committed configuration or approve unknown tools merely to finish the exercise.
+
+## Configure Playwright MCP
+
+1. In your existing CLI session, enter `/mcp` to inspect configured servers. Reuse a working Playwright configuration rather than add a duplicate.
+2. If needed, enter `/mcp add` and use Tab to move through the form.
+3. Set **Server Name** to `playwright`, **Server Type** to **STDIO** (or **Local**), and **Command** to `npx @playwright/mcp@latest --headless`.
+4. Set **Tools** to `*` for this reviewed browser server. This makes its tools available; it does not replace the CLI's permission controls.
+5. After reviewing the package and its startup command, press Ctrl+S to save. Registration starts the server and may download the package; approve that setup deliberately and respond to any package prompt.
+6. Enter `/mcp show playwright` and confirm that the server is connected and its browser tools are available.
+
+The headless browser does not need a desktop window, which suits Codespaces. The interactive add flow saves the configuration in `~/.copilot/mcp-config.json` and makes the server available without restarting the CLI. It is user configuration, not a file to include in the feature PR. The [MCP setup guide][mcp-setup] documents the fields and configuration sources.
+
+> [!NOTE]
+> Project E2E dependencies and the MCP browser are related but may require different setup. If a browser or system dependency is missing, inspect the actual error and resolve the specific prerequisite with approval. Do not automatically install browsers or assume a connected server proves it can launch one.
+
+## Start the correct app
+
+Open a separate terminal in this same filtering checkout. Confirm the directory and branch, then start the app:
+
+```bash
+pwd
+git branch --show-current
+npm run dev
+```
+
+Read the actual local URL from the server output. In the codespace, the MCP server and app run in the same environment, so use that local URL, usually `http://localhost:4321`, rather than assume a forwarded browser URL is required.
+
+If the port is occupied or Astro chooses another port, identify the server owner before proceeding. Do not reuse an unknown server or terminate it. Use the URL of the process you just started and keep that terminal open while testing.
+
+## Observe filtering behavior
+
+Replace the placeholders with the real issue URL, approved clarifications from Exercise 4, and the app URL:
+
+```plaintext
+Use the configured Playwright MCP server to validate the filtering feature against this issue: . These are the clarifications approved during planning: . The app for this checkout is running at . Confirm the checkout, branch, and server under test before relying on its results.
+
+Open the games page, note the unfiltered state, select one and then multiple categories, apply a publisher filter, and combine category and publisher selections. Exercise clearing and empty-result behavior according to the approved criteria. Check control labels, keyboard operation, and visible focus. Compare the displayed results with the selected filters and source data; do not infer success just because a control changed.
+
+Use actual browser tool actions and report what you observed for each criterion, with failures or missing evidence clearly marked. Do not run another full test suite solely for this browser exercise, change application code, create tests or customizations, change branches, commit, push, or open a PR. Ask before installing anything or stopping another process.
+```
+
+Inspect the browser tool calls and the report. Did Copilot really select multiple categories and combine them with a publisher? Do the returned games match the agreed behavior? Does the report distinguish observable browser behavior from data-layer and automated-test coverage?
+
+If something fails, record the observed behavior. Authorize any focused application fix separately, then repeat the affected browser checks and automated checks. Do not alter the acceptance criteria to match the implementation or count old evidence as verification of changed code.
+
+## Stop the owned server and continue
+
+Stop the development server with Ctrl+C in the terminal where you started it. Keep the Playwright MCP configuration available. Exercise 7 will coordinate fresh browser observations and automated E2E checks, which must not reuse a stale development server or another checkout's app.
+
+Stay **Interactive** before creating the QA profile. You've observed browser behavior without creating another PR or branch; next, [create and use a QA agent][next-lesson] to combine requirements, coverage, the skill, and final evidence.
+
+## Resources
+
+- [Adding MCP servers to Copilot CLI][mcp-setup] documents setup and management.
+- [Microsoft Playwright MCP][playwright-mcp] documents browser configuration and tools.
+- [GitHub MCP registry][mcp-registry] lists other servers to evaluate.
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-overview]: https://docs.github.com/copilot/concepts/context/mcp
+[mcp-setup]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
+[playwright-mcp]: https://github.com/microsoft/playwright-mcp
+[mcp-registry]: https://github.com/mcp
diff --git a/docs/cli/7-qa-agent.md b/docs/cli/7-qa-agent.md
new file mode 100644
index 00000000..45400f69
--- /dev/null
+++ b/docs/cli/7-qa-agent.md
@@ -0,0 +1,77 @@
+---
+title: "Exercise 7 - Create and use a QA agent"
+description: "Create a requirements-first QA profile that combines test coverage, the quality-checks skill, and direct browser evidence."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+You've run repeatable checks and explored filtering through Playwright MCP. Now create a **QA custom agent** to bring the requirements, coverage, and browser evidence together. Keep the filtering session, checkout, and branch; the feature PR comes in Exercise 8.
+
+## Create the QA profile
+
+Stay in **Interactive** mode. A profile defines a specialist's role and instructions; a skill packages reusable task instructions, scripts, and resources. The QA agent will use your skill and configured MCP tools rather than replace them.
+
+Send this prompt, then inspect the definition before running it:
+
+```plaintext
+Create a reusable QA custom agent in .github/agents/qa.agent.md. First inspect the repository instructions, package.json, test configuration, and .github/skills/quality-checks/SKILL.md. Give the profile valid YAML frontmatter with the name QA and a description explaining when to use it. Do not pin a model or add a tools list; inherit the harness's available tools and permissions. Create only the agent definition, then stop so I can inspect it before running it.
+
+In the agent's instructions, require every QA task to start from the issue and any approved acceptance criteria supplied by the user. Treat these requirements as the source of truth, not the implementation. Ask when requirements are missing or ambiguous. Inspect the feature and existing tests, and map each criterion to suitable automated coverage and observable behavior.
+
+Require direct browser validation through the configured Playwright MCP server and execution of lint, unit tests, end-to-end tests, and type checks through the existing quality-checks skill and its bundled scripts. Read the skill explicitly if it has not been automatically discovered. Report missing skills, MCP tools, prerequisites, or access as blocked; do not silently substitute another workflow or label skipped checks as passes. Identify the checkout and server under test, avoid reusing another worktree's server, stop only servers the agent started, and ask before any installation or stopping another process.
+
+Allow the QA agent to add the smallest necessary tests for genuine coverage gaps, following repository instructions; no additional tests is valid when coverage is already adequate. Do not weaken assertions, disable failing tests, change acceptance criteria to match the code, or modify application code without my approval. After changes, rerun affected checks and complete final verification of the resulting revision. Require a concise report mapping criteria to evidence and pass/fail/blocked status, listing tests added or explaining why none were needed, reporting all four check results, and identifying unresolved defects. GO requires all required checks and evidence; otherwise report NO-GO with the reason. Do not change branches, commit, push, open or merge PRs, or create additional agents or skills during QA.
+```
+
+## Inspect the profile
+
+Open `.github/agents/qa.agent.md` in your editor and inspect the diff. `description` is required; this exercise also supplies the readable `name` of `QA`. Confirm there is no pinned `model` or invented tool list. Omitting `tools` inherits available tools; it does not bypass harness permissions. Production profiles can restrict tools deliberately.
+
+Confirm the instructions start with requirements, require actual MCP browser activity and skill scripts, allow only justified test additions, and report blockers truthfully. Neither a specialist profile nor a skill requires a separate context window or orchestration of other agents.
+
+## Run QA against the issue
+
+The run prompt is for the selected **QA** custom agent, not the default agent reading a profile. Start a fresh CLI conversation in the same checkout to load the new profile without creating another feature branch.
+
+1. Retain the filtering issue URL and your approved clarifications. Wait for the current agent to finish, then enter `/exit` to return to the terminal.
+2. Confirm you are still in the filtering repository directory and on the same branch with `git branch --show-current` and `git status --short`. Do not switch branches or create a worktree.
+3. Launch the CLI with the repository profile:
+
+ ```shell
+ copilot --agent qa
+ ```
+
+4. Verify that the CLI identifies **QA** as the selected agent before running it. The [CLI command reference][cli-reference] documents `--agent`; writing or reading the profile alone is not activation. If selection fails or the agent cannot access the configured Playwright MCP tools and skill, pause and resolve that blocker with your facilitator.
+
+Replace both placeholders with the actual filtering issue URL and the clarifications approved in Exercise 4, or `none` when the issue is complete. Do not rely on the previous agent's memory.
+
+```plaintext
+Verify the filtering feature against this issue: . These are the additional acceptance criteria I approved during planning: .
+
+Validate behavior with the Playwright MCP server, inspect test coverage, add tests only for missing coverage, and run validation through the quality-checks skill. Report evidence, check results, and blockers. Do not change application code without my approval, create a commit, or open a pull request.
+```
+
+## Review the evidence
+
+Check the report against the issue: each criterion needs appropriate automated coverage and observable behavior. Inspect actual Playwright MCP tool activity, the checkout/server identity, and all four skill-script results. Browser checks and automated E2E must not reuse a stale server or another checkout.
+
+Review any added tests: they should close genuine gaps without weakening assertions. No new tests is correct when coverage is adequate. A blocked or failed **NO-GO** verdict is a valid outcome, not permission to skip evidence.
+
+If QA identifies an application defect, approve a focused fix separately and rerun affected checks and browser observations on the resulting revision. Missing prerequisites or tools need an explicit resolution. Do not treat older evidence as proof of changed code.
+
+## Save a checkpoint
+
+When QA has finished, retain its report with the issue URL, approved clarifications, tested revision, browser observations, and check results. Enter `/exit`, then launch `copilot` without `--agent` from the same directory and branch to return to a normal conversation. Provide that context again; the fresh conversation does not inherit the QA conversation's evidence.
+
+When you have reviewed the profile, any test changes, and the resulting evidence, send the following request to the normal agent:
+
+```plaintext
+Review the current diff and create a checkpoint commit for the QA agent definition and any approved test changes. Stay on the existing filtering branch. Do not push or open a pull request.
+```
+
+Continue to [Exercise 8 - Create and merge the feature PR][next-lesson] with the filtering feature, skill, QA profile, tests, and current verification evidence.
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/cli/7-slash-commands.md b/docs/cli/7-slash-commands.md
deleted file mode 100644
index 6f67591f..00000000
--- a/docs/cli/7-slash-commands.md
+++ /dev/null
@@ -1,161 +0,0 @@
----
-title: "Exercise 7 - Slash commands in GitHub Copilot CLI"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-Like any good CLI tool, GitHub Copilot CLI includes many slash commands to interact with it. These commands expose advanced functionality, "behind-the-scenes" information, or additional configuration options. You've already explored a couple with `/clear` to clear context and `/mcp` to inspect MCP servers. Let's explore a couple of other powerful ones, including `/context`, `/model`, `/share`, and `/delegate`.
-
-## Scenario
-
-You've wrapped the core CLI flows. Now let's look at a few additional capabilities — sharing sessions, switching models, and delegating tasks to [Copilot cloud agent][about-cloud-agent].
-
-In this exercise you will use:
-
-- `/share` to create a GitHub gist to share your session with the team.
-- `/context` to see the context Copilot CLI is currently using.
-- `/model` to explore the list of available models and select a new one if you so desire.
-- `/delegate` to optionally hand off a task to cloud agent. This requires cloud agent, available on Copilot Student, Pro, Pro+, Business, or Enterprise — every plan except Copilot Free.
-
-## Sharing a session
-
-Using any tool, including an AI tool, is a skill. Working together as a team, sharing learnings with each other, is the best way to help improve everyone's experience and generate higher quality code. To support this, Copilot CLI provides a `/share` command. The `/share` command can generate a markdown file or GitHub gist with the details of the session, including the prompts used and logic Copilot followed.
-
-Let's create a GitHub gist we could share with our team.
-
-1. Return to your codespace. If you closed it, navigate to your repository on GitHub.com, select **Code** > **Codespaces**, then reopen your existing codespace.
-2. Return to your open Copilot CLI session. If the terminal is closed or you exited Copilot CLI, open a terminal by selecting Ctrl+\`, then start it from the repository root by running `copilot --yolo --enable-all-github-mcp-tools`. Trust the project folder if prompted, then run `/model` and select **Auto**.
-3. In the prompt window for Copilot CLI, send the following command:
-
- ```
- /share gist
- ```
-
-4. In just a couple of moments, Copilot will create a gist and display the link.
-5. Copy the link text.
-6. In a new browser tab, paste the link to explore the gist. Note how the gist highlights the prompts sent, skills and agents used, Copilot's thought process, and even the code and results from locally run commands.
-
-The gists and markdown files generated by `/share` can be used for documentation purposes of how code was generated, or to share with your team about how certain actions were performed that generated the desired results from Copilot.
-
-## Exploring Copilot CLI's context
-
-When working on larger or more complex tasks you may bump into the maximum context window for the model. The exact size of the window will vary based on the model being used and the version of Copilot CLI. When the context window is maxed out, Copilot CLI will automatically compact it, summarizing information and removing anything it deems isn't relevant to the current task. You can both see the current state of the context and manually compact the context by using slash commands. Let's explore the context window.
-
-1. In the prompt window for Copilot CLI, send the following command:
-
- ```
- /context
- ```
-
-2. In just a couple of moments, Copilot CLI will generate a visual representation of its current context:
-
- 
-
-3. Note the model displayed (which may be different than the one in the image), and the current percentage of tokens used. The rest of the information highlights:
-
- | Title | Description |
- | ------------ | ------------------------------------------------------ |
- | System/Tools | Instructions files, file contents and tool definitions |
- | Messages | Conversation history between you and Copilot |
- | Buffer | Reserved space by Copilot CLI for generating responses |
- | Free space | Remaining free space |
-
-4. Compact the conversation history by sending the following slash command to Copilot CLI:
-
- ```
- /compact
- ```
-
-5. Once completed, send the following command to display the current context stats again:
-
- ```
- /context
- ```
-
-6. Note the change in context. There might not be a drastic change as the context window is likely relatively small at the moment.
-
-> [!NOTE]
-> Copilot CLI will automatically compact when it becomes full. As it approaches 100% capacity it will display the percentage just above the prompt window. Normally it will compact asynchronously, allowing you to continue interacting with Copilot while it does its work. It may however block a running operation for several seconds while performing its work.
-
-### Best practices with context
-
-In most sessions with Copilot context will be managed efficiently by Copilot itself without any specific guidance. However, there may be instances when you decide to manually instruct Copilot to either clear or compact its history:
-
-- If you are changing to a different part of the application, or to an unrelated task, you can use `/clear` to start new to avoid confusing Copilot with older, unrelated context.
-- If you are approaching the maximum context window, you can manually `/compact` your context to control when it happens.
-
-> [!CAUTION]
-> Again, the majority of the time, Copilot will manage its context without direct interaction from you. If you notice Copilot is a bit confused by older information, or are about to switch to an unrelated task, then you might consider using the manual commands.
-
-## Choosing your model
-
-Different models have different strengths, and different developers have different preferences. Copilot CLI allows you to list and select the model you wish to use!
-
-1. Display the list of models by sending the following slash command to Copilot CLI:
-
- ```
- /model
- ```
-
-2. Note the list of models. Each model will have both its name and cost-per-request modifier listed next to it.
-3. If you wish, select a new model! Or select Esc to exit the model list.
-
-> [!CAUTION]
-> Model selection persists in Copilot CLI.
-
-## Delegating to cloud agent (optional)
-
-There are times when you want to keep working in your terminal but hand off a longer-running task to Copilot cloud agent. The `/delegate` command sends the current Copilot CLI session to GitHub.com, where cloud agent picks it up, works asynchronously, and opens a pull request when done.
-
-> [!NOTE]
-> `/delegate` requires cloud agent, available on Copilot Student, Pro, Pro+, Business, or Enterprise — every plan except Copilot Free. If you don't have access, read through this section and skip the hands-on steps.
-
-1. Clear the current session first so accumulated workshop context isn't delegated:
-
- ```
- /clear
- ```
-
-2. Send a small, well-scoped prompt. For example, you could delegate the stretch-goal pagination from your backlog:
-
- ```
- Implement pagination on the game list page so it shows a fixed number of games per page with Previous and Next controls, and add tests.
- ```
-
-3. Send the following slash command to hand the session to cloud agent, and confirm the prompt you want to delegate:
-
- ```
- /delegate
- ```
-
-4. Open [Copilot agents](https://github.com/copilot/agents) in a browser to monitor progress.
-5. You don't need to wait for the pull request to complete in this harness; you can return to it later. If you want to dig deeper into managing asynchronous agent work, continue with the [Cloud agent harness](../../cloud/).
-
-## Summary and next steps
-
-Using slash commands in Copilot CLI allows you to configure it, share sessions, and get internal information about how Copilot's working. In this lesson you used or explored:
-
-- `/share` to create a GitHub gist to share your session with the team.
-- `/context` to see the context Copilot CLI is currently using.
-- `/model` to explore the list of available models and select a new one if you so desire.
-- Learned about `/delegate` as an optional bridge to cloud agent.
-
-There are of course more slash commands available, and more to explore with Copilot CLI! Let's close out our journey by [reviewing what we've learned][next-lesson] and some next steps to continue learning.
-
-## Resources
-
-- [Using Copilot CLI][using-copilot-cli]
-- [About Copilot CLI][about-copilot-cli]
-- [Context Management in Copilot CLI][context-management]
-- [Share Sessions with Copilot CLI][share-sessions]
-- [Selecting Models in Copilot CLI][selecting-models]
-
-[previous-lesson]: ../6-custom-agents/
-[next-lesson]: ../8-review/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[about-cloud-agent]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
-[share-sessions]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#share-sessions
-[selecting-models]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#select-an-llm
diff --git a/docs/cli/8-create-pull-request.md b/docs/cli/8-create-pull-request.md
new file mode 100644
index 00000000..d3e227f6
--- /dev/null
+++ b/docs/cli/8-create-pull-request.md
@@ -0,0 +1,99 @@
+---
+title: "Exercise 8 - Create and merge the feature PR"
+description: "Review the full filtering milestone, reuse current QA evidence, and merge the third pull request after CI and review."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Now bring the filtering milestone together in PR 3. Stay on the branch and checkout used in Exercises 4–7. It contains the filtering implementation, quality-checks skill and scripts, QA profile, and associated tests.
+
+This is a normal scoped PR request using the repository's conventions. It does not require a contribution skill.
+
+> [!NOTE]
+> A production team might separate a feature from reusable quality infrastructure. This workshop combines them deliberately to show the complete workflow in one feature PR. The earlier star-rating and instructions PRs should already be merged into `main`, not appear again as unrelated work.
+
+## Check readiness and evidence
+
+1. Review the QA verdict and its requirement-to-evidence mapping. A **NO-GO**, missing browser evidence, or skipped required check is a blocker to resolve before merging.
+2. Confirm all four checks actually ran through the quality-checks skill: lint, unit tests, E2E, and type checks.
+3. Review the tested revision and any changes since those checks. Reuse the current QA evidence only while the tested code, tests, and verification scripts remain unchanged. A checkpoint commit alone does not invalidate identical file contents, but code changes do.
+4. If the implementation or tested inputs changed, run the relevant skill checks and browser observations again and update the evidence. Do not rerun the entire suite solely because you are opening a PR when current QA results still apply.
+5. Inspect the full branch diff, not just the latest checkpoint or uncommitted changes.
+
+From another terminal in the same checkout:
+
+```bash
+git status
+git fetch origin
+git log --oneline origin/main..HEAD
+git diff --stat origin/main...HEAD
+git --no-pager diff origin/main...HEAD
+```
+
+The three-dot diff shows this branch's changes since its common ancestor with `origin/main`, including earlier checkpoints. Verify it includes only the intended filtering milestone. Inspect new files too; unexpected untracked or uncommitted files must be reviewed before staging.
+
+## Request PR 3
+
+Exercise 7 returned you to a normal **Interactive** session before the checkpoint. Continue in that established session if the QA profile is no longer active and the filtering checkout and branch are unchanged. Keep the issue URL, approved planning clarifications, and current QA report, including the tested revision and check results, available.
+
+The QA profile prohibits commit and PR actions during QA. If it is still active, return to a normal session before requesting the PR:
+
+1. Wait until QA is idle, then enter `/exit` at its CLI prompt. If the CLI remains open because another session is active, finish or preserve that work before returning to the normal prompt and pressing Ctrl+D to shut down this CLI instance.
+2. At the shell prompt, stay in the same filtering checkout and branch. Confirm their identity, then start a fresh normal session without `--agent qa` or a resume flag:
+
+ ```bash
+ pwd
+ git branch --show-current
+ git status
+ copilot
+ ```
+
+3. Confirm you are in **Interactive** mode and the QA profile is no longer active. Do not create another worktree, change branches, or resume the QA session.
+
+Replace all placeholders below with the real issue URL, approved clarifications, and current QA evidence. Supply them explicitly even if you stayed in the normal session from Exercise 7; a fresh conversation must not rely on the QA session's memory.
+
+```plaintext
+Prepare the filtering feature PR for this issue: . These are the additional acceptance criteria I approved during planning: . This is the current QA evidence: .
+
+Confirm the checkout and current filtering branch. Inspect the full diff against main, all milestone checkpoint commits, git status, the repository PR template, and the supplied QA evidence. Include only the reviewed filtering implementation, quality-checks skill and bundled scripts, QA agent definition, and associated tests.
+
+Reuse the QA results while they still describe the final file contents. If code, tests, or verification scripts changed afterward, report that and run the relevant checks through the skill and affected browser validation before presenting them as current. Do not label failed, blocked, or skipped checks as passes.
+
+Commit any remaining reviewed milestone changes if needed, push this current branch, and create one PR into main following the repository conventions. Include the issue and approved criteria, implementation summary, tests added or why none were needed, browser observations, all four check results, and remaining limitations. Do not merge, create another branch, invoke a contribution skill, or start another feature.
+```
+
+## Review the PR and CI
+
+Open the returned URL and inspect **Files changed** across the entire PR. Check that the skill's scripts and QA profile are included, and that no credentials, local MCP configuration, unrelated files, generated reports, or dependency installs slipped into the diff.
+
+Use the PR's **Checks** tab, or run these commands in the terminal on the feature branch:
+
+```bash
+gh pr view
+gh pr diff
+gh pr checks --watch
+```
+
+Inspect your repository's `.github/workflows/` rather than assume a green badge covers every kind of verification. The current Tailspin **Run tests** workflow runs lint, type checks, Vitest unit tests, and Playwright E2E tests against the built static site. It does not substitute for the direct MCP browser observations in your QA report. The workshop site's Astro build and link checks validate a different repository.
+
+If a check fails, inspect its logs and address the cause. A focused fix must be reviewed and reverified on the updated revision before pushing. If `main` changes and resolving a conflict changes the feature, refresh the affected evidence too. Wait for any required human review; an agent's own approval does not override branch protection.
+
+## Merge and update local main
+
+When the PR meets all review and check requirements, explicitly choose **Merge pull request** on GitHub and confirm the merge. Verify PR 3 is **Merged**.
+
+Exit the CLI session with `/exit`. With a clean working tree, update the local checkout:
+
+```bash
+git status
+git switch main
+git pull --ff-only
+```
+
+No new branch is needed for the next exercise. You have now merged exactly three workshop PRs: star ratings; instructions and a demonstration; filtering with the quality skill, QA profile, and tests.
+
+Continue to [Exercise 9 - Explore slash commands and CLI options][next-lesson] for a bounded tour of CLI controls, not another implementation task.
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-slash-commands/
diff --git a/docs/cli/8-review.md b/docs/cli/8-review.md
deleted file mode 100644
index c85138c5..00000000
--- a/docs/cli/8-review.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: "Exercise 8 - Review and Next Steps"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-Over the last several exercises, you explored some of the most common use cases for GitHub Copilot CLI, including:
-
-- interacting with GitHub and other MCP servers.
-- using instructions files to guide code generation.
-- implementing skills to add tools to the Copilot CLI toolbox.
-- calling custom agents for advanced and more complex tasks.
-- using slash commands to manage your session, and optionally bridging back to cloud agent via `/delegate`.
-
-Let's talk about some slash commands, best practices, and next steps.
-
-## Slash commands
-
-Copilot CLI has a series of slash commands available to interact with it, including ones which allow you to configure it or see what's going on behind the scenes. You've already used `/clear` to start a new chat which clears the current context, and `/mcp` to inspect and manage MCP servers. Some additional ones you might find helpful are:
-
-| Command | Description |
-| ------------------ | ------------------------------------------------------------- |
-| `/add-dir` | Add a directory to the trusted list for Copilot |
-| `/clear`, `/new` | Clear the conversation history and start fresh |
-| `/compact` | Summarize conversation history to reduce context window usage |
-| `/context` | Show context window token usage and visualization |
-| `/diff` | Review the changes made in the current directory |
-| `/model` | Select AI model to use (Claude Sonnet, GPT-5, etc.) |
-| `/plan ` | Create an implementation plan before coding |
-| `/review ` | Run code review agent to analyze changes |
-| `/delegate` | Delegate task to Copilot cloud agent for async processing |
-| `/session` | Show session info and workspace summary |
-| `/share` | Share session to markdown file or GitHub gist |
-| `/skills` | Manage skills for enhanced capabilities |
-| `/usage` | Display session usage metrics and statistics |
-
-> [!TIP]
-> Use `/help` to see the full list of available commands and keyboard shortcuts.
-
-## Best practices
-
-When using any AI tool, the underlying infrastructure drives the quality of what you get out. Robust instructions files, custom agents, and agent skills all play a part — you explored each of them in this workshop. [awesome-copilot][awesome-copilot] is a good source of templates, and Copilot itself can scaffold these for you as a starting point.
-
-Context still matters as much as infrastructure. Clearly describing *what* you want built, *why*, and *how* meaningfully changes the output. If a piece of information would help Copilot, pass it along.
-
-## Next steps
-
-The best way to improve your skills with any tool is to keep using the tool! Use it for production code, for hobby code, for the little app you've had in your mind for years but never got around to building. Share your learnings with your team, and learn from your team. And, as always, explore the documentation.
-
-If you'd like to explore more of the GitHub Copilot ecosystem, check out the [VS Code harness](../../vscode/) or the [Cloud agent harness](../../cloud/).
-
-## Resources
-
-- [About Copilot CLI][about-copilot-cli]
-- [Using Copilot CLI][using-copilot-cli]
-- [Awesome Copilot Repository][awesome-copilot]
-- [Custom Instructions Guide][repo-instructions]
-- [Agent Skills Documentation][agent-skills]
-- [Custom Agents Documentation][custom-agents]
-- [MCP Specification][mcp-spec]
-
-[previous-lesson]: ../7-slash-commands/
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[repo-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
-[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[mcp-spec]: https://modelcontextprotocol.io/
diff --git a/docs/cli/9-slash-commands.md b/docs/cli/9-slash-commands.md
new file mode 100644
index 00000000..d15ca980
--- /dev/null
+++ b/docs/cli/9-slash-commands.md
@@ -0,0 +1,88 @@
+---
+title: "Exercise 9 - Explore slash commands and CLI options"
+description: "Inspect context, model and session controls, review sharing destinations, and explore CLI flags without launching another feature."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+The three PR milestones are complete. Now explore the CLI controls that help you understand and manage a session. This exercise does not implement another feature, delegate work, or open another PR.
+
+From the updated learner checkout, start `copilot` in **Interactive** mode. Use `/help` and the [command reference][cli-reference] to confirm which commands your installed version supports; current documentation can describe newer controls than your installation.
+
+## Inspect context and session information
+
+1. Send a bounded, read-only request:
+
+ ```plaintext
+ Summarize the repository's instruction files, quality-checks skill, and QA profile. Explain how they support filtering verification. Do not modify files, execute checks, delegate work, commit, or open a PR.
+ ```
+
+2. Enter `/context` to inspect context-window usage. Notice how messages, instructions, and tool definitions consume context.
+3. Enter `/compact`, then `/context` again. Compaction summarizes history to reduce its size; a short session may show little change.
+4. Enter `/session` to inspect the current session, and `/usage` to inspect usage information.
+
+Compaction is not a substitute for supplying requirements. When changing tasks or agents, carry forward the issue URL, approved criteria, checkout identity, and relevant evidence explicitly.
+
+`/clear` starts a new conversation; it does not undo files or switch Git branches. `/resume` opens the session picker for returning to prior work. Explore the picker, then press Esc to leave it without resuming another task. Do not clear the only copy of acceptance criteria or assume a resumed conversation means its old verification is still current.
+
+## Inspect models and modes
+
+Enter `/model` to inspect models available to your account, including **Auto** where offered. Read the selection details and usage information; model availability and pricing can change. Press Esc to leave the picker without changing the model. If you do change it, confirm the displayed selection and the scope your CLI version applies.
+
+Use Shift+Tab to inspect the mode indicator as you cycle between **Interactive**, **Plan**, and **Autopilot**, then return to **Interactive** without sending an implementation prompt. Recall the distinction:
+
+- Plan is for agreeing the work before coding.
+- Autopilot continues through an approved, bounded task.
+- Interactive gives you deliberate review and decision points.
+- Permissions separately control which tool actions are allowed.
+
+## Inspect command-line options
+
+In a separate terminal, run:
+
+```bash
+copilot --help
+```
+
+Compare these documented options with the help for your installed version:
+
+| Option | Purpose |
+| --- | --- |
+| `--model MODEL` | Choose the model for an invocation; confirm availability first |
+| `--agent AGENT` | Select a custom agent for an invocation |
+| `-p PROMPT` | Run a prompt programmatically and exit when it completes |
+| `--output-format json` | Emit structured JSONL output, one JSON object per line |
+| `--resume` | Resume an existing session |
+| `--enable-all-github-mcp-tools` | Expose the full built-in GitHub MCP tool set |
+
+These are controls to understand, not another task to launch. Programmatic mode can execute real tool actions; a JSON output format does not make a request read-only. Agent selection is the verified workflow from [Exercise 7][qa-lesson], not a reason to replace custom-agent activation with a default-agent request to read the profile. Permissions and access still apply.
+
+## Review before sharing
+
+`/share` can send session content to different destinations. The [CLI command reference][cli-reference] documents `/share file [session|research] [PATH]` for Markdown export and `/share gist [session|research]` for gist publishing. With no subcommand, the current documented behavior creates a shareable GitHub link when logged in and synced, falling back to a Markdown export otherwise. Do not run the bare command while assuming it only previews content.
+
+For this workshop, explicitly select a local session export and filename rather than publishing:
+
+```text
+/share file session cli-session-review.md
+```
+
+Open the exported file in your editor and inspect what it actually contains. Review prompts, responses, tool output, file paths, repository data, and any credentials or personal information. Do not assume the export contains every internal step or that it has automatically removed sensitive content.
+
+> [!CAUTION]
+> A gist or shared link is an external disclosure. A secret gist is not private access control: anyone with its URL can view it. Confirm the destination, recipients, permissions, and your organization's policy before sharing. If redaction is needed, share only the reviewed, redacted artifact through an approved channel; do not publish the original session afterward.
+
+Keep this export out of the feature PR and repository history. After inspecting it, remove the file you just generated or move it to your approved local notes location. Do not remove unrelated files.
+
+Cloud delegation can create remote work and an additional PR, so do not run `/delegate` here. The [Cloud agent workshop][cloud-workshop] covers that separate workflow.
+
+## Summary and next steps
+
+You've inspected context, usage, model and mode controls, command-line options, and sharing destinations without starting another feature. Continue to [Exercise 10 - Wrap-up and next steps][next-lesson] to review the workflow and artifacts you've built.
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[qa-lesson]: ../7-qa-agent/
+[cloud-workshop]: ../../cloud/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/cli/README.md b/docs/cli/README.md
index 2ca8e6f9..76d55135 100644
--- a/docs/cli/README.md
+++ b/docs/cli/README.md
@@ -3,12 +3,12 @@ slug: cli
title: "GitHub Copilot CLI"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
**[GitHub Copilot CLI](https://docs.github.com/copilot/concepts/agents/about-copilot-cli)** puts GitHub Copilot in your terminal as an agentic coding assistant. It explores codebases, generates code, runs commands, and connects to external tools — all from the command line, so you can stay in the flow without switching to a graphical editor.
-Across these exercises you'll install and authenticate Copilot CLI, then give it project context with custom instructions before using plan mode to generate a feature deliberately. You'll connect the Playwright MCP server to test that feature in a real browser, then extend Copilot with reusable agent skills and custom agents. Finally, you'll explore slash commands for managing context, models, and sharing, and wrap up with a review of what you've built.
+After setup in Exercises 0–1, you'll complete nine core modules in Exercises 2–10. Start with a star-rating quick win, establish documentation instructions, and build filtering with **Plan** and **Autopilot** modes. Then create a reusable quality-checks skill, validate behavior with Playwright MCP, create a QA agent, and ship the feature. Finish by exploring CLI controls and reviewing what you've built.
## Exercises
@@ -16,13 +16,21 @@ Across these exercises you'll install and authenticate Copilot CLI, then give it
|----------|-------|-------------|
| [0. Prerequisites][ex0] | Setup | Create your repository and codespace |
| [1. Installing Copilot CLI][ex1] | Installation | Install and authenticate Copilot CLI |
-| [2. Custom instructions][ex2] | Context | Add an instruction and see how Copilot CLI follows it |
-| [3. Generating Code][ex3] | Code Generation | Use plan mode and generate features |
-| [4. Testing with Playwright MCP][ex4] | External Tools | Add the Playwright MCP server and test your feature in a browser |
-| [5. Agent Skills][ex5] | Skills | Enhance Copilot with specialized skills |
-| [6. Custom Agents][ex6] | Agents | Review and use custom agents |
-| [7. Slash Commands][ex7] | CLI Features | Explore context, models, sharing, and optional delegation to cloud agent |
-| [8. Review][ex8] | Summary | Review key concepts and next steps |
+| [2. Add star ratings: a quick win][ex2] | First change | Display existing ratings, validate, and merge PR 1 |
+| [3. Guide Copilot with custom instructions][ex3] | Context | Add a documentation convention, demonstrate it, and merge PR 2 |
+| [4. Build filtering with Plan and Autopilot][ex4] | Implementation | Review a plan, approve Autopilot, test, and checkpoint |
+| [5. Create and use a quality-checks skill][ex5] | Skills | Generate, inspect, and run shell-bundled checks |
+| [6. Validate functionality with Playwright MCP][ex6] | Browser tools | Observe filtering behavior in a real browser |
+| [7. Create and use a QA agent][ex7] | Agents | Audit requirements and coverage, then collect final evidence |
+| [8. Create and merge the feature PR][ex8] | Delivery | Review filtering and reusable customizations together in PR 3 |
+| [9. Explore slash commands and CLI options][ex9] | CLI controls | Inspect context, models, sessions, and sharing destinations |
+| [10. Wrap-up and next steps][ex10] | Summary | Review common artifacts and the three PR milestones |
+
+## Branches and pull requests
+
+You'll merge three pull requests: star ratings; instructions and a small demonstration; then filtering with the quality-checks skill, QA profile, and associated tests. Merge each of the first two PRs before starting the next milestone from updated `main`.
+
+Exercises 4–8 share one feature branch and checkout. Save checkpoint commits along the way; skill creation, MCP setup, and QA selection do not start new feature branches. Exercise 9 explores controls without launching another feature or PR.
## Prerequisites
@@ -44,11 +52,13 @@ Before attending this workshop, please ensure you have:
[ex0]: 0-prerequisites/
[ex1]: 1-install-copilot-cli/
-[ex2]: 2-custom-instructions/
-[ex3]: 3-generating-code/
-[ex4]: 4-mcp/
+[ex2]: 2-add-star-rating/
+[ex3]: 3-custom-instructions/
+[ex4]: 4-build-filtering/
[ex5]: 5-agent-skills/
-[ex6]: 6-custom-agents/
-[ex7]: 7-slash-commands/
-[ex8]: 8-review/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-slash-commands/
+[ex10]: 10-review/
[callout-student-plan-education]: https://github.com/education/students
diff --git a/docs/cloud/3-custom-agents.md b/docs/cloud/3-custom-agents.md
index cda3be2a..95e2ea0e 100644
--- a/docs/cloud/3-custom-agents.md
+++ b/docs/cloud/3-custom-agents.md
@@ -9,13 +9,13 @@ lastUpdated: 2026-06-30
[Custom agents][custom-agents-concept] in GitHub Copilot allow you to create specialized AI assistants tailored to specific tasks or domains within your development workflow. By defining agents through markdown files in the `.github/agents` folder of your repository, you can provide Copilot with focused instructions, best practices, coding patterns, and domain-specific knowledge that guide it to perform particular types of work more effectively. Teams can codify their expertise into reusable agents — an accessibility agent that enforces [WCAG][wcag] compliance, a security agent that follows secure coding practices, or a testing agent that maintains consistent test patterns.
-Custom agents are defined by markdown files in the `.github/agents` folder of your project, or globally in `~/.copilot/agents`. Each file has YAML frontmatter with at least a `name` and `description`, followed by a markdown prompt that defines the agent's behavior, expertise, and instructions.
+Repository custom agents are defined by `.agent.md` files in the `.github/agents` folder. Each file has YAML frontmatter with a required `description`, followed by a Markdown prompt that defines the agent's behavior, expertise, and instructions. This exercise also supplies an optional, readable `name` so you can recognize the agent in the picker.
### Custom agents compared with agent skills
-There's some logical overlap between custom agents and [agent skills][agent-skills-concept]. Both are primarily defined with markdown files and tell an AI how to perform operations. The cleanest way to separate them: a **custom agent** is the worker, and **skills** are tools.
+There's some logical overlap between custom agents and [agent skills][agent-skills-concept]. A **custom agent** defines a specialized role, instructions, and available tools. A **skill** packages task-specific instructions and can include scripts and supporting resources.
-Custom agents have their own context window and are built to orchestrate skills (and even other agents) as part of doing their work. In this lab, the accessibility custom agent reviews and updates the site against accessibility guidelines; as part of that work it could call skills such as a pull-request workflow skill or one that runs and manages tests.
+Agents can run scripts directly through available tools, or follow a skill when one is available. Selecting a custom agent does not inherently create a separate context window or require orchestration of other agents. In this lab, you'll create an accessibility profile and use the project's existing npm checks directly; no skill from another workshop harness is required.
> [!NOTE]
> There's no single "right" way to author a custom agent. As with anything in AI, test and iterate to find what works for your environments and scenarios.
@@ -25,7 +25,7 @@ Custom agents have their own context window and are built to orchestrate skills
[wcag]: https://www.w3.org/WAI/standards-guidelines/wcag/
You'll explore the following with custom agents:
-- how custom agents are defined.
+- creating and reviewing a custom-agent profile.
- assigning a task to a custom agent.
## Scenario
@@ -33,23 +33,37 @@ You'll explore the following with custom agents:
Tailspin Toys is committed to ensuring their crowdfunding platform is accessible to all users, regardless of their visual abilities or preferences. Recent user feedback has highlighted that some users find the current dark theme difficult to read due to insufficient contrast between text and background colors. To address this accessibility concern, the design team has requested the implementation of a high-contrast mode that users can toggle on and off.
Because accessibility is critical, you want to ensure this is implemented as quickly as possible. You're going to utilize a custom agent to generate the functionality.
-## Reviewing the accessibility custom agent
+## Creating and reviewing the accessibility custom agent
-A custom agent has already been created for you for accessibility. Let's review the contents to understand how it will guide Copilot.
+The template does not supply custom agents or skills. Before assigning the high-contrast issue, create an accessibility profile using GitHub's [custom-agent creation flow][creating-custom-agents]. The profile must reach your repository's **default branch** before you select it for an issue.
-Return to your codespace, then review the accessibility custom agent file:
+1. Open the [Copilot agents page][agents-page] and select your Tailspin Toys repository in the prompt box's repository dropdown.
+2. Select your repository's default branch (`main` for this workshop).
+3. Open **Select a custom agent**, then select **Create an agent**. GitHub opens a template at `.github/agents/my-agent.agent.md` in its file editor.
+4. Rename the file to `.github/agents/accessibility.agent.md`. Replace the template with this profile:
-1. Open `.github/agents/accessibility.md`.
-2. Note the YAML frontmatter with the `name` and `description` fields.
+ ```markdown
+ ---
+ name: Accessibility agent
+ description: Implement and review accessible Astro UI changes, including contrast, keyboard access, and user preference controls.
+ ---
-> [!CAUTION]
-> The frontmatter with `name` and `description` is required for custom agents.
+ Follow the user's requirements and repository instructions. Inspect existing components, styles, package.json, and tests before making focused accessibility changes.
+
+ Use semantic HTML, keyboard-accessible controls, visible focus, accessible names and states, and WCAG contrast guidance. Preserve existing behavior and persist user preferences when requested.
+
+ Add or update relevant tests. Run npm run lint, npm run test:unit, npm run test:e2e, and npm run typecheck:all directly using the existing project setup. Do not depend on supplied agents or skills.
+
+ Report changes and evidence, with accurate pass/fail/blocked check results. Distinguish automated checks from browser observations and identify any accessibility checks not performed. Report missing prerequisites or access rather than claiming success.
+ ```
+
+5. Review the profile against the repository's instructions and existing npm scripts. Confirm it guides accessibility work without prescribing an unrelated feature. `description` is required; `name` is optional but intentionally supplied here. Omitting `tools` makes the available tools accessible within the cloud agent's normal permissions.
+6. Save the reviewed profile to the default branch. Commit directly **only if** your permissions and branch rules allow it. Otherwise commit on a setup branch, open a pull request, review it, and merge it into the default branch before continuing.
+7. Open `.github/agents/accessibility.agent.md` on the default branch and confirm the reviewed contents are present. Return to the agents page, refresh it if needed, and confirm **Accessibility agent** appears in the custom-agent dropdown.
+
+> [!IMPORTANT]
+> A profile that exists only in an unmerged branch is not ready for this issue-assignment flow. If you cannot merge it or select it, resolve that access or discovery blocker before assigning the issue. Asking the default agent to read the profile is not a substitute for selecting the custom agent.
-3. From there, scan and review the next sections which highlight:
- - Core responsibilities when generating code for an accessible website.
- - Best practices for accessibility.
- - Code examples for HTML, CSS, and JavaScript.
- - A list of common pitfalls and mistakes.
## Create and assign an issue
Mission control is the central location for working with all agents for your environment. You can assign tasks to Copilot cloud agent, monitor tasks, and even redirect and provide additional guidance. Let's start by assigning a task to create the high contrast mode to Copilot.
@@ -67,12 +81,12 @@ Mission control is the central location for working with all agents for your env
7. Select **Create** to create the issue.
8. On the right side, select **Assign to Copilot** to open the assignment dialog.
-9. Select **Accessibility agent** from the list of custom agents.
+9. Select **Accessibility agent** from the custom-agent dropdown and confirm that it is the selected agent in the assignment dialog before proceeding.
10. Select **Assign**.
-11. Copilot gets to work on the task in the background!
+11. Copilot gets to work on the task in the background! When its pull request appears, check the description for the custom agent used and confirm it names your accessibility agent.
## Summary and next steps
@@ -80,7 +94,7 @@ This lesson explored [custom agents][custom-agents] in GitHub Copilot, specializ
You explored these concepts:
-- how custom agents are defined.
+- creating, reviewing, and publishing a custom-agent profile to the default branch before assignment.
- assigning a task to a custom agent.
With Copilot working on implementing the high contrast mode, we can now turn our attention to [monitoring and steering the agent session][next-lesson] from mission control.
@@ -88,6 +102,8 @@ With Copilot working on implementing the high contrast mode, we can now turn our
## Resources
- [About custom agents][custom-agents]
+- [Creating custom agents for Copilot cloud agent][creating-custom-agents]
+- [Custom agents configuration][custom-agents-config]
- [Preparing to use custom agents in your organization][org-custom-agents]
- [Preparing to use custom agents in your enterprise][enterprise-custom-agents]
@@ -99,5 +115,8 @@ With Copilot working on implementing the high contrast mode, we can now turn our
[previous-lesson]: ../2-cloud-agent/
[next-lesson]: ../4-managing-agents/
[custom-agents]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
+[creating-custom-agents]: https://docs.github.com/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/create-custom-agents
+[custom-agents-config]: https://docs.github.com/copilot/reference/custom-agents-configuration
+[agents-page]: https://github.com/copilot/agents
[org-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-organization/prepare-for-custom-agents
[enterprise-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/prepare-for-custom-agents
diff --git a/docs/cloud/5-iterating.md b/docs/cloud/5-iterating.md
index d2793824..203bb078 100644
--- a/docs/cloud/5-iterating.md
+++ b/docs/cloud/5-iterating.md
@@ -98,7 +98,7 @@ Copilot has built the related games feature! Just as before, you can work iterat
## Review the accessibility features
-Finally, let's review the accessibility features that were implemented using the custom accessibility agent. This PR should include both the high-contrast mode you assigned in Exercise 3, and the light mode that was requested in mission control in Exercise 4.
+Finally, let's review the accessibility features that were implemented using the custom accessibility agent. The profile was added to the default branch before assignment in Exercise 3; this feature PR should include both the high-contrast mode assigned there and the light mode requested in mission control in Exercise 4. Confirm the PR description identifies the accessibility agent, and review its reported npm check results rather than treating agent selection alone as verification.
1. Return to your repository in GitHub.com.
2. Select the **Pull Requests** tab.
diff --git a/docs/cloud/README.md b/docs/cloud/README.md
index faeea7f4..c9d77e28 100644
--- a/docs/cloud/README.md
+++ b/docs/cloud/README.md
@@ -8,7 +8,7 @@ lastUpdated: 2026-06-30
**[GitHub Copilot cloud agent](https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent)** lets GitHub Copilot work asynchronously in the cloud. You assign work on GitHub, and the cloud agent picks it up in the background — exploring the repository, making changes, and opening a pull request — while you stay free to do other things.
-Across these exercises you'll add custom instructions the cloud agent will follow, then assign a GitHub issue and let it implement the work. You'll review and use custom agents to shape its approach, monitor and steer sessions from the agents dashboard, and finish by reviewing its pull requests and iterating on the results.
+Across these exercises you'll add custom instructions the cloud agent will follow, then assign a GitHub issue and let it implement the work. You'll create and review an accessibility custom agent, publish its profile to the default branch before assignment, monitor and steer sessions from the agents dashboard, and finish by reviewing its pull requests and iterating on the results.
## Exercises
@@ -17,7 +17,7 @@ Across these exercises you'll add custom instructions the cloud agent will follo
| [0. Prerequisites][ex0] | Setup | Create your repository and codespace |
| [1. Custom instructions][ex1] | Context | Add custom instructions cloud agent will follow |
| [2. Cloud Agent][ex2] | Async Agent | Assign issues to Copilot cloud agent |
-| [3. Custom Agents][ex3] | Specialized Agents | Review and use custom agents |
+| [3. Custom Agents][ex3] | Specialized Agents | Create, review, and use a custom agent |
| [4. Managing Agents][ex4] | Monitoring | Monitor and steer agent sessions |
| [5. Iterating][ex5] | Review | Review PRs, iterate on Copilot's work, and choose next steps |
diff --git a/docs/es-es/README.md b/docs/es-es/README.md
index c57d5067..e6fa03a4 100644
--- a/docs/es-es/README.md
+++ b/docs/es-es/README.md
@@ -3,7 +3,7 @@ slug: es-es
title: "Manos a la obra con los agentes de GitHub Copilot"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
Las recientes ampliaciones de las capacidades de GitHub Copilot ofrecen a los desarrolladores herramientas potentes para todo el ciclo de vida del desarrollo de software (SDLC). Estas capacidades incluyen trabajar con incidencias y solicitudes de incorporación de cambios en GitHub, interactuar con servicios externos y, por supuesto, crear código. En este laboratorio se exploran estas funciones mediante casos de uso reales y consejos para aprovechar al máximo las herramientas.
@@ -17,19 +17,19 @@ Las recientes ampliaciones de las capacidades de GitHub Copilot ofrecen a los de
GitHub Copilot te acompaña allí donde trabajes. Elige el entorno que se ajuste a tu forma de desarrollar y completa sus ejercicios con el trabajo pendiente compartido de Tailspin Toys. Cada entorno comienza con su propia configuración para que puedas empezar directamente con el que elijas.
-### 🖥️ [VS Code](../vscode/)
+### 🖥️ [VS Code](vscode/)
GitHub Copilot dentro de **Visual Studio Code** y GitHub Codespaces. Trabaja con el modo agente de Copilot Chat, servidores MCP y agentes personalizados sin salir del editor que ya utilizas. Es ideal si quieres integrar la asistencia de IA directamente en el IDE.
### 💻 [Copilot CLI](cli/)
-**GitHub Copilot CLI** es un asistente basado en agentes que se ejecuta en el terminal. Instálalo, conecta servidores MCP, genera código con el modo de planificación y crea tus propias skills, agentes personalizados y comandos con barra diagonal, todo desde la línea de comandos.
+**GitHub Copilot CLI** es un asistente basado en agentes que se ejecuta en el terminal. Tras la configuración, sigue nueve módulos principales: entrega una mejora rápida de valoraciones por estrellas, establece instrucciones, planifica y crea el filtrado, crea una habilidad quality-checks, valida mediante MCP de Playwright, crea un agente QA y combina la funcionalidad. Termina con los controles de CLI y un resumen. El flujo tiene tres hitos de solicitudes de incorporación de cambios.
### 🤖 [Copilot App](app/)
-La **aplicación GitHub Copilot** es una aplicación de escritorio basada en Copilot CLI. Ejecuta sesiones de agentes en paralelo, cambia el modo de las sesiones, colabora en lienzos y gestiona incidencias y solicitudes de incorporación de cambios de GitHub de forma nativa. También incluye **Agent Merge**, que guía una solicitud de incorporación de cambios durante los cambios de base, los comentarios de revisión, las correcciones de integración continua y la combinación.
+La **aplicación GitHub Copilot** es una aplicación de escritorio basada en Copilot CLI. Sigue la misma configuración y los nueve módulos principales del flujo de valoraciones por estrellas, instrucciones, filtrado, habilidad, MCP, QA y PR de la funcionalidad, mediante las sesiones aisladas de la aplicación y **Agent Merge**. Crea y combina un lienzo guardado en el repositorio como cuarto hito de solicitudes de incorporación de cambios y termina con el resumen.
-### ☁️ [Copilot Cloud Agent](../cloud/)
+### ☁️ [Copilot Cloud Agent](cloud/)
El **agente de Copilot en la nube** es un compañero de programación asíncrono que trabaja en segundo plano en las incidencias de GitHub. Asígnale trabajo, guíalo con agentes personalizados, supervisa el progreso desde el panel de agentes y revisa las solicitudes de incorporación de cambios que abre.
diff --git a/docs/es-es/app/0-prerequisites.md b/docs/es-es/app/0-prerequisites.md
index b93e4997..676b584b 100644
--- a/docs/es-es/app/0-prerequisites.md
+++ b/docs/es-es/app/0-prerequisites.md
@@ -15,18 +15,18 @@ En esta lección:
## Instalar Node.js
-En varias lecciones se pide a un agente que desarrolle funcionalidades y ejecute en local el conjunto de pruebas de Tailspin Toys, para lo que se necesita [**Node.js**][nodejs], el único entorno de ejecución que requiere el proyecto. Instala la versión **22 o posterior**; la versión **LTS** actual es una opción segura.
+En varias lecciones se pide a un agente que desarrolle funcionalidades y ejecute en local el conjunto de pruebas de Tailspin Toys, para lo que se necesita [**Node.js**][nodejs]. Utiliza **Node.js 22.13 o posterior** y confirma la versión compatible en `package.json` y README de tu copia de trabajo.
La opción más sencilla en cualquier plataforma es usar el instalador oficial:
1. En el sistema operativo, abre una ventana de terminal con Windows Terminal, Terminal de macOS o la aplicación que utilices habitualmente.
-2. Ejecuta el comando siguiente para confirmar que tienes instalada la versión 22 de Node.js o una posterior:
+2. Ejecuta el comando siguiente para confirmar que tienes instalado Node.js 22.13 o posterior:
```shell
node --version
```
-3. Si aparece `v22` o un número superior, puedes pasar a la sección siguiente.
+3. Si la versión indicada es al menos `v22.13.0` y es compatible con el proyecto, puedes pasar a la sección siguiente.
> [!TIP]
> Solo tienes que completar estos pasos si no tienes Node instalado o si necesitas actualizarlo.
@@ -41,10 +41,10 @@ La opción más sencilla en cualquier plataforma es usar el instalador oficial:
node --version
```
-9. Debería aparecer `v22.x.x` o una versión posterior.
+9. Confirma que la versión indicada es al menos `v22.13.0` y es compatible con el proyecto.
-> [!TIP]
-> ¿Prefieres usar contenedores? Si tienes [**Docker**][docker], puedes utilizar el [contenedor de desarrollo][dev-containers] del repositorio en lugar de instalar Node.js en local; el contenedor ya incluye Node. No necesitas ambas opciones.
+> [!IMPORTANT]
+> Este recorrido de la aplicación utiliza worktrees locales. Un runtime instalado solo en un contenedor no está disponible para esas sesiones locales. Cada worktree también necesita las dependencias del proyecto y Chromium de Playwright para las comprobaciones E2E. Sigue el README del repositorio del participante al preparar un worktree y revisa cualquier solicitud de instalación antes de aprobarla.
## Configurar el repositorio del laboratorio
@@ -64,6 +64,8 @@ Trabajarás con tu propia copia del proyecto Tailspin Toys. Créala ahora a part
> [!NOTE]
> Al crear el repositorio a partir de la plantilla, se genera automáticamente una lista de incidencias de trabajo pendiente. Trabajarás con estas incidencias durante todo el taller; no necesitas crear ninguna.
+Utiliza una copia nueva de la plantilla revisada: incluye instrucciones del repositorio, código de la aplicación, pruebas y una extensión de lienzo existente, pero no incluye agentes personalizados ni habilidades. Crearás tu propia habilidad quality-checks y un perfil QA durante el taller. Si utilizas una copia anterior, examina las personalizaciones existentes en lugar de sobrescribirlas.
+
## Resumen y pasos siguientes
Ya tienes el entorno preparado. Has instalado Node.js para poder compilar y probar el proyecto en tu equipo y has creado tu propia copia del repositorio Tailspin Toys a partir de la plantilla.
@@ -79,7 +81,5 @@ A continuación, instalarás la aplicación GitHub Copilot, conectarás el repos
[next-lesson]: ../1-install-copilot-app/
[nodejs]: https://nodejs.org/
[node-download]: https://nodejs.org/en/download
-[docker]: https://www.docker.com/products/docker-desktop/
-[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
[template-repository]: https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-template-repository
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/es-es/app/1-install-copilot-app.md b/docs/es-es/app/1-install-copilot-app.md
index 212bdaee..049fe491 100644
--- a/docs/es-es/app/1-install-copilot-app.md
+++ b/docs/es-es/app/1-install-copilot-app.md
@@ -41,23 +41,23 @@ Como cabe esperar, el primer paso para utilizar la aplicación GitHub Copilot es
Con el proyecto conectado, dedica un momento a conocer el espacio de trabajo. La aplicación organiza todo en varias áreas de la barra lateral:
-- **Sessions**: donde los agentes realizan su trabajo. Cada sesión se ejecuta en su propio espacio de trabajo aislado, por lo que puedes ejecutar varias a la vez sin que sus cambios entren en conflicto. Iniciarás tu primera sesión en la siguiente lección.
+- **Sessions**: donde los agentes realizan su trabajo. En este taller, elige **new working tree** para que cada hito de PR tenga una copia de trabajo y una rama aisladas. Existen otras opciones de espacio de trabajo, pero no se utilizan aquí.
- **Quick chats**: conversaciones ligeras para preguntas y lluvias de ideas que no necesitan una rama ni un espacio de trabajo propios. Probarás una al final de esta lección.
- **My work**: tus incidencias y solicitudes de incorporación de cambios, disponibles mediante la **integración nativa con GitHub** de la aplicación. Desde aquí puedes examinar y filtrar incidencias y solicitudes de incorporación de cambios, comprobar el estado de CI, iniciar una sesión a partir de una incidencia y revisar solicitudes de incorporación de cambios, todo ello sin salir de la aplicación.
-- **Automations**: tareas de agente guardadas que se ejecutan según una programación o bajo demanda. Crearás una casi al final de este recorrido.
+- **Customize**: descubre y gestiona servidores MCP, habilidades y lienzos. Lo utilizarás para configurar MCP de Playwright.
+- **Automations**: tareas de agente guardadas que se ejecutan según una programación o bajo demanda. El resumen final enlaza a ellas como siguiente paso, no como otro ejercicio del taller.
### Localizar la lista de trabajo pendiente inicial
Como la aplicación se integra de forma nativa con GitHub, el trabajo pendiente del repositorio aparece directamente en ella. Cuando creaste el repositorio a partir de la plantilla, se generó una lista de incidencias. Vamos a comprobar que esté disponible.
1. Selecciona **My work** en la barra lateral.
-2. La plantilla ha creado ocho incidencias en tu lista de trabajo pendiente. Este módulo se centra en las tres siguientes; confirma que puedes verlas:
+2. Busca estas incidencias por su título en lugar de dar por hecho su número:
- Allow users to filter games by category and publisher
- Update our repository coding standards
- - Implement pagination on the game list page
-3. Selecciona una incidencia para leer sus detalles. Cada incidencia también sirve como punto de partida para una sesión de agente. Más adelante iniciarás el trabajo desde estas incidencias.
+3. Selecciona una incidencia para leer sus detalles. Cada incidencia también sirve como punto de partida para una sesión de agente. Más adelante iniciarás el trabajo desde estas incidencias. Las demás incidencias pendientes aportan contexto al lienzo, no son otra tarea de implementación.
> [!NOTE]
> La lista de elementos de **My work** se filtra automáticamente para mostrar solo los elementos de los repositorios que has añadido a la aplicación Copilot. Para ver elementos de trabajo de otros repositorios, añádelos a la aplicación.
@@ -70,7 +70,7 @@ Una buena forma de familiarizarse con la aplicación es utilizarla para conocer
2. Pregunta a la aplicación cómo funcionan sus sesiones:
```plaintext
- How does the GitHub Copilot app use worktrees?
+ ¿Cómo utiliza la aplicación GitHub Copilot los worktrees?
```
3. Lee la respuesta en la vista de conversación. Verás que cada sesión se ejecuta en su propio árbol de trabajo de Git aislado, lo que permite ejecutar varios agentes en paralelo sin que sus cambios entren en conflicto. Puedes continuar la conversación o iniciar un chat nuevo en cualquier momento.
@@ -84,7 +84,13 @@ Has instalado la aplicación GitHub Copilot, conectado el proyecto y explorado e
- familiarizarte con el espacio de trabajo y localizar la lista de trabajo pendiente inicial en **My work**.
- utilizar un chat rápido para formular una pregunta breve y desechable.
-A continuación, iniciarás tu primera sesión de agente y realizarás el primer cambio en el proyecto: mostrar una valoración por estrellas en las tarjetas de los juegos. Continúa con la [Lección 2 - Ejecutar tu primera sesión de agente][next-lesson].
+## Mantener separados los hitos de PR
+
+Combinarás cuatro PR: valoraciones por estrellas; instrucciones con una pequeña demostración; filtrado con la habilidad, el perfil QA y las pruebas; y, por último, el lienzo de clasificación de incidencias. Utiliza una rama por hito de PR. Las Lecciones 4–8 permanecen en la misma sesión, worktree y rama de filtrado, con commits de control en lugar de PR adicionales.
+
+Un worktree nuevo de la aplicación puede partir de un estado local desactualizado. Antes de editar archivos en cada hito nuevo, obtén los cambios del repositorio y actualiza la rama de la nueva sesión mediante un avance rápido hasta el último `origin/main`. Las lecciones siguientes lo muestran explícitamente. No apiles ramas, no selecciones commits de trabajos anteriores mediante cherry-pick ni cambies una sesión de filtrado activa a otra rama.
+
+A continuación, iniciarás tu primera sesión de agente y realizarás el primer cambio en el proyecto: mostrar una valoración por estrellas en las tarjetas de los juegos. Continúa con la [Lección 2 - Añadir valoraciones por estrellas: una mejora rápida][next-lesson].
## Recursos
@@ -92,7 +98,7 @@ A continuación, iniciarás tu primera sesión de agente y realizarás el primer
- [Introducción a la aplicación GitHub Copilot][getting-started]
- [Trabajar con sesiones de agente en la aplicación GitHub Copilot][agent-sessions]
-[ex0]: ../0-prerequisites/
+[previous-lesson]: ../0-prerequisites/
[next-lesson]: ../2-add-star-rating/
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
diff --git a/docs/es-es/app/10-review.md b/docs/es-es/app/10-review.md
new file mode 100644
index 00000000..571468a1
--- /dev/null
+++ b/docs/es-es/app/10-review.md
@@ -0,0 +1,87 @@
+---
+title: "Lección 10 - Repaso y pasos siguientes"
+description: "Repasa los nueve módulos principales de la aplicación, los cuatro hitos de PR y el flujo de calidad reutilizable, y explora otros recursos."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Durante las últimas lecciones, has llevado una funcionalidad desde la idea hasta la combinación mediante la aplicación GitHub Copilot. Entre otras cosas, has aprendido a:
+
+- conectar un repositorio y familiarizarte con el espacio de trabajo de la aplicación y la lista de trabajo pendiente inicial.
+- iniciar sesiones desde una tarea directa y desde incidencias, y utilizar los modos Plan y Autopilot para controlar cómo trabaja el agente.
+- orientar al agente con instrucciones personalizadas y después pedirle que cree una habilidad reutilizable con scripts de shell que has revisado y ejecutado para el linter, las pruebas unitarias, las pruebas de un extremo a otro y las comprobaciones de tipos.
+- probar el trabajo con el servidor MCP de Playwright en un navegador real.
+- crear y seleccionar un agente personalizado QA para evaluar requisitos, cobertura, resultados de scripts de la habilidad y pruebas de observación del navegador.
+- colaborar con el agente en un lienzo compartido.
+- combinar explícitamente las primeras PR personalmente y después autorizar **Agent Merge** dentro de los flujos de PR de la funcionalidad y el lienzo.
+
+Las Lecciones 0–1 de configuración dieron paso a nueve módulos principales, las Lecciones 2–10. Dedica un momento a repasar los recursos creados y cómo continuar; este resumen no inicia otra tarea práctica.
+
+## Qué has entregado
+
+El taller tiene cuatro hitos de PR, cada uno en su propia rama a partir de `main` actualizado:
+
+1. **Valoraciones por estrellas:** mostrar el `starRating` existente y un estado explícito sin valoración en las tarjetas de juegos.
+2. **Instrucciones y demostración:** añadir la convención de documentación y verificar su efecto en un pequeño cambio de código real.
+3. **Filtrado y flujo de calidad:** implementar la incidencia, crear la habilidad `quality-checks` con scripts de shell y el perfil QA e incluir las pruebas asociadas.
+4. **Lienzo de clasificación guardado en el repositorio:** compartir un tablero que añada contexto de incidencias sin implementar automáticamente otra funcionalidad.
+
+Las Lecciones 4–8 utilizaron la misma sesión, worktree y rama de filtrado. Los commits de control conservaron el progreso dentro de la PR 3; las habilidades, la configuración MCP y QA no necesitaron ramas de funcionalidad independientes. Cada hito posterior comenzó solo después de combinar la PR anterior y actualizar la rama de la nueva sesión desde `origin/main`.
+
+## Distintos tipos de verificación
+
+Las primeras funcionalidades utilizaron las comprobaciones npm existentes. El filtrado añadió tu inspección manual en el navegador. La habilidad hizo repetibles las cuatro comprobaciones mediante scripts incluidos, MCP añadió observaciones directas del agente en el navegador y QA combinó requisitos y cobertura con la verificación final. La PR reutilizó las pruebas de QA solo mientras correspondían a la revisión enviada.
+
+Las pruebas añadidas deben cubrir carencias reales; una ejecución QA que no necesita pruebas nuevas puede ser correcta. Las herramientas ausentes, las comprobaciones omitidas y los fallos son bloqueos visibles, no resultados satisfactorios. Revisa el código y las pruebas de verificación antes de autorizar la combinación y actualiza las afectadas después de los cambios.
+
+## Procedimientos recomendados
+
+Al utilizar cualquier herramienta de IA, la infraestructura que la rodea determina la calidad de los resultados. En este taller has creado instrucciones, una habilidad y un perfil QA; revísalos y reutilízalos entre sesiones. Los agentes personalizados definen roles especializados e instrucciones, con herramientas disponibles según la configuración y los permisos del entorno; las habilidades agrupan instrucciones reutilizables para tareas, scripts ejecutables y recursos de apoyo que se cargan bajo demanda. Un agente personalizado también puede ejecutar scripts, incluidos los que forman parte de una habilidad. Confirma la ejecución real de los scripts y la selección del agente personalizado en lugar de confiar en una descripción convincente.
+
+Adapta el **modo y el modelo** a la tarea. Utiliza **Plan** para razonar sobre un enfoque antes de desarrollar, **Interactive** para mantener el control durante cambios concretos y **Autopilot** solo para tareas aisladas y bien delimitadas. Elige un modelo más rápido para las modificaciones rutinarias y otro más capaz, con mayor esfuerzo de razonamiento, para el trabajo complejo.
+
+El contexto sigue siendo tan importante como la infraestructura. Describir con claridad *qué* quieres crear, *por qué* y *cómo* cambia sustancialmente el resultado. Los chats rápidos son un buen lugar para delimitar una idea antes de dedicarle una sesión completa.
+
+## Más opciones para explorar
+
+Ya conoces el flujo de trabajo principal. Estas son algunas funcionalidades adicionales que merece la pena explorar:
+
+- **Quick chats** para preguntas rápidas y desechables que no necesitan una sesión completa.
+- [**Automatizaciones**][using-automations] para tareas recurrentes o bajo demanda, como resumir el trabajo reciente. Revisa la programación, los permisos y el alcance antes de adoptar una; crear una automatización es un siguiente paso, no parte de este taller.
+- **Rubber duck** para razonar sobre un problema y obtener comentarios pertinentes antes de desarrollar.
+- [**Agentes personalizados**][custom-agents] para encapsular un rol, sus herramientas y sus instrucciones con el fin de realizar trabajo especializado y repetible.
+- [`/chronicle`][chronicle] para generar una narración de lo sucedido en una sesión.
+- [Usar tu propia clave (BYOK)][byok] para utilizar modelos de tu propio proveedor, incluidos modelos locales mediante Ollama, Foundry Local o LM Studio.
+- [Entornos aislados en la nube][sandboxes] para ejecutar sesiones en un entorno aislado hospedado en GitHub.
+- [Vínculos profundos][deep-links] para abrir la aplicación directamente en un repositorio, una sesión o una indicación.
+
+## Pasos siguientes
+
+La mejor forma de mejorar con cualquier herramienta es seguir utilizándola. Úsala para código de producción, proyectos personales o esa pequeña aplicación que llevas años pensando en crear. Comparte lo que aprendas con el equipo y aprende de sus experiencias. Y, como siempre, consulta la documentación.
+
+Para explorar más elementos del ecosistema de GitHub Copilot, consulta el [recorrido de VS Code][vscode-harness], el [recorrido de Copilot CLI][cli-harness] o el [recorrido del agente en la nube][cloud-harness].
+
+## Recursos
+
+- [Acerca de la aplicación GitHub Copilot][about-copilot-app]
+- [Introducción a la aplicación GitHub Copilot][getting-started]
+- [Personalizar la aplicación GitHub Copilot][customize]
+- [Utilizar automatizaciones][using-automations]
+- [Trabajar con extensiones de lienzo][canvas-docs]
+- [Acerca de los entornos aislados locales y en la nube][sandboxes]
+
+[previous-lesson]: ../9-canvases/
+[vscode-harness]: ../../vscode/
+[cli-harness]: ../../cli/
+[cloud-harness]: ../../cloud/
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
+[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
+[customize]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
+[using-automations]: https://docs.github.com/copilot/how-tos/github-copilot-app/using-automations
+[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
+[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
+[chronicle]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/chronicle
+[custom-agents]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
+[byok]: https://docs.github.com/copilot/how-tos/github-copilot-app/use-byok-models
+[deep-links]: https://docs.github.com/copilot/how-tos/github-copilot-app/open-with-deep-links
\ No newline at end of file
diff --git a/docs/es-es/app/2-add-star-rating.md b/docs/es-es/app/2-add-star-rating.md
index b10c330b..8a3cc1ef 100644
--- a/docs/es-es/app/2-add-star-rating.md
+++ b/docs/es-es/app/2-add-star-rating.md
@@ -1,5 +1,5 @@
---
-title: "Lección 2 - Ejecutar tu primera sesión de agente"
+title: "Lección 2 - Añadir valoraciones por estrellas: una mejora rápida"
description: "Inicia tu primera sesión de agente en la aplicación GitHub Copilot, realiza un pequeño cambio en las tarjetas de los juegos y combínalo como tu primera solicitud de incorporación de cambios."
authors:
- geektrainer
@@ -22,7 +22,7 @@ Cada juego de Tailspin Toys puede tener una valoración por estrellas, que ya ap
## Anatomía de una sesión
-Una **sesión** es una conversación con un agente que se ejecuta en su propio espacio de trabajo aislado. Cada sesión recibe un **árbol de trabajo y una rama de Git dedicados**, lo que permite ejecutar varias sesiones a la vez, por ejemplo, una para añadir una funcionalidad y otra para corregir un error, sin que sus cambios entren en conflicto. Las sesiones aparecen en la barra lateral agrupadas por repositorio; selecciona cualquiera de ellas para cambiar de sesión.
+Una **sesión** es una conversación con un agente. En este taller eliges **new working tree**, lo que proporciona a la sesión una copia de trabajo y una rama dedicadas. Así se aísla cada hito de PR sin una rama distinta para cada lección. Las sesiones aparecen en la barra lateral agrupadas por repositorio; selecciona cualquiera de ellas para cambiar de sesión.
Dentro de una sesión verás tres elementos: la **conversación** con el agente, la **actividad de las herramientas** del agente mientras explora y edita archivos, y la lista de **archivos modificados** con sus diferencias.
@@ -36,16 +36,20 @@ Vamos a iniciar una sesión nueva para comenzar a explorar el proyecto e impleme
-4. Utiliza la indicación siguiente para solicitar el cambio:
+4. Elige **new working tree** y el modo **Interactive** debajo del cuadro de indicaciones. Utiliza la indicación siguiente para solicitar el cambio:
```plaintext
- On the game cards, show each game's star rating. The Game type already includes a starRating field — it's a number out of 5, or null when a game hasn't been rated yet. Display it on each card in src/components/GameCard.astro, and when starRating is null show "No rating yet" instead. Keep the change small and don't restructure the card layout.
+ Antes de editar, identifica esta copia de trabajo y su rama, confirma que es un worktree nuevo y limpio, obtén los cambios de origin y actualiza la rama de esta sesión mediante un avance rápido hasta origin/main. Confirma que HEAD coincide con origin/main. Detente y explica el motivo si hay cambios pendientes, divergencias o no se puede actualizar; no restablezcas ni descartes trabajo.
+
+ Muestra la valoración por estrellas de cada juego en las tarjetas. El tipo Game ya incluye un campo starRating: un número sobre 5, o null cuando el juego aún no tiene valoración. Muéstralo en cada tarjeta de src/components/GameCard.astro y, cuando starRating sea null, muestra "No rating yet". Mantén el cambio pequeño y no reestructures el diseño de las tarjetas ni cambies el modelo de datos.
+
+ Sigue las instrucciones del repositorio, añade o actualiza las pruebas adecuadas y ejecuta las comprobaciones npm existentes pertinentes. Examina los requisitos previos y pregunta antes de instalar cualquier cosa. Informa de los archivos modificados y los resultados de las comprobaciones y después detente para que los revise. No crees commits, no envíes cambios, no abras una solicitud de incorporación de cambios ni implementes otra funcionalidad.
```
> [!NOTE]
> Observa que la indicación contiene el nombre del archivo que Copilot debe actualizar. Aunque no es necesario especificar los archivos que Copilot debe incluir en su trabajo, orientarlo ayuda a que genere el código con rapidez y reduzca el uso de tokens.
-5. Selecciona Enter para enviar la indicación a Copilot.
+5. Pulsa Enter para enviar la indicación a Copilot.
La aplicación Copilot comienza por crear un árbol de trabajo nuevo, una copia aislada del proyecto. Después explora el proyecto, localiza los archivos que debe actualizar para añadir la funcionalidad y crea el código necesario. Ya has añadido una nueva funcionalidad con la aplicación Copilot.
@@ -76,7 +80,9 @@ Todos los cambios generados por IA deben revisarse antes de combinarlos, incluso
## Comprobar los cambios
-No debemos limitarnos a leer el código y dar por hecho que funciona. También debemos probarlo visualmente. Para ello, iniciaremos la aplicación desde la terminal y confirmaremos que todo funciona. La aplicación Copilot incluye una terminal integrada.
+Revisa los resultados de las comprobaciones automatizadas del agente antes de abrir un navegador. Confirma que las pruebas cubren un `starRating` numérico y la alternativa para `null`, mediante los scripts npm existentes del proyecto en lugar de una habilidad que aún no existe. Un requisito previo ausente o una comprobación omitida no cuentan como superados.
+
+Después examina la aplicación manualmente desde la terminal integrada de la sesión. Identifica el worktree antes de iniciar el servidor y no reutilices un servidor de otra copia de trabajo.
1. En el panel de revisión situado a la derecha de la aplicación Copilot, selecciona **Terminal**. Si no aparece el botón **Terminal**, selecciona **+** (con la etiqueta **Open in panel**) y, después, **Terminal**.
@@ -89,26 +95,30 @@ No debemos limitarnos a leer el código y dar por hecho que funciona. También d
```
3. Cuando se inicie el servidor, lo que solo tardará un momento, abre una ventana del navegador.
-4. Ve a http://localhost:4321.
-5. Ahora deberías ver valoraciones por estrellas en todos los juegos de la página de inicio.
+4. Abre la URL local que muestra el servidor, normalmente `http://localhost:4321`. Si el puerto está ocupado, identifica a quién pertenece en lugar de detener un proceso ajeno.
+5. Confirma que las tarjetas de juegos valorados muestran su puntuación sobre cinco. Si hay datos sin valoración, confirma que aparece **No rating yet**; de lo contrario, verifica el caso null mediante la prueba automatizada en lugar de afirmar que lo has observado.
6. Vuelve a la ventana de terminal.
-7. Selecciona Ctrl+C para detener el servidor de desarrollo.
+7. Pulsa Control+C (Mac) o Ctrl+C (Windows/Linux) para detener el servidor de desarrollo que has iniciado.
## Abrir y combinar tu primera solicitud de incorporación de cambios
-El cambio tiene buen aspecto; ha llegado el momento de publicarlo. Pedirás al agente que abra una solicitud de incorporación de cambios y, después, la revisarás y combinarás en github.com. Por ahora, gestionarás este proceso de forma manual. En una próxima lección descubrirás cómo Copilot puede encargarse automáticamente de parte del trabajo.
+El cambio tiene buen aspecto; ha llegado el momento de entregar la PR 1. Primero autoriza el commit y la PR por separado de la implementación:
+
+```plaintext
+Revisa todas las diferencias del cambio de valoraciones por estrellas y sus pruebas, resume la verificación y crea un commit con los cambios revisados en la rama de esta sesión. Envía la rama y crea una solicitud de incorporación de cambios destinada a main con la plantilla de PR del repositorio. No la combines.
+```
-1. En la esquina superior derecha, selecciona **Create PR**.
+1. Abre el enlace de la PR creada en la sesión. Si la aplicación muestra una confirmación **Create PR**, selecciónala para aprobar la solicitud en lugar de crear una segunda PR.
2. Si se solicita, selecciona **Sign in with your browser** y sigue las indicaciones para autenticarte.
3. Copilot comenzará a crear la solicitud de incorporación de cambios.
-Una vez creada, Copilot supervisará los flujos de trabajo del repositorio que deban ejecutarse. Después de unos instantes, el botón de la esquina superior derecha cambiará a **Ready to merge**. Esto indica que la solicitud está lista para combinarse.
+Una vez creada la PR, examina todas sus diferencias y las comprobaciones en **My work**. Lee los resultados de los flujos de trabajo del repositorio del participante; espera a que se completen las comprobaciones y revisiones obligatorias y resuelve los fallos antes de combinar. **Ready to merge** no sustituye la revisión del cambio ni las pruebas de verificación locales.
4. Selecciona la burbuja **PR** situada justo encima del chat para abrir la solicitud en el panel de revisión. Puedes revisarla aquí según sea necesario.
5. Cuando esté lista, selecciona **Ready to merge**.
6. Selecciona **Merge pull request** en el nuevo cuadro de diálogo para combinar la solicitud.
-Ya has publicado una nueva funcionalidad en el sitio web.
+Confirma que la PR 1 se ha combinado en `main` antes de continuar. Combinar cambios en el repositorio del participante no despliega por sí solo un sitio web. La siguiente lección inicia un worktree nuevo y lo actualiza desde `origin/main` para que incluya esta PR.
## Resumen y pasos siguientes
@@ -118,7 +128,7 @@ Has iniciado tu primera sesión de agente y publicado tu primer cambio. En concr
- has indicado al agente que realice un cambio pequeño y específico en las tarjetas de los juegos.
- has revisado el cambio en la vista de diferencias del espacio de trabajo.
- has ejecutado la aplicación en local para confirmar la valoración por estrellas en el navegador.
-- has abierto una solicitud de incorporación de cambios y la has combinado personalmente en github.com.
+- has abierto la PR 1, revisado sus comprobaciones y autorizado explícitamente su combinación.
A continuación, utilizarás la aplicación para añadir al repositorio un estándar de instrucciones personalizadas a partir de una de las incidencias de la lista de trabajo pendiente. Continúa con la [Lección 3 - Guiar a Copilot con instrucciones personalizadas][next-lesson].
@@ -128,7 +138,8 @@ A continuación, utilizarás la aplicación para añadir al repositorio un está
- [Acerca de la aplicación GitHub Copilot][about-copilot-app]
- [Gestionar incidencias y solicitudes de incorporación de cambios con la aplicación GitHub Copilot][managing-issues-prs]
-[prior-lesson]: ../1-install-copilot-app/#instalar-y-configurar-la-aplicacion-github-copilot
+[prior-lesson]: ../1-install-copilot-app/#instalar-y-configurar-la-aplicación-github-copilot
+[previous-lesson]: ../1-install-copilot-app/
[next-lesson]: ../3-custom-instructions/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
diff --git a/docs/es-es/app/3-custom-instructions.md b/docs/es-es/app/3-custom-instructions.md
index 3275c5e6..4c6be980 100644
--- a/docs/es-es/app/3-custom-instructions.md
+++ b/docs/es-es/app/3-custom-instructions.md
@@ -1,9 +1,9 @@
---
title: "Lección 3 - Guiar a Copilot con instrucciones personalizadas"
-description: "Utiliza la aplicación GitHub Copilot para añadir al repositorio un estándar de instrucciones personalizadas a partir de una incidencia de la lista de trabajo pendiente y combina el cambio como una solicitud de incorporación de cambios."
+description: "Añade un estándar de documentación, demuéstralo en una pequeña función auxiliar o un componente existente y combina ambos como segunda solicitud de incorporación de cambios."
authors:
- geektrainer
-lastUpdated: 2026-07-09
+lastUpdated: 2026-09-11
---
El contexto es fundamental al trabajar con IA generativa. Si una tarea debe realizarse de una forma concreta o Copilot necesita conocer información de fondo, conviene que ese contexto esté disponible. Una de las herramientas más potentes para proporcionarlo son los [archivos de instrucciones][instruction-files], que describen no solo *qué* código quieres, sino también *cómo* debe estructurarse. En esta lección añadirás un estándar de documentación al repositorio y lo harás como realizarás la mayor parte del trabajo a partir de ahora: comenzarás desde una incidencia de la lista de trabajo pendiente y dejarás que el agente realice el cambio.
@@ -12,15 +12,17 @@ En esta lección:
- explorarás cómo llegan al agente las instrucciones del repositorio y los archivos de instrucciones limitados por ruta.
- iniciarás una sesión desde la incidencia sobre instrucciones de la lista de trabajo pendiente.
-- pedirás al agente que añada un estándar de documentación a `.github/copilot-instructions.md`.
-- revisarás el cambio y lo combinarás como una solicitud de incorporación de cambios.
+- pedirás al agente que añada un estándar de documentación específico a los archivos de instrucciones adecuados del repositorio.
+- demostrarás el estándar con un pequeño cambio de código real, lo validarás y combinarás la PR 2.
## Escenario
Como cualquier buen equipo de desarrollo, Tailspin Toys dispone de directrices y requisitos para las prácticas de desarrollo. Entre ellos se incluyen:
-- Se debe añadir documentación al código mediante comentarios de documentación TSDoc.
-- El formato se debe documentar y aplicar mediante linting.
+- Los comentarios deben explicar la intención y las decisiones no evidentes, en lugar de repetir lo que hace el código.
+- Las funciones exportadas de `db/` y `src/lib/` deben documentar su propósito, parámetros y valores de retorno mediante TSDoc/JSDoc, incluido un argumento `db` inyectable cuando exista.
+- Los componentes reutilizables de Astro deben documentar sus contratos de `Props`, y los comentarios deben mantenerse actualizados cuando cambie el código relacionado.
+- Deben conservarse las directrices existentes de formato y lint.
Mediante los archivos de instrucciones, garantizarás que Copilot disponga de la información adecuada para realizar las tareas conforme a estas prácticas.
@@ -28,13 +30,13 @@ Mediante los archivos de instrucciones, garantizarás que Copilot disponga de la
Las instrucciones personalizadas permiten proporcionar contexto y preferencias a Copilot para que comprenda mejor el estilo y los requisitos de programación. Esta potente funcionalidad ayuda a orientar a Copilot para obtener sugerencias y fragmentos de código más pertinentes. Puedes especificar las convenciones de programación, las bibliotecas e incluso los tipos de comentarios que prefieres incluir en el código. También puedes crear instrucciones para todo el repositorio o para tipos de archivo concretos, con contexto específico para una tarea.
-Hay dos tipos de archivos de instrucciones:
+El proyecto utiliza dos tipos de archivos de instrucciones:
- `.github/copilot-instructions.md`, un único archivo de instrucciones que se envía a Copilot con **cada** solicitud del repositorio. Debe contener información del proyecto que sea pertinente para la mayoría de las solicitudes de chat o CLI enviadas a Copilot, como la pila tecnológica, una descripción general de lo que se está creando, procedimientos recomendados y otras directrices globales.
- Los archivos `.github/instructions/*.instructions.md` se pueden crear para tareas o tipos de archivo concretos. Puedes utilizarlos para proporcionar directrices para lenguajes específicos, como TypeScript o Astro, o para tareas como crear un componente de interfaz de usuario o un nuevo conjunto de pruebas unitarias.
> [!NOTE]
-> Copilot admite otros estándares para incorporar instrucciones mediante AGENTS.md, CLAUDE.md y GEMINI.md, de modo que siempre disponga del contexto adecuado.
+> Los demás formatos de instrucciones y su compatibilidad varían según el entorno. Consulta la [referencia de compatibilidad de instrucciones personalizadas][custom-instructions-support] antes de depender de un formato concreto.
### Procedimientos recomendados para gestionar archivos de instrucciones
@@ -74,49 +76,55 @@ Dedica un momento a leer los archivos de instrucciones incluidos en este reposit
11. Por último, abre `.github/instructions/drizzle.instructions.md` y desplázate hasta el final. Observa los vínculos a otros archivos de instrucciones, como `unit-tests.instructions.md`, y a archivos existentes del proyecto. De este modo puedes dividir conjuntos de instrucciones grandes en archivos más pequeños y reutilizables, y señalar a Copilot ejemplos que debe seguir al generar código. Las rutas son relativas al archivo de instrucciones, no a la raíz del repositorio.
> [!NOTE]
-> La sección **Code formatting requirements** de `copilot-instructions.md` documenta los estándares de programación del proyecto, pero todavía no exige documentación dentro del código. En los pasos siguientes añadirás reglas para comentarios de documentación TSDoc y comentarios de cabecera de archivo.
+> Compara las directrices existentes con la incidencia real de estándares de programación antes de añadir reglas. Esta lección se centra en comentarios que explican la intención, documentación de funciones exportadas de la capa de datos y contratos de `Props` de Astro, no en cabeceras obligatorias para todos los archivos ni en comentarios que repiten el código.
## Empezar desde la incidencia sobre instrucciones
-En la lección anterior iniciaste una sesión con una indicación directa. Sin embargo, la mayor parte del trabajo comienza con una incidencia. Vamos a crear una sesión basada en una incidencia presentada para actualizar los archivos de instrucciones y, después, solicitaremos la actualización.
+Confirma que la PR 1 está combinada antes de crear esta sesión. Inicia un worktree nuevo para la PR 2; no continúes en la rama de valoraciones por estrellas. La mayor parte del trabajo comienza con una incidencia, así que utiliza la de estándares de programación para aportar los requisitos.
> [!NOTE]
> Como los archivos de instrucciones influyen mucho en el código que genera Copilot, debes asegurarte de que lo orienten con claridad. Pedir a Copilot que cree una primera versión, como harás en esta lección, es un buen enfoque, siempre que después la revises para confirmar que las actualizaciones cumplen tus requisitos.
1. Selecciona **My work** en la barra lateral.
2. Selecciona la incidencia titulada **Update our repository coding standards** para abrirla.
-3. Selecciona **New session** en la esquina superior derecha para iniciar una sesión basada en la incidencia.
+3. Selecciona **New session** en la esquina superior derecha, elige **new working tree** y selecciona el modo **Interactive**.
-4. Utiliza la indicación siguiente para pedir a Copilot que actualice los archivos de instrucciones de acuerdo con los requisitos documentados en la incidencia:
+4. Utiliza la siguiente indicación. Actualizar la rama de la nueva sesión antes de editar hace que el último `main` combinado sea el punto de partida real, aunque la copia local de la aplicación estuviera desactualizada:
- ```plaintext
- Following this issue, make the updates to the instructions files in this project to meet the requirements documented. Don't create the PR quite yet!
- ```
+ ```plaintext
+ Antes de editar, identifica esta copia de trabajo y su rama, confirma que es un worktree nuevo y limpio, obtén los cambios de origin y actualiza la rama de esta sesión mediante un avance rápido hasta origin/main. Confirma que HEAD coincide con origin/main e incluye la PR de valoraciones por estrellas combinada. Detente si hay cambios pendientes, divergencias o falta esa combinación; no restablezcas, no descartes trabajo ni crees otra rama.
+
+ Lee la incidencia "Update our repository coding standards" y las instrucciones existentes del repositorio. Añade una convención de documentación específica: explica la intención en lugar de la mecánica; documenta las funciones exportadas de db/ y src/lib/ con TSDoc/JSDoc que cubra propósito, parámetros, valores de retorno y argumentos db inyectables cuando existan; documenta los contratos de Props de los componentes reutilizables de Astro; y mantén los comentarios actualizados cuando cambie el código relacionado.
+
+ Coloca cada regla en el archivo de instrucciones existente adecuado, sin duplicaciones ni contradicciones, y enlaza o resume el estándar actualizado en README. Conserva las directrices existentes de formato y lint. No exijas cabeceras para todos los archivos, no migres herramientas de formato, no reescribas la documentación de toda la aplicación ni implementes el filtrado. Muéstrame las diferencias de las instrucciones y después detente para que las revise. No crees una habilidad o un agente, no crees commits, no envíes cambios ni crees una PR.
+ ```
Copilot realizará las actualizaciones.
## Revisar el cambio
-Vamos a leer las actualizaciones de Copilot y también a pedirle un ejemplo del código que generará a partir de las instrucciones actualizadas.
+Lee las directrices actualizadas y demuestra su efecto en un archivo real. Un fragmento propuesto por sí solo no demuestra que las instrucciones del repositorio hayan influido en un cambio de código.
1. Selecciona **Changes** en la esquina superior derecha para abrir los cambios de código.
-2. Revisa el archivo de instrucciones actualizado. Confirma que contiene las directrices para añadir documentación y comentarios al código.
+2. Revisa los archivos de instrucciones actualizados y la referencia en README. Confirma que las reglas coinciden con la filosofía de comentarios, la documentación de funciones exportadas y los contratos de componentes de la incidencia, sin inventar un requisito general de cabeceras de archivo.
> [!NOTE]
> Como la IA es probabilística y no determinista, el texto exacto puede variar.
-3. Utiliza la indicación siguiente para pedir a Copilot que cree un ejemplo del código que generará ahora:
+3. Tras revisar las instrucciones, solicita una demostración acotada en esta misma sesión:
+
+ ```plaintext
+ Demuestra la convención de documentación actualizada en una pequeña función auxiliar exportada de TypeScript existente en db/ o src/lib/, o en un componente reutilizable de Astro. Examina el repositorio para elegir un archivo existente adecuado; no des por hecho que existe una función auxiliar de editores. Realiza una pequeña mejora de legibilidad que conserve el comportamiento y aplica las directrices pertinentes de documentación de funciones o contratos de Props. Explica las intenciones no evidentes sin añadir comentarios que se limiten a repetir el código.
- ```plaintext
- Do not make any updates, but show me what the code would look like. Based on the new instructions, if I asked Copilot to create a new library component to return all Publishers what would that code look like?
- ```
+ Limita el cambio a esa demostración y las pruebas directamente relacionadas. No implementes el filtrado ni crees una funcionalidad nueva. Ejecuta las comprobaciones npm existentes pertinentes, informa de lo que ha cambiado y de cómo la instrucción ha influido en el código y detente para que lo revise. Pregunta antes de instalar cualquier cosa. No crees commits, no envíes cambios ni crees una PR.
+ ```
-4. Revisa el código que propone Copilot. Observa los comentarios de documentación TSDoc y el comentario de cabecera de archivo que incluye, exactamente lo que solicitan las instrucciones actualizadas.
+4. Revisa las diferencias reales del archivo, no solo la respuesta del chat. Comprueba que la documentación explica el comportamiento real y que la mejora de legibilidad lo conserva. Revisa los resultados pertinentes de pruebas, lint y comprobaciones de tipos; resuelve los fallos antes de continuar.
Ya has actualizado los archivos de instrucciones del proyecto y has comprobado el efecto que tendrán.
@@ -124,17 +132,23 @@ Ya has actualizado los archivos de instrucciones del proyecto y has comprobado e
Los archivos de instrucciones pasan a ser recursos del repositorio y, por tanto, se comparten con el resto del equipo. Vamos a crear una solicitud de incorporación de cambios con nuestro trabajo, igual que haríamos con cualquier otro recurso.
-1. En la esquina superior derecha, selecciona **Create PR**.
+Primero autoriza conjuntamente las instrucciones y la demostración revisadas:
+
+```plaintext
+Revisa todas las diferencias de las instrucciones de estándares de programación, la referencia en README y la demostración de código acotada, incluidas las pruebas relacionadas. Resume la verificación y crea un commit con estos cambios revisados en la rama de esta sesión. Envía la rama y crea una única solicitud de incorporación de cambios destinada a main, con la plantilla de PR del repositorio y un enlace a la incidencia de estándares de programación. Descríbela como contribución parcial salvo que se cumplan todos los criterios de aceptación de la incidencia; no utilices palabras clave de cierre para trabajo incompleto. No la combines.
+```
+
+1. Abre el enlace de la PR en la sesión. Si la aplicación muestra una confirmación **Create PR**, selecciónala sin crear una PR duplicada.
2. Si se solicita, selecciona **Sign in with your browser** y sigue las indicaciones para autenticarte.
3. Copilot comenzará a crear la solicitud de incorporación de cambios.
-Una vez creada, Copilot supervisará los flujos de trabajo del repositorio que deban ejecutarse. Después de unos instantes, el botón de la esquina superior derecha cambiará a **Ready to merge**. Esto indica que la solicitud está lista para combinarse.
+Examina todas las diferencias de la PR en **My work**, incluidos los cambios de instrucciones y código. Revisa los resultados de CI del repositorio del participante y las revisiones obligatorias. Resuelve los fallos antes de seleccionar **Ready to merge**; CI no sustituye la demostración ni tu revisión.
4. Selecciona **Ready to merge**.
5. Selecciona **Merge pull request** en el nuevo cuadro de diálogo para combinar la solicitud.
> [!NOTE]
-> Una vez combinado el estándar en la rama predeterminada, pasa a formar parte del proyecto para todo el equipo y para cada sesión nueva. Cuando inicies la sesión de filtrado de la siguiente lección desde una rama predeterminada actualizada, el agente seguirá este estándar automáticamente. Verás que el código TypeScript que genera incluye comentarios de documentación TSDoc sin que se lo pidas: una demostración pequeña pero real de cómo las instrucciones determinan el código generado.
+> Confirma que la PR 2 se ha combinado en `main` antes de empezar el filtrado. Un worktree nuevo por sí solo no garantiza código actualizado: en la Lección 4 obtendrás los cambios y actualizarás la rama de la nueva sesión mediante un avance rápido hasta `origin/main`, y verificarás que ambas combinaciones anteriores están presentes antes de planificar.
## Resumen y pasos siguientes
@@ -142,10 +156,10 @@ Has explorado cómo la aplicación obtiene contexto de los archivos de instrucci
- has explorado el archivo `copilot-instructions.md` del repositorio y los archivos `*.instructions.md` limitados por ruta.
- has iniciado una sesión desde la incidencia sobre instrucciones de la lista de trabajo pendiente.
-- has pedido al agente que añada un estándar de documentación a `.github/copilot-instructions.md`.
-- has revisado el cambio y lo has combinado como una solicitud de incorporación de cambios.
+- has pedido al agente que añada reglas de documentación específicas a los archivos de instrucciones adecuados y las referencie desde README.
+- has examinado el efecto del estándar en un cambio de código real, validado el resultado y combinado ambos como PR 2.
-A continuación, crearás la funcionalidad de filtrado en una sesión nueva y comprobarás cómo adopta el estándar que acabas de combinar. Continúa con la [Lección 4 - Crear una funcionalidad con Autopilot][next-lesson].
+A continuación, crearás la funcionalidad de filtrado en una sesión nueva y comprobarás que sigue el estándar que acabas de combinar. Continúa con la [Lección 4 - Crear el filtrado con Plan y Autopilot][next-lesson].
## Recursos
@@ -154,6 +168,7 @@ A continuación, crearás la funcionalidad de filtrado en una sesión nueva y co
- [Procedimientos recomendados para crear instrucciones personalizadas][instructions-best-practices]
- [Awesome Copilot: colección de archivos de instrucciones y otros recursos][awesome-copilot]
+[previous-lesson]: ../2-add-star-rating/
[next-lesson]: ../4-build-filtering/
[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/es-es/app/4-build-filtering.md b/docs/es-es/app/4-build-filtering.md
index 39105d16..954d4fe8 100644
--- a/docs/es-es/app/4-build-filtering.md
+++ b/docs/es-es/app/4-build-filtering.md
@@ -1,186 +1,122 @@
---
-title: "Lección 4 - Crear una funcionalidad con Autopilot"
-description: "Utiliza los modos Plan y Autopilot de la aplicación GitHub Copilot para crear una funcionalidad de filtrado estática en el cliente, comprobar que hereda el estándar de documentación y verificarla con una habilidad de agente."
+title: "Lección 4 - Crear el filtrado con Plan y Autopilot"
+description: "Planifica el filtrado desde su incidencia, aprueba Autopilot explícitamente, valida con las comprobaciones npm existentes y una visita manual al navegador, y guarda un punto de control."
authors:
- geektrainer
-lastUpdated: 2026-07-13
+lastUpdated: 2026-09-11
---
-Hasta ahora hemos realizado un par de pequeñas actualizaciones en el proyecto. Sin embargo, los cambios más amplios requieren un proceso más sólido. La aplicación GitHub Copilot está diseñada para integrarse en nuestro flujo actual y garantizar que creemos lo correcto de la forma adecuada. Esta es la primera de tres lecciones en las que seguirás un proceso de desarrollo habitual: empezarás por utilizar una incidencia para generar una funcionalidad nueva y una habilidad de agente para ejecutar las pruebas de validación y los linters.
+Has combinado las valoraciones por estrellas y el estándar de documentación con su demostración en código. Ahora crea la funcionalidad de filtrado. Este es el inicio de un hito de PR más amplio: mantén esta misma sesión, worktree y rama durante las Lecciones 4–8.
En esta lección:
-- iniciarás una sesión nueva desde la incidencia sobre filtrado.
-- utilizarás el modo **Plan** para planificar la funcionalidad y, después, **Autopilot** para crearla.
-- confirmarás que el código generado sigue el estándar de documentación que combinaste anteriormente.
-- verificarás el trabajo con la habilidad `quality-checks` del proyecto.
+- partirás de `main` actualizado y leerás la incidencia real de filtrado.
+- resolverás los requisitos en modo **Plan** antes de aprobar explícitamente **Autopilot**.
+- revisarás el filtrado y las pruebas y después ejecutarás las cuatro comprobaciones npm existentes.
+- visitarás la funcionalidad manualmente en un navegador y guardarás un punto de control.
-## Escenario
+La habilidad, la validación MCP, el perfil QA y la PR de la funcionalidad llegarán en módulos posteriores. No los crees durante este paso de implementación.
-La página de inicio muestra todos los juegos, pero los visitantes no pueden restringir la lista. La incidencia sobre filtrado solicita que puedan filtrar los juegos por **categoría** y **editor**. Vamos a utilizar Copilot para implementar esta funcionalidad.
-
-## Contexto
+## Modos de sesión
-Introducir agentes de programación con IA en el flujo de desarrollo no cambia los principios fundamentales. De hecho, adquieren aún más importancia. La mayoría de los desarrolladores siguen un flujo similar al siguiente:
+El selector de modo situado debajo de la indicación controla la autonomía del agente:
-1. Abrir una incidencia que detalle lo que debe hacerse.
-2. Crear un plan de lo que debe desarrollarse.
-3. Crear y revisar el código.
-4. Ejecutar las pruebas para validar el código.
-5. Validar manualmente la nueva funcionalidad.
-6. Crear una solicitud de incorporación de cambios (PR).
-7. Una vez revisado el código y completado correctamente el proceso de integración continua, combinarlo.
+- **Interactive** te mantiene al tanto mientras el agente trabaja y solicita información.
+- **Plan** prepara un plan para revisarlo antes de la implementación.
+- **Autopilot** implementa e itera de forma autónoma dentro del alcance y los permisos aprobados.
-> [!NOTE]
-> Los detalles concretos variarán según el equipo y la organización, pero la mayoría de los procesos serán una variante del flujo anterior.
+Planifica primero, aprueba de forma explícita y vuelve a Interactive antes de crear personalizaciones reutilizables.
-Al mantener este enfoque estándar, te aseguras de que el código generado por IA cumpla los requisitos establecidos y pase por el mismo proceso de validación que el código escrito manualmente.
+## Partir de main actualizado
-## Modos de sesión
+Confirma que la PR 1 y la PR 2 están combinadas en GitHub. Crea un worktree nuevo para el filtrado en lugar de continuar en cualquiera de las ramas anteriores.
-El **modo de sesión** controla el grado de autonomía del agente. Puedes establecerlo en el menú desplegable situado debajo del campo de indicaciones y cambiarlo en cualquier momento:
+1. Selecciona **My work** y busca **Allow users to filter games by category and publisher** por su título. Ábrela y copia su URL real; los números de incidencia varían entre repositorios.
+2. Selecciona **New session** y elige **new working tree**. Mantén el modo **Interactive** para actualizar el estado inicial.
-- **Interactive**: trabajas junto con el agente. El agente sugiere cambios y espera tus indicaciones antes de continuar.
-- **Plan**: el agente crea primero un plan. Revisas y apruebas el plan antes de que el agente lo ejecute.
-- **Autopilot**: el agente trabaja de forma totalmente autónoma, escribe código, ejecuta pruebas e itera sin esperar indicaciones.
+ 
-## Planificar la funcionalidad de filtrado
+3. Envía esta solicitud de preparación antes de planificar o editar:
-El mejor momento para detectar un posible problema es antes de escribir código, y una breve planificación previa es la mejor forma de hacerlo. Al planificar con Copilot, le pedirás que genere una serie de pasos y documente el enfoque que seguirá. Después podrás revisar el plan y proponer mejoras antes de permitir que Copilot genere el código a partir de él.
-
-Vamos a abrir la incidencia, iniciar una sesión nueva y crear un plan. Para ello, cambiaremos al modo Plan y enviaremos la solicitud.
+ ```plaintext
+ Prepara esta nueva sesión de filtrado sin implementar nada. Identifica la copia de trabajo y la rama, confirma que el worktree está limpio, obtén los cambios de origin y actualiza la rama de esta sesión mediante un avance rápido hasta origin/main. Confirma que HEAD coincide con origin/main e incluye las PR combinadas de valoraciones por estrellas y estándares de programación.
-1. Selecciona **My work** en la pestaña de navegación.
-2. Selecciona la incidencia titulada **Allow users to filter games by category and publisher**.
-3. Selecciona **New session** en la esquina superior derecha.
+ Detente y explica el motivo si hay cambios pendientes, divergencias o falta cualquiera de las combinaciones. No restablezcas ni descartes trabajo, no cambies de rama, no crees otra rama ni edites archivos de la aplicación. Informa de la revisión de partida.
+ ```
- 
+4. Comprueba el estado inicial comunicado. Obtener los cambios no actualiza por sí solo el worktree: la rama de la sesión actual debe avanzar mediante un avance rápido y su `HEAD` debe coincidir con el `origin/main` obtenido antes de empezar a trabajar.
-4. Selecciona Shift+Tab hasta que el modo muestre **Plan**.
+## Planificar la funcionalidad de filtrado
- 
+Cambia el selector de modo a **Plan**. Sustituye el marcador de posición de la incidencia por la URL que has copiado.
-5. Envía la indicación siguiente. La incidencia sobre filtrado ya está en el contexto de esta sesión porque la has iniciado desde ella:
+```plaintext
+Planifica la funcionalidad de filtrado a partir de esta incidencia: . Lee todos sus criterios de aceptación y las instrucciones del repositorio y después examina la aplicación estática de Astro actual, sus funciones auxiliares de acceso a datos y sus pruebas existentes. No implementes nada todavía.
- ```plaintext
- Plan the work based on the requirements documented in the issue. Please ask any clarifying questions you might have as you build the plan.
- ```
+Cubre la selección de varias categorías, el filtrado por editor, la combinación de categorías y editor, las funciones auxiliares de acceso a datos adecuadas, los controles accesibles y la cobertura unitaria y de un extremo a otro que exige la incidencia. Pregúntame para resolver comportamientos no especificados, como la combinación de varias categorías, el borrado de filtros y los resultados vacíos, en lugar de inventar requisitos sin decirlo. No introduzcas una API de servidor a menos que los requisitos y la arquitectura existente lo justifiquen.
-6. El agente puede plantear preguntas de seguimiento mientras crea el plan. Respóndelas según cómo desarrollarías la funcionalidad.
+Propón un plan de implementación y verificación acotado que siga la convención de documentación del repositorio y añada o actualice las pruebas unitarias y de un extremo a otro necesarias. Tras confirmar los comandos en package.json, planifica la ejecución de npm run lint, npm run test:unit, npm run test:e2e y npm run typecheck:all con las herramientas existentes del proyecto. Registra la URL de la incidencia y mis aclaraciones aprobadas en el plan para que pueda reutilizarlas en QA.
-> [!NOTE]
-> Como Copilot es probabilístico, las preguntas de seguimiento exactas pueden variar. Incluso es posible que no formule ninguna. Es completamente normal.
+Incluye estas medidas de seguridad de ejecución en el plan antes de que lo apruebe: identifica la copia de trabajo y el servidor que se prueban; examina los requisitos previos antes de ejecutar las comprobaciones; pregunta antes de instalar software, dependencias o navegadores; no reutilices el servidor de otro worktree; detén solo los servidores que hayas iniciado; e informa de otros conflictos de puerto en lugar de detener procesos ajenos. Los requisitos previos ausentes y las comprobaciones omitidas deben comunicarse como bloqueos, no como comprobaciones superadas.
-7. Cuando termine, Copilot ofrecerá un resumen del plan. Revísalo. Debería proponer crear consultas, añadir controles de filtrado y, por supuesto, pruebas. Si quieres, proporciona comentarios para perfeccionarlo; el agente incorporará las sugerencias en una versión nueva.
+Incluye este límite de implementación en el plan: después de que apruebe explícitamente Autopilot, implementa solo la funcionalidad de filtrado acordada y sus pruebas en este mismo worktree y rama, ejecuta las cuatro comprobaciones, informa de la implementación y de todos los resultados, incluidos fallos o bloqueos, y después detente para que revise el trabajo y lo compruebe manualmente en el navegador. No crees habilidades ni agentes personalizados, no configures MCP, no cambies de rama, no crees commits, no envíes cambios ni abras una PR durante la implementación. La comprobación manual del navegador y el commit de punto de control tendrán lugar después, bajo mis instrucciones por separado.
-## Crear la funcionalidad con Autopilot
+Por ahora, mantén el modo Plan y detente con el plan para que lo revise. No implementes, no crees habilidades ni agentes personalizados, no configures MCP, no cambies de rama, no crees commits, no envíes cambios ni abras una PR.
+```
-Con el plan preparado, vamos a dejar que Copilot cree la implementación.
+Responde a las preguntas aclaratorias y revisa el plan frente a la incidencia. Busca los cambios de acceso a datos, los controles accesibles y las pruebas, en lugar de aceptar una implementación solo de interfaz. Guarda la URL real de la incidencia y las aclaraciones aprobadas del plan para las Lecciones 6 y 7; utiliza `none` cuando no hagan falta criterios adicionales.
-1. En la lista de opciones del cuadro de diálogo **Plan summary**, selecciona la opción más parecida a **Approve and implement with autopilot**.
+Antes de aprobar, confirma que el propio plan contiene las cuatro comprobaciones, la convención de documentación, las medidas de seguridad sobre requisitos previos y servidores, el requisito de mantener el mismo worktree y rama y la parada tras la implementación y la verificación. Debe prohibir las habilidades, agentes y configuración MCP posteriores, los commits, los envíos de cambios y las PR durante la implementación. Si falta algún límite, solicita un plan revisado mientras sigues en modo **Plan** y examina la revisión antes de aprobar.
-Copilot comenzará a trabajar en la implementación.
+## Aprobar Autopilot explícitamente
-> [!NOTE]
-> Si Copilot no empieza a crear automáticamente el código necesario, puedes pedírselo con una indicación como "Go ahead and start building out the plan!".
->
-> Las actualizaciones necesarias tardarán varios minutos. El agente edita y crea archivos, escribe y ejecuta pruebas e itera. Es un buen momento para repasar lo que has explorado hasta ahora o tomar algo.
+Solo cuando el plan revisado contenga tus requisitos y todos los límites de ejecución, selecciona **Approve and implement with autopilot** en los controles de aprobación del plan, o la opción explícita de Autopilot equivalente de tu versión. Confirma que el indicador de modo muestra **Autopilot**.
-## Revisar los cambios
+La aprobación puede iniciar la ejecución inmediatamente. Por tanto, todo el alcance de implementación, las reglas de seguridad y los límites de parada deben estar en el plan revisado antes de aprobar; no confíes en añadirlos mediante un mensaje posterior cuando la ejecución ya haya empezado.
-Todo el código generado por IA debe revisarse antes de combinarlo. Vamos a revisar el código y ejecutar el sitio para comprobar que todo funciona correctamente.
+Autopilot puede escribir código y pruebas e iterar sobre los fallos, pero este permiso no autoriza a completar módulos posteriores del taller. La falta de un requisito previo es un bloqueo que debe resolverse con aprobación, no una comprobación superada.
-1. Selecciona **Changes** en la esquina superior derecha para abrir los cambios de código.
+## Revisar y verificar la implementación
- 
+1. Abre **Changes** y examina la implementación del filtrado y las pruebas.
+2. Compara el resultado con la incidencia y las aclaraciones aprobadas, incluidas las combinaciones de varias categorías y editores. Comprueba que las funciones auxiliares nuevas o modificadas siguen el estándar de documentación de la Lección 3.
+3. Examina la salida real de los comandos de las cuatro comprobaciones npm. Ahora se ejecutan directamente porque aún no has creado la habilidad quality-checks.
+4. Resuelve los fallos y repite las comprobaciones afectadas antes de aceptar la implementación. La configuración E2E de Playwright compila y sirve una vista previa y puede reutilizar un servidor local; asegúrate de que el servidor probado pertenece a este worktree, no a una lección anterior.
-2. Revisa los cambios. Deberías ver nuevos archivos de TypeScript y Astro, además de archivos de prueba. Observa que las nuevas funciones auxiliares incluyen comentarios de documentación TSDoc y un comentario de cabecera de archivo: el estándar de documentación que combinaste en la Lección 3, aplicado automáticamente sin solicitarlo.
-3. En el panel de revisión situado a la derecha de la aplicación Copilot, selecciona **Terminal**. Si no aparece el botón **Terminal**, selecciona **+** (con la etiqueta **Open in panel**) y, después, **Terminal**.
+## Comprobar la funcionalidad manualmente
- 
+Vuelve al modo **Interactive** antes de la revisión manual y mantenlo para la Lección 5.
-4. Introduce el comando siguiente en la ventana de terminal para iniciar el servidor de desarrollo de la aplicación web:
+1. Abre **Terminal** en el panel de revisión de esta sesión. Si es necesario, selecciona **+** y después **Terminal**.
+2. Confirma que la terminal está en el worktree de filtrado y ejecuta:
```shell
npm run dev
```
-5. Cuando se inicie el servidor, lo que solo tardará un momento, abre una ventana del navegador.
-6. Ve a http://localhost:4321.
-7. Ahora deberías ver filtros en la página de inicio.
-8. Si algo no parece correcto, puedes pedir a Copilot que lo actualice.
-9. Cuando estés conforme, vuelve a la ventana de terminal.
-10. Selecciona Ctrl+C para detener el servidor de desarrollo.
+3. Abre en el navegador la URL que muestra este servidor, normalmente `http://localhost:4321`. Si el puerto está ocupado, identifica a quién pertenece en lugar de detener un proceso ajeno o suponer que el servidor existente contiene tus cambios.
+4. Prueba la selección de categorías, la selección de editor y su combinación según el comportamiento aprobado. Comprueba el acceso mediante teclado y el comportamiento acordado de borrado de filtros y resultados vacíos.
+5. Si algo falla, solicita una corrección específica, revisa las diferencias, repite las comprobaciones automatizadas afectadas y las comprobaciones pertinentes del navegador.
+6. Vuelve a la terminal y pulsa Control+C (Mac) o Ctrl+C (Windows/Linux) para detener el servidor que has iniciado. Confirma que se ha detenido antes de la ejecución E2E del siguiente módulo.
-## Verificar el trabajo con la habilidad quality-checks
+Esta es tu observación manual en el navegador. La observación en el navegador dirigida por el agente mediante MCP llegará en la Lección 6.
-Podrías revisar visualmente las diferencias y dar el trabajo por terminado, pero el equipo ha definido un nivel de calidad y una forma repetible de comprobarlo.
+## Guardar un punto de control
-Las **habilidades de agente** permiten proporcionar a Copilot directrices para realizar tareas repetibles, como ejecutar pruebas, generar compilaciones o crear solicitudes de incorporación de cambios. Una habilidad es una carpeta con instrucciones, scripts y recursos que el agente puede cargar bajo demanda. [Agent Skills es un estándar abierto][agent-skills-repo] que utilizan distintos agentes, por lo que la misma habilidad funciona en Copilot Chat en modo agente, el agente en la nube de Copilot, Copilot CLI y la aplicación GitHub Copilot.
+Tras revisar los cambios y la verificación, autoriza un commit local:
-Las habilidades se almacenan en la carpeta `.github/skills` de un proyecto o de forma global en `~/.copilot/skills`. Cada habilidad es una carpeta que contiene un archivo `SKILL.md` con frontmatter YAML, formado por un `name` y una `description`, seguido de las instrucciones en Markdown:
-
-```yaml
----
-name: quality-checks
-description: Run the project's test suites and linter to verify code changes are ready to commit, push, or merge.
----
+```plaintext
+Revisa las diferencias actuales y crea un commit de control para la implementación del filtrado y sus pruebas. Mantén esta misma rama y worktree de filtrado. No crees habilidades ni agentes, no configures MCP, no envíes cambios ni abras una solicitud de incorporación de cambios.
```
-Las habilidades también pueden incluir subcarpetas con scripts, recursos y material de referencia. La estructura completa se describe en la [especificación de habilidades de agente][agent-skills-spec].
-
-> [!TIP]
-> Las habilidades se cargan de forma dinámica. El agente decide cuál se aplica según el campo `description`; una descripción clara y específica del escenario marca la diferencia entre una habilidad que se utiliza y otra que se ignora.
-
-## Explorar la habilidad quality-checks
-
-Vamos a explorar la habilidad para ver qué hace.
-
-1. Si el panel de revisión aún no está visible, selecciona **Toggle review panel** en la esquina superior derecha para abrirlo.
-
- 
-
-2. Selecciona **+** para añadir un elemento nuevo al panel de revisión.
-3. Selecciona **File**.
-4. Busca `SKILL.md`.
-5. Selecciona `SKILL.md .github/skills/quality-checks` en la lista de archivos para abrirlo.
-6. Observa los campos `name` y `description`. La descripción indica al agente *cuándo* debe utilizar la habilidad: siempre que sea necesario probar, analizar con un linter o verificar cambios de código antes de una confirmación, un envío o una combinación.
-7. Lee la habilidad. Observa que documenta qué script ejecuta cada conjunto de pruebas, como las pruebas unitarias, las pruebas de un extremo a otro de Playwright y ESLint, en qué orden y cómo depurar errores habituales. Así, el agente ejecuta las comprobaciones según el proceso del equipo en lugar de adivinarlo.
-
-## Ejecutar las comprobaciones
-
-En la misma sesión de filtrado, pide al agente que verifique el trabajo. No mencionarás el nombre de la habilidad; el agente la identificará a partir de la solicitud.
-
-1. Vuelve a la aplicación Copilot.
-2. Llama directamente a la habilidad mediante el comando de barra diagonal `/quality-checks` y selecciona Enter.
-3. Siguiendo la habilidad, el agente ejecutará las pruebas unitarias, el linter y las pruebas de un extremo a otro, y comunicará los resultados. Si algo falla, pídele que corrija el problema y vuelva a ejecutar las comprobaciones hasta que todo se complete correctamente.
-4. **Mantén abierta esta sesión.** En la siguiente lección añadirás el servidor MCP de Playwright y lo utilizarás para comprobar la funcionalidad de filtrado en un navegador real.
-
-## Resumen y pasos siguientes
-
-Has creado una funcionalidad real de principio a fin y la has verificado según el nivel de calidad del equipo. En concreto:
-
-- has iniciado una sesión nueva desde la incidencia sobre filtrado en un proyecto actualizado.
-- has utilizado el modo Plan para planificar la funcionalidad y Autopilot para crearla.
-- has confirmado que la función auxiliar generada sigue el estándar de documentación que combinaste en la Lección 3.
-- has verificado el trabajo con la habilidad `quality-checks`.
-
-A continuación, conectarás el servidor MCP de Playwright y pedirás al agente que explore la funcionalidad de filtrado en un navegador real. Continúa con la [Lección 5 - Realizar pruebas con el servidor MCP de Playwright][next-lesson].
+Este punto de control forma parte de la PR 3, no de una PR independiente. Mantén el modo **Interactive** en la misma sesión para la [Lección 5 - Crear y utilizar una habilidad quality-checks][next-lesson].
## Recursos
- [Trabajar con sesiones de agente en la aplicación GitHub Copilot][agent-sessions]
-- [Acerca de Agent Skills][about-agent-skills]
-- [Personalizar la aplicación GitHub Copilot][customize-app]
- [Acerca de los entornos aislados locales y en la nube para GitHub Copilot][sandboxes]
-[ex0]: ../0-prerequisites/
-[ex2]: ../2-add-star-rating/
-[ex3]: ../3-custom-instructions/
-[next-lesson]: ../5-mcp-playwright/
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
\ No newline at end of file
diff --git a/docs/es-es/app/5-agent-skills.md b/docs/es-es/app/5-agent-skills.md
new file mode 100644
index 00000000..52747991
--- /dev/null
+++ b/docs/es-es/app/5-agent-skills.md
@@ -0,0 +1,93 @@
+---
+title: "Lección 5 - Crear y utilizar una habilidad quality-checks"
+description: "Pide a Copilot que cree comprobaciones de calidad reutilizables con scripts de shell incluidos, examina la habilidad y ejecútala en la rama de filtrado."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+La funcionalidad de filtrado está implementada y comprobada con los comandos npm existentes. Ahora reunirás esas comprobaciones en una **habilidad de agente** reutilizable. Mantén la misma sesión y rama de filtrado durante las Lecciones 4–8; esta lección no crea una solicitud de incorporación de cambios.
+
+En esta lección:
+
+- volverás al modo **Interactive** antes de crear personalizaciones.
+- pedirás a Copilot que cree `quality-checks` y después se detenga para que la examines.
+- ejecutarás las cuatro comprobaciones mediante los scripts incluidos y demostrarás que un argumento que indica un único archivo de pruebas selecciona solo ese archivo.
+- guardarás un punto de control de la habilidad junto con la funcionalidad de filtrado.
+
+## Instrucciones, scripts y recursos
+
+Las habilidades reúnen instrucciones de tareas reutilizables, scripts ejecutables y recursos de apoyo que un agente carga cuando los necesita. Los agentes personalizados definen roles especializados, instrucciones y herramientas disponibles. Son complementarios: un agente personalizado puede ejecutar scripts, incluidos los de una habilidad.
+
+Una habilidad del repositorio reside en `.github/skills//SKILL.md`, con `name` y `description` en el frontmatter e instrucciones en Markdown. Los scripts y otros recursos se encuentran junto a ese archivo. Pedirás a Copilot que genere `.github/skills/quality-checks/SKILL.md` y sus scripts incluidos, en lugar de copiar una solución preparada. La [especificación de Agent Skills][skill-spec] describe el formato.
+
+Copilot utiliza la descripción de una habilidad descubierta para decidir cuándo cargarla. No supongas que una habilidad nueva se descubre inmediatamente en una sesión ya abierta; la sección de ejecución incluye una alternativa de lectura explícita. Un formato portable no elimina los requisitos previos del shell o del proyecto.
+
+## Crear la habilidad
+
+Vuelve a poner la sesión de filtrado en modo **Interactive** mediante el selector de modo antes de enviar la indicación. Mantén la copia de trabajo y la rama actuales. Si empezaste con una plantilla antigua que ya contiene esta habilidad, examínala y amplíala en lugar de sobrescribir tus personalizaciones.
+
+```plaintext
+Crea .github/skills/quality-checks/SKILL.md y cuatro scripts envoltorio para npm run lint, npm run test:unit, npm run test:e2e y npm run typecheck:all. Lee primero package.json, README, la configuración de pruebas y las instrucciones del repositorio.
+
+Detecta este entorno. Crea SOLO scripts Bash .sh para macOS/Linux/WSL O scripts PowerShell .ps1 para Windows nativo; pregunta si no está claro. No crees ambos. Limita los scripts envoltorio a resolver la raíz del repositorio desde su propia ubicación, verificar que allí está el package.json de este proyecto e invocar npm. Si la raíz no es válida, falla con un mensaje claro. Admite cualquier directorio de trabajo y rutas con espacios. Conserva la salida y los códigos de salida de los fallos, incluidos los fallos de comandos nativos en PowerShell. Inserta el separador -- de npm exactamente una vez; quienes invoquen los scripts deben pasar directamente los argumentos de la herramienta, sin otro --. No gestiones puertos ni procesos.
+
+Incluye en SKILL.md un frontmatter con name y description, instrucciones para ejecutar los cuatro scripts envoltorio, requisitos previos, resolución de problemas y ejemplos portables que incluyan un archivo existente de pruebas unitarias. Todos los ejemplos de Bash deben invocar bash explícitamente; nunca eludas la directiva de ejecución de PowerShell. Explica la reutilización de servidores de Playwright: detén solo los servidores que hayas iniciado realmente; en caso contrario, pregunta.
+
+Crea únicamente la habilidad y los scripts necesarios. No ejecutes comprobaciones ni sondeos, no instales nada, no cambies código de la aplicación, no crees commits ni abras una PR. Detente para que pueda revisar los archivos.
+```
+
+## Examinar la habilidad
+
+1. Abre **Changes** para revisar los archivos generados. También puedes utilizar **+**, **File** en el panel de revisión y después buscar `SKILL.md` o los nombres de los scripts.
+2. Comprueba que `name` y `description` describen la habilidad y cuándo se aplica. Lee las instrucciones, no solo los metadatos.
+3. Confirma que la secuencia de ejecución invoca realmente los scripts incluidos bajo `.github/skills/quality-checks/` para lint, pruebas unitarias, E2E y comprobación de tipos.
+4. Examina en cada script envoltorio la resolución de la raíz relativa al script y la comprobación explícita de que el directorio calculado contiene el `package.json` previsto para esta copia de trabajo. Que un comando termine correctamente porque npm busca en directorios superiores no demuestra que la raíz sea correcta. Comprueba las rutas entre comillas, el reenvío de argumentos, la salida visible y los códigos de salida ante fallos; PowerShell debe propagar los fallos nativos de npm.
+5. Comprueba el ejemplo documentado de un único archivo de pruebas unitarias. El script envoltorio inserta el separador `--` de npm, por lo que quienes lo invoquen pasan directamente los argumentos de la herramienta de destino sin otro separador. Mantén las instrucciones reutilizables sin rutas absolutas de la copia de trabajo específicas de una máquina. Pide a Copilot que corrija las carencias antes de ejecutar nada.
+6. Limita los scripts a validar la raíz y el manifiesto y a ejecutar las comprobaciones npm existentes. Las decisiones sobre puertos y procesos corresponden a SKILL.md, no a código de gestión de procesos en shell. Confirma que solo se pueden detener servidores que el agente haya iniciado realmente; que coincidan el directorio de trabajo o el nombre del proceso no demuestra a quién pertenece. Los archivos entregados deben contener solo la habilidad, los scripts envoltorio necesarios y cualquier archivo auxiliar compartido que haga falta, sin archivos temporales de sondeo o depuración.
+
+> [!NOTE]
+> Tailspin Toys requiere actualmente Node.js 22.13 o posterior, las dependencias del proyecto y Chromium de Playwright para las comprobaciones E2E. Confirma los requisitos previos en README y `package.json` de tu copia de trabajo. Los requisitos previos ausentes o una directiva de ejecución de PowerShell que bloquee la ejecución necesitan una solución aprobada, no una instalación automática, una elusión de la directiva ni un cambio silencioso a npm directo.
+
+## Ejecutar la habilidad
+
+Confirma que el servidor de desarrollo de la lección anterior se ha detenido. Playwright compila y sirve una vista previa para E2E, pero su configuración local puede reutilizar un servidor en el puerto `4321`. Un servidor de otra copia de trabajo no proporciona pruebas de verificación válidas para tu funcionalidad.
+
+Si la aplicación ofrece `/quality-checks`, selecciónalo para invocar explícitamente la habilidad descubierta e incluye la solicitud siguiente. Si no se ha descubierto, envía la misma solicitud directamente en esta sesión; leer la habilidad es una alternativa admitida en este ejercicio.
+
+```plaintext
+Lee .github/skills/quality-checks/SKILL.md y sigue sus instrucciones para validar la funcionalidad de filtrado en esta copia de trabajo. Primero examina el código de cada script envoltorio para verificar que calcula el directorio que contiene el package.json previsto para esta copia de trabajo y falla de forma explícita si la raíz no es válida, en lugar de depender de que npm descubra paquetes en directorios superiores. No muevas, renombres, elimines ni modifiques archivos del repositorio para simular fallos. Ejecuta realmente los scripts incluidos para lint, pruebas unitarias, pruebas de un extremo a otro y comprobaciones de tipos. Ejecuta también el ejemplo documentado de un único archivo de pruebas unitarias, pasando directamente los argumentos de la herramienta de destino porque el script envoltorio se encarga del separador -- de npm. Verifica en los resultados del ejecutor de pruebas que SOLO se ha ejecutado el archivo indicado e informa de su nombre y del número de archivos de prueba ejecutados. Mostrar los argumentos o devolver el código de salida 0 no demuestra por sí solo que la selección sea correcta.
+
+Informa de cada invocación de script y su resultado, incluidos fallos, comprobaciones omitidas o requisitos previos ausentes. No sustituyas silenciosamente un script inutilizable de la habilidad por comandos npm directos. Identifica la copia de trabajo y el servidor que se prueban, detén solo los servidores que hayas iniciado y pregunta antes de instalar algo o detener otro proceso. No cambies código de la aplicación, no cambies de rama, no crees commits, no envíes cambios ni abras una solicitud de incorporación de cambios.
+```
+
+Examina las llamadas a herramientas y su salida. Los cuatro scripts deben ejecutarse realmente; una descripción de las comprobaciones o una comprobación omitida no equivale a superarlas. Para el ejemplo de un único archivo, compara el nombre de archivo solicitado con los resultados reales por archivo del ejecutor y el número comunicado: solo debe ejecutarse ese archivo. Mostrar los argumentos o devolver el código de salida 0 es insuficiente si también se ejecutaron otros archivos. Un fallo aporta información útil: corrige la habilidad o resuelve el bloqueo de configuración con aprobación y después repite las comprobaciones afectadas. No detengas procesos ajenos ni fuerces la resolución de un conflicto de puerto.
+
+## Guardar un punto de control
+
+Cuando hayas revisado la habilidad y sus resultados, autoriza un punto de control local:
+
+```plaintext
+Revisa las diferencias actuales y crea un commit de punto de control solo para los archivos de la habilidad quality-checks. Mantén la rama de filtrado existente. No envíes cambios ni crees una solicitud de incorporación de cambios.
+```
+
+Los archivos de la habilidad acompañarán al filtrado, al perfil de QA y a las pruebas asociadas en la PR de funcionalidad de la Lección 8. Continúa en esta misma sesión con la [Lección 6 - Validar la funcionalidad con MCP de Playwright][next-lesson].
+
+## Ejemplos adicionales de habilidades
+
+Estos ejemplos de la comunidad son referencias, no tareas adicionales. Revisa sus requisitos previos y su comportamiento antes de adoptarlos:
+
+- [Flujo de contribución: `make-repo-contribution`][contribution-example].
+- [Documentos de requisitos: `prd`][prd-example].
+- [Diagramas y un script de exportación incluido: `drawio`][drawio-example].
+- [Pruebas de navegador: `webapp-testing`][browser-example].
+
+El ejemplo de contribución original se llama `make-repo-contribution`; las plantillas antiguas de Tailspin utilizaban otro nombre, `make-contribution`. Este taller no depende de ninguna de esas habilidades de contribución.
+
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/es-es/app/5-mcp-playwright.md b/docs/es-es/app/5-mcp-playwright.md
deleted file mode 100644
index 705fe8cd..00000000
--- a/docs/es-es/app/5-mcp-playwright.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: "Lección 5 - Realizar pruebas con el servidor MCP de Playwright"
-description: "Añade el servidor MCP de Playwright a la aplicación GitHub Copilot y pide al agente que pruebe manualmente la funcionalidad de filtrado en un navegador real."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-En la lección anterior creaste y verificaste la funcionalidad de filtrado con el conjunto de pruebas automatizadas del proyecto. Las pruebas automatizan la validación del código, pero permitir que el agente confirme el comportamiento también resulta muy útil. Así puede responder a los problemas que detecte en la interfaz de usuario que está creando. Vamos a explorar cómo MCP proporciona a los agentes de IA acceso a capacidades externas y a añadir el servidor MCP de Playwright para que Copilot pueda interactuar directamente con el sitio que estás desarrollando.
-
-En esta lección:
-
-- comprenderás qué es Model Context Protocol (MCP) y cómo lo utiliza la aplicación GitHub Copilot.
-- añadirás el servidor MCP de Playwright desde la configuración de la aplicación.
-- pedirás al agente que controle un navegador y explore la funcionalidad de filtrado.
-
-## Escenario
-
-Aunque las pruebas unitarias y de un extremo a otro son importantes, validar las actualizaciones de la interfaz de usuario requiere interactuar con ella. Quieres que Copilot pueda utilizar el sitio web en el que trabajas como lo haría un usuario para automatizar aún más los cambios y aumentar la confianza en que las actualizaciones funcionan según lo previsto.
-
-## ¿Qué es Model Context Protocol (MCP)?
-
-[Model Context Protocol (MCP)][mcp-blog-post] proporciona a los agentes de IA una forma de comunicarse con herramientas y servicios externos. Mediante MCP, los agentes de IA pueden comunicarse con ellos en tiempo real. Esto les permite acceder a información actualizada mediante recursos y realizar acciones en tu nombre mediante herramientas.
-
-Se accede a estas herramientas y recursos a través de un servidor MCP, que actúa como puente entre el agente de IA y las herramientas y servicios externos. El servidor MCP gestiona la comunicación entre el agente de IA y las herramientas externas, como API existentes o herramientas locales, por ejemplo, paquetes NPM. Cada servidor MCP representa un conjunto diferente de herramientas y recursos a los que puede acceder el agente de IA.
-
-Dos servidores MCP populares son:
-
-- [**GitHub MCP Server**](https://github.com/github/github-mcp-server): proporciona acceso a un conjunto de API para gestionar repositorios de GitHub. Permite al agente de IA realizar acciones como crear repositorios, actualizar los existentes y gestionar incidencias y solicitudes de incorporación de cambios.
-- [**Playwright MCP Server**][playwright-mcp-server]: proporciona capacidades de automatización del navegador mediante Playwright. Permite al agente de IA realizar acciones como visitar páginas web, completar formularios y seleccionar botones.
-
-Hay muchos otros servidores MCP que proporcionan acceso a distintas herramientas y recursos. GitHub aloja un [registro de MCP](https://github.com/mcp) para facilitar su descubrimiento y las contribuciones al ecosistema.
-
-> [!CAUTION]
-> Trata los servidores MCP como cualquier otra dependencia del proyecto. Antes de utilizar uno, revisa atentamente su código fuente, verifica el editor y considera las implicaciones de seguridad. Utiliza únicamente servidores MCP de confianza y ten cuidado al conceder acceso a recursos u operaciones confidenciales.
-
-## Añadir el servidor MCP de Playwright
-
-Los servidores MCP se añaden y gestionan desde la configuración de la aplicación. La aplicación incluye un catálogo de servidores populares, por lo que el [servidor MCP de Playwright][playwright-mcp-server] está a solo un par de selecciones.
-
-1. Selecciona Ctrl+, para abrir la página de configuración de la aplicación Copilot.
-2. Selecciona **MCP servers**.
-3. En el cuadro de búsqueda, escribe `Playwright`.
-4. Selecciona **Playwright** en la lista de **Popular MCP servers**.
-5. Selecciona **Add server** para añadirlo a la lista de servidores MCP disponibles.
-6. Selecciona Esc para cerrar el cuadro de diálogo de configuración.
-
-Ya has añadido el servidor MCP de Playwright.
-
-## Pedir a Copilot que explore la funcionalidad mediante Playwright
-
-Vamos a pedir a Copilot que pruebe manualmente la funcionalidad mediante el servidor MCP de Playwright.
-
-1. Utiliza la indicación siguiente para pedir a Copilot que valide la nueva funcionalidad:
-
- ```plaintext
- Start the dev server then use the Playwright MCP server to validate the functionality you just added exists. Use the details in the issue to ensure the newly added behavior matches the specs.
- ```
-
-Copilot iniciará un navegador mediante el servidor MCP de Playwright, recorrerá cada paso y comunicará lo que encuentre. Verás cómo abre un navegador en el sistema para realizar las tareas.
-
-2. Compara el resumen con los criterios de aceptación de la incidencia. Si algo no parece correcto, formula preguntas de seguimiento o pide al agente que corrija el código antes de abrir una solicitud de incorporación de cambios.
-3. Mantén abierta esta sesión, ya que la completaremos en la siguiente lección.
-
-Copilot también ha validado la funcionalidad en el navegador mediante la exploración de la característica como lo haría un usuario.
-
-## Resumen y pasos siguientes
-
-Has utilizado el servidor MCP de Playwright para explorar la funcionalidad en un navegador real desde la aplicación GitHub Copilot. En resumen:
-
-- has aprendido qué es Model Context Protocol (MCP) y cómo la aplicación pone a disposición las herramientas MCP.
-- has añadido el servidor MCP de Playwright desde la configuración de la aplicación.
-- has pedido al agente que controle un navegador y explore la funcionalidad de filtrado.
-
-La funcionalidad está creada, verificada y en funcionamiento. Ahora toca publicarla mediante **Agent Merge**, que abrirá y combinará la solicitud de incorporación de cambios. Continúa con la [Lección 6 - Combinar cambios con Agent Merge][next-lesson].
-
-## Recursos
-
-- [¿Qué es MCP y por qué todo el mundo habla de él?][mcp-blog-post]
-- [Servidor MCP de Playwright de Microsoft][playwright-mcp-server]
-- [Configurar servidores MCP en la aplicación GitHub Copilot][customize-app]
-
-[next-lesson]: ../6-agent-merge/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
\ No newline at end of file
diff --git a/docs/es-es/app/6-agent-merge.md b/docs/es-es/app/6-agent-merge.md
deleted file mode 100644
index b29b7903..00000000
--- a/docs/es-es/app/6-agent-merge.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: "Lección 6 - Combinar cambios con Agent Merge"
-description: "Abre la solicitud de incorporación de cambios del filtrado, revísala en My work y deja que Agent Merge corrija los bloqueos y la combine por ti, el nivel más alto de la automatización de combinaciones."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-La funcionalidad de filtrado está creada, verificada y en funcionamiento en un navegador. El último paso es combinarla. Ya has combinado dos cambios en este recorrido; en ambos casos abriste la solicitud de incorporación de cambios y la combinaste personalmente en github.com. Esta vez dejarás que la aplicación se encargue del trabajo con **Agent Merge**, que guía una solicitud durante todo su ciclo de vida desde la aplicación.
-
-En esta lección:
-
-- aprenderás qué es Agent Merge y cómo automatiza el ciclo de vida de una combinación.
-- habilitarás Agent Merge en la sesión de filtrado.
-- observarás cómo crea la solicitud de incorporación de cambios, ejecuta CI y la combina cuando todo se completa correctamente.
-
-## Escenario
-
-En los últimos módulos has explorado distintos niveles de automatización, desde crear código hasta permitir que Copilot valide directamente una interfaz de usuario. Para acelerar aún más el desarrollo, Tailspin Toys quiere averiguar si las solicitudes de incorporación de cambios que ya se han revisado y validado pueden combinarse automáticamente.
-
-## Introducción a Agent Merge
-
-**Agent Merge** permite automatizar el último tramo de la incorporación de una solicitud de cambios mediante la aplicación Copilot. Al habilitarlo, la sesión de la aplicación lee la solicitud y resuelve lo que la bloquea: corrige comprobaciones de CI con errores, responde a comentarios de revisión y reorganiza la base cuando es necesario. Después la combina en cuanto GitHub lo permite. Se ejecuta en segundo plano, continúa tras reiniciar la aplicación y se desactiva cuando se combina la solicitud.
-
-Hasta ahora, tú seleccionabas **Merge pull request** en github.com. Agent Merge transfiere esa responsabilidad al agente para que puedas pasar a la siguiente tarea mientras este guía la solicitud hasta completarla. Sigues revisando y aprobando el trabajo; el agente se ocupa del proceso mecánico final.
-
-## Utilizar Agent Merge para gestionar la solicitud
-
-Has revisado el código manualmente, ejecutado pruebas e incluso permitido que Copilot valide la interfaz de usuario. Ha llegado el momento de combinar el código nuevo con el código base. Vamos a permitir que Agent Merge guíe la solicitud durante la integración continua (CI) y la combine.
-
-1. Vuelve a la sesión que mantuviste abierta en el módulo anterior mientras añadías la funcionalidad de filtrado.
-2. En la esquina superior derecha, selecciona el menú desplegable situado junto a **Create PR**.
-3. Selecciona **Agent merge** para habilitar Agent Merge.
-
- 
-
-4. El texto del botón cambia a **Agent merge**.
-5. Selecciona el botón **Agent merge** para iniciar el proceso.
-
-La aplicación Copilot comenzará a crear y gestionar la solicitud. Primero explora el proyecto para determinar la mejor forma de crearla y, después, genera la nueva solicitud.
-
-Transcurridos unos instantes, observarás que Copilot vuelve a trabajar y examina las condiciones de la solicitud, incluido el proceso de CI que ejecuta todas las pruebas del repositorio. Comunicará el estado de las revisiones de otros miembros del equipo, las comprobaciones que deben ejecutarse y si la solicitud puede combinarse.
-
-6. Permite que Agent Merge combine la solicitud seleccionando el menú desplegable situado junto a **Agent merge** y, después, **Merge pull request**.
-
- 
-
-7. Cuando todos los procesos de CI estén en verde, lo que significa que las pruebas han finalizado correctamente, Copilot combinará la solicitud.
-
-## Resumen y pasos siguientes
-
-Has automatizado varias partes del proceso de desarrollo, como la generación, las pruebas y la validación de código, y ahora también el proceso de solicitud de incorporación de cambios. En concreto:
-
-- has aprendido qué es Agent Merge y cómo automatiza el ciclo de vida de una combinación.
-- has habilitado Agent Merge en la sesión de filtrado.
-- has observado cómo crea la solicitud de incorporación de cambios, ejecuta CI y la combina cuando todo se completa correctamente.
-
-A continuación, explorarás los **lienzos**, una forma más completa de planificar y visualizar el trabajo con el agente. Continúa con la [Lección 7 - Planificar con lienzos][next-lesson].
-
-## Recursos
-
-- [Gestionar incidencias y solicitudes de incorporación de cambios con la aplicación GitHub Copilot][managing-issues-prs]
-- [Acerca de la aplicación GitHub Copilot][about-copilot-app]
-
-[next-lesson]: ../7-canvases/
-[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/es-es/app/6-mcp-playwright.md b/docs/es-es/app/6-mcp-playwright.md
new file mode 100644
index 00000000..82712159
--- /dev/null
+++ b/docs/es-es/app/6-mcp-playwright.md
@@ -0,0 +1,90 @@
+---
+title: "Lección 6 - Validar la funcionalidad con MCP de Playwright"
+description: "Configura MCP de Playwright mediante Customize y observa el filtrado en un navegador desde el worktree existente de la funcionalidad."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+En la lección anterior agrupaste y ejecutaste las comprobaciones del proyecto mediante tu habilidad quality-checks. Ahora da al agente acceso a un navegador para que pueda observar directamente la interfaz de filtrado. Permanece en la misma sesión, worktree y rama de filtrado. Esta lección aporta pruebas de observación en el navegador, no otra funcionalidad, una nueva ejecución de todo el conjunto de pruebas ni una PR.
+
+En esta lección:
+
+- comprenderás qué es Model Context Protocol (MCP) y cómo lo utiliza la aplicación GitHub Copilot.
+- añadirás el servidor MCP de Playwright mediante **Customize**.
+- pedirás al agente que controle un navegador y explore la funcionalidad de filtrado.
+
+## Escenario
+
+Aunque las pruebas unitarias y de un extremo a otro son importantes, validar las actualizaciones de la interfaz de usuario requiere interactuar con ella. Quieres que Copilot pueda utilizar el sitio web en el que trabajas como lo haría un usuario para automatizar aún más los cambios y aumentar la confianza en que las actualizaciones funcionan según lo previsto.
+
+## ¿Qué es Model Context Protocol (MCP)?
+
+[Model Context Protocol (MCP)][mcp-blog-post] proporciona a los agentes de IA una forma de comunicarse con herramientas y servicios externos. Mediante MCP, los agentes de IA pueden comunicarse con ellos en tiempo real. Esto les permite acceder a información actualizada mediante recursos y realizar acciones en tu nombre mediante herramientas.
+
+Se accede a estas herramientas y recursos a través de un servidor MCP, que actúa como puente entre el agente de IA y las herramientas y servicios externos. El servidor MCP gestiona la comunicación entre el agente de IA y las herramientas externas, como API existentes o herramientas locales, por ejemplo, paquetes NPM. Cada servidor MCP representa un conjunto diferente de herramientas y recursos a los que puede acceder el agente de IA.
+
+Dos servidores MCP populares son:
+
+- [**GitHub MCP Server**](https://github.com/github/github-mcp-server): proporciona acceso a un conjunto de API para gestionar repositorios de GitHub. Permite al agente de IA realizar acciones como crear repositorios, actualizar los existentes y gestionar incidencias y solicitudes de incorporación de cambios.
+- [**Playwright MCP Server**][playwright-mcp-server]: proporciona capacidades de automatización del navegador mediante Playwright. Permite al agente de IA realizar acciones como visitar páginas web, completar formularios y seleccionar botones.
+
+Hay muchos otros servidores MCP que proporcionan acceso a distintas herramientas y recursos. GitHub aloja un [registro de MCP](https://github.com/mcp) para facilitar su descubrimiento y las contribuciones al ecosistema.
+
+> [!CAUTION]
+> Trata los servidores MCP como cualquier otra dependencia del proyecto. Antes de utilizar uno, revisa atentamente su código fuente, verifica el editor y considera las implicaciones de seguridad. Utiliza únicamente servidores MCP de confianza y ten cuidado al conceder acceso a recursos u operaciones confidenciales.
+
+## Añadir el servidor MCP de Playwright
+
+La [documentación actual de personalización de la aplicación][customize-app] utiliza **Customize** en la barra lateral para descubrir y gestionar MCP. Los servidores MCP configurados para tus repositorios o Copilot CLI pueden estar ya disponibles en la aplicación; examina los servidores instalados antes de añadir un duplicado.
+
+1. Selecciona **Customize** en la barra lateral.
+2. Selecciona **MCP** y comprueba en **Installed** si ya existe un servidor de Playwright.
+3. Si es necesario, busca **Playwright** entre los servidores disponibles o utiliza el procedimiento de servidor personalizado documentado por el editor.
+4. Revisa el editor, la configuración y cualquier solicitud de instalación antes de aprobarla. Sigue las indicaciones para añadir el servidor; las directivas de la organización o la falta de requisitos previos pueden bloquear la configuración.
+5. Vuelve a la sesión de filtrado existente y mantén el modo **Interactive**. Confirma que las herramientas de navegador de MCP de Playwright están disponibles antes de solicitar la validación. No crees un worktree nuevo de la funcionalidad para solucionar problemas de configuración.
+
+Si la configuración falla, resuelve el problema de configuración o permisos en lugar de aceptar una afirmación de que el agente ha navegado sin herramientas. La visibilidad del navegador depende de la configuración del servidor; la actividad real de las herramientas y las observaciones son las pruebas.
+
+## Pedir a Copilot que explore la funcionalidad mediante Playwright
+
+Utiliza la URL real de la incidencia y las aclaraciones aprobadas que guardaste en la Lección 4. Detén cualquier servidor de desarrollo manual de lecciones anteriores antes de que el agente inicie el suyo. Debe identificar la copia de trabajo y el servidor que está probando.
+
+1. Utiliza la indicación siguiente para pedir a Copilot que valide la nueva funcionalidad:
+
+ ```plaintext
+ Utiliza el servidor MCP de Playwright configurado para observar la funcionalidad de filtrado según esta incidencia: . Estas son mis aclaraciones de planificación aprobadas: . Permanece en este worktree y rama de filtrado.
+
+ Identifica la copia de trabajo, inicia su servidor de desarrollo y utiliza herramientas reales de navegador para probar la selección de varias categorías, el filtrado por editor, el filtrado combinado, los controles accesibles y cualquier comportamiento acordado de borrado de filtros o resultados vacíos. Informa de las observaciones frente a los criterios, incluidos fallos o comprobaciones bloqueadas. No afirmes comportamientos que no hayas observado.
+
+ Este paso es una observación en el navegador, no otra ejecución automatizada completa de pruebas. No cambies código de la aplicación, pruebas, habilidades ni perfiles de agente, no crees commits, no envíes cambios ni crees una PR. Informa como bloqueadas las herramientas MCP o los requisitos previos ausentes y pregunta antes de instalar cualquier cosa. No reutilices el servidor de otra copia de trabajo ni detengas procesos ajenos. Al terminar, detén solo el servidor que hayas iniciado.
+ ```
+
+Examina las llamadas a herramientas MCP de Playwright, la URL probada y las observaciones comunicadas del navegador. Un relato basado solo en el código fuente o en resultados E2E anteriores no demuestra el uso de MCP.
+
+2. Compara el resumen con la incidencia y las aclaraciones aprobadas. Si hay un defecto, autoriza por separado una corrección específica, revisa las diferencias y repite las comprobaciones automatizadas y observaciones del navegador pertinentes. Las pruebas anteriores a la corrección no demuestran la revisión resultante.
+3. Confirma que el agente ha detenido su propio servidor. Mantén abierta esta sesión de filtrado y permanece en modo **Interactive** antes de crear el perfil QA en la Lección 7.
+
+Esta etapa aporta observación directa, no sustituye la cobertura automatizada. Los fallos y las observaciones bloqueadas siguen siendo visibles para QA.
+
+## Resumen y pasos siguientes
+
+Has utilizado el servidor MCP de Playwright para explorar la funcionalidad en un navegador real desde la aplicación GitHub Copilot. En resumen:
+
+- has aprendido qué es Model Context Protocol (MCP) y cómo la aplicación pone a disposición las herramientas MCP.
+- has configurado el servidor MCP de Playwright mediante **Customize**.
+- has pedido al agente que controle un navegador y explore la funcionalidad de filtrado.
+
+A continuación, reúne los requisitos, las observaciones del navegador, la cobertura y la habilidad en un perfil especializado. Continúa en esta misma sesión con la [Lección 7 - Crear y utilizar un agente QA][next-lesson]. No crees todavía la PR de la funcionalidad.
+
+## Recursos
+
+- [¿Qué es MCP y por qué todo el mundo habla de él?][mcp-blog-post]
+- [Servidor MCP de Playwright de Microsoft][playwright-mcp-server]
+- [Configurar servidores MCP en la aplicación GitHub Copilot][customize-app]
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
+[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
\ No newline at end of file
diff --git a/docs/es-es/app/7-canvases.md b/docs/es-es/app/7-canvases.md
deleted file mode 100644
index 2272a3bc..00000000
--- a/docs/es-es/app/7-canvases.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: "Lección 7 - Planificar con lienzos"
-description: "Crea un lienzo compartido y dirigido por agentes en la aplicación GitHub Copilot para planificar y realizar el seguimiento del trabajo junto con el agente."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-Hasta ahora has dirigido a los agentes mediante el chat. Sin embargo, gran parte del trabajo no reside en una conversación, sino en un tablero, un documento o una lista de comprobación. Los **lienzos** ofrecen al agente y a ti una superficie compartida para ese tipo de trabajo, directamente en la aplicación. En esta lección crearás un lienzo sencillo para planificar y realizar el seguimiento de la lista de trabajo pendiente que has estado abordando.
-
-En esta lección:
-
-- comprenderás qué es un lienzo y cuándo utilizarlo.
-- crearás un lienzo compartido con un tablero Kanban para clasificar la lista de trabajo pendiente.
-- guardarás el lienzo en el repositorio y lo combinarás para el equipo.
-- abrirás el lienzo en una sesión nueva y empezarás a trabajar desde él.
-
-## Escenario
-
-Examinar una lista de incidencias puede resultar abrumador, incluso en las mejores circunstancias. Los desarrolladores de Tailspin Toys buscan una herramienta que les permita clasificar las incidencias con rapidez y empezar a trabajar en ellas desde la aplicación Copilot.
-
-## ¿Qué es un lienzo?
-
-Un [lienzo][canvas-docs] es una superficie interactiva y compartida para un recurso de trabajo, como un plan, un tablero de clasificación, una lista de comprobación de versiones, un panel o un documento. Aunque el chat resulta adecuado para describir intenciones y razonar sobre ambigüedades, la mayor parte del trabajo se realiza en una *superficie*. Los lienzos permiten colaborar con el agente directamente sobre ella.
-
-Los lienzos son **bidireccionales**: el agente puede actualizar el lienzo mientras trabaja y tú puedes editar la misma superficie. Cuando creas un lienzo, el agente lo genera a partir de la indicación y el flujo de trabajo, y puedes pedirle que añada, elimine o revise capacidades a medida que avanzas. Una vez creado, el lienzo se abre en el panel derecho de la aplicación.
-
-Algunos ejemplos habituales son:
-
-- **Lienzos de Markdown** para planificar el día y priorizar incidencias y solicitudes de incorporación de cambios.
-- **Tableros Kanban con agentes** en los que las personas y los agentes añaden tarjetas y desplazan el trabajo entre columnas.
-- **Tableros de clasificación de incidencias** que resumen las incidencias principales y los temas recurrentes de un repositorio.
-
-## ¿Por qué utilizar un lienzo?
-
-Utiliza un lienzo cuando una tarea requiera estructura, iteración y verificación, y un chat no sea suficiente. Un lienzo permite:
-
-- basar el trabajo del agente en un recurso real que se adapte al flujo de trabajo.
-- orientar o corregir el trabajo directamente en la superficie compartida y, después, permitir que el agente continúe a partir de los cambios.
-- inspeccionar el progreso como cambios visibles en un recurso, no solo como respuestas del chat.
-
-## Crear un lienzo para realizar el seguimiento del trabajo
-
-Has publicado numerosos cambios: la valoración por estrellas, el estándar de documentación y la funcionalidad de filtrado ya están combinados. Sin embargo, todavía quedan elementos en la lista de trabajo pendiente. Vamos a crear el lienzo para clasificar el trabajo con rapidez.
-
-1. Vuelve a la aplicación GitHub Copilot o ábrela.
-2. Selecciona **Home screen**.
-3. Comprueba que `tailspin-toys` esté seleccionado como repositorio.
-4. En el cuadro de indicaciones, utiliza la indicación siguiente para crear un lienzo que satisfaga nuestras necesidades:
-
- ```plaintext
- Create a basic Kanban board canvas that allows me to quickly triage work. Highlight the three issues which are most likely to need attention right now, with the remainder in a second section down below. The top three cards should include a description of the issue's content and a justification of why they're at the top of the list. Each issue should have a button that allows me to add it to the current context for the current session so I can get to work on it straightaway.
- ```
-
-Copilot comenzará a crear el lienzo.
-
-> [!NOTE]
-> La creación tardará unos minutos. Como se trata de una tarea compleja, es posible que la primera versión no te satisfaga. Puedes seguir enviando indicaciones hasta crear la herramienta que necesitas.
-
-## Guardar el lienzo y combinarlo con el repositorio
-
-Los lienzos pueden convertirse en recursos del repositorio, al igual que los archivos de instrucciones y las habilidades. Vamos a pedir a Copilot que lo añada al repositorio y lo combine para que pueda utilizarlo todo el equipo.
-
-1. En la misma sesión, pide a Copilot que guarde el lienzo en el repositorio mediante la indicación siguiente:
-
- ```plaintext
- Let's save this canvas definition to the repository so I can share it with my development team
- ```
-
-2. Cuando Copilot haya guardado los archivos del lienzo, selecciona el menú desplegable situado junto a **Create PR** en la esquina superior derecha.
-3. Selecciona **Agent merge** para habilitar Agent Merge.
-
- 
-
-4. El texto del botón cambia a **Agent merge**.
-5. Selecciona el botón **Agent merge** para iniciar el proceso.
-
-La aplicación Copilot comenzará a crear y gestionar la solicitud. Primero explora el proyecto para determinar la mejor forma de crearla y, después, la genera.
-
-Transcurridos unos instantes, observarás que Copilot vuelve a trabajar y examina las condiciones de la solicitud, incluido el proceso de CI que ejecuta todas las pruebas del repositorio. Comunicará el estado de las revisiones de otros miembros del equipo, las comprobaciones que deben ejecutarse y si la solicitud puede combinarse.
-
-6. Permite que Agent Merge combine la solicitud seleccionando el menú desplegable situado junto a **Agent merge** y, después, **Merge pull request**.
-
- 
-
-7. Espera a que todos los procesos de CI se completen correctamente y se muestren en verde. Cuando terminen, Copilot combinará automáticamente la solicitud.
-
-Ya has creado un lienzo compartido para el equipo.
-
-## Trabajar en el lienzo
-
-Con el lienzo creado, vamos a iniciar una sesión nueva y utilizarlo.
-
-1. En la aplicación Copilot, selecciona **New session** junto a **tailspin-toys** para iniciar una sesión nueva.
-2. Pide a Copilot que abra el lienzo de clasificación mediante la indicación siguiente:
-
- ```plaintext
- Open the triage issues canvas
- ```
-
-3. El lienzo que has creado debería abrirse en la sesión nueva.
-4. Selecciona **Add to current context** en una de las incidencias que más te interese.
-5. Copilot empezará a trabajar en la incidencia.
-
-Has utilizado un lienzo creado por ti para agilizar el proceso de desarrollo.
-
-## Resumen y pasos siguientes
-
-Has creado una superficie compartida en la que puedes colaborar con el agente. En concreto:
-
-- has aprendido qué son los lienzos y cuándo utilizarlos.
-- has creado con el agente un lienzo compartido con un tablero Kanban para clasificar incidencias.
-- has guardado y combinado el lienzo con el repositorio mediante Agent Merge.
-- has abierto el lienzo en una sesión nueva y lo has utilizado para empezar a trabajar.
-
-Con la lista de trabajo pendiente organizada, da un paso atrás para revisar todo lo que has creado y descubrir cómo continuar. Continúa con la [Lección 8 - Repaso y pasos siguientes][next-lesson].
-
-## Recursos
-
-- [Trabajar con extensiones de lienzo en la aplicación GitHub Copilot][canvas-docs]
-- [Lienzos en Awesome Copilot][awesome-copilot-canvases]
-- [Acerca de la aplicación GitHub Copilot][about-copilot-app]
-
-[next-lesson]: ../8-review/
-[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
-[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/es-es/app/7-qa-agent.md b/docs/es-es/app/7-qa-agent.md
new file mode 100644
index 00000000..689d9a84
--- /dev/null
+++ b/docs/es-es/app/7-qa-agent.md
@@ -0,0 +1,73 @@
+---
+title: "Lección 7 - Crear y utilizar un agente de QA"
+description: "Crea un perfil de QA que parta de los requisitos y combine cobertura de pruebas, la habilidad quality-checks y observaciones directas del navegador."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Has ejecutado comprobaciones repetibles y explorado el filtrado mediante MCP de Playwright. Ahora crea un **agente personalizado de QA** para reunir los requisitos, la cobertura y las observaciones del navegador. Mantén la sesión, la copia de trabajo y la rama de filtrado; la PR de funcionalidad llegará en la Lección 8.
+
+## Crear el perfil de QA
+
+Mantén el modo **Interactive**. Un perfil define el rol y las instrucciones de un especialista; una habilidad reúne instrucciones de tareas reutilizables, scripts y recursos. El agente de QA utilizará tu habilidad y las herramientas MCP configuradas en lugar de sustituirlas.
+
+Envía esta indicación y después examina la definición antes de ejecutarla:
+
+```plaintext
+Crea un agente personalizado de QA reutilizable en .github/agents/qa.agent.md. Primero examina las instrucciones del repositorio, package.json, la configuración de pruebas y .github/skills/quality-checks/SKILL.md. Proporciona al perfil un frontmatter YAML válido con name establecido en QA y una description que explique cuándo utilizarlo. No fijes un modelo ni añadas una lista tools; hereda las herramientas y los permisos disponibles del entorno. Crea solo la definición del agente y después detente para que pueda examinarla antes de ejecutarlo.
+
+En las instrucciones del agente, exige que toda tarea de QA parta de la incidencia y de los criterios de aceptación aprobados que proporcione el usuario. Trata estos requisitos como fuente de verdad, no la implementación. Pregunta cuando falten requisitos o sean ambiguos. Examina la funcionalidad y las pruebas existentes y relaciona cada criterio con la cobertura automatizada adecuada y el comportamiento observable.
+
+Exige validación directa en el navegador mediante el servidor MCP de Playwright configurado y la ejecución de lint, pruebas unitarias, pruebas de un extremo a otro y comprobaciones de tipos mediante la habilidad quality-checks existente y sus scripts incluidos. Lee la habilidad explícitamente si no se ha descubierto automáticamente. Informa de la ausencia de habilidades, herramientas MCP, requisitos previos o acceso como bloqueos; no sustituyas silenciosamente el flujo por otro ni etiquetes comprobaciones omitidas como superadas. Identifica la copia de trabajo y el servidor que se prueban, evita reutilizar el servidor de otro worktree, detén solo los servidores que haya iniciado el agente y pregunta antes de cualquier instalación o de detener otro proceso.
+
+Permite que el agente de QA añada las pruebas mínimas necesarias para carencias reales de cobertura, siguiendo las instrucciones del repositorio; no añadir pruebas es válido cuando la cobertura ya es adecuada. No debilites aserciones, no desactives pruebas fallidas, no cambies los criterios de aceptación para ajustarlos al código ni modifiques código de la aplicación sin mi aprobación. Tras los cambios, repite las comprobaciones afectadas y completa la verificación final de la revisión resultante. Exige un informe conciso que relacione los criterios con las pruebas de verificación y el estado superado/fallido/bloqueado, enumere las pruebas añadidas o explique por qué no hicieron falta, comunique los resultados de las cuatro comprobaciones e identifique los defectos sin resolver. GO exige todas las comprobaciones y pruebas de verificación obligatorias; de lo contrario, informa de NO-GO y su motivo. No cambies de rama, no crees commits, no envíes cambios, no abras ni combines PR y no crees agentes o habilidades adicionales durante QA.
+```
+
+## Examinar el perfil
+
+Abre `.github/agents/qa.agent.md` en **Changes** o en el panel de revisión de archivos. `description` es obligatorio; esta lección también proporciona `QA` como `name` legible. Confirma que no se ha fijado un `model` ni inventado una lista de herramientas. Omitir `tools` hereda las herramientas disponibles; no elude los permisos del entorno. Los perfiles de producción pueden restringir las herramientas deliberadamente.
+
+Confirma que las instrucciones parten de los requisitos, exigen actividad real del navegador mediante MCP y scripts de la habilidad, permiten solo adiciones de pruebas justificadas e informan de los bloqueos con veracidad. Ni un perfil especializado ni una habilidad requieren una ventana de contexto independiente o la orquestación de otros agentes.
+
+## Ejecutar QA frente a la incidencia
+
+La indicación de ejecución es para el agente personalizado **QA** seleccionado, no para el agente predeterminado que lee un perfil. Mantén la misma copia de trabajo y rama de filtrado.
+
+1. En la sesión actual, abre el selector de agentes del cuadro de la indicación o introduce `/agent`, como describe la [documentación de personalización de la aplicación][customize-app].
+2. Selecciona **QA** y verifica que la aplicación identifica visiblemente a **QA** como agente activo antes de enviar la indicación de ejecución.
+3. Si **QA** no aparece o no puedes confirmar que está activo, detente y pregunta a la persona que dirige el taller, conservando este worktree y rama. No crees otra sesión de funcionalidad, no inventes una secuencia de recarga ni sustituyas este paso por una solicitud al agente predeterminado para que lea `qa.agent.md`.
+
+El selector documentado está disponible durante una sesión, pero el descubrimiento de un perfil de repositorio recién creado puede depender de la versión de la aplicación. No trates la creación del archivo como prueba de activación.
+
+Sustituye ambos marcadores por la URL real de la incidencia de filtrado y las aclaraciones aprobadas en la Lección 4, o por `none` si la incidencia está completa. No dependas de la memoria del agente anterior.
+
+```plaintext
+Verifica la funcionalidad de filtrado frente a esta incidencia: . Estos son los criterios de aceptación adicionales que aprobé durante la planificación: .
+
+Valida el comportamiento con el servidor MCP de Playwright, examina la cobertura de pruebas, añade pruebas solo para carencias de cobertura y ejecuta la validación mediante la habilidad quality-checks. Informa de las pruebas de verificación, los resultados de las comprobaciones y los bloqueos. No cambies código de la aplicación sin mi aprobación, no crees un commit ni abras una solicitud de incorporación de cambios.
+```
+
+## Revisar las pruebas de verificación
+
+Contrasta el informe con la incidencia: cada criterio necesita cobertura automatizada adecuada y comportamiento observable. Examina la actividad real de las herramientas MCP de Playwright, la identidad de la copia de trabajo y del servidor y los resultados de los cuatro scripts de la habilidad. Las comprobaciones de navegador y E2E automatizadas no deben reutilizar un servidor obsoleto ni otra copia de trabajo.
+
+Revisa las pruebas añadidas: deben cubrir carencias reales sin debilitar las aserciones. No añadir pruebas es correcto cuando la cobertura es adecuada. Un dictamen **NO-GO** por bloqueo o fallo es un resultado válido, no permiso para omitir pruebas de verificación.
+
+Si QA identifica un defecto de la aplicación, aprueba por separado una corrección específica y repite las comprobaciones y observaciones de navegador afectadas en la revisión resultante. La ausencia de requisitos previos o herramientas necesita una resolución explícita. No trates las pruebas de verificación anteriores como demostración del código modificado.
+
+## Guardar un punto de control
+
+Cuando QA haya terminado, mantén disponibles su informe, la URL de la incidencia, las aclaraciones aprobadas y la revisión probada. En la misma sesión, utiliza el selector de agentes documentado para volver al agente habitual de Copilot y confirma que **QA** ya no está seleccionado. Mantén la misma copia de trabajo y rama; no inicies otra sesión de funcionalidad ni recargues el worktree. Si no encuentras la opción del agente habitual, detente y pregunta a la persona que dirige el taller en lugar de enviar instrucciones de commit a QA.
+
+Cuando hayas revisado el perfil, los cambios de pruebas y las pruebas de verificación resultantes, envía la solicitud de punto de control al agente habitual con ese contexto de QA:
+
+```plaintext
+Revisa las diferencias actuales y crea un commit de punto de control para la definición del agente de QA y los cambios de pruebas aprobados. Mantén la rama de filtrado existente. No envíes cambios ni abras una solicitud de incorporación de cambios.
+```
+
+Continúa con la [Lección 8 - Crear y combinar la PR de la funcionalidad][next-lesson] con la funcionalidad de filtrado, la habilidad, el perfil de QA, las pruebas y las pruebas de verificación actuales.
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/es-es/app/8-create-pull-request.md b/docs/es-es/app/8-create-pull-request.md
new file mode 100644
index 00000000..f495c902
--- /dev/null
+++ b/docs/es-es/app/8-create-pull-request.md
@@ -0,0 +1,89 @@
+---
+title: "Lección 8 - Crear y combinar la PR de la funcionalidad"
+description: "Revisa conjuntamente el filtrado, la habilidad, el perfil QA y las pruebas, crea la PR 3 y autoriza Agent Merge explícitamente."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+La implementación del filtrado, la habilidad quality-checks, el perfil QA y las pruebas asociadas están guardados en commits de control en una sola rama. Revísalos juntos y utiliza las pruebas de verificación actuales de QA para preparar la PR 3. Ya has combinado explícitamente las PR de valoraciones por estrellas e instrucciones. Esta vez utilizarás **Agent Merge** dentro del flujo de PR, no como una funcionalidad o rama independiente.
+
+En esta lección:
+
+- aprenderás qué es Agent Merge y cómo automatiza el ciclo de vida de una combinación.
+- examinarás la PR completa de la funcionalidad y las pruebas de verificación.
+- autorizarás Agent Merge solo después de la revisión y confirmarás que la PR está combinada.
+
+## Escenario
+
+En los últimos módulos has explorado distintos niveles de automatización, desde crear código hasta permitir que Copilot valide directamente una interfaz de usuario. Para acelerar aún más el desarrollo, Tailspin Toys quiere averiguar si las solicitudes de incorporación de cambios que ya se han revisado y validado pueden combinarse automáticamente.
+
+## Introducción a Agent Merge
+
+**Agent Merge** permite automatizar el último tramo de la incorporación de una solicitud de cambios mediante la aplicación Copilot. Al habilitarlo, la sesión de la aplicación lee la solicitud y resuelve lo que la bloquea: corrige comprobaciones de CI con errores, responde a comentarios de revisión y reorganiza la base cuando es necesario. Después la combina en cuanto GitHub lo permite. Se ejecuta en segundo plano, continúa tras reiniciar la aplicación y se desactiva cuando se combina la solicitud.
+
+Hasta ahora has seleccionado **Merge pull request** personalmente. Agent Merge puede asumir esa responsabilidad, pero su capacidad de editar código y combinar sigue necesitando tu autorización explícita. Revisa sus acciones permitidas y el trabajo antes de conceder permiso para combinar.
+
+## Revisar el hito completo
+
+Permanece en la sesión de filtrado de las Lecciones 4–7. Comprueba todas las diferencias de la rama frente a `main`, no solo el último punto de control: deben contener el filtrado, `.github/skills/quality-checks/SKILL.md`, los scripts incluidos, `.github/agents/qa.agent.md` y las pruebas asociadas.
+
+Utiliza el selector de agentes para volver de **QA** al agente general de Copilot antes de solicitar commits o acciones de PR y mantén el modo **Interactive**. El trabajo del perfil QA era verificar, no publicar. Cambiar el agente seleccionado no debe cambiar la sesión, la copia de trabajo ni la rama de filtrado.
+
+Este taller combina deliberadamente el trabajo de la funcionalidad y la infraestructura de calidad reutilizable en una sola PR. Un equipo de producción podría separarlos; aquí, los commits de control conservan pasos revisables sin ramas apiladas ni PR adicionales.
+
+Revisa el informe QA de la Lección 7. Reutiliza sus pruebas de verificación solo si cubren la revisión final que se va a enviar, con las cuatro comprobaciones y las observaciones pertinentes del navegador completadas. Si los cambios de código, los conflictos o las correcciones de CI alteran lo que se probó, repite las comprobaciones y observaciones afectadas y actualiza las pruebas de verificación. Un informe **NO-GO** con fallos o bloqueos no autoriza la combinación.
+
+Cuando las diferencias y las pruebas de verificación estén listas, envía:
+
+```plaintext
+Revisa todas las diferencias de la rama de filtrado frente a main, incluidas la funcionalidad de filtrado, la habilidad quality-checks y sus scripts, la definición del agente QA y las pruebas asociadas. Resume los criterios de la incidencia, las aclaraciones aprobadas y las pruebas de verificación actuales de QA. Reutiliza la verificación solo si sigue siendo válida para la revisión final; informa de pruebas de verificación desactualizadas, ausentes o con fallos antes de continuar.
+
+Si los cambios revisados y la verificación están listos, crea un commit con los cambios aprobados restantes del hito, envía esta rama y crea una única PR de la funcionalidad destinada a main con la plantilla de PR del repositorio y la URL real de la incidencia de filtrado. Mantén el historial de puntos de control en esta rama. No utilices una habilidad de contribución, no crees otra rama o PR ni combines todavía.
+```
+
+Abre la PR en **My work** y examina **Files changed**, su descripción, las revisiones y los resultados de las comprobaciones. Examina los archivos de flujos de trabajo propios de Tailspin Toys y las comprobaciones obligatorias; no supongas que todas las comprobaciones locales u observaciones del navegador se ejecutan en CI. La compilación Astro y el comprobador de enlaces que publican el taller pertenecen a otro repositorio y no validan esta funcionalidad.
+
+## Utilizar Agent Merge para gestionar la solicitud
+
+Tras revisar la PR existente, configura Agent Merge en esta misma sesión. No crees una segunda PR.
+
+1. Vuelve a la sesión de filtrado y confirma que está vinculada a la PR 3.
+2. Abre el menú desplegable de acciones de PR en la esquina superior derecha. Antes de que exista una PR, está junto a **Create PR**; la etiqueta puede cambiar cuando hay una PR vinculada.
+3. Selecciona **Agent merge** para habilitar Agent Merge.
+4. Revisa los permisos disponibles, incluidos **Address reviews**, **Fix CI failures**, **Resolve conflicts** y **Merge pull request**. Mantén desactivado el permiso de combinación mientras haya hallazgos o verificaciones pendientes.
+5. Antes de iniciarlo, envía el alcance y la autorización siguientes y después selecciona **Agent merge**:
+
+ ```plaintext
+ Gestiona esta PR de filtrado existente con Agent Merge. Resuelve los bloqueos de revisión o CI solo dentro del alcance de esta PR. No debilites las pruebas ni los requisitos y pregunta antes de realizar cambios ajenos o instalaciones. Cualquier cambio de la revisión probada exige actualizar las comprobaciones pertinentes y las pruebas de observación del navegador; no trates resultados QA anteriores como prueba de código modificado.
+
+ No combines hasta que habilite explícitamente Merge pull request tras revisar las diferencias finales y las pruebas de verificación. No crees otra PR ni empieces la tarea del lienzo.
+ ```
+
+6. Revisa los cambios posteriores y los resultados actualizados. Cuando las diferencias finales estén aprobadas, CI y las revisiones obligatorias se hayan completado correctamente y las pruebas de QA correspondan a esa revisión, autoriza explícitamente la combinación seleccionando el menú desplegable junto a **Agent merge** y después **Merge pull request**.
+
+ 
+
+7. Confirma que GitHub muestra la PR 3 como **Merged**, no solo como combinable o en cola. Agent Merge no elude las protecciones del repositorio ni los permisos ausentes; resuelve esos bloqueos antes de continuar.
+
+Solo después de esa combinación debes iniciar el hito del lienzo. La Lección 9 crea un worktree nuevo y actualiza su rama de sesión mediante un avance rápido hasta el último `origin/main` para que el lienzo parta de la funcionalidad completa combinada.
+
+## Resumen y pasos siguientes
+
+Has automatizado varias partes del proceso de desarrollo, como la generación, las pruebas y la validación de código, y ahora también el proceso de solicitud de incorporación de cambios. En concreto:
+
+- has aprendido qué es Agent Merge y cómo automatiza el ciclo de vida de una combinación.
+- has revisado todas las diferencias de filtrado, habilidad, perfil QA y pruebas como PR 3.
+- has reutilizado las pruebas de QA actuales, examinado CI y autorizado Agent Merge explícitamente.
+
+A continuación, explorarás los **lienzos**, una forma más completa de planificar y visualizar el trabajo con el agente. Continúa con la [Lección 9 - Crear un lienzo de clasificación de incidencias][next-lesson].
+
+## Recursos
+
+- [Gestionar incidencias y solicitudes de incorporación de cambios con la aplicación GitHub Copilot][managing-issues-prs]
+- [Acerca de la aplicación GitHub Copilot][about-copilot-app]
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-canvases/
+[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/es-es/app/8-review.md b/docs/es-es/app/8-review.md
deleted file mode 100644
index 7f9a64f2..00000000
--- a/docs/es-es/app/8-review.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: "Lección 8 - Repaso y pasos siguientes"
-description: "Repasa el recorrido de la aplicación GitHub Copilot, automatiza el trabajo recurrente y descubre cómo continuar."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-Durante las últimas lecciones, has llevado una funcionalidad desde la idea hasta la combinación mediante la aplicación GitHub Copilot. Entre otras cosas, has aprendido a:
-
-- conectar un repositorio y familiarizarte con el espacio de trabajo de la aplicación y la lista de trabajo pendiente inicial.
-- iniciar sesiones desde una tarea directa y desde incidencias, y utilizar los modos Plan y Autopilot para controlar cómo trabaja el agente.
-- orientar al agente con instrucciones personalizadas y una habilidad reutilizable.
-- probar el trabajo con el servidor MCP de Playwright en un navegador real.
-- colaborar con el agente en un lienzo compartido.
-- publicar cambios con niveles crecientes de automatización de combinaciones, desde combinarlos personalmente en github.com hasta permitir que **Agent Merge** incorpore una solicitud de cambios.
-
-Vamos a automatizar parte del trabajo recurrente, comentar procedimientos recomendados y descubrir cómo continuar.
-
-## Automatizar el trabajo recurrente
-
-La aplicación puede ejecutar agentes según una programación o bajo demanda mediante **automatizaciones**, una opción muy útil para tareas rutinarias como clasificar incidencias nuevas o resumir la actividad reciente. Vamos a crear una automatización sencilla y no destructiva.
-
-1. Selecciona **Automations** en la barra lateral y, después, **New automation**.
-2. Asigna un nombre, como `Recap my recent work`.
-3. Elige un desencadenador. **Manual** permite ejecutarla bajo demanda; **On a schedule** la ejecuta automáticamente; **When an issue is created** responde a incidencias nuevas. Para esta lección, elige **Manual**.
-4. Introduce una indicación de solo lectura para que la automatización no pueda modificar nada, por ejemplo:
-
- ```plaintext
- Summarize the pull requests merged in this repository over the last week, and list any issues still open in the backlog.
- ```
-
-5. Elige el proyecto, tu repositorio de Tailspin Toys, y crea la automatización.
-6. Ejecútala bajo demanda para ver el resultado.
-
-> [!TIP]
-> Las automatizaciones pueden ejecutarse en local o en la nube. Habilita **Run in the cloud** y elige las **Tools** que puede utilizar una automatización cuando quieras que se ejecute sin supervisión según una programación. Mantén las automatizaciones programadas bien delimitadas y sin acciones destructivas hasta que confíes en sus resultados.
-
-## Procedimientos recomendados
-
-Al utilizar cualquier herramienta de IA, la infraestructura que la rodea determina la calidad de los resultados. Los archivos de instrucciones, las habilidades y los agentes personalizados han contribuido al trabajo de este taller. Invierte en ellos y reutilízalos entre sesiones.
-
-Adapta el **modo y el modelo** a la tarea. Utiliza **Plan** para razonar sobre un enfoque antes de desarrollar, **Interactive** para mantener el control durante cambios concretos y **Autopilot** solo para tareas aisladas y bien delimitadas. Elige un modelo más rápido para las modificaciones rutinarias y otro más capaz, con mayor esfuerzo de razonamiento, para el trabajo complejo.
-
-El contexto sigue siendo tan importante como la infraestructura. Describir con claridad *qué* quieres crear, *por qué* y *cómo* cambia sustancialmente el resultado. Los chats rápidos son un buen lugar para delimitar una idea antes de dedicarle una sesión completa.
-
-## Más opciones para explorar
-
-Ya conoces el flujo de trabajo principal. Estas son algunas funcionalidades adicionales que merece la pena explorar:
-
-- **Quick chats** para preguntas rápidas y desechables que no necesitan una sesión completa.
-- **Rubber duck** para razonar sobre un problema y obtener comentarios pertinentes antes de desarrollar.
-- [**Agentes personalizados**][custom-agents] para encapsular un rol, sus herramientas y sus instrucciones con el fin de realizar trabajo especializado y repetible.
-- [`/chronicle`][chronicle] para generar una narración de lo sucedido en una sesión.
-- [Usar tu propia clave (BYOK)][byok] para utilizar modelos de tu propio proveedor, incluidos modelos locales mediante Ollama, Foundry Local o LM Studio.
-- [Entornos aislados en la nube][sandboxes] para ejecutar sesiones en un entorno aislado hospedado en GitHub.
-- [Vínculos profundos][deep-links] para abrir la aplicación directamente en un repositorio, una sesión o una indicación.
-
-## Pasos siguientes
-
-La mejor forma de mejorar con cualquier herramienta es seguir utilizándola. Úsala para código de producción, proyectos personales o esa pequeña aplicación que llevas años pensando en crear. Comparte lo que aprendas con el equipo y aprende de sus experiencias. Y, como siempre, consulta la documentación.
-
-Para explorar más elementos del ecosistema de GitHub Copilot, consulta el [recorrido de VS Code](../../vscode/), el [recorrido de Copilot CLI](../../cli/) o el [recorrido del agente en la nube](../../cloud/).
-
-## Recursos
-
-- [Acerca de la aplicación GitHub Copilot][about-copilot-app]
-- [Introducción a la aplicación GitHub Copilot][getting-started]
-- [Personalizar la aplicación GitHub Copilot][customize]
-- [Utilizar automatizaciones][using-automations]
-- [Trabajar con extensiones de lienzo][canvas-docs]
-- [Acerca de los entornos aislados locales y en la nube][sandboxes]
-
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
-[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
-[customize]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
-[using-automations]: https://docs.github.com/copilot/how-tos/github-copilot-app/using-automations
-[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
-[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
-[chronicle]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/chronicle
-[custom-agents]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
-[byok]: https://docs.github.com/copilot/how-tos/github-copilot-app/use-byok-models
-[deep-links]: https://docs.github.com/copilot/how-tos/github-copilot-app/open-with-deep-links
\ No newline at end of file
diff --git a/docs/es-es/app/9-canvases.md b/docs/es-es/app/9-canvases.md
new file mode 100644
index 00000000..bf7737fd
--- /dev/null
+++ b/docs/es-es/app/9-canvases.md
@@ -0,0 +1,148 @@
+---
+title: "Lección 9 - Crear un lienzo de clasificación de incidencias"
+description: "Crea y revisa un lienzo de clasificación guardado en el repositorio, combina la PR 4 y vuelve a abrirlo para añadir contexto de incidencias sin iniciar otra funcionalidad."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Hasta ahora has dirigido a los agentes mediante el chat. Sin embargo, gran parte del trabajo no reside en una conversación, sino en un tablero, un documento o una lista de comprobación. Los **lienzos** ofrecen al agente y a ti una superficie compartida para ese tipo de trabajo, directamente en la aplicación. En esta lección crearás un lienzo sencillo para planificar y realizar el seguimiento de la lista de trabajo pendiente que has estado abordando.
+
+En esta lección:
+
+- comprenderás qué es un lienzo y cuándo utilizarlo.
+- crearás un lienzo compartido con un tablero Kanban para clasificar la lista de trabajo pendiente.
+- guardarás el lienzo en el repositorio y lo combinarás para el equipo.
+- volverás a abrir el lienzo y añadirás contexto de incidencias sin implementar otra funcionalidad.
+
+## Escenario
+
+Examinar una lista de incidencias puede resultar abrumador. Los desarrolladores de Tailspin Toys quieren una herramienta para clasificarlas y añadir sus detalles al contexto de una sesión. Añadir contexto no autoriza a implementar una incidencia; este ejercicio termina con un tablero reutilizable, no con una quinta PR.
+
+## ¿Qué es un lienzo?
+
+Un [lienzo][canvas-docs] es una superficie interactiva y compartida para un recurso de trabajo, como un plan, un tablero de clasificación, una lista de comprobación de versiones, un panel o un documento. Aunque el chat resulta adecuado para describir intenciones y razonar sobre ambigüedades, la mayor parte del trabajo se realiza en una *superficie*. Los lienzos permiten colaborar con el agente directamente sobre ella.
+
+Los lienzos son **bidireccionales**: el agente puede actualizar el lienzo mientras trabaja y tú puedes editar la misma superficie. Cuando creas un lienzo, el agente lo genera a partir de la indicación y el flujo de trabajo, y puedes pedirle que añada, elimine o revise capacidades a medida que avanzas. Una vez creado, el lienzo se abre en el panel derecho de la aplicación.
+
+Algunos ejemplos habituales son:
+
+- **Lienzos de Markdown** para planificar el día y priorizar incidencias y solicitudes de incorporación de cambios.
+- **Tableros Kanban con agentes** en los que las personas y los agentes añaden tarjetas y desplazan el trabajo entre columnas.
+- **Tableros de clasificación de incidencias** que resumen las incidencias principales y los temas recurrentes de un repositorio.
+
+## ¿Por qué utilizar un lienzo?
+
+Utiliza un lienzo cuando una tarea requiera estructura, iteración y verificación, y un chat no sea suficiente. Un lienzo permite:
+
+- basar el trabajo del agente en un recurso real que se adapte al flujo de trabajo.
+- orientar o corregir el trabajo directamente en la superficie compartida y, después, permitir que el agente continúe a partir de los cambios.
+- inspeccionar el progreso como cambios visibles en un recurso, no solo como respuestas del chat.
+
+## Crear un lienzo para realizar el seguimiento del trabajo
+
+Confirma que la PR 3 se ha combinado. Las valoraciones por estrellas, el estándar de documentación, la funcionalidad de filtrado, la habilidad de calidad y el perfil QA deben estar en `main` antes de empezar el lienzo. Utiliza una sesión nueva y una rama para este último hito de PR.
+
+1. Vuelve a la aplicación GitHub Copilot o ábrela.
+2. Selecciona **Home screen**.
+3. Comprueba que `tailspin-toys` esté seleccionado como repositorio.
+4. Elige **new working tree** y el modo **Interactive**. Envía esta solicitud de estado inicial antes de crear archivos:
+
+ ```plaintext
+ Prepara esta nueva sesión de lienzo sin implementar nada. Confirma que es un worktree nuevo y limpio, obtén los cambios de origin y actualiza la rama de la sesión actual mediante un avance rápido hasta origin/main. Informa de la copia de trabajo, la rama y las revisiones coincidentes de HEAD y origin/main. Verifica que la PR de filtrado está combinada y que están presentes la funcionalidad de filtrado, la habilidad quality-checks y el perfil QA.
+
+ Detente si hay cambios pendientes, divergencias o falta la combinación anterior. No restablezcas, no descartes trabajo, no cambies de rama ni crees otra rama. Detente después de comunicar el estado inicial.
+ ```
+
+5. Comprueba el informe del estado inicial y solicita el lienzo guardado en el repositorio:
+
+ ```plaintext
+ Crea un lienzo Kanban básico de clasificación de incidencias guardado en este repositorio mediante el flujo de extensiones de lienzo compatible con la aplicación. Guarda su definición en .github/extensions/ para que el equipo pueda reutilizarlo. Examina las extensiones existentes y consérvalas; no sobrescribas el explorador de base de datos incluido.
+
+ Lee las incidencias abiertas actuales. Destaca las tres con más probabilidades de necesitar atención y muestra las demás debajo. Incluye en cada incidencia destacada su título, un resumen del contenido, la URL y una justificación de su prioridad. Trata la clasificación como sugerencia, no como instrucción para modificar incidencias.
+
+ Proporciona en cada tarjeta una acción Add to current context que adjunte los detalles de la incidencia solo a esta sesión. No debe iniciar la implementación, crear sesiones o ramas, cambiar el estado de la incidencia ni crear PR. Mantén el alcance del lienzo acotado y hazlo accesible mediante teclado.
+
+ Muéstrame los archivos generados y abre el lienzo para revisarlo. No cambies el código de la aplicación, no crees commits, no envíes cambios ni crees una PR. Pregunta antes de instalar cualquier cosa o añadir dependencias.
+ ```
+
+Copilot crea los archivos del lienzo y abre la superficie compartida. Revisa la extensión generada antes de confiar en sus acciones; es contenido ejecutable del repositorio, no solo una imagen.
+
+> [!NOTE]
+> Si la primera versión necesita mejoras, solicita cambios específicos dentro del alcance de clasificación de incidencias. No conviertas este ejercicio en la implementación de una incidencia pendiente.
+
+## Revisar y probar el lienzo
+
+1. Abre **Changes** y confirma que la definición del lienzo se guarda en el repositorio bajo `.github/extensions/`, no solo para tu usuario o sesión. Comprueba que las extensiones existentes y los archivos de la aplicación no han cambiado.
+2. Compara el tablero con las incidencias abiertas reales y evalúa las explicaciones de la clasificación.
+3. Comprueba que las tarjetas y los controles se leen bien y se pueden utilizar con teclado.
+4. Selecciona **Add to current context** en una incidencia y confirma que solo sus detalles se añaden a la conversación. No debe iniciarse ninguna implementación ni cambio de estado de la incidencia.
+5. Revisa las correcciones y pide a Copilot que ejecute la validación existente aplicable a los archivos modificados. Registra resultados y bloqueos, en lugar de suponer que una superficie interactiva funciona correctamente solo porque se ha abierto.
+
+## Guardar el lienzo y combinarlo con el repositorio
+
+El lienzo ya es un recurso del repositorio. Crea un commit y envía solo el trabajo revisado del lienzo como PR 4:
+
+1. En la misma sesión, envía:
+
+ ```plaintext
+ Revisa las diferencias del lienzo de clasificación guardado en el repositorio y sus pruebas de validación. Crea un commit con los archivos del lienzo aprobados en la rama de esta sesión, envíala y crea una única PR destinada a main con la plantilla de PR del repositorio. Describe el comportamiento del lienzo y cómo hemos verificado que añadir una incidencia solo añade contexto. No combines todavía ni implementes una incidencia pendiente.
+ ```
+
+2. Revisa todas las diferencias y comprobaciones de la PR en **My work**. Confirma que contiene el lienzo, no trabajo de la aplicación ajeno a la tarea.
+3. En la misma sesión del lienzo, abre el menú desplegable de acciones de PR y selecciona **Agent merge**. Revisa sus acciones permitidas y mantén **Merge pull request** desactivado hasta aprobar el resultado final.
+4. Define el alcance antes de iniciar Agent Merge:
+
+ ```plaintext
+ Gestiona esta PR de lienzo existente con Agent Merge. Resuelve solo los bloqueos de revisión y CI dentro del alcance; pregunta antes de realizar cambios ajenos o instalaciones. Si cambia el lienzo, repite la validación afectada y actualiza las pruebas de verificación. No combines hasta que habilite explícitamente Merge pull request tras la revisión. No implementes incidencias pendientes ni crees otra PR.
+ ```
+
+5. Selecciona **Agent merge** y revisa los cambios posteriores. Examina las comprobaciones reales de CI del repositorio del participante y resuelve los fallos; CI no sustituye las pruebas de uso del lienzo.
+
+6. Cuando las diferencias finales y las pruebas de verificación actuales estén aprobadas y se hayan superado las comprobaciones y revisiones obligatorias, autoriza explícitamente a Agent Merge a combinar seleccionando su menú desplegable y después **Merge pull request**.
+
+ 
+
+7. Confirma que GitHub muestra la PR 4 como **Merged** antes de continuar.
+
+Ya has creado un lienzo compartido para el equipo.
+
+## Volver a abrir el lienzo sin iniciar otra funcionalidad
+
+Vuelve a abrir el lienzo guardado en el repositorio en la misma sesión del lienzo después de combinar su PR. Es un paso de inspección, no otra rama ni otro hito de PR.
+
+1. Vuelve a la sesión del lienzo, mantén el modo **Interactive** y cierra el panel del lienzo si sigue abierto.
+2. Envía:
+
+ ```plaintext
+ Vuelve a abrir el lienzo de clasificación de incidencias del repositorio en esta misma sesión. Añadiré una incidencia al contexto solo para examinar sus detalles. No edites archivos, no implementes la incidencia, no cambies su estado, no crees otra sesión o rama, no crees commits, no envíes cambios ni abras una PR.
+ ```
+
+3. Confirma que el lienzo guardado se abre de nuevo sin regenerar su definición.
+4. Selecciona **Add to current context** en una de las incidencias que más te interese.
+5. Confirma que los detalles de la incidencia seleccionada aparecen en el contexto sin iniciar la implementación. Detente aquí: el taller tiene cuatro hitos de PR, no cinco.
+
+Has utilizado un lienzo creado por ti para agilizar el proceso de desarrollo.
+
+## Resumen y pasos siguientes
+
+Has creado una superficie compartida en la que puedes colaborar con el agente. En concreto:
+
+- has aprendido qué son los lienzos y cuándo utilizarlos.
+- has creado con el agente un lienzo compartido con un tablero Kanban para clasificar incidencias.
+- has guardado y combinado el lienzo con el repositorio mediante Agent Merge.
+- has vuelto a abrir el lienzo combinado y añadido contexto de incidencias sin iniciar otra funcionalidad.
+
+Con la lista de trabajo pendiente organizada, da un paso atrás para revisar todo lo que has creado y descubrir cómo continuar. Continúa con la [Lección 10 - Repaso y pasos siguientes][next-lesson].
+
+## Recursos
+
+- [Trabajar con extensiones de lienzo en la aplicación GitHub Copilot][canvas-docs]
+- [Lienzos en Awesome Copilot][awesome-copilot-canvases]
+- [Acerca de la aplicación GitHub Copilot][about-copilot-app]
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
+[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/es-es/app/README.md b/docs/es-es/app/README.md
index 3607a893..e6be0557 100644
--- a/docs/es-es/app/README.md
+++ b/docs/es-es/app/README.md
@@ -3,12 +3,14 @@ slug: es-es/app
title: "Aplicación GitHub Copilot"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
La [**aplicación GitHub Copilot**](https://docs.github.com/copilot/concepts/agents/github-copilot-app) es una aplicación de escritorio basada en Copilot CLI que reúne el desarrollo dirigido por agentes en un único espacio de trabajo específico. Añade sesiones de agente en paralelo, modos de sesión intercambiables, lienzos compartidos y gestión nativa de incidencias y solicitudes de incorporación de cambios de GitHub, incluido **Agent Merge**, que guía una solicitud durante reorganizaciones de base, comentarios de revisión, correcciones de CI y la combinación.
-A lo largo de estas lecciones instalarás la aplicación y configurarás el proyecto. Después, conocerás el espacio de trabajo de la aplicación y la lista de trabajo pendiente que la plantilla ha creado para ti. Empezarás con un cambio pequeño, añadir una valoración por estrellas, y luego añadirás desde una incidencia un estándar de instrucciones personalizadas, crearás una funcionalidad de filtrado en una sesión de agente aislada y la verificarás con una habilidad reutilizable. Añadirás el servidor MCP de Playwright para explorar la funcionalidad en un navegador real y avanzarás por niveles crecientes de automatización de combinaciones hasta que **Agent Merge** incorpore la solicitud. Por último, colaborarás en un lienzo compartido y automatizarás el trabajo recurrente: un ciclo completo desde la idea hasta una funcionalidad combinada.
+Las Lecciones 0–1 de configuración preparan el proyecto y el espacio de trabajo de la aplicación. Los nueve módulos principales, las Lecciones 2–10, empiezan con una mejora rápida de valoraciones por estrellas y una convención de documentación demostrada en código real. Después planificarás y crearás el filtrado, crearás y ejecutarás una habilidad quality-checks con scripts de shell, observarás la funcionalidad mediante MCP de Playwright y crearás un agente personalizado QA para evaluar requisitos y cobertura. Revisarás la PR completa de la funcionalidad y autorizarás Agent Merge; después crearás y combinarás un lienzo compartido de clasificación de incidencias.
+
+El taller tiene cuatro hitos de PR: valoraciones por estrellas; instrucciones con su demostración; filtrado con la habilidad, el perfil QA y las pruebas; y, por último, el lienzo. Empieza cada hito desde `main` actualizado, con una rama por PR en lugar de una por módulo. Las Lecciones 4–8 permanecen en la misma sesión, worktree y rama de filtrado. Volver a abrir el lienzo añade contexto de incidencias sin iniciar otra funcionalidad ni una quinta PR. Las automatizaciones se enlazan como siguiente paso, no como ejercicio adicional.
## Lecciones
@@ -16,13 +18,15 @@ A lo largo de estas lecciones instalarás la aplicación y configurarás el proy
|--------|-------|-------------|
| [0. Requisitos previos][ex0] | Configuración | Instala Node.js y crea tu copia del proyecto Tailspin Toys |
| [1. Instalar la aplicación Copilot][ex1] | Configuración | Instala la aplicación, conecta el proyecto y familiarízate con el espacio de trabajo |
-| [2. Ejecutar tu primera sesión de agente][ex2] | Primer cambio | Inicia una sesión y publica un pequeño cambio como tu primera solicitud de incorporación de cambios |
-| [3. Guiar a Copilot con instrucciones personalizadas][ex3] | Contexto | Añade un estándar de documentación desde una incidencia y combínalo |
-| [4. Crear una funcionalidad con Autopilot][ex4] | Funcionalidad principal | Utiliza Plan y Autopilot para crear el filtrado y verifícalo con una habilidad |
-| [5. Realizar pruebas con MCP de Playwright][ex5] | Herramientas externas | Añade el servidor MCP de Playwright y explora la funcionalidad en un navegador |
-| [6. Combinar cambios con Agent Merge][ex6] | Combinación | Deja que Agent Merge corrija e incorpore la solicitud de filtrado |
-| [7. Planificar con lienzos][ex7] | Colaboración | Crea un lienzo compartido para planificar y realizar el seguimiento del trabajo |
-| [8. Repaso y pasos siguientes][ex8] | Resumen | Automatiza tareas recurrentes y descubre cómo continuar |
+| [2. Añadir valoraciones por estrellas: una mejora rápida][ex2] | Primer cambio | Muestra las valoraciones existentes y la alternativa para null y combina la PR 1 |
+| [3. Guiar a Copilot con instrucciones personalizadas][ex3] | Contexto | Añade un estándar de documentación y una demostración real y combina la PR 2 |
+| [4. Crear el filtrado con Plan y Autopilot][ex4] | Implementación | Aprueba el plan, implementa y comprueba el filtrado y guarda un punto de control |
+| [5. Crear y utilizar una habilidad quality-checks][ex5] | Comprobaciones repetibles | Crea, revisa y ejecuta los scripts de shell incluidos |
+| [6. Validar la funcionalidad con MCP de Playwright][ex6] | Observación en el navegador | Configura MCP mediante Customize y examina el comportamiento del filtrado |
+| [7. Crear y utilizar un agente QA][ex7] | Requisitos y cobertura | Selecciona un perfil especializado y reúne pruebas de verificación final |
+| [8. Crear y combinar la PR de la funcionalidad][ex8] | Revisión y combinación | Revisa el filtrado, la habilidad, el perfil QA y las pruebas y autoriza Agent Merge para la PR 3 |
+| [9. Crear un lienzo de clasificación de incidencias][ex9] | Colaboración | Comparte un lienzo guardado en el repositorio en la PR 4 y añade contexto de incidencias |
+| [10. Repaso y pasos siguientes][ex10] | Resumen | Revisa el flujo, los recursos creados y otros materiales |
## Requisitos previos
@@ -50,9 +54,11 @@ Antes de asistir a este taller, asegúrate de disponer de:
[ex2]: 2-add-star-rating/
[ex3]: 3-custom-instructions/
[ex4]: 4-build-filtering/
-[ex5]: 5-mcp-playwright/
-[ex6]: 6-agent-merge/
-[ex7]: 7-canvases/
-[ex8]: 8-review/
+[ex5]: 5-agent-skills/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-canvases/
+[ex10]: 10-review/
[install-git]: https://github.com/git-guides/install-git
[callout-student-plan-education]: https://github.com/education/students
\ No newline at end of file
diff --git a/docs/es-es/cli/0-prerequisites.md b/docs/es-es/cli/0-prerequisites.md
index 383b011b..b6430c83 100644
--- a/docs/es-es/cli/0-prerequisites.md
+++ b/docs/es-es/cli/0-prerequisites.md
@@ -2,7 +2,7 @@
title: "Ejercicio 0: Requisitos previos"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
Antes de empezar los ejercicios de Copilot CLI, tienes que dejarlo todo preparado. Crearás tu propia copia del repositorio Tailspin Toys y pondrás en marcha un [codespace][codespaces], cuyo terminal integrado usarás para instalar y ejecutar Copilot CLI en el siguiente ejercicio.
@@ -11,6 +11,8 @@ Antes de empezar los ejercicios de Copilot CLI, tienes que dejarlo todo preparad
Para crear una copia del repositorio para el código que vas a crear, generarás una instancia a partir de la [plantilla][template-repository]. La nueva instancia contendrá todos los archivos necesarios para el laboratorio y la usarás a medida que avances por los ejercicios.
+Utiliza una copia nueva de la plantilla. Incluye instrucciones del repositorio, código de la aplicación, pruebas y CI, pero no agentes personalizados ni habilidades. Crearás esos recursos tú mismo. Si vuelves a una copia anterior, examina las personalizaciones existentes antes de cambiarlas; no sobrescribas tu trabajo.
+
1. En una nueva ventana del navegador, ve al repositorio de GitHub de este laboratorio: `https://github.com/github-samples/tailspin-toys`.
2. Crea tu propia copia del repositorio seleccionando el botón **Use this template** en la página del repositorio del laboratorio. Después, selecciona **Create a new repository**.
@@ -27,6 +29,8 @@ Para crear una copia del repositorio para el código que vas a crear, generarás
>
> Cuando creas tu repositorio a partir de la plantilla, se crea automáticamente un backlog de incidencias de GitHub para ti. Trabajarás con esas incidencias durante todo el taller; no tienes que crear ninguna por tu cuenta.
+Espera a que termine el flujo de creación inicial de incidencias y comprueba en la pestaña **Issues** que aparecen **Allow users to filter games by category and publisher** y **Update our repository coding standards**. Utiliza sus títulos y URL reales en las lecciones, no números de incidencia supuestos. Si falta la lista de incidencias, examina el resultado del flujo antes de continuar.
+
## Crear un codespace
Ahora usarás un codespace para completar los ejercicios del laboratorio.
@@ -53,6 +57,8 @@ La creación del codespace tardará varios minutos, aunque sigue siendo mucho m
[codespaces]: https://github.com/features/codespaces
[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
+Cuando el codespace esté listo, el [Ejercicio 1][next-lesson] abrirá su terminal y comprobará el repositorio, el entorno de ejecución y la autenticación antes de instalar Copilot CLI.
+
## Resumen
¡Enhorabuena! Has creado una copia del repositorio del laboratorio. También has iniciado el proceso de creación de tu codespace, que usarás cuando empieces a trabajar con Copilot CLI.
diff --git a/docs/es-es/cli/1-install-copilot-cli.md b/docs/es-es/cli/1-install-copilot-cli.md
index c1a08af2..b1cab318 100644
--- a/docs/es-es/cli/1-install-copilot-cli.md
+++ b/docs/es-es/cli/1-install-copilot-cli.md
@@ -2,7 +2,7 @@
title: "Ejercicio 1 - Instalar GitHub Copilot CLI"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
[GitHub Copilot CLI][about-copilot-cli] es un potente asistente de programación con agentes que se ejecuta en tu terminal y te permite explorar bases de código, generar código, ejecutar comandos e interactuar con herramientas externas, todo desde la línea de comandos. Te permite delegar tareas, solicitar cambios y mantener la concentración. Como imaginarás, el primer paso es instalar la herramienta. Por suerte, puedes hacerlo con herramientas que ya conoces.
@@ -21,10 +21,25 @@ Tu equipo está empezando a usar agentes de IA para gestionar un backlog cada ve
Antes de instalar Copilot CLI, tienes que abrir una ventana de terminal en tu codespace.
-1. Vuelve a tu codespace si todavía no estás allí.
+1. Vuelve a tu codespace y espera a que termine su configuración.
2. Abre una ventana de terminal pulsando Ctrl+\`.
3. Deberías ver un panel de terminal en la parte inferior de la ventana de VS Code.
+## Confirmar el entorno del participante
+
+En la terminal del codespace, confirma que estás en tu propio repositorio Tailspin Toys, no en el repositorio de contenido del taller. Lee su `README.md` y `package.json` para conocer la configuración y los comandos de comprobación. Tailspin Toys requiere actualmente Node.js 22.13 o posterior, las dependencias del proyecto y Chromium de Playwright para las pruebas E2E.
+
+```bash
+pwd
+git remote -v
+node --version
+gh auth status
+```
+
+GitHub CLI (`gh`) te ayudará a examinar PR y CI. Si falta autenticación, utiliza `gh auth login` y sigue sus instrucciones del navegador. Confirma que tu cuenta puede enviar ramas y crear y combinar PR en este repositorio; las directivas de la organización pueden exigir otro revisor. Resuelve los requisitos previos ausentes siguiendo las instrucciones de configuración del repositorio antes de cambiar código y revisa cualquier instalación antes de autorizarla.
+
+CLI se ejecuta sobre la copia de trabajo desde la que lo inicias; empezar una conversación no crea automáticamente un worktree aislado. Este taller utiliza una rama por hito de PR. Primero combinarás las valoraciones por estrellas y la demostración de instrucciones, y después mantendrás la misma rama de filtrado durante los Ejercicios 4–8.
+
## Instalar Copilot CLI
Puedes instalar Copilot CLI mediante [npm][install-npm], [WinGet][install-winget] y [Homebrew][install-homebrew]. Como GitHub Codespaces incluye Node.js preinstalado, usarás npm para instalar Copilot CLI.
@@ -35,7 +50,7 @@ Puedes instalar Copilot CLI mediante [npm][install-npm], [WinGet][install-winget
node --version
```
- Deberías ver la versión 22 o posterior (por ejemplo, `v22.x.x`).
+ Tailspin Toys requiere la versión 22.13 o posterior, aunque el requisito de CLI sea distinto. Sigue las instrucciones de configuración del repositorio del participante si tu versión es demasiado antigua.
2. Instala Copilot CLI globalmente en el codespace con npm:
@@ -51,8 +66,8 @@ Puedes instalar Copilot CLI mediante [npm][install-npm], [WinGet][install-winget
Deberías ver el número de versión mostrado (por ejemplo, `v1.0.XX`).
-> [!TIP]
-> Si encuentras errores de permisos, puede que necesites usar `sudo npm install -g @github/copilot` en algunos sistemas. Sin embargo, en GitHub Codespaces no debería ser necesario.
+> [!NOTE]
+> Si la instalación falla por un error de permisos, examina la configuración de npm o pide ayuda a la persona que dirige el taller en lugar de volver a ejecutar un comando desconocido con privilegios elevados.
## Autenticarse con GitHub
@@ -85,22 +100,39 @@ Ahora que estás en el prompt de Copilot CLI por primera vez, vamos a marcar com
2. Para este taller, selecciona **Yes, and remember this folder for future sessions**, ya que trabajarás en este repositorio durante toda la sesión.
3. Haz a Copilot una pregunta sencilla para verificar que funciona:
- ```
- What files are in this project?
+ ```plaintext
+ ¿Qué archivos hay en este proyecto?
```
4. Copilot debería explorar el repositorio y ofrecer un resumen de la estructura del proyecto.
5. Prueba el comando `/help` para ver los comandos de barra disponibles:
- ```
+ ```text
/help
```
-6. Sal de Copilot CLI introduciendo el siguiente comando en el terminal. Volveremos a Copilot CLI en un ejercicio posterior.
+6. Sal de esta sesión introduciendo el siguiente comando en el prompt de Copilot. Iniciarás una sesión nueva para el primer cambio.
+ ```text
+ /exit
```
- exit
- ```
+
+## Comprender modos y permisos
+
+Copilot CLI trabaja en el directorio y la rama de Git donde lo inicias. Confiar en un directorio le permite utilizar el contexto del repositorio; no equivale a aprobar todas las acciones de herramientas. Revisa las solicitudes de permiso para cambios de archivos, comandos de shell y operaciones de GitHub.
+
+Inicia los ejercicios de código desde la raíz del repositorio del participante con:
+
+```bash
+copilot --enable-all-github-mcp-tools
+```
+
+El servidor MCP de GitHub está integrado. Esta opción expone todas sus herramientas para trabajar con incidencias y PR; la autenticación, los permisos del repositorio y las aprobaciones de herramientas siguen siendo necesarios. No autoriza un commit ni una PR por sí sola.
+
+Utiliza Shift+Tab para alternar entre los modos estándar **Interactive**, **Plan** y **Autopilot**. Comprueba el indicador de modo antes de enviar una solicitud. Mantendrás Interactive para los primeros cambios, planificarás el filtrado antes de crearlo y volverás explícitamente a Interactive antes de crear y revisar personalizaciones.
+
+> [!CAUTION]
+> Los ajustes de modo y permisos son distintos. Autopilot continúa trabajando de forma autónoma; `--allow-all` y su alias `--yolo` conceden todos los permisos de herramientas, rutas y URL. Este taller no exige iniciar todas las sesiones con permisos ilimitados. Revisa el alcance antes de conceder acceso, incluso dentro de un codespace.
## Resumen y siguientes pasos
@@ -111,7 +143,7 @@ Ahora que estás en el prompt de Copilot CLI por primera vez, vamos a marcar com
- confiar en un directorio para que Copilot CLI pueda trabajar con él.
- verificar que la instalación funciona correctamente.
-Ahora que Copilot CLI está instalado, vamos a darle a Copilot algo de contexto del proyecto. Continúa con el [Ejercicio 2 - Instrucciones personalizadas con CLI][next-lesson].
+Ahora que Copilot CLI está instalado, realiza un cambio pequeño y revisable en el [Ejercicio 2 - Añadir valoraciones por estrellas: una mejora rápida][next-lesson].
## Recursos
@@ -120,7 +152,7 @@ Ahora que Copilot CLI está instalado, vamos a darle a Copilot algo de contexto
- [Usar Copilot CLI][using-copilot-cli]
[previous-lesson]: ../0-prerequisites/
-[next-lesson]: ../2-custom-instructions/
+[next-lesson]: ../2-add-star-rating/
[install-copilot-cli]: https://docs.github.com/copilot/how-tos/set-up/install-copilot-cli
[install-npm]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-npm-all-platforms
[install-winget]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-winget-windows
diff --git a/docs/es-es/cli/10-review.md b/docs/es-es/cli/10-review.md
new file mode 100644
index 00000000..2a27553f
--- /dev/null
+++ b/docs/es-es/cli/10-review.md
@@ -0,0 +1,67 @@
+---
+title: "Ejercicio 10 - Repaso y próximos pasos"
+description: "Repasa el flujo de desarrollo compartido, los recursos reutilizables y los tres hitos de solicitudes de incorporación de cambios de CLI."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Has utilizado Copilot CLI para pasar de un cambio pequeño a una funcionalidad planificada con verificación reutilizable. La configuración de los Ejercicios 0–1 preparó tu entorno; los nueve módulos principales de los Ejercicios 2–10 enseñaron un flujo completo de desarrollo.
+
+## Repasar los tres hitos de PR
+
+| Hito | Resultado combinado | Hábito de revisión |
+| --- | --- | --- |
+| PR 1: valoraciones por estrellas | El `starRating` existente se muestra en las tarjetas de juegos, incluido `No rating yet` para `null` | Mantener el cambio acotado y verificar ambos casos |
+| PR 2: instrucciones personalizadas | Una convención de documentación específica y una pequeña demostración en código real | Comprobar que las instrucciones mejoran código real, no solo ejemplos del chat |
+| PR 3: filtrado y verificación | Filtrado, la habilidad quality-checks, el perfil de QA y las pruebas asociadas | Revisar todos los puntos de control, las pruebas de verificación actuales de QA y CI antes de combinar |
+
+Las dos primeras PR se combinaron antes de iniciar el siguiente hito desde `main` actualizado. Los Ejercicios 4–8 compartieron una rama y una copia de trabajo. Los commits de puntos de control conservaron el progreso sin crear una PR por módulo. El ejercicio de controles no inició otra funcionalidad o PR.
+
+## Repasar los recursos compartidos
+
+Son los mismos resultados principales que los del [taller de la aplicación Copilot][app-workshop], alcanzados mediante una interfaz de terminal:
+
+- **Las instrucciones del repositorio** explican el contexto y los estándares del proyecto; las instrucciones limitadas por ruta añaden detalles para los archivos pertinentes.
+- **La implementación de filtrado y las pruebas** satisfacen la incidencia y las aclaraciones que aprobaste durante la planificación.
+- **La habilidad quality-checks** reúne instrucciones reutilizables y scripts reales de shell que ejecutan las cuatro comprobaciones del proyecto.
+- **La configuración de MCP de Playwright** proporciona herramientas de navegador para observación directa. En este flujo de CLI reside en la configuración del usuario, no en la PR de funcionalidad.
+- **El agente personalizado de QA** define un rol reutilizable que parte de requisitos, comprueba cobertura, utiliza la habilidad y las herramientas de navegador e informa de resultados veraces.
+- **La PR y las pruebas de verificación** conectan los cambios revisados con los resultados de pruebas, las observaciones de navegador, las limitaciones y CI.
+
+Una habilidad es más que una lista de comandos y un perfil es más que un nombre de archivo. Has examinado los recursos generados, confirmado su ejecución real y seleccionado el agente personalizado antes de confiar en su informe.
+
+## Distinguir las finalidades de validación
+
+La planificación aclaró los requisitos antes de la implementación. Autopilot ejecutó ese plan acotado; volver a Interactive restableció puntos deliberados de revisión antes de crear personalizaciones.
+
+La implementación utilizó las comprobaciones npm existentes antes de que existiera una habilidad. El ejercicio de la habilidad demostró que sus scripts incluidos y el reenvío de argumentos funcionaban. MCP demostró interacción directa con el navegador en lugar de repetir una batería completa. QA combinó criterios, cobertura, observaciones de navegador y las cuatro comprobaciones mediante la habilidad. La PR reutilizó resultados actuales de QA mientras CI comprobaba la revisión enviada.
+
+Los fallos y bloqueos son resultados útiles. La ausencia de herramientas de navegador, las pruebas omitidas, los servidores obsoletos o un requisito sin resolver significan **NO-GO**, no permiso para rebajar el estándar. Añadir pruebas se justifica por carencias reales; no añadir ninguna es correcto cuando la cobertura existente es adecuada.
+
+## Mantener estos hábitos
+
+- Proporciona a Copilot la incidencia, el motivo del cambio y límites claros.
+- Revisa los planes antes de aprobar trabajo autónomo.
+- Examina instrucciones, habilidades y perfiles generados antes de ejecutarlos.
+- Identifica la copia de trabajo, la rama, el servidor y la revisión a los que corresponde un resultado.
+- Aplica la corrección más pequeña justificada y actualiza las pruebas de verificación tras los cambios.
+- Mantén explícitas las instalaciones, las acciones destructivas, el uso compartido y las combinaciones de PR.
+
+## Seguir aprendiendo
+
+El [taller de la aplicación Copilot][app-workshop] alcanza los resultados compartidos mediante su interfaz gráfica y añade un hito de lienzo. El [taller de VS Code][vscode-workshop] y el [taller del agente en la nube][cloud-workshop] exploran otras formas de trabajar con agentes.
+
+Utiliza [Awesome Copilot][awesome-copilot] para encontrar ejemplos de instrucciones, habilidades y agentes personalizados. Los [ejemplos de habilidades del Ejercicio 5][skill-examples] incluyen flujos de contribución, documentos de requisitos, diagramas y pruebas de navegador. Revisa los requisitos previos y el comportamiento antes de adoptar contenido de la comunidad.
+
+Como referencia cotidiana, consulta la [referencia de comandos de CLI][cli-reference], la [documentación de habilidades de agente][agent-skills] y la [documentación de agentes personalizados][custom-agents]. Sigue experimentando con tareas acotadas y comparte solo material revisado mediante canales aprobados.
+
+[previous-lesson]: ../9-slash-commands/
+[app-workshop]: ../../app/
+[vscode-workshop]: ../../vscode/
+[cloud-workshop]: ../../cloud/
+[skill-examples]: ../5-agent-skills/#ejemplos-adicionales-de-habilidades
+[awesome-copilot]: https://github.com/github/awesome-copilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
+[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
+[custom-agents]: https://docs.github.com/copilot/concepts/agents/copilot-cli/about-custom-agents
diff --git a/docs/es-es/cli/2-add-star-rating.md b/docs/es-es/cli/2-add-star-rating.md
new file mode 100644
index 00000000..38c4a713
--- /dev/null
+++ b/docs/es-es/cli/2-add-star-rating.md
@@ -0,0 +1,83 @@
+---
+title: "Ejercicio 2 - Añadir valoraciones por estrellas: una mejora rápida"
+description: "Muestra las valoraciones existentes de los juegos, revisa y valida el cambio y combina tu primera solicitud de incorporación de cambios."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Empieza con un cambio pequeño que puedas comprender y verificar. Tailspin Toys ya almacena el `starRating` de cada juego y lo muestra en la página de detalles. Mostrarás ese valor existente en las tarjetas de juegos, incluido un mensaje claro cuando un juego no tenga valoración.
+
+En este ejercicio:
+
+- solicitarás un cambio específico en una sesión Interactive de CLI.
+- examinarás las diferencias y verificarás las tarjetas con y sin valoración.
+- crearás un commit, abrirás y revisarás la PR 1 y la combinarás.
+
+## Iniciar el primer hito
+
+Desde la raíz del repositorio del participante, confirma que el árbol de trabajo está limpio, actualiza `main` y crea una rama. Si `git status` muestra cambios inesperados, resuélvelos antes de cambiar de rama; no los descartes.
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-star-rating
+copilot --enable-all-github-mcp-tools
+```
+
+Confía en el repositorio cuando se solicite. Comprueba que estás en modo **Interactive** y utiliza `/model` para examinar los modelos disponibles o seleccionar **Auto**. Revisa las aprobaciones de herramientas a medida que aparezcan.
+
+## Solicitar el cambio
+
+Envía esta indicación:
+
+```plaintext
+Muestra la valoración por estrellas de cada juego en las tarjetas. El tipo Game ya incluye un campo starRating: un número sobre 5, o null cuando el juego aún no tiene valoración. Muéstralo en cada tarjeta de src/components/GameCard.astro y, cuando starRating sea null, muestra "No rating yet". Mantén el cambio pequeño y no reestructures el diseño de las tarjetas.
+
+Examina y sigue las instrucciones del repositorio. Utiliza el modelo de datos existente; no añadas una API de valoraciones, un esquema nuevo ni una funcionalidad ajena a la tarea. Añade o actualiza las pruebas adecuadas para los casos con y sin valoración. No crees commits, no envíes cambios ni abras una solicitud de incorporación de cambios todavía.
+```
+
+Copilot debería examinar el tipo y el componente existentes antes de editar. Lee la actividad de sus herramientas además de su respuesta final. Un resumen seguro de sí mismo no demuestra que la implementación sea correcta.
+
+## Revisar y validar
+
+1. Introduce `/diff` y examina todos los archivos modificados en el editor o la vista de diferencias.
+2. Confirma que la tarjeta utiliza el `starRating` existente, muestra un valor sobre 5 y presenta `No rating yet` para `null`. Una comprobación basada solo en si el valor se evalúa como verdadero puede tratar erróneamente un cero numérico como ausencia de valoración.
+3. Comprueba que el cambio conserva el diseño de la tarjeta y proporciona a la valoración una etiqueta textual significativa en lugar de depender solo de una estrella o del color.
+4. Pide a Copilot que verifique el cambio con las comprobaciones existentes:
+
+ ```plaintext
+ Examina package.json y la configuración de pruebas y ejecuta lint, comprobaciones de tipos y las pruebas unitarias o E2E existentes adecuadas para este cambio de tarjeta. Verifica tanto las valoraciones numéricas como la alternativa para null; informa de los comandos exactos y sus resultados, incluida cualquier carencia de cobertura o comprobación bloqueada. No instales nada, no cambies de rama, no crees commits, no envíes cambios ni abras una PR.
+ ```
+
+5. Revisa la salida de los comandos y los cambios de pruebas. Resuelve los fallos antes de entregar; pregunta antes de instalar requisitos previos ausentes.
+
+Para observar la tarjeta en un navegador, abre una segunda terminal en esta misma copia de trabajo y ejecuta:
+
+```bash
+npm run dev
+```
+
+Abre el puerto reenviado en el panel **Ports** del codespace. Examina las tarjetas con valoración en la página de inicio. Si los datos iniciales actuales no contienen un ejemplo sin valoración, exige un caso de prueba automatizado con datos que cubran `null`; no afirmes haber observado una tarjeta sin valoración. Detén el servidor de desarrollo con Ctrl+C en su terminal antes de las comprobaciones E2E o de salir del ejercicio. Las pruebas automatizadas de Playwright no deben reutilizar un servidor de otra copia de trabajo.
+
+## Crear y combinar la PR 1
+
+Tras revisar el cambio y superar las comprobaciones, autoriza este hito por separado:
+
+```plaintext
+Revisa las diferencias actuales y los resultados de las comprobaciones. Crea un commit solo con el cambio de valoraciones por estrellas revisado y sus pruebas, envía la rama actual y crea una solicitud de incorporación de cambios a main utilizando la plantilla de PR de este repositorio, si existe. Incluye el resumen del cambio y los resultados reales de verificación. No combines la PR ni empieces otra tarea.
+```
+
+Abre la URL de la PR que se devuelve. Examina **Files changed** y los resultados de las comprobaciones, no solo el resumen del agente. Revisa las definiciones de los flujos de trabajo del repositorio Tailspin al interpretar CI; CI no sustituye tu observación en el navegador. Resuelve los fallos y vuelve a verificar el código modificado.
+
+Cuando la PR cumpla los requisitos de revisión y comprobación del repositorio, selecciona **Merge pull request** y confirma la combinación en GitHub. Si la protección de ramas exige otro revisor, espera esa aprobación. Confirma que la PR está **Merged** antes de continuar.
+
+Sal de la sesión de Copilot con `/exit`. En el siguiente ejercicio actualizarás el `main` local antes de crear la rama de instrucciones; no la inicies desde esta rama de funcionalidad sin combinar.
+
+## Resumen y pasos siguientes
+
+Has completado el primer ciclo: una indicación acotada, código revisado, pruebas de verificación y una PR combinada. A continuación, [guía a Copilot con instrucciones personalizadas][next-lesson] y demuestra una convención de documentación en una segunda PR pequeña.
+
+[previous-lesson]: ../1-install-copilot-cli/
+[next-lesson]: ../3-custom-instructions/
diff --git a/docs/es-es/cli/2-custom-instructions.md b/docs/es-es/cli/2-custom-instructions.md
deleted file mode 100644
index 538123fb..00000000
--- a/docs/es-es/cli/2-custom-instructions.md
+++ /dev/null
@@ -1,243 +0,0 @@
----
-title: "Ejercicio 2 - Instrucciones personalizadas (Copilot CLI)"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-[← Lección anterior: Instalar Copilot CLI][previous-lesson] · [Siguiente lección: Generar código con CLI →][next-lesson]
-
-El contexto es clave cuando se trabaja con IA generativa. Si una tarea debe hacerse de una forma concreta, o hay información de fondo que Copilot debería conocer, te interesa asegurarte de que ese contexto esté disponible. Tienes varias herramientas a tu disposición para ayudar a Copilot, y las exploraremos a lo largo de este taller. Vamos a empezar con los [archivos de instrucciones][instruction-files], que suelen centrarse en cómo debe estructurarse el propio código. Esto ayuda a Copilot a entender no solo *qué* código quieres, sino también *cómo* debe estructurarse.
-
-En este ejercicio vas a:
-
-- explorar cómo el contexto específico del proyecto, las directrices de desarrollo y los estándares de documentación llegan a Copilot a través de las instrucciones personalizadas del repositorio y de los archivos de instrucciones con ámbito de ruta;
-- generar el primer bloque de datos para el filtrado (un helper de editoriales) con las instrucciones *actuales*;
-- añadir un nuevo estándar general del repositorio a `.github/copilot-instructions.md`;
-- ejecutar un prompt de seguimiento y ver cómo el código regenerado adopta el nuevo estándar;
-- confirmar los cambios de las instrucciones y del helper para que el siguiente ejercicio pueda basarse en ellos.
-
-> [!CAUTION]
-> El código generado puede desviarse de algunos de los estándares que establezcas. Copilot no es determinista. El objetivo es observar la *tendencia* del cambio de comportamiento tras actualizar las instrucciones, no hacer que la salida coincida carácter por carácter.
-
-## Archivos de instrucciones
-
-### Escenario
-
-Como cualquier buen equipo de desarrollo, Tailspin Toys tiene un conjunto de directrices y requisitos para sus prácticas de desarrollo. Entre ellos se incluyen:
-
-- La capa de datos siempre necesita pruebas unitarias.
-- La interfaz debe estar en modo oscuro y tener un aspecto moderno.
-- Debe añadirse documentación al código en forma de comentarios de documentación TSDoc.
-- Debe añadirse un bloque de comentarios al inicio de cada archivo para describir lo que hace.
-
-Gracias al uso de archivos de instrucciones, te asegurarás de que Copilot disponga de la información correcta para realizar las tareas de acuerdo con las prácticas indicadas.
-
-### Instrucciones personalizadas
-
-Las instrucciones personalizadas te permiten proporcionar contexto y preferencias a Copilot para que entienda mejor tu estilo de desarrollo y tus requisitos. Es una función muy potente que puede ayudarte a orientar Copilot para obtener sugerencias y fragmentos de código más relevantes. Puedes indicar tus convenciones de desarrollo preferidas, bibliotecas e incluso los tipos de comentarios que te gusta incluir en el código. Puedes crear instrucciones para todo el repositorio o para tipos de archivo concretos, con el fin de aportar contexto a nivel de tarea.
-
-Hay dos tipos de archivos de instrucciones:
-
-- `.github/copilot-instructions.md`, un único archivo de instrucciones que se envía a Copilot en **todas** las solicitudes del repositorio. Este archivo debe contener información a nivel de proyecto, es decir, contexto relevante para la mayoría de las solicitudes que se envían a Copilot desde el chat o la CLI. Puede incluir la pila tecnológica que se usa, una visión general de lo que se está construyendo, buenas prácticas y otras directrices globales.
-- Se pueden crear archivos `.github/instructions/*.instructions.md` para tareas o tipos de archivo concretos. Puedes usarlos para proporcionar directrices para lenguajes concretos (como TypeScript o Astro), o para tareas como crear un componente de interfaz o un nuevo conjunto de pruebas unitarias.
-
-> [!NOTE]
-> Cuando trabajas en tu IDE, los archivos de instrucciones solo se usan para generar código en Copilot Chat, no para las finalizaciones de código ni para las sugerencias de la siguiente edición.
->
-> Copilot Chat, Copilot CLI y Copilot cloud agent usan tanto los archivos a nivel de repositorio como los archivos `*.instructions.md` (con frontmatter `applyTo`) al generar código.
->
-> Además, Copilot [admite archivos de instrucciones que usan otros estándares][custom-instructions-support], incluidos los archivos AGENTS.md y CLAUDE.md.
-
-### Buenas prácticas para gestionar archivos de instrucciones
-
-Una conversación completa sobre cómo crear archivos de instrucciones queda fuera del alcance de este taller. Sin embargo, los ejemplos proporcionados en el proyecto de ejemplo muestran un enfoque representativo. A grandes rasgos:
-
-- Mantén las instrucciones de `copilot-instructions.md` centradas en directrices a nivel de proyecto, como una descripción de lo que se está construyendo, la estructura del proyecto y los estándares globales de desarrollo.
-- Usa archivos `*.instructions.md` para proporcionar instrucciones específicas según el tipo de archivo (pruebas unitarias, componentes Astro, capa de datos) o la tarea.
-- Usa lenguaje natural. Mantén las directrices claras. Proporciona ejemplos de cómo debería verse el código, y de cómo no.
-
-No existe una única forma de crear archivos de instrucciones, igual que no existe una única forma de usar la IA. A través de la experimentación descubrirás qué funciona mejor para tu proyecto.
-
-> [!TIP]
-> Todos los proyectos que usan GitHub Copilot deberían contar con una colección sólida de archivos de instrucciones. Al explorar los de este proyecto, puede que veas que hay archivos para muchos tipos de tareas, incluidas [actualizaciones de la interfaz][ui-instructions] y [Astro][astro-instructions].
->
-> Copilot también puede ayudarte a generar archivos de instrucciones. Cada superficie lo presenta de una forma distinta (por ejemplo, **Configure Chat → Generate Agent Instructions** en VS Code, o `/init` en Copilot CLI); la lección de la superficie en la que estés lo señalará cuando sea relevante.
->
-> ¿Buscas plantillas o un punto de partida? Explora [awesome-copilot][awesome-copilot], un repositorio lleno de archivos de instrucciones, agentes personalizados y otros recursos.
-
-[ui-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/ui.instructions.md
-[astro-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/astro.instructions.md
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[custom-instructions-support]: https://docs.github.com/copilot/reference/custom-instructions-support
-
-## Explorar los archivos de instrucciones personalizadas de este proyecto
-
-Dedica un momento a leer los archivos de instrucciones incluidos en este repositorio: hay un `copilot-instructions.md` principal y una colección de archivos `*.instructions.md` para varias tareas. Ábrelos en tu editor o en la interfaz web de GitHub.
-
-1. Abre `.github/copilot-instructions.md`.
-2. Explora el archivo y fíjate en la breve descripción del proyecto y en secciones como **Agent notes**, **Code standards**, **Scripts** y **Repository Structure**. En **Code standards**, fíjate en la guía anidada **GitHub Actions Workflows**. Se aplica a cualquier interacción que tengas con Copilot.
-3. Abre la carpeta `.github/instructions` y échale un vistazo. Verás instrucciones para archivos Astro, la capa de datos de Drizzle, pruebas y mucho más.
-4. Abre `.github/instructions/unit-tests.instructions.md`. Fíjate en el campo `applyTo` de la parte superior: establece un glob (relativo a la raíz del repositorio) que determina a qué archivos se aplican las instrucciones. Aquí, cualquier archivo de prueba TypeScript (por ejemplo, uno que coincida con `**/*.test.ts`) coincidirá.
-5. Observa las instrucciones específicas para crear pruebas unitarias para este proyecto.
-6. Por último, abre `.github/instructions/drizzle.instructions.md` y desplázate hasta el final. Fíjate en los enlaces a otros archivos de instrucciones (como `unit-tests.instructions.md`) y a archivos existentes del proyecto. Esto te permite dividir conjuntos de instrucciones más grandes en archivos más pequeños y reutilizables, y mostrar a Copilot ejemplos que seguir al generar código. (Las rutas allí son relativas al archivo de instrucciones, no a la raíz del repositorio).
-
-> [!NOTE]
-> La sección **Code formatting requirements** de `copilot-instructions.md` documenta los estándares de desarrollo del proyecto, pero todavía no exige documentación dentro del código. En los pasos siguientes, añadirás reglas para comentarios de documentación TSDoc y encabezados de comentario a nivel de archivo.
-
-## Crear una rama
-
-Vas a hacer cambios en el código, así que crea una rama para trabajar.
-
-1. Desde el terminal de tu codespace, crea una rama nueva y cambia a ella:
-
- ```bash
- git checkout -b update-custom-instructions
- ```
-
-2. Confirma que Copilot CLI está instalado y autenticado:
-
- ```bash
- copilot --version
- ```
-
- Si no se encuentra el comando o no has iniciado sesión, vuelve al [Ejercicio 1 - Instalar GitHub Copilot CLI](../1-install-copilot-cli/).
-
-## Usar Copilot CLI *antes* de actualizar las instrucciones
-
-Para ver el impacto de las instrucciones personalizadas, empieza generando código con las instrucciones actuales. Más adelante, actualizarás el archivo y ejecutarás un prompt de seguimiento.
-
-> [!TIP]
-> **Inicia una sesión de Copilot CLI**
->
-> Antes de empezar los ejercicios siguientes, vuelve a tu codespace y abre un terminal (Ctrl+\` si no hay ninguno abierto). Después, inicia Copilot CLI con `--yolo` y `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar la sesión más reciente de este proyecto en lugar de empezar desde cero, ejecuta `copilot --yolo --enable-all-github-mcp-tools --continue`. Si Copilot CLI ya se está ejecutando desde un ejercicio anterior, envía `/clear` para empezar una conversación limpia.
->
-> `--enable-all-github-mcp-tools` habilita las herramientas GitHub MCP de lectura y escritura para la sesión actual, de modo que Copilot pueda leer tu backlog y abrir pull requests durante el flujo del taller.
-
-> [!CAUTION]
-> `--yolo` habilita permisos automáticos completos (`--allow-all-tools`, `--allow-all-paths` y `--allow-all-urls`). Úsalo solo en un entorno aislado, como un Codespace o una máquina virtual, y no lo configures nunca como alias predeterminado para el desarrollo diario. Consulta [Allowing and denying tool use][allow-all-warning] para más información.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. Asegúrate de que tu sesión de Copilot CLI se está ejecutando desde la **raíz del repositorio** para que detecte automáticamente `.github/copilot-instructions.md`.
-2. En el prompt de Copilot CLI, pídele que genere el helper de editoriales que usará la interfaz de filtrado:
-
- ```plaintext
- Create a new data-access helper at src/lib/publishers.ts to return a list of all publishers. It should return the name and id for all publishers. Do not run the tests yet.
- ```
-
-3. Copilot CLI explorará el proyecto, propondrá un plan y escribirá el archivo en esta sesión con `--yolo`. Supervisa los cambios en la salida del terminal y luego revísalos en tu editor.
-4. Abre el archivo generado `src/lib/publishers.ts` en tu editor.
-5. Observa que el helper es una función tipada que recibe un cliente `db` como primer argumento y devuelve un array tipado de editoriales; esto procede de las convenciones de la capa de datos en `.github/instructions/drizzle.instructions.md` (que se aplica a `src/lib/*.ts`).
-6. Observa que al código generado **le faltan** comentarios de documentación TSDoc y un encabezado de comentario a nivel de archivo.
-
-> [!CAUTION]
-> Copilot es probabilístico: existe la posibilidad de que añada comentarios de documentación incluso sin que se lo indiques. Si ocurre, no pasa nada; la mejora en la *consistencia* después de actualizar las instrucciones sigue siendo la idea importante.
-
-## Añadir un nuevo estándar del repositorio
-
-Como se indicó antes, `.github/copilot-instructions.md` está diseñado para proporcionar información del proyecto a Copilot. Vamos a asegurarnos de que los estándares de desarrollo del repositorio queden documentados para mejorar las sugerencias de código.
-
-1. Vuelve a abrir `.github/copilot-instructions.md`.
-2. Localiza la sección **Code formatting requirements**, que debería estar cerca de la línea 27. Observa cómo documenta los estándares de desarrollo del proyecto, pero todavía no tiene ninguna regla para la documentación dentro del código, y por eso el helper generado no incluía comentarios de documentación.
-3. Añade las siguientes líneas de Markdown justo debajo de los estándares existentes para indicar a Copilot que añada encabezados de comentario a nivel de archivo y comentarios de documentación TSDoc:
-
- ```markdown
- - Every exported function should have a TSDoc comment describing its purpose, parameters, and return value.
- - Before imports or any code, add a comment block to the file that explains its purpose.
- ```
-
-4. Guarda `copilot-instructions.md`.
-
-> [!TIP]
-> Como viste en la lección anterior, los archivos de instrucciones pueden crearse a nivel de repositorio (`.github/copilot-instructions.md`) para directrices globales, o como archivos `*.instructions.md` para lenguajes, tipos de archivo o tareas concretos. El archivo a nivel de repositorio es el lugar adecuado para estándares generales del proyecto, como la regla de comentarios de documentación que acabas de añadir.
-
-## Ejecutar de nuevo el prompt y observar el cambio
-
-Ahora que las instrucciones incluyen una regla para los comentarios de documentación, pídele a Copilot CLI que actualice el archivo de editoriales que acabas de generar. La misma directriz de estándares orientará la reescritura.
-
-1. Envía `/clear` en tu sesión de Copilot CLI para empezar con una conversación limpia.
-2. Envía el siguiente prompt:
-
- ```plaintext
- Update src/lib/publishers.ts to follow the latest documentation conventions in .github/copilot-instructions.md.
- ```
-
-3. Deja que termine la edición y vuelve a abrir `src/lib/publishers.ts`.
-4. Observa que el archivo ahora empieza con un bloque de comentarios similar a este:
-
- ```typescript
- /**
- * Helpers de acceso a datos de editoriales para la plataforma de crowdfunding de Tailspin Toys.
- * Proporciona funciones para recuperar información de editoriales desde la base de datos.
- */
- ```
-
-5. Observa que la función generada ahora incluye un comentario de documentación TSDoc similar a este:
-
- ```typescript
- /**
- * Devuelve una lista de todas las editoriales con su id y su nombre.
- *
- * @param db - El cliente de base de datos de Drizzle.
- * @returns Una promesa que se resuelve en un array de objetos de editoriales.
- */
- ```
-
-6. Mantén este archivo actualizado. Es el primer bloque de datos sobre el que trabajarás en el siguiente ejercicio.
-
-## Confirmar y enviar este primer bloque de filtrado
-
-1. En el terminal, verifica los archivos modificados:
-
- ```bash
- git status
- ```
-
-2. Prepara el cambio de las instrucciones y el helper:
-
- ```bash
- git add .github/copilot-instructions.md src/lib/publishers.ts
- ```
-
-3. Confirma los cambios:
-
- ```bash
- git commit -m "Add doc comment standards and publishers helper foundation"
- ```
-
-4. Envía la rama:
-
- ```bash
- git push -u origin update-custom-instructions
- ```
-
-## Resumen y siguientes pasos
-
-Has explorado cómo Copilot toma el contexto de los archivos de instrucciones de este proyecto y después has usado Copilot CLI para:
-
-- generar una base del helper de acceso a datos de editoriales para el filtrado con las instrucciones *existentes*;
-- añadir un nuevo estándar general del repositorio a `.github/copilot-instructions.md`;
-- ejecutar un prompt de seguimiento y ver cómo el código regenerado adopta el nuevo estándar;
-- confirmar y enviar tanto la actualización de instrucciones como la base del helper.
-
-A continuación, aplicarás estas instrucciones mientras implementas trabajo del backlog en el [ejercicio de generación de código][next-lesson].
-
-## Recursos
-
-- [Archivos de instrucciones para la personalización de GitHub Copilot][instruction-files]
-- [Buenas prácticas para crear instrucciones personalizadas][instructions-best-practices]
-- [5 consejos para escribir mejores instrucciones personalizadas para Copilot][copilot-instructions-five-tips]
-- [Awesome Copilot: una colección de archivos de instrucciones y otros recursos][awesome-copilot]
-
-[previous-lesson]: ../1-install-copilot-cli/
-[next-lesson]: ../3-generating-code/
-[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
-[instructions-best-practices]: https://docs.github.com/enterprise-cloud@latest/copilot/using-github-copilot/coding-agent/best-practices-for-using-copilot-to-work-on-tasks#adding-custom-instructions-to-your-repository
-[copilot-instructions-five-tips]: https://github.blog/ai-and-ml/github-copilot/5-tips-for-writing-better-custom-instructions-for-copilot/
diff --git a/docs/es-es/cli/3-custom-instructions.md b/docs/es-es/cli/3-custom-instructions.md
new file mode 100644
index 00000000..12aba9a4
--- /dev/null
+++ b/docs/es-es/cli/3-custom-instructions.md
@@ -0,0 +1,109 @@
+---
+title: "Ejercicio 3 - Guiar a Copilot con instrucciones personalizadas"
+description: "Añade una convención de documentación específica, demuéstrala en código existente y combina la segunda solicitud de incorporación de cambios."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+El contexto ayuda a Copilot a comprender no solo *qué* crear, sino *cómo* espera tu equipo que se escriba el código. Añadirás una convención de documentación específica, observarás su efecto en código real y combinarás las instrucciones y la demostración juntas como PR 2.
+
+En este ejercicio:
+
+- explorarás instrucciones generales del repositorio y limitadas por ruta.
+- añadirás un estándar de documentación sin implementar el filtrado antes de tiempo.
+- demostrarás el estándar en una pequeña función auxiliar o un componente existente.
+- validarás y combinarás el hito de instrucciones.
+
+## Explorar las instrucciones
+
+El repositorio ya contiene dos tipos útiles de instrucciones:
+
+- `.github/copilot-instructions.md` proporciona contexto general del repositorio, como la pila tecnológica, la estructura y las prácticas habituales.
+- `.github/instructions/*.instructions.md` proporciona directrices de alcance limitado. Un patrón glob `applyTo` en el frontmatter identifica los archivos a los que se aplican.
+
+Abre estos archivos en el editor:
+
+1. Lee `.github/copilot-instructions.md` y localiza los estándares actuales de programación y verificación.
+2. Explora `.github/instructions/`, incluidas las directrices de Astro, capa de datos y pruebas.
+3. En `unit-tests.instructions.md`, examina el patrón `applyTo` y las convenciones de pruebas.
+4. En `drizzle.instructions.md`, examina los patrones de acceso a datos y las referencias a ejemplos.
+
+Mantén concisas las instrucciones generales, coloca los detalles específicos de archivo en el archivo de instrucciones pertinente y evita copias contradictorias de la misma regla. La [referencia de compatibilidad de instrucciones de GitHub][instruction-support] explica qué formatos admite cada entorno.
+
+> [!NOTE]
+> Las instrucciones influyen en la generación; no garantizan el cumplimiento. Tu revisión comprobará tanto el texto de las instrucciones como su efecto en el código. Si Copilot ya produce buenos comentarios, el objetivo es hacer explícita y repetible la convención, no forzar un fallo para comparar un antes y un después.
+
+## Partir de la PR 1 combinada
+
+Confirma que la PR de valoraciones por estrellas está combinada. Desde la terminal del repositorio del participante, inicia el siguiente hito a partir de `main` actualizado:
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c update-custom-instructions
+copilot --enable-all-github-mcp-tools
+```
+
+Si el árbol de trabajo no está limpio o falla la actualización, resuelve ese estado antes de continuar. Mantén el modo **Interactive**.
+
+En la pestaña **Issues** del repositorio, busca **Update our repository coding standards** y copia su URL real. La incidencia proporciona el contexto más amplio: explicar la intención, documentar funciones exportadas de la capa de datos y contratos de componentes y mantener los comentarios actualizados. Este ejercicio aborda una parte acotada de la documentación, no una refactorización de todo el repositorio ni una promesa de cumplir todos los criterios de la incidencia.
+
+## Añadir la convención de documentación
+
+Sustituye el marcador por la URL real de la incidencia y envía:
+
+```plaintext
+Lee esta incidencia de estándares de programación como contexto: . Examina las instrucciones generales y de alcance limitado existentes. Añade una convención de documentación específica: explica la intención en lugar de repetir el código, documenta las funciones exportadas de db/ y src/lib/ con TSDoc/JSDoc que cubra propósito, parámetros y valores de retorno, documenta los contratos de Props de los componentes reutilizables de Astro y mantén los comentarios actualizados cuando cambie el código relacionado.
+
+Coloca cada regla en el archivo de instrucciones existente adecuado y evita duplicaciones o contradicciones. Conserva los estándares de formato y lint existentes; enlaza o resume la convención de documentación en README donde corresponda. Limita este cambio al estándar de documentación, no a una migración de herramientas de formato ni a una reescritura de todo el repositorio. No crees una habilidad o un agente, no implementes el filtrado, no crees commits, no envíes cambios ni abras una PR. Detente para que pueda examinar las instrucciones antes de la demostración.
+```
+
+Examina las diferencias. La convención debe fomentar comentarios útiles, no exigir una cabecera genérica en todos los archivos ni comentarios que repitan código evidente. Pide correcciones antes de continuar.
+
+## Demostrar la convención en código real
+
+Elige una pequeña función auxiliar exportada o un componente reutilizable existente tras examinar el repositorio. No tiene que ser una función auxiliar de editores, y no se exige que `src/lib/publishers.ts` ya exista.
+
+Envía:
+
+```plaintext
+Con las instrucciones actualizadas, selecciona una pequeña función auxiliar exportada o un componente reutilizable de Astro existente que se beneficie de una documentación más clara. Aplica la convención directamente a ese archivo sin cambiar el comportamiento en ejecución ni añadir filtrado. Explica qué instrucción ha guiado el cambio y detente antes de crear un commit o abrir una PR.
+```
+
+Abre el archivo real modificado. En una función auxiliar, comprueba que los comentarios describen correctamente sus parámetros, el valor de retorno y cualquier argumento de base de datos inyectado. En un componente, comprueba que su contrato de `Props` está documentado. Confirma que la explicación coincide con el código en lugar de limitarte a buscar un bloque de comentarios.
+
+> [!TIP]
+> Un fragmento ilustrativo en el chat no es la demostración: examina un cambio real del repositorio. Si el código elegido ya cumple la convención, elige otro objetivo pequeño existente donde la mejora esté justificada en lugar de añadir comentarios redundantes.
+
+## Validar y combinar la PR 2
+
+Pide a Copilot que valide los cambios revisados:
+
+```plaintext
+Revisa los cambios de instrucciones y la pequeña demostración de documentación. Confirma que el comportamiento en ejecución no ha cambiado. Examina package.json, ejecuta npm run lint y npm run typecheck:all y ejecuta las pruebas existentes afectadas cuando el cambio de código lo justifique. Informa de los comandos exactos y sus resultados. No instales nada, no crees una habilidad, no crees commits, no envíes cambios ni abras una PR todavía.
+```
+
+Resuelve los fallos y examina las diferencias finales. Después autoriza el hito:
+
+```plaintext
+Crea un commit solo con las instrucciones de documentación revisadas, la actualización directamente relacionada de README y la pequeña demostración de código. Envía la rama actual y crea una PR a main siguiendo la plantilla de PR del repositorio. Incluye los resultados de verificación y referencia la incidencia de estándares de programación como contribución parcial; no utilices una palabra clave de cierre salvo que se cumplan realmente todos los criterios de la incidencia. No combines ni empieces el filtrado.
+```
+
+Abre la URL de la PR, examina **Files changed** y revisa CI. Cuando se superen todas las comprobaciones y revisiones obligatorias, combina en GitHub y confirma que la PR 2 está **Merged**. Sal de la sesión de CLI con `/exit`. No inicies el siguiente hito hasta que esta PR esté combinada.
+
+## Resumen y pasos siguientes
+
+La convención de documentación y una demostración real ya están en `main`. A continuación, [crearás el filtrado con Plan y Autopilot][next-lesson] en una rama nueva basada en ese estado combinado.
+
+## Recursos
+
+- [Añadir instrucciones personalizadas al repositorio][repository-instructions] explica las directrices generales y limitadas por ruta.
+- [Awesome Copilot][awesome-copilot] ofrece ejemplos para revisar y adaptar, no para adoptar a ciegas.
+
+[previous-lesson]: ../2-add-star-rating/
+[next-lesson]: ../4-build-filtering/
+[instruction-support]: https://docs.github.com/copilot/reference/custom-instructions-support
+[repository-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
+[awesome-copilot]: https://github.com/github/awesome-copilot
diff --git a/docs/es-es/cli/3-generating-code.md b/docs/es-es/cli/3-generating-code.md
deleted file mode 100644
index eb9e6c4b..00000000
--- a/docs/es-es/cli/3-generating-code.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: "Ejercicio 3 - Añadir funcionalidades al proyecto con GitHub Copilot CLI"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-Como ya puedes imaginar, una de las tareas principales que realizarás con GitHub Copilot CLI es añadir funciones, capacidades y código a un proyecto. Vamos a tomar una de las incidencias de tu backlog y pedir a Copilot que nos ayude a implementarla.
-
-## Escenario
-
-Ha llegado el momento de completar el filtrado en el proyecto. Ya tienes la incidencia de filtrado en tu backlog y un helper base del ejercicio anterior. Vamos a hacer que Copilot recupere los detalles de la incidencia, tenga en cuenta el trabajo existente y construya la funcionalidad restante.
-
-En este ejercicio vas a:
-
-- utilizar el modo de planificación para generar un plan de implementación de la funcionalidad de filtrado.
-- generar con Copilot el código necesario para añadir el filtrado al sitio web.
-
-Al final de este ejercicio, habrás añadido nueva funcionalidad al proyecto.
-
-## Utilizar el modo de planificación
-
-Uno de los mejores usos de la IA es la planificación. Muchas veces tendrás una buena idea de lo que quieres construir, pero solo necesitas contrastar algunas ideas con algo. Las herramientas de IA pueden ayudarte a concretar tus ideas haciendo preguntas de seguimiento y analizando distintos riesgos o componentes que falten. Para apoyar este proceso, Copilot CLI ofrece un modo de planificación. Además, el tiempo que dediques a planificar ayudará a Copilot a generar código que se ajuste mejor a los requisitos establecidos.
-
-Empezarás el proceso de creación de la nueva funcionalidad utilizando el modo de planificación de Copilot CLI.
-
-> [!TIP]
-> **Inicia una sesión de Copilot CLI**
->
-> Antes de empezar los ejercicios siguientes, vuelve a tu codespace y abre un terminal (Ctrl+\` si no hay ninguno abierto). Después, inicia Copilot CLI con `--yolo` y `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar la sesión más reciente de este proyecto en lugar de empezar desde cero, ejecuta `copilot --yolo --enable-all-github-mcp-tools --continue`. Si Copilot CLI ya se está ejecutando desde un ejercicio anterior, envía `/clear` para empezar una conversación limpia.
->
-> `--enable-all-github-mcp-tools` habilita las herramientas GitHub MCP de lectura y escritura para la sesión actual, de modo que Copilot pueda leer tu backlog y abrir pull requests durante el flujo del taller.
-
-> [!CAUTION]
-> `--yolo` habilita permisos automáticos completos (`--allow-all-tools`, `--allow-all-paths` y `--allow-all-urls`). Úsalo solo en un entorno aislado, como un Codespace o una máquina virtual, y no lo configures nunca como alias predeterminado para el desarrollo diario. Consulta [Allowing and denying tool use][allow-all-warning] para más información.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. Introduce el siguiente prompt en Copilot CLI para crear un plan basado en la incidencia de filtrado:
-
- ```
- /plan Retrieve the issue on the repository related to adding filtering. We already added a publishers helper in src/lib/publishers.ts, so treat that as existing work and plan the remaining updates (games filtering logic, UI, and tests).
- ```
-
-2. Copilot puede hacer preguntas de seguimiento mientras desarrolla el plan. Cuando aparezcan, respóndelas según cómo construirías tú la funcionalidad.
-3. Una vez generado el plan, revisa el esquema. Deberías ver que recomienda cambios pendientes en la capa de datos y en la interfaz, además de generar pruebas.
-4. Copilot CLI te ofrecerá la posibilidad de añadir comentarios adicionales al plan. Puedes mover el cursor hasta la sección indicada y escribir tus sugerencias. Copilot incorporará esas sugerencias a una nueva versión del plan.
-5. Cuando estés conforme, selecciona la opción que ofrece Copilot para empezar a trabajar en la nueva funcionalidad.
-
-> [!NOTE]
-> Como Copilot es probabilístico, el texto exacto y las opciones que se muestren variarán. Sin embargo, verás una opción para empezar a construir que dirá algo parecido a esto:
->
-> `Yes, and switch to autopilot mode`.
->
-> Copilot puede ofrecerte la opción de habilitar el [modo autopilot](https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot), como se muestra en el ejemplo anterior. El modo autopilot permite que Copilot CLI trabaje en una tarea sin esperar tu intervención después de cada paso. Una vez que le das la instrucción inicial, Copilot CLI resuelve cada paso de forma autónoma hasta que determina que la tarea está completa. Como estamos trabajando en un entorno aislado, podemos ejecutar autopilot y permitir todas las herramientas.
-
-6. Copilot se pondrá manos a la obra generando los archivos.
-
-> [!NOTE]
-> Es probable que esta operación tarde varios minutos. Verás a Copilot editar y crear archivos, actualizar y generar pruebas, y ejecutar todas las pruebas para comprobar que todo funciona correctamente. Es un buen momento para reflexionar sobre lo que has explorado hasta ahora o para tomarte algo.
-
-## Revisar el código
-
-Todo código generado por IA debe revisarse antes de fusionarse en producción. Vamos a dedicar ahora un momento a explorar los archivos que Copilot ha creado y modificado al implementar la nueva funcionalidad.
-
-1. Usa Copilot CLI para mostrar el "diff" o los cambios de código con el siguiente comando en Copilot CLI:
-
- ```
- /diff
- ```
-
-2. Observa los archivos modificados. Usa las teclas de dirección izquierda y derecha para ver los distintos archivos. Deberías ver actualizaciones en archivos como la página del listado de juegos (donde viven los nuevos controles de filtrado y el filtrado del lado del cliente) y `src/lib/games.ts`, además de pruebas como `games.test.ts`. También es posible que veas cambios en `publishers.ts` si Copilot ajusta tu helper existente para alinearlo con la implementación completa.
-
-## Resumen y siguientes pasos
-
-Ya has añadido la funcionalidad de filtrado al sitio web con la ayuda de Copilot CLI. En concreto:
-
-- has utilizado el modo de planificación para generar un plan de implementación de la funcionalidad de filtrado.
-- has generado con Copilot el código necesario para añadir el filtrado al sitio web.
-
-Por supuesto, el siguiente paso es asegurarte de que funciona. Vamos a [probar tu funcionalidad con el servidor MCP de Playwright][next-lesson] antes de abrir una pull request.
-
-## Recursos
-
-- [Usar Copilot CLI][using-copilot-cli]
-- [Acerca de Copilot CLI][about-copilot-cli]
-- [Gestión del contexto en Copilot CLI][context-management]
-
-[previous-lesson]: ../2-custom-instructions/
-[next-lesson]: ../4-mcp/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
diff --git a/docs/es-es/cli/4-build-filtering.md b/docs/es-es/cli/4-build-filtering.md
new file mode 100644
index 00000000..e46f788d
--- /dev/null
+++ b/docs/es-es/cli/4-build-filtering.md
@@ -0,0 +1,102 @@
+---
+title: "Ejercicio 4 - Crear el filtrado con Plan y Autopilot"
+description: "Acuerda los requisitos de filtrado, aprueba un plan de implementación, valida el código y guarda un punto de control en la rama de la funcionalidad."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Ahora crea la funcionalidad más amplia: permitir que los usuarios filtren juegos por categoría y editor. Planificarás antes de programar, autorizarás explícitamente **Autopilot**, revisarás y probarás la implementación y guardarás un punto de control. Este ejercicio no crea la habilidad, el agente de QA ni la PR de la funcionalidad.
+
+## Iniciar el hito de filtrado
+
+Confirma que las PR 1 y 2 están combinadas. En la terminal del repositorio del participante:
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-game-filtering
+copilot --enable-all-github-mcp-tools
+```
+
+Continúa solo con un árbol de trabajo limpio y una actualización correcta desde `main`. Los Ejercicios 4–8 utilizan esta misma rama y copia de trabajo. Los commits de puntos de control posteriores añadirán la habilidad y el perfil de QA; no crees una rama por ejercicio.
+
+## Recuperar la incidencia real
+
+Busca **Allow users to filter games by category and publisher** en la pestaña **Issues** del repositorio y copia su URL. No supongas que el nombre de archivo de la plantilla o un número de incidencia identifica la incidencia en tu copia.
+
+La incidencia actual exige:
+
+- seleccionar una o varias categorías.
+- filtrar por editor y combinarlo con las categorías.
+- funciones auxiliares de acceso a datos en `src/lib/` que admitan ambos filtros.
+- controles accesibles con navegación por teclado, ARIA adecuado, estados de foco visibles y atributos `data-testid`.
+- cobertura unitaria con Vitest de las funciones auxiliares y cobertura E2E con Playwright del comportamiento de filtrado.
+
+Lee la incidencia actual como fuente de verdad. Conserva su URL y cualquier aclaración que apruebes para la indicación de QA del Ejercicio 7.
+
+## Planificar antes de programar
+
+Utiliza Shift+Tab para seleccionar el modo **Plan**, o empieza con `/plan`. Sustituye el marcador de la incidencia y envía:
+
+```plaintext
+Planifica la funcionalidad de filtrado descrita en esta incidencia: . Lee la incidencia, las instrucciones del repositorio, las funciones auxiliares de acceso a datos existentes, la interfaz y las pruebas antes de proponer cambios. Toma la copia de trabajo actual como punto de partida; no supongas que ya se ha creado una función auxiliar de editores.
+
+Cubre la selección de varias categorías, el filtrado por editor, su combinación, el soporte de acceso a datos, los controles accesibles y la cobertura unitaria/E2E. Pídeme que aclare comportamientos no especificados, como la forma de combinar varias categorías, limpiar los filtros y los resultados vacíos; registra las decisiones con el plan aprobado. Conserva la arquitectura estática de Astro en lugar de introducir una API de servidor innecesaria.
+
+Planifica la implementación en la rama actual, incluidas las pruebas unitarias y E2E necesarias y la verificación con npm run lint, npm run test:unit, npm run test:e2e y npm run typecheck:all. Examina primero los requisitos previos y a quién pertenece el servidor; informa de los bloqueos en lugar de instalar software o detener procesos ajenos.
+
+Incluye estos límites de ejecución en el plan: cuando lo apruebe, implementa solo la funcionalidad de filtrado y las pruebas necesarias, ejecuta las comprobaciones y después detente para que pueda revisar. No crees la habilidad quality-checks, un agente de QA ni otros recursos de ejercicios posteriores. No cambies de rama, no crees commits, no envíes cambios ni abras o combines una PR.
+
+No edites código de la aplicación ni empieces la implementación hasta que apruebe el plan.
+```
+
+Responde a las preguntas de seguimiento. No añadas después criterios de aceptación ocultos: guarda las respuestas acordadas junto con la URL de la incidencia para que la implementación, las comprobaciones de navegador y QA utilicen los mismos requisitos.
+
+Revisa que el plan incluya cambios en la capa de datos y la interfaz, pruebas, controles accesibles y la convención de documentación que has combinado. Confirma que incluye explícitamente las cuatro comprobaciones, la parada para revisión y las prohibiciones de crear recursos posteriores del taller, cambiar de rama, crear commits, enviar cambios y realizar operaciones de PR. Pide revisiones antes de aprobar si falta algún límite o criterio o si propone trabajo ajeno a la incidencia.
+
+## Aprobar Autopilot explícitamente
+
+Solo cuando el plan incluya el alcance y los límites de ejecución revisados, utiliza la opción de aprobación **Accept plan and build on autopilot**. Si tu versión utiliza otro texto, selecciona explícitamente la opción que cambia a **Autopilot** y comprueba el indicador de modo. La aprobación inicia la ejecución del plan acotado; no confíes en una indicación posterior para añadir límites cuando el trabajo ya haya empezado.
+
+> [!CAUTION]
+> Autopilot controla la continuación del trabajo, no solo los permisos de herramientas. Revisa el cuadro de diálogo de permisos antes de elegir. Los permisos completos permiten acceso a herramientas, rutas y URL; los limitados pueden bloquear acciones que requieren aprobación. Un codespace no da permiso para exponer secretos ni cambiar recursos ajenos. Resuelve deliberadamente el acceso bloqueado en lugar de tratar las comprobaciones omitidas como superadas.
+
+Supervisa el trabajo y los resultados de los comandos. Autopilot puede detenerse en un límite de continuación o informar de un bloqueo antes de completar el plan. Revisa ese estado antes de autorizar que continúe y mantén el mismo alcance.
+
+## Volver a Interactive y revisar
+
+Cuando se detenga la implementación, utiliza Shift+Tab para volver al modo **Interactive** antes de enviar más indicaciones. Autopilot puede permanecer activo tras una tarea; no supongas que ha vuelto automáticamente.
+
+Introduce `/diff` y examina todos los archivos modificados. Compara la implementación con la incidencia y las aclaraciones aprobadas:
+
+- ¿Pueden los usuarios seleccionar varias categorías, filtrar por editor y combinarlos según lo acordado?
+- ¿Las funciones auxiliares de acceso a datos admiten realmente los filtros, en lugar de cambiar solo la interfaz?
+- ¿Los controles tienen etiquetas significativas, soporte de teclado, foco visible e identificadores de prueba estables?
+- ¿Las pruebas verifican el comportamiento, incluidos los casos acordados de limpieza y resultados vacíos, sin debilitar las aserciones existentes?
+- ¿El código sigue la convención de documentación y conserva la arquitectura estática de la aplicación?
+
+Revisa las pruebas de ejecución de las cuatro comprobaciones npm. Aún no has creado `quality-checks`, así que estas comprobaciones se ejecutan directamente. La configuración E2E de Playwright compila y sirve una vista previa; antes de ejecutar la batería, detén solo un servidor de desarrollo que hayas iniciado tú para evitar que reutilice contenido obsoleto. Un conflicto de puerto o un navegador ausente es un bloqueo que resolver, no una razón para terminar otro proceso o afirmar que se ha superado una comprobación.
+
+Solicita correcciones específicas si hacen falta, vuelve a ejecutar las comprobaciones afectadas y asegúrate de que la implementación final está completamente verificada. La observación directa en el navegador llega en el Ejercicio 6; tiene una finalidad distinta de esta verificación automatizada.
+
+## Guardar el punto de control de implementación
+
+Cuando las diferencias y los resultados sean satisfactorios, autoriza un punto de control local:
+
+```plaintext
+Revisa las diferencias actuales y los resultados de verificación. Crea un commit de punto de control que contenga solo la implementación de filtrado revisada y sus pruebas. Mantén la rama y la copia de trabajo de filtrado actuales. No envíes cambios, no abras una PR ni crees todavía la habilidad o el agente de QA.
+```
+
+Registra la revisión probada y conserva la URL de la incidencia y las aclaraciones aprobadas. Mantén **Interactive** y continúa en esta misma copia de trabajo con el [Ejercicio 5 - Crear y utilizar una habilidad quality-checks][next-lesson].
+
+## Recursos
+
+- [Modo Autopilot y permisos][autopilot] explica la continuación autónoma y cómo volver a Interactive.
+- [Referencia de comandos de Copilot CLI][cli-reference] enumera los controles de modo y los comandos actuales.
+
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
+[autopilot]: https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/es-es/cli/4-mcp.md b/docs/es-es/cli/4-mcp.md
deleted file mode 100644
index c7694b51..00000000
--- a/docs/es-es/cli/4-mcp.md
+++ /dev/null
@@ -1,160 +0,0 @@
----
-title: "Ejercicio 4 - Probar tu funcionalidad con el servidor MCP de Playwright"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-Acabas de generar la funcionalidad de filtrado con Copilot CLI. Antes de abrir una pull request, deberías confirmar que funciona en el navegador. En lugar de recorrer la aplicación manualmente, conectarás el **servidor MCP de Playwright** y dejarás que Copilot controle un navegador real para probar la funcionalidad por ti.
-
-En este ejercicio vas a:
-
-- comprender qué es Model Context Protocol (MCP) y cómo amplían los servidores MCP las capacidades de Copilot CLI.
-- añadir el servidor MCP de Playwright a Copilot CLI.
-- pedir a Copilot que lo use para probar manualmente tu funcionalidad de filtrado en un navegador.
-
-## ¿Qué es Model Context Protocol (MCP)?
-
-[Model Context Protocol (MCP)](https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/) proporciona a los agentes de IA una forma de comunicarse con herramientas y servicios externos. Al usar MCP, los agentes de IA pueden comunicarse con herramientas y servicios externos en tiempo real. Esto les permite acceder a información actualizada (mediante recursos) y realizar acciones en tu nombre (mediante herramientas).
-
-Se accede a estas herramientas y recursos a través de un servidor MCP, que actúa como puente entre el agente de IA y las herramientas y servicios externos. El servidor MCP se encarga de gestionar la comunicación entre el agente de IA y las herramientas externas (como API existentes o herramientas locales como paquetes de NPM). Cada servidor MCP representa un conjunto distinto de herramientas y recursos a los que el agente de IA puede acceder.
-
-Algunos servidores MCP populares ya existentes son:
-
-- **[GitHub MCP Server](https://github.com/github/github-mcp-server)**: este servidor proporciona acceso a un conjunto de API para gestionar tus repositorios de GitHub. Permite al agente de IA realizar acciones como crear repositorios nuevos, actualizar los existentes y gestionar incidencias y pull requests.
-- **[Playwright MCP Server](https://github.com/microsoft/playwright-mcp)**: este servidor proporciona capacidades de automatización del navegador mediante Playwright. Permite al agente de IA realizar acciones como navegar por páginas web, rellenar formularios y seleccionar botones.
-
-Hay muchos otros servidores MCP disponibles que proporcionan acceso a distintas herramientas y recursos. GitHub aloja un [registro de MCP](https://github.com/mcp) para mejorar la visibilidad y las contribuciones al ecosistema.
-
-> [!CAUTION]
-> En términos de seguridad, trata los servidores MCP como tratarías cualquier otra dependencia de tu proyecto. Antes de usar un servidor MCP, revisa cuidadosamente su código fuente, verifica el publicador y valora las implicaciones de seguridad. Usa solo servidores MCP en los que confíes y ten cuidado al conceder acceso a recursos u operaciones sensibles.
-
-> [!NOTE]
-> El [servidor GitHub MCP][github-mcp-server] está **integrado** en Copilot CLI: ya está disponible sin ninguna configuración, y así es como Copilot ha estado leyendo y escribiendo en tu repositorio durante todo el taller. En este ejercicio añadirás un *segundo* servidor, Playwright, para darle a Copilot un navegador.
-
-## Añadir el servidor MCP de Playwright
-
-La forma más rápida de añadir un servidor es el comando interactivo `/mcp add`. Registrarás el [servidor MCP de Playwright][playwright-mcp-server], que proporciona a Copilot un navegador que puede controlar.
-
-> [!TIP]
-> **Inicia una sesión de Copilot CLI**
->
-> Antes de empezar los ejercicios siguientes, vuelve a tu codespace y abre un terminal (Ctrl+\` si no hay ninguno abierto). Después, inicia Copilot CLI con `--yolo` y `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar la sesión más reciente de este proyecto en lugar de empezar desde cero, ejecuta `copilot --yolo --enable-all-github-mcp-tools --continue`. Si Copilot CLI ya se está ejecutando desde un ejercicio anterior, envía `/clear` para empezar una conversación limpia.
->
-> `--enable-all-github-mcp-tools` habilita las herramientas GitHub MCP de lectura y escritura para la sesión actual, de modo que Copilot pueda leer tu backlog y abrir pull requests durante el flujo del taller.
-
-> [!CAUTION]
-> `--yolo` habilita permisos automáticos completos (`--allow-all-tools`, `--allow-all-paths` y `--allow-all-urls`). Úsalo solo en un entorno aislado, como un Codespace o una máquina virtual, y no lo configures nunca como alias predeterminado para el desarrollo diario. Consulta [Allowing and denying tool use][allow-all-warning] para más información.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. En tu sesión de Copilot CLI, introduce:
-
- ```text
- /mcp add
- ```
-
-2. Aparecerá un formulario de configuración. Usa Tab para desplazarte por los campos y complétalo de esta forma:
-
- - **Server Name**: `playwright`
- - **Server Type**: selecciona **Local** (también aparece como **STDIO**)
- - **Command**: `npx @playwright/mcp@latest --headless`
- - **Tools**: déjalo en `*` para permitir todas las herramientas del servidor
-
-3. Pulsa Ctrl+S para guardar. El servidor se añade y queda disponible de inmediato; no hace falta reiniciar nada.
-
-La opción `--headless` indica a Playwright que ejecute el navegador sin una ventana visible, lo que es necesario dentro de un codespace donde no hay un escritorio para mostrarlo. Internamente, esto escribe el servidor en tu archivo `~/.copilot/mcp-config.json`:
-
-```json
-{
- "mcpServers": {
- "playwright": {
- "type": "local",
- "command": "npx",
- "args": ["@playwright/mcp@latest", "--headless"],
- "tools": ["*"]
- }
- }
-}
-```
-
-4. Confirma que el servidor está registrado y activo mostrando la lista de servidores MCP:
-
- ```text
- /mcp show
- ```
-
-5. Deberías ver `playwright` en la lista junto con el servidor `github` integrado.
-
-> [!NOTE]
-> El proyecto Tailspin Toys ya usa Playwright para sus pruebas end-to-end, así que normalmente el navegador que Playwright necesita ya está instalado. Si Copilot informa más adelante de que falta un navegador, pídele que ejecute `npx playwright install chromium` y vuelve a intentarlo.
-
-## Iniciar el sitio web
-
-El servidor MCP de Playwright necesita una aplicación en ejecución sobre la que probar. Inicia el servidor de desarrollo de Astro en un terminal **independiente** para que siga ejecutándose mientras trabajas en Copilot CLI.
-
-1. Abre un terminal nuevo en tu codespace pulsando Ctrl+\`.
-2. Inicia el sitio web:
-
- ```bash
- npm run dev
- ```
-
-3. Deja este terminal en ejecución. Cuando veas el banner `Astro server: http://localhost:4321`, la aplicación estará lista.
-
-## Probar la funcionalidad de filtrado
-
-Vuelve a tu sesión de Copilot CLI y pídele a Copilot que pruebe la funcionalidad.
-
-El [servidor MCP de Playwright][playwright-mcp-server] le da a Copilot un navegador real que puede controlar. En lugar de que tengas que recorrer manualmente la aplicación para comprobar tu trabajo, el agente puede abrir una página, navegar, aplicar filtros y devolverte el resultado, para luego resumirte lo que ha visto. Es la forma más rápida de confirmar que una funcionalidad se comporta como esperas sin salir de la conversación.
-
-Internamente, el servidor MCP de Playwright trabaja a partir del [árbol de accesibilidad][playwright-mcp-server] de la página, en lugar de usar capturas de pantalla. Eso significa que el agente razona sobre elementos estructurados y etiquetados (botones, enlaces, elementos de lista) de la misma forma que lo hace la tecnología de asistencia, así que una comprobación funcional rápida también sirve como verificación básica de accesibilidad.
-
-Con el servidor conectado y la aplicación en ejecución, pídele a Copilot que ejercite la funcionalidad de filtrado que acabas de crear:
-
-```text
-Using the Playwright MCP server, open a browser to the running app at http://localhost:4321 and verify the new game filtering feature:
-
-1. Go to the games page and note how many games are listed.
-2. Apply a category filter and confirm the list updates to only show games in that category.
-3. Clear it, then apply a publisher filter and confirm the list updates to that publisher.
-4. Combine a category and a publisher filter and confirm the results respect both.
-
-Report what you observe at each step, and call out anything that does not behave as expected.
-```
-
-Copilot iniciará un navegador a través del servidor MCP de Playwright, recorrerá cada paso y te informará de lo que ha encontrado. Lee su resumen comparándolo con los criterios de aceptación de la incidencia. Si algo no parece correcto, haz preguntas de seguimiento o pídele que vuelva a corregir el código antes de abrir una pull request.
-
-> [!NOTE]
-> La aplicación debe estar ejecutándose en `http://localhost:4321` para esta prueba. Si has detenido el servidor de desarrollo, vuelve a iniciarlo antes de enviar el prompt. La primera vez que Copilot use el servidor MCP de Playwright puede que necesite descargar un navegador; si informa de que falta uno, pídele que ejecute `npx playwright install chromium` y vuelve a intentarlo.
-
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
-
-## Resumen y siguientes pasos
-
-¡Enhorabuena! Has usado el servidor MCP de Playwright para probar manualmente tu funcionalidad con Copilot CLI. En resumen:
-
-- has aprendido qué es Model Context Protocol (MCP) y cómo amplían los servidores MCP las capacidades de Copilot CLI.
-- has añadido el servidor MCP de Playwright con `/mcp add`.
-- has pedido a Copilot que controle un navegador y verifique tu funcionalidad de filtrado antes de publicarla.
-
-Ahora que has confirmado que la funcionalidad funciona, puedes continuar con el siguiente ejercicio, en el que [abrirás una pull request con la ayuda de una habilidad de agente][next-lesson].
-
-## Recursos
-
-- [¿Qué demonios es MCP y por qué todo el mundo habla de ello?][mcp-blog-post]
-- [Servidor MCP de Playwright de Microsoft][playwright-mcp-server]
-- [Añadir servidores MCP para Copilot CLI][cli-add-mcp]
-- [Servidor MCP de GitHub][github-mcp-server]
-
-[previous-lesson]: ../3-generating-code/
-[next-lesson]: ../5-agent-skills/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[github-mcp-server]: https://github.com/github/github-mcp-server
-[cli-add-mcp]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
diff --git a/docs/es-es/cli/5-agent-skills.md b/docs/es-es/cli/5-agent-skills.md
index ec274c1e..ba0791dd 100644
--- a/docs/es-es/cli/5-agent-skills.md
+++ b/docs/es-es/cli/5-agent-skills.md
@@ -1,121 +1,93 @@
---
-title: "Ejercicio 5 - Usar habilidades de agente"
+title: "Ejercicio 5 - Crear y utilizar una habilidad quality-checks"
+description: "Pide a Copilot que cree comprobaciones de calidad reutilizables con scripts de shell incluidos, examina la habilidad y ejecútala en la rama de filtrado."
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
-Desarrollar una aplicación suele implicar tareas repetibles, como generar builds, ejecutar pruebas o crear pull requests. Las **habilidades de agente** te permiten dar a Copilot, y a otros agentes de IA, directrices sobre cómo realizar esas tareas. Una habilidad es una carpeta de instrucciones, scripts y recursos que el agente puede cargar bajo demanda. [Agent Skills es un estándar abierto][agent-skills-repo] utilizado por distintos agentes, por lo que la misma habilidad puede funcionar en Copilot Chat en modo agente, Copilot cloud agent, Copilot CLI y la aplicación GitHub Copilot.
+La funcionalidad de filtrado está implementada y comprobada con los comandos npm existentes. Ahora reunirás esas comprobaciones en una **habilidad de agente** reutilizable. Mantén la misma sesión y rama de filtrado durante los Ejercicios 4–8; este ejercicio no crea una solicitud de incorporación de cambios.
-Las habilidades viven en la carpeta `.github/skills` de un proyecto, o globalmente en `~/.copilot/skills`. Cada habilidad es una carpeta que contiene un archivo `SKILL.md` con frontmatter YAML (un `name` y un `description`) seguido de las instrucciones en Markdown:
+En este ejercicio:
-```yaml
----
-name: make-contribution
-description: All changes to code must follow the guidance documented in the repository. Before any issue is filed, branch is made, commits generated, or pull request (or PR) created, a search must be done to ensure the right steps are followed. Whenever asked to create an issue, commit messages, to push code, or create a PR, use this skill so everything is done correctly.
----
-```
-
-Las habilidades también pueden incluir subcarpetas con scripts, recursos y material de referencia. La estructura completa se describe en la [especificación de agent skills][agent-skills-spec].
-
-> [!TIP]
-> Las habilidades se cargan dinámicamente. El agente decide qué habilidad se aplica a partir del campo `description`; una descripción clara y específica para el escenario marca la diferencia entre una habilidad que se usa y otra que se ignora.
+- volverás al modo **Interactive** antes de crear personalizaciones.
+- pedirás a Copilot que cree `quality-checks` y después se detenga para que la examines.
+- ejecutarás las cuatro comprobaciones mediante los scripts incluidos y demostrarás que un argumento que indica un único archivo de pruebas selecciona solo ese archivo.
+- guardarás un punto de control de la habilidad junto con la funcionalidad de filtrado.
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
+## Instrucciones, scripts y recursos
-Vamos a ver cómo una habilidad puede garantizar que las pull requests sigan las especificaciones marcadas por nuestro equipo.
+Las habilidades reúnen instrucciones de tareas reutilizables, scripts ejecutables y recursos de apoyo que un agente carga cuando los necesita. Los agentes personalizados definen roles especializados, instrucciones y herramientas disponibles. Son complementarios: un agente personalizado puede ejecutar scripts, incluidos los de una habilidad.
-## Escenario
+Una habilidad del repositorio reside en `.github/skills//SKILL.md`, con `name` y `description` en el frontmatter e instrucciones en Markdown. Los scripts y otros recursos se encuentran junto a ese archivo. Pedirás a Copilot que genere `.github/skills/quality-checks/SKILL.md` y sus scripts incluidos, en lugar de copiar una solución preparada. La [especificación de Agent Skills][skill-spec] describe el formato.
-El equipo tiene una serie de requisitos para las pull requests (PR):
+Copilot utiliza la descripción de una habilidad descubierta para decidir cuándo cargarla. No supongas que una habilidad nueva se descubre inmediatamente en una sesión ya abierta; la sección de ejecución incluye una alternativa de lectura explícita. Un formato portable no elimina los requisitos previos del shell o del proyecto.
-- mensajes de confirmación claros, con los archivos agrupados de forma lógica.
-- todas las pruebas deben superarse antes de crear una PR.
-- cada PR debe contener las siguientes secciones:
- - una descripción de por qué se hicieron los cambios.
- - una visión general de los archivos modificados.
- - fragmentos de bloques de código importantes.
- - detalles de los cambios realizados agrupados juntos.
+## Crear la habilidad
-Como el equipo usa Copilot para generar código y PR, quiere asegurarse de que las herramientas de IA sigan estos requisitos.
+Vuelve al modo **Interactive** antes de enviar la indicación. Mantén la copia de trabajo y la rama actuales. Si empezaste con una plantilla antigua que ya contiene esta habilidad, examínala y amplíala en lugar de sobrescribir tus personalizaciones.
-En este ejercicio vas a:
+```plaintext
+Crea .github/skills/quality-checks/SKILL.md y cuatro scripts envoltorio para npm run lint, npm run test:unit, npm run test:e2e y npm run typecheck:all. Lee primero package.json, README, la configuración de pruebas y las instrucciones del repositorio.
-- explorar una habilidad existente para crear pull requests.
-- aprender cómo utiliza el agente de IA las habilidades.
-- crear una PR que cumpla las directrices con ayuda de la habilidad.
+Detecta este entorno. Crea SOLO scripts Bash .sh para macOS/Linux/WSL O scripts PowerShell .ps1 para Windows nativo; pregunta si no está claro. No crees ambos. Limita los scripts envoltorio a resolver la raíz del repositorio desde su propia ubicación, verificar que allí está el package.json de este proyecto e invocar npm. Si la raíz no es válida, falla con un mensaje claro. Admite cualquier directorio de trabajo y rutas con espacios. Conserva la salida y los códigos de salida de los fallos, incluidos los fallos de comandos nativos en PowerShell. Inserta el separador -- de npm exactamente una vez; quienes invoquen los scripts deben pasar directamente los argumentos de la herramienta, sin otro --. No gestiones puertos ni procesos.
-## Ejecutar habilidades
+Incluye en SKILL.md un frontmatter con name y description, instrucciones para ejecutar los cuatro scripts envoltorio, requisitos previos, resolución de problemas y ejemplos portables que incluyan un archivo existente de pruebas unitarias. Todos los ejemplos de Bash deben invocar bash explícitamente; nunca eludas la directiva de ejecución de PowerShell. Explica la reutilización de servidores de Playwright: detén solo los servidores que hayas iniciado realmente; en caso contrario, pregunta.
-Las habilidades se cargan dinámicamente cuando el agente determina que son necesarias. La decisión de qué habilidades usar depende de la descripción del archivo `SKILL.md`. Por eso, es importante que las descripciones sean claras y definan el caso de uso de la habilidad.
-
-## Explorar la habilidad de PR
-
-Como Tailspin Toys tiene un conjunto de requisitos para crear PR, ha creado una habilidad para ayudar a las herramientas de IA a generar PR que cumplan esas directrices. Vamos a explorar la habilidad para entender qué hará.
+Crea únicamente la habilidad y los scripts necesarios. No ejecutes comprobaciones ni sondeos, no instales nada, no cambies código de la aplicación, no crees commits ni abras una PR. Detente para que pueda revisar los archivos.
+```
-1. Abre `.github/skills/make-contribution/SKILL.md`.
-2. Fíjate en el nombre y la descripción. Observa cómo la descripción destaca el escenario en el que debe usarse, es decir, siempre que se solicite crear una pull request o confirmar código.
-3. Lee la habilidad. Observa que define reglas sobre cómo deben crearse las ramas, generarse las confirmaciones y redactarse los contenidos de la pull request.
+## Examinar la habilidad
-## Usar la habilidad
+1. Abre `.github/skills/quality-checks/SKILL.md` y sus scripts incluidos en el editor y examina las diferencias.
+2. Comprueba que `name` y `description` describen la habilidad y cuándo se aplica. Lee las instrucciones, no solo los metadatos.
+3. Confirma que la secuencia de ejecución invoca realmente los scripts incluidos bajo `.github/skills/quality-checks/` para lint, pruebas unitarias, E2E y comprobación de tipos.
+4. Examina en cada script envoltorio la resolución de la raíz relativa al script y la comprobación explícita de que el directorio calculado contiene el `package.json` previsto para esta copia de trabajo. Que un comando termine correctamente porque npm busca en directorios superiores no demuestra que la raíz sea correcta. Comprueba las rutas entre comillas, el reenvío de argumentos, la salida visible y los códigos de salida ante fallos; PowerShell debe propagar los fallos nativos de npm.
+5. Comprueba el ejemplo documentado de un único archivo de pruebas unitarias. El script envoltorio inserta el separador `--` de npm, por lo que quienes lo invoquen pasan directamente los argumentos de la herramienta de destino sin otro separador. Mantén las instrucciones reutilizables sin rutas absolutas de la copia de trabajo específicas de una máquina. Pide a Copilot que corrija las carencias antes de ejecutar nada.
+6. Limita los scripts a validar la raíz y el manifiesto y a ejecutar las comprobaciones npm existentes. Las decisiones sobre puertos y procesos corresponden a SKILL.md, no a código de gestión de procesos en shell. Confirma que solo se pueden detener servidores que el agente haya iniciado realmente; que coincidan el directorio de trabajo o el nombre del proceso no demuestra a quién pertenece. Los archivos entregados deben contener solo la habilidad, los scripts envoltorio necesarios y cualquier archivo auxiliar compartido que haga falta, sin archivos temporales de sondeo o depuración.
-Como se indicó antes, Copilot CLI invoca automáticamente las habilidades. Como resultado, lo único que tienes que hacer es pedirle a Copilot que cree una PR.
+> [!NOTE]
+> Tailspin Toys requiere actualmente Node.js 22.13 o posterior, las dependencias del proyecto y Chromium de Playwright para las comprobaciones E2E. Confirma los requisitos previos en README y `package.json` de tu copia de trabajo. Los requisitos previos ausentes o una directiva de ejecución de PowerShell que bloquee la ejecución necesitan una solución aprobada, no una instalación automática, una elusión de la directiva ni un cambio silencioso a npm directo.
-> [!TIP]
-> **Inicia una sesión de Copilot CLI**
->
-> Antes de empezar los ejercicios siguientes, vuelve a tu codespace y abre un terminal (Ctrl+\` si no hay ninguno abierto). Después, inicia Copilot CLI con `--yolo` y `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar la sesión más reciente de este proyecto en lugar de empezar desde cero, ejecuta `copilot --yolo --enable-all-github-mcp-tools --continue`. Si Copilot CLI ya se está ejecutando desde un ejercicio anterior, envía `/clear` para empezar una conversación limpia.
->
-> `--enable-all-github-mcp-tools` habilita las herramientas GitHub MCP de lectura y escritura para la sesión actual, de modo que Copilot pueda leer tu backlog y abrir pull requests durante el flujo del taller.
+## Ejecutar la habilidad
-> [!CAUTION]
-> `--yolo` habilita permisos automáticos completos (`--allow-all-tools`, `--allow-all-paths` y `--allow-all-urls`). Úsalo solo en un entorno aislado, como un Codespace o una máquina virtual, y no lo configures nunca como alias predeterminado para el desarrollo diario. Consulta [Allowing and denying tool use][allow-all-warning] para más información.
+Confirma que el servidor de desarrollo del ejercicio anterior se ha detenido. Playwright compila y sirve una vista previa para E2E, pero su configuración local puede reutilizar un servidor en el puerto `4321`. Un servidor de otra copia de trabajo no proporciona pruebas de verificación válidas para tu funcionalidad.
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
+Si Copilot CLI ofrece `/quality-checks`, selecciónalo para invocar explícitamente la habilidad descubierta e incluye la solicitud siguiente. Si no se ha descubierto, envía la misma solicitud directamente en esta sesión; leer la habilidad es una alternativa admitida en este ejercicio.
-1. Pídele a Copilot que cree una PR con el siguiente prompt:
+```plaintext
+Lee .github/skills/quality-checks/SKILL.md y sigue sus instrucciones para validar la funcionalidad de filtrado en esta copia de trabajo. Primero examina el código de cada script envoltorio para verificar que calcula el directorio que contiene el package.json previsto para esta copia de trabajo y falla de forma explícita si la raíz no es válida, en lugar de depender de que npm descubra paquetes en directorios superiores. No muevas, renombres, elimines ni modifiques archivos del repositorio para simular fallos. Ejecuta realmente los scripts incluidos para lint, pruebas unitarias, pruebas de un extremo a otro y comprobaciones de tipos. Ejecuta también el ejemplo documentado de un único archivo de pruebas unitarias, pasando directamente los argumentos de la herramienta de destino porque el script envoltorio se encarga del separador -- de npm. Verifica en los resultados del ejecutor de pruebas que SOLO se ha ejecutado el archivo indicado e informa de su nombre y del número de archivos de prueba ejecutados. Mostrar los argumentos o devolver el código de salida 0 no demuestra por sí solo que la selección sea correcta.
- ```
- Can you please create a pull request for me!
- ```
+Informa de cada invocación de script y su resultado, incluidos fallos, comprobaciones omitidas o requisitos previos ausentes. No sustituyas silenciosamente un script inutilizable de la habilidad por comandos npm directos. Identifica la copia de trabajo y el servidor que se prueban, detén solo los servidores que hayas iniciado y pregunta antes de instalar algo o detener otro proceso. No cambies código de la aplicación, no cambies de rama, no crees commits, no envíes cambios ni abras una solicitud de incorporación de cambios.
+```
-2. Copilot confirmará la solicitud. Al cabo de unos instantes, verás que Copilot indica que está utilizando la habilidad **make-contribution**.
+Examina las llamadas a herramientas y su salida. Los cuatro scripts deben ejecutarse realmente; una descripción de las comprobaciones o una comprobación omitida no equivale a superarlas. Para el ejemplo de un único archivo, compara el nombre de archivo solicitado con los resultados reales por archivo del ejecutor y el número comunicado: solo debe ejecutarse ese archivo. Mostrar los argumentos o devolver el código de salida 0 es insuficiente si también se ejecutaron otros archivos. Un fallo aporta información útil: corrige la habilidad o resuelve el bloqueo de configuración con aprobación y después repite las comprobaciones afectadas. No detengas procesos ajenos ni fuerces la resolución de un conflicto de puerto.
-3. Después, Copilot seguirá las instrucciones de la habilidad. Empezará ejecutando las pruebas y luego creará una rama, confirmaciones y, finalmente, la PR.
-4. Cuando se cree la PR, vuelve a tu repositorio y ábrela. Observa que las secciones siguen las directrices definidas en la habilidad y coinciden con los requisitos establecidos por el equipo.
-5. Antes de pasar al siguiente ejercicio, restablece tu espacio de trabajo local en una rama nueva desde `main` para que el trabajo de accesibilidad quede separado de esta PR de filtrado:
+## Guardar un punto de control
- ```bash
- git checkout main
- git pull
- git checkout -b accessibility-cli
- ```
+Cuando hayas revisado la habilidad y sus resultados, autoriza un punto de control local:
-## Resumen y siguientes pasos
+```plaintext
+Revisa las diferencias actuales y crea un commit de punto de control solo para los archivos de la habilidad quality-checks. Mantén la rama de filtrado existente. No envíes cambios ni crees una solicitud de incorporación de cambios.
+```
-Con la ayuda de una habilidad de agente, has creado una PR nueva que cumple los requisitos documentados. Has hecho lo siguiente:
+Los archivos de la habilidad acompañarán al filtrado, al perfil de QA y a las pruebas asociadas en la PR de funcionalidad del Ejercicio 8. Continúa en esta misma copia de trabajo con el [Ejercicio 6 - Validar la funcionalidad con MCP de Playwright][next-lesson].
-- explorar una habilidad existente para crear pull requests.
-- aprender cómo utiliza el agente de IA las habilidades.
-- crear una PR que cumple las directrices con ayuda de la habilidad.
+## Ejemplos adicionales de habilidades
-Las habilidades son perfectas para tareas concretas, pero para operaciones más amplias conviene aprovechar los [agentes personalizados][next-lesson], que exploraremos a continuación.
+Estos ejemplos de la comunidad son referencias, no tareas adicionales. Revisa sus requisitos previos y su comportamiento antes de adoptarlos:
-## Recursos
+- [Flujo de contribución: `make-repo-contribution`][contribution-example].
+- [Documentos de requisitos: `prd`][prd-example].
+- [Diagramas y un script de exportación incluido: `drawio`][drawio-example].
+- [Pruebas de navegador: `webapp-testing`][browser-example].
-- [Acerca de las habilidades de agente][about-agent-skills]
-- [Especificación de Agent Skills][agent-skills-spec]
-- [Repositorio de Agent Skills][agent-skills-repo]
-- [Habilidades de agente en awesome-copilot][awesome-copilot-skills]
+El ejemplo de contribución original se llama `make-repo-contribution`; las plantillas antiguas de Tailspin utilizaban otro nombre, `make-contribution`. Este taller no depende de ninguna de esas habilidades de contribución.
-[previous-lesson]: ../4-mcp/
-[next-lesson]: ../6-custom-agents/
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[awesome-copilot-skills]: https://github.com/github/awesome-copilot/tree/main/skills
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/es-es/cli/6-custom-agents.md b/docs/es-es/cli/6-custom-agents.md
deleted file mode 100644
index f9cf2562..00000000
--- a/docs/es-es/cli/6-custom-agents.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: "Ejercicio 6 - Agentes personalizados con GitHub Copilot CLI"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-## ¿Qué son los agentes personalizados?
-
-Los [agentes personalizados][custom-agents-concept] de GitHub Copilot te permiten crear asistentes de IA especializados y adaptados a tareas o dominios concretos dentro de tu flujo de desarrollo. Al definir agentes mediante archivos Markdown en la carpeta `.github/agents` de tu repositorio, puedes proporcionar a Copilot instrucciones enfocadas, buenas prácticas, patrones de desarrollo y conocimiento específico del dominio para orientarlo y que realice ciertos tipos de trabajo con mayor eficacia. Los equipos pueden codificar su experiencia en agentes reutilizables: un agente de accesibilidad que aplique el cumplimiento de [WCAG][wcag], un agente de seguridad que siga prácticas de desarrollo seguro o un agente de pruebas que mantenga patrones de prueba coherentes.
-
-Los agentes personalizados se definen mediante archivos Markdown en la carpeta `.github/agents` de tu proyecto, o globalmente en `~/.copilot/agents`. Cada archivo tiene frontmatter YAML con al menos `name` y `description`, seguido de un prompt en Markdown que define el comportamiento, la especialización y las instrucciones del agente.
-
-### Agentes personalizados frente a habilidades de agente
-
-Existe cierta superposición lógica entre los agentes personalizados y las [habilidades de agente][agent-skills-concept]. Ambos se definen principalmente mediante archivos Markdown y explican a una IA cómo realizar operaciones. La forma más clara de diferenciarlos es esta: un **agente personalizado** es quien trabaja y las **habilidades** son herramientas.
-
-Los agentes personalizados tienen su propia ventana de contexto y están pensados para orquestar habilidades, e incluso otros agentes, como parte de su trabajo. En este laboratorio, el agente personalizado de accesibilidad revisa y actualiza el sitio según las directrices de accesibilidad; como parte de ese trabajo podría invocar habilidades como una habilidad de flujo de trabajo de pull requests o una que ejecute y gestione pruebas.
-
-> [!NOTE]
-> No existe una única forma "correcta" de crear un agente personalizado. Como ocurre con todo en IA, conviene probar e iterar para descubrir qué funciona mejor en tus entornos y escenarios.
-
-[custom-agents-concept]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
-[agent-skills-concept]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[wcag]: https://www.w3.org/WAI/standards-guidelines/wcag/
-
-## Escenario
-
-Muchas aplicaciones web no logran ser accesibles para todos los usuarios, y el sitio web en el que estás trabajando no es una excepción. Usarás un agente personalizado para identificar y corregir carencias de accesibilidad.
-
-Tailspin Toys se compromete a garantizar que su plataforma de crowdfunding sea accesible para todos los usuarios, independientemente de sus capacidades visuales o preferencias. Comentarios recientes de usuarios han señalado que algunas personas encuentran el tema oscuro actual difícil de leer debido al contraste insuficiente entre el texto y los colores de fondo. Para responder a este problema de accesibilidad, el equipo de diseño ha solicitado implementar un modo de alto contraste que los usuarios puedan activar y desactivar.
-
-Como la accesibilidad es crítica, quieres asegurarte de que esto se implemente lo antes posible. Vas a utilizar un agente personalizado para generar la funcionalidad.
-
-En este ejercicio vas a:
-
-- explorar los agentes personalizados.
-- habilitar un agente personalizado y asignarle una tarea con Copilot CLI.
-
-## Revisar el agente personalizado de accesibilidad
-
-Ya se ha creado para ti un agente personalizado de accesibilidad. Vamos a revisar su contenido para entender cómo orientará a Copilot.
-
-1. Abre `.github/agents/accessibility.md`.
-2. Fíjate en el frontmatter YAML con los campos `name` y `description`.
-
-> [!CAUTION]
-> El frontmatter con `name` y `description` es obligatorio para los agentes personalizados.
-
-3. A continuación, revisa las secciones siguientes, que destacan:
- - responsabilidades principales al generar código para un sitio web accesible.
- - buenas prácticas de accesibilidad.
- - ejemplos de código para HTML, CSS y JavaScript.
- - una lista de errores y problemas habituales.
-
-## Usar un agente personalizado en Copilot CLI
-
-Puedes iniciar un agente personalizado en Copilot CLI con el comando `/agent`. Vamos a realizar una revisión de accesibilidad de nuestro sitio web.
-
-> [!TIP]
-> **Inicia una sesión de Copilot CLI**
->
-> Antes de empezar los ejercicios siguientes, vuelve a tu codespace y abre un terminal (Ctrl+\` si no hay ninguno abierto). Después, inicia Copilot CLI con `--yolo` y `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar la sesión más reciente de este proyecto en lugar de empezar desde cero, ejecuta `copilot --yolo --enable-all-github-mcp-tools --continue`. Si Copilot CLI ya se está ejecutando desde un ejercicio anterior, envía `/clear` para empezar una conversación limpia.
->
-> `--enable-all-github-mcp-tools` habilita las herramientas GitHub MCP de lectura y escritura para la sesión actual, de modo que Copilot pueda leer tu backlog y abrir pull requests durante el flujo del taller.
-
-> [!CAUTION]
-> `--yolo` habilita permisos automáticos completos (`--allow-all-tools`, `--allow-all-paths` y `--allow-all-urls`). Úsalo solo en un entorno aislado, como un Codespace o una máquina virtual, y no lo configures nunca como alias predeterminado para el desarrollo diario. Consulta [Allowing and denying tool use][allow-all-warning] para más información.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. Muestra la lista de agentes escribiendo `/agent` en la ventana de prompt de Copilot CLI y seleccionando Enter.
-2. Selecciona **Accessibility agent** en la lista de agentes disponibles.
-3. Usa el siguiente prompt para pedir al agente de accesibilidad que realice una revisión y genere correcciones para el elemento del backlog relacionado con accesibilidad:
-
- ```
- Perform an accessibility review of the site. Pull the related issue down from the repository for details. Implement a high-contrast mode toggle that persists the user's preference across page reloads. Ensure there are e2e tests for any updates made to the project. Then create a PR with the updates.
- ```
-
-4. Copilot se pondrá a trabajar en la tarea. Empezará recuperando la incidencia, después realizará la revisión, generará las actualizaciones y, por último, creará la PR. También deberías observar que, al crear la PR, utiliza la habilidad centrada en PR del proyecto.
-
-> [!NOTE]
-> Es probable que este proceso tarde unos minutos. Es un buen momento para reflexionar sobre todo lo que has aprendido, tomar algo o adelantarte al siguiente módulo, donde se comentan algunos comandos adicionales disponibles en Copilot CLI.
-
-## Resumen y siguientes pasos
-
-Esta lección ha explorado los [agentes personalizados][custom-agents] de GitHub Copilot, asistentes de IA especializados adaptados a tareas y dominios concretos. Con los agentes personalizados puedes codificar la experiencia y los estándares de tu equipo en agentes reutilizables que orienten a Copilot para realizar determinados tipos de trabajo con mayor eficacia.
-
-Has explorado estos conceptos:
-
-- cómo se definen los agentes personalizados.
-- cómo usar un agente personalizado en Copilot CLI.
-
-Ahora vamos a explorar [algunos comandos de barra][next-lesson] para aprender algunos trucos adicionales con Copilot CLI.
-
-## Recursos
-
-- [Agentes personalizados][custom-agents]
-- [Crear agentes personalizados para un repositorio][creating-custom-agents]
-- [Agentes personalizados en awesome-copilot][awesome-copilot-agents]
-- [Prepararse para usar agentes personalizados en tu organización][org-custom-agents]
-- [Prepararse para usar agentes personalizados en tu empresa][enterprise-custom-agents]
-
-[previous-lesson]: ../5-agent-skills/
-[next-lesson]: ../7-slash-commands/
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[creating-custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/create-custom-agents
-[awesome-copilot-agents]: https://github.com/github/awesome-copilot/tree/main/agents
-[org-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-organization/prepare-for-custom-agents
-[enterprise-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/prepare-for-custom-agents
diff --git a/docs/es-es/cli/6-mcp-playwright.md b/docs/es-es/cli/6-mcp-playwright.md
new file mode 100644
index 00000000..6d6c85e0
--- /dev/null
+++ b/docs/es-es/cli/6-mcp-playwright.md
@@ -0,0 +1,83 @@
+---
+title: "Ejercicio 6 - Validar la funcionalidad con MCP de Playwright"
+description: "Conecta un navegador mediante MCP y compara el comportamiento de filtrado observado con la incidencia y el plan aprobado."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+La implementación de filtrado y la habilidad quality-checks ya tienen verificación automatizada. Ahora proporciona a Copilot un navegador y pídele que observe directamente la funcionalidad. Este ejercicio demuestra la interacción mediante **Model Context Protocol (MCP)**, no otra ejecución completa de la batería de pruebas.
+
+Mantén el modo **Interactive** en la misma copia de trabajo y rama de filtrado. Configurar MCP no inicia un nuevo hito de funcionalidad.
+
+## Qué aporta MCP
+
+[MCP][mcp-overview] conecta un agente con herramientas y contexto externos mediante servidores. El servidor MCP de GitHub integrado permite a Copilot trabajar con incidencias y PR. El [servidor MCP de Playwright][playwright-mcp] proporciona herramientas de navegador para abrir páginas, examinar elementos accesibles, navegar e interactuar con controles.
+
+La instantánea de accesibilidad del navegador ayuda al agente a identificar controles, pero no demuestra un cumplimiento completo de accesibilidad. Compara las acciones y observaciones reales con los requisitos de la incidencia en lugar de aceptar un «parece correcto» genérico.
+
+> [!CAUTION]
+> Trata un servidor MCP como una dependencia del proyecto: revisa quién lo publica, el código fuente, los permisos y cualquier descarga de paquetes antes de activarlo. Las directivas de la organización pueden restringir los servidores que pueden ejecutarse. No incluyas credenciales en configuración versionada ni apruebes herramientas desconocidas solo para terminar el ejercicio.
+
+## Configurar MCP de Playwright
+
+1. En la sesión de CLI existente, introduce `/mcp` para examinar los servidores configurados. Reutiliza una configuración de Playwright que funcione en lugar de añadir una duplicada.
+2. Si hace falta, introduce `/mcp add` y utiliza Tab para desplazarte por el formulario.
+3. Establece **Server Name** en `playwright`, **Server Type** en **STDIO** (o **Local**) y **Command** en `npx @playwright/mcp@latest --headless`.
+4. Establece **Tools** en `*` para este servidor de navegador revisado. Esto hace disponibles sus herramientas; no sustituye los controles de permisos de CLI.
+5. Tras revisar el paquete y su comando de inicio, pulsa Ctrl+S para guardar. El registro inicia el servidor y puede descargar el paquete; aprueba esta configuración de forma deliberada y responde a las solicitudes del paquete.
+6. Introduce `/mcp show playwright` y confirma que el servidor está conectado y sus herramientas de navegador están disponibles.
+
+El navegador sin interfaz gráfica no necesita una ventana de escritorio, lo que resulta adecuado para Codespaces. El flujo interactivo de adición guarda la configuración en `~/.copilot/mcp-config.json` y hace disponible el servidor sin reiniciar CLI. Es configuración del usuario, no un archivo que incluir en la PR de la funcionalidad. La [guía de configuración de MCP][mcp-setup] documenta los campos y las fuentes de configuración.
+
+> [!NOTE]
+> Las dependencias E2E del proyecto y el navegador de MCP están relacionados, pero pueden requerir configuraciones distintas. Si falta un navegador o una dependencia del sistema, examina el error real y resuelve ese requisito previo específico con aprobación. No instales navegadores automáticamente ni supongas que un servidor conectado demuestra que puede iniciar uno.
+
+## Iniciar la aplicación correcta
+
+Abre otra terminal en esta misma copia de trabajo de filtrado. Confirma el directorio y la rama y después inicia la aplicación:
+
+```bash
+pwd
+git branch --show-current
+npm run dev
+```
+
+Lee la URL local real en la salida del servidor. En el codespace, el servidor MCP y la aplicación se ejecutan en el mismo entorno, así que utiliza esa URL local, normalmente `http://localhost:4321`, en lugar de suponer que hace falta una URL de navegador reenviada.
+
+Si el puerto está ocupado o Astro elige otro puerto, identifica a quién pertenece el servidor antes de continuar. No reutilices un servidor desconocido ni lo termines. Utiliza la URL del proceso que acabas de iniciar y mantén esa terminal abierta durante las pruebas.
+
+## Observar el comportamiento de filtrado
+
+Sustituye los marcadores por la URL real de la incidencia, las aclaraciones aprobadas en el Ejercicio 4 y la URL de la aplicación:
+
+```plaintext
+Utiliza el servidor MCP de Playwright configurado para validar la funcionalidad de filtrado frente a esta incidencia: . Estas son las aclaraciones aprobadas durante la planificación: . La aplicación de esta copia de trabajo se está ejecutando en . Confirma la copia de trabajo, la rama y el servidor que se prueban antes de confiar en los resultados.
+
+Abre la página de juegos, observa el estado sin filtros, selecciona una y después varias categorías, aplica un filtro de editor y combina las selecciones de categoría y editor. Prueba la limpieza de filtros y los resultados vacíos según los criterios aprobados. Comprueba las etiquetas de los controles, el funcionamiento con teclado y el foco visible. Compara los resultados mostrados con los filtros seleccionados y los datos de origen; no deduzcas que todo funciona solo porque haya cambiado un control.
+
+Utiliza acciones reales de las herramientas del navegador e informa de lo observado para cada criterio, marcando claramente los fallos o las pruebas de verificación ausentes. No ejecutes otra batería completa de pruebas solo por este ejercicio de navegador, no cambies código de la aplicación, no crees pruebas o personalizaciones, no cambies de rama, no crees commits, no envíes cambios ni abras una PR. Pregunta antes de instalar algo o detener otro proceso.
+```
+
+Examina las llamadas a las herramientas del navegador y el informe. ¿Copilot realmente seleccionó varias categorías y las combinó con un editor? ¿Los juegos devueltos coinciden con el comportamiento acordado? ¿El informe distingue el comportamiento observable del navegador de la cobertura de la capa de datos y las pruebas automatizadas?
+
+Si algo falla, registra el comportamiento observado. Autoriza por separado cualquier corrección específica de la aplicación y repite las comprobaciones de navegador y automatizadas afectadas. No cambies los criterios de aceptación para que coincidan con la implementación ni cuentes pruebas de ejecución antiguas como verificación del código modificado.
+
+## Detener el servidor propio y continuar
+
+Detén el servidor de desarrollo con Ctrl+C en la terminal donde lo iniciaste. Mantén disponible la configuración de MCP de Playwright. El Ejercicio 7 coordinará observaciones nuevas en el navegador y comprobaciones E2E automatizadas, que no deben reutilizar un servidor de desarrollo obsoleto ni la aplicación de otra copia de trabajo.
+
+Mantén **Interactive** antes de crear el perfil de QA. Has observado el comportamiento del navegador sin crear otra PR o rama; a continuación, [crea y utiliza un agente de QA][next-lesson] para combinar requisitos, cobertura, la habilidad y las pruebas de verificación finales.
+
+## Recursos
+
+- [Añadir servidores MCP a Copilot CLI][mcp-setup] documenta la configuración y administración.
+- [Microsoft Playwright MCP][playwright-mcp] documenta la configuración y las herramientas del navegador.
+- [Registro MCP de GitHub][mcp-registry] enumera otros servidores que evaluar.
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-overview]: https://docs.github.com/copilot/concepts/context/mcp
+[mcp-setup]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
+[playwright-mcp]: https://github.com/microsoft/playwright-mcp
+[mcp-registry]: https://github.com/mcp
diff --git a/docs/es-es/cli/7-qa-agent.md b/docs/es-es/cli/7-qa-agent.md
new file mode 100644
index 00000000..680b8169
--- /dev/null
+++ b/docs/es-es/cli/7-qa-agent.md
@@ -0,0 +1,77 @@
+---
+title: "Ejercicio 7 - Crear y utilizar un agente de QA"
+description: "Crea un perfil de QA que parta de los requisitos y combine cobertura de pruebas, la habilidad quality-checks y observaciones directas del navegador."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Has ejecutado comprobaciones repetibles y explorado el filtrado mediante MCP de Playwright. Ahora crea un **agente personalizado de QA** para reunir los requisitos, la cobertura y las observaciones del navegador. Mantén la sesión, la copia de trabajo y la rama de filtrado; la PR de funcionalidad llegará en el Ejercicio 8.
+
+## Crear el perfil de QA
+
+Mantén el modo **Interactive**. Un perfil define el rol y las instrucciones de un especialista; una habilidad reúne instrucciones de tareas reutilizables, scripts y recursos. El agente de QA utilizará tu habilidad y las herramientas MCP configuradas en lugar de sustituirlas.
+
+Envía esta indicación y después examina la definición antes de ejecutarla:
+
+```plaintext
+Crea un agente personalizado de QA reutilizable en .github/agents/qa.agent.md. Primero examina las instrucciones del repositorio, package.json, la configuración de pruebas y .github/skills/quality-checks/SKILL.md. Proporciona al perfil un frontmatter YAML válido con name establecido en QA y una description que explique cuándo utilizarlo. No fijes un modelo ni añadas una lista tools; hereda las herramientas y los permisos disponibles del entorno. Crea solo la definición del agente y después detente para que pueda examinarla antes de ejecutarlo.
+
+En las instrucciones del agente, exige que toda tarea de QA parta de la incidencia y de los criterios de aceptación aprobados que proporcione el usuario. Trata estos requisitos como fuente de verdad, no la implementación. Pregunta cuando falten requisitos o sean ambiguos. Examina la funcionalidad y las pruebas existentes y relaciona cada criterio con la cobertura automatizada adecuada y el comportamiento observable.
+
+Exige validación directa en el navegador mediante el servidor MCP de Playwright configurado y la ejecución de lint, pruebas unitarias, pruebas de un extremo a otro y comprobaciones de tipos mediante la habilidad quality-checks existente y sus scripts incluidos. Lee la habilidad explícitamente si no se ha descubierto automáticamente. Informa de la ausencia de habilidades, herramientas MCP, requisitos previos o acceso como bloqueos; no sustituyas silenciosamente el flujo por otro ni etiquetes comprobaciones omitidas como superadas. Identifica la copia de trabajo y el servidor que se prueban, evita reutilizar el servidor de otro worktree, detén solo los servidores que haya iniciado el agente y pregunta antes de cualquier instalación o de detener otro proceso.
+
+Permite que el agente de QA añada las pruebas mínimas necesarias para carencias reales de cobertura, siguiendo las instrucciones del repositorio; no añadir pruebas es válido cuando la cobertura ya es adecuada. No debilites aserciones, no desactives pruebas fallidas, no cambies los criterios de aceptación para ajustarlos al código ni modifiques código de la aplicación sin mi aprobación. Tras los cambios, repite las comprobaciones afectadas y completa la verificación final de la revisión resultante. Exige un informe conciso que relacione los criterios con las pruebas de verificación y el estado superado/fallido/bloqueado, enumere las pruebas añadidas o explique por qué no hicieron falta, comunique los resultados de las cuatro comprobaciones e identifique los defectos sin resolver. GO exige todas las comprobaciones y pruebas de verificación obligatorias; de lo contrario, informa de NO-GO y su motivo. No cambies de rama, no crees commits, no envíes cambios, no abras ni combines PR y no crees agentes o habilidades adicionales durante QA.
+```
+
+## Examinar el perfil
+
+Abre `.github/agents/qa.agent.md` en el editor y examina las diferencias. `description` es obligatorio; este ejercicio también proporciona `QA` como `name` legible. Confirma que no se ha fijado un `model` ni inventado una lista de herramientas. Omitir `tools` hereda las herramientas disponibles; no elude los permisos del entorno. Los perfiles de producción pueden restringir las herramientas deliberadamente.
+
+Confirma que las instrucciones parten de los requisitos, exigen actividad real del navegador mediante MCP y scripts de la habilidad, permiten solo adiciones de pruebas justificadas e informan de los bloqueos con veracidad. Ni un perfil especializado ni una habilidad requieren una ventana de contexto independiente o la orquestación de otros agentes.
+
+## Ejecutar QA frente a la incidencia
+
+La indicación de ejecución es para el agente personalizado **QA** seleccionado, no para el agente predeterminado que lee un perfil. Inicia una conversación nueva de CLI en la misma copia de trabajo para cargar el perfil nuevo sin crear otra rama de funcionalidad.
+
+1. Conserva la URL de la incidencia de filtrado y las aclaraciones aprobadas. Espera a que termine el agente actual y después introduce `/exit` para volver a la terminal.
+2. Confirma que sigues en el directorio del repositorio de filtrado y en la misma rama con `git branch --show-current` y `git status --short`. No cambies de rama ni crees un worktree.
+3. Inicia CLI con el perfil del repositorio:
+
+ ```shell
+ copilot --agent qa
+ ```
+
+4. Verifica que CLI identifica a **QA** como agente seleccionado antes de ejecutarlo. La [referencia de comandos de CLI][cli-reference] documenta `--agent`; escribir o leer el perfil no constituye por sí solo su activación. Si la selección falla o el agente no puede acceder a las herramientas MCP de Playwright configuradas y a la habilidad, detente y resuelve ese bloqueo con la persona que dirige el taller.
+
+Sustituye ambos marcadores por la URL real de la incidencia de filtrado y las aclaraciones aprobadas en el Ejercicio 4, o por `none` si la incidencia está completa. No dependas de la memoria del agente anterior.
+
+```plaintext
+Verifica la funcionalidad de filtrado frente a esta incidencia: . Estos son los criterios de aceptación adicionales que aprobé durante la planificación: .
+
+Valida el comportamiento con el servidor MCP de Playwright, examina la cobertura de pruebas, añade pruebas solo para carencias de cobertura y ejecuta la validación mediante la habilidad quality-checks. Informa de las pruebas de verificación, los resultados de las comprobaciones y los bloqueos. No cambies código de la aplicación sin mi aprobación, no crees un commit ni abras una solicitud de incorporación de cambios.
+```
+
+## Revisar las pruebas de verificación
+
+Contrasta el informe con la incidencia: cada criterio necesita cobertura automatizada adecuada y comportamiento observable. Examina la actividad real de las herramientas MCP de Playwright, la identidad de la copia de trabajo y del servidor y los resultados de los cuatro scripts de la habilidad. Las comprobaciones de navegador y E2E automatizadas no deben reutilizar un servidor obsoleto ni otra copia de trabajo.
+
+Revisa las pruebas añadidas: deben cubrir carencias reales sin debilitar las aserciones. No añadir pruebas es correcto cuando la cobertura es adecuada. Un dictamen **NO-GO** por bloqueo o fallo es un resultado válido, no permiso para omitir pruebas de verificación.
+
+Si QA identifica un defecto de la aplicación, aprueba por separado una corrección específica y repite las comprobaciones y observaciones de navegador afectadas en la revisión resultante. La ausencia de requisitos previos o herramientas necesita una resolución explícita. No trates las pruebas de verificación anteriores como demostración del código modificado.
+
+## Guardar un punto de control
+
+Cuando QA haya terminado, conserva su informe con la URL de la incidencia, las aclaraciones aprobadas, la revisión probada, las observaciones de navegador y los resultados de las comprobaciones. Introduce `/exit` y después inicia `copilot` sin `--agent` desde el mismo directorio y rama para volver a una conversación normal. Proporciona ese contexto de nuevo; la conversación nueva no hereda las pruebas de verificación de la conversación de QA.
+
+Cuando hayas revisado el perfil, los cambios de pruebas y las pruebas de verificación resultantes, envía la solicitud siguiente al agente normal:
+
+```plaintext
+Revisa las diferencias actuales y crea un commit de punto de control para la definición del agente de QA y los cambios de pruebas aprobados. Mantén la rama de filtrado existente. No envíes cambios ni abras una solicitud de incorporación de cambios.
+```
+
+Continúa con el [Ejercicio 8 - Crear y combinar la PR de la funcionalidad][next-lesson] con la funcionalidad de filtrado, la habilidad, el perfil de QA, las pruebas y las pruebas de verificación actuales.
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/es-es/cli/7-slash-commands.md b/docs/es-es/cli/7-slash-commands.md
deleted file mode 100644
index b3e1bbe9..00000000
--- a/docs/es-es/cli/7-slash-commands.md
+++ /dev/null
@@ -1,177 +0,0 @@
----
-title: "Ejercicio 7 - Comandos de barra en GitHub Copilot CLI"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-Como cualquier buena herramienta de CLI, GitHub Copilot CLI incluye muchos comandos de barra para interactuar con ella. Estos comandos exponen funcionalidad avanzada, información "entre bastidores" u opciones de configuración adicionales. Ya has explorado un par de ellos con `/clear` para borrar el contexto y `/mcp` para inspeccionar los servidores MCP. Vamos a explorar otros muy potentes, entre ellos `/context`, `/model`, `/share` y `/delegate`.
-
-## Escenario
-
-Ya has completado los flujos principales de CLI. Ahora vamos a ver algunas capacidades adicionales: compartir sesiones, cambiar de modelo y delegar tareas en [Copilot cloud agent][about-cloud-agent].
-
-En este ejercicio usarás:
-
-- `/share` para crear un GitHub gist y compartir tu sesión con el equipo.
-- `/context` para ver el contexto que está usando actualmente Copilot CLI.
-- `/model` para explorar la lista de modelos disponibles y seleccionar uno nuevo si así lo deseas.
-- `/delegate` para delegar opcionalmente una tarea al agente en la nube. Esto requiere cloud agent, disponible en Copilot Student, Pro, Pro+, Business o Enterprise, es decir, en todos los planes excepto Copilot Free.
-
-## Compartir una sesión
-
-Usar cualquier herramienta, incluida una herramienta de IA, es una habilidad. Trabajar en equipo y compartir lo aprendido es la mejor forma de mejorar la experiencia de todos y generar código de mayor calidad. Para ello, Copilot CLI proporciona el comando `/share`. El comando `/share` puede generar un archivo Markdown o un GitHub gist con los detalles de la sesión, incluidos los prompts utilizados y la lógica que siguió Copilot.
-
-Vamos a crear un GitHub gist que podríamos compartir con nuestro equipo.
-
-> [!TIP]
-> **Inicia una sesión de Copilot CLI**
->
-> Antes de empezar los ejercicios siguientes, vuelve a tu codespace y abre un terminal (Ctrl+\` si no hay ninguno abierto). Después, inicia Copilot CLI con `--yolo` y `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar la sesión más reciente de este proyecto en lugar de empezar desde cero, ejecuta `copilot --yolo --enable-all-github-mcp-tools --continue`. Si Copilot CLI ya se está ejecutando desde un ejercicio anterior, envía `/clear` para empezar una conversación limpia.
->
-> `--enable-all-github-mcp-tools` habilita las herramientas GitHub MCP de lectura y escritura para la sesión actual, de modo que Copilot pueda leer tu backlog y abrir pull requests durante el flujo del taller.
-
-> [!CAUTION]
-> `--yolo` habilita permisos automáticos completos (`--allow-all-tools`, `--allow-all-paths` y `--allow-all-urls`). Úsalo solo en un entorno aislado, como un Codespace o una máquina virtual, y no lo configures nunca como alias predeterminado para el desarrollo diario. Consulta [Allowing and denying tool use][allow-all-warning] para más información.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. En la ventana de prompt de Copilot CLI, envía el siguiente comando:
-
- ```
- /share gist
- ```
-
-2. En apenas unos instantes, Copilot creará un gist y mostrará el enlace.
-3. Copia el texto del enlace.
-4. En una pestaña nueva del navegador, pega el enlace para explorar el gist. Observa cómo el gist destaca los prompts enviados, las habilidades y los agentes utilizados, el proceso de razonamiento de Copilot e incluso el código y los resultados de los comandos ejecutados localmente.
-
-Los gists y archivos Markdown generados por `/share` pueden usarse para documentar cómo se generó el código o para compartir con el equipo cómo se llevaron a cabo determinadas acciones que produjeron los resultados deseados con Copilot.
-
-## Explorar el contexto de Copilot CLI
-
-Cuando trabajas en tareas grandes o complejas, puedes llegar al límite máximo de la ventana de contexto del modelo. El tamaño exacto de la ventana variará según el modelo que se esté usando y la versión de Copilot CLI. Cuando la ventana de contexto se llena, Copilot CLI la compacta automáticamente, resumiendo la información y eliminando lo que considera irrelevante para la tarea actual. Puedes tanto ver el estado actual del contexto como compactarlo manualmente usando comandos de barra. Vamos a explorar la ventana de contexto.
-
-1. En la ventana de prompt de Copilot CLI, envía el siguiente comando:
-
- ```
- /context
- ```
-
-2. En apenas unos instantes, Copilot CLI generará una representación visual de su contexto actual:
-
- 
-
-3. Fíjate en el modelo mostrado (que puede ser distinto del de la imagen) y en el porcentaje actual de tokens usados. El resto de la información destaca lo siguiente:
-
- | Título | Descripción |
- | ------------ | ------------------------------------------------------ |
- | Sistema/Herramientas | Archivos de instrucciones, contenido de archivos y definiciones de herramientas |
- | Mensajes | Historial de la conversación entre tú y Copilot |
- | Búfer | Espacio reservado por Copilot CLI para generar respuestas |
- | Espacio libre | Espacio libre restante |
-
-4. Compacta el historial de la conversación enviando el siguiente comando de barra a Copilot CLI:
-
- ```
- /compact
- ```
-
-5. Cuando termine, envía de nuevo el siguiente comando para mostrar las estadísticas actuales del contexto:
-
- ```
- /context
- ```
-
-6. Observa el cambio en el contexto. Puede que no sea drástico, ya que es probable que la ventana de contexto sea relativamente pequeña en este momento.
-
-> [!NOTE]
-> Copilot CLI compactará automáticamente el contexto cuando se llene. Cuando se acerque al 100 % de capacidad, mostrará el porcentaje justo encima de la ventana de prompt. Normalmente lo compactará de forma asíncrona, lo que te permitirá seguir interactuando con Copilot mientras realiza ese trabajo. Aun así, puede bloquear una operación en curso durante varios segundos mientras lo hace.
-
-### Buenas prácticas con el contexto
-
-En la mayoría de las sesiones, Copilot gestionará el contexto de forma eficiente sin que tengas que darle instrucciones específicas. Sin embargo, puede haber ocasiones en las que decidas indicarle manualmente que borre o compacte el historial:
-
-- Si vas a pasar a otra parte de la aplicación o a una tarea no relacionada, puedes usar `/clear` para empezar de nuevo y evitar confundir a Copilot con contexto antiguo que no tiene relación.
-- Si te estás acercando al límite máximo de la ventana de contexto, puedes usar manualmente `/compact` para controlar cuándo ocurre.
-
-> [!CAUTION]
-> De nuevo, la mayor parte del tiempo Copilot gestionará su contexto sin interacción directa por tu parte. Si observas que Copilot está algo confundido por información antigua, o estás a punto de cambiar a una tarea no relacionada, entonces quizá te convenga usar los comandos manuales.
-
-## Elegir tu modelo
-
-Los distintos modelos tienen puntos fuertes diferentes y cada desarrollador tiene sus propias preferencias. Copilot CLI te permite listar y seleccionar el modelo que quieras usar.
-
-1. Muestra la lista de modelos enviando el siguiente comando de barra a Copilot CLI:
-
- ```
- /model
- ```
-
-2. Observa la lista de modelos. Junto a cada modelo aparecerán tanto su nombre como el modificador de coste por solicitud.
-3. Si quieres, selecciona un modelo nuevo. O bien selecciona Esc para salir de la lista de modelos.
-
-> [!CAUTION]
-> La selección de modelo persiste en Copilot CLI.
-
-## Delegar en cloud agent (opcional)
-
-Hay ocasiones en las que quieres seguir trabajando en tu terminal, pero delegar una tarea de mayor duración en Copilot cloud agent. El comando `/delegate` envía la sesión actual de Copilot CLI a GitHub.com, donde cloud agent la retoma, trabaja de forma asíncrona y abre una pull request cuando termina.
-
-> [!NOTE]
-> `/delegate` requiere cloud agent, disponible en Copilot Student, Pro, Pro+, Business o Enterprise, es decir, en todos los planes excepto Copilot Free. Si no tienes acceso, lee esta sección y omite los pasos prácticos.
-
-1. Borra primero la sesión actual para no delegar el contexto acumulado del taller:
-
- ```
- /clear
- ```
-
-2. Envía un prompt pequeño y bien delimitado. Por ejemplo, podrías delegar la paginación de objetivo ampliado de tu backlog:
-
- ```
- Implement pagination on the game list page so it shows a fixed number of games per page with Previous and Next controls, and add tests.
- ```
-
-3. Envía el siguiente comando de barra para delegar la sesión al agente en la nube y confirma el prompt que quieres delegar:
-
- ```
- /delegate
- ```
-
-4. Abre [Copilot agents](https://github.com/copilot/agents) en un navegador para supervisar el progreso.
-5. No necesitas esperar a que la pull request termine en este recorrido; puedes volver más tarde. Si quieres profundizar en la gestión del trabajo asíncrono con agentes, continúa con el [recorrido de Cloud agent](../../cloud/).
-
-## Resumen y siguientes pasos
-
-Usar comandos de barra en Copilot CLI te permite configurarlo, compartir sesiones y obtener información interna sobre cómo está trabajando Copilot. En esta lección has usado o explorado:
-
-- `/share` para crear un GitHub gist y compartir tu sesión con el equipo.
-- `/context` para ver el contexto que está usando actualmente Copilot CLI.
-- `/model` para explorar la lista de modelos disponibles y seleccionar uno nuevo si así lo deseas.
-- `/delegate` como puente opcional hacia cloud agent.
-
-Por supuesto, hay más comandos de barra disponibles y mucho más por explorar con Copilot CLI. Vamos a cerrar este recorrido [repasando lo que hemos aprendido][next-lesson] y viendo algunos próximos pasos para seguir aprendiendo.
-
-## Recursos
-
-- [Usar Copilot CLI][using-copilot-cli]
-- [Acerca de Copilot CLI][about-copilot-cli]
-- [Gestión del contexto en Copilot CLI][context-management]
-- [Compartir sesiones con Copilot CLI][share-sessions]
-- [Seleccionar modelos en Copilot CLI][selecting-models]
-
-[previous-lesson]: ../6-custom-agents/
-[next-lesson]: ../8-review/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[about-cloud-agent]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
-[share-sessions]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#share-sessions
-[selecting-models]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#select-an-llm
diff --git a/docs/es-es/cli/8-create-pull-request.md b/docs/es-es/cli/8-create-pull-request.md
new file mode 100644
index 00000000..8824b999
--- /dev/null
+++ b/docs/es-es/cli/8-create-pull-request.md
@@ -0,0 +1,99 @@
+---
+title: "Ejercicio 8 - Crear y combinar la PR de la funcionalidad"
+description: "Revisa todo el hito de filtrado, reutiliza las pruebas de verificación actuales de QA y combina la tercera solicitud de incorporación de cambios tras CI y la revisión."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Ahora reúne el hito de filtrado en la PR 3. Mantén la rama y la copia de trabajo utilizadas en los Ejercicios 4–7. Contienen la implementación de filtrado, la habilidad quality-checks y sus scripts, el perfil de QA y las pruebas asociadas.
+
+Esta es una petición normal de PR con alcance limitado que utiliza las convenciones del repositorio. No requiere una habilidad de contribución.
+
+> [!NOTE]
+> Un equipo de producción podría separar una funcionalidad de la infraestructura de calidad reutilizable. Este taller las combina deliberadamente para mostrar el flujo completo en una PR de funcionalidad. Las PR anteriores de valoraciones por estrellas e instrucciones ya deberían estar combinadas en `main`, no aparecer otra vez como trabajo ajeno.
+
+## Comprobar la preparación y las pruebas de verificación
+
+1. Revisa el dictamen de QA y la correspondencia entre requisitos y pruebas de verificación. Un **NO-GO**, la ausencia de observaciones de navegador o una comprobación obligatoria omitida es un bloqueo que resolver antes de combinar.
+2. Confirma que las cuatro comprobaciones se ejecutaron realmente mediante la habilidad quality-checks: lint, pruebas unitarias, E2E y comprobación de tipos.
+3. Revisa la revisión probada y los cambios posteriores a esas comprobaciones. Reutiliza las pruebas de verificación actuales de QA solo mientras el código probado, las pruebas y los scripts de verificación no hayan cambiado. Un commit de punto de control por sí solo no invalida contenidos de archivo idénticos, pero los cambios de código sí.
+4. Si cambió la implementación o alguna entrada probada, ejecuta de nuevo las comprobaciones pertinentes de la habilidad y las observaciones de navegador y actualiza las pruebas de verificación. No repitas toda la batería solo por abrir una PR cuando los resultados actuales de QA siguen siendo aplicables.
+5. Examina las diferencias de toda la rama, no solo el último punto de control o los cambios sin commit.
+
+Desde otra terminal en la misma copia de trabajo:
+
+```bash
+git status
+git fetch origin
+git log --oneline origin/main..HEAD
+git diff --stat origin/main...HEAD
+git --no-pager diff origin/main...HEAD
+```
+
+La comparación de tres puntos muestra los cambios de esta rama desde su antecesor común con `origin/main`, incluidos los puntos de control anteriores. Verifica que incluye solo el hito de filtrado previsto. Examina también los archivos nuevos; los archivos inesperados sin seguimiento o sin commit deben revisarse antes de prepararlos.
+
+## Solicitar la PR 3
+
+El Ejercicio 7 te devolvió a una sesión **Interactive** normal antes del punto de control. Continúa en esa sesión establecida si el perfil de QA ya no está activo y la copia de trabajo y la rama de filtrado no han cambiado. Mantén disponibles la URL de la incidencia, las aclaraciones aprobadas de planificación y el informe actual de QA, incluida la revisión probada y los resultados de las comprobaciones.
+
+El perfil de QA prohíbe las acciones de commit y PR durante QA. Si sigue activo, vuelve a una sesión normal antes de solicitar la PR:
+
+1. Espera a que QA esté inactivo y después introduce `/exit` en su prompt de CLI. Si CLI permanece abierto porque hay otra sesión activa, termina o conserva ese trabajo antes de volver al prompt normal y pulsar Ctrl+D para cerrar esta instancia de CLI.
+2. En el prompt del shell, permanece en la misma copia de trabajo y rama de filtrado. Confirma su identidad e inicia una sesión normal nueva sin `--agent qa` ni una opción de reanudación:
+
+ ```bash
+ pwd
+ git branch --show-current
+ git status
+ copilot
+ ```
+
+3. Confirma que estás en modo **Interactive** y el perfil de QA ya no está activo. No crees otro worktree, no cambies de rama ni reanudes la sesión de QA.
+
+Sustituye todos los marcadores siguientes por la URL real de la incidencia, las aclaraciones aprobadas y las pruebas de verificación actuales de QA. Proporciónalos explícitamente aunque hayas permanecido en la sesión normal del Ejercicio 7; una conversación nueva no debe depender de la memoria de la sesión de QA.
+
+```plaintext
+Prepara la PR de la funcionalidad de filtrado para esta incidencia: . Estos son los criterios de aceptación adicionales que aprobé durante la planificación: . Estas son las pruebas de verificación actuales de QA: .
+
+Confirma la copia de trabajo y la rama de filtrado actual. Examina todas las diferencias frente a main, todos los commits de puntos de control del hito, git status, la plantilla de PR del repositorio y las pruebas de verificación de QA proporcionadas. Incluye solo la implementación de filtrado revisada, la habilidad quality-checks y los scripts incluidos, la definición del agente de QA y las pruebas asociadas.
+
+Reutiliza los resultados de QA mientras sigan describiendo el contenido final de los archivos. Si el código, las pruebas o los scripts de verificación cambiaron después, indícalo y ejecuta las comprobaciones pertinentes mediante la habilidad y la validación de navegador afectada antes de presentarlos como actuales. No etiquetes comprobaciones fallidas, bloqueadas u omitidas como superadas.
+
+Si hace falta, crea un commit con los cambios revisados restantes del hito, envía esta rama actual y crea una sola PR a main siguiendo las convenciones del repositorio. Incluye la incidencia y los criterios aprobados, un resumen de implementación, las pruebas añadidas o por qué no hicieron falta, las observaciones de navegador, los resultados de las cuatro comprobaciones y las limitaciones restantes. No combines, no crees otra rama, no invoques una habilidad de contribución ni empieces otra funcionalidad.
+```
+
+## Revisar la PR y CI
+
+Abre la URL devuelta y examina **Files changed** en toda la PR. Comprueba que los scripts de la habilidad y el perfil de QA están incluidos y que no se han colado credenciales, configuración local de MCP, archivos ajenos, informes generados o instalaciones de dependencias.
+
+Utiliza la pestaña **Checks** de la PR o ejecuta estos comandos en la terminal de la rama de funcionalidad:
+
+```bash
+gh pr view
+gh pr diff
+gh pr checks --watch
+```
+
+Examina `.github/workflows/` de tu repositorio en lugar de suponer que una insignia verde cubre todos los tipos de verificación. El flujo actual **Run tests** de Tailspin ejecuta lint, comprobaciones de tipos, pruebas unitarias de Vitest y pruebas E2E de Playwright contra el sitio estático compilado. No sustituye las observaciones directas del navegador mediante MCP del informe de QA. La compilación Astro y las comprobaciones de enlaces del sitio del taller validan otro repositorio.
+
+Si una comprobación falla, examina sus registros y resuelve la causa. Una corrección específica debe revisarse y verificarse de nuevo en la revisión actualizada antes de enviar cambios. Si `main` cambia y la resolución de un conflicto modifica la funcionalidad, actualiza también las pruebas de verificación afectadas. Espera cualquier revisión humana obligatoria; la aprobación del propio agente no anula la protección de ramas.
+
+## Combinar y actualizar el main local
+
+Cuando la PR cumpla todos los requisitos de revisión y comprobación, elige explícitamente **Merge pull request** en GitHub y confirma la combinación. Verifica que la PR 3 está **Merged**.
+
+Sal de la sesión de CLI con `/exit`. Con el árbol de trabajo limpio, actualiza la copia local:
+
+```bash
+git status
+git switch main
+git pull --ff-only
+```
+
+No hace falta una rama nueva para el siguiente ejercicio. Has combinado exactamente tres PR del taller: valoraciones por estrellas; instrucciones y una demostración; y filtrado con la habilidad de calidad, el perfil de QA y las pruebas.
+
+Continúa con el [Ejercicio 9 - Explorar comandos de barra y opciones de CLI][next-lesson] para recorrer de forma acotada los controles de CLI, no para realizar otra tarea de implementación.
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-slash-commands/
diff --git a/docs/es-es/cli/8-review.md b/docs/es-es/cli/8-review.md
deleted file mode 100644
index 48534f24..00000000
--- a/docs/es-es/cli/8-review.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: "Ejercicio 8 - Repaso y próximos pasos"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-En los últimos ejercicios, has explorado algunos de los casos de uso más habituales de GitHub Copilot CLI, entre ellos:
-
-- interactuar con GitHub y otros servidores MCP.
-- usar archivos de instrucciones para orientar la generación de código.
-- implementar habilidades para añadir herramientas al conjunto de herramientas de Copilot CLI.
-- invocar agentes personalizados para tareas avanzadas y más complejas.
-- usar comandos de barra para gestionar tu sesión y, opcionalmente, volver a conectar con cloud agent mediante `/delegate`.
-
-Vamos a hablar de algunos comandos de barra, buenas prácticas y próximos pasos.
-
-## Comandos de barra
-
-Copilot CLI tiene una serie de comandos de barra disponibles para interactuar con él, incluidos algunos que te permiten configurarlo o ver qué está ocurriendo entre bastidores. Ya has usado `/clear` para iniciar un chat nuevo que borra el contexto actual, y `/mcp` para inspeccionar y gestionar servidores MCP. Algunos adicionales que pueden resultarte útiles son:
-
-| Comando | Descripción |
-| ------------------ | ------------------------------------------------------------- |
-| `/add-dir` | Añadir un directorio a la lista de confianza de Copilot |
-| `/clear`, `/new` | Borrar el historial de la conversación y empezar de cero |
-| `/compact` | Resumir el historial de la conversación para reducir el uso de la ventana de contexto |
-| `/context` | Mostrar el uso de tokens de la ventana de contexto y su visualización |
-| `/diff` | Revisar los cambios realizados en el directorio actual |
-| `/model` | Seleccionar el modelo de IA que se va a usar (Claude Sonnet, GPT-5, etc.) |
-| `/plan ` | Crear un plan de implementación antes de programar |
-| `/review ` | Ejecutar el agente de revisión de código para analizar los cambios |
-| `/delegate` | Delegar la tarea en Copilot cloud agent para procesamiento asíncrono |
-| `/session` | Mostrar la información de la sesión y el resumen del espacio de trabajo |
-| `/share` | Compartir la sesión en un archivo Markdown o un GitHub gist |
-| `/skills` | Gestionar habilidades para ampliar las capacidades |
-| `/usage` | Mostrar métricas y estadísticas de uso de la sesión |
-
-> [!TIP]
-> Usa `/help` para ver la lista completa de comandos disponibles y de atajos de teclado.
-
-## Buenas prácticas
-
-Cuando usas una herramienta de IA, la infraestructura subyacente determina en gran medida la calidad de lo que obtienes. Unos archivos de instrucciones sólidos, agentes personalizados y habilidades de agente robustas forman parte de ello, y en este taller has explorado cada uno de esos elementos. [awesome-copilot][awesome-copilot] es una buena fuente de plantillas, y el propio Copilot puede generarlas como punto de partida.
-
-El contexto sigue importando tanto como la infraestructura. Describir claramente *qué* quieres que se construya, *por qué* y *cómo* cambia de forma significativa el resultado. Si una información puede ayudar a Copilot, compártela.
-
-## Próximos pasos
-
-La mejor forma de mejorar tus habilidades con cualquier herramienta es seguir usándola. Úsala para código de producción, para proyectos personales, para esa pequeña aplicación en la que llevas años pensando pero que nunca llegabas a construir. Comparte lo que aprendas con tu equipo y aprende también de él. Y, como siempre, explora la documentación.
-
-Si quieres explorar más del ecosistema de GitHub Copilot, consulta el [recorrido de VS Code](../../vscode/) o el [recorrido de Cloud agent](../../cloud/).
-
-## Recursos
-
-- [Acerca de Copilot CLI][about-copilot-cli]
-- [Usar Copilot CLI][using-copilot-cli]
-- [Repositorio Awesome Copilot][awesome-copilot]
-- [Guía de instrucciones personalizadas][repo-instructions]
-- [Documentación de las habilidades de agente][agent-skills]
-- [Documentación de agentes personalizados][custom-agents]
-- [Especificación de MCP][mcp-spec]
-
-[previous-lesson]: ../7-slash-commands/
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[repo-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
-[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[mcp-spec]: https://modelcontextprotocol.io/
diff --git a/docs/es-es/cli/9-slash-commands.md b/docs/es-es/cli/9-slash-commands.md
new file mode 100644
index 00000000..89e86230
--- /dev/null
+++ b/docs/es-es/cli/9-slash-commands.md
@@ -0,0 +1,88 @@
+---
+title: "Ejercicio 9 - Explorar comandos de barra y opciones de CLI"
+description: "Examina el contexto y los controles de modelos y sesiones, revisa los destinos para compartir y explora opciones de CLI sin iniciar otra funcionalidad."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Los tres hitos de PR están completos. Ahora explora los controles de CLI que te ayudan a comprender y gestionar una sesión. Este ejercicio no implementa otra funcionalidad, no delega trabajo ni abre otra PR.
+
+Desde la copia de trabajo actualizada del participante, inicia `copilot` en modo **Interactive**. Utiliza `/help` y la [referencia de comandos][cli-reference] para confirmar los comandos que admite tu versión instalada; la documentación actual puede describir controles más recientes que tu instalación.
+
+## Examinar el contexto y la información de sesión
+
+1. Envía una solicitud acotada de solo lectura:
+
+ ```plaintext
+ Resume los archivos de instrucciones del repositorio, la habilidad quality-checks y el perfil de QA. Explica cómo ayudan a verificar el filtrado. No modifiques archivos, no ejecutes comprobaciones, no delegues trabajo, no crees commits ni abras una PR.
+ ```
+
+2. Introduce `/context` para examinar el uso de la ventana de contexto. Observa cómo los mensajes, las instrucciones y las definiciones de herramientas consumen contexto.
+3. Introduce `/compact` y después `/context` de nuevo. La compactación resume el historial para reducir su tamaño; una sesión corta puede mostrar pocos cambios.
+4. Introduce `/session` para examinar la sesión actual y `/usage` para consultar la información de uso.
+
+La compactación no sustituye la aportación de requisitos. Al cambiar de tarea o agente, proporciona explícitamente la URL de la incidencia, los criterios aprobados, la identidad de la copia de trabajo y las pruebas de verificación pertinentes.
+
+`/clear` inicia una conversación nueva; no deshace archivos ni cambia de rama de Git. `/resume` abre el selector de sesiones para volver a un trabajo anterior. Explora el selector y pulsa Esc para salir sin reanudar otra tarea. No borres la única copia de los criterios de aceptación ni supongas que reanudar una conversación significa que su verificación anterior sigue vigente.
+
+## Examinar modelos y modos
+
+Introduce `/model` para examinar los modelos disponibles para tu cuenta, incluido **Auto** donde se ofrezca. Lee los detalles de selección y la información de uso; la disponibilidad y los precios de los modelos pueden cambiar. Pulsa Esc para salir del selector sin cambiar de modelo. Si lo cambias, confirma la selección mostrada y el alcance que aplica tu versión de CLI.
+
+Utiliza Shift+Tab para examinar el indicador de modo al alternar entre **Interactive**, **Plan** y **Autopilot**, y vuelve después a **Interactive** sin enviar una indicación de implementación. Recuerda la diferencia:
+
+- Plan sirve para acordar el trabajo antes de programar.
+- Autopilot continúa una tarea aprobada y acotada.
+- Interactive proporciona puntos deliberados de revisión y decisión.
+- Los permisos controlan por separado qué acciones de herramientas están permitidas.
+
+## Examinar opciones de línea de comandos
+
+En otra terminal, ejecuta:
+
+```bash
+copilot --help
+```
+
+Compara estas opciones documentadas con la ayuda de tu versión instalada:
+
+| Opción | Finalidad |
+| --- | --- |
+| `--model MODEL` | Elegir el modelo para una invocación; confirma primero su disponibilidad |
+| `--agent AGENT` | Seleccionar un agente personalizado para una invocación |
+| `-p PROMPT` | Ejecutar una indicación de forma programática y salir cuando termine |
+| `--output-format json` | Emitir salida JSONL estructurada, un objeto JSON por línea |
+| `--resume` | Reanudar una sesión existente |
+| `--enable-all-github-mcp-tools` | Exponer el conjunto completo de herramientas MCP de GitHub integradas |
+
+Son controles que comprender, no otra tarea que iniciar. El modo programático puede ejecutar acciones reales de herramientas; un formato de salida JSON no convierte una solicitud en solo lectura. La selección del agente sigue el flujo verificado del [Ejercicio 7][qa-lesson], no es una razón para sustituir la activación del agente personalizado por una petición al agente predeterminado para que lea el perfil. Los permisos y el acceso siguen siendo necesarios.
+
+## Revisar antes de compartir
+
+`/share` puede enviar el contenido de la sesión a distintos destinos. La [referencia de comandos de CLI][cli-reference] documenta `/share file [session|research] [PATH]` para exportar Markdown y `/share gist [session|research]` para publicar un gist. Sin subcomando, el comportamiento documentado actualmente crea un enlace de GitHub para compartir cuando hay una sesión iniciada y sincronizada, y recurre a una exportación Markdown en caso contrario. No ejecutes el comando sin argumentos suponiendo que solo muestra una vista previa.
+
+Para este taller, selecciona explícitamente una exportación local de la sesión y un nombre de archivo en lugar de publicar:
+
+```text
+/share file session cli-session-review.md
+```
+
+Abre el archivo exportado en el editor y examina lo que contiene realmente. Revisa indicaciones, respuestas, salida de herramientas, rutas de archivo, datos del repositorio y cualquier credencial o información personal. No supongas que la exportación contiene todos los pasos internos ni que ha eliminado automáticamente el contenido sensible.
+
+> [!CAUTION]
+> Un gist o un enlace compartido supone divulgar información fuera del entorno. Un gist secreto no proporciona control de acceso privado: cualquiera que tenga su URL puede verlo. Confirma el destino, los destinatarios, los permisos y la directiva de tu organización antes de compartir. Si hace falta ocultar información, comparte solo el archivo revisado y depurado mediante un canal aprobado; no publiques después la sesión original.
+
+Mantén esta exportación fuera de la PR de funcionalidad y del historial del repositorio. Tras examinarla, elimina el archivo que acabas de generar o muévelo a la ubicación local de notas aprobada. No elimines archivos ajenos.
+
+La delegación en la nube puede crear trabajo remoto y una PR adicional, así que no ejecutes `/delegate` aquí. El [taller del agente en la nube][cloud-workshop] cubre ese flujo independiente.
+
+## Resumen y pasos siguientes
+
+Has examinado el contexto, el uso, los controles de modelos y modos, las opciones de línea de comandos y los destinos para compartir sin iniciar otra funcionalidad. Continúa con el [Ejercicio 10 - Repaso y próximos pasos][next-lesson] para revisar el flujo y los recursos que has creado.
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[qa-lesson]: ../7-qa-agent/
+[cloud-workshop]: ../../cloud/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/es-es/cli/README.md b/docs/es-es/cli/README.md
index aca3c5c9..88ad8e2d 100644
--- a/docs/es-es/cli/README.md
+++ b/docs/es-es/cli/README.md
@@ -3,12 +3,12 @@ slug: es-es/cli
title: "GitHub Copilot CLI"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
**[GitHub Copilot CLI](https://docs.github.com/copilot/concepts/agents/about-copilot-cli)** incorpora GitHub Copilot a tu terminal como asistente de programación con agentes. Explora bases de código, genera código, ejecuta comandos y se conecta a herramientas externas, todo desde la línea de comandos, para que puedas mantener el flujo sin cambiar a un editor gráfico.
-A lo largo de estos ejercicios instalarás y autenticarás Copilot CLI, y después le darás contexto del proyecto con instrucciones personalizadas antes de usar el modo de planificación para generar una funcionalidad de forma deliberada. Conectarás el servidor MCP de Playwright para probar esa funcionalidad en un navegador real y, a continuación, ampliarás Copilot con habilidades de agente reutilizables y agentes personalizados. Por último, explorarás los comandos de barra para gestionar el contexto, los modelos y el uso compartido, y terminarás con un repaso de lo que has creado.
+Tras la configuración de los Ejercicios 0–1, completarás nueve módulos principales en los Ejercicios 2–10. Empieza con una mejora rápida de valoraciones por estrellas, establece instrucciones de documentación y crea el filtrado con los modos **Plan** y **Autopilot**. Después crea una habilidad quality-checks reutilizable, valida el comportamiento con MCP de Playwright, crea un agente de QA y entrega la funcionalidad. Termina explorando los controles de CLI y repasando lo que has creado.
## Ejercicios
@@ -16,13 +16,21 @@ A lo largo de estos ejercicios instalarás y autenticarás Copilot CLI, y despu
|----------|-------|-------------|
| [0. Requisitos previos][ex0] | Configuración | Crea tu repositorio y tu codespace |
| [1. Instalación de Copilot CLI][ex1] | Instalación | Instala y autentica Copilot CLI |
-| [2. Instrucciones personalizadas][ex2] | Contexto | Añade una instrucción y comprueba cómo la sigue Copilot CLI |
-| [3. Generación de código][ex3] | Generación de código | Usa el modo de planificación y genera funcionalidades |
-| [4. Pruebas con Playwright MCP][ex4] | Herramientas externas | Añade el servidor MCP de Playwright y prueba tu funcionalidad en un navegador |
-| [5. Habilidades de agente][ex5] | Habilidades | Mejora Copilot con habilidades especializadas |
-| [6. Agentes personalizados][ex6] | Agentes | Revisa y usa agentes personalizados |
-| [7. Comandos de barra][ex7] | Funciones de CLI | Explora el contexto, los modelos, el uso compartido y la delegación opcional al agente en la nube |
-| [8. Repaso][ex8] | Resumen | Repasa los conceptos clave y los próximos pasos |
+| [2. Añadir valoraciones por estrellas: una mejora rápida][ex2] | Primer cambio | Muestra las valoraciones existentes, valida y combina la PR 1 |
+| [3. Guiar a Copilot con instrucciones personalizadas][ex3] | Contexto | Añade una convención de documentación, demuéstrala y combina la PR 2 |
+| [4. Crear el filtrado con Plan y Autopilot][ex4] | Implementación | Revisa un plan, aprueba Autopilot, prueba y guarda un punto de control |
+| [5. Crear y utilizar una habilidad quality-checks][ex5] | Habilidades | Genera, examina y ejecuta comprobaciones con scripts de shell incluidos |
+| [6. Validar la funcionalidad con MCP de Playwright][ex6] | Herramientas de navegador | Observa el comportamiento del filtrado en un navegador real |
+| [7. Crear y utilizar un agente de QA][ex7] | Agentes | Audita requisitos y cobertura y reúne las pruebas de verificación finales |
+| [8. Crear y combinar la PR de la funcionalidad][ex8] | Entrega | Revisa el filtrado y las personalizaciones reutilizables juntos en la PR 3 |
+| [9. Explorar comandos de barra y opciones de CLI][ex9] | Controles de CLI | Examina contexto, modelos, sesiones y destinos para compartir |
+| [10. Repaso y próximos pasos][ex10] | Resumen | Repasa los recursos comunes y los tres hitos de PR |
+
+## Ramas y solicitudes de incorporación de cambios
+
+Combinarás tres solicitudes de incorporación de cambios: valoraciones por estrellas; instrucciones y una pequeña demostración; y filtrado con la habilidad quality-checks, el perfil de QA y las pruebas asociadas. Combina cada una de las dos primeras PR antes de iniciar el siguiente hito desde `main` actualizado.
+
+Los Ejercicios 4–8 comparten una rama de funcionalidad y una copia de trabajo. Guarda commits de puntos de control durante el proceso; crear la habilidad, configurar MCP y seleccionar QA no inicia nuevas ramas de funcionalidad. El Ejercicio 9 explora los controles sin iniciar otra funcionalidad o PR.
## Requisitos previos
@@ -46,10 +54,12 @@ Antes de asistir a este taller, asegúrate de tener:
[ex0]: 0-prerequisites/
[ex1]: 1-install-copilot-cli/
-[ex2]: 2-custom-instructions/
-[ex3]: 3-generating-code/
-[ex4]: 4-mcp/
+[ex2]: 2-add-star-rating/
+[ex3]: 3-custom-instructions/
+[ex4]: 4-build-filtering/
[ex5]: 5-agent-skills/
-[ex6]: 6-custom-agents/
-[ex7]: 7-slash-commands/
-[ex8]: 8-review/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-slash-commands/
+[ex10]: 10-review/
diff --git a/docs/ja-jp/README.md b/docs/ja-jp/README.md
index 04db18c9..3524829f 100644
--- a/docs/ja-jp/README.md
+++ b/docs/ja-jp/README.md
@@ -3,7 +3,7 @@ slug: ja-jp
title: "GitHub Copilot のエージェントを実践で学ぶ"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
GitHub Copilot に最近追加された機能は、ソフトウェア開発ライフサイクル (SDLC) 全体を通して開発者を支援する強力なツールです。GitHub の Issue や pull request を使った作業、外部サービスとの連携、そしてもちろんコードの作成も含まれます。このラボでは、実際のユースケースを通して機能を試し、ツールを最大限に活用するためのヒントを紹介します。
@@ -23,11 +23,11 @@ GitHub Copilot は、どの環境で作業していても利用できます。
### 💻 [Copilot CLI](cli/)
-**GitHub Copilot CLI** は、ターミナルで動作するエージェント型アシスタントです。インストールして MCP サーバーに接続し、プラン モードでコードを生成できます。さらに、独自のスキル、カスタム エージェント、スラッシュ コマンドをすべてコマンド ラインから構築できます。
+**GitHub Copilot CLI** は、ターミナルで動作するエージェント型アシスタントです。セットアップ後は9つのコアモジュールに取り組みます。まず星評価を追加する小さな変更をリリースし、指示を整備して、フィルター機能を計画・構築します。続いて quality-checks スキルの作成、Playwright MCP による検証、QA エージェントの作成を行い、機能をマージします。最後に CLI の操作方法と振り返りを扱います。この流れには3つの pull request のマイルストーンがあります。
### 🤖 [Copilot App](app/)
-**GitHub Copilot app** は、Copilot CLI を基盤とするデスクトップ アプリケーションです。複数のエージェント セッションを並行して実行し、セッション モードの切り替え、キャンバスでの共同作業、GitHub Issue と pull request の管理をアプリ内で行えます。さらに **Agent Merge** を使用すると、リベース、レビュー フィードバックへの対応、CI の修正、マージまで、pull request の一連の作業を進められます。
+**GitHub Copilot app** は、Copilot CLI を基盤とするデスクトップ アプリケーションです。同じセットアップと9つのコアモジュールを通じて、星評価、指示、フィルター機能、スキル、MCP、QA、機能の PR という流れに取り組みます。アプリの分離されたセッションと **Agent Merge** を使用します。4つ目の pull request のマイルストーンとして、リポジトリに保存するキャンバスを作成してマージし、最後に振り返ります。
### ☁️ [Copilot Cloud Agent](../cloud/)
diff --git a/docs/ja-jp/app/0-prerequisites.md b/docs/ja-jp/app/0-prerequisites.md
index 10329a2d..909ca044 100644
--- a/docs/ja-jp/app/0-prerequisites.md
+++ b/docs/ja-jp/app/0-prerequisites.md
@@ -15,18 +15,18 @@ GitHub Copilot app は、Copilot と GitHub の両方を一元的に扱うデス
## Node.js をインストールする
-いくつかのレッスンでは、エージェントに機能を構築させ、Tailspin Toys のテストスイートをローカルで実行します。そのためには [**Node.js**][nodejs] (プロジェクトに必要な唯一のランタイム) が必要です。バージョン **22 以降**をインストールしてください。現在の **LTS** リリースを選ぶと安心です。
+いくつかのレッスンでは、エージェントに機能を構築させ、Tailspin Toys のテストスイートをローカルで実行します。そのためには [**Node.js**][nodejs] が必要です。**Node.js 22.13 以降**を使用し、チェックアウトの `package.json` と README でサポートされるバージョンを確認してください。
どのプラットフォームでも、公式インストーラーを使うのが最も簡単です。
1. Windows Terminal、macOS のターミナル、または普段使用しているターミナルを開きます。
-2. 次のコマンドを実行し、Node.js 22 以降がインストールされていることを確認します。
+2. 次のコマンドを実行し、Node.js 22.13 以降がインストールされていることを確認します。
```shell
node --version
```
-3. `v22` 以上のバージョン番号が表示された場合は、次のセクションに進めます。
+3. 表示されたバージョンが `v22.13.0` 以降で、プロジェクトでサポートされている場合は、次のセクションに進めます。
> [!TIP]
> Node.js がインストールされていない場合、または更新が必要な場合にのみ、以降の手順を実行してください。
@@ -41,10 +41,10 @@ GitHub Copilot app は、Copilot と GitHub の両方を一元的に扱うデス
node --version
```
-9. `v22.x.x` 以上が表示されることを確認します。
+9. 表示されたバージョンが `v22.13.0` 以降で、プロジェクトでサポートされていることを確認します。
-> [!TIP]
-> コンテナーを使用する場合、[**Docker**][docker] があれば、Node.js をローカルにインストールする代わりにリポジトリの [dev container][dev-containers] を使用できます。dev container には Node.js が含まれているため、両方を用意する必要はありません。
+> [!IMPORTANT]
+> この App の学習パスではローカルのワークツリーを使用します。コンテナー内にだけインストールしたランタイムは、ローカルセッションでは利用できません。各ワークツリーには、プロジェクトの依存関係と E2E チェック用の Playwright Chromium も必要です。ワークツリーの準備では学習用リポジトリの README に従い、インストールの要求は内容を確認してから承認してください。
## ラボ用リポジトリを設定する
@@ -64,6 +64,8 @@ Tailspin Toys プロジェクトの自分用コピーを使って作業します
> [!NOTE]
> テンプレートからリポジトリを作成すると、GitHub Issue のバックログが自動的に作成されます。ワークショップ全体を通してこれらの Issue を使用するため、自分で作成する必要はありません。
+改訂済みテンプレートの新しいコピーを使用してください。リポジトリの指示、アプリケーションコード、テスト、既存のキャンバス拡張機能が含まれますが、カスタムエージェントやスキルは同梱されていません。ワークショップ中に独自の quality-checks スキルと QA プロファイルを作成します。古いコピーを使う場合は、既存のカスタマイズを上書きせず、内容を確認してください。
+
## まとめと次のステップ
準備が整いました。プロジェクトをコンピューター上でビルドしてテストできるように Node.js をインストールし、テンプレートから Tailspin Toys リポジトリの自分用コピーを作成しました。
@@ -79,7 +81,5 @@ Tailspin Toys プロジェクトの自分用コピーを使って作業します
[next-lesson]: ../1-install-copilot-app/
[nodejs]: https://nodejs.org/
[node-download]: https://nodejs.org/en/download
-[docker]: https://www.docker.com/products/docker-desktop/
-[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
[template-repository]: https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-template-repository
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/ja-jp/app/1-install-copilot-app.md b/docs/ja-jp/app/1-install-copilot-app.md
index 39325f0d..554abc19 100644
--- a/docs/ja-jp/app/1-install-copilot-app.md
+++ b/docs/ja-jp/app/1-install-copilot-app.md
@@ -41,23 +41,23 @@ GitHub Copilot app を使用するには、まずアプリをインストール
プロジェクトを接続したら、各領域を確認します。アプリのサイドバーは、主に次の領域で構成されています。
-- **Sessions** - エージェントが作業する場所です。各セッションは分離された独自のワークスペースで実行されるため、変更が競合することなく複数のセッションを同時に実行できます。次のレッスンで最初のセッションを開始します。
+- **Sessions** - エージェントが作業する場所です。このワークショップでは **new working tree** を選択し、各 PR マイルストーンに専用の分離されたチェックアウトとブランチを用意します。ほかのワークスペースの選択肢もありますが、ここでは使用しません。
- **Quick chats** - 独自のブランチやワークスペースを必要としない、質問やブレインストーミング向けの簡易的な会話です。このレッスンの最後に試します。
- **My work** - アプリの **GitHub ネイティブ統合**を通じて表示される Issue と pull request です。アプリを離れずに、Issue と pull request の参照や絞り込み、CI ステータスの確認、Issue からのセッション開始、pull request のレビューを行えます。
-- **Automations** - スケジュールまたはオンデマンドで実行する、保存済みのエージェントタスクです。ハーネスの終盤で作成します。
+- **Customize** - MCP server、スキル、キャンバスを検索・管理します。Playwright MCP の設定に使用します。
+- **Automations** - スケジュールまたはオンデマンドで実行する、保存済みのエージェントタスクです。振り返りでは次のステップとしてリンクを紹介し、追加の演習にはしません。
### 用意されたバックログを確認する
アプリは GitHub とネイティブに統合されているため、リポジトリで待機中の作業がアプリ内に表示されます。テンプレートからリポジトリを作成したときに、バックログとなる Issue が用意されています。表示されていることを確認します。
1. サイドバーで **My work** を選択します。
-2. テンプレートはバックログに 8 件の Issue を用意しています。このハーネスでは次の 3 件に焦点を当てます。表示されていることを確認してください。
+2. Issue 番号を決めつけず、次のタイトルで検索します。
- Allow users to filter games by category and publisher
- Update our repository coding standards
- - Implement pagination on the game list page
-3. Issue を選択して詳細を読みます。各 Issue はエージェントセッションの開始点にもなります。ハーネスの後半では、これらの Issue から作業を開始します。
+3. Issue を選択して詳細を読みます。各 Issue はエージェントセッションの開始点にもなります。ハーネスの後半では、これらの Issue から作業を開始します。ほかのバックログの Issue はキャンバスのコンテキストとして使用し、追加の実装タスクにはしません。
> [!NOTE]
> My work の項目一覧は自動的に絞り込まれ、Copilot app に追加したリポジトリの項目だけが表示されます。ほかのリポジトリの作業項目を表示するには、そのリポジトリをアプリに追加してください。
@@ -70,7 +70,7 @@ GitHub Copilot app を使用するには、まずアプリをインストール
2. アプリのセッションがどのように動作するかを尋ねます。
```plaintext
- How does the GitHub Copilot app use worktrees?
+ GitHub Copilot app はワークツリーをどのように使用しますか。
```
3. 会話ビューで回答を読みます。各セッションが分離された独自の git worktree で実行されるため、変更が競合することなく複数のエージェントを並列実行できることがわかります。会話はいつでも継続でき、新しいチャットも開始できます。
@@ -84,7 +84,13 @@ GitHub Copilot app をインストールし、プロジェクトを接続して
- ワークスペースを確認し、**My work** で用意されたバックログを見つける。
- クイックチャットを使って、その場限りの簡単な質問をする。
-次は、最初のエージェントセッションを開始し、ゲームカードに星評価を表示する最初の変更をプロジェクトに加えます。[レッスン 2「最初のエージェントセッションの実行」][next-lesson]に進んでください。
+## PR マイルストーンを分ける
+
+4つの PR をマージします。星評価、指示と小さな実証、フィルター機能とスキル・QA プロファイル・テスト、そしてトリアージキャンバスです。PR マイルストーンごとに1つのブランチを使用します。レッスン4～8では同じフィルター機能のセッション、ワークツリー、ブランチを維持し、追加の PR ではなくチェックポイントコミットを作成します。
+
+App の新しいワークツリーは、古いローカル状態から始まる場合があります。各マイルストーンでファイルを編集する前にリポジトリをフェッチし、新しいセッションのブランチを最新の `origin/main` まで fast-forward してください。以降のレッスンで手順を明示します。ブランチを積み重ねたり、以前の作業を cherry-pick したり、作業中のフィルター機能のセッションを別のブランチに切り替えたりしないでください。
+
+次は、最初のエージェントセッションを開始し、ゲームカードに星評価を表示する最初の変更をプロジェクトに加えます。[レッスン 2「星評価の追加で小さな成果を得る」][next-lesson]に進んでください。
## リソース
@@ -92,7 +98,7 @@ GitHub Copilot app をインストールし、プロジェクトを接続して
- [GitHub Copilot app の概要][getting-started]
- [GitHub Copilot app でのエージェントセッションの操作][agent-sessions]
-[ex0]: ../0-prerequisites/
+[previous-lesson]: ../0-prerequisites/
[next-lesson]: ../2-add-star-rating/
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
diff --git a/docs/ja-jp/app/10-review.md b/docs/ja-jp/app/10-review.md
new file mode 100644
index 00000000..ff5b5200
--- /dev/null
+++ b/docs/ja-jp/app/10-review.md
@@ -0,0 +1,87 @@
+---
+title: "レッスン 10 - 振り返りと次のステップ"
+description: "App の9つのコアモジュール、4つの PR マイルストーン、再利用可能な品質管理ワークフローを振り返り、追加のリソースを確認します。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+ここ数回のレッスンでは、GitHub Copilot app を使い、アイデアから機能のマージまでを実践しました。取り組んだ内容は次のとおりです。
+
+- リポジトリを接続し、アプリのワークスペースと用意されたバックログを確認した。
+- 直接指定したタスクと Issue からセッションを開始し、Plan モードと Autopilot モードでエージェントの動作を制御した。
+- カスタム指示でエージェントをガイドし、シェルスクリプトを含む再利用可能なスキルの作成を依頼して、スクリプトを確認した後、lint、単体テスト、エンドツーエンドテスト、型チェックを実行した。
+- Playwright MCP server を使い、実際のブラウザーで作業をテストした。
+- 要件、カバレッジ、スキルのスクリプトの結果、ブラウザーでの証拠を評価する QA カスタムエージェントを作成して選択した。
+- 共有キャンバスでエージェントと共同作業した。
+- 最初の PR を自分で明示的にマージし、その後、機能とキャンバスの PR ワークフローで **Agent Merge** を承認した。
+
+セットアップのレッスン0～1から、9つのコアモジュールであるレッスン2～10に進みました。成果物と次のステップを振り返りましょう。この振り返りで追加の実習タスクを始めることはありません。
+
+## リリースしたもの
+
+ワークショップには4つの PR マイルストーンがあり、それぞれ更新済みの `main` から作成した専用のブランチを使用します。
+
+1. **星評価:** ゲームカードに既存の `starRating` と明示的な未評価状態を表示します。
+2. **指示と実証:** ドキュメント規約を追加し、小さな実際のコード変更で効果を検証します。
+3. **フィルター機能と品質管理ワークフロー:** Issue を実装し、シェルスクリプトを同梱した `quality-checks` スキルと QA プロファイルを作成して、関連するテストも含めます。
+4. **リポジトリに保存したトリアージキャンバス:** 別の機能を自動実装せず、Issue のコンテキストを追加するボードを共有します。
+
+レッスン4～8では、同じフィルター機能のセッション、ワークツリー、ブランチを使用しました。チェックポイントコミットで PR 3 内の進捗を保存し、スキル、MCP 設定、QA のために別の機能ブランチは必要ありませんでした。後のマイルストーンは、前の PR がマージされ、新しいセッションのブランチを `origin/main` から更新した後にのみ開始しました。
+
+## 検証方法の違い
+
+最初の機能では既存の npm チェックを使用しました。フィルター機能では手動のブラウザー確認を追加しました。スキルは同梱のスクリプトで4つのチェックを繰り返し実行できるようにし、MCP はエージェントによる直接のブラウザー観察を追加し、QA は要件とカバレッジを最終検証と組み合わせました。PR では、提出するリビジョンに適用できる場合にのみ QA の証拠を再利用しました。
+
+追加するテストは実際の不足を補うものにします。新しいテストが不要な QA 実行も正しい結果になり得ます。ツールの不足、スキップされたチェック、失敗は明示すべき阻害要因であり、成功ではありません。マージを承認する前にコードと証拠をレビューし、変更後は関連する証拠を更新してください。
+
+## ベストプラクティス
+
+AI ツールを使用するときは、その周辺の基盤が出力の品質を左右します。このワークショップでは指示、スキル、QA プロファイルを作成しました。これらをレビューし、セッション間で再利用してください。カスタムエージェントは専門家としての役割と指示を定義し、利用可能なツールは設定とハーネスの権限によって決まります。スキルは、必要に応じて読み込む再利用可能なタスクの指示、実行可能なスクリプト、補助リソースをまとめます。カスタムエージェントも、スキルに同梱されたものを含め、スクリプトを実行できます。説得力のある説明だけを信頼せず、実際のスクリプト実行とカスタムエージェントの選択を確認してください。
+
+タスクに合わせて**モードとモデル**を選択します。構築前にアプローチを検討するには **Plan**、対象を絞った変更で作業に関与し続けるには **Interactive**、範囲が明確で分離されたタスクに限って **Autopilot** を使用します。定型的な編集には高速なモデルを選び、複雑な作業には推論能力が高く、より多くの推論を行うモデルを選びます。
+
+基盤と同じくらい、コンテキストも重要です。何を、なぜ、どのように構築するかを明確に説明すると、出力は大きく変わります。アイデアを本格的なセッションに移す前に範囲を決める場所として、Quick chats が役立ちます。
+
+## さらに確認する機能
+
+コアワークフローを学習しました。ほかにも確認する価値がある機能があります。
+
+- 完全なセッションを必要としない、その場限りの簡単な質問に使用する **Quick chats**。
+- 最近の作業の要約など、定期的またはオンデマンドのタスクに使用する [**Automations**][using-automations]。導入前にスケジュール、権限、範囲をレビューしてください。自動化の作成は次のステップであり、このワークショップの一部ではありません。
+- 構築前に問題について対話し、重要なフィードバックを得るための **Rubber duck**。
+- ロール、その tools、指示をまとめ、繰り返し使用する専門的な作業に対応する [**Custom agents**][custom-agents]。
+- セッションで起きたことの記録を生成する [`/chronicle`][chronicle]。
+- Ollama、Foundry Local、LM Studio を介したローカルモデルなど、独自のプロバイダーのモデルを使用する [Bring your own key (BYOK)][byok]。
+- GitHub がホストする分離環境でセッションを実行する [Cloud sandboxes][sandboxes]。
+- アプリを直接リポジトリ、セッション、プロンプトの画面で開く [Deep links][deep-links]。
+
+## 次のステップ
+
+ツールを使いこなす最良の方法は、使い続けることです。実稼働コード、趣味のコード、長年構想していながら構築できていなかった小さなアプリなどに活用してください。学んだことをチームと共有し、チームからも学びましょう。そして、引き続きドキュメントを確認してください。
+
+GitHub Copilot エコシステムをさらに学ぶには、[VS Code ハーネス][vscode-harness]、[Copilot CLI ハーネス][cli-harness]、[Cloud agent ハーネス][cloud-harness]を確認してください。
+
+## リソース
+
+- [GitHub Copilot app について][about-copilot-app]
+- [GitHub Copilot app の概要][getting-started]
+- [GitHub Copilot app のカスタマイズ][customize]
+- [Automations の使用][using-automations]
+- [Canvas extensions の操作][canvas-docs]
+- [クラウドサンドボックスとローカルサンドボックスについて][sandboxes]
+
+[previous-lesson]: ../9-canvases/
+[vscode-harness]: ../../vscode/
+[cli-harness]: ../../cli/
+[cloud-harness]: ../../cloud/
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
+[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
+[customize]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
+[using-automations]: https://docs.github.com/copilot/how-tos/github-copilot-app/using-automations
+[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
+[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
+[chronicle]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/chronicle
+[custom-agents]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
+[byok]: https://docs.github.com/copilot/how-tos/github-copilot-app/use-byok-models
+[deep-links]: https://docs.github.com/copilot/how-tos/github-copilot-app/open-with-deep-links
\ No newline at end of file
diff --git a/docs/ja-jp/app/2-add-star-rating.md b/docs/ja-jp/app/2-add-star-rating.md
index b1edad2c..046a81da 100644
--- a/docs/ja-jp/app/2-add-star-rating.md
+++ b/docs/ja-jp/app/2-add-star-rating.md
@@ -1,5 +1,5 @@
---
-title: "レッスン 2 - 最初のエージェントセッションの実行"
+title: "レッスン 2 - 星評価の追加で小さな成果を得る"
description: "GitHub Copilot app で最初のエージェントセッションを開始し、ゲームカードに小さな変更を加えて、最初の pull request としてマージします。"
authors:
- geektrainer
@@ -22,7 +22,7 @@ Tailspin Toys の各ゲームには星評価を設定でき、ゲーム詳細ペ
## セッションの構造
-**セッション**とは、分離された独自のワークスペースで実行されるエージェントとの会話です。すべてのセッションに**専用の git worktree とブランチ**が割り当てられます。そのため、一方では機能を追加し、もう一方ではバグを修正するなど、変更を競合させずに複数のセッションを同時に実行できます。セッションはリポジトリごとにグループ化されてサイドバーに表示され、選択すると切り替えられます。
+**セッション**とは、エージェントとの会話です。このワークショップでは **new working tree** を選択し、セッション専用のチェックアウトとブランチを用意します。レッスンごとにブランチを分けず、各 PR マイルストーンを分離できます。セッションはリポジトリごとにグループ化されてサイドバーに表示され、選択すると切り替えられます。
セッション内には、エージェントとの**会話**、ファイルを調査および編集するときのエージェントの**ツールアクティビティ**、差分付きの**変更済みファイル**一覧という3つの要素が表示されます。
@@ -36,16 +36,20 @@ Tailspin Toys の各ゲームには星評価を設定でき、ゲーム詳細ペ
-4. 次のプロンプトを使って変更を依頼します。
+4. プロンプトボックスの下で **new working tree** と **Interactive** モードを選択します。次のプロンプトを使って変更を依頼します。
```plaintext
- On the game cards, show each game's star rating. The Game type already includes a starRating field — it's a number out of 5, or null when a game hasn't been rated yet. Display it on each card in src/components/GameCard.astro, and when starRating is null show "No rating yet" instead. Keep the change small and don't restructure the card layout.
+ 編集前にチェックアウトとブランチを特定し、未コミットの変更がない新しいワークツリーであることを確認して、origin をフェッチし、このセッションのブランチを origin/main まで fast-forward してください。HEAD と origin/main が一致することを確認してください。未コミットの変更、分岐、更新できない問題がある場合は停止して説明し、リセットや作業の破棄はしないでください。
+
+ ゲームカードに各ゲームの星評価を表示してください。Game 型には starRating フィールドがすでにあり、5点満点の数値、または未評価の場合は null が入ります。src/components/GameCard.astro の各カードに表示し、starRating が null の場合は代わりに "No rating yet" と表示してください。変更は小さく保ち、カードのレイアウトの再構成やデータモデルの変更はしないでください。
+
+ リポジトリの指示に従い、適切なテストを追加または更新して、関連する既存の npm チェックを実行してください。前提条件を調べ、インストールの前に確認してください。変更したファイルとチェック結果を報告したら、レビューのために停止してください。コミット、プッシュ、pull request の作成、別の機能の実装はしないでください。
```
> [!NOTE]
> プロンプトに、Copilot が更新するファイル名が含まれていることに注目してください。Copilot が作業に含めるファイルを指定する必要はありませんが、方向性を示すことで、コードをすばやく生成し、トークン使用量を削減できます。
-5. Enter を選択して、プロンプトを Copilot に送信します。
+5. Enter を押して、プロンプトを Copilot に送信します。
Copilot app は、最初にプロジェクトの分離されたコピーである新しい worktree を作成して作業を開始します。次にプロジェクトを調査し、新機能の追加に必要な更新対象ファイルを見つけて、必要なコードを作成します。これで Copilot app を使って新機能を追加できました。
@@ -76,7 +80,9 @@ AI が生成したすべての変更は、どれほど小さくてもマージ
## 変更を確認する
-コードを読むだけで動作すると判断せず、視覚的にもテストします。そのためには、ターミナルからアプリを起動して、すべてが動作することを確認する必要があります。Copilot app にはターミナルが組み込まれています。
+ブラウザーを開く前に、エージェントの自動チェック結果をレビューします。まだ作成していないスキルではなく、プロジェクトの既存の npm スクリプトを使い、数値の `starRating` と `null` の場合の代替表示をテストしていることを確認します。前提条件が不足していたり、チェックがスキップされていたりする場合は成功ではありません。
+
+次にセッション内蔵のターミナルでアプリを手動確認します。サーバーを起動する前にワークツリーを特定し、別のチェックアウトのサーバーを再利用しないでください。
1. Copilot app の右側にあるレビューパネルで **Terminal** を選択します。**Terminal** ボタンがない場合は、**+** (**Open in panel** というラベルが付いています) を選択してから **Terminal** を選択します。
@@ -89,26 +95,30 @@ AI が生成したすべての変更は、どれほど小さくてもマージ
```
3. サーバーが起動したら、ブラウザーウィンドウを開きます。起動には少し時間がかかります。
-4. http://localhost:4321 に移動します。
-5. ランディングページのすべてのゲームに星評価が表示されていることを確認します。
+4. サーバーが出力したローカル URL を開きます。通常は `http://localhost:4321` です。ポートが使用中の場合は、無関係なプロセスを停止せず所有者を特定します。
+5. 評価済みのゲームカードに5点満点の値が表示されることを確認します。未評価のデータがある場合は **No rating yet** が表示されることを確認します。ない場合は、観察したと主張せず、自動テストで null のケースを検証します。
6. ターミナルウィンドウに戻ります。
-7. Ctrl+C を選択して開発サーバーを停止します。
+7. Control+C (Mac) または Ctrl+C (Windows/Linux) を押し、自分で起動した開発サーバーを停止します。
## 最初の pull request を作成してマージする
-変更に問題がないことを確認できたので、リリースします。エージェントに pull request の作成を依頼し、github.com で自分でレビューしてマージします。今回は手動で管理します。後のレッスンでは、Copilot でこの作業の一部を自動的に処理する方法を確認します。
+変更に問題がないことを確認できたので、PR 1 を作成します。まず、実装とは別にコミットと PR の作成を承認します。
+
+```plaintext
+星評価の変更とそのテストの差分全体をレビューし、検証結果をまとめて、レビュー済みの変更をこのセッションのブランチにコミットしてください。ブランチをプッシュし、リポジトリの PR テンプレートを使って main を対象とする pull request を作成してください。マージはしないでください。
+```
-1. 右上隅にある **Create PR** を選択します。
+1. セッション内の作成済み PR のリンクを開きます。アプリに **Create PR** の確認が表示された場合は、それを選択して依頼を承認し、2つ目の PR は作成しないでください。
2. 求められた場合は **Sign in with your browser** を選択し、画面の指示に従って認証します。
3. Copilot が PR の作成を開始します。
-PR が作成されると、Copilot はリポジトリで実行する必要があるワークフローを監視します。しばらくすると、右上のボタンが **Ready to merge** に変わります。これは PR をマージする準備が整ったことを示します。
+PR が作成されたら、**My work** で PR の差分全体とチェックを確認します。学習用リポジトリのワークフロー結果を読み、必須のチェックとレビューが完了するのを待ち、失敗に対処してからマージします。**Ready to merge** は、変更のレビューやローカルで得た証拠の代わりにはなりません。
4. チャットのすぐ上にある **PR** バブルを選択し、レビューペインで PR を開いて pull request を確認します。必要に応じて、ここで PR をレビューできます。
5. 準備ができたら **Ready to merge** を選択します。
6. 新しいダイアログウィンドウで **Merge pull request** を選択し、pull request をマージします。
-これで Web サイトに新機能を反映できました。
+続行前に PR 1 が `main` にマージされたことを確認します。学習用リポジトリのマージだけで Web サイトがデプロイされるわけではありません。次のレッスンでは新しいワークツリーを開始し、`origin/main` から更新してこの PR を取り込みます。
## まとめと次のステップ
@@ -118,7 +128,7 @@ PR が作成されると、Copilot はリポジトリで実行する必要があ
- ゲームカードに小規模で対象を絞った変更を加えるようエージェントに指示した。
- ワークスペースの差分ビューで変更をレビューした。
- アプリをローカルで実行し、ブラウザーで星評価を確認した。
-- pull request を作成し、github.com で自分でマージした。
+- PR 1 を作成し、チェックをレビューして、明示的にマージした。
次は、アプリを使ってリポジトリにカスタム指示の標準を追加します。バックログ内の Issue の1つから作業を開始します。[レッスン 3「カスタム指示による Copilot のガイド」][next-lesson]に進んでください。
@@ -129,6 +139,7 @@ PR が作成されると、Copilot はリポジトリで実行する必要があ
- [GitHub Copilot app での Issue と pull request の管理][managing-issues-prs]
[prior-lesson]: ../1-install-copilot-app/#github-copilot-app-をインストールして構成する
+[previous-lesson]: ../1-install-copilot-app/
[next-lesson]: ../3-custom-instructions/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
diff --git a/docs/ja-jp/app/3-custom-instructions.md b/docs/ja-jp/app/3-custom-instructions.md
index 8b801657..51030e7d 100644
--- a/docs/ja-jp/app/3-custom-instructions.md
+++ b/docs/ja-jp/app/3-custom-instructions.md
@@ -1,9 +1,9 @@
---
title: "レッスン 3 - カスタム指示による Copilot のガイド"
-description: "GitHub Copilot app を使い、バックログの Issue から始めてカスタム指示の標準をリポジトリに追加し、変更を pull request としてマージします。"
+description: "ドキュメント標準を追加し、小さな既存のヘルパーまたはコンポーネントで効果を確認して、両方を2つ目の pull request としてマージします。"
authors:
- geektrainer
-lastUpdated: 2026-07-09
+lastUpdated: 2026-09-11
---
生成 AI を扱うとき、コンテキストは重要です。タスクを特定の方法で実行する必要がある場合や、Copilot が把握しておくべき背景情報がある場合は、そのコンテキストを利用できるようにします。特に強力なツールの1つが[指示ファイル][instruction-files]です。指示ファイルには、必要なコードの内容だけでなく、その構成方法も記述します。このレッスンでは、リポジトリにドキュメント標準を追加します。ここから先の多くの作業と同様に、バックログの Issue から開始し、エージェントに変更を行わせます。
@@ -12,15 +12,17 @@ lastUpdated: 2026-07-09
- リポジトリ指示とパス固有の指示ファイルがエージェントにどのように渡されるかを確認する。
- バックログ内の指示に関する Issue からセッションを開始する。
-- `.github/copilot-instructions.md` にドキュメント標準を追加するようエージェントに依頼する。
-- 変更をレビューし、pull request としてマージする。
+- 適切なリポジトリの指示ファイルに、対象を絞ったドキュメント標準を追加するようエージェントに依頼する。
+- 小さな実際のコード変更で標準の効果を確認し、検証して PR 2 をマージする。
## シナリオ
優れた開発組織と同様に、Tailspin Toys にも開発プラクティスのガイドラインと要件があります。内容は次のとおりです。
-- TSDoc doc comment の形式でコードにドキュメントを追加する。
-- フォーマット方法を文書化し、lint によって適用する。
+- コメントはコードを言い換えるのではなく、意図や自明ではない判断を説明する。
+- `db/` と `src/lib/` のエクスポートされた関数には、目的、パラメーター、戻り値を TSDoc/JSDoc で記載し、注入可能な `db` 引数があればそれも説明する。
+- 再利用可能な Astro コンポーネントには `Props` の契約を文書化し、関連コードが変わったらコメントも最新に保つ。
+- 既存のフォーマットと lint のガイダンスを保持する。
指示ファイルを使用すると、示されたプラクティスに沿ってタスクを実行するために必要な情報を Copilot に提供できます。
@@ -28,13 +30,13 @@ lastUpdated: 2026-07-09
カスタム指示を使うと、Copilot にコンテキストと設定を提供でき、コーディングスタイルや要件をより正確に理解させることができます。Copilot をガイドし、より関連性の高い提案やコードスニペットを得るための強力な機能です。希望するコーディング規約、ライブラリ、コードに含めるコメントの種類まで指定できます。リポジトリ全体に適用する指示や、タスクレベルのコンテキストとして特定のファイル種類に適用する指示を作成できます。
-指示ファイルには2つの種類があります。
+このプロジェクトでは2種類の指示ファイルを使用します。
- `.github/copilot-instructions.md` は、リポジトリに対する**すべての**リクエストで Copilot に送信される単一の指示ファイルです。このファイルには、Copilot に送信するほとんどのチャットまたは CLI リクエストに関係する、プロジェクトレベルの情報を記載します。使用する技術スタック、構築するものの概要、ベストプラクティスなど、全体に適用するガイダンスを含められます。
- `.github/instructions/*.instructions.md` ファイルは、特定のタスクやファイル種類向けに作成できます。特定の言語 (TypeScript や Astro など) や、UI コンポーネントまたは新しい単体テスト一式の作成といったタスクに関するガイドラインを提供できます。
> [!NOTE]
-> Copilot は AGENTS.md、CLAUDE.md、GEMINI.md を通じて指示のガイダンスを取り込むほかの標準もサポートしており、常に適切なコンテキストを提供できます。
+> ほかの指示形式やサポート状況はハーネスによって異なります。特定の形式を利用する前に、[カスタム指示のサポートリファレンス][custom-instructions-support]を確認してください。
### 指示ファイルを管理するためのベストプラクティス
@@ -74,49 +76,55 @@ AI の使い方に唯一の方法がないのと同様に、指示ファイル
11. 最後に `.github/instructions/drizzle.instructions.md` を開き、末尾まで移動します。ほかの指示ファイル (`unit-tests.instructions.md` など) と、プロジェクト内の既存ファイルへのリンクに注目してください。これにより、大きな指示セットを小さく再利用可能なファイルに分割し、コード生成時に参照する例を Copilot に提示できます。そこに記載されたパスは、リポジトリのルートではなく指示ファイルを基準とします。
> [!NOTE]
-> `copilot-instructions.md` の **Code formatting requirements** セクションにはプロジェクトのコーディング標準が記載されていますが、コード内のドキュメントはまだ必須ではありません。次の手順で、TSDoc doc comment とファイルコメントヘッダーの規則を追加します。
+> 規則を追加する前に、既存のガイダンスと実際のコーディング標準の Issue を比較してください。このレッスンでは、すべてのファイルへの一律のヘッダーやコードの言い換えではなく、意図を説明するコメント、エクスポートされたデータレイヤー関数のドキュメント、Astro の `Props` の契約に焦点を当てます。
## 指示に関する Issue から開始する
-前のレッスンでは、直接入力したプロンプトからセッションを開始しました。しかし、多くの作業は Issue から始まります。指示ファイルを更新するために登録された Issue に基づいて新しいセッションを作成し、更新を依頼します。
+このセッションを作成する前に PR 1 がマージされたことを確認します。PR 2 用の新しいワークツリーを開始し、星評価のブランチでは続けないでください。多くの作業は Issue から始まるため、コーディング標準の Issue を要件として使用します。
> [!NOTE]
> 指示ファイルは Copilot が生成するコードに大きな影響を与えるため、Copilot を明確にガイドする内容になっていることを慎重に確認してください。このレッスンのように、Copilot で最初のバージョンを作成した後、自分でレビューして更新内容が要件を満たすことを確認する方法が効果的です。
1. サイドバーで **My work** を選択します。
2. **Update our repository coding standards** というタイトルの Issue を選択して開きます。
-3. 右上の **New session** を選択し、Issue に基づく新しいセッションを開始します。
+3. 右上の **New session** を選択し、**new working tree** と **Interactive** モードを選択します。
-4. 次のプロンプトを使い、Issue に記載された要件を満たすように指示ファイルを更新することを Copilot に依頼します。
+4. 次のプロンプトを使用します。編集前に新しいセッションのブランチを更新することで、アプリのローカルチェックアウトが古くても、マージ済みの最新の `main` から確実に開始できます。
- ```plaintext
- Following this issue, make the updates to the instructions files in this project to meet the requirements documented. Don't create the PR quite yet!
- ```
+ ```plaintext
+ 編集前にチェックアウトとブランチを特定し、未コミットの変更がない新しいワークツリーであることを確認して、origin をフェッチし、このセッションのブランチを origin/main まで fast-forward してください。HEAD と origin/main が一致し、マージ済みの星評価の PR が含まれることを確認してください。未コミットの変更、分岐、そのマージの不足がある場合は停止し、リセット、作業の破棄、別のブランチの作成はしないでください。
+
+ "Update our repository coding standards" という Issue と既存のリポジトリの指示を読んでください。対象を絞ったドキュメント規約を追加してください。処理の仕組みではなく意図を説明し、db/ と src/lib/ のエクスポートされた関数には TSDoc/JSDoc で目的、パラメーター、戻り値、存在する場合は注入可能な db 引数を記載してください。再利用可能な Astro コンポーネントの Props の契約を文書化し、関連コードの変更時にはコメントを最新に保つようにしてください。
+
+ 各規則を適切な既存の指示ファイルに重複や矛盾なく配置し、README から更新した標準にリンクするか、その概要を記載してください。既存のフォーマットと lint のガイダンスを保持してください。一律のファイルヘッダーの要求、フォーマットツールの移行、アプリケーション全体のドキュメントの書き換え、フィルター機能の実装はしないでください。指示の差分を提示したらレビューのために停止してください。スキルやエージェントの作成、コミット、プッシュ、PR の作成はしないでください。
+ ```
Copilot が更新を行います。
## 変更をレビューする
-Copilot が行った更新を読み、更新された指示に基づいて生成するコード例も提示させます。
+更新したガイダンスを読み、実際のファイルで効果を確認します。コードスニペットの提案だけでは、リポジトリの指示がコード変更に影響したことは示せません。
1. 右上の **Changes** を選択してコードの変更を開きます。
-2. 更新された指示ファイルをレビューします。コードにドキュメントとコメントを追加するためのガイドラインが含まれていることを確認します。
+2. 更新された指示ファイルと README の参照をレビューします。一律のファイルヘッダーを要求せず、Issue のコメント方針、エクスポートされた関数のドキュメント、コンポーネントの契約に規則が合っていることを確認します。
> [!NOTE]
> AI は決定論的ではなく確率的に動作するため、実際のテキストは異なります。
-3. 次のプロンプトを使い、Copilot が今後生成するコード例を作成するよう依頼します。
+3. 指示をレビューした後、この同じセッションで範囲を限定した実証を依頼します。
+
+ ```plaintext
+ db/ または src/lib/ の小さな既存のエクスポートされた TypeScript ヘルパー1つ、または再利用可能な Astro コンポーネント1つで、更新したドキュメント規約を実証してください。リポジトリを調べて適切な既存ファイルを選び、publishers ヘルパーが存在すると決めつけないでください。動作を変えずに可読性を少し改善し、該当する関数ドキュメントや Props の契約のガイダンスを適用してください。コードを言い換えるだけのコメントは追加せず、自明ではない意図を説明してください。
- ```plaintext
- Do not make any updates, but show me what the code would look like. Based on the new instructions, if I asked Copilot to create a new library component to return all Publishers what would that code look like?
- ```
+ 変更はその実証と直接関連するテストに限定してください。フィルター機能の実装や新機能の作成はしないでください。関連する既存の npm チェックを実行し、変更内容と指示がコードに与えた影響を報告して、レビューのために停止してください。インストールの前には確認してください。コミット、プッシュ、PR の作成はしないでください。
+ ```
-4. Copilot が提案するコードをレビューします。更新された指示で求めたとおり、TSDoc doc comment とファイルヘッダーコメントが含まれていることを確認します。
+4. チャットの応答だけでなく、実際のファイルの差分をレビューします。ドキュメントが実際の動作を説明し、可読性の改善によって動作が変わっていないことを確認します。関連するテスト、lint、型チェックの結果を確認し、失敗を解消してから続けます。
これでプロジェクトの指示ファイルを更新し、その効果を確認できました。
@@ -124,17 +132,23 @@ Copilot が行った更新を読み、更新された指示に基づいて生成
指示ファイルはリポジトリのアセットとなり、チームのほかのメンバーと共有されます。ほかのアセットと同様に、作業内容を含む PR を作成します。
-1. 右上隅にある **Create PR** を選択します。
+まず、レビュー済みの指示と実証コードをまとめて承認します。
+
+```plaintext
+コーディング標準の指示、README の参照、範囲を限定した実証コードについて、関連するテストも含めて差分全体をレビューしてください。検証結果をまとめ、レビュー済みの変更をこのセッションのブランチにコミットしてください。ブランチをプッシュし、リポジトリの PR テンプレートを使用してコーディング標準の Issue にリンクした、main を対象とする pull request を1つ作成してください。Issue のすべての受け入れ条件を満たしていない限り、部分的な貢献として説明し、未完了の作業に Issue を閉じるキーワードを使用しないでください。マージはしないでください。
+```
+
+1. セッション内の PR のリンクを開きます。アプリに **Create PR** の確認が表示された場合は、重複する PR を作成せず、その確認を選択します。
2. 求められた場合は **Sign in with your browser** を選択し、画面の指示に従って認証します。
3. Copilot が PR の作成を開始します。
-PR が作成されると、Copilot はリポジトリで実行する必要があるワークフローを監視します。しばらくすると、右上のボタンが **Ready to merge** に変わります。これは PR をマージする準備が整ったことを示します。
+**My work** で指示とコードの変更を含む PR の差分全体を確認します。学習用リポジトリの CI 結果と必須のレビューを確認してください。失敗に対処してから **Ready to merge** を選択します。CI は実証やレビューの代わりにはなりません。
4. **Ready to merge** を選択します。
5. 新しいダイアログウィンドウで **Merge pull request** を選択し、pull request をマージします。
> [!NOTE]
-> 標準がデフォルトブランチにマージされると、すべてのメンバーと新しいセッションでプロジェクトの一部として利用できます。次のレッスンで最新のデフォルトブランチからフィルター機能のセッションを開始すると、エージェントは自動的にこの標準に従います。生成された TypeScript に、依頼していなくても TSDoc doc comment が含まれます。指示が生成コードを形作ることを示す、小さいながらも実際的な例です。
+> フィルター機能を始める前に、PR 2 が `main` にマージされたことを確認してください。新しいワークツリーを作るだけでは最新のコードは保証されません。レッスン4ではフェッチし、新しいセッションのブランチを `origin/main` まで fast-forward して、先の2つのマージが含まれることを確認してから計画を立てます。
## まとめと次のステップ
@@ -142,10 +156,10 @@ PR が作成されると、Copilot はリポジトリで実行する必要があ
- リポジトリの `copilot-instructions.md` とパス固有の `*.instructions.md` ファイルを確認した。
- バックログ内の指示に関する Issue からセッションを開始した。
-- `.github/copilot-instructions.md` にドキュメント標準を追加するようエージェントに依頼した。
-- 変更をレビューし、pull request としてマージした。
+- 適切な指示ファイルに対象を絞ったドキュメント規則を追加し、README から参照するようエージェントに依頼した。
+- 実際のコード変更に対する標準の効果を確認し、結果を検証して、両方を PR 2 としてマージした。
-次は、新しいセッションでフィルター機能を構築し、先ほどマージした標準が適用される様子を確認します。[レッスン 4「Autopilot による機能の構築」][next-lesson]に進んでください。
+次は、新しいセッションでフィルター機能を構築し、先ほどマージした標準に従っていることを確認します。[レッスン 4「Plan と Autopilot によるフィルター機能の構築」][next-lesson]に進んでください。
## リソース
@@ -154,6 +168,7 @@ PR が作成されると、Copilot はリポジトリで実行する必要があ
- [カスタム指示を作成するためのベストプラクティス][instructions-best-practices]
- [Awesome Copilot - 指示ファイルなどのリソース集][awesome-copilot]
+[previous-lesson]: ../2-add-star-rating/
[next-lesson]: ../4-build-filtering/
[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/ja-jp/app/4-build-filtering.md b/docs/ja-jp/app/4-build-filtering.md
index 781f83d0..5d4b6dba 100644
--- a/docs/ja-jp/app/4-build-filtering.md
+++ b/docs/ja-jp/app/4-build-filtering.md
@@ -1,186 +1,122 @@
---
-title: "レッスン 4 - Autopilot による機能の構築"
-description: "GitHub Copilot app の Plan モードと Autopilot モードを使って静的なクライアント側フィルター機能を構築し、ドキュメント標準が継承されることを確認して、エージェントスキルで検証します。"
+title: "レッスン 4 - Plan と Autopilot によるフィルター機能の構築"
+description: "Issue に基づいてフィルター機能を計画し、Autopilot を明示的に承認して、既存の npm チェックと手動のブラウザー確認で検証し、チェックポイントを保存します。"
authors:
- geektrainer
-lastUpdated: 2026-07-13
+lastUpdated: 2026-09-11
---
-ここまで、プロジェクトに小さな更新をいくつか加えました。しかし、より本格的な変更には、よりしっかりしたプロセスが必要です。GitHub Copilot app は既存のフローと連携できるように設計されており、適切なものを適切な方法で構築できます。このレッスンから3回にわたり、一般的な開発プロセスに従います。まず Issue を使って新機能を生成し、エージェントスキルで検証テストと linter を実行します。
+星評価と、実証コードを含むドキュメント標準をマージしました。次はフィルター機能を構築します。ここから1つの大きな PR マイルストーンが始まります。レッスン4～8では、この同じセッション、ワークツリー、ブランチを維持してください。
このレッスンでは、次の内容を学習します。
-- フィルター機能に関する Issue から新しいセッションを開始する。
-- **Plan** モードで機能を計画し、**Autopilot** で構築する。
-- 生成されたコードが、以前マージしたドキュメント標準に従っていることを確認する。
-- プロジェクトの `quality-checks` スキルで作業を検証する。
+- 更新済みの `main` から開始し、実際のフィルター機能の Issue を読む。
+- **Plan** モードで要件を明確にしてから、**Autopilot** を明示的に承認する。
+- フィルター機能とテストをレビューし、既存の4つの npm チェックを実行する。
+- ブラウザーで機能を手動確認し、チェックポイントを保存する。
-## シナリオ
+スキル、MCP による検証、QA プロファイル、機能の PR は後のモジュールで扱います。この実装段階では作成しないでください。
-ホームページにはすべてのゲームが一覧表示されますが、訪問者は一覧を絞り込めません。フィルター機能に関する Issue では、**カテゴリー**と**パブリッシャー**でゲームを絞り込めるようにすることが求められています。Copilot を使ってこの機能を実装します。
-
-## 背景
+## セッションモード
-AI コーディングエージェントを開発フローに導入しても、基本は変わりません。むしろ、基本はさらに重要になります。多くの開発者は、次のようなフローに従います。
+プロンプト下のモードセレクターでエージェントの自律性を制御します。
-1. 必要な作業の詳細が記載された Issue を開く。
-2. 構築する内容の計画を作成する。
-3. コードを構築してレビューする。
-4. テストを実行してコードを検証する。
-5. 新機能を手動で検証する。
-6. pull request (PR) を作成する。
-7. コードのレビューと継続的インテグレーションプロセスが成功したら、コードをマージする。
+- **Interactive** では、エージェントが作業し、入力を求める中で継続的に関与します。
+- **Plan** では、実装前にレビューする計画を用意します。
+- **Autopilot** では、承認した範囲と権限内で自律的に実装と反復を進めます。
-> [!NOTE]
-> 正確な手順はチームや Organization によって異なりますが、多くの場合は上記の流れを変形したものです。
+まず計画を立て、承認を明示し、再利用可能なカスタマイズを作成する前に Interactive に戻します。
-この標準的なアプローチを守ることで、AI が生成したコードが定められた要件を満たし、人間が作成したコードと同じ審査プロセスを通るようにできます。
+## 更新済みの main から開始する
-## セッションモード
+GitHub で PR 1 と PR 2 がマージされたことを確認します。以前のブランチを続けるのではなく、フィルター機能用の新しいワークツリーを作成します。
-**セッションモード**は、エージェントの自律性を制御します。プロンプトフィールド下のドロップダウンから設定し、いつでも変更できます。
+1. **My work** を選択し、**Allow users to filter games by category and publisher** をタイトルで検索します。開いて実際の URL をコピーしてください。Issue 番号はリポジトリによって異なります。
+2. **New session** を選択し、**new working tree** を選びます。開始状態の更新中は **Interactive** モードを維持します。
-- **Interactive**: ユーザーとエージェントが共同で作業します。エージェントは変更を提案し、続行前に入力を待ちます。
-- **Plan**: エージェントが最初に計画を作成します。計画実行前に内容をレビューして承認します。
-- **Autopilot**: エージェントが完全に自律して作業し、入力を待たずにコードの作成、テストの実行、反復を行います。
+ 
-## フィルター機能を計画する
+3. 計画や編集の前に、次の準備の依頼を送信します。
-潜在的な問題を見つける最適なタイミングは、コードを作成する前です。そのためには、事前に少し計画を立てるのが効果的です。Copilot と計画を立てると、一連の手順と採用するアプローチが生成されます。その計画をレビューし、改善案があれば提案してから、計画に基づいて Copilot にコードを生成させることができます。
-
-Issue を開いて新しいセッションを開始し、Plan モードに切り替えて計画を作成します。
+ ```plaintext
+ 何も実装せずに、この新しいフィルター機能のセッションを準備してください。チェックアウトとブランチを特定し、ワークツリーに未コミットの変更がないことを確認して、origin をフェッチし、このセッションのブランチを origin/main まで fast-forward してください。HEAD が origin/main と一致し、マージ済みの星評価とコーディング標準の PR が含まれることを確認してください。
-1. ナビゲーションタブから **My work** を選択します。
-2. **Allow users to filter games by category and publisher** というタイトルの Issue を選択します。
-3. 右上の **New session** を選択します。
+ 未コミットの変更、分岐、いずれかのマージの不足がある場合は停止して説明してください。リセット、作業の破棄、ブランチの切り替え、別のブランチの作成、アプリケーションファイルの編集はしないでください。開始時点のリビジョンを報告してください。
+ ```
- 
+4. 報告された開始状態を確認します。フェッチだけではワークツリーは更新されません。作業前に現在のセッションのブランチを fast-forward し、`HEAD` がフェッチした `origin/main` と一致する必要があります。
-4. モードに **Plan** と表示されるまで Shift+Tab を選択します。
+## フィルター機能を計画する
- 
+モードセレクターを **Plan** に切り替えます。以下の Issue のプレースホルダーをコピーした URL に置き換えてください。
-5. 次のプロンプトを送信します。Issue から開始したため、フィルター機能の Issue はすでにこのセッションのコンテキストに含まれています。
+```plaintext
+この Issue に基づいてフィルター機能を計画してください: 。受け入れ条件の全文とリポジトリの指示を読み、現在の静的な Astro アプリケーションと既存のデータアクセス用ヘルパー、テストを調べてください。まだ実装しないでください。
- ```plaintext
- Plan the work based on the requirements documented in the issue. Please ask any clarifying questions you might have as you build the plan.
- ```
+Issue で求められる複数カテゴリーの選択、パブリッシャーによるフィルター、カテゴリーとパブリッシャーを組み合わせたフィルター、適切なデータアクセス用ヘルパー、アクセシブルな操作部品、単体テストとエンドツーエンドテストのカバレッジを扱ってください。複数カテゴリーの組み合わせ方、フィルターのクリア、結果が空の場合など、指定されていない動作は勝手に要件を作らず質問してください。要件と既存のアーキテクチャに照らして妥当でない限り、サーバー API は導入しないでください。
-6. 計画の作成中に、エージェントから追加の質問が提示される場合があります。自分で機能を構築するときの方針に基づいて回答します。
+リポジトリのドキュメント規約に従い、必要な単体テストとエンドツーエンドテストを追加または更新する、範囲を限定した実装・検証計画を提案してください。package.json でコマンドを確認したうえで、既存のプロジェクトツールを使って npm run lint、npm run test:unit、npm run test:e2e、npm run typecheck:all を実行する計画にしてください。QA で再利用できるよう、Issue の URL と承認した追加の取り決めを計画に記録してください。
-> [!NOTE]
-> Copilot は確率的に動作するため、追加で尋ねられる質問は異なります。質問がまったくない場合もありますが、問題ありません。
+承認前の計画に、次の実行時の安全策を含めてください。テスト対象のチェックアウトとサーバーを特定し、チェック実行前に前提条件を確認してください。ソフトウェア、依存関係、ブラウザーのインストール前には確認してください。別のワークツリーのサーバーを再利用せず、自分で起動したサーバーだけを停止し、それ以外のポート競合は無関係なプロセスを停止せず報告してください。前提条件の不足とスキップされたチェックは、成功ではなく阻害要因として報告する必要があります。
-7. 完了すると、Copilot が計画の概要を提示します。計画をレビューしてください。クエリの構築、フィルターコントロールの追加、テストの作成が提案されているはずです。必要に応じてフィードバックを返して改善できます。エージェントは提案を新しいバージョンに反映します。
+計画に次の実装範囲を含めてください。私が Autopilot を明示的に承認した後、この同じワークツリーとブランチで合意したフィルター機能とテストだけを実装し、4つのチェックを実行してください。実装内容とすべてのチェック結果を、失敗や阻害要因も含めて報告し、レビューと手動のブラウザー確認のために停止してください。実装中は、スキルやカスタムエージェントの作成、MCP の設定、ブランチの変更、コミット、プッシュ、PR の作成をしないでください。手動のブラウザー確認とチェックポイントコミットは、後で私の別の指示に従って行います。
-## Autopilot で構築する
+今は Plan モードを維持し、レビューできるよう計画を提示して停止してください。実装、スキルやカスタムエージェントの作成、MCP の設定、ブランチの変更、コミット、プッシュ、PR の作成はしないでください。
+```
-計画が完成したので、Copilot に実装を構築させます。
+確認の質問に回答し、Issue と照らし合わせて計画をレビューします。UI だけの実装を承認せず、データアクセスの変更、アクセシブルな操作部品、テストを確認してください。レッスン6と7で使うために、実際の Issue の URL と承認した追加の取り決めを計画から保存します。追加の条件が不要だった場合は `none` を使用します。
-1. **Plan summary** ダイアログのオプション一覧で、**Approve and implement with autopilot** に最も近いオプションを選択します。
+承認前に、計画自体に4つのチェック、ドキュメント規約、前提条件とサーバーの安全策、同じワークツリーとブランチを維持する要件、実装と検証後の停止が含まれることを確認してください。実装中に、後のスキルやエージェントの作成、MCP の設定、コミット、プッシュ、PR の作成を禁止している必要があります。境界条件が不足していれば、**Plan** モードのまま計画の修正を依頼し、修正版を確認してから承認します。
-Copilot が実装作業を開始します。
+## Autopilot を明示的に承認する
-> [!NOTE]
-> Copilot が必要なコードの作成を自動的に開始しない場合は、"Go ahead and start building out the plan!" のようなプロンプトを使って開始を依頼できます。
->
-> 必要な更新の作成には数分かかります。エージェントはファイルを編集および作成し、テストを作成して実行し、反復します。この時間に、ここまで学習した内容を振り返ったり、飲み物を用意したりできます。
+レビュー済みの計画に要件とすべての実行境界が含まれていることを確認してから、計画の承認操作で **Approve and implement with autopilot**、または使用中のバージョンで表示される同等の明示的な Autopilot オプションを選択します。モード表示が **Autopilot** になっていることを確認してください。
-## 変更をレビューする
+承認するとすぐに実行が始まる場合があります。そのため、実装範囲、安全規則、停止条件はすべて承認前のレビュー済み計画に含める必要があります。実行が始まった後の追加メッセージで指定することを前提にしないでください。
-AI が生成したすべてのコードは、マージ前にレビューする必要があります。コードをレビューし、サイトを実行して問題がないことを確認します。
+Autopilot はコードとテストを作成し、失敗に対処して反復できます。ただし、これは後のモジュールまで完了させる許可ではありません。前提条件の不足は承認を得て解決する阻害要因であり、チェックの成功ではありません。
-1. 右上の **Changes** を選択してコードの変更を開きます。
+## 実装をレビューして検証する
- 
+1. **Changes** を開き、フィルター機能の実装とテストを確認します。
+2. 複数カテゴリーとパブリッシャーの組み合わせも含め、結果を Issue と承認した追加の取り決めに照らし合わせます。新規または変更したヘルパーがレッスン3のドキュメント標準に従っていることを確認します。
+3. 4つの npm チェックすべての実際のコマンド出力を確認します。quality-checks スキルはまだ作成していないため、この段階では直接実行します。
+4. 実装を承認する前に失敗を解消し、該当するチェックを再実行します。Playwright の E2E 設定はビルドしてプレビューを配信し、ローカルサーバーを再利用できるため、テスト対象が以前のレッスンではなくこのワークツリーのサーバーであることを確認します。
-2. 変更をレビューします。新しい TypeScript ファイル、Astro ファイル、テストファイルが表示されます。新しいヘルパー関数には、レッスン3でマージしたドキュメント標準に従い、依頼していなくても TSDoc doc comment とファイルヘッダーコメントが含まれていることを確認します。
-3. Copilot app の右側にあるレビューパネルで **Terminal** を選択します。**Terminal** ボタンがない場合は、**+** (**Open in panel** というラベルが付いています) を選択してから **Terminal** を選択します。
+## 機能を手動確認する
- 
+手動レビューの前にセッションを **Interactive** モードに戻し、レッスン5でも維持します。
-4. ターミナルウィンドウに次のコマンドを入力し、Web アプリの開発サーバーを起動します。
+1. このセッションのレビューパネルで **Terminal** を開きます。必要であれば **+**、**Terminal** の順に選択します。
+2. ターミナルがフィルター機能のワークツリー内にあることを確認し、次を実行します。
```shell
npm run dev
```
-5. サーバーが起動したら、ブラウザーウィンドウを開きます。起動には少し時間がかかります。
-6. http://localhost:4321 に移動します。
-7. ランディングページでフィルターを使用できることを確認します。
-8. 問題がある場合は、Copilot に更新を依頼できます。
-9. 問題がなければ、ターミナルウィンドウに戻ります。
-10. Ctrl+C を選択して開発サーバーを停止します。
+3. このサーバーが出力した URL をブラウザーで開きます。通常は `http://localhost:4321` です。ポートが使用中の場合は、無関係なプロセスを停止したり既存のサーバーに変更が含まれると決めつけたりせず、所有者を特定します。
+4. 承認した動作に照らして、カテゴリー選択、パブリッシャー選択、それらの組み合わせを試します。キーボードでの操作と、合意したクリア操作や結果が空の場合の動作も確認します。
+5. 問題があれば、範囲を絞った修正を依頼し、差分をレビューして、関連する自動チェックとブラウザーでの確認を繰り返します。
+6. ターミナルに戻り、Control+C (Mac) または Ctrl+C (Windows/Linux) を押して、自分で起動したサーバーを停止します。次のモジュールの E2E 実行前に、停止したことを確認してください。
-## quality-checks スキルで作業を検証する
+これは手動のブラウザー観察です。MCP を使ったエージェントによるブラウザー観察はレッスン6で扱います。
-差分を目視で確認するだけで完了とすることもできますが、このチームには明確な品質基準と、それを繰り返し確認する方法があります。
+## チェックポイントを保存する
-**エージェントスキル**を使うと、テストの実行、ビルドの生成、pull request の作成など、繰り返し発生するタスクの実行方法を Copilot に指示できます。スキルは、エージェントが必要に応じて読み込める指示、スクリプト、リソースのフォルダーです。[Agent Skills はオープン標準][agent-skills-repo]であり、さまざまなエージェントで使用されています。そのため、同じスキルをエージェントモードの Copilot Chat、Copilot cloud agent、Copilot CLI、GitHub Copilot app で使用できます。
+変更と検証結果をレビューしたら、ローカルコミットを承認します。
-スキルはプロジェクトの `.github/skills` フォルダー、またはグローバルの `~/.copilot/skills` に配置します。各スキルは、YAML frontmatter (`name` と `description`) と、それに続く Markdown の指示が記載された `SKILL.md` ファイルを含むフォルダーです。
-
-```yaml
----
-name: quality-checks
-description: Run the project's test suites and linter to verify code changes are ready to commit, push, or merge.
----
+```plaintext
+現在の差分をレビューし、フィルター機能の実装とテストのチェックポイントコミットを作成してください。この同じフィルター機能のブランチとワークツリーを維持してください。スキルやエージェントの作成、MCP の設定、プッシュ、pull request の作成はしないでください。
```
-スキルには、スクリプト、アセット、参考資料を含むサブフォルダーも追加できます。完全な構造については、[エージェントスキルの仕様][agent-skills-spec]を参照してください。
-
-> [!TIP]
-> スキルは動的に読み込まれます。エージェントは `description` フィールドに基づいて適用するスキルを判断します。明確でシナリオに合った説明を記述することが、スキルが使用されるか無視されるかを左右します。
-
-## quality-checks スキルを確認する
-
-スキルの内容を確認します。
-
-1. レビューパネルが表示されていない場合は、右上の **Toggle review panel** を選択して開きます。
-
- 
-
-2. **+** を選択し、レビューパネルに新しい項目を追加します。
-3. **File** を選択します。
-4. `SKILL.md` を検索します。
-5. ファイル一覧から `SKILL.md .github/skills/quality-checks` を選択して開きます。
-6. `name` と `description` を確認します。説明は、コード変更を commit、push、merge する前にテスト、lint、検証する必要がある場合に、このスキルを使用することをエージェントに伝えます。
-7. スキル全体を読みます。単体テスト、Playwright のエンドツーエンドテスト、ESLint の各スイートを実行するスクリプト、実行順序、一般的な失敗のデバッグ方法が記載されています。そのため、エージェントは推測するのではなく、チームの方法でチェックを実行できます。
-
-## チェックを実行する
-
-同じフィルター機能のセッションで、エージェントに作業の検証を依頼します。スキル名を説明する必要はありません。エージェントがリクエストに一致するスキルを見つけます。
-
-1. Copilot app に戻ります。
-2. スラッシュコマンド `/quality-checks` を使ってスキルを直接呼び出し、Enter を選択します。
-3. エージェントはスキルに従って単体テスト、linter、エンドツーエンドテストを実行し、結果を報告します。失敗したものがあれば、問題を修正して、すべて成功するまでチェックを再実行するよう依頼します。
-4. **このセッションを開いたままにします。** 次のレッスンでは Playwright MCP server を追加し、実際のブラウザーでフィルター機能が動作することを確認します。
-
-## まとめと次のステップ
-
-実際の機能をエンドツーエンドで構築し、チームの基準に照らして検証しました。具体的には、次の作業を行いました。
-
-- 最新のプロジェクトで、フィルター機能に関する Issue から新しいセッションを開始した。
-- Plan モードで機能を計画し、Autopilot で構築した。
-- 生成されたヘルパーが、レッスン3でマージしたドキュメント標準に従っていることを確認した。
-- `quality-checks` スキルで作業を検証した。
-
-次は Playwright MCP server を接続し、実際のブラウザーでフィルター機能を確認するようエージェントに依頼します。[レッスン 5「Playwright MCP server によるテスト」][next-lesson]に進んでください。
+このチェックポイントは PR 3 の一部であり、別の PR ではありません。同じセッションの **Interactive** モードを維持して、[レッスン 5「quality-checks スキルの作成と使用」][next-lesson]に進んでください。
## リソース
- [GitHub Copilot app でのエージェントセッションの操作][agent-sessions]
-- [Agent Skills について][about-agent-skills]
-- [GitHub Copilot app のカスタマイズ][customize-app]
- [GitHub Copilot のクラウドサンドボックスとローカルサンドボックスについて][sandboxes]
-[ex0]: ../0-prerequisites/
-[ex2]: ../2-add-star-rating/
-[ex3]: ../3-custom-instructions/
-[next-lesson]: ../5-mcp-playwright/
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
\ No newline at end of file
diff --git a/docs/ja-jp/app/5-agent-skills.md b/docs/ja-jp/app/5-agent-skills.md
new file mode 100644
index 00000000..cc6d482d
--- /dev/null
+++ b/docs/ja-jp/app/5-agent-skills.md
@@ -0,0 +1,93 @@
+---
+title: "レッスン 5 - quality-checks スキルの作成と使用"
+description: "再利用可能なシェルスクリプト付き品質チェックスキルを Copilot に作成させ、内容を確認してフィルター機能のブランチで実行します。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+フィルター機能を実装し、既存の npm コマンドでチェックしました。次は、これらのチェックを再利用可能な**エージェントスキル**にまとめます。レッスン4～8では同じフィルター機能のセッションとブランチを維持してください。このレッスンでは pull request を作成しません。
+
+このレッスンでは、次のことを行います。
+
+- カスタマイズを作成する前に **Interactive** モードに戻る。
+- Copilot に `quality-checks` を作成させ、確認のために停止させる。
+- 同梱のスクリプトを通じて4つすべてのチェックを実行し、単一のテストファイルを指定する引数が、そのファイルだけを選択することを実証する。
+- フィルター機能と同じブランチにスキルのチェックポイントを保存する。
+
+## 指示、スクリプト、リソース
+
+スキルは、再利用可能なタスクの指示、実行可能なスクリプト、補助リソースをまとめたもので、エージェントが必要に応じて読み込みます。カスタムエージェントは、専門的な役割、指示、利用可能なツールを定義します。これらは補完関係にあります。カスタムエージェントは、スキルに同梱されたものを含め、スクリプトを実行できます。
+
+リポジトリのスキルは `.github/skills//SKILL.md` に配置し、`name` と `description` のフロントマターと Markdown の指示を持ちます。スクリプトやほかのリソースは、その隣に置きます。完成済みの答えをコピーせず、Copilot に `.github/skills/quality-checks/SKILL.md` と同梱のスクリプトを生成するよう依頼します。[Agent Skills 仕様][skill-spec]に形式が説明されています。
+
+Copilot は検出したスキルの説明を使い、いつ読み込むかを判断します。すでに開いているセッションで新しいスキルがすぐ検出されるとは限りません。実行の節では、明示的に読み込む代替手順も示します。形式に移植性があっても、シェルやプロジェクトの前提条件は必要です。
+
+## スキルを作成する
+
+プロンプトを送る前に、モードセレクターでフィルター機能のセッションを **Interactive** モードに戻します。現在のチェックアウトとブランチを維持してください。古いテンプレートから始めてこのスキルがすでにある場合は、カスタマイズを上書きせず、確認して拡張します。
+
+```plaintext
+.github/skills/quality-checks/SKILL.md と、npm run lint、npm run test:unit、npm run test:e2e、npm run typecheck:all を呼び出す4本のスクリプトを作成してください。まず package.json、README、テスト設定、リポジトリの指示を読んでください。
+
+現在の環境を判別してください。macOS/Linux/WSL なら Bash の .sh スクリプト、ネイティブ Windows なら PowerShell の .ps1 スクリプトだけを作成し、不明な場合は質問してください。両方を作成しないでください。ラッパーの役割は、自分自身の配置場所からリポジトリのルートを解決し、そこにこのプロジェクトの package.json があることを検証して npm を呼び出すことに限定してください。不正なルートでは明確なエラーで失敗させてください。どの作業ディレクトリからでも、空白を含むパスでも動作するようにしてください。出力と失敗時の終了コードを維持し、PowerShell のネイティブコマンドの失敗も扱ってください。npm の区切り文字 -- は1回だけ挿入し、呼び出し側は余分な -- を付けずにツールの引数を直接渡すようにしてください。ポートやプロセスは管理しないでください。
+
+SKILL.md に name と description のフロントマター、4本のラッパーを実行する指示、前提条件、トラブルシューティング、既存の単体テストファイル1つを使う例を含む移植可能な呼び出し例を記載してください。Bash の例はすべて bash を明示的に呼び出し、PowerShell の実行ポリシーは決して回避しないでください。Playwright のサーバー再利用について説明してください。停止してよいのは自分で実際に起動したサーバーだけとし、それ以外の場合は質問するようにしてください。
+
+スキルと必要なスクリプトだけを作成してください。チェックや調査用の試行、インストール、アプリケーションコードの変更、コミット、PR の作成はしないでください。内容を確認できるよう、そこで停止してください。
+```
+
+## スキルを確認する
+
+1. **Changes** を開いて生成されたファイルをレビューします。レビューパネルの **+**、**File** の順に選び、`SKILL.md` やスクリプトのファイル名を検索することもできます。
+2. `name` と `description` がスキルの内容と適用する場面を説明しているか確認します。メタデータだけでなく、指示も読んでください。
+3. 実行手順が、lint、単体テスト、E2E、型チェックのために `.github/skills/quality-checks/` 以下の同梱スクリプトを実際に呼び出すことを確認します。
+4. 各ラッパーについて、スクリプトの場所を基準にしたルートの解決と、導き出したディレクトリにこのチェックアウトで使う対象の `package.json` があることを明示的に確認する処理を調べます。npm が祖先ディレクトリを探索してコマンドが成功しても、ルートが正しい証拠にはなりません。パスの引用符、引数の転送、出力の表示、失敗時の終了処理を確認してください。PowerShell はネイティブ npm コマンドの失敗を伝播する必要があります。
+5. 記載された単体テストの1ファイルだけを実行する例を確認します。npm の区切り文字 `--` はラッパーが挿入するため、呼び出し側は別の区切り文字を付けず、対象ツールの引数を直接渡します。再利用する指示には、マシン固有のチェックアウトの絶対パスを含めないでください。何かを実行する前に、不足を修正するよう Copilot に依頼してください。
+6. スクリプトは、ルートとマニフェストの検証、および既存の npm チェックの実行に限定します。ポートやプロセスに関する判断は、シェルのプロセス管理コードではなく SKILL.md に置きます。停止できるのはエージェントが実際に起動したサーバーだけであることを確認してください。作業ディレクトリやプロセス名の一致だけでは、所有者であると判断できません。成果物にはスキル、必須のラッパー、必要な共有ヘルパーだけを含め、一時的な調査用ファイルやデバッグ用ファイルを残さないようにします。
+
+> [!NOTE]
+> 現在の Tailspin Toys には Node.js 22.13 以降、プロジェクトの依存関係、E2E チェック用の Playwright Chromium が必要です。チェックアウトの README と `package.json` で前提条件を確認してください。前提条件の不足や PowerShell の実行ポリシーによる制限は、承認を得て解消する必要があります。自動インストール、ポリシーの回避、断りなく npm の直接実行に切り替える方法で対処してはいけません。
+
+## スキルを実行する
+
+前のレッスンの開発サーバーが停止していることを確認します。Playwright は E2E 用にビルドしてプレビューを配信しますが、ローカルの設定ではポート `4321` のサーバーを再利用できます。別のチェックアウトのサーバーは、この機能の有効な証拠にはなりません。
+
+App に `/quality-checks` が表示される場合は、選択して検出済みのスキルを明示的に呼び出し、以下のリクエストを含めます。検出されていない場合は、このセッションで同じリクエストを直接送信します。この演習では、スキルを読み込む方法を代替手順として使用できます。
+
+```plaintext
+.github/skills/quality-checks/SKILL.md を読み、その指示に従ってこのチェックアウトのフィルター機能を検証してください。まず各ラッパーのコードを調べ、npm による祖先ディレクトリのパッケージ探索に依存せず、このチェックアウトで使う対象の package.json を含むディレクトリを導き出し、不正なルートでは明確に失敗する処理があることを確認してください。失敗を再現するために、リポジトリのファイルを移動、名前変更、削除、変更しないでください。lint、単体テスト、エンドツーエンドテスト、型チェック用の同梱スクリプトを実際に実行してください。記載された単体テストの1ファイルだけを実行する例も実行してください。npm の区切り文字 -- はラッパーが挿入するため、対象ツールの引数を直接渡してください。テストランナーの結果から指定したファイルだけが実行されたことを確認し、そのファイル名と実行されたテストファイル数を報告してください。引数の表示や終了コード 0 だけでは、正しく選択された証拠にはなりません。
+
+各スクリプトの呼び出しと結果を、失敗、スキップしたチェック、不足する前提条件も含めて報告してください。使用できないスキルのスクリプトを、断りなく npm コマンドの直接実行で置き換えないでください。テスト対象のチェックアウトとサーバーを特定し、自分で起動したサーバーだけを停止してください。インストールや別のプロセスの停止前には確認してください。アプリケーションコードやブランチの変更、コミット、プッシュ、pull request の作成はしないでください。
+```
+
+ツールの呼び出しと出力を確認します。4つすべてのスクリプトを実際に実行する必要があります。チェックの説明やスキップされたチェックは成功ではありません。単一ファイルの例では、指定したファイル名をランナーの実際のファイル別結果と報告された件数に照らし合わせ、そのファイルだけが実行されたことを確認します。ほかのファイルも実行された場合は、引数の表示や終了コード 0 では不十分です。失敗は有用な証拠です。スキルを修正するか、承認を得てセットアップの阻害要因を解消し、影響するチェックを再実行します。無関係なプロセスを停止したり、ポート競合を強引に解消したりしてはいけません。
+
+## チェックポイントを保存する
+
+スキルと結果をレビューしたら、ローカルのチェックポイントを承認します。
+
+```plaintext
+現在の差分をレビューし、quality-checks スキルのファイルだけのチェックポイントコミットを作成してください。既存のフィルター機能のブランチを維持してください。プッシュや pull request の作成はしないでください。
+```
+
+スキルのファイルは、レッスン8の機能 PR に、フィルター機能、QA プロファイル、関連テストと一緒に含めます。この同じセッションで[レッスン 6 - Playwright MCP で機能を検証する][next-lesson]に進みます。
+
+## ほかのスキルの例
+
+これらのコミュニティの例は参考資料であり、追加のタスクではありません。採用する前に前提条件と動作を確認してください。
+
+- [コントリビューションのワークフロー: `make-repo-contribution`][contribution-example]。
+- [要件文書: `prd`][prd-example]。
+- [図と同梱のエクスポートスクリプト: `drawio`][drawio-example]。
+- [ブラウザーテスト: `webapp-testing`][browser-example]。
+
+上流のコントリビューション例の名前は `make-repo-contribution` です。古い Tailspin テンプレートでは、異なる名前の `make-contribution` を使用していました。このワークショップは、どちらのコントリビューション用スキルにも依存しません。
+
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/ja-jp/app/5-mcp-playwright.md b/docs/ja-jp/app/5-mcp-playwright.md
deleted file mode 100644
index 4cfea9b8..00000000
--- a/docs/ja-jp/app/5-mcp-playwright.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: "レッスン 5 - Playwright MCP server によるテスト"
-description: "Playwright MCP server を GitHub Copilot app に追加し、実際のブラウザーでフィルター機能を手動テストするようエージェントに依頼します。"
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-前のレッスンでは、プロジェクトの自動テストスイートを使ってフィルター機能を作成し、検証しました。テストによってコードの検証を自動化できますが、エージェント自身が動作を確認できるようにすることも効果的です。実際に作成している UI で問題を見つけた場合に、エージェントが対応できるようになります。MCP を使って AI エージェントに外部機能へのアクセスを提供する方法を確認し、Copilot が構築中のサイトを直接操作できるように Playwright MCP server を追加します。
-
-このレッスンでは、次の内容を学習します。
-
-- Model Context Protocol (MCP) の概要と、GitHub Copilot app での使用方法を理解する。
-- アプリの設定から Playwright MCP server を追加する。
-- エージェントにブラウザーを操作させ、フィルター機能を確認する。
-
-## シナリオ
-
-単体テストとエンドツーエンドテストは重要ですが、UI の更新を検証するには、実際に UI を操作する必要があります。変更作業をさらに自動化し、更新が期待どおりに動作するという確信を高めるために、ユーザーと同じ方法で Copilot が作業中の Web サイトを使用できるようにします。
-
-## Model Context Protocol (MCP) とは
-
-[Model Context Protocol (MCP)][mcp-blog-post] は、AI エージェントが外部のツールやサービスと通信するための手段を提供します。MCP を使うと、AI エージェントは外部のツールやサービスとリアルタイムで通信できます。その結果、最新情報へのアクセス (resources を使用) や、ユーザーに代わる操作 (tools を使用) が可能になります。
-
-これらの tools と resources には、AI エージェントと外部のツールやサービスをつなぐ MCP server を通じてアクセスします。MCP server は、AI エージェントと外部ツール (既存の API や NPM パッケージなどのローカルツール) 間の通信を管理します。各 MCP server は、AI エージェントがアクセスできる異なる tools と resources のセットを表します。
-
-よく使われる既存の MCP server には、次のものがあります。
-
-- [**GitHub MCP Server**](https://github.com/github/github-mcp-server): GitHub リポジトリを管理するための API セットにアクセスできます。AI エージェントは、新しいリポジトリの作成、既存のリポジトリの更新、Issue と pull request の管理などを行えます。
-- [**Playwright MCP Server**][playwright-mcp-server]: Playwright を使ったブラウザー自動化機能を提供します。AI エージェントは、Web ページへの移動、フォームへの入力、ボタンの選択などを行えます。
-
-さまざまな tools と resources にアクセスできる MCP server がほかにも多数あります。GitHub は、エコシステム内での発見と貢献を促進するために [MCP registry](https://github.com/mcp) をホストしています。
-
-> [!CAUTION]
-> MCP server は、プロジェクト内のほかの依存関係と同様に扱ってください。使用する前にソースコードを慎重に確認し、発行元を検証して、セキュリティ上の影響を考慮します。信頼できる MCP server だけを使用し、機密性の高いリソースや操作へのアクセスを許可するときは注意してください。
-
-## Playwright MCP server を追加する
-
-MCP server はアプリの設定から追加して管理します。アプリには一般的なサーバーのカタログが含まれているため、[Playwright MCP server][playwright-mcp-server] は数回の操作で追加できます。
-
-1. Ctrl+, を選択して、Copilot app の設定ページを開きます。
-2. **MCP servers** を選択します。
-3. 検索ダイアログに `Playwright` と入力します。
-4. **Popular MCP servers** の一覧から **Playwright** を選択します。
-5. **Add server** を選択し、利用可能な MCP server の一覧に追加します。
-6. Esc を選択して設定ダイアログを閉じます。
-
-これで Playwright MCP server を追加できました。
-
-## Playwright で機能を確認するよう Copilot に依頼する
-
-Playwright MCP server を使って機能を手動テストするよう Copilot に依頼します。
-
-1. 次のプロンプトを使い、新しい機能を検証するよう Copilot に依頼します。
-
- ```plaintext
- Start the dev server then use the Playwright MCP server to validate the functionality you just added exists. Use the details in the issue to ensure the newly added behavior matches the specs.
- ```
-
-Copilot は Playwright MCP server を通じてブラウザーを起動し、各手順を実行して、確認結果を報告します。タスクの実行中、システム上で実際にブラウザーが開く様子を確認できます。
-
-2. Issue の受け入れ条件と照らし合わせて概要を読みます。問題がある場合は、pull request を作成する前に追加の質問をするか、コードを修正するよう依頼します。
-3. 次のレッスンでこの作業を完了するため、セッションを開いたままにします。
-
-これで Copilot は、ユーザーと同じように機能を確認し、ブラウザーでも動作を検証しました。
-
-## まとめと次のステップ
-
-GitHub Copilot app から Playwright MCP server を使い、実際のブラウザーで機能を確認しました。学習した内容は次のとおりです。
-
-- Model Context Protocol (MCP) の概要と、アプリで MCP tools を利用する仕組みを学習した。
-- アプリの設定から Playwright MCP server を追加した。
-- エージェントにブラウザーを操作させ、フィルター機能を確認した。
-
-機能の構築と検証が完了し、動作することも確認できました。次は、**Agent Merge** を使って pull request の作成とマージをエージェントに任せ、機能をリリースします。[レッスン 6「Agent Merge によるマージ」][next-lesson]に進んでください。
-
-## リソース
-
-- [MCP とは何か、なぜ注目されているのか][mcp-blog-post]
-- [Microsoft Playwright MCP Server][playwright-mcp-server]
-- [GitHub Copilot app での MCP server の構成][customize-app]
-
-[next-lesson]: ../6-agent-merge/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
\ No newline at end of file
diff --git a/docs/ja-jp/app/6-agent-merge.md b/docs/ja-jp/app/6-agent-merge.md
deleted file mode 100644
index eefc96ae..00000000
--- a/docs/ja-jp/app/6-agent-merge.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: "レッスン 6 - Agent Merge によるマージ"
-description: "フィルター機能の pull request を作成して My work でレビューし、マージを妨げる問題の修正とマージを Agent Merge に任せて、段階的なマージ自動化の最上位まで進みます。"
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-フィルター機能の構築と検証が完了し、ブラウザーで動作することも確認できました。最後のステップはマージです。このハーネスではすでに2回マージしており、どちらも pull request を作成して github.com で自分でマージしました。今回は、pull request のライフサイクル全体をアプリ内から管理する **Agent Merge** に処理を任せます。
-
-このレッスンでは、次の内容を学習します。
-
-- Agent Merge の概要と、マージのライフサイクルを自動化する仕組みを学ぶ。
-- フィルター機能のセッションで Agent Merge を有効にする。
-- pull request の作成、CI の実行、すべて成功した後のマージを確認する。
-
-## シナリオ
-
-ここ数回のモジュールでは、コードの作成から Copilot による UI の直接検証まで、さまざまなレベルの自動化を確認しました。開発をさらに高速化するために、Tailspin Toys は審査および検証済みの pull request を自動的にマージする方法を検討しています。
-
-## Agent Merge の概要
-
-**Agent Merge** を使うと、Copilot app で pull request をマージするまでの最終工程を自動化できます。有効にすると、アプリのセッションが pull request を読み取り、失敗した CI チェックの修正、レビューコメントへの対応、必要に応じたリベースなど、マージを妨げる問題に対処します。そして GitHub で許可され次第、pull request をマージします。バックグラウンドで動作し、アプリを再起動しても継続し、pull request がマージされると自動的に無効になります。
-
-ここまでは、github.com で自分で **Merge pull request** を選択していました。Agent Merge はその責任をエージェントに移すため、エージェントが PR の完了までを管理している間に次のタスクへ進めます。作業のレビューと承認は引き続き自分で行い、エージェントには機械的な最終工程だけを任せます。
-
-## Agent Merge で PR を管理する
-
-コードを手動でレビューし、テストを実行し、Copilot による UI の検証も完了しました。新しいコードをコードベースにマージします。Agent Merge に PR を継続的インテグレーション (CI) のプロセスからマージまで管理させます。
-
-1. 前のモジュールでフィルター機能を追加していたセッションに戻ります。
-2. 右上隅にある **Create PR** の横のドロップダウンを選択します。
-3. **Agent merge** を選択して Agent Merge を有効にします。
-
- 
-
-4. ボタンのテキストが **Agent merge** に変わります。
-5. **Agent merge** ボタンを選択し、Agent Merge のプロセスを開始します。
-
-Copilot app が PR の作成と管理を開始します。最初にプロジェクトを調査して PR の最適な作成方法を判断し、新しい PR を作成します。
-
-しばらくすると、Copilot が再び作業を開始し、リポジトリ上ですべてのテストを実行する CI プロセスなど、PR の条件を確認します。ほかのチームメンバーによるレビュー、実行が必要なチェック (CI プロセス)、PR をマージできるかどうかのステータスを報告します。
-
-6. **Agent merge** の横にあるドロップダウンを選択してから **Merge pull request** を選択し、Agent Merge に pull request のマージを許可します。
-
- 
-
-7. すべての CI プロセスが成功すると、つまりテストに合格すると、Copilot が pull request をマージします。
-
-## まとめと次のステップ
-
-コードの生成、テストと検証、pull request のプロセスなど、開発プロセスの複数の部分を自動化しました。具体的には、次の作業を行いました。
-
-- Agent Merge の概要と、マージのライフサイクルを自動化する仕組みを学習した。
-- フィルター機能のセッションで Agent Merge を有効にした。
-- pull request の作成、CI の実行、すべて成功した後のマージを確認した。
-
-次は、エージェントと一緒に作業を計画して視覚化する、より高度な方法である**キャンバス**を確認します。[レッスン 7「キャンバスを使った計画」][next-lesson]に進んでください。
-
-## リソース
-
-- [GitHub Copilot app での Issue と pull request の管理][managing-issues-prs]
-- [GitHub Copilot app について][about-copilot-app]
-
-[next-lesson]: ../7-canvases/
-[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/ja-jp/app/6-mcp-playwright.md b/docs/ja-jp/app/6-mcp-playwright.md
new file mode 100644
index 00000000..a1a16b34
--- /dev/null
+++ b/docs/ja-jp/app/6-mcp-playwright.md
@@ -0,0 +1,90 @@
+---
+title: "レッスン 6 - Playwright MCP による機能の検証"
+description: "Customize から Playwright MCP を設定し、既存の機能用ワークツリーのフィルター機能をブラウザーで観察します。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+前のレッスンでは、プロジェクトのチェックを quality-checks スキルにまとめて実行しました。次は、エージェントがフィルター UI を直接観察できるよう、ブラウザーへのアクセスを提供します。同じフィルター機能のセッション、ワークツリー、ブランチを維持してください。このレッスンではブラウザーでの証拠を追加します。別の機能の実装、テストスイート全体の再実行、PR の作成は行いません。
+
+このレッスンでは、次の内容を学習します。
+
+- Model Context Protocol (MCP) の概要と、GitHub Copilot app での使用方法を理解する。
+- **Customize** から Playwright MCP server を追加する。
+- エージェントにブラウザーを操作させ、フィルター機能を確認する。
+
+## シナリオ
+
+単体テストとエンドツーエンドテストは重要ですが、UI の更新を検証するには、実際に UI を操作する必要があります。変更作業をさらに自動化し、更新が期待どおりに動作するという確信を高めるために、ユーザーと同じ方法で Copilot が作業中の Web サイトを使用できるようにします。
+
+## Model Context Protocol (MCP) とは
+
+[Model Context Protocol (MCP)][mcp-blog-post] は、AI エージェントが外部のツールやサービスと通信するための手段を提供します。MCP を使うと、AI エージェントは外部のツールやサービスとリアルタイムで通信できます。その結果、最新情報へのアクセス (resources を使用) や、ユーザーに代わる操作 (tools を使用) が可能になります。
+
+これらの tools と resources には、AI エージェントと外部のツールやサービスをつなぐ MCP server を通じてアクセスします。MCP server は、AI エージェントと外部ツール (既存の API や NPM パッケージなどのローカルツール) 間の通信を管理します。各 MCP server は、AI エージェントがアクセスできる異なる tools と resources のセットを表します。
+
+よく使われる既存の MCP server には、次のものがあります。
+
+- [**GitHub MCP Server**](https://github.com/github/github-mcp-server): GitHub リポジトリを管理するための API セットにアクセスできます。AI エージェントは、新しいリポジトリの作成、既存のリポジトリの更新、Issue と pull request の管理などを行えます。
+- [**Playwright MCP Server**][playwright-mcp-server]: Playwright を使ったブラウザー自動化機能を提供します。AI エージェントは、Web ページへの移動、フォームへの入力、ボタンの選択などを行えます。
+
+さまざまな tools と resources にアクセスできる MCP server がほかにも多数あります。GitHub は、エコシステム内での発見と貢献を促進するために [MCP registry](https://github.com/mcp) をホストしています。
+
+> [!CAUTION]
+> MCP server は、プロジェクト内のほかの依存関係と同様に扱ってください。使用する前にソースコードを慎重に確認し、発行元を検証して、セキュリティ上の影響を考慮します。信頼できる MCP server だけを使用し、機密性の高いリソースや操作へのアクセスを許可するときは注意してください。
+
+## Playwright MCP server を追加する
+
+現在の [App のカスタマイズドキュメント][customize-app]では、サイドバーの **Customize** で MCP の検索と管理を行います。リポジトリや Copilot CLI 向けに設定された MCP server は App でも利用できる場合があります。重複して追加する前に、インストール済みのサーバーを確認してください。
+
+1. サイドバーで **Customize** を選択します。
+2. **MCP** を選択し、**Installed** で既存の Playwright サーバーを確認します。
+3. 必要な場合は利用可能なサーバーから **Playwright** を探すか、発行元が文書化したカスタムサーバーの追加手順を使用します。
+4. 発行元、設定、インストールの確認内容をレビューしてから承認します。画面の案内に従ってサーバーを追加してください。組織のポリシーや前提条件の不足により、セットアップがブロックされる場合があります。
+5. **Interactive** モードを維持して既存のフィルター機能のセッションに戻ります。検証を依頼する前に Playwright MCP のブラウザーツールが利用できることを確認します。セットアップの問題を回避するために新しい機能用ワークツリーを作成しないでください。
+
+セットアップが失敗した場合は、ツールなしでブラウザーを操作したという主張を受け入れず、設定や権限の問題を解決します。ブラウザーが画面に表示されるかどうかはサーバー設定によります。実際のツールアクティビティと観察結果が証拠です。
+
+## Playwright で機能を確認するよう Copilot に依頼する
+
+レッスン4で保存した実際の Issue の URL と承認済みの追加の取り決めを使用します。エージェントがサーバーを起動する前に、以前のレッスンで手動起動した開発サーバーを停止してください。エージェントはテスト対象のチェックアウトとサーバーを特定する必要があります。
+
+1. 次のプロンプトを使い、新しい機能を検証するよう Copilot に依頼します。
+
+ ```plaintext
+ 設定済みの Playwright MCP server を使用し、この Issue に照らしてフィルター機能を観察してください: 。計画時に承認した追加の取り決めは次のとおりです: <合意した追加の取り決めを貼り付けるか、none と記入>。このフィルター機能のワークツリーとブランチを維持してください。
+
+ チェックアウトを特定してその開発サーバーを起動し、実際のブラウザーツールで、必要な複数カテゴリーの選択、パブリッシャーによるフィルター、組み合わせたフィルター、アクセシブルな操作部品、合意したクリア操作や結果が空の場合の動作を試してください。失敗やブロックされたチェックを含め、条件に対する観察結果を報告してください。観察していない動作を確認済みと主張しないでください。
+
+ この段階はブラウザーでの観察であり、自動テスト全体の再実行ではありません。アプリケーションコード、テスト、スキル、エージェントプロファイルの変更、コミット、プッシュ、PR の作成はしないでください。MCP ツールや前提条件の不足はブロックとして報告し、インストールの前に確認してください。別のチェックアウトのサーバーの再利用や無関係なプロセスの停止はしないでください。完了したら、自分で起動したサーバーだけを停止してください。
+ ```
+
+Playwright MCP のツール呼び出し、テスト対象の URL、報告されたブラウザーでの観察結果を確認します。ソースコードや以前の E2E 結果だけに基づく説明では MCP の使用を実証できません。
+
+2. Issue と承認した追加の取り決めに照らして概要を読みます。不具合がある場合は、範囲を絞った修正を別途承認し、変更した差分をレビューして、関連する自動チェックとブラウザー観察を繰り返します。修正前の証拠は修正後のリビジョンを証明しません。
+3. エージェントが自分で起動したサーバーを停止したことを確認します。レッスン7で QA プロファイルを作成する前に、このフィルター機能のセッションを開いたまま **Interactive** モードを維持します。
+
+この段階で得るのは直接観察の結果であり、自動テストのカバレッジの代わりではありません。失敗やブロックされた観察は、QA に引き継ぐため明示しておきます。
+
+## まとめと次のステップ
+
+GitHub Copilot app から Playwright MCP server を使い、実際のブラウザーで機能を確認しました。学習した内容は次のとおりです。
+
+- Model Context Protocol (MCP) の概要と、アプリで MCP tools を利用する仕組みを学習した。
+- **Customize** から Playwright MCP server を設定した。
+- エージェントにブラウザーを操作させ、フィルター機能を確認した。
+
+次は、専門家のプロファイルで要件、ブラウザー観察、カバレッジ、スキルを組み合わせます。この同じセッションで[レッスン 7「QA エージェントの作成と使用」][next-lesson]に進んでください。機能の PR はまだ作成しません。
+
+## リソース
+
+- [MCP とは何か、なぜ注目されているのか][mcp-blog-post]
+- [Microsoft Playwright MCP Server][playwright-mcp-server]
+- [GitHub Copilot app での MCP server の構成][customize-app]
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
+[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
\ No newline at end of file
diff --git a/docs/ja-jp/app/7-canvases.md b/docs/ja-jp/app/7-canvases.md
deleted file mode 100644
index 9af8465a..00000000
--- a/docs/ja-jp/app/7-canvases.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: "レッスン 7 - キャンバスを使った計画"
-description: "GitHub Copilot app でエージェント主導の共有キャンバスを作成し、エージェントと一緒に作業を計画して追跡します。"
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-ここまでは、チャットを通じてエージェントを指示してきました。しかし、多くの作業は会話の中ではなく、ボード、ドキュメント、チェックリスト上で行われます。**キャンバス**は、まさにそのような作業のために、アプリ内でユーザーとエージェントが共有できる領域です。このレッスンでは、ここまで取り組んできたバックログの計画と追跡に使用する、シンプルなキャンバスを作成します。
-
-このレッスンでは、次の内容を学習します。
-
-- キャンバスの概要と使用する場面を理解する。
-- バックログをトリアージする共有 Kanban ボードのキャンバスを作成する。
-- キャンバスをリポジトリに保存し、チーム向けにマージする。
-- 新しいセッションでキャンバスを開き、そこから作業を開始する。
-
-## シナリオ
-
-Issue の一覧は、どのような状況でも負担に感じることがあります。Tailspin Toys の開発者は、Issue をすばやくトリアージし、Copilot app で作業を開始できるツールを探しています。
-
-## キャンバスとは
-
-[キャンバス][canvas-docs]は、計画、トリアージボード、リリースチェックリスト、ダッシュボード、ドキュメントなどの作業成果物を扱う、共有の対話型領域です。チャットは意図の説明や曖昧さの検討に適していますが、多くの作業は具体的な*領域*上で行われます。キャンバスを使うと、その領域でエージェントと直接共同作業できます。
-
-キャンバスは**双方向**です。エージェントが作業中にキャンバスを更新できる一方で、ユーザーも同じ領域を編集できます。キャンバスを作成すると、エージェントはプロンプトとワークフローに基づいて内容を構築します。その後も、機能の追加、削除、修正を依頼できます。作成したキャンバスは、アプリの右側のパネルに開きます。
-
-一般的な例は次のとおりです。
-
-- 1日の計画を立て、Issue と pull request に優先順位を付けるための **Markdown canvases**。
-- ユーザーとエージェントがカードを追加し、作業を列間で移動する **Agentic kanban boards**。
-- リポジトリの重要な Issue と繰り返し現れるテーマをまとめる **Issue triage boards**。
-
-## キャンバスを使用する理由
-
-タスクに構造、反復、検証が必要で、チャットだけでは不十分な場合はキャンバスを使用します。キャンバスでは次のことができます。
-
-- ワークフローに合った実際の成果物に、エージェントの作業を結び付ける。
-- 共有領域で作業を直接調整または修正し、その変更を基にエージェントに作業を続けさせる。
-- チャットの応答だけでなく、成果物への目に見える変更として進捗を確認する。
-
-## 作業を追跡するキャンバスを作成する
-
-星評価、ドキュメント標準、フィルター機能をすべてマージし、多くの成果をリリースしました。しかし、バックログにはまだ項目が残っています。作業をすばやくトリアージするためのキャンバスを作成します。
-
-1. GitHub Copilot app に戻ります。アプリを閉じている場合は開きます。
-2. **Home screen** を選択します。
-3. リポジトリに `tailspin-toys` が選択されていることを確認します。
-4. プロンプトボックスで次のプロンプトを使用し、要件を満たすキャンバスを作成します。
-
- ```plaintext
- Create a basic Kanban board canvas that allows me to quickly triage work. Highlight the three issues which are most likely to need attention right now, with the remainder in a second section down below. The top three cards should include a description of the issue's content and a justification of why they're at the top of the list. Each issue should have a button that allows me to add it to the current context for the current session so I can get to work on it straightaway.
- ```
-
-Copilot がキャンバスの作成を開始します。
-
-> [!NOTE]
-> 作成には数分かかります。複雑なタスクであるため、最初のバージョンでは満足できない場合があります。理想のツールになるまで、プロンプトで構築を続けるよう依頼できます。
-
-## キャンバスを保存してリポジトリにマージする
-
-キャンバスは、指示ファイルやスキルと同様に、リポジトリのアセットにできます。Copilot にリポジトリへの追加とマージを依頼し、チーム全体で使用できるようにします。
-
-1. 同じセッションで、次のプロンプトを使ってキャンバスをリポジトリに保存するよう Copilot に依頼します。
-
- ```plaintext
- Let's save this canvas definition to the repository so I can share it with my development team
- ```
-
-2. Copilot がキャンバスファイルを保存したら、右上隅にある **Create PR** の横のドロップダウンを選択します。
-3. **Agent merge** を選択して Agent Merge を有効にします。
-
- 
-
-4. ボタンのテキストが **Agent merge** に変わります。
-5. **Agent merge** ボタンを選択し、Agent Merge のプロセスを開始します。
-
-Copilot app が PR の作成と管理を開始します。最初にプロジェクトを調査して PR の最適な作成方法を判断し、PR を作成します。
-
-しばらくすると、Copilot が再び作業を開始し、リポジトリ上ですべてのテストを実行する CI プロセスなど、PR の条件を確認します。ほかのチームメンバーによるレビュー、実行が必要なチェック (CI プロセス)、PR をマージできるかどうかのステータスを報告します。
-
-6. **Agent merge** の横にあるドロップダウンを選択してから **Merge pull request** を選択し、Agent Merge に pull request のマージを許可します。
-
- 
-
-7. すべての CI プロセスが成功するまで待ちます。成功すると、Copilot が pull request を自動的にマージします。
-
-これでチーム用の新しい共有キャンバスを作成できました。
-
-## キャンバスで作業する
-
-キャンバスを作成できたので、新しいセッションを開始して使用します。
-
-1. Copilot app で **tailspin-toys** の横にある **New session** を選択し、新しいセッションを開始します。
-2. 次のプロンプトを使い、トリアージ用キャンバスを開くよう Copilot に依頼します。
-
- ```plaintext
- Open the triage issues canvas
- ```
-
-3. 作成したキャンバスが新しいセッションで開いたことを確認します。
-4. 最も関心のある Issue の1つで **Add to current context** を選択します。
-5. Copilot が Issue の作業を開始します。
-
-これで、作成したキャンバスを使って開発プロセスを効率化できました。
-
-## まとめと次のステップ
-
-ユーザーとエージェントが共同作業できる共有領域を作成しました。具体的には、次の作業を行いました。
-
-- キャンバスの概要と使用する場面を学習した。
-- エージェントと共有の Kanban トリアージボードのキャンバスを作成した。
-- Agent Merge を使ってキャンバスをリポジトリに保存し、マージした。
-- 新しいセッションでキャンバスを開き、そこから作業を開始した。
-
-バックログを追跡できるようになったので、ここまで構築した内容と今後の進め方を振り返ります。[レッスン 8「振り返りと次のステップ」][next-lesson]に進んでください。
-
-## リソース
-
-- [GitHub Copilot app での canvas extension の操作][canvas-docs]
-- [Awesome Copilot の Canvases][awesome-copilot-canvases]
-- [GitHub Copilot app について][about-copilot-app]
-
-[next-lesson]: ../8-review/
-[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
-[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/ja-jp/app/7-qa-agent.md b/docs/ja-jp/app/7-qa-agent.md
new file mode 100644
index 00000000..751b156f
--- /dev/null
+++ b/docs/ja-jp/app/7-qa-agent.md
@@ -0,0 +1,73 @@
+---
+title: "レッスン 7 - QA エージェントの作成と使用"
+description: "テストのカバレッジ、quality-checks スキル、ブラウザーで直接得た証拠を組み合わせる、要件を起点とした QA プロファイルを作成します。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+繰り返し実行できるチェックを実行し、Playwright MCP でフィルター機能を確認しました。次は**QA カスタムエージェント**を作成し、要件、カバレッジ、ブラウザーの証拠をまとめます。フィルター機能のセッション、チェックアウト、ブランチを維持してください。機能の PR はレッスン8で扱います。
+
+## QA プロファイルを作成する
+
+**Interactive** モードを維持します。プロファイルは専門家の役割と指示を定義し、スキルは再利用可能なタスクの指示、スクリプト、リソースをまとめます。QA エージェントは、自分で作成したスキルと設定済みの MCP ツールを置き換えるのではなく、利用します。
+
+次のプロンプトを送り、実行前に定義を確認します。
+
+```plaintext
+.github/agents/qa.agent.md に再利用可能な QA カスタムエージェントを作成してください。まずリポジトリの指示、package.json、テスト設定、.github/skills/quality-checks/SKILL.md を確認してください。プロファイルには有効な YAML フロントマターを付け、name を QA とし、description で使う場面を説明してください。モデルを固定したり tools リストを追加したりせず、ハーネスで利用可能なツールと権限を継承してください。エージェント定義だけを作成し、実行前に内容を確認できるよう停止してください。
+
+エージェントの指示では、すべての QA タスクを Issue とユーザーが提供した承認済みの受け入れ条件から始めることを必須にしてください。実装ではなく、これらの要件を正しい基準として扱ってください。要件が不足しているか曖昧な場合は質問してください。機能と既存のテストを確認し、各条件を適切な自動テストのカバレッジと観察可能な動作に対応付けてください。
+
+設定済みの Playwright MCP サーバーによるブラウザーの直接検証と、既存の quality-checks スキルおよび同梱スクリプトによる lint、単体テスト、エンドツーエンドテスト、型チェックの実行を必須にしてください。スキルが自動検出されていなければ明示的に読んでください。スキル、MCP ツール、前提条件、アクセスが不足している場合は、実行が阻害されていると報告してください。断りなく別のワークフローに置き換えたり、スキップしたチェックを成功扱いにしたりしないでください。テスト対象のチェックアウトとサーバーを特定し、別のワークツリーのサーバーを再利用せず、エージェントが起動したサーバーだけを停止してください。インストールや別のプロセスの停止前には確認してください。
+
+QA エージェントは、リポジトリの指示に従い、実際にカバレッジが不足している箇所に必要最小限のテストを追加できるようにしてください。カバレッジがすでに十分なら、追加のテストがないことも妥当です。アサーションを弱めたり、失敗するテストを無効にしたり、コードに合わせて受け入れ条件を変えたり、私の承認なしにアプリケーションコードを変更したりしないでください。変更後は影響するチェックを再実行し、変更後のリビジョンの最終検証を完了してください。各条件を証拠と成功・失敗・阻害の状態に対応付け、追加したテストまたは追加不要だった理由、4つすべてのチェック結果、未解決の不具合を示す簡潔な報告を必須にしてください。GO には必要なチェックと証拠がすべてそろっている必要があり、そうでなければ理由とともに NO-GO を報告してください。QA 中はブランチの変更、コミット、プッシュ、PR の作成やマージ、追加のエージェントやスキルの作成はしないでください。
+```
+
+## プロファイルを確認する
+
+**Changes** またはファイルのレビューパネルで `.github/agents/qa.agent.md` を開きます。`description` は必須です。このレッスンでは、わかりやすい `name` として `QA` も指定します。固定された `model` や、勝手に作られたツール一覧がないことを確認します。`tools` を省略すると利用可能なツールを継承しますが、ハーネスの権限を回避するわけではありません。本番用のプロファイルでは、意図的にツールを制限できます。
+
+指示が要件から始まり、実際の MCP ブラウザー操作とスキルのスクリプトを要求し、妥当なテスト追加だけを許可し、阻害要因を正直に報告することを確認します。専門家のプロファイルもスキルも、別のコンテキストウィンドウやほかのエージェントのオーケストレーションを必要としません。
+
+## Issue に対して QA を実行する
+
+実行プロンプトは、プロファイルを読む既定のエージェントではなく、選択した **QA** カスタムエージェントに送るものです。同じフィルター機能のチェックアウトとブランチを維持します。
+
+1. 現在のセッションで、[App のカスタマイズドキュメント][customize-app]に従い、プロンプトボックスのエージェント選択画面を開くか、`/agent` を入力します。
+2. **QA** を選択し、実行プロンプトを送る前に、App がアクティブなエージェントとして **QA** を明示していることを確認します。
+3. **QA** が一覧にない場合や、アクティブであることを確認できない場合は、このワークツリーとブランチを保ったまま一時停止し、講師に相談してください。新しい機能セッションを作成したり、根拠のない再読み込み手順を使ったり、既定のエージェントに `qa.agent.md` を読むよう依頼する方法で代用したりしてはいけません。
+
+ドキュメントに記載された選択画面はセッション中に利用できますが、新しく作成したリポジトリのプロファイルが検出されるかどうかは App のバージョンによる場合があります。ファイルを書いたことを、有効化の証拠として扱ってはいけません。
+
+両方のプレースホルダーを、実際のフィルター機能の Issue の URL と、レッスン4で承認した追加の取り決めに置き換えます。Issue だけで要件が十分な場合は `none` を使います。前のエージェントの記憶に依存してはいけません。
+
+```plaintext
+次の Issue に照らしてフィルター機能を検証してください: 。計画時に承認した追加の受け入れ条件は次のとおりです: <合意した追加の取り決めを貼り付けるか、なければ none と記入>。
+
+Playwright MCP サーバーで動作を検証し、テストのカバレッジを確認して、不足するカバレッジに対してだけテストを追加し、quality-checks スキルを通じて検証を実行してください。証拠、チェック結果、阻害要因を報告してください。私の承認なしにアプリケーションコードを変更しないでください。コミットや pull request を作成しないでください。
+```
+
+## 証拠をレビューする
+
+レポートを Issue に照らし合わせます。各条件には、適切な自動テストのカバレッジと観察可能な動作が必要です。実際の Playwright MCP ツールの操作、チェックアウトとサーバーの識別情報、4つすべてのスキルスクリプトの結果を確認してください。ブラウザーチェックと自動 E2E で、古いサーバーや別のチェックアウトを再利用してはいけません。
+
+追加されたテストをレビューします。アサーションを弱めず、実際の不足を埋める必要があります。カバレッジが十分なら、新しいテストがないことが適切です。阻害や失敗による **NO-GO** の判定は有効な結果であり、証拠を省く許可ではありません。
+
+QA がアプリケーションの不具合を見つけた場合は、範囲を絞った修正を別途承認し、変更後のリビジョンで影響するチェックとブラウザー観察を再実行します。不足する前提条件やツールには、明示的な対処が必要です。古い証拠を変更後のコードの証明として扱ってはいけません。
+
+## チェックポイントを保存する
+
+QA が完了したら、レポート、Issue の URL、承認した追加の取り決め、テストしたリビジョンを利用できる状態にします。同じセッションで、ドキュメントに記載されたエージェント選択画面を使って通常の Copilot エージェントに戻り、**QA** が選択されていないことを確認します。同じチェックアウトとブランチを維持し、別の機能セッションの開始やワークツリーの再読み込みはしないでください。通常のエージェントの選択肢が見つからない場合は、QA にコミットを指示せず、一時停止して講師に相談してください。
+
+プロファイル、テストの変更、得られた証拠をレビューしたら、その QA のコンテキストとともに、通常のエージェントへチェックポイントのリクエストを送信します。
+
+```plaintext
+現在の差分をレビューし、QA エージェント定義と承認済みのテスト変更のチェックポイントコミットを作成してください。既存のフィルター機能のブランチを維持してください。プッシュや pull request の作成はしないでください。
+```
+
+フィルター機能、スキル、QA プロファイル、テスト、現在の検証の証拠をそろえて、[レッスン 8 - 機能の PR を作成してマージする][next-lesson]に進みます。
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/ja-jp/app/8-create-pull-request.md b/docs/ja-jp/app/8-create-pull-request.md
new file mode 100644
index 00000000..76b5db79
--- /dev/null
+++ b/docs/ja-jp/app/8-create-pull-request.md
@@ -0,0 +1,90 @@
+---
+title: "レッスン 8 - 機能の PR の作成とマージ"
+description: "フィルター機能、スキル、QA プロファイル、テストをまとめてレビューし、PR 3 を作成して Agent Merge を明示的に承認します。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+フィルター機能の実装、quality-checks スキル、QA プロファイル、関連するテストを、1つのブランチにチェックポイントとして保存しました。これらをまとめてレビューし、現在の QA の証拠を使って PR 3 を準備します。星評価と指示の PR はすでに明示的にマージしました。今回は、別の機能やブランチとしてではなく、PR ワークフローの中で **Agent Merge** を使用します。
+
+このレッスンでは、次の内容を学習します。
+
+- Agent Merge の概要と、マージのライフサイクルを自動化する仕組みを学ぶ。
+- 機能の PR 全体と検証の証拠を確認する。
+- レビュー後にのみ Agent Merge を承認し、PR のマージを確認する。
+
+## シナリオ
+
+ここ数回のモジュールでは、コードの作成から Copilot による UI の直接検証まで、さまざまなレベルの自動化を確認しました。開発をさらに高速化するために、Tailspin Toys は審査および検証済みの pull request を自動的にマージする方法を検討しています。
+
+## Agent Merge の概要
+
+**Agent Merge** を使うと、Copilot app で pull request をマージするまでの最終工程を自動化できます。有効にすると、アプリのセッションが pull request を読み取り、失敗した CI チェックの修正、レビューコメントへの対応、必要に応じたリベースなど、マージを妨げる問題に対処します。そして GitHub で許可され次第、pull request をマージします。バックグラウンドで動作し、アプリを再起動しても継続し、pull request がマージされると自動的に無効になります。
+
+ここまでは、自分で **Merge pull request** を選択していました。Agent Merge に任せることもできますが、コードの編集やマージには引き続き明示的な承認が必要です。マージを許可する前に、許可される操作と作業内容をレビューしてください。
+
+## マイルストーン全体をレビューする
+
+レッスン4～7のフィルター機能のセッションを維持します。最新のチェックポイントだけでなく、`main` に対するブランチの差分全体を確認してください。フィルター機能、`.github/skills/quality-checks/SKILL.md`、同梱のスクリプト、`.github/agents/qa.agent.md`、関連するテストが含まれているはずです。
+
+コミットや PR 操作を依頼する前に、エージェント選択で **QA** から通常の Copilot エージェントに戻し、**Interactive** モードを維持します。QA プロファイルの役割は検証であり、リリースではありません。エージェントを変更しても、フィルター機能のセッション、チェックアウト、ブランチは変更しないでください。
+
+このワークショップでは、機能の作業と再利用可能な品質管理の仕組みを意図的に1つの PR にまとめます。実際のチームでは分割する場合もありますが、ここではブランチの積み重ねや追加の PR を使わず、チェックポイントコミットでレビュー可能な段階を残します。
+
+レッスン7の QA レポートをレビューします。4つすべてのチェックと関連するブラウザー観察が完了し、提出する最終リビジョンを対象としている場合にのみ証拠を再利用してください。コード変更、競合の解消、CI の修正でテスト対象が変わった場合は、関連するチェックとブラウザー観察を再実行し、証拠を更新します。失敗やブロックを示す **NO-GO** レポートは、マージの承認ではありません。
+
+差分と証拠が整ったら、次を送信します。
+
+```plaintext
+main に対するフィルター機能のブランチの差分全体を、フィルター機能、quality-checks スキルとスクリプト、QA エージェント定義、関連するテストも含めてレビューしてください。Issue の条件、承認済みの追加の取り決め、現在の QA の証拠をまとめてください。最終リビジョンにも適用できる場合にのみ検証を再利用し、古い証拠、不足、失敗があれば続行前に報告してください。
+
+レビュー済みの変更と検証が整っていれば、このマイルストーンの承認済みの変更で残っているものをコミットし、このブランチをプッシュして、リポジトリの PR テンプレートと実際のフィルター機能の Issue の URL を使い、main を対象とする機能の PR を1つ作成してください。このブランチのチェックポイント履歴を保持してください。コントリビューション用スキルの使用、別のブランチや PR の作成、マージはまだ行わないでください。
+```
+
+**My work** で PR を開き、**Files changed**、説明、レビュー、チェック結果を確認します。Tailspin Toys 自体のワークフローファイルと必須チェックを確認してください。すべてのローカルチェックやブラウザー観察が CI で実行されるとは限りません。ワークショップ公開用の Astro ビルドやリンクチェッカーは別のリポジトリのもので、この機能を検証するものではありません。
+
+## Agent Merge で PR を管理する
+
+既存の PR をレビューした後、この同じセッションで Agent Merge を設定します。2つ目の PR を作成しないでください。
+
+1. フィルター機能のセッションに戻り、PR 3 にリンクされていることを確認します。
+2. 右上隅の PR 操作のドロップダウンを開きます。PR がまだない場合は **Create PR** の横にあります。PR がリンクされるとラベルが変わる場合があります。
+3. **Agent merge** を選択して Agent Merge を有効にします。
+
+4. **Address reviews**、**Fix CI failures**、**Resolve conflicts**、**Merge pull request** など、利用可能な権限を確認します。指摘事項や検証が未解決の間はマージ権限を無効のままにします。
+5. 開始前に次の範囲と承認の指示を送信してから、**Agent merge** を選択します。
+
+ ```plaintext
+ この既存のフィルター機能の PR を Agent Merge で管理してください。レビューや CI の阻害要因には、この PR の範囲内でのみ対処してください。テストや要件を弱めず、無関係な変更やインストールの前には確認してください。テスト済みリビジョンに変更があれば、関連するチェックとブラウザーでの証拠を更新する必要があります。古い QA 結果を変更後のコードの証明にしないでください。
+
+ 最終差分と証拠をレビューした後で私が Merge pull request を明示的に有効にするまで、マージしないでください。別の PR の作成やキャンバスタスクの開始はしないでください。
+ ```
+
+6. 追加の変更と更新された結果をレビューします。最終差分を承認し、必須の CI とレビューが成功して、QA の証拠がそのリビジョンに適用できることを確認したら、**Agent merge** の横のドロップダウンから **Merge pull request** を選択し、マージを明示的に承認します。
+
+ 
+
+7. GitHub で PR 3 が単にマージ可能または待機中ではなく **Merged** と表示されることを確認します。Agent Merge はリポジトリの保護や権限不足を回避しません。続行前にそれらの阻害要因を解消してください。
+
+そのマージが完了してから、キャンバスのマイルストーンを開始します。レッスン9では新しいワークツリーを作成し、セッションのブランチを最新の `origin/main` まで fast-forward することで、マージ済みの機能全体を含む状態からキャンバスの作業を始めます。
+
+## まとめと次のステップ
+
+コードの生成、テストと検証、pull request のプロセスなど、開発プロセスの複数の部分を自動化しました。具体的には、次の作業を行いました。
+
+- Agent Merge の概要と、マージのライフサイクルを自動化する仕組みを学習した。
+- フィルター機能、スキル、QA プロファイル、テストの差分全体を PR 3 としてレビューした。
+- 現在の QA の証拠を再利用し、CI を確認して、Agent Merge を明示的に承認した。
+
+次は、エージェントと一緒に作業を計画して視覚化する、より高度な方法である**キャンバス**を確認します。[レッスン 9「トリアージキャンバスの作成」][next-lesson]に進んでください。
+
+## リソース
+
+- [GitHub Copilot app での Issue と pull request の管理][managing-issues-prs]
+- [GitHub Copilot app について][about-copilot-app]
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-canvases/
+[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/ja-jp/app/8-review.md b/docs/ja-jp/app/8-review.md
deleted file mode 100644
index cbcdcf44..00000000
--- a/docs/ja-jp/app/8-review.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: "レッスン 8 - 振り返りと次のステップ"
-description: "GitHub Copilot app のハーネスを振り返り、繰り返し発生する作業を自動化して、次に学ぶ内容を確認します。"
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-ここ数回のレッスンでは、GitHub Copilot app を使い、アイデアから機能のマージまでを実践しました。取り組んだ内容は次のとおりです。
-
-- リポジトリを接続し、アプリのワークスペースと用意されたバックログを確認した。
-- 直接指定したタスクと Issue からセッションを開始し、Plan モードと Autopilot モードでエージェントの動作を制御した。
-- カスタム指示と再利用可能なスキルでエージェントをガイドした。
-- Playwright MCP server を使い、実際のブラウザーで作業をテストした。
-- 共有キャンバスでエージェントと共同作業した。
-- github.com で自分でマージする方法から、**Agent Merge** に pull request のマージを任せる方法まで、段階的なマージ自動化を使って変更をリリースした。
-
-繰り返し発生する作業を自動化し、ベストプラクティスと今後の進め方を確認します。
-
-## 繰り返し発生する作業を自動化する
-
-アプリでは、**automations** を使って、スケジュールまたはオンデマンドでエージェントを実行できます。新しい Issue のトリアージや最近のアクティビティの振り返りなど、定型的なタスクに適しています。シンプルで破壊的でない automation を作成します。
-
-1. サイドバーで **Automations** を選択してから **New automation** を選択します。
-2. `Recap my recent work` などの名前を付けます。
-3. トリガーを選択します。**Manual** はオンデマンドで実行し、**On a schedule** は自動的に実行し、**When an issue is created** は新しい Issue に反応します。このレッスンでは **Manual** を選択します。
-4. automation が何も変更しないように、次の例のような読み取り専用のプロンプトを入力します。
-
- ```plaintext
- Summarize the pull requests merged in this repository over the last week, and list any issues still open in the backlog.
- ```
-
-5. プロジェクト (Tailspin Toys リポジトリ) を選択し、automation を作成します。
-6. オンデマンドで実行し、結果を確認します。
-
-> [!TIP]
-> Automations はローカルまたはクラウドで実行できます。スケジュールに従って無人で実行する場合は、**Run in the cloud** を有効にし、automation に使用を許可する **Tools** を選択します。出力を信頼できるようになるまでは、スケジュールされた automations の範囲を限定し、破壊的でないものにしてください。
-
-## ベストプラクティス
-
-AI ツールを使用するときは、その周辺の基盤が出力の品質を左右します。このワークショップでは、指示ファイル、スキル、カスタムエージェントがそれぞれ役割を果たしました。これらに投資し、セッション間で再利用してください。
-
-タスクに合わせて**モードとモデル**を選択します。構築前にアプローチを検討するには **Plan**、対象を絞った変更で作業に関与し続けるには **Interactive**、範囲が明確で分離されたタスクに限って **Autopilot** を使用します。定型的な編集には高速なモデルを選び、複雑な作業には推論能力が高く、より多くの推論を行うモデルを選びます。
-
-基盤と同じくらい、コンテキストも重要です。何を、なぜ、どのように構築するかを明確に説明すると、出力は大きく変わります。アイデアを本格的なセッションに移す前に範囲を決める場所として、Quick chats が役立ちます。
-
-## さらに確認する機能
-
-コアワークフローを学習しました。ほかにも確認する価値がある機能があります。
-
-- 完全なセッションを必要としない、その場限りの簡単な質問に使用する **Quick chats**。
-- 構築前に問題について対話し、重要なフィードバックを得るための **Rubber duck**。
-- ロール、その tools、指示をまとめ、繰り返し使用する専門的な作業に対応する [**Custom agents**][custom-agents]。
-- セッションで起きたことの記録を生成する [`/chronicle`][chronicle]。
-- Ollama、Foundry Local、LM Studio を介したローカルモデルなど、独自のプロバイダーのモデルを使用する [Bring your own key (BYOK)][byok]。
-- GitHub がホストする分離環境でセッションを実行する [Cloud sandboxes][sandboxes]。
-- アプリを直接リポジトリ、セッション、プロンプトの画面で開く [Deep links][deep-links]。
-
-## 次のステップ
-
-ツールを使いこなす最良の方法は、使い続けることです。実稼働コード、趣味のコード、長年構想していながら構築できていなかった小さなアプリなどに活用してください。学んだことをチームと共有し、チームからも学びましょう。そして、引き続きドキュメントを確認してください。
-
-GitHub Copilot エコシステムをさらに学ぶには、[VS Code ハーネス](../../vscode/)、[Copilot CLI ハーネス](../../cli/)、[Cloud agent ハーネス](../../cloud/)を確認してください。
-
-## リソース
-
-- [GitHub Copilot app について][about-copilot-app]
-- [GitHub Copilot app の概要][getting-started]
-- [GitHub Copilot app のカスタマイズ][customize]
-- [Automations の使用][using-automations]
-- [Canvas extensions の操作][canvas-docs]
-- [クラウドサンドボックスとローカルサンドボックスについて][sandboxes]
-
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
-[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
-[customize]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
-[using-automations]: https://docs.github.com/copilot/how-tos/github-copilot-app/using-automations
-[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
-[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
-[chronicle]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/chronicle
-[custom-agents]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
-[byok]: https://docs.github.com/copilot/how-tos/github-copilot-app/use-byok-models
-[deep-links]: https://docs.github.com/copilot/how-tos/github-copilot-app/open-with-deep-links
\ No newline at end of file
diff --git a/docs/ja-jp/app/9-canvases.md b/docs/ja-jp/app/9-canvases.md
new file mode 100644
index 00000000..5e31ecea
--- /dev/null
+++ b/docs/ja-jp/app/9-canvases.md
@@ -0,0 +1,148 @@
+---
+title: "レッスン 9 - トリアージキャンバスの作成"
+description: "リポジトリに保存するトリアージキャンバスを作成・レビューして PR 4 をマージし、別の機能に着手せずキャンバスを再度開いて Issue のコンテキストを追加します。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+ここまでは、チャットを通じてエージェントを指示してきました。しかし、多くの作業は会話の中ではなく、ボード、ドキュメント、チェックリスト上で行われます。**キャンバス**は、まさにそのような作業のために、アプリ内でユーザーとエージェントが共有できる領域です。このレッスンでは、ここまで取り組んできたバックログの計画と追跡に使用する、シンプルなキャンバスを作成します。
+
+このレッスンでは、次の内容を学習します。
+
+- キャンバスの概要と使用する場面を理解する。
+- バックログをトリアージする共有 Kanban ボードのキャンバスを作成する。
+- キャンバスをリポジトリに保存し、チーム向けにマージする。
+- 別の機能を実装せずにキャンバスを再度開き、Issue のコンテキストを追加する。
+
+## シナリオ
+
+Issue の一覧を見ると、負担に感じることがあります。Tailspin Toys の開発者は、Issue をトリアージし、その詳細をセッションのコンテキストに追加するツールを求めています。コンテキストの追加は Issue の実装を許可するものではありません。この演習は5つ目の PR ではなく、再利用可能なボードの完成で終わります。
+
+## キャンバスとは
+
+[キャンバス][canvas-docs]は、計画、トリアージボード、リリースチェックリスト、ダッシュボード、ドキュメントなどの作業成果物を扱う、共有の対話型領域です。チャットは意図の説明や曖昧さの検討に適していますが、多くの作業は具体的な*領域*上で行われます。キャンバスを使うと、その領域でエージェントと直接共同作業できます。
+
+キャンバスは**双方向**です。エージェントが作業中にキャンバスを更新できる一方で、ユーザーも同じ領域を編集できます。キャンバスを作成すると、エージェントはプロンプトとワークフローに基づいて内容を構築します。その後も、機能の追加、削除、修正を依頼できます。作成したキャンバスは、アプリの右側のパネルに開きます。
+
+一般的な例は次のとおりです。
+
+- 1日の計画を立て、Issue と pull request に優先順位を付けるための **Markdown canvases**。
+- ユーザーとエージェントがカードを追加し、作業を列間で移動する **Agentic kanban boards**。
+- リポジトリの重要な Issue と繰り返し現れるテーマをまとめる **Issue triage boards**。
+
+## キャンバスを使用する理由
+
+タスクに構造、反復、検証が必要で、チャットだけでは不十分な場合はキャンバスを使用します。キャンバスでは次のことができます。
+
+- ワークフローに合った実際の成果物に、エージェントの作業を結び付ける。
+- 共有領域で作業を直接調整または修正し、その変更を基にエージェントに作業を続けさせる。
+- チャットの応答だけでなく、成果物への目に見える変更として進捗を確認する。
+
+## 作業を追跡するキャンバスを作成する
+
+PR 3 がマージされたことを確認します。キャンバスを始める前に、星評価、ドキュメント標準、フィルター機能、品質チェック用スキル、QA プロファイルがすべて `main` にある必要があります。この最後の PR マイルストーンには、新しいセッションと1つのブランチを使用します。
+
+1. GitHub Copilot app に戻ります。アプリを閉じている場合は開きます。
+2. **Home screen** を選択します。
+3. リポジトリに `tailspin-toys` が選択されていることを確認します。
+4. **new working tree** と **Interactive** モードを選択します。ファイルを作成する前に、次の開始状態の確認を依頼します。
+
+ ```plaintext
+ 何も実装せずに、この新しいキャンバスのセッションを準備してください。未コミットの変更がない新しいワークツリーであることを確認し、origin をフェッチして、現在のセッションのブランチを origin/main まで fast-forward してください。チェックアウト、ブランチ、一致した HEAD と origin/main のリビジョンを報告してください。フィルター機能の PR がマージされ、フィルター機能、quality-checks スキル、QA プロファイルが存在することを確認してください。
+
+ 未コミットの変更、分岐、前のマージの不足がある場合は停止してください。リセット、作業の破棄、ブランチの切り替え、別のブランチの作成はしないでください。開始状態を報告したら停止してください。
+ ```
+
+5. 開始状態の報告を確認してから、リポジトリに保存するキャンバスを依頼します。
+
+ ```plaintext
+ App がサポートするキャンバス拡張機能のワークフローを使用し、このリポジトリ用の基本的な Kanban トリアージキャンバスを作成してください。チームで再利用できるよう、定義を .github/extensions/ に保存してください。既存の拡張機能を調べて保持し、同梱のデータベースエクスプローラーを上書きしないでください。
+
+ 現在オープンな Issue を読んでください。対応が必要である可能性が最も高い3件を目立たせ、残りを下に表示してください。上位の各 Issue にはタイトル、内容の概要、URL、優先順位の理由を含めてください。順位は提案であり、Issue を変更する指示ではないものとして扱ってください。
+
+ 各カードに、このセッションにだけ Issue の詳細を追加する Add to current context アクションを用意してください。実装の開始、セッションやブランチの作成、Issue の状態変更、PR の作成は行わないようにしてください。キャンバスの範囲を限定し、キーボードで利用可能にしてください。
+
+ 生成したファイルを提示し、確認できるようキャンバスを開いてください。アプリケーションコードの変更、コミット、プッシュ、PR の作成はしないでください。インストールや依存関係の追加の前に確認してください。
+ ```
+
+Copilot がキャンバスのファイルを作成し、共有領域を開きます。アクションを信頼して使用する前に、生成された拡張機能をレビューしてください。単なる画像ではなく、リポジトリ内の実行可能なコンテンツです。
+
+> [!NOTE]
+> 最初のバージョンに改善が必要な場合は、トリアージの範囲内で対象を絞った改善を依頼します。この演習をバックログの Issue の実装に変えないでください。
+
+## キャンバスを確認して操作する
+
+1. **Changes** を開き、キャンバス定義がユーザーやセッション専用ではなく、リポジトリの `.github/extensions/` に保存されていることを確認します。既存の拡張機能とアプリケーションファイルが変更されていないことも確認します。
+2. ボードを実際のオープンな Issue と比較し、順位の理由を評価します。
+3. カードと操作部品が読みやすく、キーボードで利用できることを確認します。
+4. Issue の **Add to current context** を選択し、詳細だけが会話に入ることを確認します。実装や Issue の状態変更が始まってはいけません。
+5. 修正があればレビューし、変更したファイルに適用できる既存の検証を実行するよう Copilot に依頼します。開いたから正しいと判断せず、結果と阻害要因を記録します。
+
+## キャンバスを保存してリポジトリにマージする
+
+キャンバスはすでにリポジトリのアセットです。レビュー済みのキャンバスの作業だけをコミットし、PR 4 として提出します。
+
+1. 同じセッションで、次を送信します。
+
+ ```plaintext
+ リポジトリに保存したトリアージキャンバスの差分と検証の証拠をレビューしてください。承認済みのキャンバスファイルをこのセッションのブランチにコミットし、プッシュして、リポジトリの PR テンプレートを使用して main を対象とする PR を1つ作成してください。キャンバスの動作と、Issue の追加がコンテキストだけを追加することをどう検証したかを説明してください。まだマージせず、バックログの Issue は実装しないでください。
+ ```
+
+2. **My work** で PR の差分全体とチェックをレビューします。キャンバスが含まれ、無関係なアプリケーションの作業が含まれていないことを確認します。
+3. 同じキャンバスのセッションで PR 操作のドロップダウンを開き、**Agent merge** を選択します。許可する操作をレビューし、最終結果を承認するまで **Merge pull request** を無効にしておきます。
+4. Agent Merge を開始する前に範囲を設定します。
+
+ ```plaintext
+ この既存のキャンバスの PR を Agent Merge で管理してください。範囲内のレビューと CI の阻害要因にだけ対処し、無関係な変更やインストールの前には確認してください。キャンバスを変更した場合は、影響する検証を繰り返して証拠を更新してください。レビュー後に私が Merge pull request を明示的に有効にするまでマージしないでください。バックログの Issue の実装や別の PR の作成はしないでください。
+ ```
+
+5. **Agent merge** を選択し、追加の変更をレビューします。学習用リポジトリの実際の CI チェックを確認し、失敗を解消してください。CI はキャンバスの操作確認の代わりにはなりません。
+
+6. 最終差分と現在の証拠が承認され、必須のチェックとレビューが成功したら、Agent Merge のドロップダウンから **Merge pull request** を選択してマージを明示的に許可します。
+
+ 
+
+7. 続行前に、GitHub で PR 4 が **Merged** と表示されることを確認します。
+
+これでチーム用の新しい共有キャンバスを作成できました。
+
+## 別の機能に着手せずキャンバスを再度開く
+
+PR がマージされた後、同じキャンバスのセッションで、リポジトリに保存したキャンバスを再度開きます。これは確認の手順であり、別のブランチや PR のマイルストーンではありません。
+
+1. キャンバスのセッションに戻って **Interactive** モードを維持し、キャンバスのパネルが開いていれば閉じます。
+2. 次を送信します。
+
+ ```plaintext
+ この同じセッションでリポジトリのトリアージキャンバスを再度開いてください。詳細を確認するためだけに Issue をコンテキストに追加します。ファイルの編集、Issue の実装や状態変更、別のセッションやブランチの作成、コミット、プッシュ、PR の作成はしないでください。
+ ```
+
+3. 定義を再生成せず、保存済みのキャンバスが再び開くことを確認します。
+4. 最も関心のある Issue の1つで **Add to current context** を選択します。
+5. 実装が始まらず、選択した Issue の詳細がコンテキストに表示されることを確認します。ここで終了してください。ワークショップの PR マイルストーンは5つではなく4つです。
+
+これで、作成したキャンバスを使って開発プロセスを効率化できました。
+
+## まとめと次のステップ
+
+ユーザーとエージェントが共同作業できる共有領域を作成しました。具体的には、次の作業を行いました。
+
+- キャンバスの概要と使用する場面を学習した。
+- エージェントと共有の Kanban トリアージボードのキャンバスを作成した。
+- Agent Merge を使ってキャンバスをリポジトリに保存し、マージした。
+- マージ済みのキャンバスを再度開き、別の機能に着手せず Issue のコンテキストを追加した。
+
+バックログを追跡できるようになったので、ここまで構築した内容と今後の進め方を振り返ります。[レッスン 10「振り返りと次のステップ」][next-lesson]に進んでください。
+
+## リソース
+
+- [GitHub Copilot app での canvas extension の操作][canvas-docs]
+- [Awesome Copilot の Canvases][awesome-copilot-canvases]
+- [GitHub Copilot app について][about-copilot-app]
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
+[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/ja-jp/app/README.md b/docs/ja-jp/app/README.md
index fb9e8b76..fc96c289 100644
--- a/docs/ja-jp/app/README.md
+++ b/docs/ja-jp/app/README.md
@@ -3,12 +3,14 @@ slug: ja-jp/app
title: "GitHub Copilot app"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
[**GitHub Copilot app**](https://docs.github.com/copilot/concepts/agents/github-copilot-app) は Copilot CLI を基盤とするデスクトップアプリケーションで、エージェント主導の開発を単一の作業用ワークスペースで実現します。並列エージェントセッション、切り替え可能なセッションモード、共有キャンバス、GitHub Issue と pull request のネイティブ管理機能を備えています。さらに、リベース、レビューのフィードバック、CI の修正、マージまで pull request を導く **Agent Merge** も利用できます。
-一連のレッスンでは、アプリをインストールしてプロジェクトを設定した後、アプリのワークスペースと、テンプレートによって用意されたバックログを確認します。まず、星評価を追加する小さな変更に取り組みます。次に、Issue に基づいてカスタム指示の標準を追加し、分離されたエージェントセッションでフィルター機能を構築して、再利用可能なスキルで検証します。Playwright MCP server を追加して実際のブラウザーで機能を確認した後、段階的にマージの自動化を進め、最後は **Agent Merge** で pull request をマージします。最後に、共有キャンバスで共同作業し、繰り返し発生する作業を自動化します。アイデアから機能のマージまで、開発の一連の流れを体験できます。
+セットアップを扱うレッスン0～1で、プロジェクトと App のワークスペースを準備します。9つのコアモジュールであるレッスン2～10では、まず星評価を追加する小さな変更と、実際のコードで効果を確認するドキュメント規約に取り組みます。次にフィルター機能を計画・構築し、シェルスクリプトを同梱した quality-checks スキルを作成して実行します。Playwright MCP で機能を観察し、要件とカバレッジを評価する QA カスタムエージェントを作成します。機能全体の PR をレビューして Agent Merge を承認した後、共有トリアージキャンバスを作成してマージします。
+
+ワークショップには4つの PR マイルストーンがあります。星評価、指示とその実証、フィルター機能とスキル・QA プロファイル・テスト、そしてキャンバスです。各マイルストーンは更新済みの `main` から開始し、モジュールごとではなく PR ごとに1つのブランチを使用します。レッスン4～8では、同じフィルター機能のセッション、ワークツリー、ブランチを維持します。キャンバスを再度開く際は Issue のコンテキストを追加するだけで、別の機能や5つ目の PR には着手しません。自動化は次のステップとしてリンクを紹介し、追加の演習にはしません。
## レッスン
@@ -16,13 +18,15 @@ lastUpdated: 2026-06-30
|--------|-------|-------------|
| [0. 前提条件][ex0] | セットアップ | Node.js をインストールし、Tailspin Toys プロジェクトの自分用コピーを作成します |
| [1. Copilot app のインストール][ex1] | セットアップ | アプリをインストールしてプロジェクトを接続し、ワークスペースを確認します |
-| [2. 最初のエージェントセッションの実行][ex2] | 最初の変更 | セッションを開始し、最初の pull request として小さな変更をリリースします |
-| [3. カスタム指示による Copilot のガイド][ex3] | コンテキスト | Issue に基づいてドキュメント標準を追加し、マージします |
-| [4. Autopilot による機能の構築][ex4] | コア機能 | Plan と Autopilot を使ってフィルター機能を構築し、スキルで検証します |
-| [5. Playwright MCP によるテスト][ex5] | 外部ツール | Playwright MCP server を追加し、ブラウザーで機能を確認します |
-| [6. Agent Merge によるマージ][ex6] | マージ | Agent Merge でフィルター機能の pull request を修正してマージします |
-| [7. キャンバスを使った計画][ex7] | コラボレーション | 共有キャンバスを作成し、作業の計画と追跡に使用します |
-| [8. 振り返りと次のステップ][ex8] | まとめ | 繰り返し発生するタスクを自動化し、次に学ぶ内容を確認します |
+| [2. 星評価の追加で小さな成果を得る][ex2] | 最初の変更 | 既存の評価と null の場合の表示を追加し、PR 1 をマージします |
+| [3. カスタム指示による Copilot のガイド][ex3] | コンテキスト | ドキュメント標準と実際の実証コードを追加し、PR 2 をマージします |
+| [4. Plan と Autopilot によるフィルター機能の構築][ex4] | 実装 | 計画を承認し、フィルター機能を実装・検証してチェックポイントを保存します |
+| [5. quality-checks スキルの作成と使用][ex5] | 繰り返し実行できるチェック | 同梱するシェルスクリプトを作成、確認、実行します |
+| [6. Playwright MCP による機能の検証][ex6] | ブラウザーでの観察 | Customize から MCP を設定し、フィルターの動作を確認します |
+| [7. QA エージェントの作成と使用][ex7] | 要件とカバレッジ | 専門家のプロファイルを選択し、最終検証の証拠を収集します |
+| [8. 機能の PR の作成とマージ][ex8] | レビューとマージ | フィルター機能、スキル、QA プロファイル、テストをレビューし、PR 3 の Agent Merge を承認します |
+| [9. トリアージキャンバスの作成][ex9] | コラボレーション | リポジトリに保存するキャンバスを PR 4 で共有し、Issue のコンテキストを追加します |
+| [10. 振り返りと次のステップ][ex10] | まとめ | ワークフロー、成果物、追加のリソースを振り返ります |
## 前提条件
@@ -50,9 +54,11 @@ lastUpdated: 2026-06-30
[ex2]: 2-add-star-rating/
[ex3]: 3-custom-instructions/
[ex4]: 4-build-filtering/
-[ex5]: 5-mcp-playwright/
-[ex6]: 6-agent-merge/
-[ex7]: 7-canvases/
-[ex8]: 8-review/
+[ex5]: 5-agent-skills/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-canvases/
+[ex10]: 10-review/
[install-git]: https://github.com/git-guides/install-git
[callout-student-plan-education]: https://github.com/education/students
\ No newline at end of file
diff --git a/docs/ja-jp/cli/0-prerequisites.md b/docs/ja-jp/cli/0-prerequisites.md
index eeda24e4..82fd2823 100644
--- a/docs/ja-jp/cli/0-prerequisites.md
+++ b/docs/ja-jp/cli/0-prerequisites.md
@@ -2,7 +2,7 @@
title: "演習 0: 前提条件"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
Copilot CLI の演習を始める前に、必要な準備を整えます。Tailspin Toys リポジトリの自分用コピーを作成し、[codespace][codespaces] を立ち上げます。次の演習では、その統合ターミナルを使って Copilot CLI をインストールし、実行します。
@@ -11,6 +11,8 @@ Copilot CLI の演習を始める前に、必要な準備を整えます。Tails
これから作成するコード用にリポジトリのコピーを作成するため、[template][template-repository] からインスタンスを作成します。新しいインスタンスにはラボに必要なすべてのファイルが含まれており、演習を進める間はこのリポジトリを使用します。
+テンプレートの新しいコピーを使用してください。リポジトリの指示、アプリケーションコード、テスト、CI は含まれていますが、カスタムエージェントやスキルは同梱されていません。これらの資産は自分で作成します。以前のコピーに戻る場合は、既存のカスタマイズを確認してから変更し、自分の作業を上書きしないでください。
+
1. 新しいブラウザー ウィンドウで、このラボの GitHub リポジトリ `https://github.com/github-samples/tailspin-toys` に移動します。
2. ラボ用リポジトリ ページの **Use this template** ボタンを選択して、自分用のリポジトリ コピーを作成します。次に **Create a new repository** を選択します。
@@ -27,6 +29,8 @@ Copilot CLI の演習を始める前に、必要な準備を整えます。Tails
>
> テンプレートからリポジトリを作成すると、GitHub issue のバックログが自動的に作成されます。ワークショップ全体を通してこれらの issue を使って作業するため、自分で起票する必要はありません。
+Issue を初期作成するワークフローの完了を待ち、**Issues** タブで **Allow users to filter games by category and publisher** と **Update our repository coding standards** を確認します。演習では、推測した Issue 番号ではなく、実際のタイトルと URL を使ってください。バックログがない場合は、ワークフローの結果を確認してから進みます。
+
## Codespace を作成する
次は、codespace を使ってラボの演習を進めます。
@@ -50,8 +54,8 @@ Codespace の作成には数分かかりますが、すべてのサービスを
> [!NOTE]
> このワークショップは、codespace またはローカルの [dev container][dev-containers] 内で実行する前提で作られています。どちらでも、必要な前提条件がすべてインストールされた環境を用意できるため、スムーズに進められます。ローカルで実行したい場合は、クローンしたリポジトリを VS Code で開き、表示されたら **Reopen in Container** を選択してください。VS Code が、codespace と同じ dev container を構築します。
-[codespaces]: https://github.com/features/codespaces
-[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
+Codespace の準備ができたら、[演習 1][next-lesson]でターミナルを開き、Copilot CLI をインストールする前にリポジトリ、ランタイム、認証を確認します。
+
## まとめ
おめでとうございます。ラボ用リポジトリのコピーを作成できました。さらに、Copilot CLI を使い始めるときに使用する codespace の作成も開始しました。
@@ -69,3 +73,5 @@ Copilot CLI をインストールし、GitHub アカウントで認証しまし
[template-repository]: https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-template-repository
[codespaces-quickstart]: https://docs.github.com/codespaces/getting-started/quickstart
[next-lesson]: ../1-install-copilot-cli/
+[codespaces]: https://github.com/features/codespaces
+[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
diff --git a/docs/ja-jp/cli/1-install-copilot-cli.md b/docs/ja-jp/cli/1-install-copilot-cli.md
index ce05003b..0e63ec98 100644
--- a/docs/ja-jp/cli/1-install-copilot-cli.md
+++ b/docs/ja-jp/cli/1-install-copilot-cli.md
@@ -2,7 +2,7 @@
title: "演習 1 - GitHub Copilot CLI をインストールする"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
[GitHub Copilot CLI][about-copilot-cli] は、ターミナルで動作する強力なエージェント型コーディング アシスタントです。コードベースの探索、コード生成、コマンド実行、外部ツールとの連携をすべてコマンド ラインから行えます。タスクを任せたり、変更を依頼したりしながら、集中を保って作業できます。最初のステップは、想像どおりツールをインストールすることです。幸い、すでによく知っているツールを使って実行できます。
@@ -21,10 +21,25 @@ lastUpdated: 2026-06-30
Copilot CLI をインストールする前に、codespace でターミナル ウィンドウを開く必要があります。
-1. まだ開いていない場合は、codespace に戻ります。
+1. Codespace に戻り、セットアップの完了を待ちます。
2. Ctrl+\` を押してターミナル ウィンドウを開きます。
3. VS Code ウィンドウの下部にターミナル パネルが表示されます。
+## 学習用環境を確認する
+
+Codespace のターミナルで、ワークショップ教材のリポジトリではなく、自分の Tailspin Toys リポジトリにいることを確認します。`README.md` と `package.json` を読み、セットアップとチェックのコマンドを確認してください。現在の Tailspin Toys には Node.js 22.13 以降、プロジェクトの依存関係、E2E テスト用の Playwright Chromium が必要です。
+
+```bash
+pwd
+git remote -v
+node --version
+gh auth status
+```
+
+GitHub CLI（`gh`）は PR と CI の確認に役立ちます。認証されていない場合は、`gh auth login` を実行してブラウザーの案内に従います。このリポジトリでブランチをプッシュし、PR を作成・マージできるアカウントであることを確認してください。組織のポリシーによっては、別のレビュアーが必要です。コードの変更を始める前に、リポジトリのセットアップ手順に従って不足している前提条件を解消し、インストール内容を確認してから承認します。
+
+CLI は起動したチェックアウトで動作します。会話を始めても、独立したワークツリーが自動的に作成されるわけではありません。このワークショップでは PR マイルストーンごとに1つのブランチを使います。先に星評価と指示の実証をマージし、演習4～8では同じフィルター機能のブランチを維持します。
+
## Copilot CLI をインストールする
Copilot CLI は [npm][install-npm]、[WinGet][install-winget]、[Homebrew][install-homebrew] でインストールできます。GitHub Codespaces には Node.js があらかじめインストールされているため、この演習では npm を使って Copilot CLI をインストールします。
@@ -35,7 +50,7 @@ Copilot CLI は [npm][install-npm]、[WinGet][install-winget]、[Homebrew][insta
node --version
```
- バージョン 22 以上（例: `v22.x.x`）が表示されるはずです。
+ CLI 自体の要件が異なる場合でも、Tailspin Toys にはバージョン 22.13 以上が必要です。バージョンが古い場合は、学習用リポジトリのセットアップ手順に従ってください。
2. npm を使って codespace に Copilot CLI をグローバル インストールします。
@@ -51,8 +66,8 @@ Copilot CLI は [npm][install-npm]、[WinGet][install-winget]、[Homebrew][insta
バージョン番号（例: `v1.0.XX`）が表示されるはずです。
-> [!TIP]
-> 権限エラーが発生した場合は、一部のシステムで `sudo npm install -g @github/copilot` の使用が必要になることがあります。ただし、GitHub Codespaces では通常必要ありません。
+> [!NOTE]
+> 権限エラーでインストールに失敗した場合は、不慣れなコマンドを管理者権限で再実行せず、npm の設定を確認するか、ワークショップの講師に相談してください。
## GitHub で認証する
@@ -85,22 +100,39 @@ Copilot CLI は [npm][install-npm]、[WinGet][install-winget]、[Homebrew][insta
2. このワークショップでは、このリポジトリで継続して作業するため、**Yes, and remember this folder for future sessions** を選択します。
3. Copilot に簡単な質問をして、正しく動作していることを確認します。
- ```
- What files are in this project?
+ ```plaintext
+ このプロジェクトにはどのようなファイルがありますか。
```
4. Copilot がリポジトリを探索し、プロジェクト構造の概要を返すはずです。
5. `/help` コマンドを試して、利用可能な slash command を確認します。
- ```
+ ```text
/help
```
-6. ターミナルで次のコマンドを入力して Copilot CLI を終了します。後続の演習で再び Copilot CLI に戻ります。
+6. Copilot のプロンプトで次のコマンドを入力して、このセッションを終了します。最初の変更には新しいセッションを使います。
+ ```text
+ /exit
```
- exit
- ```
+
+## モードと権限を理解する
+
+Copilot CLI は起動したディレクトリと Git ブランチで作業します。ディレクトリを信頼するとリポジトリのコンテキストを利用できるようになりますが、すべてのツール操作の承認とは異なります。ファイル変更、シェルコマンド、GitHub 操作の権限要求を確認してください。
+
+コードの演習は、学習用リポジトリのルートから次のコマンドで開始します。
+
+```bash
+copilot --enable-all-github-mcp-tools
+```
+
+GitHub MCP サーバーは組み込まれています。このフラグで Issue や PR の作業に使うすべてのツールを公開しますが、認証、リポジトリの権限、ツールの承認は引き続き必要です。このフラグだけでコミットや PR を承認するわけではありません。
+
+Shift+Tab で通常の **Interactive**、**Plan**、**Autopilot** モードを切り替えます。リクエストを送る前にモード表示を確認してください。最初の変更では Interactive を維持し、フィルター機能は計画してから構築します。カスタマイズの作成とレビューの前には、明示的に Interactive に戻します。
+
+> [!CAUTION]
+> モードと権限の設定は別です。Autopilot は自律的に作業を続け、`--allow-all` とその別名 `--yolo` はすべてのツール、パス、URL の権限を付与します。このワークショップでは、毎回のセッションを無制限の権限で始める必要はありません。Codespace 内でも、アクセスを許可する前に範囲を確認してください。
## まとめと次のステップ
@@ -111,7 +143,7 @@ Copilot CLI は [npm][install-npm]、[WinGet][install-winget]、[Homebrew][insta
- Copilot CLI が作業できるようにディレクトリを信頼する。
- インストールが正しく動作していることを確認する。
-Copilot CLI をインストールできたので、次は Copilot にプロジェクトのコンテキストを与えます。[演習 2 - Copilot CLI のカスタム命令][next-lesson] に進んでください。
+Copilot CLI をインストールできたので、[演習 2 - 星評価を追加して小さな成果を得る][next-lesson]で、レビューしやすい小さな変更を行います。
## リソース
@@ -120,7 +152,7 @@ Copilot CLI をインストールできたので、次は Copilot にプロジ
- [Copilot CLI を使う][using-copilot-cli]
[previous-lesson]: ../0-prerequisites/
-[next-lesson]: ../2-custom-instructions/
+[next-lesson]: ../2-add-star-rating/
[install-copilot-cli]: https://docs.github.com/copilot/how-tos/set-up/install-copilot-cli
[install-npm]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-npm-all-platforms
[install-winget]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-winget-windows
diff --git a/docs/ja-jp/cli/10-review.md b/docs/ja-jp/cli/10-review.md
new file mode 100644
index 00000000..f0d5b368
--- /dev/null
+++ b/docs/ja-jp/cli/10-review.md
@@ -0,0 +1,67 @@
+---
+title: "演習 10 - 振り返りと次のステップ"
+description: "共通の開発ワークフロー、再利用可能な資産、CLI の3つの pull request マイルストーンを振り返ります。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Copilot CLI を使い、小さな変更から、再利用可能な検証を伴う計画的な機能開発へと進みました。演習0～1のセットアップで環境を整え、演習2～10の9つのコアモジュールで一連の開発ワークフローを学びました。
+
+## 3つの PR マイルストーンを振り返る
+
+| マイルストーン | マージした成果 | レビューの習慣 |
+| --- | --- | --- |
+| PR 1: 星評価 | 既存の `starRating` をゲームカードに表示し、`null` の場合は `No rating yet` を表示 | 変更の範囲を保ち、両方のケースを検証する |
+| PR 2: カスタム指示 | 範囲を絞ったドキュメント規約と実際のコードによる小さな実証 | チャット内の例だけでなく、指示が実際のコードを改善しているか確認する |
+| PR 3: フィルター機能と検証 | フィルター機能、quality-checks スキル、QA プロファイル、関連テスト | マージ前にすべてのチェックポイント、現在の QA の証拠、CI をレビューする |
+
+最初の2つの PR は、それぞれマージしてから更新済みの `main` で次のマイルストーンを始めました。演習4～8では1つのブランチとチェックアウトを共有しました。チェックポイントコミットで進捗を保存し、モジュールごとに PR を作成することはありませんでした。操作方法の演習でも、別の機能や PR は開始しませんでした。
+
+## 共通の資産を振り返る
+
+ターミナルのインターフェイスを通じて、[Copilot App ワークショップ][app-workshop]と同じ中核的な成果を得ました。
+
+- **リポジトリの指示**はプロジェクトのコンテキストと基準を説明し、パス別の指示は対象ファイルに関する詳細を追加します。
+- **フィルター機能の実装とテスト**は、Issue と計画時に承認した追加の取り決めを満たします。
+- **quality-checks スキル**は、再利用可能な指示と、プロジェクトの4つのチェックを実行する実際のシェルスクリプトをまとめます。
+- **Playwright MCP の設定**は、直接観察するためのブラウザーツールを提供します。この CLI の流れでは、機能の PR ではなくユーザー設定に保存されます。
+- **QA カスタムエージェント**は、要件から始めてカバレッジを確認し、スキルとブラウザーツールを使い、正確な結果を報告する再利用可能な役割を定義します。
+- **PR と検証の証拠**は、レビュー済みの変更を、テスト結果、ブラウザー観察、制限事項、CI に結び付けます。
+
+スキルは単なるコマンド一覧ではなく、プロファイルも単なるファイル名ではありません。生成された資産を確認し、実際の実行を確かめ、カスタムエージェントを選択してからその報告を利用しました。
+
+## 検証の目的を区別する
+
+計画では実装前に要件を明確にしました。Autopilot は範囲を限定した計画を実行し、Interactive に戻ることで、カスタマイズ作成前の意識的なレビューの機会を取り戻しました。
+
+実装時にはスキルが存在する前から既存の npm チェックを使いました。スキルの演習では、同梱のスクリプトと引数の転送が動作することを確認しました。MCP ではスイート全体を繰り返すのではなく、ブラウザーを直接操作しました。QA では条件、カバレッジ、ブラウザーの証拠、スキル経由の4つすべてのチェックを組み合わせました。PR では現在も有効な QA 結果を再利用し、CI が提出したリビジョンをチェックしました。
+
+失敗と阻害要因も有用な結果です。ブラウザーツールの不足、テストのスキップ、古いサーバー、未解決の要件は **NO-GO** を意味し、基準を下げる許可ではありません。テストの追加は実際の不足に基づいて判断します。既存のカバレッジが十分なら、テストを追加しない判断が適切です。
+
+## これからも続ける習慣
+
+- Issue、変更の理由、明確な境界を Copilot に伝えます。
+- 自律的な作業を承認する前に計画をレビューします。
+- 生成した指示、スキル、プロファイルは、実行前に確認します。
+- 結果がどのチェックアウト、ブランチ、サーバー、リビジョンを示しているか把握します。
+- 妥当な最小限の修正を行い、変更後は証拠を更新します。
+- インストール、破壊的な操作、共有、PR のマージは明示的に承認します。
+
+## 学習を続ける
+
+[Copilot App ワークショップ][app-workshop]では、グラフィカルなインターフェイスで共通の成果に到達し、キャンバスのマイルストーンも追加します。[VS Code ワークショップ][vscode-workshop]と[Cloud エージェントワークショップ][cloud-workshop]では、エージェントと作業するほかの方法を学べます。
+
+[Awesome Copilot][awesome-copilot]で、指示、スキル、カスタムエージェントの例を探してください。[演習5のスキル例][skill-examples]には、コントリビューションのワークフロー、要件文書、図、ブラウザーテストがあります。コミュニティのコンテンツを採用する前に、前提条件と動作を確認します。
+
+日々の参照には、[CLI コマンドリファレンス][cli-reference]、[エージェントスキルのドキュメント][agent-skills]、[カスタムエージェントのドキュメント][custom-agents]を利用してください。範囲を限定したタスクで試行を続け、確認済みの資料だけを承認された経路で共有します。
+
+[previous-lesson]: ../9-slash-commands/
+[app-workshop]: ../../app/
+[vscode-workshop]: ../../vscode/
+[cloud-workshop]: ../../cloud/
+[skill-examples]: ../5-agent-skills/#ほかのスキルの例
+[awesome-copilot]: https://github.com/github/awesome-copilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
+[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
+[custom-agents]: https://docs.github.com/copilot/concepts/agents/copilot-cli/about-custom-agents
diff --git a/docs/ja-jp/cli/2-add-star-rating.md b/docs/ja-jp/cli/2-add-star-rating.md
new file mode 100644
index 00000000..d33c07c5
--- /dev/null
+++ b/docs/ja-jp/cli/2-add-star-rating.md
@@ -0,0 +1,83 @@
+---
+title: "演習 2 - 星評価を追加して小さな成果を得る"
+description: "既存のゲーム評価を表示し、変更をレビュー・検証して、最初の pull request をマージします。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+理解して検証できる小さな変更から始めます。Tailspin Toys は各ゲームの `starRating` をすでに保存し、詳細ページに表示しています。この既存の値をゲームカードにも表示し、未評価のゲームにはわかりやすいメッセージを表示します。
+
+この演習では、次のことを行います。
+
+- Interactive の CLI セッションで、範囲を絞った変更を依頼する。
+- 差分を確認し、評価済みと未評価のカードを検証する。
+- コミットし、PR 1 を作成、レビュー、マージする。
+
+## 最初のマイルストーンを開始する
+
+学習用リポジトリのルートで、作業ツリーに未コミットの変更がないことを確認し、`main` を更新してブランチを作成します。`git status` に予期しない変更が表示されたら、切り替える前に解消してください。変更を破棄してはいけません。
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-star-rating
+copilot --enable-all-github-mcp-tools
+```
+
+確認されたらリポジトリを信頼します。**Interactive** モードであることを確認し、`/model` で利用可能なモデルを調べるか、**Auto** を選択します。ツールの承認要求が表示されたら確認してください。
+
+## 変更を依頼する
+
+次のプロンプトを送信します。
+
+```plaintext
+ゲームカードに各ゲームの星評価を表示してください。Game 型には starRating フィールドがすでにあります。5点満点の数値で、未評価のゲームでは null です。src/components/GameCard.astro の各カードに表示し、starRating が null の場合は代わりに "No rating yet" を表示してください。変更は小さく保ち、カードのレイアウト構造は変更しないでください。
+
+リポジトリの指示を確認して従ってください。既存のデータモデルを使い、評価 API、新しいスキーマ、無関係な機能は追加しないでください。評価済みと未評価のケースに適したテストを追加または更新してください。まだコミット、プッシュ、pull request の作成はしないでください。
+```
+
+Copilot は編集前に既存の型とコンポーネントを確認するはずです。最終回答だけでなく、ツールの実行内容も読んでください。自信のある要約だけでは、実装が正しい証拠にはなりません。
+
+## レビューして検証する
+
+1. `/diff` を入力し、変更されたすべてのファイルをエディターまたは差分表示で確認します。
+2. カードが既存の `starRating` を使い、5点満点の値を表示し、`null` の場合は `No rating yet` を表示することを確認します。真偽値への変換だけで判定すると、数値のゼロを未評価と誤認する場合があります。
+3. カードのレイアウトを維持し、星の記号や色だけに頼らず、意味のあるテキストラベルで評価を伝えていることを確認します。
+4. 既存のチェックを使って変更を検証するよう Copilot に依頼します。
+
+ ```plaintext
+ package.json とテスト設定を確認し、このカードの変更に適した lint、型チェック、既存の単体テストまたは E2E テストを実行してください。数値の評価と null の代替表示を両方検証し、カバレッジの不足や実行できなかったチェックも含め、正確なコマンドと結果を報告してください。インストール、ブランチの変更、コミット、プッシュ、PR の作成はしないでください。
+ ```
+
+5. コマンド出力とテストの変更を確認します。リリース前に失敗を解消し、不足する前提条件をインストールする前に確認してください。
+
+ブラウザーでカードを観察するには、同じチェックアウトで2つ目のターミナルを開き、次を実行します。
+
+```bash
+npm run dev
+```
+
+Codespace の **Ports** パネルで転送されたポートを開きます。ホームページで評価済みのカードを確認してください。現在のシードデータに未評価の例がなければ、`null` を扱う自動テストのフィクスチャを用意するよう求めてください。未評価のカードを観察したと主張してはいけません。E2E チェックの前、または演習を終える前に、開発サーバーのターミナルで Ctrl+C を押して停止します。Playwright の自動テストで別のチェックアウトのサーバーを再利用してはいけません。
+
+## PR 1 を作成してマージする
+
+変更をレビューし、チェックが成功したら、このマイルストーンを別途承認します。
+
+```plaintext
+現在の差分とチェック結果をレビューしてください。レビュー済みの星評価の変更とテストだけをコミットし、現在のブランチをプッシュして、main を対象とする pull request を作成してください。リポジトリに PR テンプレートがあれば使ってください。変更の概要と実際の検証結果を含めてください。PR のマージや別のタスクの開始はしないでください。
+```
+
+返された PR の URL を開きます。エージェントの要約だけでなく、**Files changed** とチェック結果を確認してください。CI を解釈する際は、Tailspin リポジトリのワークフロー定義を確認します。CI は自分で行うブラウザー観察の代わりにはなりません。失敗に対処し、変更したコードを再検証します。
+
+PR がリポジトリのレビューとチェックの要件を満たしたら、**Merge pull request** を選択し、GitHub でマージを確定します。ブランチ保護によって別のレビュアーが必要な場合は、その承認を待ちます。PR が **Merged** であることを確認してから進んでください。
+
+`/exit` で Copilot セッションを終了します。次の演習では、指示用のブランチを作成する前にローカルの `main` を更新します。未マージの機能ブランチから始めてはいけません。
+
+## まとめと次のステップ
+
+範囲を限定したプロンプト、コードのレビュー、検証の証拠、PR のマージという最初のサイクルを完了しました。次は[カスタム指示で Copilot を導き][next-lesson]、2つ目の小さな PR でドキュメント規約を実証します。
+
+[previous-lesson]: ../1-install-copilot-cli/
+[next-lesson]: ../3-custom-instructions/
diff --git a/docs/ja-jp/cli/2-custom-instructions.md b/docs/ja-jp/cli/2-custom-instructions.md
deleted file mode 100644
index 43406601..00000000
--- a/docs/ja-jp/cli/2-custom-instructions.md
+++ /dev/null
@@ -1,239 +0,0 @@
----
-title: "演習 2 - カスタム命令 (Copilot CLI)"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-[← 前のレッスン: Copilot CLI のインストール][previous-lesson] · [次のレッスン: CLI でコードを生成する →][next-lesson]
-
-生成 AI を使って作業するときは、コンテキストが重要です。特定のやり方で進める必要があるタスクや、Copilot に知っておいてほしい背景情報がある場合は、そのコンテキストを確実に渡すことが大切です。Copilot を補助するためのツールはいくつかあり、このワークショップ全体で確認していきます。最初に取り上げるのは [instruction file][instruction-files] です。instruction file は通常、コードそのものをどのように構成すべきかに重点を置きます。これにより、どのようなコードが必要かだけでなく、どのように構成すべきかも Copilot に理解させられます。
-
-この演習では、次のことを行います。
-
-- リポジトリの custom instruction と、パス単位で適用される instruction file を通じて、プロジェクト固有のコンテキスト、コーディング ガイドライン、ドキュメント標準がどのように Copilot に渡るかを確認する。
-- *現在の* instruction のまま、フィルタリングの最初のデータ スライス（publishers helper）を生成する。
-- `.github/copilot-instructions.md` に、リポジトリ全体に適用される新しい標準を追加する。
-- フォローアップのプロンプトを実行し、再生成されたコードが新しい標準を取り入れる様子を確認する。
-- instruction の更新と helper を commit し、次の演習でその続きに取り組めるようにする。
-
-> [!CAUTION]
-> 生成されたコードは、設定した標準から外れることがあります。Copilot は非決定的です。目的は、instruction を更新したあとに振る舞いの傾向がどう変わるかを確認することであり、出力を 1 文字単位で一致させることではありません。
-
-## Instruction files
-
-### シナリオ
-
-優れた開発チームと同様に、Tailspin Toys にも開発プラクティスに関するガイドラインと要件があります。たとえば次のような内容です。
-
-- データ レイヤーには常に unit test が必要です。
-- UI はダーク モードで、モダンな印象にする必要があります。
-- ドキュメントは TSDoc の doc comment としてコード内に追加する必要があります。
-- 各ファイルの先頭には、そのファイルの役割を説明するコメント ブロックを追加する必要があります。
-
-Instruction file を使うことで、これらのプラクティスに沿ってタスクを実行するために必要な情報を Copilot に確実に渡せます。
-
-### Custom instructions
-
-Custom instruction を使うと、コンテキストや設定を Copilot に渡せるため、コーディング スタイルや要件をより正確に理解させられます。これは非常に強力な機能であり、より関連性の高い提案やコード スニペットを Copilot から引き出すのに役立ちます。好みのコーディング規約、使用するライブラリ、含めたいコメントの種類まで指定できます。instruction はリポジトリ全体に対して作成することも、タスク レベルのコンテキストとして特定のファイル種別向けに作成することもできます。
-
-instruction file には 2 種類あります。
-
-- `.github/copilot-instructions.md` は、リポジトリへの**すべて**のリクエストで Copilot に送られる単一の instruction file です。このファイルにはプロジェクト レベルの情報、つまり Copilot に送るほとんどの chat や CLI リクエストに関連するコンテキストを含める必要があります。たとえば、使用している技術スタック、作成中のものの概要、ベスト プラクティス、その他のグローバル ガイダンスなどです。
-- `.github/instructions/*.instructions.md` ファイルは、特定のタスクやファイル種別向けに作成できます。TypeScript や Astro のような特定の言語向けガイドラインや、UI component 作成、unit test 追加などのタスク向けガイドラインを提供するために使えます。
-
-> [!NOTE]
-> IDE で作業している場合、instruction file は Copilot Chat でのコード生成にのみ使用されます。コード補完や next-edit suggestion には使われません。
->
-> Copilot Chat、Copilot CLI、Copilot cloud agent は、コード生成時にリポジトリ レベルの instruction file と `*.instructions.md` ファイル（`applyTo` front matter 付き）の両方を使用します。
->
-> さらに、Copilot は [ほかの標準を使った instruction file][custom-instructions-support] もサポートしており、AGENTS.md や CLAUDE.md ファイルも利用できます。
-
-### Instruction file を管理するためのベスト プラクティス
-
-instruction file の作成に関する詳しい説明は、このワークショップの範囲外です。ただし、サンプル プロジェクトに含まれている例は、代表的なアプローチを示しています。大まかには次のとおりです。
-
-- `copilot-instructions.md` の instruction は、何を作っているかの説明、プロジェクト構造、グローバルなコーディング標準など、プロジェクト レベルのガイダンスに集中させます。
-- `*.instructions.md` ファイルは、ファイル種別（unit test、Astro component、データ レイヤー）や特定のタスク向けに、具体的な instruction を提供するために使います。
-- 自然言語を使います。ガイダンスは明確に保ちます。コードの望ましい形と望ましくない形の両方の例を示します。
-
-instruction file の作り方に唯一の正解があるわけではなく、AI の使い方にも唯一の正解はありません。試行錯誤しながら、自分のプロジェクトに最適な方法を見つけてください。
-
-> [!TIP]
-> GitHub Copilot を使うすべてのプロジェクトには、充実した instruction file のセットがあるべきです。このプロジェクトの instruction file を見ていくと、[UI 更新][ui-instructions] や [Astro][astro-instructions] など、多くの種類のタスク向けのファイルがあることに気づくかもしれません。
->
-> Copilot は instruction file の生成も支援できます。各 surface で公開方法は異なります（たとえば VS Code の **Configure Chat → Generate Agent Instructions** や、Copilot CLI の `/init` など）。現在使用している surface のレッスンで、関係がある場面に案内があります。
->
-> テンプレートや出発点を探していますか。instruction file、custom agent、そのほかのリソースが集まったリポジトリ [awesome-copilot][awesome-copilot] を確認してください。
-
-[ui-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/ui.instructions.md
-[astro-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/astro.instructions.md
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[custom-instructions-support]: https://docs.github.com/copilot/reference/custom-instructions-support
-## このプロジェクトの custom instruction file を確認する
-
-このリポジトリに含まれている instruction file をひととおり読んでみましょう。中核となる `copilot-instructions.md` が 1 つあり、さまざまなタスク向けの `*.instructions.md` ファイル群があります。エディターまたは GitHub の Web UI で開いて確認します。
-
-1. `.github/copilot-instructions.md` を開きます。
-2. ファイルを確認し、プロジェクトの簡潔な説明に加えて、**Agent notes**、**Code standards**、**Scripts**、**Repository Structure** などのセクションに注目します。**Code standards** の中にある **GitHub Actions Workflows** に関するガイダンスにも注目してください。これらは Copilot とのあらゆるやり取りに適用されます。
-3. `.github/instructions` フォルダーを開いて中を見てみます。Astro ファイル、Drizzle データ レイヤー、test などに関する instruction があることを確認してください。
-4. `.github/instructions/unit-tests.instructions.md` を開きます。先頭にある `applyTo` フィールドに注目してください。ここには、どのファイルに instruction を適用するかを決める glob パターン（repo root からの相対パス）が設定されています。この例では、任意の TypeScript test ファイル（たとえば `**/*.test.ts` に一致するもの）が対象になります。
-5. このプロジェクトの unit test 作成に特化した instruction を確認します。
-6. 最後に `.github/instructions/drizzle.instructions.md` を開き、一番下までスクロールします。ほかの instruction file（`unit-tests.instructions.md` など）や、プロジェクト内の既存ファイルへのリンクがあることに注目してください。これにより、大きな instruction セットを小さく再利用しやすい単位に分割し、コード生成時に Copilot が従うべき例を示せます。（そこに書かれているパスは repo root ではなく instruction file からの相対パスです。）
-
-> [!NOTE]
-> `copilot-instructions.md` の **Code formatting requirements** セクションには、このプロジェクトのコーディング標準が記載されていますが、コード内ドキュメントはまだ必須ではありません。次の手順で、TSDoc の doc comment とファイル コメント ヘッダーのルールを追加します。
-## ブランチを作成する
-
-コード変更を行うため、作業用ブランチを作成します。
-
-1. codespace のターミナルで、新しいブランチを作成して切り替えます。
-
- ```bash
- git checkout -b update-custom-instructions
- ```
-
-2. Copilot CLI がインストール済みで、認証されていることを確認します。
-
- ```bash
- copilot --version
- ```
-
- コマンドが見つからない場合や、まだログインしていない場合は、[演習 1 - GitHub Copilot CLI のインストール](../1-install-copilot-cli/) に戻ってください。
-
-## instruction を更新する*前に* Copilot CLI を使う
-
-custom instruction の効果を見るため、まずは現在の instruction を使ってコードを生成します。その後でファイルを更新し、フォローアップのプロンプトを実行します。
-
-> [!TIP]
-> **Copilot CLI セッションを開始する**
->
-> 以下の演習を始める前に、codespace に戻ってターミナルを開きます（まだ開いていない場合は Ctrl+\`）。次に、`--yolo` と `--enable-all-github-mcp-tools` を付けて Copilot CLI を起動します。
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 新しく開始する代わりに、このプロジェクトの直近のセッションを引き継ぐには `copilot --yolo --enable-all-github-mcp-tools --continue` を実行します。前の演習から Copilot CLI がすでに実行中であれば、`/clear` を送ってクリーンな会話を開始してください。
->
-> `--enable-all-github-mcp-tools` を付けると、現在のセッションで GitHub MCP の読み取り / 書き込みツールが有効になります。これにより、ワークショップの流れの中で Copilot がバックログを読み取り、pull request を開けるようになります。
-
-> [!CAUTION]
-> `--yolo` は完全な自動権限（`--allow-all-tools`、`--allow-all-paths`、`--allow-all-urls`）を有効にします。Codespace や VM のような分離された環境でのみ使用し、日常的な開発の既定値として alias しないでください。詳しくは [Allowing and denying tool use][allow-all-warning] を参照してください。
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. `.github/copilot-instructions.md` を自動的に読み取れるよう、Copilot CLI セッションが**repository root** から実行されていることを確認します。
-2. Copilot CLI のプロンプトで、フィルタリング UI が利用する publishers helper を生成するよう依頼します。
-
- ```plaintext
- Create a new data-access helper at src/lib/publishers.ts to return a list of all publishers. It should return the name and id for all publishers. Do not run the tests yet.
- ```
-
-3. Copilot CLI はプロジェクトを探索し、計画を提案し、この `--yolo` セッションでファイルを書き込みます。ターミナル出力の変化を確認し、その後エディターでレビューします。
-4. 生成された `src/lib/publishers.ts` をエディターで開きます。
-5. helper が型付き関数として生成され、第一引数に `db` client を受け取り、publishers の型付き配列を返していることを確認してください。これは `.github/instructions/drizzle.instructions.md` にあるデータ レイヤーの規約（`src/lib/*.ts` に適用される）によるものです。
-6. 生成されたコードに、TSDoc の doc comment とファイル レベルのコメント ヘッダーが**含まれていない**ことを確認します。
-
-> [!CAUTION]
-> Copilot は確率的に動作するため、指示しなくても doc comment を追加する可能性があります。その場合でも問題ありません。instruction 更新後に一貫性が向上することが、この演習での重要なポイントです。
-
-## 新しいリポジトリ標準を追加する
-
-先ほど説明したように、`.github/copilot-instructions.md` は Copilot にプロジェクト レベルの情報を提供するためのファイルです。リポジトリのコーディング標準を文書化し、コード提案の質を高めましょう。
-
-1. `.github/copilot-instructions.md` をもう一度開きます。
-2. **Code formatting requirements** セクションを探します。27 行目付近にあるはずです。ここにプロジェクトのコーディング標準が記載されている一方で、コード内ドキュメントに関するルールがまだないことに注目してください。そのため、生成された helper には doc comment がありませんでした。
-3. 既存の標準のすぐ下に、次の markdown 行を追加して、ファイル コメント ヘッダーと TSDoc の doc comment を追加するよう Copilot に指示します。
-
- ```markdown
- - Every exported function should have a TSDoc comment describing its purpose, parameters, and return value.
- - Before imports or any code, add a comment block to the file that explains its purpose.
- ```
-
-4. `copilot-instructions.md` を保存します。
-
-> [!TIP]
-> 前のレッスンで見たとおり、instruction file はグローバル ガイダンス向けのリポジトリ レベル（`.github/copilot-instructions.md`）にも、特定の言語、ファイル種別、タスク向けの `*.instructions.md` としても作成できます。いま追加した doc comment ルールのような、プロジェクト全体に適用する標準を置く場所としては、リポジトリ レベルのファイルが適切です。
-## プロンプトを再実行して変化を確認する
-
-instruction に doc comment ルールを追加したので、先ほど生成した publishers ファイルを更新するよう Copilot CLI に依頼します。同じ標準ディレクティブが、書き換えの方向性を導きます。
-
-1. Copilot CLI セッションで `/clear` を送信し、新しい会話を始めます。
-2. 次のプロンプトを送信します。
-
- ```plaintext
- Update src/lib/publishers.ts to follow the latest documentation conventions in .github/copilot-instructions.md.
- ```
-
-3. 編集が完了したら、`src/lib/publishers.ts` をもう一度開きます。
-4. ファイルの先頭に、次のようなコメント ブロックが追加されていることを確認します。
-
- ```typescript
- /**
- * Publisher data-access helpers for the Tailspin Toys Crowd Funding platform.
- * Provides functions to retrieve publisher information from the database.
- */
- ```
-
-5. 生成された関数に、次のような TSDoc の doc comment が含まれていることを確認します。
-
- ```typescript
- /**
- * Returns a list of all publishers with their id and name.
- *
- * @param db - The Drizzle database client.
- * @returns A promise that resolves to an array of publisher objects.
- */
- ```
-
-6. この更新済みファイルはそのまま残してください。次の演習で、この最初のデータ スライスを土台として使います。
-
-## フィルタリングの最初のスライスを commit して push する
-
-1. ターミナルで、変更されたファイルを確認します。
-
- ```bash
- git status
- ```
-
-2. instruction の更新と helper を stage します。
-
- ```bash
- git add .github/copilot-instructions.md src/lib/publishers.ts
- ```
-
-3. 変更を commit します。
-
- ```bash
- git commit -m "Add doc comment standards and publishers helper foundation"
- ```
-
-4. ブランチを push します。
-
- ```bash
- git push -u origin update-custom-instructions
- ```
-
-## まとめと次のステップ
-
-このプロジェクトの instruction file から Copilot がどのようにコンテキストを取得するかを確認し、そのうえで Copilot CLI を使って次のことを行いました。
-
-- *既存の* instruction を使って、フィルタリング用の publishers data-access helper の土台を生成する。
-- `.github/copilot-instructions.md` に、リポジトリ全体の新しい標準を追加する。
-- フォローアップのプロンプトを実行し、再生成されたコードが新しい標準を取り入れる様子を確認する。
-- instruction の更新と helper の土台の両方を commit して push する。
-
-次は、[コード生成の演習][next-lesson] で、これらの instruction を適用しながらバックログの作業を実装します。
-
-## リソース
-
-- [GitHub Copilot のカスタマイズ用 instruction file][instruction-files]
-- [custom instruction 作成のベスト プラクティス][instructions-best-practices]
-- [Copilot 向けの custom instruction をより良く書くための 5 つのヒント][copilot-instructions-five-tips]
-- [Awesome Copilot — instruction file などのリソース集][awesome-copilot]
-
-[previous-lesson]: ../1-install-copilot-cli/
-[next-lesson]: ../3-generating-code/
-[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
-[instructions-best-practices]: https://docs.github.com/enterprise-cloud@latest/copilot/using-github-copilot/coding-agent/best-practices-for-using-copilot-to-work-on-tasks#adding-custom-instructions-to-your-repository
-[copilot-instructions-five-tips]: https://github.blog/ai-and-ml/github-copilot/5-tips-for-writing-better-custom-instructions-for-copilot/
diff --git a/docs/ja-jp/cli/3-custom-instructions.md b/docs/ja-jp/cli/3-custom-instructions.md
new file mode 100644
index 00000000..dfabd224
--- /dev/null
+++ b/docs/ja-jp/cli/3-custom-instructions.md
@@ -0,0 +1,109 @@
+---
+title: "演習 3 - カスタム指示で Copilot を導く"
+description: "範囲を絞ったドキュメント規約を追加し、既存コードで実証して、2つ目の pull request をマージします。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+コンテキストは、*何を*作るかだけでなく、チームが*どのように*コードを書くことを期待しているかを Copilot が理解する助けになります。範囲を絞ったドキュメント規約を追加し、実際のコードへの効果を確認して、指示と実証をまとめて PR 2 としてマージします。
+
+この演習では、次のことを行います。
+
+- リポジトリ全体とパス別の指示を確認する。
+- フィルター機能を先に実装せず、ドキュメント規約を追加する。
+- 小さな既存のヘルパーやコンポーネントで規約を実証する。
+- 指示のマイルストーンを検証してマージする。
+
+## 指示を確認する
+
+リポジトリには、すでに2種類の有用な指示があります。
+
+- `.github/copilot-instructions.md` は、技術スタック、構成、共通の慣行など、リポジトリ全体のコンテキストを提供します。
+- `.github/instructions/*.instructions.md` は対象を限定した指針を提供します。フロントマターの `applyTo` glob で、指示を適用するファイルを指定します。
+
+エディターで次のファイルを開きます。
+
+1. `.github/copilot-instructions.md` を読み、現在のコーディング規約と検証基準を確認します。
+2. `.github/instructions/` で、Astro、データ層、テストの指針を確認します。
+3. `unit-tests.instructions.md` で、`applyTo` パターンとテスト規約を確認します。
+4. `drizzle.instructions.md` で、データアクセスのパターンとサンプルへの参照を確認します。
+
+リポジトリ全体の指示は簡潔にし、ファイル固有の詳細は適切な対象範囲のファイルに置き、同じルールの矛盾したコピーを避けます。[GitHub の指示サポートリファレンス][instruction-support]には、各ハーネスでサポートされる指示形式が説明されています。
+
+> [!NOTE]
+> 指示は生成に影響しますが、遵守を保証するものではありません。レビューでは、指示の文面とコードへの効果を両方確認します。Copilot がすでに良いコメントを生成しているなら、この演習の目的は規約を明示して再現可能にすることです。変更前後の失敗を無理に作ることではありません。
+
+## マージ済みの PR 1 から始める
+
+星評価の PR がマージ済みであることを確認します。学習用リポジトリのターミナルで、更新済みの `main` から次のマイルストーンを始めます。
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c update-custom-instructions
+copilot --enable-all-github-mcp-tools
+```
+
+作業ツリーに未コミットの変更がある場合や pull に失敗した場合は、その状態を解消してから進みます。**Interactive** モードを維持してください。
+
+リポジトリの **Issues** タブで **Update our repository coding standards** を探し、実際の URL をコピーします。この Issue は、意図の説明、エクスポートされたデータ層関数とコンポーネントの契約の文書化、コメントの最新化という広いコンテキストを提供します。この演習で扱うのは範囲を限定したドキュメントの一部であり、リポジトリ全体のリファクタリングや、Issue の全条件を完了する約束ではありません。
+
+## ドキュメント規約を追加する
+
+プレースホルダーを実際の Issue の URL に置き換えて送信します。
+
+```plaintext
+コンテキストとして、このコーディング規約の Issue を読んでください: 。既存のリポジトリ全体と対象範囲別の指示を確認してください。範囲を絞ったドキュメント規約を追加してください。コードを言い換えるのではなく意図を説明し、db/ と src/lib/ のエクスポートされた関数には TSDoc/JSDoc で目的、パラメーター、戻り値を記述し、再利用可能な Astro コンポーネントの Props 契約を文書化し、関連コードの変更時にはコメントを最新に保つようにしてください。
+
+各ルールを適切な既存の指示ファイルに配置し、重複や矛盾を避けてください。既存のフォーマットと lint の基準を維持し、必要に応じて README にドキュメント規約へのリンクまたは要約を追加してください。変更はドキュメント規約に限定し、フォーマットツールの移行やリポジトリ全体の書き直しは行わないでください。スキルやエージェントの作成、フィルター機能の実装、コミット、プッシュ、PR の作成はしないでください。実証の前に指示を確認できるよう、そこで停止してください。
+```
+
+差分を確認します。規約は有用なコメントを促すものであり、全ファイルへの定型ヘッダーや、自明なコードを繰り返すだけのコメントを要求するものではありません。修正が必要なら、先に依頼してから進みます。
+
+## 実際のコードで規約を実証する
+
+リポジトリを確認して、小さな既存のエクスポートされたヘルパーや再利用可能なコンポーネントを選びます。パブリッシャーのヘルパーである必要はなく、`src/lib/publishers.ts` がすでに存在することも前提ではありません。
+
+次を送信します。
+
+```plaintext
+更新した指示を使い、より明確なドキュメントが役立つ小さな既存のエクスポートされたヘルパー、または再利用可能な Astro コンポーネントを1つ選んでください。実行時の動作を変えたりフィルター機能を追加したりせず、そのファイルに規約を直接適用してください。どの指示が変更を導いたか説明し、コミットや PR の作成前に停止してください。
+```
+
+実際に変更されたファイルを開きます。ヘルパーの場合は、パラメーター、戻り値、注入されるデータベース引数がコメントに正確に記述されているか確認します。コンポーネントの場合は、`Props` 契約が文書化されているか確認します。コメントブロックの有無だけでなく、説明がコードと一致していることを確認してください。
+
+> [!TIP]
+> チャット内の説明用スニペットは実証ではありません。実際のリポジトリの変更を確認してください。選んだコードがすでに規約を満たしている場合は、冗長なコメントを追加せず、改善が妥当な別の小さな既存箇所を選びます。
+
+## PR 2 を検証してマージする
+
+レビュー済みの変更を検証するよう Copilot に依頼します。
+
+```plaintext
+指示の変更と小さなドキュメントの実証をレビューしてください。実行時の動作が変わっていないことを確認してください。package.json を確認し、npm run lint と npm run typecheck:all を実行してください。コードの変更に照らして必要なら、影響する既存のテストも実行してください。正確なコマンドと結果を報告してください。まだインストール、スキルの作成、コミット、プッシュ、PR の作成はしないでください。
+```
+
+失敗を解消して最終差分を確認します。その後、マイルストーンを承認します。
+
+```plaintext
+レビュー済みのドキュメントの指示、直接関連する README の更新、小さなコードの実証だけをコミットしてください。現在のブランチをプッシュし、リポジトリの PR テンプレートに従って main を対象とする PR を作成してください。検証結果を含め、コーディング規約の Issue への部分的な貢献であることを明記してください。Issue の全条件を実際に満たしていない限り、Issue を閉じるキーワードは使わないでください。マージやフィルター機能の開始はしないでください。
+```
+
+PR の URL を開き、**Files changed** と CI を確認します。必要なチェックとレビューがすべて通ったら、GitHub でマージし、PR 2 が **Merged** であることを確認します。`/exit` で CLI セッションを終了します。この PR がマージされるまで、次のマイルストーンを始めてはいけません。
+
+## まとめと次のステップ
+
+ドキュメント規約と実際の実証が `main` に入りました。次は、そのマージ済みの状態から作成した新しいブランチで、[Plan と Autopilot を使ってフィルター機能を構築します][next-lesson]。
+
+## リソース
+
+- [リポジトリのカスタム指示を追加する][repository-instructions]では、リポジトリ全体とパス別の指針を説明しています。
+- [Awesome Copilot][awesome-copilot]の例は、無条件に採用せず、確認して調整するために利用してください。
+
+[previous-lesson]: ../2-add-star-rating/
+[next-lesson]: ../4-build-filtering/
+[instruction-support]: https://docs.github.com/copilot/reference/custom-instructions-support
+[repository-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
+[awesome-copilot]: https://github.com/github/awesome-copilot
diff --git a/docs/ja-jp/cli/3-generating-code.md b/docs/ja-jp/cli/3-generating-code.md
deleted file mode 100644
index 061fa324..00000000
--- a/docs/ja-jp/cli/3-generating-code.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: "演習 3 - GitHub Copilot CLI でプロジェクト機能を追加する"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-想像のとおり、GitHub Copilot CLI で実行する中心的な作業は、プロジェクトに機能やコードを追加することです。バックログの issue を 1 つ取り上げ、実装を Copilot に手伝ってもらいましょう。
-
-## シナリオ
-
-プロジェクトのフィルタリング機能を完成させるタイミングになりました。バックログにはフィルタリングに関する issue がすでにあり、前の演習でその土台となる helper も追加しています。Copilot に issue の詳細を取得してもらい、既存の作業を考慮しながら、残りの機能を実装してもらいます。
-
-この演習では、次のことを行います。
-
-- プラン モードを使って、フィルタリング機能を実装する計画を生成する。
-- Copilot を使って、Web サイトにフィルタリングを追加するためのコードを生成する。
-
-この演習を終えるころには、プロジェクトに新しい機能が追加されています。
-
-## プラン モードを活用する
-
-AI の優れた使い方の 1 つが計画づくりです。何を作りたいかの大まかなイメージはあっても、アイデアを整理したり、抜けや落とし穴を洗い出したりしたい場面はよくあります。AI ツールは、追跡質問を投げかけたり、異なる問題点や不足している要素を一緒に検討したりすることで、考えを明確にする助けになります。このプロセスを支えるために、Copilot CLI にはプラン モードが用意されています。さらに、計画にかけた時間は、設定された要件により適したコードを Copilot が生成する助けにもなります。
-
-まずは、Copilot CLI のプラン モードを活用して新機能の作成プロセスを始めます。
-
-> [!TIP]
-> **Copilot CLI セッションを開始する**
->
-> 以下の演習を始める前に、codespace に戻ってターミナルを開きます（まだ開いていない場合は Ctrl+\`）。次に、`--yolo` と `--enable-all-github-mcp-tools` を付けて Copilot CLI を起動します。
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 新しく開始する代わりに、このプロジェクトの直近のセッションを引き継ぐには `copilot --yolo --enable-all-github-mcp-tools --continue` を実行します。前の演習から Copilot CLI がすでに実行中であれば、`/clear` を送ってクリーンな会話を開始してください。
->
-> `--enable-all-github-mcp-tools` を付けると、現在のセッションで GitHub MCP の読み取り / 書き込みツールが有効になります。これにより、ワークショップの流れの中で Copilot がバックログを読み取り、pull request を開けるようになります。
-
-> [!CAUTION]
-> `--yolo` は完全な自動権限（`--allow-all-tools`、`--allow-all-paths`、`--allow-all-urls`）を有効にします。Codespace や VM のような分離された環境でのみ使用し、日常的な開発の既定値として alias しないでください。詳しくは [Allowing and denying tool use][allow-all-warning] を参照してください。
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. 次のプロンプトを Copilot CLI に入力し、フィルタリング issue に基づく計画を作成します。
-
- ```
- /plan Retrieve the issue on the repository related to adding filtering. We already added a publishers helper in src/lib/publishers.ts, so treat that as existing work and plan the remaining updates (games filtering logic, UI, and tests).
- ```
-
-2. 計画を作成する過程で、Copilot から追跡質問が表示されることがあります。表示された場合は、自分ならどのように機能を実装するかに基づいて答えてください。
-3. 計画が生成されたら、その設計図をレビューします。データ レイヤーや UI の残りの変更に加え、test の生成も推奨されていることに気づくはずです。
-4. Copilot CLI は、計画に対して追加のフィードバックを提供する機会を提示します。カーソルを案内された位置まで下げ、提案を入力すると、Copilot がそれを取り込んだ新しいバージョンの計画を作成します。
-5. 内容に満足したら、Copilot が提示する選択肢を選び、新機能の実装作業を開始します。
-
-> [!NOTE]
-> Copilot は確率的に動作するため、表示されるテキストや選択肢は完全には一致しません。ただし、実装の開始に進む選択肢が表示され、その文言は次のようなものになります。
->
-> `Yes, and switch to autopilot mode`.
->
-> 上の例のように、Copilot から [autopilot mode](https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot) を有効にする選択肢が提示される場合があります。autopilot mode を使うと、各ステップのたびに入力を待たずに、Copilot CLI がタスクを進められます。最初の指示を与えると、タスクが完了したと判断するまで Copilot CLI が各ステップを自律的に実行します。このワークショップでは隔離された環境で動作しているため、autopilot を有効にし、すべてのツールを許可しても問題ありません。
-
-6. Copilot がファイルの生成作業を開始します。
-
-> [!NOTE]
-> この操作には数分かかることがあります。Copilot がファイルを編集 / 作成し、test を更新 / 生成し、すべて成功することを確認するために test を実行する様子が表示されます。ここまでに確認した内容を振り返ったり、飲み物を楽しんだりするのにちょうどよい時間です。
-
-## コードをレビューする
-
-AI が生成したコードは、本番環境にマージする前に必ずレビューする必要があります。ここで少し時間を取り、Copilot が新機能の実装で作成 / 変更したファイルを確認しましょう。
-
-1. Copilot CLI で次のコマンドを使い、「diff」またはコード変更を表示します。
-
- ```
- /diff
- ```
-
-2. 変更されたファイルを確認します。左右の矢印キーで別のファイルに切り替えられます。新しい filter control とクライアント側フィルタリングが実装された games 一覧ページや `src/lib/games.ts`、さらに `games.test.ts` などの test が更新されているはずです。Copilot が既存の helper を完全な実装に合わせて調整した場合は、`publishers.ts` に変更が加わることもあります。
-
-## まとめと次のステップ
-
-Copilot CLI の助けを借りて、Web サイトにフィルタリング機能を追加できました。具体的には次のことを行いました。
-
-- プラン モードを使って、フィルタリング機能を実装する計画を生成する。
-- Copilot を使って、Web サイトにフィルタリングを追加するためのコードを生成する。
-
-もちろん、次にやるべきことは、それが正しく動作することを確認することです。pull request を開く前に、[Playwright MCP サーバーで機能をテスト][next-lesson] しましょう。
-
-## リソース
-
-- [Copilot CLI を使う][using-copilot-cli]
-- [Copilot CLI について][about-copilot-cli]
-- [Copilot CLI のコンテキスト管理][context-management]
-
-[previous-lesson]: ../2-custom-instructions/
-[next-lesson]: ../4-mcp/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
diff --git a/docs/ja-jp/cli/4-build-filtering.md b/docs/ja-jp/cli/4-build-filtering.md
new file mode 100644
index 00000000..5968f072
--- /dev/null
+++ b/docs/ja-jp/cli/4-build-filtering.md
@@ -0,0 +1,102 @@
+---
+title: "演習 4 - Plan と Autopilot でフィルター機能を構築する"
+description: "フィルターの要件に合意し、実装計画を承認してコードを検証し、機能ブランチにチェックポイントを保存します。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+次は、カテゴリとパブリッシャーでゲームを絞り込める、より大きな機能を構築します。コーディングの前に計画し、**Autopilot** を明示的に承認してから実装をレビュー・テストし、チェックポイントを保存します。この演習では、スキル、QA エージェント、機能の PR は作成しません。
+
+## フィルター機能のマイルストーンを開始する
+
+PR 1 と PR 2 がマージ済みであることを確認します。学習用リポジトリのターミナルで、次を実行します。
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-game-filtering
+copilot --enable-all-github-mcp-tools
+```
+
+作業ツリーに未コミットの変更がなく、`main` からの更新が成功した場合にのみ進みます。演習4～8では、同じブランチとチェックアウトを使用します。後のチェックポイントコミットでスキルと QA プロファイルを追加します。演習ごとにブランチを作成してはいけません。
+
+## 実際の Issue を取得する
+
+リポジトリの **Issues** タブで **Allow users to filter games by category and publisher** を探し、URL をコピーします。テンプレートのファイル名や Issue 番号が、自分のコピーの Issue を特定できるとは限りません。
+
+現在の Issue では、次のことが求められています。
+
+- 1つ以上のカテゴリを選択する。
+- パブリッシャーで絞り込み、カテゴリと組み合わせる。
+- 両方のフィルターをサポートするデータアクセス用ヘルパーを `src/lib/` に用意する。
+- キーボードナビゲーション、適切な ARIA、見えるフォーカス状態、`data-testid` 属性を持つ、アクセシブルな操作部品を用意する。
+- ヘルパーには Vitest の単体テスト、フィルターの動作には Playwright の E2E テストによるカバレッジを用意する。
+
+実際の Issue を正しい要件の情報源として読んでください。演習7の QA プロンプトで使えるよう、URL と承認した追加の取り決めを保存します。
+
+## コーディングの前に計画する
+
+Shift+Tab で **Plan** モードを選ぶか、`/plan` で開始します。Issue のプレースホルダーを置き換えて送信します。
+
+```plaintext
+次の Issue に記載されたフィルター機能を計画してください: 。変更を提案する前に、Issue、リポジトリの指示、既存のデータアクセス用ヘルパー、UI、テストを読んでください。現在のチェックアウトを基準とし、パブリッシャーのヘルパーがすでに作成されていると仮定しないでください。
+
+複数カテゴリの選択、パブリッシャーのフィルター、それらの組み合わせ、データアクセスの対応、アクセシブルな操作部品、単体テストと E2E のカバレッジを扱ってください。複数カテゴリの組み合わせ方、フィルターの解除、結果が空の場合など、未指定の動作は確認を求め、決定事項を承認済みの計画とともに記録してください。不要なサーバー API を導入せず、静的な Astro のアーキテクチャを維持してください。
+
+現在のブランチでの実装を計画し、必要な単体テストと E2E テスト、npm run lint、npm run test:unit、npm run test:e2e、npm run typecheck:all による検証を含めてください。先に前提条件とサーバーの所有者を確認し、ソフトウェアのインストールや無関係なプロセスの停止はせず、阻害要因を報告してください。
+
+計画に次の実行境界を含めてください。私が承認した後は、フィルター機能と必要なテストだけを実装し、チェックを実行してから、レビューできるように停止してください。quality-checks スキル、QA エージェント、後のワークショップで扱うほかの資産は作成しないでください。ブランチの変更、コミット、プッシュ、PR の作成やマージはしないでください。
+
+私が計画を承認するまで、アプリケーションコードの編集や実装の開始はしないでください。
+```
+
+追加の質問に回答します。後から隠れた受け入れ条件を追加してはいけません。実装、ブラウザーチェック、QA ですべて同じ要件を使えるよう、合意した回答を Issue の URL とともに保存します。
+
+計画で、データ層と UI の変更、テスト、アクセシブルな操作部品、マージしたドキュメント規約を確認します。4つすべてのチェック、レビューのための停止条件、後のワークショップの資産・ブランチ変更・コミット・プッシュ・PR 操作の禁止が明記されていることを確認してください。制限や条件が欠けている場合、または Issue の範囲外の作業を提案している場合は、承認前に修正を依頼します。
+
+## Autopilot を明示的に承認する
+
+計画にレビュー済みの範囲と実行境界が含まれていることを確認してから、計画の承認オプション **Accept plan and build on autopilot** を使います。使用中のバージョンで文言が異なる場合は、**Autopilot** に切り替えるオプションを明示的に選択し、モード表示を確認します。承認すると、範囲を限定した計画の実行が始まります。作業開始後のプロンプトで制限を追加することを前提にしてはいけません。
+
+> [!CAUTION]
+> Autopilot はツールの権限だけでなく、作業の継続を制御します。選択前に権限ダイアログを確認してください。完全な権限ではツール、パス、URL にアクセスできます。制限付きの権限では、承認が必要な操作が阻止される場合があります。Codespace の使用は、シークレットの公開や無関係なリソースの変更の許可ではありません。スキップしたチェックを成功扱いにせず、阻止されたアクセスを意識して解決してください。
+
+作業とコマンドの結果を監視します。Autopilot は、計画を完了する前に継続回数の上限で一時停止したり、阻害要因を報告したりする場合があります。同じ範囲を維持し、その状態を確認してから継続を承認します。
+
+## Interactive に戻ってレビューする
+
+実装が停止したら、追加のプロンプトを送る前に Shift+Tab で **Interactive** モードに戻します。タスク後も Autopilot が有効な場合があります。自動的に戻ったと仮定してはいけません。
+
+`/diff` を入力し、変更されたすべてのファイルを確認します。実装を Issue と承認した追加の取り決めに照らし合わせます。
+
+- 合意どおりに複数カテゴリを選択し、パブリッシャーで絞り込み、それらを組み合わせられますか。
+- データアクセス用ヘルパーは、UI を変えるだけでなく、実際にフィルターをサポートしていますか。
+- 操作部品には意味のあるラベル、キーボード対応、見えるフォーカス、安定したテスト識別子がありますか。
+- 既存のアサーションを弱めずに、合意した解除操作や空の結果も含めて、テストで動作を検証していますか。
+- コードはドキュメント規約に従い、静的アプリのアーキテクチャを維持していますか。
+
+4つすべての npm チェックの証拠をレビューします。`quality-checks` はまだ作成していないため、チェックは直接実行します。Playwright の E2E 設定はビルドしてプレビューを配信します。古い内容を再利用しないよう、スイートの実行前に自分で起動した開発サーバーだけを停止してください。ポート競合やブラウザーの不足は解消すべき阻害要因であり、別のプロセスを停止したり成功を主張したりする理由ではありません。
+
+必要に応じて範囲を絞った修正を依頼し、影響するチェックを再実行して、最終実装の検証をすべて完了します。ブラウザーでの直接観察は演習6で扱います。今回の自動検証とは目的が異なります。
+
+## 実装のチェックポイントを保存する
+
+差分と結果に問題がなければ、ローカルのチェックポイントを承認します。
+
+```plaintext
+現在の差分と検証結果をレビューしてください。レビュー済みのフィルター機能の実装とテストだけを含むチェックポイントコミットを作成してください。現在のフィルター機能のブランチとチェックアウトを維持してください。まだプッシュ、PR の作成、スキルや QA エージェントの作成はしないでください。
+```
+
+テストしたリビジョンを記録し、Issue の URL と承認した追加の取り決めを保持します。**Interactive** を維持し、この同じチェックアウトで[演習 5 - quality-checks スキルを作成して使用する][next-lesson]に進みます。
+
+## リソース
+
+- [Autopilot モードと権限][autopilot]では、自律的な継続と Interactive に戻る方法を説明しています。
+- [Copilot CLI コマンドリファレンス][cli-reference]には、現在のモード操作とコマンドが掲載されています。
+
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
+[autopilot]: https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/ja-jp/cli/4-mcp.md b/docs/ja-jp/cli/4-mcp.md
deleted file mode 100644
index 9b3541fa..00000000
--- a/docs/ja-jp/cli/4-mcp.md
+++ /dev/null
@@ -1,158 +0,0 @@
----
-title: "演習 4 - Playwright MCP サーバーで機能をテストする"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-Copilot CLI でフィルタリング機能を生成したので、pull request を開く前に、ブラウザーで正しく動作することを確認する必要があります。自分でアプリを操作して確認する代わりに、**Playwright MCP server** を接続し、Copilot に実際のブラウザーを操作させて機能をテストしてもらいます。
-
-この演習では、次のことを行います。
-
-- Model Context Protocol（MCP）とは何か、そして MCP server がどのように Copilot CLI を拡張するかを理解する。
-- Playwright MCP server を Copilot CLI に追加する。
-- ブラウザーでフィルタリング機能を手動テストするよう Copilot に依頼する。
-
-## Model Context Protocol (MCP) とは
-
-[Model Context Protocol (MCP)](https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/) は、AI agent が外部ツールやサービスと通信するための方法を提供します。MCP を使用すると、AI agent は外部ツールやサービスとリアルタイムでやり取りできます。これにより、最新情報にアクセスし（resources を利用）、代わりに操作を実行できます（tools を利用）。
-
-これらの tool や resource には、MCP server を通じてアクセスします。MCP server は AI agent と外部ツールやサービスの間をつなぐブリッジとして機能します。MCP server は、AI agent と外部ツール（既存の API や NPM package のようなローカル ツールなど）の通信を管理します。各 MCP server は、AI agent がアクセスできる別々の tool と resource のセットを表します。
-
-すでに広く使われている MCP server として、次のようなものがあります。
-
-- **[GitHub MCP Server](https://github.com/github/github-mcp-server)**: GitHub リポジトリを管理するための API セットにアクセスできます。新しいリポジトリの作成、既存リポジトリの更新、issue や pull request の管理などを AI agent が実行できます。
-- **[Playwright MCP Server](https://github.com/microsoft/playwright-mcp)**: Playwright を使ったブラウザー自動化機能を提供します。Web ページへの移動、フォーム入力、ボタン選択などを AI agent が実行できます。
-
-ほかにも、さまざまな tool や resource へのアクセスを提供する MCP server が多数あります。GitHub は、エコシステムの発見性とコントリビューションを高めるために [MCP registry](https://github.com/mcp) を公開しています。
-
-> [!CAUTION]
-> セキュリティの観点では、MCP server はプロジェクト内のほかの依存関係と同じように扱ってください。MCP server を使用する前に、ソース コードを慎重に確認し、公開元を検証し、セキュリティ上の影響を検討してください。信頼できる MCP server のみを使用し、機密性の高い resource や操作へのアクセスを与える際は慎重に判断してください。
-
-> [!NOTE]
-> [GitHub MCP server][github-mcp-server] は Copilot CLI に**組み込まれています**。そのため、追加設定なしで利用でき、ワークショップ全体を通して Copilot がリポジトリを読み書きできていたのはこの server によるものです。この演習では、Copilot にブラウザーを与えるために 2 つ目の server として Playwright を追加します。
-
-## Playwright MCP server を追加する
-
-server を追加する最も手早い方法は、対話式の `/mcp add` コマンドです。ここでは、Copilot が制御できるブラウザーを提供する [Playwright MCP server][playwright-mcp-server] を登録します。
-
-> [!TIP]
-> **Copilot CLI セッションを開始する**
->
-> 以下の演習を始める前に、codespace に戻ってターミナルを開きます（まだ開いていない場合は Ctrl+\`）。次に、`--yolo` と `--enable-all-github-mcp-tools` を付けて Copilot CLI を起動します。
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 新しく開始する代わりに、このプロジェクトの直近のセッションを引き継ぐには `copilot --yolo --enable-all-github-mcp-tools --continue` を実行します。前の演習から Copilot CLI がすでに実行中であれば、`/clear` を送ってクリーンな会話を開始してください。
->
-> `--enable-all-github-mcp-tools` を付けると、現在のセッションで GitHub MCP の読み取り / 書き込みツールが有効になります。これにより、ワークショップの流れの中で Copilot がバックログを読み取り、pull request を開けるようになります。
-
-> [!CAUTION]
-> `--yolo` は完全な自動権限（`--allow-all-tools`、`--allow-all-paths`、`--allow-all-urls`）を有効にします。Codespace や VM のような分離された環境でのみ使用し、日常的な開発の既定値として alias しないでください。詳しくは [Allowing and denying tool use][allow-all-warning] を参照してください。
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. Copilot CLI セッションで、次を入力します。
-
- ```text
- /mcp add
- ```
-
-2. 設定フォームが表示されます。Tab でフィールド間を移動し、次のように入力します。
-
- - **Server Name**: `playwright`
- - **Server Type**: **Local**（**STDIO** とも表示されます）を選択する
- - **Command**: `npx @playwright/mcp@latest --headless`
- - **Tools**: server のすべての tool を許可するため、`*` のままにする
-
-3. Ctrl+S を押して保存します。server は追加され、再起動なしですぐに利用できます。
-
-`--headless` フラグを付けると、Playwright は表示ウィンドウなしでブラウザーを実行します。デスクトップ表示のない codespace 内ではこれが必要です。内部的には、server が `~/.copilot/mcp-config.json` に書き込まれます。
-
-```json
-{
- "mcpServers": {
- "playwright": {
- "type": "local",
- "command": "npx",
- "args": ["@playwright/mcp@latest", "--headless"],
- "tools": ["*"]
- }
- }
-}
-```
-
-4. MCP server の一覧を表示して、server が登録済みでアクティブであることを確認します。
-
- ```text
- /mcp show
- ```
-
-5. 組み込みの `github` server と並んで `playwright` が表示されるはずです。
-
-> [!NOTE]
-> Tailspin Toys プロジェクトでは、エンドツーエンド test にすでに Playwright を使用しています。そのため、Playwright が必要とするブラウザーは通常すでにインストールされています。後で Copilot からブラウザーが見つからないと報告された場合は、`npx playwright install chromium` を実行してから再試行してください。
-
-## Web サイトを起動する
-
-Playwright MCP server がテストを実行するには、対象となるアプリが起動している必要があります。Copilot CLI で作業している間も実行し続けられるよう、**別の**ターミナルで Astro の dev server を起動します。
-
-1. Ctrl+\` を選択して、codespace で新しいターミナルを開きます。
-2. Web サイトを起動します。
-
- ```bash
- npm run dev
- ```
-
-3. このターミナルはそのまま動かしておきます。`Astro server: http://localhost:4321` の表示が出たら、アプリの準備は完了です。
-
-## フィルタリング機能をテストする
-
-Copilot CLI セッションに戻り、Copilot に機能をテストするよう依頼します。
-
-[Playwright MCP server][playwright-mcp-server] は、Copilot に実際のブラウザーを操作させます。自分でアプリを操作して確認する代わりに、agent がページを開き、移動し、filter を適用し、その結果を読み取って要約できます。会話を離れずに、機能が期待どおりに動作することを確認する最も速い方法です。
-
-内部的には、Playwright MCP server はスクリーンショットではなく、ページの [accessibility tree][playwright-mcp-server] を基に動作します。つまり、agent はボタン、リンク、リスト項目などの構造化されラベル付けされた要素を、支援技術と同じように扱います。そのため、簡単な機能確認が、軽いアクセシビリティの健全性チェックも兼ねることになります。
-
-server を接続し、アプリを起動したら、次のように Copilot に依頼して、先ほど実装したフィルタリング機能を試してもらいます。
-
-```text
-Using the Playwright MCP server, open a browser to the running app at http://localhost:4321 and verify the new game filtering feature:
-
-1. Go to the games page and note how many games are listed.
-2. Apply a category filter and confirm the list updates to only show games in that category.
-3. Clear it, then apply a publisher filter and confirm the list updates to that publisher.
-4. Combine a category and a publisher filter and confirm the results respect both.
-
-Report what you observe at each step, and call out anything that does not behave as expected.
-```
-
-Copilot は Playwright MCP server 経由でブラウザーを起動し、各ステップを実行して、確認結果を報告します。その要約を issue の受け入れ条件と照らし合わせて読み、違和感があれば、追跡質問をしたり、pull request を開く前にコード修正を依頼したりしてください。
-
-> [!NOTE]
-> このテストでは、アプリが `http://localhost:4321` で動作している必要があります。dev server を停止していた場合は、プロンプトを送る前に再起動してください。Copilot が初めて Playwright MCP server を使う際には、ブラウザーのダウンロードが必要になることがあります。ブラウザーが見つからないと報告された場合は、`npx playwright install chromium` を実行して再試行してください。
-
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
-## まとめと次のステップ
-
-おめでとうございます。Playwright MCP server を使って、Copilot CLI で機能を手動テストできました。要点を振り返ると、次のことを行いました。
-
-- Model Context Protocol（MCP）とは何か、そして MCP server がどのように Copilot CLI を拡張するかを学ぶ。
-- `/mcp add` で Playwright MCP server を追加する。
-- Copilot にブラウザー操作を任せ、出荷前にフィルタリング機能を検証する。
-
-機能が正しく動作することを確認できたので、次の演習に進み、[agent skill の助けを借りて pull request を開く][next-lesson] ことができます。
-
-## リソース
-
-- [MCP とは何か、なぜいま注目されているのか][mcp-blog-post]
-- [Microsoft Playwright MCP Server][playwright-mcp-server]
-- [Copilot CLI に MCP server を追加する][cli-add-mcp]
-- [GitHub MCP Server][github-mcp-server]
-
-[previous-lesson]: ../3-generating-code/
-[next-lesson]: ../5-agent-skills/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[github-mcp-server]: https://github.com/github/github-mcp-server
-[cli-add-mcp]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
diff --git a/docs/ja-jp/cli/5-agent-skills.md b/docs/ja-jp/cli/5-agent-skills.md
index 60f0cca0..76ef5cdc 100644
--- a/docs/ja-jp/cli/5-agent-skills.md
+++ b/docs/ja-jp/cli/5-agent-skills.md
@@ -1,119 +1,93 @@
---
-title: "演習 5 - エージェント スキルを使う"
+title: "演習 5 - quality-checks スキルを作成して使用する"
+description: "再利用可能なシェルスクリプト付き品質チェックスキルを Copilot に作成させ、内容を確認してフィルター機能のブランチで実行します。"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
-アプリ開発では、build の生成、test の実行、pull request の作成といった繰り返し可能なタスクがよく発生します。**Agent skill** を使うと、Copilot やほかの AI agent に対して、それらのタスクをどのように実行すべきかを示すガイダンスを与えられます。skill は、agent が必要に応じて読み込める instruction、script、resource のフォルダーです。[Agent Skills は open standard][agent-skills-repo] であり、さまざまな agent が利用しています。そのため、同じ skill を Copilot Chat の agent mode、Copilot cloud agent、Copilot CLI、GitHub Copilot app の間で共有できます。
+フィルター機能を実装し、既存の npm コマンドでチェックしました。次は、これらのチェックを再利用可能な**エージェントスキル**にまとめます。演習4～8では同じフィルター機能のセッションとブランチを維持してください。この演習では pull request を作成しません。
-skill はプロジェクトの `.github/skills` フォルダー、またはグローバルな `~/.copilot/skills` に配置します。各 skill はフォルダー単位で、YAML frontmatter（`name` と `description`）を持つ `SKILL.md` ファイルと、その後に続く markdown の instruction で構成されます。
-
-```yaml
----
-name: make-contribution
-description: All changes to code must follow the guidance documented in the repository. Before any issue is filed, branch is made, commits generated, or pull request (or PR) created, a search must be done to ensure the right steps are followed. Whenever asked to create an issue, commit messages, to push code, or create a PR, use this skill so everything is done correctly.
----
-```
-
-skill には、script、asset、参照資料を含むサブフォルダーを追加することもできます。全体の構造は [agent skills specification][agent-skills-spec] で説明されています。
+この演習では、次のことを行います。
-> [!TIP]
-> skill は動的に読み込まれます。どの skill が適用されるかは、agent が `description` フィールドを基に判断します。明確でシナリオに即した説明にすることが、使われる skill と無視される skill を分けます。
+- カスタマイズを作成する前に **Interactive** モードに戻る。
+- Copilot に `quality-checks` を作成させ、確認のために停止させる。
+- 同梱のスクリプトを通じて4つすべてのチェックを実行し、単一のテストファイルを指定する引数が、そのファイルだけを選択することを実証する。
+- フィルター機能と同じブランチにスキルのチェックポイントを保存する。
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
-team の pull request が、定められた仕様に確実に従うよう skill を使う方法を見ていきましょう。
+## 指示、スクリプト、リソース
-## シナリオ
+スキルは、再利用可能なタスクの指示、実行可能なスクリプト、補助リソースをまとめたもので、エージェントが必要に応じて読み込みます。カスタムエージェントは、専門的な役割、指示、利用可能なツールを定義します。これらは補完関係にあります。カスタムエージェントは、スキルに同梱されたものを含め、スクリプトを実行できます。
-チームでは pull request（PR）に対して、次の要件を定めています。
+リポジトリのスキルは `.github/skills//SKILL.md` に配置し、`name` と `description` のフロントマターと Markdown の指示を持ちます。スクリプトやほかのリソースは、その隣に置きます。完成済みの答えをコピーせず、Copilot に `.github/skills/quality-checks/SKILL.md` と同梱のスクリプトを生成するよう依頼します。[Agent Skills 仕様][skill-spec]に形式が説明されています。
-- 明確な commit message にし、ファイルは論理的にグループ化する。
-- PR を作成する前に、すべての test が通過している必要がある。
-- 各 PR には次のセクションを含める必要がある。
- - 変更を行った理由の説明。
- - 変更したファイルの概要。
- - 重要なコード ブロックの抜粋。
- - 行った変更の詳細をまとめた説明。
+Copilot は検出したスキルの説明を使い、いつ読み込むかを判断します。すでに開いているセッションで新しいスキルがすぐ検出されるとは限りません。実行の節では、明示的に読み込む代替手順も示します。形式に移植性があっても、シェルやプロジェクトの前提条件は必要です。
-チームでは、Copilot を使ってコードや PR を生成しているため、AI ツールがこれらの要件に従うことを確実にしたいと考えています。
+## スキルを作成する
-この演習では、次のことを行います。
+プロンプトを送る前に **Interactive** モードに戻します。現在のチェックアウトとブランチを維持してください。古いテンプレートから始めてこのスキルがすでにある場合は、カスタマイズを上書きせず、確認して拡張します。
-- pull request 作成用に既存の skill を確認する。
-- AI agent がどのように skill を利用するかを学ぶ。
-- skill の助けを借りて、ガイドラインに沿った PR を作成する。
+```plaintext
+.github/skills/quality-checks/SKILL.md と、npm run lint、npm run test:unit、npm run test:e2e、npm run typecheck:all を呼び出す4本のスクリプトを作成してください。まず package.json、README、テスト設定、リポジトリの指示を読んでください。
-## skill を実行する
+現在の環境を判別してください。macOS/Linux/WSL なら Bash の .sh スクリプト、ネイティブ Windows なら PowerShell の .ps1 スクリプトだけを作成し、不明な場合は質問してください。両方を作成しないでください。ラッパーの役割は、自分自身の配置場所からリポジトリのルートを解決し、そこにこのプロジェクトの package.json があることを検証して npm を呼び出すことに限定してください。不正なルートでは明確なエラーで失敗させてください。どの作業ディレクトリからでも、空白を含むパスでも動作するようにしてください。出力と失敗時の終了コードを維持し、PowerShell のネイティブコマンドの失敗も扱ってください。npm の区切り文字 -- は1回だけ挿入し、呼び出し側は余分な -- を付けずにツールの引数を直接渡すようにしてください。ポートやプロセスは管理しないでください。
-skill は、agent が必要だと判断したときに動的に読み込まれます。どの skill を使うかの判断は、`SKILL.md` ファイル内の description によって決まります。そのため、skill の用途を明確に定義した説明を書くことが重要です。
+SKILL.md に name と description のフロントマター、4本のラッパーを実行する指示、前提条件、トラブルシューティング、既存の単体テストファイル1つを使う例を含む移植可能な呼び出し例を記載してください。Bash の例はすべて bash を明示的に呼び出し、PowerShell の実行ポリシーは決して回避しないでください。Playwright のサーバー再利用について説明してください。停止してよいのは自分で実際に起動したサーバーだけとし、それ以外の場合は質問するようにしてください。
-## PR skill を確認する
+スキルと必要なスクリプトだけを作成してください。チェックや調査用の試行、インストール、アプリケーションコードの変更、コミット、PR の作成はしないでください。内容を確認できるよう、そこで停止してください。
+```
-Tailspin Toys には PR 作成に関する要件があるため、AI ツールがこれらのガイドラインに従った PR を生成できるように skill が用意されています。どのような動作をするか理解するために、その skill を確認しましょう。
+## スキルを確認する
-1. `.github/skills/make-contribution/SKILL.md` を開きます。
-2. name と description を確認します。description では、pull request の作成や commit の作成を求められたときに使うべき scenario が示されていることに注目してください。
-3. skill 全体を読みます。branch の作成方法、commit の作り方、pull request の内容に関するルールが定義されていることを確認します。
+1. エディターで `.github/skills/quality-checks/SKILL.md` と同梱のスクリプトを開き、差分を確認します。
+2. `name` と `description` がスキルの内容と適用する場面を説明しているか確認します。メタデータだけでなく、指示も読んでください。
+3. 実行手順が、lint、単体テスト、E2E、型チェックのために `.github/skills/quality-checks/` 以下の同梱スクリプトを実際に呼び出すことを確認します。
+4. 各ラッパーについて、スクリプトの場所を基準にしたルートの解決と、導き出したディレクトリにこのチェックアウトで使う対象の `package.json` があることを明示的に確認する処理を調べます。npm が祖先ディレクトリを探索してコマンドが成功しても、ルートが正しい証拠にはなりません。パスの引用符、引数の転送、出力の表示、失敗時の終了処理を確認してください。PowerShell はネイティブ npm コマンドの失敗を伝播する必要があります。
+5. 記載された単体テストの1ファイルだけを実行する例を確認します。npm の区切り文字 `--` はラッパーが挿入するため、呼び出し側は別の区切り文字を付けず、対象ツールの引数を直接渡します。再利用する指示には、マシン固有のチェックアウトの絶対パスを含めないでください。何かを実行する前に、不足を修正するよう Copilot に依頼してください。
+6. スクリプトは、ルートとマニフェストの検証、および既存の npm チェックの実行に限定します。ポートやプロセスに関する判断は、シェルのプロセス管理コードではなく SKILL.md に置きます。停止できるのはエージェントが実際に起動したサーバーだけであることを確認してください。作業ディレクトリやプロセス名の一致だけでは、所有者であると判断できません。成果物にはスキル、必須のラッパー、必要な共有ヘルパーだけを含め、一時的な調査用ファイルやデバッグ用ファイルを残さないようにします。
-## skill を使う
+> [!NOTE]
+> 現在の Tailspin Toys には Node.js 22.13 以降、プロジェクトの依存関係、E2E チェック用の Playwright Chromium が必要です。チェックアウトの README と `package.json` で前提条件を確認してください。前提条件の不足や PowerShell の実行ポリシーによる制限は、承認を得て解消する必要があります。自動インストール、ポリシーの回避、断りなく npm の直接実行に切り替える方法で対処してはいけません。
-先ほど触れたとおり、skill は Copilot CLI によって自動的に呼び出されます。そのため、必要なのは Copilot に PR を作成するよう依頼することだけです。
+## スキルを実行する
-> [!TIP]
-> **Copilot CLI セッションを開始する**
->
-> 以下の演習を始める前に、codespace に戻ってターミナルを開きます（まだ開いていない場合は Ctrl+\`）。次に、`--yolo` と `--enable-all-github-mcp-tools` を付けて Copilot CLI を起動します。
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 新しく開始する代わりに、このプロジェクトの直近のセッションを引き継ぐには `copilot --yolo --enable-all-github-mcp-tools --continue` を実行します。前の演習から Copilot CLI がすでに実行中であれば、`/clear` を送ってクリーンな会話を開始してください。
->
-> `--enable-all-github-mcp-tools` を付けると、現在のセッションで GitHub MCP の読み取り / 書き込みツールが有効になります。これにより、ワークショップの流れの中で Copilot がバックログを読み取り、pull request を開けるようになります。
+前の演習の開発サーバーが停止していることを確認します。Playwright は E2E 用にビルドしてプレビューを配信しますが、ローカルの設定ではポート `4321` のサーバーを再利用できます。別のチェックアウトのサーバーは、この機能の有効な証拠にはなりません。
-> [!CAUTION]
-> `--yolo` は完全な自動権限（`--allow-all-tools`、`--allow-all-paths`、`--allow-all-urls`）を有効にします。Codespace や VM のような分離された環境でのみ使用し、日常的な開発の既定値として alias しないでください。詳しくは [Allowing and denying tool use][allow-all-warning] を参照してください。
+Copilot CLI に `/quality-checks` が表示される場合は、選択して検出済みのスキルを明示的に呼び出し、以下のリクエストを含めます。検出されていない場合は、このセッションで同じリクエストを直接送信します。この演習では、スキルを読み込む方法を代替手順として使用できます。
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. 次のプロンプトを使って、Copilot に PR を作成するよう依頼します。
+```plaintext
+.github/skills/quality-checks/SKILL.md を読み、その指示に従ってこのチェックアウトのフィルター機能を検証してください。まず各ラッパーのコードを調べ、npm による祖先ディレクトリのパッケージ探索に依存せず、このチェックアウトで使う対象の package.json を含むディレクトリを導き出し、不正なルートでは明確に失敗する処理があることを確認してください。失敗を再現するために、リポジトリのファイルを移動、名前変更、削除、変更しないでください。lint、単体テスト、エンドツーエンドテスト、型チェック用の同梱スクリプトを実際に実行してください。記載された単体テストの1ファイルだけを実行する例も実行してください。npm の区切り文字 -- はラッパーが挿入するため、対象ツールの引数を直接渡してください。テストランナーの結果から指定したファイルだけが実行されたことを確認し、そのファイル名と実行されたテストファイル数を報告してください。引数の表示や終了コード 0 だけでは、正しく選択された証拠にはなりません。
- ```
- Can you please create a pull request for me!
- ```
+各スクリプトの呼び出しと結果を、失敗、スキップしたチェック、不足する前提条件も含めて報告してください。使用できないスキルのスクリプトを、断りなく npm コマンドの直接実行で置き換えないでください。テスト対象のチェックアウトとサーバーを特定し、自分で起動したサーバーだけを停止してください。インストールや別のプロセスの停止前には確認してください。アプリケーションコードやブランチの変更、コミット、プッシュ、pull request の作成はしないでください。
+```
-2. Copilot がリクエストを受け付けます。しばらくすると、Copilot が **make-contribution** skill を利用していることが表示されます。
+ツールの呼び出しと出力を確認します。4つすべてのスクリプトを実際に実行する必要があります。チェックの説明やスキップされたチェックは成功ではありません。単一ファイルの例では、指定したファイル名をランナーの実際のファイル別結果と報告された件数に照らし合わせ、そのファイルだけが実行されたことを確認します。ほかのファイルも実行された場合は、引数の表示や終了コード 0 では不十分です。失敗は有用な証拠です。スキルを修正するか、承認を得てセットアップの阻害要因を解消し、影響するチェックを再実行します。無関係なプロセスを停止したり、ポート競合を強引に解消したりしてはいけません。
-3. その後、Copilot は skill の instruction に従います。まず test を実行し、その後 branch、commit、最終的には PR を作成します。
-4. PR が作成されたら、リポジトリに戻って PR を開きます。セクションが skill で定められたガイドラインに従い、チームの要件に一致していることを確認してください。
-5. 次の演習に進む前に、このフィルタリング PR とアクセシビリティ作業を分けておけるよう、ローカル workspace を `main` から新しい branch にリセットします。
+## チェックポイントを保存する
- ```bash
- git checkout main
- git pull
- git checkout -b accessibility-cli
- ```
+スキルと結果をレビューしたら、ローカルのチェックポイントを承認します。
-## まとめと次のステップ
+```plaintext
+現在の差分をレビューし、quality-checks スキルのファイルだけのチェックポイントコミットを作成してください。既存のフィルター機能のブランチを維持してください。プッシュや pull request の作成はしないでください。
+```
-agent skill の助けを借りて、文書化された要件に沿う新しい PR を作成できました。次のことを行いました。
+スキルのファイルは、演習8の機能 PR に、フィルター機能、QA プロファイル、関連テストと一緒に含めます。この同じチェックアウトで[演習 6 - Playwright MCP で機能を検証する][next-lesson]に進みます。
-- pull request 作成用に既存の skill を確認する。
-- AI agent がどのように skill を利用するかを学ぶ。
-- skill の助けを借りて、ガイドラインに沿った PR を作成する。
+## ほかのスキルの例
-skill はタスク向けに最適ですが、より高度な作業には [カスタム エージェント][next-lesson] を活用したくなります。次はそれを確認しましょう。
+これらのコミュニティの例は参考資料であり、追加のタスクではありません。採用する前に前提条件と動作を確認してください。
-## リソース
+- [コントリビューションのワークフロー: `make-repo-contribution`][contribution-example]。
+- [要件文書: `prd`][prd-example]。
+- [図と同梱のエクスポートスクリプト: `drawio`][drawio-example]。
+- [ブラウザーテスト: `webapp-testing`][browser-example]。
-- [Agent Skills について][about-agent-skills]
-- [Agent Skills 仕様][agent-skills-spec]
-- [Agent Skills リポジトリ][agent-skills-repo]
-- [awesome-copilot の Agent Skills][awesome-copilot-skills]
+上流のコントリビューション例の名前は `make-repo-contribution` です。古い Tailspin テンプレートでは、異なる名前の `make-contribution` を使用していました。このワークショップは、どちらのコントリビューション用スキルにも依存しません。
-[previous-lesson]: ../4-mcp/
-[next-lesson]: ../6-custom-agents/
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[awesome-copilot-skills]: https://github.com/github/awesome-copilot/tree/main/skills
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/ja-jp/cli/6-custom-agents.md b/docs/ja-jp/cli/6-custom-agents.md
deleted file mode 100644
index 0398cbe5..00000000
--- a/docs/ja-jp/cli/6-custom-agents.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: "演習 6 - GitHub Copilot CLI のカスタム エージェント"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-## custom agent とは
-
-GitHub Copilot の [カスタム エージェント][custom-agents-concept] を使うと、開発ワークフロー内の特定のタスクや領域に合わせた専門的な AI アシスタントを作成できます。リポジトリの `.github/agents` フォルダー内にある markdown ファイルで agent を定義することで、focused instruction、best practice、コーディング パターン、ドメイン固有の知識を Copilot に与え、特定の種類の作業をより効果的に進められるようにできます。チームは自分たちの専門知識を再利用可能な agent として定義できます。たとえば、[WCAG][wcag] への準拠を徹底するアクセシビリティ agent、secure coding practice に従うセキュリティ agent、一定の test pattern を保つ testing agent などです。
-
-custom agent は、プロジェクトの `.github/agents` フォルダー、またはグローバルな `~/.copilot/agents` にある markdown ファイルで定義します。各ファイルには、少なくとも `name` と `description` を含む YAML frontmatter があり、その後に agent の振る舞い、専門性、instruction を定義する markdown プロンプトが続きます。
-
-### custom agent と agent skill の比較
-
-custom agent と [agent skill][agent-skills-concept] には、概念的に重なる部分があります。どちらも主に markdown ファイルで定義され、AI にどのように作業すべきかを伝えます。最も分かりやすい区別は、**custom agent** は作業者で、**skill** はツールだということです。
-
-custom agent には独自の context window があり、作業を進める中で skill（さらにはほかの agent）をオーケストレーションすることを前提に設計されています。このラボでは、アクセシビリティ custom agent がガイドラインに照らしてサイトをレビューし、更新します。その過程で、pull request ワークフロー用の skill や、test の実行と管理を行う skill などを呼び出すことがあります。
-
-> [!NOTE]
-> custom agent の書き方に、唯一の「正しい」方法はありません。AI 全般に言えることですが、自分の環境やシナリオに合う形を見つけるために、テストと反復を行ってください。
-
-[custom-agents-concept]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
-[agent-skills-concept]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[wcag]: https://www.w3.org/WAI/standards-guidelines/wcag/
-## シナリオ
-
-多くの Web アプリケーションは、すべてのユーザーにとって十分にアクセシブルとは言えず、現在作業している Web サイトも例外ではありません。アクセシビリティ上の不足を特定して解消するために、custom agent を使用します。
-
-Tailspin Toys は、自社のクラウドファンディング プラットフォームを、視覚能力や好みにかかわらずすべてのユーザーが利用しやすいものにしたいと考えています。最近のユーザー フィードバックでは、現在の dark theme はテキストと背景色のコントラストが不十分で読みにくいという指摘がありました。このアクセシビリティ上の懸念に対応するため、デザイン チームは、ユーザーがオン / オフを切り替えられる high-contrast mode の実装を求めています。
-
-アクセシビリティは重要であるため、できるだけ早く実装したいと考えています。そこで、機能生成のために custom agent を活用します。
-この演習では、次のことを行います。
-
-- custom agent を確認する。
-- custom agent を有効にし、Copilot CLI を使ってタスクを割り当てる。
-
-## アクセシビリティ custom agent を確認する
-
-アクセシビリティ用の custom agent は、すでに用意されています。Copilot をどのように導くのか理解するために、その内容を確認しましょう。
-
-1. `.github/agents/accessibility.md` を開きます。
-2. `name` フィールドと `description` フィールドを持つ YAML frontmatter を確認します。
-
-> [!CAUTION]
-> `name` と `description` を含む frontmatter は、custom agent に必須です。
-
-3. 続いて、次の内容が示されている各セクションを読みます。
- - アクセシブルな Web サイトのコードを生成するときの中核的な責務。
- - アクセシビリティのベスト プラクティス。
- - HTML、CSS、JavaScript のコード例。
- - よくある落とし穴やミスの一覧。
-## Copilot CLI で custom agent を使う
-
-Copilot CLI では、`/agent` コマンドを使って custom agent を開始できます。では、Web サイトに対してアクセシビリティの確認を実行しましょう。
-
-> [!TIP]
-> **Copilot CLI セッションを開始する**
->
-> 以下の演習を始める前に、codespace に戻ってターミナルを開きます（まだ開いていない場合は Ctrl+\`）。次に、`--yolo` と `--enable-all-github-mcp-tools` を付けて Copilot CLI を起動します。
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 新しく開始する代わりに、このプロジェクトの直近のセッションを引き継ぐには `copilot --yolo --enable-all-github-mcp-tools --continue` を実行します。前の演習から Copilot CLI がすでに実行中であれば、`/clear` を送ってクリーンな会話を開始してください。
->
-> `--enable-all-github-mcp-tools` を付けると、現在のセッションで GitHub MCP の読み取り / 書き込みツールが有効になります。これにより、ワークショップの流れの中で Copilot がバックログを読み取り、pull request を開けるようになります。
-
-> [!CAUTION]
-> `--yolo` は完全な自動権限（`--allow-all-tools`、`--allow-all-paths`、`--allow-all-urls`）を有効にします。Codespace や VM のような分離された環境でのみ使用し、日常的な開発の既定値として alias しないでください。詳しくは [Allowing and denying tool use][allow-all-warning] を参照してください。
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. Copilot CLI のプロンプト ウィンドウで `/agent` と入力し、Enter を押して agent の一覧を表示します。
-2. 利用可能な agent の一覧から **Accessibility agent** を選択します。
-3. 次のプロンプトを使い、アクセシビリティ agent に対してアクセシビリティ関連のバックログ項目をレビューし、修正を生成するよう依頼します。
-
- ```
- Perform an accessibility review of the site. Pull the related issue down from the repository for details. Implement a high-contrast mode toggle that persists the user's preference across page reloads. Ensure there are e2e tests for any updates made to the project. Then create a PR with the updates.
- ```
-
-4. Copilot がタスクの実行を開始します。まず issue を取得し、その後レビュー、更新の生成、最後に PR の作成へと進みます。PR を作成するときに、このプロジェクトの PR 用 skill を利用していることにも気づくはずです。
-
-> [!NOTE]
-> この処理には数分かかることがあります。ここまでに学んだ内容を振り返ったり、飲み物を楽しんだり、Copilot CLI で利用できる追加コマンドを扱う次のモジュールを先に読んだりするのによい時間です。
-
-## まとめと次のステップ
-
-このレッスンでは、GitHub Copilot の [カスタム エージェント][custom-agents] を確認しました。custom agent は、特定のタスクや領域に合わせた専門的な AI アシスタントです。custom agent を使うと、チームの専門知識や標準を再利用可能な agent に落とし込み、Copilot が特定の種類の作業をより効果的に行えるよう導けます。
-
-このレッスンで確認した内容は次のとおりです。
-
-- custom agent がどのように定義されるか。
-- Copilot CLI で custom agent を使う方法。
-
-次は、[いくつかの slash command][next-lesson] を確認し、Copilot CLI の追加テクニックを学びましょう。
-
-## リソース
-
-- [カスタム エージェント][custom-agents]
-- [リポジトリ用カスタム エージェントの作成][creating-custom-agents]
-- [awesome-copilot のカスタム エージェント][awesome-copilot-agents]
-- [organization で custom agent を使う準備][org-custom-agents]
-- [enterprise で custom agent を使う準備][enterprise-custom-agents]
-
-[previous-lesson]: ../5-agent-skills/
-[next-lesson]: ../7-slash-commands/
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[creating-custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/create-custom-agents
-[awesome-copilot-agents]: https://github.com/github/awesome-copilot/tree/main/agents
-[org-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-organization/prepare-for-custom-agents
-[enterprise-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/prepare-for-custom-agents
diff --git a/docs/ja-jp/cli/6-mcp-playwright.md b/docs/ja-jp/cli/6-mcp-playwright.md
new file mode 100644
index 00000000..0fc53872
--- /dev/null
+++ b/docs/ja-jp/cli/6-mcp-playwright.md
@@ -0,0 +1,83 @@
+---
+title: "演習 6 - Playwright MCP で機能を検証する"
+description: "MCP でブラウザーに接続し、観察したフィルターの動作を Issue と承認済みの計画に照らし合わせます。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+フィルター機能の実装と quality-checks スキルは、すでに自動検証を済ませています。次は Copilot にブラウザーを提供し、機能を直接観察するよう依頼します。この演習は **Model Context Protocol（MCP）** による操作の実証であり、テストスイート全体の再実行ではありません。
+
+同じフィルター機能のチェックアウトとブランチで **Interactive** モードを維持してください。MCP の設定で新しい機能マイルストーンを開始することはありません。
+
+## MCP が追加する機能
+
+[MCP][mcp-overview] は、サーバーを通じてエージェントを外部ツールやコンテキストに接続します。組み込みの GitHub MCP サーバーでは Issue と PR を扱えます。[Playwright MCP サーバー][playwright-mcp]は、ページを開く、アクセシブルな要素を確認する、移動する、操作部品を操作するといったブラウザーツールを提供します。
+
+ブラウザーのアクセシビリティスナップショットは、エージェントが操作部品を特定する助けになりますが、アクセシビリティへの完全な準拠を証明するものではありません。単なる「問題なさそう」という報告を受け入れず、実際の操作と観察結果を Issue の要件と比較してください。
+
+> [!CAUTION]
+> MCP サーバーはプロジェクトの依存関係と同様に扱い、有効にする前に提供元、ソース、権限、パッケージのダウンロードを確認してください。組織のポリシーによって、実行できるサーバーが制限される場合があります。コミットする設定に認証情報を入れたり、演習を終えるためだけに未知のツールを承認したりしてはいけません。
+
+## Playwright MCP を設定する
+
+1. 既存の CLI セッションで `/mcp` を入力して設定済みサーバーを確認します。動作する Playwright の設定があれば、重複して追加せず再利用します。
+2. 必要に応じて `/mcp add` を入力し、Tab でフォーム内を移動します。
+3. **Server Name** を `playwright`、**Server Type** を **STDIO**（または **Local**）、**Command** を `npx @playwright/mcp@latest --headless` に設定します。
+4. 確認済みのこのブラウザーサーバーでは、**Tools** を `*` に設定します。これでツールが利用可能になりますが、CLI の権限制御を置き換えるものではありません。
+5. パッケージと起動コマンドを確認してから、Ctrl+S を押して保存します。登録するとサーバーが起動し、パッケージがダウンロードされる場合があります。このセットアップを意識して承認し、パッケージの確認プロンプトに対応してください。
+6. `/mcp show playwright` を入力し、サーバーが接続済みで、ブラウザーツールを利用できることを確認します。
+
+ヘッドレスブラウザーにはデスクトップウィンドウが不要なため、Codespaces に適しています。対話形式の追加手順は設定を `~/.copilot/mcp-config.json` に保存し、CLI の再起動なしでサーバーを利用可能にします。これはユーザー設定であり、機能の PR に含めるファイルではありません。[MCP セットアップガイド][mcp-setup]には、各フィールドと設定の取得元が説明されています。
+
+> [!NOTE]
+> プロジェクトの E2E 依存関係と MCP ブラウザーは関連していますが、異なるセットアップが必要な場合があります。ブラウザーやシステム依存関係が不足している場合は、実際のエラーを確認し、承認を得て該当する前提条件を解消してください。ブラウザーを自動でインストールしたり、サーバーが接続済みならブラウザーも起動できると判断したりしてはいけません。
+
+## 正しいアプリを起動する
+
+同じフィルター機能のチェックアウトで別のターミナルを開きます。ディレクトリとブランチを確認し、アプリを起動します。
+
+```bash
+pwd
+git branch --show-current
+npm run dev
+```
+
+サーバー出力から実際のローカル URL を確認します。Codespace では MCP サーバーとアプリが同じ環境で実行されるため、ブラウザー向けの転送 URL が必要だと決めつけず、通常は `http://localhost:4321` となるローカル URL を使います。
+
+ポートが使用中の場合や Astro が別のポートを選んだ場合は、サーバーの所有者を確認してから進みます。所有者不明のサーバーを再利用したり停止したりしてはいけません。自分で起動したプロセスの URL を使い、テスト中はそのターミナルを開いておきます。
+
+## フィルターの動作を観察する
+
+プレースホルダーを、実際の Issue の URL、演習4で承認した追加の取り決め、アプリの URL に置き換えます。
+
+```plaintext
+設定済みの Playwright MCP サーバーを使い、次の Issue に照らしてフィルター機能を検証してください: 。計画時に承認した追加の取り決めは次のとおりです: <合意した追加の取り決めを貼り付けるか、なければ none と記入>。このチェックアウトのアプリは で実行されています。結果を利用する前に、テスト対象のチェックアウト、ブランチ、サーバーを確認してください。
+
+ゲームページを開き、フィルター未適用の状態を記録し、1つのカテゴリ、次に複数のカテゴリを選択してください。パブリッシャーのフィルターを適用し、カテゴリとパブリッシャーの選択を組み合わせてください。承認済みの条件に従って、フィルターの解除と結果が空になる場合の動作を確認してください。操作部品のラベル、キーボード操作、見えるフォーカスを確認してください。表示された結果を選択したフィルターと元のデータに照らし合わせ、操作部品が変わっただけで成功と判断しないでください。
+
+実際のブラウザーツールを操作し、各条件について観察した内容を報告してください。失敗と証拠の不足は明示してください。このブラウザー演習のためだけにテストスイート全体を再実行したり、アプリケーションコードを変更したり、テストやカスタマイズを作成したり、ブランチを変更したり、コミット、プッシュ、PR の作成をしたりしないでください。インストールや別のプロセスの停止前には確認してください。
+```
+
+ブラウザーツールの呼び出しと報告を確認します。Copilot は実際に複数カテゴリを選び、パブリッシャーと組み合わせたでしょうか。返されたゲームは合意した動作と一致しているでしょうか。報告では、ブラウザーで観察できる動作と、データ層や自動テストのカバレッジを区別しているでしょうか。
+
+失敗があれば、観察した動作を記録します。範囲を絞ったアプリケーションの修正は別途承認し、影響するブラウザーチェックと自動チェックを再実行します。実装に合わせて受け入れ条件を変更したり、古い証拠を変更後のコードの検証として扱ったりしてはいけません。
+
+## 自分のサーバーを停止して次に進む
+
+開発サーバーを起動したターミナルで Ctrl+C を押して停止します。Playwright MCP の設定は利用可能なままにします。演習7では、新しいブラウザー観察と自動 E2E チェックを調整して実行します。その際、古い開発サーバーや別のチェックアウトのアプリを再利用してはいけません。
+
+QA プロファイルを作成する前も **Interactive** を維持します。別の PR やブランチを作らずにブラウザーの動作を観察できました。次は[QA エージェントを作成して使用し][next-lesson]、要件、カバレッジ、スキル、最終的な証拠をまとめます。
+
+## リソース
+
+- [Copilot CLI に MCP サーバーを追加する][mcp-setup]では、セットアップと管理を説明しています。
+- [Microsoft Playwright MCP][playwright-mcp]では、ブラウザーの設定とツールを説明しています。
+- [GitHub MCP レジストリ][mcp-registry]には、検討できるほかのサーバーが掲載されています。
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-overview]: https://docs.github.com/copilot/concepts/context/mcp
+[mcp-setup]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
+[playwright-mcp]: https://github.com/microsoft/playwright-mcp
+[mcp-registry]: https://github.com/mcp
diff --git a/docs/ja-jp/cli/7-qa-agent.md b/docs/ja-jp/cli/7-qa-agent.md
new file mode 100644
index 00000000..905bd520
--- /dev/null
+++ b/docs/ja-jp/cli/7-qa-agent.md
@@ -0,0 +1,77 @@
+---
+title: "演習 7 - QA エージェントを作成して使用する"
+description: "テストのカバレッジ、quality-checks スキル、ブラウザーで直接得た証拠を組み合わせる、要件を起点とした QA プロファイルを作成します。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+繰り返し実行できるチェックを実行し、Playwright MCP でフィルター機能を確認しました。次は**QA カスタムエージェント**を作成し、要件、カバレッジ、ブラウザーの証拠をまとめます。フィルター機能のセッション、チェックアウト、ブランチを維持してください。機能の PR は演習8で扱います。
+
+## QA プロファイルを作成する
+
+**Interactive** モードを維持します。プロファイルは専門家の役割と指示を定義し、スキルは再利用可能なタスクの指示、スクリプト、リソースをまとめます。QA エージェントは、自分で作成したスキルと設定済みの MCP ツールを置き換えるのではなく、利用します。
+
+次のプロンプトを送り、実行前に定義を確認します。
+
+```plaintext
+.github/agents/qa.agent.md に再利用可能な QA カスタムエージェントを作成してください。まずリポジトリの指示、package.json、テスト設定、.github/skills/quality-checks/SKILL.md を確認してください。プロファイルには有効な YAML フロントマターを付け、name を QA とし、description で使う場面を説明してください。モデルを固定したり tools リストを追加したりせず、ハーネスで利用可能なツールと権限を継承してください。エージェント定義だけを作成し、実行前に内容を確認できるよう停止してください。
+
+エージェントの指示では、すべての QA タスクを Issue とユーザーが提供した承認済みの受け入れ条件から始めることを必須にしてください。実装ではなく、これらの要件を正しい基準として扱ってください。要件が不足しているか曖昧な場合は質問してください。機能と既存のテストを確認し、各条件を適切な自動テストのカバレッジと観察可能な動作に対応付けてください。
+
+設定済みの Playwright MCP サーバーによるブラウザーの直接検証と、既存の quality-checks スキルおよび同梱スクリプトによる lint、単体テスト、エンドツーエンドテスト、型チェックの実行を必須にしてください。スキルが自動検出されていなければ明示的に読んでください。スキル、MCP ツール、前提条件、アクセスが不足している場合は、実行が阻害されていると報告してください。断りなく別のワークフローに置き換えたり、スキップしたチェックを成功扱いにしたりしないでください。テスト対象のチェックアウトとサーバーを特定し、別のワークツリーのサーバーを再利用せず、エージェントが起動したサーバーだけを停止してください。インストールや別のプロセスの停止前には確認してください。
+
+QA エージェントは、リポジトリの指示に従い、実際にカバレッジが不足している箇所に必要最小限のテストを追加できるようにしてください。カバレッジがすでに十分なら、追加のテストがないことも妥当です。アサーションを弱めたり、失敗するテストを無効にしたり、コードに合わせて受け入れ条件を変えたり、私の承認なしにアプリケーションコードを変更したりしないでください。変更後は影響するチェックを再実行し、変更後のリビジョンの最終検証を完了してください。各条件を証拠と成功・失敗・阻害の状態に対応付け、追加したテストまたは追加不要だった理由、4つすべてのチェック結果、未解決の不具合を示す簡潔な報告を必須にしてください。GO には必要なチェックと証拠がすべてそろっている必要があり、そうでなければ理由とともに NO-GO を報告してください。QA 中はブランチの変更、コミット、プッシュ、PR の作成やマージ、追加のエージェントやスキルの作成はしないでください。
+```
+
+## プロファイルを確認する
+
+エディターで `.github/agents/qa.agent.md` を開き、差分を確認します。`description` は必須です。この演習では、わかりやすい `name` として `QA` も指定します。固定された `model` や、勝手に作られたツール一覧がないことを確認します。`tools` を省略すると利用可能なツールを継承しますが、ハーネスの権限を回避するわけではありません。本番用のプロファイルでは、意図的にツールを制限できます。
+
+指示が要件から始まり、実際の MCP ブラウザー操作とスキルのスクリプトを要求し、妥当なテスト追加だけを許可し、阻害要因を正直に報告することを確認します。専門家のプロファイルもスキルも、別のコンテキストウィンドウやほかのエージェントのオーケストレーションを必要としません。
+
+## Issue に対して QA を実行する
+
+実行プロンプトは、プロファイルを読む既定のエージェントではなく、選択した **QA** カスタムエージェントに送るものです。別の機能ブランチを作成せず、同じチェックアウトで新しい CLI の会話を開始して新しいプロファイルを読み込みます。
+
+1. フィルター機能の Issue の URL と承認した追加の取り決めを保持します。現在のエージェントの完了を待ち、`/exit` を入力してターミナルに戻ります。
+2. `git branch --show-current` と `git status --short` で、フィルター機能のリポジトリのディレクトリと同じブランチにいることを確認します。ブランチの切り替えやワークツリーの作成はしないでください。
+3. リポジトリのプロファイルを指定して CLI を起動します。
+
+ ```shell
+ copilot --agent qa
+ ```
+
+4. 実行前に、CLI が選択済みのエージェントとして **QA** を表示していることを確認します。[CLI コマンドリファレンス][cli-reference]には `--agent` が説明されています。プロファイルを書いたり読んだりするだけでは有効化されません。選択に失敗した場合や、エージェントが設定済みの Playwright MCP ツールとスキルにアクセスできない場合は、一時停止して講師と阻害要因を解消してください。
+
+両方のプレースホルダーを、実際のフィルター機能の Issue の URL と、演習4で承認した追加の取り決めに置き換えます。Issue だけで要件が十分な場合は `none` を使います。前のエージェントの記憶に依存してはいけません。
+
+```plaintext
+次の Issue に照らしてフィルター機能を検証してください: 。計画時に承認した追加の受け入れ条件は次のとおりです: <合意した追加の取り決めを貼り付けるか、なければ none と記入>。
+
+Playwright MCP サーバーで動作を検証し、テストのカバレッジを確認して、不足するカバレッジに対してだけテストを追加し、quality-checks スキルを通じて検証を実行してください。証拠、チェック結果、阻害要因を報告してください。私の承認なしにアプリケーションコードを変更しないでください。コミットや pull request を作成しないでください。
+```
+
+## 証拠をレビューする
+
+レポートを Issue に照らし合わせます。各条件には、適切な自動テストのカバレッジと観察可能な動作が必要です。実際の Playwright MCP ツールの操作、チェックアウトとサーバーの識別情報、4つすべてのスキルスクリプトの結果を確認してください。ブラウザーチェックと自動 E2E で、古いサーバーや別のチェックアウトを再利用してはいけません。
+
+追加されたテストをレビューします。アサーションを弱めず、実際の不足を埋める必要があります。カバレッジが十分なら、新しいテストがないことが適切です。阻害や失敗による **NO-GO** の判定は有効な結果であり、証拠を省く許可ではありません。
+
+QA がアプリケーションの不具合を見つけた場合は、範囲を絞った修正を別途承認し、変更後のリビジョンで影響するチェックとブラウザー観察を再実行します。不足する前提条件やツールには、明示的な対処が必要です。古い証拠を変更後のコードの証明として扱ってはいけません。
+
+## チェックポイントを保存する
+
+QA が完了したら、Issue の URL、承認した追加の取り決め、テストしたリビジョン、ブラウザー観察、チェック結果を含むレポートを保持します。`/exit` を入力し、同じディレクトリとブランチから `--agent` を付けずに `copilot` を起動して通常の会話に戻ります。これらのコンテキストを再度渡してください。新しい会話は QA の会話の証拠を引き継ぎません。
+
+プロファイル、テストの変更、得られた証拠をレビューしたら、通常のエージェントに次のリクエストを送信します。
+
+```plaintext
+現在の差分をレビューし、QA エージェント定義と承認済みのテスト変更のチェックポイントコミットを作成してください。既存のフィルター機能のブランチを維持してください。プッシュや pull request の作成はしないでください。
+```
+
+フィルター機能、スキル、QA プロファイル、テスト、現在の検証の証拠をそろえて、[演習 8 - 機能の PR を作成してマージする][next-lesson]に進みます。
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/ja-jp/cli/7-slash-commands.md b/docs/ja-jp/cli/7-slash-commands.md
deleted file mode 100644
index b884222d..00000000
--- a/docs/ja-jp/cli/7-slash-commands.md
+++ /dev/null
@@ -1,178 +0,0 @@
----
-title: "演習 7 - GitHub Copilot CLI のスラッシュ コマンド"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-優れた CLI ツールと同様に、GitHub Copilot CLI には多くの slash command が用意されています。これらのコマンドは、高度な機能、「内部で何が起きているか」に関する情報、追加の設定オプションを提供します。すでに `/clear` でコンテキストのクリアを、`/mcp` で MCP server の確認を行いました。ここでは、`/context`、`/model`、`/share`、`/delegate` など、ほかの強力なコマンドを確認します。
-
-## シナリオ
-
-中核となる CLI フローは完了しました。ここからは追加機能として、セッションの共有、モデルの切り替え、[Copilot cloud agent][about-cloud-agent] へのタスク委任を見ていきます。
-
-この演習では次を使用します。
-
-- `/share` で GitHub gist を作成し、チームとセッションを共有する。
-- `/context` で、Copilot CLI が現在使用しているコンテキストを確認する。
-- `/model` で利用可能なモデルの一覧を確認し、必要に応じて別のモデルを選択する。
-- `/delegate` で、必要に応じてタスクを cloud agent に引き渡す。これには cloud agent が必要で、Copilot Student、Pro、Pro+、Business、Enterprise で利用できます。つまり Copilot Free を除くすべてのプランで利用可能です。
-
-## セッションを共有する
-
-AI ツールを含め、どのツールでも使いこなすにはスキルが必要です。チームで協力し、学びを共有し合うことが、全員の体験を改善し、より質の高いコードを生み出す最善の方法です。そのために、Copilot CLI には `/share` コマンドがあります。`/share` コマンドは、使用した prompt や Copilot がたどったロジックを含むセッションの詳細を、markdown ファイルまたは GitHub gist として生成できます。
-
-チームと共有できる GitHub gist を作成してみましょう。
-
-> [!TIP]
-> **Copilot CLI セッションを開始する**
->
-> 以下の演習を始める前に、codespace に戻ってターミナルを開きます（まだ開いていない場合は Ctrl+\`）。次に、`--yolo` と `--enable-all-github-mcp-tools` を付けて Copilot CLI を起動します。
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 新しく開始する代わりに、このプロジェクトの直近のセッションを引き継ぐには `copilot --yolo --enable-all-github-mcp-tools --continue` を実行します。前の演習から Copilot CLI がすでに実行中であれば、`/clear` を送ってクリーンな会話を開始してください。
->
-> `--enable-all-github-mcp-tools` を付けると、現在のセッションで GitHub MCP の読み取り / 書き込みツールが有効になります。これにより、ワークショップの流れの中で Copilot がバックログを読み取り、pull request を開けるようになります。
-
-> [!CAUTION]
-> `--yolo` は完全な自動権限（`--allow-all-tools`、`--allow-all-paths`、`--allow-all-urls`）を有効にします。Codespace や VM のような分離された環境でのみ使用し、日常的な開発の既定値として alias しないでください。詳しくは [Allowing and denying tool use][allow-all-warning] を参照してください。
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. Copilot CLI のプロンプト ウィンドウで、次のコマンドを送信します。
-
- ```
- /share gist
- ```
-
-2. 少し待つと、Copilot が gist を作成し、リンクを表示します。
-3. リンクの文字列をコピーします。
-4. 新しいブラウザー タブでそのリンクを貼り付け、gist を確認します。送信した prompt、使用した skill と agent、Copilot の思考過程、さらにローカルで実行したコマンドのコードと結果まで記録されていることに注目してください。
-
-`/share` が生成する gist と markdown ファイルは、コードがどのように生成されたかを文書化したり、望ましい結果を得るためにどのような操作を行ったかをチームと共有したりする用途に使えます。
-
-## Copilot CLI のコンテキストを確認する
-
-より大きなタスクや複雑なタスクに取り組むと、モデルの最大 context window に近づくことがあります。window の正確なサイズは、使用しているモデルや Copilot CLI のバージョンによって異なります。context window が上限に達すると、Copilot CLI は自動的に compact を実行し、情報を要約して、現在のタスクに不要と判断した内容を取り除きます。slash command を使えば、現在のコンテキストの状態を確認することも、手動で compact することもできます。では、context window を見てみましょう。
-
-1. Copilot CLI のプロンプト ウィンドウで、次のコマンドを送信します。
-
- ```
- /context
- ```
-
-2. 少し待つと、Copilot CLI が現在のコンテキストを視覚的に表現した表示を生成します。
-
- 
-
-3. 表示されているモデル名（画像と異なる場合があります）と、現在使用されている token の割合を確認します。その他の情報では、次の内容が示されています。
-
- | Title | Description |
- | ------------ | ------------------------------------------------------ |
- | System/Tools | instruction file、ファイル内容、tool 定義 |
- | Messages | 自分と Copilot の会話履歴 |
- | Buffer | Copilot CLI が応答生成のために確保している予約領域 |
- | Free space | 残りの空き領域 |
-
-4. 次の slash command を Copilot CLI に送信し、会話履歴を compact します。
-
- ```
- /compact
- ```
-
-5. 完了したら、次のコマンドを送信して現在のコンテキスト統計をもう一度表示します。
-
- ```
- /context
- ```
-
-6. コンテキストの変化を確認します。現時点では context window がまだ比較的小さいため、大きな変化は見られないかもしれません。
-
-> [!NOTE]
-> Copilot CLI は、コンテキストがいっぱいになると自動的に compact を実行します。容量が 100% に近づくと、その割合がプロンプト ウィンドウの上に表示されます。通常は非同期に compact を実行するため、処理中でも Copilot との対話を続けられます。ただし、処理中の操作が数秒間ブロックされる場合があります。
-
-### コンテキストに関するベスト プラクティス
-
-ほとんどのセッションでは、Copilot 自身が効率的にコンテキストを管理するため、特別な指示は必要ありません。ただし、状況によっては履歴を手動でクリアまたは compact したいことがあります。
-
-- アプリケーションの別の部分や、無関係なタスクに切り替える場合は、古い無関係なコンテキストで Copilot を混乱させないよう `/clear` を使って新しい会話を始められます。
-- 最大 context window に近づいている場合は、`/compact` を手動で実行して、そのタイミングを制御できます。
-
-> [!CAUTION]
-> 繰り返しになりますが、ほとんどの場合は Copilot が直接操作なしでコンテキストを管理します。古い情報のせいで少し混乱しているように見えるときや、これから無関係なタスクに切り替えるときに、手動コマンドの利用を検討してください。
-
-## モデルを選択する
-
-モデルにはそれぞれ異なる強みがあり、開発者によって好みも異なります。Copilot CLI では、使用したいモデルの一覧表示と選択ができます。
-
-1. 次の slash command を Copilot CLI に送信し、モデル一覧を表示します。
-
- ```
- /model
- ```
-
-2. モデルの一覧を確認します。各モデルには、名前とリクエスト単位のコスト修正値が表示されます。
-3. 必要であれば新しいモデルを選択します。終了したい場合は Esc を押します。
-
-> [!CAUTION]
-> Copilot CLI では、モデル選択が保持されます。
-
-## cloud agent に委任する（任意）
-
-ターミナルで作業を続けながら、時間のかかるタスクは Copilot cloud agent に任せたい場面があります。`/delegate` コマンドを使うと、現在の Copilot CLI セッションを GitHub.com に送信できます。cloud agent がそのセッションを引き継ぎ、非同期で作業し、完了すると pull request を開きます。
-
-> [!NOTE]
-> `/delegate` には cloud agent が必要です。これは Copilot Student、Pro、Pro+、Business、Enterprise で利用でき、Copilot Free では利用できません。アクセスできない場合は、このセクションを読んでからハンズオン手順はスキップしてください。
-
-1. ワークショップ全体のコンテキストがまとめて委任されないよう、まず現在のセッションをクリアします。
-
- ```
- /clear
- ```
-
-2. 小さく、スコープが明確な prompt を送信します。たとえば、バックログにある stretch goal のページネーションを委任できます。
-
- ```
- Implement pagination on the game list page so it shows a fixed number of games per page with Previous and Next controls, and add tests.
- ```
-
-3. 次の slash command を送信して、セッションを cloud agent に引き渡します。続いて、委任したい prompt を確認します。
-
- ```
- /delegate
- ```
-
-4. ブラウザーで [Copilot agents](https://github.com/copilot/agents) を開き、進捗を確認します。
-5. この harness では、pull request が完了するまで待つ必要はありません。後で戻って確認できます。非同期 agent 作業の管理をより深く知りたい場合は、[Cloud agent ハーネス][cloud-harness-link] に進んでください。
-
-## まとめと次のステップ
-
-Copilot CLI の slash command を使うと、設定の変更、セッションの共有、Copilot の内部状態に関する情報の取得ができます。このレッスンでは、次の機能を使ったり確認したりしました。
-
-- `/share` で GitHub gist を作成し、チームとセッションを共有する。
-- `/context` で、Copilot CLI が現在使用しているコンテキストを確認する。
-- `/model` で利用可能なモデルの一覧を確認し、必要に応じて別のモデルを選択する。
-- `/delegate` が cloud agent への任意の橋渡しになることを学ぶ。
-
-利用できる slash command はもちろんこれ以外にもあり、Copilot CLI にはまだ多くの機能があります。最後に、[ここまでに学んだことを振り返り][next-lesson]、学習を続けるための次のステップを確認して締めくくりましょう。
-
-## リソース
-
-- [Copilot CLI を使う][using-copilot-cli]
-- [Copilot CLI について][about-copilot-cli]
-- [Copilot CLI のコンテキスト管理][context-management]
-- [Copilot CLI でセッションを共有する][share-sessions]
-- [Copilot CLI でモデルを選択する][selecting-models]
-
-[previous-lesson]: ../6-custom-agents/
-[next-lesson]: ../8-review/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[about-cloud-agent]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
-[share-sessions]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#share-sessions
-[selecting-models]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#select-an-llm
-
-[cloud-harness-link]: ../../cloud/
diff --git a/docs/ja-jp/cli/8-create-pull-request.md b/docs/ja-jp/cli/8-create-pull-request.md
new file mode 100644
index 00000000..bdd95455
--- /dev/null
+++ b/docs/ja-jp/cli/8-create-pull-request.md
@@ -0,0 +1,99 @@
+---
+title: "演習 8 - 機能の PR を作成してマージする"
+description: "フィルター機能のマイルストーン全体をレビューし、現在の QA の証拠を再利用して、CI とレビュー後に3つ目の pull request をマージします。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+フィルター機能のマイルストーンを PR 3 にまとめます。演習4～7で使ったブランチとチェックアウトを維持してください。フィルター機能の実装、quality-checks スキルとスクリプト、QA プロファイル、関連テストが含まれています。
+
+これは、リポジトリの規約に従う通常の範囲限定の PR リクエストです。コントリビューション用スキルは必要ありません。
+
+> [!NOTE]
+> 実際のチームでは、機能と再利用可能な品質管理の基盤を分ける場合があります。このワークショップでは、1つの機能 PR で一連の流れを示すため、意図的にまとめています。以前の星評価と指示の PR はすでに `main` にマージされているはずです。無関係な作業として再び含めてはいけません。
+
+## 準備状況と証拠を確認する
+
+1. QA の判定と、要件に対応する証拠を確認します。**NO-GO**、ブラウザーの証拠の不足、必要なチェックのスキップは、マージ前に解消すべき阻害要因です。
+2. lint、単体テスト、E2E、型チェックの4つが、実際に quality-checks スキルを通じて実行されたことを確認します。
+3. テストしたリビジョンと、チェック後の変更を確認します。テスト対象のコード、テスト、検証スクリプトが変わっていない場合にのみ、現在の QA の証拠を再利用してください。ファイル内容が同じなら、チェックポイントコミットだけでは証拠は無効になりませんが、コードの変更では無効になります。
+4. 実装やテストの入力が変わった場合は、該当するスキルのチェックとブラウザー観察を再実行し、証拠を更新します。現在の QA 結果がまだ適用できるなら、PR を作成するという理由だけでスイート全体を再実行してはいけません。
+5. 最新のチェックポイントや未コミットの変更だけでなく、ブランチの差分全体を確認します。
+
+同じチェックアウトの別のターミナルで、次を実行します。
+
+```bash
+git status
+git fetch origin
+git log --oneline origin/main..HEAD
+git diff --stat origin/main...HEAD
+git --no-pager diff origin/main...HEAD
+```
+
+3点の diff は、`origin/main` との共通祖先以降のこのブランチの変更を、以前のチェックポイントも含めて表示します。意図したフィルター機能のマイルストーンだけが含まれることを確認してください。新しいファイルも確認し、予期しない未追跡または未コミットのファイルは、ステージングする前にレビューします。
+
+## PR 3 を依頼する
+
+演習7では、チェックポイントの前に通常の **Interactive** セッションに戻りました。QA プロファイルがすでに無効で、フィルター機能のチェックアウトとブランチが変わっていなければ、そのセッションを続けます。Issue の URL、計画時に承認した追加の取り決め、テストしたリビジョンとチェック結果を含む現在の QA レポートを利用できる状態にします。
+
+QA プロファイルは、QA 中のコミットと PR 操作を禁止しています。まだ有効な場合は、PR を依頼する前に通常のセッションに戻ります。
+
+1. QA が待機状態になるまで待ち、CLI のプロンプトで `/exit` を入力します。別のセッションが有効なため CLI が開いたままの場合は、その作業を完了するか保存します。その後、通常のプロンプトに戻り、Ctrl+D を押してこの CLI インスタンスを終了します。
+2. シェルのプロンプトでは、同じフィルター機能のチェックアウトとブランチを維持します。両方を確認してから、`--agent qa` や再開フラグを付けずに新しい通常のセッションを開始します。
+
+ ```bash
+ pwd
+ git branch --show-current
+ git status
+ copilot
+ ```
+
+3. **Interactive** モードで、QA プロファイルが無効になっていることを確認します。別のワークツリーの作成、ブランチの変更、QA セッションの再開はしないでください。
+
+以下のすべてのプレースホルダーを、実際の Issue の URL、承認した追加の取り決め、現在の QA の証拠に置き換えます。演習7の通常セッションを続けている場合でも、これらを明示的に渡してください。新しい会話で QA セッションの記憶に依存してはいけません。
+
+```plaintext
+次の Issue のフィルター機能 PR を準備してください: 。計画時に承認した追加の受け入れ条件は次のとおりです: <合意した追加の取り決めを貼り付けるか、なければ none と記入>。現在の QA の証拠は次のとおりです: <テストしたリビジョン、ブラウザー観察、カバレッジの評価、4つすべてのチェック結果、制限事項を含む QA レポートを貼り付ける>。
+
+チェックアウトと現在のフィルター機能のブランチを確認してください。main に対する差分全体、マイルストーンのすべてのチェックポイントコミット、git status、リポジトリの PR テンプレート、提供した QA の証拠を確認してください。レビュー済みのフィルター機能の実装、quality-checks スキルと同梱スクリプト、QA エージェント定義、関連テストだけを含めてください。
+
+最終的なファイル内容をまだ表している間は、QA 結果を再利用してください。その後にコード、テスト、検証スクリプトが変更された場合は報告し、現在の結果として提示する前に、該当するチェックをスキル経由で実行し、影響するブラウザー検証を行ってください。失敗、阻害、スキップされたチェックを成功扱いにしないでください。
+
+必要に応じて、レビュー済みのマイルストーンの残りの変更をコミットし、この現在のブランチをプッシュして、リポジトリの規約に従い main を対象とする PR を1つ作成してください。Issue と承認済みの条件、実装の概要、追加したテストまたは追加不要だった理由、ブラウザー観察、4つすべてのチェック結果、残る制限事項を含めてください。マージ、別のブランチの作成、コントリビューション用スキルの呼び出し、別の機能の開始はしないでください。
+```
+
+## PR と CI をレビューする
+
+返された URL を開き、PR 全体の **Files changed** を確認します。スキルのスクリプトと QA プロファイルが含まれ、認証情報、ローカルの MCP 設定、無関係なファイル、生成されたレポート、依存関係のインストールによる変更が差分に紛れ込んでいないことを確認します。
+
+PR の **Checks** タブを使うか、機能ブランチのターミナルで次を実行します。
+
+```bash
+gh pr view
+gh pr diff
+gh pr checks --watch
+```
+
+緑色のバッジがあらゆる検証を網羅していると判断せず、リポジトリの `.github/workflows/` を確認します。現在の Tailspin の **Run tests** ワークフローは、ビルドした静的サイトに対して lint、型チェック、Vitest の単体テスト、Playwright の E2E テストを実行します。QA レポートに含まれる MCP の直接的なブラウザー観察を置き換えるものではありません。ワークショップサイトの Astro ビルドとリンクチェックは、別のリポジトリを検証しています。
+
+チェックが失敗したら、ログを確認して原因に対処します。範囲を絞った修正は、プッシュ前に更新後のリビジョンでレビューして再検証する必要があります。`main` が変更され、競合の解決によって機能が変わった場合も、影響する証拠を更新してください。必要な人間のレビューを待ちます。エージェント自身の承認がブランチ保護に優先することはありません。
+
+## マージしてローカルの main を更新する
+
+PR がすべてのレビューとチェックの要件を満たしたら、GitHub で **Merge pull request** を明示的に選択し、マージを確定します。PR 3 が **Merged** であることを確認します。
+
+`/exit` で CLI セッションを終了します。作業ツリーに未コミットの変更がない状態で、ローカルのチェックアウトを更新します。
+
+```bash
+git status
+git switch main
+git pull --ff-only
+```
+
+次の演習に新しいブランチは必要ありません。これで、星評価、指示と実証、フィルター機能と品質チェックスキル・QA プロファイル・テストという、ちょうど3つのワークショップ PR をマージしました。
+
+[演習 9 - スラッシュコマンドと CLI オプションを確認する][next-lesson]に進みます。別の実装タスクではなく、範囲を限定して CLI の操作方法を確認します。
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-slash-commands/
diff --git a/docs/ja-jp/cli/8-review.md b/docs/ja-jp/cli/8-review.md
deleted file mode 100644
index 71baaadf..00000000
--- a/docs/ja-jp/cli/8-review.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: "演習 8 - 振り返りと次のステップ"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-ここ数回の演習で、GitHub Copilot CLI の最も一般的なユース ケースのいくつかを確認しました。具体的には次の内容です。
-
-- GitHub やほかの MCP server と連携する。
-- instruction file を使ってコード生成を導く。
-- skill を実装して、Copilot CLI のツールボックスに tool を追加する。
-- custom agent を呼び出して、より高度で複雑なタスクに対応する。
-- slash command を使ってセッションを管理し、必要に応じて `/delegate` で cloud agent に橋渡しする。
-
-ここでは、いくつかの slash command、ベスト プラクティス、次のステップについて確認します。
-
-## slash command
-
-Copilot CLI には、多数の slash command が用意されています。設定を変更したり、内部で起きていることを確認したりできるコマンドも含まれます。すでに、現在のコンテキストをクリアして新しい chat を始める `/clear` と、MCP server を確認 / 管理する `/mcp` を使いました。役立つ追加コマンドとしては次のようなものがあります。
-
-| Command | 説明 |
-| ------------------ | ------------------------------------------------------------- |
-| `/add-dir` | Copilot の trusted list にディレクトリを追加する |
-| `/clear`, `/new` | 会話履歴をクリアして新しく始める |
-| `/compact` | 会話履歴を要約し、context window の使用量を減らす |
-| `/context` | context window の token 使用量と可視化を表示する |
-| `/diff` | 現在のディレクトリで行われた変更をレビューする |
-| `/model` | 使用する AI model を選択する（Claude Sonnet、GPT-5 など） |
-| `/plan ` | コーディング前に実装計画を作成する |
-| `/review ` | code review agent を実行して変更を分析する |
-| `/delegate` | タスクを Copilot cloud agent に委任して非同期で処理する |
-| `/session` | セッション情報と workspace の概要を表示する |
-| `/share` | セッションを markdown ファイルまたは GitHub gist に共有する |
-| `/skills` | capability を拡張する skill を管理する |
-| `/usage` | セッションの使用状況メトリクスと統計を表示する |
-
-> [!TIP]
-> `/help` を使うと、利用可能な command とキーボード shortcut の完全な一覧を表示できます。
-
-## ベスト プラクティス
-
-AI ツールを使うときは、基盤となる仕組みが出力品質を左右します。しっかりした instruction file、custom agent、agent skill のいずれも重要な役割を果たします。このワークショップでは、それらをそれぞれ確認しました。[awesome-copilot][awesome-copilot] はテンプレートのよい情報源であり、Copilot 自身にこれらのひな形を作らせて出発点にすることもできます。
-
-基盤と同じくらい、コンテキストも重要です。何を作りたいのか、なぜ必要なのか、どのように進めたいのかを明確に伝えることで、出力は大きく変わります。Copilot の助けになる情報があるなら、できるだけ渡してください。
-
-## 次のステップ
-
-どのツールでも、スキルを高める最善の方法は使い続けることです。本番コード、趣味のコード、何年も頭の中にあったけれどまだ形にしていない小さなアプリなど、さまざまな場面で活用してください。学びをチームと共有し、チームからも学んでください。そして、いつものようにドキュメントを確認しましょう。
-
-GitHub Copilot エコシステムをさらに試してみたい場合は、[VS Code ハーネス][vscode-harness-link] または [Cloud agent ハーネス][cloud-harness-link] を確認してください。
-
-## リソース
-
-- [Copilot CLI について][about-copilot-cli]
-- [Copilot CLI を使う][using-copilot-cli]
-- [Awesome Copilot リポジトリ][awesome-copilot]
-- [Custom instructions ガイド][repo-instructions]
-- [Agent Skills ドキュメント][agent-skills]
-- [カスタム エージェント ドキュメント][custom-agents]
-- [MCP 仕様][mcp-spec]
-
-[previous-lesson]: ../7-slash-commands/
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[repo-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
-[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[mcp-spec]: https://modelcontextprotocol.io/
-
-[vscode-harness-link]: ../../vscode/
-[cloud-harness-link]: ../../cloud/
diff --git a/docs/ja-jp/cli/9-slash-commands.md b/docs/ja-jp/cli/9-slash-commands.md
new file mode 100644
index 00000000..1a79be36
--- /dev/null
+++ b/docs/ja-jp/cli/9-slash-commands.md
@@ -0,0 +1,88 @@
+---
+title: "演習 9 - スラッシュコマンドと CLI オプションを確認する"
+description: "別の機能を開始せず、コンテキスト、モデルとセッションの操作、共有先、CLI フラグを確認します。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+3つの PR マイルストーンを完了しました。次は、セッションを理解して管理するための CLI の操作方法を確認します。この演習では、別の機能の実装、作業の委任、別の PR の作成は行いません。
+
+更新済みの学習用チェックアウトから、**Interactive** モードで `copilot` を起動します。`/help` と[コマンドリファレンス][cli-reference]で、インストール済みのバージョンがサポートするコマンドを確認します。現在のドキュメントには、使用中のバージョンより新しい操作が記載されている場合があります。
+
+## コンテキストとセッション情報を確認する
+
+1. 範囲を限定した読み取り専用のリクエストを送信します。
+
+ ```plaintext
+ リポジトリの指示ファイル、quality-checks スキル、QA プロファイルを要約してください。フィルター機能の検証にどのように役立つか説明してください。ファイルの変更、チェックの実行、作業の委任、コミット、PR の作成はしないでください。
+ ```
+
+2. `/context` を入力してコンテキストウィンドウの使用状況を確認します。メッセージ、指示、ツール定義がコンテキストをどのように消費するか確認してください。
+3. `/compact` を入力し、もう一度 `/context` を入力します。圧縮は履歴を要約してサイズを減らします。短いセッションでは変化が小さい場合があります。
+4. `/session` で現在のセッションを、`/usage` で使用量の情報を確認します。
+
+圧縮は要件を渡すことの代わりにはなりません。タスクやエージェントを変更するときは、Issue の URL、承認済みの条件、チェックアウトの識別情報、関連する証拠を明示的に引き継ぎます。
+
+`/clear` は新しい会話を開始しますが、ファイルを元に戻したり Git ブランチを切り替えたりはしません。`/resume` は、以前の作業に戻るためのセッション選択画面を開きます。選択画面を確認したら、Esc を押し、別のタスクを再開せずに閉じてください。受け入れ条件の唯一のコピーを消したり、会話を再開したから古い検証が今も有効だと判断したりしてはいけません。
+
+## モデルとモードを確認する
+
+`/model` を入力し、提供されている場合の **Auto** も含め、アカウントで使えるモデルを確認します。選択の詳細と使用量の情報を読んでください。モデルの提供状況と料金は変わる場合があります。Esc を押し、モデルを変更せずに選択画面を閉じます。変更した場合は、表示された選択内容と、使用中の CLI バージョンでの適用範囲を確認してください。
+
+Shift+Tab で **Interactive**、**Plan**、**Autopilot** を順に切り替えながらモード表示を確認し、実装プロンプトを送らずに **Interactive** に戻します。次の違いを思い出してください。
+
+- Plan は、コーディング前に作業内容に合意するためのモードです。
+- Autopilot は、承認された範囲限定のタスクを継続します。
+- Interactive は、意識的にレビューして判断する機会を提供します。
+- 権限は、許可するツール操作を別途制御します。
+
+## コマンドラインオプションを確認する
+
+別のターミナルで次を実行します。
+
+```bash
+copilot --help
+```
+
+以下のドキュメント上のオプションを、インストール済みバージョンのヘルプと比較します。
+
+| オプション | 目的 |
+| --- | --- |
+| `--model MODEL` | 起動時のモデルを選択する。先に利用可能か確認する |
+| `--agent AGENT` | 起動時のカスタムエージェントを選択する |
+| `-p PROMPT` | プロンプトをプログラムから実行し、完了時に終了する |
+| `--output-format json` | 1行に1つの JSON オブジェクトを含む、構造化された JSONL を出力する |
+| `--resume` | 既存のセッションを再開する |
+| `--enable-all-github-mcp-tools` | 組み込みの GitHub MCP ツールをすべて公開する |
+
+これらは理解するための操作項目であり、別のタスクを開始するためのものではありません。プログラムから実行するモードでも実際のツール操作が行われます。出力形式を JSON にしてもリクエストは読み取り専用にはなりません。エージェントの選択には[演習7][qa-lesson]で検証した手順を使います。カスタムエージェントの有効化を、既定のエージェントにプロファイルを読むよう依頼する方法に置き換えてはいけません。権限とアクセスの制限は引き続き適用されます。
+
+## 共有前に確認する
+
+`/share` はセッションの内容をさまざまな共有先に送れます。[CLI コマンドリファレンス][cli-reference]には、Markdown エクスポート用の `/share file [session|research] [PATH]` と、gist 公開用の `/share gist [session|research]` が記載されています。サブコマンドがない場合、現在のドキュメントでは、ログインして同期済みなら共有可能な GitHub リンクを作成し、そうでなければ Markdown エクスポートに切り替えるとされています。内容のプレビューだけだと思って、サブコマンドなしで実行してはいけません。
+
+このワークショップでは、公開するのではなく、ローカルのセッションエクスポートとファイル名を明示的に指定します。
+
+```text
+/share file session cli-session-review.md
+```
+
+エクスポートしたファイルをエディターで開き、実際の内容を確認します。プロンプト、回答、ツール出力、ファイルパス、リポジトリのデータ、認証情報や個人情報を確認してください。すべての内部手順が含まれている、あるいは機密情報が自動的に削除されていると判断してはいけません。
+
+> [!CAUTION]
+> Gist や共有リンクは外部への情報開示です。シークレット gist は非公開のアクセス制御ではなく、URL を知る人は誰でも閲覧できます。共有前に、共有先、受信者、権限、組織のポリシーを確認してください。情報を削除する必要がある場合は、確認して機密部分を除いた資料だけを承認済みの経路で共有します。その後に元のセッションを公開してはいけません。
+
+このエクスポートを機能の PR やリポジトリの履歴に含めないでください。確認後、自分で生成したファイルを削除するか、承認済みのローカルのメモ保存先に移動します。無関係なファイルを削除してはいけません。
+
+Cloud への委任では、リモートの作業と追加の PR が作成される場合があるため、ここで `/delegate` を実行してはいけません。この別の流れは [Cloud エージェントワークショップ][cloud-workshop]で扱います。
+
+## まとめと次のステップ
+
+別の機能を開始せずに、コンテキスト、使用量、モデルとモードの操作、コマンドラインオプション、共有先を確認しました。[演習 10 - 振り返りと次のステップ][next-lesson]で、構築したワークフローと資産を振り返ります。
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[qa-lesson]: ../7-qa-agent/
+[cloud-workshop]: ../../cloud/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/ja-jp/cli/README.md b/docs/ja-jp/cli/README.md
index 2ab725f8..15681879 100644
--- a/docs/ja-jp/cli/README.md
+++ b/docs/ja-jp/cli/README.md
@@ -3,12 +3,12 @@ slug: ja-jp/cli
title: "GitHub Copilot CLI"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
**[GitHub Copilot CLI](https://docs.github.com/copilot/concepts/agents/about-copilot-cli)** は、ターミナルで GitHub Copilot をエージェント型のコーディング アシスタントとして利用できるようにします。コードベースを探索し、コードを生成し、コマンドを実行し、外部ツールに接続できます。すべてコマンド ラインから行えるため、グラフィカル エディターに切り替えずに作業の流れを保てます。
-これらの演習では、Copilot CLI のインストールと認証から始め、カスタム命令でプロジェクトのコンテキストを与えたうえで、プラン モードを使って意図的に機能を実装します。続いて Playwright MCP サーバーを接続し、実際のブラウザーでその機能をテストします。その後、再利用可能な agent skill と custom agent で Copilot を拡張します。最後に、コンテキスト管理、モデル選択、共有に使う slash command を確認し、作成した内容を振り返ります。
+演習0～1のセットアップ後、演習2～10の9つのコアモジュールに取り組みます。星評価を追加する小さな変更から始め、ドキュメントの指示を整備し、**Plan** と **Autopilot** モードでフィルター機能を構築します。続いて再利用可能な quality-checks スキルを作成し、Playwright MCP で動作を検証し、QA エージェントを作成して機能をリリースします。最後に CLI の操作方法を確認し、作成した内容を振り返ります。
## 演習
@@ -16,13 +16,21 @@ lastUpdated: 2026-06-30
|----------|-------|-------------|
| [0. 前提条件][ex0] | セットアップ | リポジトリと codespace を作成する |
| [1. Copilot CLI のインストール][ex1] | インストール | Copilot CLI をインストールして認証する |
-| [2. カスタム命令][ex2] | コンテキスト | 命令を追加し、Copilot CLI がどのように従うかを確認する |
-| [3. コード生成][ex3] | コード生成 | プラン モードを使って機能を生成する |
-| [4. Playwright MCP によるテスト][ex4] | 外部ツール | Playwright MCP サーバーを追加し、ブラウザーで機能をテストする |
-| [5. エージェント スキル][ex5] | スキル | 専門スキルで Copilot を強化する |
-| [6. カスタム エージェント][ex6] | エージェント | カスタム エージェントを確認して使用する |
-| [7. スラッシュ コマンド][ex7] | CLI 機能 | コンテキスト、モデル、共有、cloud agent への任意の委任を確認する |
-| [8. 振り返り][ex8] | まとめ | 重要な概念と次のステップを確認する |
+| [2. 星評価を追加して小さな成果を得る][ex2] | 最初の変更 | 既存の評価を表示し、検証して PR 1 をマージする |
+| [3. カスタム指示で Copilot を導く][ex3] | コンテキスト | ドキュメント規約を追加して実証し、PR 2 をマージする |
+| [4. Plan と Autopilot でフィルター機能を構築する][ex4] | 実装 | 計画をレビューし、Autopilot を承認してテストし、チェックポイントを保存する |
+| [5. quality-checks スキルを作成して使用する][ex5] | スキル | シェルスクリプトを同梱したチェックを生成、確認、実行する |
+| [6. Playwright MCP で機能を検証する][ex6] | ブラウザーツール | 実際のブラウザーでフィルターの動作を観察する |
+| [7. QA エージェントを作成して使用する][ex7] | エージェント | 要件とカバレッジを評価し、最終的な証拠を集める |
+| [8. 機能の PR を作成してマージする][ex8] | リリース | フィルター機能と再利用可能なカスタマイズを PR 3 でまとめてレビューする |
+| [9. スラッシュコマンドと CLI オプションを確認する][ex9] | CLI の操作 | コンテキスト、モデル、セッション、共有先を確認する |
+| [10. 振り返りと次のステップ][ex10] | まとめ | 共通の資産と3つの PR マイルストーンを振り返る |
+
+## ブランチと pull request
+
+3つの pull request をマージします。星評価、指示と小さな実証、そしてフィルター機能と quality-checks スキル・QA プロファイル・関連テストです。最初の2つの PR は、それぞれマージしてから更新済みの `main` で次のマイルストーンを始めます。
+
+演習4～8では1つの機能ブランチとチェックアウトを共有します。途中でチェックポイントコミットを保存してください。スキルの作成、MCP の設定、QA の選択で新しい機能ブランチは作成しません。演習9では別の機能や PR を開始せず、操作方法を確認します。
## 前提条件
@@ -46,10 +54,12 @@ lastUpdated: 2026-06-30
[ex0]: 0-prerequisites/
[ex1]: 1-install-copilot-cli/
-[ex2]: 2-custom-instructions/
-[ex3]: 3-generating-code/
-[ex4]: 4-mcp/
+[ex2]: 2-add-star-rating/
+[ex3]: 3-custom-instructions/
+[ex4]: 4-build-filtering/
[ex5]: 5-agent-skills/
-[ex6]: 6-custom-agents/
-[ex7]: 7-slash-commands/
-[ex8]: 8-review/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-slash-commands/
+[ex10]: 10-review/
diff --git a/docs/ko-kr/README.md b/docs/ko-kr/README.md
index 2960a995..6ecf9836 100644
--- a/docs/ko-kr/README.md
+++ b/docs/ko-kr/README.md
@@ -3,7 +3,7 @@ slug: ko-kr
title: "GitHub Copilot 에이전트 실습"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
최근 GitHub Copilot에 추가된 기능은 소프트웨어 개발 수명 주기(SDLC) 전반에서 개발자에게 강력한 도구를 제공합니다. 여기에는 GitHub의 이슈 및 끌어오기 요청 작업, 외부 서비스와의 상호 작용, 그리고 코드 작성이 포함됩니다. 이 랩에서는 이러한 기능을 살펴보고, 실제 사용 사례와 도구를 최대한 활용하는 방법을 소개합니다.
@@ -23,11 +23,11 @@ GitHub Copilot은 어떤 작업 환경에서든 함께할 수 있습니다. 원
### 💻 [Copilot CLI](cli/)
-**GitHub Copilot CLI**는 터미널에서 실행되는 에이전트형 도우미입니다. 이를 설치하고, MCP 서버를 연결하고, 계획 모드로 코드를 생성하고, 명령줄에서 직접 스킬, 사용자 지정 에이전트, 슬래시 명령을 만듭니다.
+**GitHub Copilot CLI**는 터미널에서 실행되는 에이전트형 도우미입니다. 설정 후 아홉 개의 핵심 모듈을 진행합니다. 별점을 추가하는 작은 변경을 제공하고, 지침을 정립하고, 필터링을 계획하고 구축한 다음, quality-checks 스킬을 만들고, Playwright MCP로 검증하고, QA 에이전트를 만들어 기능을 병합합니다. 마지막으로 CLI 조작 방법과 마무리를 다룹니다. 이 과정에는 세 번의 끌어오기 요청 마일스톤이 있습니다.
### 🤖 [Copilot 앱](app/)
-**GitHub Copilot 앱**은 Copilot CLI를 기반으로 구축된 데스크톱 애플리케이션입니다. 여러 에이전트 세션을 병렬로 실행하고, 세션 모드를 전환하고, 캔버스에서 협업하고, GitHub 이슈와 끌어오기 요청을 기본 기능으로 관리합니다. 여기에는 끌어오기 요청의 리베이스, 검토 피드백, CI 수정, 병합 과정을 관리하는 **Agent Merge**도 포함됩니다.
+**GitHub Copilot 앱**은 Copilot CLI를 기반으로 구축된 데스크톱 애플리케이션입니다. 앱의 격리된 세션과 **Agent Merge**를 사용하여 동일한 설정 과정과 아홉 개의 핵심 모듈에서 별점, 지침, 필터링, 스킬, MCP, QA, 기능 PR 워크플로를 진행합니다. 네 번째 끌어오기 요청 마일스톤으로 리포지토리에 저장하는 캔버스를 만들고 병합한 다음 마무리합니다.
### ☁️ [Copilot 클라우드 에이전트](../cloud/)
diff --git a/docs/ko-kr/app/0-prerequisites.md b/docs/ko-kr/app/0-prerequisites.md
index 5296f49c..eed6f2bd 100644
--- a/docs/ko-kr/app/0-prerequisites.md
+++ b/docs/ko-kr/app/0-prerequisites.md
@@ -15,18 +15,18 @@ GitHub Copilot app은 Copilot과 GitHub를 모두 사용하는 중앙 허브 역
## Node.js 설치
-여러 레슨에서 에이전트에게 기능을 구축하고 Tailspin Toys 테스트 도구 모음을 로컬에서 실행하도록 요청합니다. 이 작업에는 프로젝트에 필요한 유일한 런타임인 [**Node.js**][nodejs]가 필요합니다. **22 이상** 버전을 설치합니다. 현재 **LTS** 릴리스가 안전한 선택입니다.
+여러 레슨에서 에이전트에게 기능을 구축하고 Tailspin Toys 테스트 도구 모음을 로컬에서 실행하도록 요청합니다. 이 작업에는 [**Node.js**][nodejs]가 필요합니다. **Node.js 22.13 이상**을 사용하고 체크아웃의 `package.json`과 README에서 지원 버전을 확인합니다.
모든 플랫폼에서 가장 간단한 방법은 공식 설치 프로그램을 사용하는 것입니다.
1. 운영 체제에서 Windows Terminal, macOS 터미널 또는 평소 사용하는 도구로 터미널 창을 엽니다.
-2. 다음 명령을 실행하여 Node.js 22 이상이 설치되어 있는지 확인합니다.
+2. 다음 명령을 실행하여 Node.js 22.13 이상이 설치되어 있는지 확인합니다.
```shell
node --version
```
-3. `v22` 이상의 숫자가 표시되면 다음 섹션으로 건너뛸 수 있습니다.
+3. 표시된 버전이 `v22.13.0` 이상이고 프로젝트에서 지원한다면 다음 섹션으로 건너뛸 수 있습니다.
> [!TIP]
> Node가 설치되어 있지 않거나 업데이트해야 하는 경우에만 다음 단계를 수행하면 됩니다.
@@ -41,10 +41,10 @@ GitHub Copilot app은 Copilot과 GitHub를 모두 사용하는 중앙 허브 역
node --version
```
-9. `v22.x.x` 이상이 표시되어야 합니다.
+9. 표시된 버전이 `v22.13.0` 이상이며 프로젝트에서 지원하는지 확인합니다.
-> [!TIP]
-> 컨테이너를 선호합니까? [**Docker**][docker]가 있다면 Node.js를 로컬에 설치하는 대신 리포지토리의 [dev container][dev-containers]를 사용할 수 있습니다. 이 컨테이너에는 Node가 포함되어 있으므로 두 가지가 모두 필요하지는 않습니다.
+> [!IMPORTANT]
+> 이 App 학습 과정은 로컬 워크트리를 사용합니다. 컨테이너에만 설치한 런타임은 로컬 세션에서 사용할 수 없습니다. 각 워크트리에는 프로젝트 의존성과 E2E 검사용 Playwright Chromium도 필요합니다. 워크트리를 준비할 때 학습용 리포지토리의 README를 따르고, 설치 요청을 검토한 후 승인합니다.
## 실습 리포지토리 설정
@@ -64,6 +64,8 @@ Tailspin Toys 프로젝트의 복사본에서 작업합니다. 지금 [템플릿
> [!NOTE]
> 템플릿에서 리포지토리를 만들면 GitHub 이슈 백로그가 자동으로 생성됩니다. 워크숍 전체에서 이 이슈를 사용하므로 직접 등록할 항목은 없습니다.
+개정된 템플릿의 새 복사본을 사용합니다. 리포지토리 지침, 애플리케이션 코드, 테스트, 기존 캔버스 확장은 포함되지만 사용자 지정 에이전트나 스킬은 제공되지 않습니다. 워크숍에서 직접 quality-checks 스킬과 QA 프로필을 만듭니다. 이전 복사본을 사용한다면 기존 사용자 지정을 덮어쓰지 말고 먼저 살펴봅니다.
+
## 요약 및 다음 단계
설정이 완료되었습니다. 프로젝트를 컴퓨터에서 빌드하고 테스트할 수 있도록 Node.js를 설치하고, 템플릿에서 Tailspin Toys 리포지토리의 복사본을 만들었습니다.
@@ -79,7 +81,5 @@ Tailspin Toys 프로젝트의 복사본에서 작업합니다. 지금 [템플릿
[next-lesson]: ../1-install-copilot-app/
[nodejs]: https://nodejs.org/
[node-download]: https://nodejs.org/en/download
-[docker]: https://www.docker.com/products/docker-desktop/
-[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
[template-repository]: https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-template-repository
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/ko-kr/app/1-install-copilot-app.md b/docs/ko-kr/app/1-install-copilot-app.md
index 798c84ab..053d592d 100644
--- a/docs/ko-kr/app/1-install-copilot-app.md
+++ b/docs/ko-kr/app/1-install-copilot-app.md
@@ -41,23 +41,23 @@ GitHub Copilot app을 사용하려면 먼저 앱을 설치해야 합니다. Wind
프로젝트를 연결했으므로 잠시 워크스페이스의 구성을 살펴봅니다. 앱의 사이드바는 몇 가지 영역으로 구성됩니다.
-- **Sessions** — 에이전트가 작업하는 곳입니다. 각 세션은 격리된 워크스페이스에서 실행되므로 변경 내용이 충돌하지 않게 여러 세션을 동시에 실행할 수 있습니다. 다음 레슨에서 첫 번째 세션을 시작합니다.
+- **Sessions** — 에이전트가 작업하는 곳입니다. 이 워크숍에서는 **new working tree**를 선택하여 PR 마일스톤마다 격리된 체크아웃과 브랜치를 사용합니다. 다른 워크스페이스 선택지도 있지만 여기서는 사용하지 않습니다.
- **Quick chats** — 별도의 브랜치나 워크스페이스가 필요하지 않은 질문과 브레인스토밍을 위한 가벼운 대화입니다. 이 레슨의 마지막에서 사용해 봅니다.
- **My work** — 앱의 **GitHub 기본 통합**을 통해 이슈와 끌어오기 요청을 표시합니다. 앱을 벗어나지 않고 이슈와 끌어오기 요청을 찾아 필터링하고, CI 상태를 확인하고, 이슈에서 세션을 시작하고, 끌어오기 요청을 검토할 수 있습니다.
-- **Automations** — 일정에 따라 또는 요청 시 실행되는 저장된 에이전트 작업입니다. 이 실습 과정의 끝부분에서 하나를 만듭니다.
+- **Customize** — MCP 서버, 스킬, 캔버스를 검색하고 관리합니다. Playwright MCP를 구성할 때 사용합니다.
+- **Automations** — 일정에 따라 또는 요청 시 실행되는 저장된 에이전트 작업입니다. 마무리에서 다음 단계로 링크를 제공하며 추가 워크숍 실습으로 다루지는 않습니다.
### 미리 생성된 백로그 찾기
앱은 GitHub와 기본적으로 통합되므로 리포지토리에서 대기 중인 작업을 앱 안에서 바로 볼 수 있습니다. 템플릿에서 리포지토리를 만들 때 이슈 백로그가 생성되었습니다. 백로그가 있는지 확인합니다.
1. 사이드바에서 **My work**를 선택합니다.
-2. 템플릿은 백로그에 여덟 개의 이슈를 생성했습니다. 이 하네스에서는 다음 세 이슈에 집중합니다. 표시되는지 확인합니다.
+2. 이슈 번호를 가정하지 말고 다음 제목으로 이슈를 찾습니다.
- Allow users to filter games by category and publisher
- Update our repository coding standards
- - Implement pagination on the game list page
-3. 이슈를 선택하여 세부 정보를 읽습니다. 각 이슈는 에이전트 세션을 시작하는 지점이기도 합니다. 이 실습 과정의 뒷부분에서 이 이슈를 바탕으로 작업을 시작합니다.
+3. 이슈를 선택하여 세부 정보를 읽습니다. 각 이슈는 에이전트 세션을 시작하는 지점이기도 합니다. 이 실습 과정의 뒷부분에서 이 이슈를 바탕으로 작업을 시작합니다. 다른 백로그 이슈는 캔버스의 컨텍스트로 사용하며 추가 구현 작업으로 다루지 않습니다.
> [!NOTE]
> My work의 항목 목록은 Copilot app에 추가한 리포지토리의 항목만 표시하도록 자동으로 필터링됩니다. 다른 리포지토리의 작업 항목을 보려면 해당 리포지토리를 앱에 추가합니다.
@@ -70,7 +70,7 @@ GitHub Copilot app을 사용하려면 먼저 앱을 설치해야 합니다. Wind
2. 앱의 세션이 어떻게 작동하는지 질문합니다.
```plaintext
- How does the GitHub Copilot app use worktrees?
+ GitHub Copilot app은 워크트리를 어떻게 사용합니까?
```
3. 대화 보기에서 응답을 읽습니다. 각 세션이 격리된 git 작업 트리에서 실행되므로 변경 내용이 충돌하지 않게 여러 에이전트를 병렬로 실행할 수 있다는 점을 확인할 수 있습니다. 언제든지 대화를 계속하거나 새 채팅을 시작할 수 있습니다.
@@ -84,7 +84,13 @@ GitHub Copilot app을 설치하고 프로젝트를 연결하고 워크스페이
- 워크스페이스를 살펴보고 **My work**에서 미리 생성된 백로그를 찾습니다.
- 빠른 채팅을 사용하여 일회성 질문을 합니다.
-다음으로 첫 번째 에이전트 세션을 시작하고 프로젝트를 처음으로 변경하여 게임 카드에 별점을 표시합니다. [레슨 2 - 첫 번째 에이전트 세션 실행][next-lesson]을 계속 진행합니다.
+## PR 마일스톤 분리
+
+별점, 지침과 작은 시연, 필터링과 스킬·QA 프로필·테스트, 마지막으로 이슈 분류 캔버스의 네 PR을 병합합니다. PR 마일스톤별로 하나의 브랜치를 사용합니다. 레슨 4~8은 동일한 필터링 세션, 워크트리, 브랜치에서 진행하고 추가 PR 대신 체크포인트 커밋을 만듭니다.
+
+새 App 워크트리가 오래된 로컬 상태에서 시작할 수 있습니다. 각 마일스톤에서 파일을 편집하기 전에 리포지토리를 가져오고 새 세션 브랜치를 최신 `origin/main`으로 fast-forward합니다. 다음 레슨에서 구체적인 절차를 다룹니다. 브랜치를 쌓거나 이전 작업을 cherry-pick하거나 활성 필터링 세션을 다른 브랜치로 전환하지 않습니다.
+
+다음으로 첫 번째 에이전트 세션을 시작하고 프로젝트를 처음으로 변경하여 게임 카드에 별점을 표시합니다. [레슨 2 - 별점 추가로 작은 성과 얻기][next-lesson]를 계속 진행합니다.
## 리소스
@@ -92,7 +98,7 @@ GitHub Copilot app을 설치하고 프로젝트를 연결하고 워크스페이
- [GitHub Copilot app 시작하기][getting-started]
- [GitHub Copilot app에서 에이전트 세션 사용][agent-sessions]
-[ex0]: ../0-prerequisites/
+[previous-lesson]: ../0-prerequisites/
[next-lesson]: ../2-add-star-rating/
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
diff --git a/docs/ko-kr/app/10-review.md b/docs/ko-kr/app/10-review.md
new file mode 100644
index 00000000..fe3c7053
--- /dev/null
+++ b/docs/ko-kr/app/10-review.md
@@ -0,0 +1,87 @@
+---
+title: "Lesson 10 - 마무리 및 다음 단계"
+description: "App의 아홉 핵심 모듈, 네 PR 마일스톤, 재사용 가능한 품질 워크플로를 돌아보고 추가 리소스를 살펴봅니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+지난 여러 레슨에서 GitHub Copilot app으로 아이디어를 기능으로 만들고 병합하기까지 다음 작업을 수행했습니다.
+
+- 리포지토리를 연결하고 앱의 워크스페이스와 미리 생성된 백로그를 살펴봤습니다.
+- 직접 작업과 이슈에서 세션을 시작하고 Plan 및 Autopilot 모드로 에이전트의 작업 방식을 제어했습니다.
+- 사용자 지정 지침으로 에이전트를 안내한 다음, 셸 스크립트가 포함된 재사용 가능한 스킬을 만들도록 요청하고, 스크립트를 검토한 후 린트, 단위 테스트, 엔드투엔드 테스트, 타입 검사를 실행했습니다.
+- Playwright MCP 서버를 사용하여 실제 브라우저에서 작업을 테스트했습니다.
+- 요구 사항, 커버리지, 스킬 스크립트 결과, 브라우저 근거를 평가할 QA 사용자 지정 에이전트를 만들고 선택했습니다.
+- 공유 캔버스에서 에이전트와 협업했습니다.
+- 초기 PR을 직접 명시적으로 병합한 다음 기능과 캔버스 PR 워크플로에서 **Agent Merge**를 승인했습니다.
+
+설정 레슨 0~1에 이어 아홉 개의 핵심 모듈인 레슨 2~10을 진행했습니다. 산출물과 다음 단계를 돌아봅니다. 이 마무리에서는 다른 실습 작업을 시작하지 않습니다.
+
+## 제공한 결과
+
+워크숍에는 네 번의 PR 마일스톤이 있으며, 각각 업데이트된 `main`에서 시작한 자체 브랜치를 사용합니다.
+
+1. **별점:** 게임 카드에 기존 `starRating`과 명시적인 미평가 상태를 표시합니다.
+2. **지침과 시연:** 문서화 규칙을 추가하고 작은 실제 코드 변경에 미친 영향을 검증합니다.
+3. **필터링과 품질 워크플로:** 이슈를 구현하고 셸 스크립트를 포함하는 `quality-checks` 스킬과 QA 프로필을 만들며 관련 테스트를 포함합니다.
+4. **리포지토리에 저장한 이슈 분류 캔버스:** 다른 기능을 자동으로 구현하지 않고 이슈 컨텍스트를 추가하는 보드를 공유합니다.
+
+레슨 4~8은 동일한 필터링 세션, 워크트리, 브랜치를 사용했습니다. 체크포인트 커밋으로 PR 3 안에서 진행 상황을 보존했으며 스킬, MCP 구성, QA에 별도의 기능 브랜치가 필요하지 않았습니다. 이후 각 마일스톤은 앞선 PR이 병합되고 새 세션 브랜치가 `origin/main`에서 업데이트된 후에만 시작했습니다.
+
+## 서로 다른 검증 방식
+
+초기 기능은 기존 npm 검사를 사용했습니다. 필터링에는 직접 수행하는 브라우저 검토를 추가했습니다. 스킬은 함께 제공되는 스크립트로 네 가지 검사를 반복 가능하게 만들었고, MCP는 에이전트의 직접 브라우저 관찰을 추가했으며, QA는 요구 사항과 커버리지를 최종 검증과 결합했습니다. PR에서는 제출한 리비전에 적용될 때만 QA 근거를 재사용했습니다.
+
+추가한 테스트는 실제 커버리지 부족을 해결해야 합니다. 새 테스트가 필요 없는 QA 실행도 올바를 수 있습니다. 누락된 도구, 건너뛴 검사, 실패는 드러내야 할 차단 요인이지 통과가 아닙니다. 병합 승인 전에 코드와 근거를 검토하고 변경 후 관련 근거를 갱신합니다.
+
+## 모범 사례
+
+AI 도구를 사용할 때는 도구를 둘러싼 인프라가 결과의 품질을 좌우합니다. 이 워크숍에서는 지침, 스킬, QA 프로필을 만들었습니다. 이를 검토하고 세션 간에 재사용합니다. 사용자 지정 에이전트는 전문가 역할과 지침을 정의하며 사용 가능한 도구는 구성과 하네스 권한에 따라 결정됩니다. 스킬은 필요할 때 불러오는 재사용 가능한 작업 지침, 실행 가능한 스크립트, 보조 리소스를 묶어 제공합니다. 사용자 지정 에이전트도 스킬과 함께 제공되는 스크립트를 비롯한 스크립트를 실행할 수 있습니다. 설득력 있는 설명에 의존하지 말고 실제 스크립트 실행과 사용자 지정 에이전트 선택을 확인합니다.
+
+작업에 맞는 **모드와 모델**을 선택합니다. 구축 전에 접근 방식을 검토하려면 **Plan**을 사용하고, 범위가 명확한 변경에서 계속 참여하려면 **Interactive**를 사용하며, 범위가 명확하고 격리된 작업에만 **Autopilot**을 사용합니다. 일상적인 편집에는 빠른 모델을 선택하고 복잡한 작업에는 추론 능력이 더 높은 모델을 선택합니다.
+
+컨텍스트는 인프라만큼 중요합니다. 만들려는 *항목*, 그 *이유*, 원하는 *방식*을 명확하게 설명하면 출력이 크게 달라집니다. 빠른 채팅은 아이디어를 전체 세션에 적용하기 전에 범위를 정하기에 적합합니다.
+
+## 더 살펴볼 내용
+
+핵심 워크플로를 모두 살펴봤습니다. 다음 기능도 확인해 볼 만합니다.
+
+- 전체 세션이 필요 없는 빠른 일회성 질문을 위한 **Quick chats**
+- 최근 작업 요약 같은 반복 또는 요청 시 작업을 위한 [**Automations**][using-automations]. 도입 전에 일정, 권한, 범위를 검토합니다. 자동화 만들기는 다음 단계이며 이 워크숍에 포함되지 않습니다.
+- 구축 전에 문제를 함께 검토하고 유용한 피드백을 받기 위한 **Rubber duck**
+- 반복 가능한 전문 작업을 위해 역할, 도구, 지침을 패키지하는 [**Custom agents**][custom-agents]
+- 세션에서 일어난 일을 서술형으로 생성하는 [`/chronicle`][chronicle]
+- Ollama, Foundry Local, LM Studio를 통한 로컬 모델을 포함하여 자체 공급자의 모델을 사용하는 [Bring your own key (BYOK)][byok]
+- GitHub에서 호스팅하는 격리된 환경에서 세션을 실행하는 [Cloud sandboxes][sandboxes]
+- 리포지토리, 세션, 프롬프트에서 바로 앱을 여는 [Deep links][deep-links]
+
+## 다음 단계
+
+어떤 도구든 더 능숙하게 사용하려면 계속 사용해야 합니다. 프로덕션 코드, 취미 프로젝트, 오랫동안 생각만 하고 만들지 못했던 작은 앱에 사용해 봅니다. 배운 내용을 팀과 공유하고 팀의 경험에서도 배웁니다. 언제나 그렇듯 문서를 살펴봅니다.
+
+GitHub Copilot 생태계를 더 살펴보려면 [VS Code 실습 과정][vscode-harness], [Copilot CLI 실습 과정][cli-harness], [Cloud agent 실습 과정][cloud-harness]을 확인합니다.
+
+## 리소스
+
+- [GitHub Copilot app 정보][about-copilot-app]
+- [GitHub Copilot app 시작하기][getting-started]
+- [GitHub Copilot app 사용자 지정][customize]
+- [자동화 사용][using-automations]
+- [캔버스 확장 사용][canvas-docs]
+- [클라우드 및 로컬 샌드박스 정보][sandboxes]
+
+[previous-lesson]: ../9-canvases/
+[vscode-harness]: ../../vscode/
+[cli-harness]: ../../cli/
+[cloud-harness]: ../../cloud/
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
+[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
+[customize]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
+[using-automations]: https://docs.github.com/copilot/how-tos/github-copilot-app/using-automations
+[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
+[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
+[chronicle]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/chronicle
+[custom-agents]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
+[byok]: https://docs.github.com/copilot/how-tos/github-copilot-app/use-byok-models
+[deep-links]: https://docs.github.com/copilot/how-tos/github-copilot-app/open-with-deep-links
\ No newline at end of file
diff --git a/docs/ko-kr/app/2-add-star-rating.md b/docs/ko-kr/app/2-add-star-rating.md
index 1bb6fc6f..35ea3808 100644
--- a/docs/ko-kr/app/2-add-star-rating.md
+++ b/docs/ko-kr/app/2-add-star-rating.md
@@ -1,5 +1,5 @@
---
-title: "Lesson 2 - 첫 번째 에이전트 세션 실행"
+title: "Lesson 2 - 별점 추가로 작은 성과 얻기"
description: "GitHub Copilot app에서 첫 번째 에이전트 세션을 시작하고 게임 카드를 조금 변경한 다음 첫 번째 끌어오기 요청으로 병합합니다."
authors:
- geektrainer
@@ -22,7 +22,7 @@ Tailspin Toys의 각 게임에는 별점이 있을 수 있으며, 별점은 이
## 세션 구조
-**세션**은 격리된 자체 워크스페이스에서 실행되는 에이전트와의 대화입니다. 모든 세션에는 **전용 git 작업 트리와 브랜치**가 제공됩니다. 따라서 변경 내용이 충돌하지 않게 한 세션에서는 기능을 추가하고 다른 세션에서는 버그를 수정하는 등 여러 세션을 동시에 실행할 수 있습니다. 세션은 사이드바에서 리포지토리별로 그룹화되며, 원하는 세션을 선택하여 전환할 수 있습니다.
+**세션**은 에이전트와의 대화입니다. 이 워크숍에서는 **new working tree**를 선택하여 세션 전용 체크아웃과 브랜치를 사용합니다. 이렇게 하면 레슨마다 별도 브랜치를 만들지 않고 각 PR 마일스톤을 격리할 수 있습니다. 세션은 사이드바에서 리포지토리별로 그룹화되며, 원하는 세션을 선택하여 전환할 수 있습니다.
세션 안에는 에이전트와의 **대화**, 에이전트가 파일을 탐색하고 편집할 때의 **도구 활동**, diff와 함께 표시되는 **변경된 파일** 목록이 있습니다.
@@ -36,16 +36,20 @@ Tailspin Toys의 각 게임에는 별점이 있을 수 있으며, 별점은 이
-4. 다음 프롬프트를 사용하여 변경을 요청합니다.
+4. 프롬프트 상자 아래에서 **new working tree**와 **Interactive** 모드를 선택합니다. 다음 프롬프트로 변경을 요청합니다.
```plaintext
- On the game cards, show each game's star rating. The Game type already includes a starRating field — it's a number out of 5, or null when a game hasn't been rated yet. Display it on each card in src/components/GameCard.astro, and when starRating is null show "No rating yet" instead. Keep the change small and don't restructure the card layout.
+ 편집하기 전에 이 체크아웃과 브랜치를 식별하고, 커밋하지 않은 변경이 없는 새 워크트리인지 확인한 다음 origin을 가져오고 이 세션 브랜치를 origin/main으로 fast-forward해 주십시오. HEAD가 origin/main과 일치하는지 확인해 주십시오. 미커밋 변경이나 분기가 있거나 업데이트할 수 없으면 중단하고 설명해 주십시오. 재설정하거나 작업을 버리지 마십시오.
+
+ 게임 카드에 각 게임의 별점을 표시해 주십시오. Game 타입에는 이미 starRating 필드가 있으며 5점 만점의 숫자이거나 아직 평가되지 않은 경우 null입니다. src/components/GameCard.astro의 각 카드에 표시하고, starRating이 null이면 대신 "No rating yet"을 표시해 주십시오. 변경을 작게 유지하고 카드 레이아웃을 재구성하거나 데이터 모델을 변경하지 마십시오.
+
+ 리포지토리 지침을 따르고 적절한 테스트를 추가하거나 업데이트한 다음 관련된 기존 npm 검사를 실행해 주십시오. 필수 조건을 살펴보고 설치 전에 질문해 주십시오. 변경된 파일과 검사 결과를 보고한 다음 제가 검토할 수 있도록 중단해 주십시오. 커밋, 푸시, 끌어오기 요청 생성, 다른 기능 구현은 하지 마십시오.
```
> [!NOTE]
> 프롬프트에 Copilot이 업데이트할 파일 이름을 포함했습니다. Copilot이 작업에 포함할 파일을 반드시 지정할 필요는 없지만, 방향을 제시하면 Copilot이 코드를 더 빠르게 생성하고 토큰 사용량을 줄이는 데 도움이 됩니다.
-5. Enter를 선택하여 Copilot에 프롬프트를 보냅니다.
+5. Enter를 눌러 Copilot에 프롬프트를 보냅니다.
Copilot app은 먼저 프로젝트의 격리된 복사본인 새 작업 트리를 만들고 작업을 시작합니다. 그런 다음 프로젝트를 탐색하고 새 기능을 추가하기 위해 업데이트해야 할 파일을 찾은 후 필요한 코드를 만듭니다. 이제 Copilot app으로 새 기능을 추가했습니다.
@@ -76,7 +80,9 @@ AI가 생성한 모든 변경 내용은 작더라도 병합하기 전에 검토
## 변경 내용 확인
-코드를 읽고 작동한다고 가정해서는 안 됩니다. 모든 내용을 시각적으로 테스트해야 합니다. 터미널에서 앱을 시작한 다음 모든 기능이 작동하는지 확인합니다. Copilot app에는 터미널이 기본 제공됩니다.
+브라우저를 열기 전에 에이전트의 자동 검사 결과를 검토합니다. 아직 존재하지 않는 스킬 대신 프로젝트의 기존 npm 스크립트를 사용하여 숫자 `starRating`과 `null` 대체 표시를 테스트하는지 확인합니다. 누락된 필수 조건이나 건너뛴 검사는 통과가 아닙니다.
+
+그런 다음 세션의 내장 터미널로 앱을 수동 확인합니다. 서버를 시작하기 전에 워크트리를 식별하고 다른 체크아웃의 서버를 재사용하지 않습니다.
1. Copilot app 오른쪽의 검토 패널에서 **Terminal**을 선택합니다. **Terminal** 버튼이 없으면 **+**(**Open in panel** 레이블)를 선택한 다음 **Terminal**을 선택합니다.
@@ -89,26 +95,30 @@ AI가 생성한 모든 변경 내용은 작더라도 병합하기 전에 검토
```
3. 서버가 시작되면 브라우저 창을 엽니다. 잠시만 기다리면 됩니다.
-4. [http://localhost:4321](http://localhost:4321)로 이동합니다.
-5. 이제 랜딩 페이지의 모든 게임에 별점이 표시되어야 합니다.
+4. 서버가 출력한 로컬 URL을 엽니다. 일반적으로 `http://localhost:4321`입니다. 포트가 사용 중이면 관련 없는 프로세스를 중지하지 말고 소유자를 확인합니다.
+5. 평가된 게임 카드에 5점 만점의 값이 표시되는지 확인합니다. 미평가 데이터가 있으면 **No rating yet**이 표시되는지 확인합니다. 없다면 관찰했다고 주장하지 말고 자동 테스트로 null 사례를 검증합니다.
6. 터미널 창으로 돌아갑니다.
-7. Ctrl+C를 선택하여 개발 서버를 중지합니다.
+7. Control+C(Mac) 또는 Ctrl+C(Windows/Linux)를 눌러 직접 시작한 개발 서버를 중지합니다.
## 첫 번째 끌어오기 요청 열기 및 병합
-변경 내용이 올바르게 작동하므로 이제 제공할 차례입니다. 에이전트에게 끌어오기 요청을 열도록 요청한 다음 github.com에서 직접 검토하고 병합합니다. 지금은 이 과정을 수동으로 관리합니다. 이후 레슨에서는 Copilot이 일부 작업을 자동으로 처리하는 방법을 살펴봅니다.
+변경 내용이 올바르므로 이제 PR 1을 만들 차례입니다. 먼저 구현과 별도로 커밋과 PR 생성을 승인합니다.
+
+```plaintext
+별점 변경과 테스트의 전체 diff를 검토하고, 검증 결과를 요약하고, 검토된 변경을 이 세션 브랜치에 커밋해 주십시오. 브랜치를 푸시하고 리포지토리의 PR 템플릿을 사용하여 main을 대상으로 끌어오기 요청을 만들어 주십시오. 병합하지 마십시오.
+```
-1. 오른쪽 위에서 **Create PR**을 선택합니다.
+1. 세션에서 생성된 PR 링크를 엽니다. 앱에 **Create PR** 확인이 표시되면 이를 선택하여 요청을 승인하고 두 번째 PR을 만들지 않습니다.
2. 메시지가 표시되면 **Sign in with your browser**를 선택하고 안내에 따라 인증합니다.
3. Copilot이 PR을 만들기 시작합니다.
-PR이 만들어지면 Copilot은 리포지토리에서 실행해야 하는 워크플로를 모니터링합니다. 잠시 후 오른쪽 위의 버튼이 **Ready to merge**로 바뀝니다. 이는 PR을 병합할 준비가 되었다는 표시입니다.
+PR이 만들어지면 **My work**에서 전체 PR diff와 검사를 살펴봅니다. 학습용 리포지토리의 워크플로 결과를 읽고, 필수 검사와 검토가 완료되기를 기다리며, 실패를 해결한 후 병합합니다. **Ready to merge**는 변경 내용 검토나 로컬 검증 근거를 대체하지 않습니다.
4. 채팅 바로 위의 **PR** 버블을 선택하여 검토 창에서 PR을 열고 끌어오기 요청을 확인합니다. 필요에 따라 여기에서 PR을 검토할 수 있습니다.
5. 준비가 되면 **Ready to merge**를 선택합니다.
6. 새 대화 상자에서 **Merge pull request**를 선택하여 끌어오기 요청을 병합합니다.
-이제 웹사이트에 새 기능을 제공했습니다.
+계속하기 전에 PR 1이 `main`에 병합되었는지 확인합니다. 학습용 리포지토리를 병합하는 것만으로 웹사이트가 배포되지는 않습니다. 다음 레슨은 새 워크트리에서 시작하고 `origin/main`으로 업데이트하여 이 PR을 포함합니다.
## 요약 및 다음 단계
@@ -118,7 +128,7 @@ PR이 만들어지면 Copilot은 리포지토리에서 실행해야 하는 워
- 에이전트에게 게임 카드를 작고 구체적으로 변경하도록 지시했습니다.
- 워크스페이스의 diff 보기에서 변경 내용을 검토했습니다.
- 앱을 로컬에서 실행하여 브라우저에서 별점을 확인했습니다.
-- 끌어오기 요청을 열고 github.com에서 직접 병합했습니다.
+- PR 1을 만들고 검사를 검토한 다음 명시적으로 병합했습니다.
다음으로 백로그의 이슈 중 하나에서 시작하여 앱으로 리포지토리에 사용자 지정 지침 표준을 추가합니다. [레슨 3 - 사용자 지정 지침으로 Copilot 안내][next-lesson]를 계속 진행합니다.
@@ -129,6 +139,7 @@ PR이 만들어지면 Copilot은 리포지토리에서 실행해야 하는 워
- [GitHub Copilot app으로 이슈 및 끌어오기 요청 관리][managing-issues-prs]
[prior-lesson]: ../1-install-copilot-app/#github-copilot-app-설치-및-구성
+[previous-lesson]: ../1-install-copilot-app/
[next-lesson]: ../3-custom-instructions/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
diff --git a/docs/ko-kr/app/3-custom-instructions.md b/docs/ko-kr/app/3-custom-instructions.md
index a8dad33c..978bc6ba 100644
--- a/docs/ko-kr/app/3-custom-instructions.md
+++ b/docs/ko-kr/app/3-custom-instructions.md
@@ -1,9 +1,9 @@
---
title: "Lesson 3 - 사용자 지정 지침으로 Copilot 안내"
-description: "GitHub Copilot app을 사용하여 백로그의 이슈에서 시작해 리포지토리에 사용자 지정 지침 표준을 추가하고 변경 내용을 끌어오기 요청으로 병합합니다."
+description: "문서화 표준을 추가하고 작은 기존 도우미나 구성 요소에서 시연한 다음 둘을 두 번째 끌어오기 요청으로 병합합니다."
authors:
- geektrainer
-lastUpdated: 2026-07-09
+lastUpdated: 2026-09-11
---
생성형 AI를 사용할 때는 컨텍스트가 중요합니다. 작업을 특정 방식으로 수행해야 하거나 Copilot이 알아야 할 배경 정보가 있다면 해당 컨텍스트를 제공해야 합니다. 가장 강력한 도구 중 하나는 원하는 코드의 *내용*뿐 아니라 코드의 *구조*도 설명하는 [지침 파일][instruction-files]입니다. 이 레슨에서는 리포지토리에 문서화 표준을 추가합니다. 이후 대부분의 작업과 마찬가지로 백로그의 이슈에서 시작하여 에이전트가 변경하도록 합니다.
@@ -12,15 +12,17 @@ lastUpdated: 2026-07-09
- 리포지토리 지침과 경로 범위 지침 파일이 에이전트에 전달되는 방식을 살펴봅니다.
- 백로그의 지침 이슈에서 세션을 시작합니다.
-- 에이전트에게 `.github/copilot-instructions.md`에 문서화 표준을 추가하도록 요청합니다.
-- 변경 내용을 검토하고 끌어오기 요청으로 병합합니다.
+- 에이전트에게 적절한 리포지토리 지침 파일에 범위를 좁힌 문서화 표준을 추가하도록 요청합니다.
+- 작은 실제 코드 변경으로 표준을 시연하고 검증한 다음 PR 2를 병합합니다.
## 시나리오
모범적인 개발 조직인 Tailspin Toys에는 개발 방식에 관한 지침과 요구 사항이 있습니다. 여기에는 다음 항목이 포함됩니다.
-- 코드에 TSDoc doc comments 형식의 문서를 추가해야 합니다.
-- 형식을 문서화하고 린팅으로 적용해야 합니다.
+- 주석은 코드를 다시 설명하기보다 의도와 명확하지 않은 결정을 설명해야 합니다.
+- `db/`와 `src/lib/`에서 내보내는 함수는 TSDoc/JSDoc으로 목적, 매개 변수, 반환값을 문서화하고, 주입 가능한 `db` 인수가 있다면 함께 설명해야 합니다.
+- 재사용 가능한 Astro 구성 요소는 `Props` 계약을 문서화하고, 관련 코드가 바뀌면 주석도 최신 상태로 유지해야 합니다.
+- 기존 서식과 린트 지침을 보존해야 합니다.
지침 파일을 사용하면 Copilot이 이러한 방식에 맞게 작업을 수행하는 데 필요한 정보를 제공할 수 있습니다.
@@ -28,13 +30,13 @@ lastUpdated: 2026-07-09
사용자 지정 지침은 Copilot에 컨텍스트와 기본 설정을 제공하여 코딩 스타일과 요구 사항을 더 잘 이해하게 합니다. 이 기능을 사용하면 Copilot이 더 관련성 높은 제안과 코드 조각을 생성하도록 안내할 수 있습니다. 선호하는 코딩 규칙과 라이브러리는 물론 코드에 포함할 주석 유형까지 지정할 수 있습니다. 리포지토리 전체에 적용되는 지침이나 작업 수준의 컨텍스트를 제공하는 특정 파일 유형용 지침을 만들 수 있습니다.
-지침 파일에는 두 가지 유형이 있습니다.
+이 프로젝트는 두 종류의 지침 파일을 사용합니다.
- `.github/copilot-instructions.md`는 리포지토리의 **모든** 요청에서 Copilot에 전달되는 단일 지침 파일입니다. 이 파일에는 Copilot에 보내는 대부분의 채팅 또는 CLI 요청과 관련된 프로젝트 수준 정보를 포함해야 합니다. 사용 중인 기술 스택, 구축 중인 항목의 개요, 모범 사례, 기타 전역 지침을 포함할 수 있습니다.
- 특정 작업이나 파일 유형에 맞게 `.github/instructions/*.instructions.md` 파일을 만들 수 있습니다. TypeScript 또는 Astro 같은 특정 언어나 UI 구성 요소 또는 새 단위 테스트 집합 만들기와 같은 작업에 관한 지침을 제공할 수 있습니다.
> [!NOTE]
-> Copilot은 AGENTS.md, CLAUDE.md, GEMINI.md를 통해 지침을 가져오는 다른 표준도 지원하므로 항상 올바른 컨텍스트를 제공할 수 있습니다.
+> 다른 지침 형식과 지원 여부는 하네스에 따라 다릅니다. 특정 형식에 의존하기 전에 [사용자 지정 지침 지원 참조][custom-instructions-support]를 확인합니다.
### 지침 파일 관리 모범 사례
@@ -74,49 +76,55 @@ AI를 사용하는 방식이 하나로 정해져 있지 않듯 지침 파일을
11. 마지막으로 `.github/instructions/drizzle.instructions.md`를 열고 아래쪽으로 스크롤합니다. 다른 지침 파일(예: `unit-tests.instructions.md`)과 프로젝트의 기존 파일로 연결되는 링크를 확인합니다. 이를 통해 큰 지침 집합을 더 작고 재사용 가능한 파일로 나누고 Copilot이 코드를 생성할 때 따를 예제를 지정할 수 있습니다. 이 경로는 리포지토리 루트가 아니라 지침 파일을 기준으로 합니다.
> [!NOTE]
-> `copilot-instructions.md`의 **Code formatting requirements** 섹션에는 프로젝트의 코딩 표준이 있지만 아직 코드 내 문서는 요구하지 않습니다. 다음 단계에서 TSDoc doc comments와 파일 주석 헤더에 관한 규칙을 추가합니다.
+> 규칙을 추가하기 전에 기존 지침과 실제 코딩 표준 이슈를 비교합니다. 이 레슨은 일률적인 파일 헤더나 코드를 다시 설명하는 주석이 아니라 의도 중심 주석, 내보내는 데이터 계층 함수 문서화, Astro `Props` 계약에 집중합니다.
## 지침 이슈에서 시작
-이전 레슨에서는 직접 프롬프트로 세션을 시작했습니다. 하지만 대부분의 작업은 이슈에서 시작합니다. 지침 파일 업데이트를 위해 등록된 이슈를 바탕으로 새 세션을 만들고 업데이트를 요청합니다.
+이 세션을 만들기 전에 PR 1이 병합되었는지 확인합니다. PR 2용 새 워크트리에서 시작하고 별점 브랜치에서 계속하지 않습니다. 대부분의 작업은 이슈에서 시작하므로 코딩 표준 이슈를 요구 사항으로 사용합니다.
> [!NOTE]
> 지침 파일은 Copilot이 생성하는 코드에 큰 영향을 주므로 Copilot을 명확하게 안내하는지 주의 깊게 확인해야 합니다. 이 레슨처럼 Copilot으로 초안을 만든 다음 요구 사항을 충족하는지 직접 검토하는 방법이 좋습니다.
1. 사이드바에서 **My work**를 선택합니다.
2. **Update our repository coding standards** 이슈를 선택하여 엽니다.
-3. 오른쪽 위의 **New session**을 선택하여 이슈를 바탕으로 새 세션을 시작합니다.
+3. 오른쪽 위의 **New session**을 선택하고 **new working tree**와 **Interactive** 모드를 선택합니다.
-4. 다음 프롬프트를 사용하여 이슈에 문서화된 요구 사항에 맞게 지침 파일을 업데이트하도록 Copilot에 요청합니다.
+4. 다음 프롬프트를 사용합니다. 편집 전에 새 세션 브랜치를 업데이트하면 앱의 로컬 체크아웃이 오래되었더라도 최근 병합된 `main`에서 실제로 시작할 수 있습니다.
- ```plaintext
- Following this issue, make the updates to the instructions files in this project to meet the requirements documented. Don't create the PR quite yet!
- ```
+ ```plaintext
+ 편집하기 전에 이 체크아웃과 브랜치를 식별하고 미커밋 변경이 없는 새 워크트리인지 확인한 다음 origin을 가져오고 이 세션 브랜치를 origin/main으로 fast-forward해 주십시오. HEAD가 origin/main과 일치하며 병합된 별점 PR을 포함하는지 확인해 주십시오. 미커밋 변경이나 분기가 있거나 해당 병합이 누락되었으면 중단해 주십시오. 재설정하거나 작업을 버리거나 다른 브랜치를 만들지 마십시오.
+
+ "Update our repository coding standards" 이슈와 기존 리포지토리 지침을 읽어 주십시오. 범위를 좁힌 문서화 규칙을 추가해 주십시오. 작동 방식보다 의도를 설명하고, db/와 src/lib/에서 내보내는 함수를 TSDoc/JSDoc으로 문서화하여 목적, 매개 변수, 반환값, 존재하는 경우 주입 가능한 db 인수를 다뤄 주십시오. 재사용 가능한 Astro 구성 요소의 Props 계약을 문서화하고 관련 코드 변경 시 주석도 최신 상태로 유지하도록 해 주십시오.
+
+ 중복이나 모순 없이 각 규칙을 적절한 기존 지침 파일에 배치하고 README에서 업데이트된 표준을 링크하거나 요약해 주십시오. 기존 서식과 린트 지침을 보존해 주십시오. 일률적인 파일 헤더를 요구하거나 서식 도구를 이전하거나 애플리케이션 전체의 문서를 다시 작성하거나 필터링을 구현하지 마십시오. 지침 diff를 보여 준 다음 검토를 위해 중단해 주십시오. 스킬이나 에이전트를 만들거나 커밋, 푸시, PR 생성을 하지 마십시오.
+ ```
Copilot이 업데이트를 적용합니다.
## 변경 내용 검토
-Copilot이 적용한 업데이트를 읽고, 업데이트된 지침을 바탕으로 앞으로 생성할 코드의 예제도 요청합니다.
+업데이트된 지침을 읽고 실제 파일에서 효과를 시연합니다. 코드 조각을 제안하는 것만으로는 리포지토리 지침이 코드 변경에 영향을 미쳤음을 보여 줄 수 없습니다.
1. 오른쪽 위의 **Changes**를 선택하여 코드 변경 내용을 엽니다.
-2. 업데이트된 지침 파일을 검토합니다. 코드에 문서와 주석을 추가하는 지침이 있는지 확인합니다.
+2. 업데이트된 지침 파일과 README 참조를 검토합니다. 일률적인 파일 헤더 요구 사항을 만들지 않고 이슈의 주석 철학, 내보내는 함수 문서화, 구성 요소 계약에 규칙이 맞는지 확인합니다.
> [!NOTE]
> AI는 결정론적이 아니라 확률적으로 작동하므로 정확한 텍스트는 달라질 수 있습니다.
-3. 다음 프롬프트를 사용하여 앞으로 생성할 코드의 예제를 만들도록 Copilot에 요청합니다.
+3. 지침을 검토한 후 동일한 세션에서 범위를 제한한 시연을 요청합니다.
+
+ ```plaintext
+ db/ 또는 src/lib/에서 내보내는 작은 기존 TypeScript 도우미 하나나 재사용 가능한 Astro 구성 요소 하나에서 업데이트된 문서화 규칙을 시연해 주십시오. 리포지토리를 살펴보고 적절한 기존 파일을 선택해 주십시오. publishers 도우미가 있다고 가정하지 마십시오. 동작을 보존하는 작은 가독성 개선을 적용하고 관련 함수 문서화 또는 Props 계약 지침을 적용해 주십시오. 코드를 다시 설명하기만 하는 주석을 추가하지 말고 명확하지 않은 의도를 설명해 주십시오.
- ```plaintext
- Do not make any updates, but show me what the code would look like. Based on the new instructions, if I asked Copilot to create a new library component to return all Publishers what would that code look like?
- ```
+ 변경 범위를 해당 시연과 직접 관련된 테스트로 제한해 주십시오. 필터링을 구현하거나 새 기능을 만들지 마십시오. 관련된 기존 npm 검사를 실행하고, 변경 내용과 지침이 코드에 미친 영향을 보고한 다음 검토를 위해 중단해 주십시오. 설치 전에 질문해 주십시오. 커밋, 푸시, PR 생성은 하지 마십시오.
+ ```
-4. Copilot이 제안한 코드를 검토합니다. 업데이트된 지침에서 요구한 대로 TSDoc doc comments와 파일 헤더 주석이 포함되어 있는지 확인합니다.
+4. 채팅 응답뿐 아니라 실제 파일 diff를 검토합니다. 문서가 실제 동작을 설명하는지, 가독성 변경이 동작을 보존하는지 확인합니다. 관련 테스트, 린트, 타입 검사 결과를 검토하고 실패를 해결한 후 계속합니다.
이제 프로젝트의 지침 파일을 업데이트하고 그 영향을 확인했습니다.
@@ -124,17 +132,23 @@ Copilot이 적용한 업데이트를 읽고, 업데이트된 지침을 바탕으
지침 파일은 리포지토리 자산이므로 팀의 다른 구성원과 공유됩니다. 다른 자산과 마찬가지로 작업 내용이 포함된 PR을 만듭니다.
-1. 오른쪽 위에서 **Create PR**을 선택합니다.
+먼저 검토한 지침과 시연을 함께 승인합니다.
+
+```plaintext
+관련 테스트를 포함하여 코딩 표준 지침, README 참조, 범위를 제한한 코드 시연의 전체 diff를 검토해 주십시오. 검증 결과를 요약하고 검토한 변경을 이 세션 브랜치에 커밋해 주십시오. 브랜치를 푸시하고 리포지토리의 PR 템플릿을 사용하며 코딩 표준 이슈를 연결하여 main을 대상으로 끌어오기 요청 하나를 만들어 주십시오. 이슈의 모든 수락 기준을 충족하지 않았다면 부분 기여로 설명하고, 미완료 작업에는 이슈를 닫는 키워드를 사용하지 마십시오. 병합하지 마십시오.
+```
+
+1. 세션의 PR 링크를 엽니다. 앱에 **Create PR** 확인이 표시되면 중복 PR을 만들지 않고 이를 선택합니다.
2. 메시지가 표시되면 **Sign in with your browser**를 선택하고 안내에 따라 인증합니다.
3. Copilot이 PR을 만들기 시작합니다.
-PR이 만들어지면 Copilot은 리포지토리에서 실행해야 하는 워크플로를 모니터링합니다. 잠시 후 오른쪽 위의 버튼이 **Ready to merge**로 바뀝니다. 이는 PR을 병합할 준비가 되었다는 표시입니다.
+**My work**에서 지침과 코드 변경을 모두 포함한 전체 PR diff를 살펴봅니다. 학습용 리포지토리의 CI 결과와 필수 검토를 확인합니다. 실패를 해결한 후 **Ready to merge**를 선택합니다. CI는 시연이나 직접 검토를 대체하지 않습니다.
4. **Ready to merge**를 선택합니다.
5. 새 대화 상자에서 **Merge pull request**를 선택하여 끌어오기 요청을 병합합니다.
> [!NOTE]
-> 표준을 기본 브랜치에 병합하면 모든 사용자와 새 세션에서 프로젝트의 일부로 사용됩니다. 다음 레슨에서 최신 기본 브랜치로 필터링 세션을 시작하면 에이전트가 이 표준을 자동으로 따릅니다. 요청하지 않아도 생성된 TypeScript에 TSDoc doc comments가 포함되는 것을 통해 지침이 생성 코드에 미치는 작지만 실제적인 영향을 확인할 수 있습니다.
+> 필터링을 시작하기 전에 PR 2가 `main`에 병합되었는지 확인합니다. 새 워크트리만으로 최신 코드를 보장할 수는 없습니다. 레슨 4에서 원격 내용을 가져오고 새 세션 브랜치를 `origin/main`으로 fast-forward한 다음 앞선 두 병합이 모두 포함되었는지 확인한 후 계획합니다.
## 요약 및 다음 단계
@@ -142,10 +156,10 @@ PR이 만들어지면 Copilot은 리포지토리에서 실행해야 하는 워
- 리포지토리의 `copilot-instructions.md`와 경로 범위 `*.instructions.md` 파일을 살펴봤습니다.
- 백로그의 지침 이슈에서 세션을 시작했습니다.
-- 에이전트에게 `.github/copilot-instructions.md`에 문서화 표준을 추가하도록 요청했습니다.
-- 변경 내용을 검토하고 끌어오기 요청으로 병합했습니다.
+- 에이전트에게 적절한 지침 파일에 범위를 좁힌 문서화 규칙을 추가하고 README에서 참조하도록 요청했습니다.
+- 실제 코드 변경에 표준이 미친 영향을 살펴보고 결과를 검증한 다음 둘을 PR 2로 병합했습니다.
-다음으로 새 세션에서 필터링 기능을 구축하고 방금 병합한 표준이 자동으로 적용되는지 확인합니다. [레슨 4 - Autopilot으로 기능 구축][next-lesson]을 계속 진행합니다.
+다음으로 새 세션에서 필터링 기능을 구축하고 방금 병합한 표준을 따르는지 확인합니다. [레슨 4 - Plan과 Autopilot으로 필터링 구축][next-lesson]을 계속 진행합니다.
## 리소스
@@ -154,6 +168,7 @@ PR이 만들어지면 Copilot은 리포지토리에서 실행해야 하는 워
- [사용자 지정 지침 만들기 모범 사례][instructions-best-practices]
- [Awesome Copilot — 지침 파일 및 기타 리소스 모음][awesome-copilot]
+[previous-lesson]: ../2-add-star-rating/
[next-lesson]: ../4-build-filtering/
[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/ko-kr/app/4-build-filtering.md b/docs/ko-kr/app/4-build-filtering.md
index 1bf692d4..48e5656f 100644
--- a/docs/ko-kr/app/4-build-filtering.md
+++ b/docs/ko-kr/app/4-build-filtering.md
@@ -1,186 +1,122 @@
---
-title: "Lesson 4 - Autopilot으로 기능 구축"
-description: "GitHub Copilot app의 Plan 및 Autopilot 모드로 정적 클라이언트 쪽 필터링 기능을 구축하고, 문서화 표준이 적용되는지 확인하고, 에이전트 스킬로 검증합니다."
+title: "Lesson 4 - Plan과 Autopilot으로 필터링 구축"
+description: "이슈를 바탕으로 필터링을 계획하고 Autopilot을 명시적으로 승인한 다음 기존 npm 검사와 수동 브라우저 확인으로 검증하고 체크포인트를 저장합니다."
authors:
- geektrainer
-lastUpdated: 2026-07-13
+lastUpdated: 2026-09-11
---
-지금까지 프로젝트를 작게 몇 차례 업데이트했습니다. 하지만 더 큰 변경에는 더 탄탄한 프로세스가 필요합니다. GitHub Copilot app은 기존 흐름과 함께 작동하도록 구축되어 올바른 항목을 올바른 방식으로 만들 수 있게 합니다. 이 레슨은 일반적인 개발 프로세스를 따르는 세 레슨 중 첫 번째입니다. 이슈를 사용하여 새 기능을 생성하고 에이전트 스킬로 검증 테스트와 린터를 실행합니다.
+별점과 코드 시연이 포함된 문서화 표준을 병합했습니다. 이제 필터링 기능을 구축합니다. 하나의 큰 PR 마일스톤을 시작하는 단계입니다. 레슨 4~8에서 동일한 세션, 워크트리, 브랜치를 유지합니다.
이 레슨에서는 다음 작업을 수행합니다.
-- 필터링 이슈에서 새 세션을 시작합니다.
-- **Plan** 모드로 기능을 계획한 다음 **Autopilot**으로 구축합니다.
-- 생성된 코드가 이전에 병합한 문서화 표준을 따르는지 확인합니다.
-- 프로젝트의 `quality-checks` 스킬로 작업을 검증합니다.
+- 업데이트된 `main`에서 시작하고 실제 필터링 이슈를 읽습니다.
+- **Plan** 모드에서 요구 사항을 확정한 다음 **Autopilot**을 명시적으로 승인합니다.
+- 필터링과 테스트를 검토하고 기존 npm 검사 네 가지를 실행합니다.
+- 브라우저에서 기능을 수동으로 확인하고 체크포인트를 저장합니다.
-## 시나리오
+스킬, MCP 검증, QA 프로필, 기능 PR은 이후 모듈에서 다룹니다. 이 구현 단계에서 만들지 않습니다.
-홈페이지에는 모든 게임이 표시되지만 방문자는 목록을 좁힐 수 없습니다. 필터링 이슈에서는 **category**와 **publisher**로 게임을 필터링할 수 있게 해 달라고 요청합니다. Copilot을 사용하여 이 기능을 구현합니다.
-
-## 배경
+## 세션 모드
-AI 코딩 에이전트를 개발 흐름에 도입해도 기본 원칙은 달라지지 않습니다. 오히려 더 중요해집니다. 대부분의 개발자는 다음과 비슷한 흐름을 따릅니다.
+프롬프트 아래의 모드 선택기는 에이전트의 자율성을 제어합니다.
-1. 수행할 작업의 세부 정보가 담긴 이슈를 엽니다.
-2. 구축할 항목을 계획합니다.
-3. 코드를 구축하고 검토합니다.
-4. 테스트를 실행하여 코드를 검증합니다.
-5. 새 기능을 수동으로 검증합니다.
-6. 끌어오기 요청(PR)을 만듭니다.
-7. 코드를 검토하고 지속적 통합 프로세스가 성공하면 코드를 병합합니다.
+- **Interactive**는 에이전트가 작업하고 입력을 요청하는 동안 사용자가 계속 참여하도록 합니다.
+- **Plan**은 구현 전에 검토할 계획을 준비합니다.
+- **Autopilot**은 승인된 범위와 권한 안에서 자율적으로 구현하고 반복합니다.
-> [!NOTE]
-> 정확한 세부 사항은 팀과 조직에 따라 달라지지만 대부분 위 주제의 변형입니다.
+먼저 계획하고 명시적으로 승인한 다음, 재사용 가능한 사용자 지정을 만들기 전에 Interactive로 돌아갑니다.
-이 표준 접근 방식을 따르면 AI가 생성한 코드가 요구 사항을 충족하고 사람이 작성한 코드와 동일한 검증 과정을 거치게 할 수 있습니다.
+## 업데이트된 main에서 시작
-## 세션 모드
+GitHub에서 PR 1과 PR 2가 병합되었는지 확인합니다. 이전 브랜치에서 계속하지 말고 필터링용 새 워크트리를 만듭니다.
-**세션 모드**는 에이전트의 자율성 수준을 제어합니다. 프롬프트 필드 아래의 드롭다운에서 설정하고 언제든지 변경할 수 있습니다.
+1. **My work**를 선택하고 **Allow users to filter games by category and publisher**를 제목으로 찾습니다. 이슈를 열고 실제 URL을 복사합니다. 이슈 번호는 리포지토리마다 다릅니다.
+2. **New session**을 선택하고 **new working tree**를 선택합니다. 시작 상태를 업데이트할 때는 **Interactive** 모드를 유지합니다.
-- **Interactive**: 사용자와 에이전트가 함께 작업합니다. 에이전트는 변경을 제안하고 진행하기 전에 사용자의 입력을 기다립니다.
-- **Plan**: 에이전트가 먼저 계획을 만듭니다. 에이전트가 실행하기 전에 계획을 검토하고 승인합니다.
-- **Autopilot**: 에이전트가 입력을 기다리지 않고 코드 작성, 테스트 실행, 반복 작업을 완전히 자율적으로 수행합니다.
+ 
-## 필터링 기능 계획
+3. 계획하거나 편집하기 전에 다음 준비 요청을 보냅니다.
-잠재적인 문제는 코드를 작성하기 전에 발견하는 것이 가장 좋으며, 사전 계획이 이를 돕습니다. Copilot에 계획을 요청하면 단계와 접근 방식을 문서화합니다. 계획을 검토하고 개선 제안을 한 후 해당 계획을 바탕으로 Copilot이 코드를 생성하게 할 수 있습니다.
-
-이슈를 열고 새 세션을 시작한 다음 Plan 모드로 전환하여 계획을 만듭니다.
+ ```plaintext
+ 아무것도 구현하지 않고 이 새 필터링 세션을 준비해 주십시오. 체크아웃과 브랜치를 식별하고, 워크트리에 미커밋 변경이 없는지 확인하고, origin을 가져온 다음 이 세션 브랜치를 origin/main으로 fast-forward해 주십시오. HEAD가 origin/main과 일치하고 병합된 별점 및 코딩 표준 PR을 포함하는지 확인해 주십시오.
-1. 탐색 탭에서 **My work**를 선택합니다.
-2. **Allow users to filter games by category and publisher** 이슈를 선택합니다.
-3. 오른쪽 위의 **New session**을 선택합니다.
+ 체크아웃에 미커밋 변경이나 분기가 있거나 두 병합 중 하나라도 누락되었다면 중단하고 설명해 주십시오. 재설정하거나 작업을 버리거나 브랜치를 전환하거나 다른 브랜치를 만들거나 애플리케이션 파일을 편집하지 마십시오. 시작 리비전을 보고해 주십시오.
+ ```
- 
+4. 보고된 시작 상태를 확인합니다. 가져오기만으로는 워크트리를 업데이트할 수 없습니다. 작업 시작 전에 현재 세션 브랜치를 fast-forward하고 `HEAD`가 가져온 `origin/main`과 일치해야 합니다.
-4. 모드에 **Plan**이 표시될 때까지 Shift+Tab을 선택합니다.
+## 필터링 기능 계획
- 
+모드 선택기를 **Plan**으로 전환합니다. 아래 이슈 자리 표시자를 복사한 URL로 바꿉니다.
-5. 다음 프롬프트를 보냅니다. 이슈에서 세션을 시작했으므로 필터링 이슈는 이미 세션의 컨텍스트에 있습니다.
+```plaintext
+이 이슈를 바탕으로 필터링 기능을 계획해 주십시오: . 전체 수락 기준과 리포지토리 지침을 읽고 현재 정적 Astro 애플리케이션 및 기존 데이터 접근 도우미와 테스트를 살펴봐 주십시오. 아직 구현하지 마십시오.
- ```plaintext
- Plan the work based on the requirements documented in the issue. Please ask any clarifying questions you might have as you build the plan.
- ```
+이슈에서 요구하는 여러 카테고리 선택, 퍼블리셔 필터링, 카테고리와 퍼블리셔의 조합 필터링, 적절한 데이터 접근 도우미, 접근성 있는 컨트롤, 단위 및 엔드투엔드 테스트 커버리지를 다뤄 주십시오. 여러 카테고리를 조합하는 방식, 필터 초기화, 빈 결과 등 지정되지 않은 동작은 임의로 요구 사항을 만들지 말고 질문해 주십시오. 요구 사항과 기존 아키텍처가 정당화하지 않는 한 서버 API를 도입하지 마십시오.
-6. 에이전트가 계획을 세우면서 후속 질문을 할 수 있습니다. 기능을 구축할 방식에 따라 답변합니다.
+리포지토리 문서화 규칙을 따르고 필요한 단위 및 엔드투엔드 테스트를 추가하거나 업데이트하는 범위가 제한된 구현 및 검증 계획을 제안해 주십시오. package.json에서 명령을 확인한 후 기존 프로젝트 도구로 npm run lint, npm run test:unit, npm run test:e2e, npm run typecheck:all을 실행하도록 계획해 주십시오. QA에서 재사용할 수 있도록 이슈 URL과 제가 승인한 추가 합의 사항을 계획에 기록해 주십시오.
-> [!NOTE]
-> Copilot은 확률적으로 작동하므로 정확한 후속 질문은 달라질 수 있으며 질문을 하지 않을 수도 있습니다. 이는 정상입니다.
+승인 전에 다음 실행 안전장치를 계획에 포함해 주십시오. 테스트할 체크아웃과 서버를 식별하고, 검사 전에 필수 조건을 확인하며, 소프트웨어·의존성·브라우저 설치 전에 질문해 주십시오. 다른 워크트리의 서버를 재사용하지 말고 직접 시작한 서버만 중지하며, 다른 포트 충돌은 관련 없는 프로세스를 중지하지 말고 보고해 주십시오. 누락된 필수 조건과 건너뛴 검사는 통과가 아니라 차단 요인으로 보고해야 합니다.
-7. 완료되면 Copilot이 계획 요약을 제공합니다. 계획을 검토합니다. 쿼리 구축, 필터 컨트롤 추가, 테스트를 제안해야 합니다. 원하는 경우 피드백을 제공하여 구체화할 수 있으며 에이전트는 제안을 새 버전에 반영합니다.
+계획에 다음 구현 경계를 포함해 주십시오. 제가 Autopilot을 명시적으로 승인한 후, 동일한 워크트리와 브랜치에서 합의한 필터링 기능과 테스트만 구현하고 네 가지 검사를 실행하며, 실패나 차단 요인을 포함한 구현 내용과 모든 검사 결과를 보고한 다음 검토와 수동 브라우저 확인을 위해 중단해 주십시오. 구현 중에는 스킬이나 사용자 지정 에이전트를 만들거나 MCP를 구성하거나 브랜치를 변경하거나 커밋, 푸시, PR 생성을 하지 마십시오. 수동 브라우저 확인과 체크포인트 커밋은 나중에 별도 지시에 따라 진행합니다.
-## Autopilot으로 구축
+지금은 Plan 모드를 유지하고 제가 검토할 수 있도록 계획을 제시한 뒤 중단해 주십시오. 구현하거나 스킬이나 사용자 지정 에이전트를 만들거나 MCP를 구성하거나 브랜치를 변경하거나 커밋, 푸시, PR 생성을 하지 마십시오.
+```
-계획을 만들었으므로 Copilot이 구현을 구축하게 합니다.
+확인 질문에 답하고 이슈와 비교하여 계획을 검토합니다. UI만 구현하는 계획을 수락하지 말고 데이터 접근 변경, 접근성 있는 컨트롤, 테스트를 확인합니다. 레슨 6과 7에서 사용할 실제 이슈 URL과 승인한 추가 합의 사항을 계획에서 저장합니다. 추가 기준이 필요하지 않았다면 `none`을 사용합니다.
-1. **Plan summary** 대화 상자의 옵션 목록에서 **Approve and implement with autopilot**과 가장 가까운 옵션을 선택합니다.
+승인하기 전에 계획 자체에 네 가지 검사, 문서화 규칙, 필수 조건 및 서버 안전장치, 동일한 워크트리와 브랜치 유지 요구 사항, 구현과 검증 후 중단 조건이 포함되었는지 확인합니다. 구현 중에는 이후 스킬, 에이전트, MCP 설정, 커밋, 푸시, PR을 금지해야 합니다. 경계가 누락되면 **Plan** 모드에서 수정 계획을 요청하고 수정본을 검토한 후 승인합니다.
-Copilot이 구현 작업을 시작합니다.
+## Autopilot 명시적 승인
-> [!NOTE]
-> Copilot이 필요한 코드를 자동으로 만들기 시작하지 않으면 "Go ahead and start building out the plan!" 같은 프롬프트로 요청할 수 있습니다.
->
-> 필요한 업데이트를 만드는 데 몇 분 정도 걸립니다. 에이전트는 파일을 편집하고 만들며, 테스트를 작성하고 실행하고, 반복해서 개선합니다. 지금까지 살펴본 내용을 돌아보거나 잠시 쉬어도 좋습니다.
+검토한 계획에 요구 사항과 모든 실행 경계가 포함된 후에만 계획 승인 컨트롤에서 **Approve and implement with autopilot** 또는 사용 중인 버전에 표시되는 동등한 명시적 Autopilot 옵션을 선택합니다. 모드 표시가 **Autopilot**인지 확인합니다.
-## 변경 내용 검토
+승인 즉시 실행이 시작될 수 있습니다. 따라서 구현 범위, 안전 규칙, 중단 경계를 모두 승인 전에 검토한 계획에 포함해야 합니다. 실행 시작 후 후속 메시지로 추가하는 방식에 의존하지 않습니다.
-AI가 생성한 모든 코드는 병합 전에 검토해야 합니다. 코드를 검토하고 사이트를 실행하여 올바르게 작동하는지 확인합니다.
+Autopilot은 코드와 테스트를 작성하고 실패를 반복해서 해결할 수 있지만, 이 권한이 이후 워크숍 모듈까지 완료하라는 허가는 아닙니다. 누락된 필수 조건은 승인을 받아 해결할 차단 요인이지 통과한 검사가 아닙니다.
-1. 오른쪽 위의 **Changes**를 선택하여 코드 변경 내용을 엽니다.
+## 구현 검토 및 검증
- 
+1. **Changes**를 열고 필터링 구현과 테스트를 살펴봅니다.
+2. 여러 카테고리와 퍼블리셔 조합을 포함하여 결과를 이슈 및 승인한 추가 합의 사항과 비교합니다. 새로 만들거나 변경한 도우미가 레슨 3의 문서화 표준을 따르는지 확인합니다.
+3. 네 가지 npm 검사 모두의 실제 명령 출력을 확인합니다. quality-checks 스킬을 아직 만들지 않았으므로 지금은 직접 실행합니다.
+4. 구현을 수락하기 전에 실패를 해결하고 관련 검사를 다시 실행합니다. Playwright E2E 구성은 빌드하고 미리 보기를 제공하며 로컬 서버를 재사용할 수 있습니다. 테스트한 서버가 이전 레슨이 아니라 이 워크트리의 서버인지 확인합니다.
-2. 변경 내용을 검토합니다. 새 TypeScript, Astro, 테스트 파일이 표시되어야 합니다. 새 도우미 함수에 TSDoc doc comments와 파일 헤더 주석이 있는지 확인합니다. 레슨 3에서 병합한 문서화 표준이 요청 없이 자동으로 적용된 것입니다.
-3. Copilot app 오른쪽의 검토 패널에서 **Terminal**을 선택합니다. **Terminal** 버튼이 없으면 **+**(**Open in panel** 레이블)를 선택한 다음 **Terminal**을 선택합니다.
+## 기능 수동 확인
- 
+수동 검토 전에 세션을 **Interactive** 모드로 되돌리고 레슨 5에서도 유지합니다.
-4. 터미널 창에 다음 명령을 입력하여 웹앱의 개발 서버를 시작합니다.
+1. 이 세션의 검토 패널에서 **Terminal**을 엽니다. 필요하면 **+**를 선택한 다음 **Terminal**을 선택합니다.
+2. 터미널이 필터링 워크트리에 있는지 확인하고 실행합니다.
```shell
npm run dev
```
-5. 서버가 시작되면 브라우저 창을 엽니다. 잠시만 기다리면 됩니다.
-6. [http://localhost:4321](http://localhost:4321)로 이동합니다.
-7. 이제 랜딩 페이지에 필터가 표시되어야 합니다.
-8. 올바르게 보이지 않는 항목이 있으면 Copilot에 업데이트를 요청할 수 있습니다.
-9. 만족하면 터미널 창으로 돌아갑니다.
-10. Ctrl+C를 선택하여 개발 서버를 중지합니다.
+3. 서버가 출력한 URL을 브라우저에서 엽니다. 일반적으로 `http://localhost:4321`입니다. 포트가 사용 중이면 관련 없는 프로세스를 중지하거나 기존 서버에 변경 내용이 있다고 가정하지 말고 소유자를 확인합니다.
+4. 승인한 동작에 맞춰 카테고리 선택, 퍼블리셔 선택, 두 조건의 조합을 사용해 봅니다. 키보드 접근성과 합의한 초기화 및 빈 결과 동작도 확인합니다.
+5. 실패하면 범위를 좁힌 수정을 요청하고 diff를 검토한 다음 관련 자동 검사와 브라우저 검사를 다시 수행합니다.
+6. 터미널로 돌아와 Control+C(Mac) 또는 Ctrl+C(Windows/Linux)를 눌러 직접 시작한 서버를 중지합니다. 다음 모듈의 E2E 실행 전에 중지되었는지 확인합니다.
-## quality-checks 스킬로 작업 검증
+이는 직접 수행한 브라우저 관찰입니다. MCP를 통한 에이전트의 브라우저 관찰은 레슨 6에서 다룹니다.
-diff를 눈으로 확인하고 끝낼 수도 있지만 팀에는 정해진 품질 기준과 이를 반복해서 확인하는 방법이 있습니다.
+## 체크포인트 저장
-**에이전트 스킬(Agent skills)**은 테스트 실행, 빌드 생성, 끌어오기 요청 만들기처럼 반복 가능한 작업을 수행하는 방법을 Copilot에 안내합니다. 스킬은 에이전트가 필요할 때 불러올 수 있는 지침, 스크립트, 리소스가 담긴 폴더입니다. [Agent Skills는 공개 표준][agent-skills-repo]이며 다양한 에이전트에서 사용되므로 동일한 스킬을 에이전트 모드의 Copilot Chat, Copilot cloud agent, Copilot CLI, GitHub Copilot app에서 사용할 수 있습니다.
+변경 내용과 검증 결과를 검토한 후 로컬 커밋을 승인합니다.
-스킬은 프로젝트의 `.github/skills` 폴더 또는 전역 `~/.copilot/skills`에 있습니다. 각 스킬은 YAML frontmatter의 `name`과 `description` 뒤에 Markdown 지침이 이어지는 `SKILL.md` 파일을 포함하는 폴더입니다.
-
-```yaml
----
-name: quality-checks
-description: Run the project's test suites and linter to verify code changes are ready to commit, push, or merge.
----
+```plaintext
+현재 diff를 검토하고 필터링 구현과 테스트의 체크포인트 커밋을 만들어 주십시오. 동일한 필터링 브랜치와 워크트리를 유지해 주십시오. 스킬이나 에이전트를 만들거나 MCP를 구성하거나 푸시하거나 끌어오기 요청을 만들지 마십시오.
```
-스킬에는 스크립트, 자산, 참조 자료가 담긴 하위 폴더도 포함할 수 있습니다. 전체 구조는 [에이전트 스킬 사양][agent-skills-spec]에서 확인할 수 있습니다.
-
-> [!TIP]
-> 스킬은 동적으로 불러옵니다. 에이전트는 `description` 필드를 바탕으로 적용할 스킬을 결정하므로, 명확하고 시나리오에 맞는 설명이 있어야 스킬을 제대로 사용할 수 있습니다.
-
-## quality-checks 스킬 살펴보기
-
-스킬의 작동 방식을 살펴봅니다.
-
-1. 검토 패널이 표시되지 않으면 오른쪽 위의 **Toggle review panel**을 선택하여 엽니다.
-
- 
-
-2. 검토 패널에 새 항목을 추가하려면 **+**를 선택합니다.
-3. **File**을 선택합니다.
-4. `SKILL.md`를 검색합니다.
-5. 파일 목록에서 `SKILL.md .github/skills/quality-checks`를 선택하여 엽니다.
-6. `name`과 `description`을 확인합니다. 설명은 커밋, 푸시, 병합 전에 코드 변경을 테스트하거나 린팅하거나 검증할 때 이 스킬을 사용하라고 에이전트에 알려 줍니다.
-7. 스킬을 읽습니다. 어떤 스크립트가 어떤 도구 모음(단위 테스트, Playwright 엔드투엔드 테스트, ESLint)을 어떤 순서로 실행하는지, 일반적인 실패를 디버그하는 방법은 무엇인지 확인합니다. 따라서 에이전트가 추측하지 않고 팀의 방식대로 검사를 실행합니다.
-
-## 검사 실행
-
-동일한 필터링 세션에서 에이전트에게 작업을 검증하도록 요청합니다. 스킬 이름을 설명하지 않아도 에이전트가 요청과 일치시킵니다.
-
-1. Copilot app으로 돌아갑니다.
-2. 슬래시 명령 `/quality-checks`를 사용하여 스킬을 직접 호출하고 Enter를 선택합니다.
-3. 에이전트는 스킬에 따라 단위 테스트, 린터, 엔드투엔드 테스트를 실행하고 결과를 보고합니다. 실패하는 항목이 있으면 문제를 수정하고 모두 통과할 때까지 검사를 다시 실행하도록 요청합니다.
-4. **이 세션을 열어 둡니다.** 다음 레슨에서 Playwright MCP 서버를 추가하고 실제 브라우저에서 필터링 기능이 작동하는지 확인합니다.
-
-## 요약 및 다음 단계
-
-실제 기능을 처음부터 끝까지 구축하고 팀의 품질 기준에 맞게 검증했습니다. 구체적으로 다음 작업을 수행했습니다.
-
-- 최신 프로젝트의 필터링 이슈에서 새 세션을 시작했습니다.
-- Plan 모드로 기능을 계획하고 Autopilot으로 구축했습니다.
-- 생성된 도우미가 레슨 3에서 병합한 문서화 표준을 따르는지 확인했습니다.
-- `quality-checks` 스킬로 작업을 검증했습니다.
-
-다음으로 Playwright MCP 서버를 연결하고 에이전트에게 실제 브라우저에서 필터링 기능을 살펴보도록 요청합니다. [레슨 5 - Playwright MCP 서버로 테스트][next-lesson]를 계속 진행합니다.
+이 체크포인트는 PR 3의 일부이며 별도 PR이 아닙니다. 동일한 세션에서 **Interactive** 모드를 유지하고 [레슨 5 - quality-checks 스킬 만들기 및 사용][next-lesson]을 진행합니다.
## 리소스
- [GitHub Copilot app에서 에이전트 세션 사용][agent-sessions]
-- [Agent Skills 정보][about-agent-skills]
-- [GitHub Copilot app 사용자 지정][customize-app]
- [GitHub Copilot용 클라우드 및 로컬 샌드박스 정보][sandboxes]
-[ex0]: ../0-prerequisites/
-[ex2]: ../2-add-star-rating/
-[ex3]: ../3-custom-instructions/
-[next-lesson]: ../5-mcp-playwright/
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
\ No newline at end of file
diff --git a/docs/ko-kr/app/5-agent-skills.md b/docs/ko-kr/app/5-agent-skills.md
new file mode 100644
index 00000000..639d8f54
--- /dev/null
+++ b/docs/ko-kr/app/5-agent-skills.md
@@ -0,0 +1,93 @@
+---
+title: "레슨 5 - quality-checks 스킬 만들기 및 사용"
+description: "재사용 가능한 셸 스크립트 기반 품질 검사를 Copilot에 요청하고, 스킬을 검토한 후 필터링 브랜치에서 실행합니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+필터링 기능을 구현하고 기존 npm 명령으로 검사했습니다. 이제 이러한 검사를 재사용 가능한 **에이전트 스킬**로 묶습니다. 레슨 4~8에서 동일한 필터링 세션과 브랜치를 유지합니다. 이 레슨에서는 끌어오기 요청을 만들지 않습니다.
+
+이 레슨에서는 다음을 수행합니다.
+
+- 사용자 지정을 만들기 전에 **Interactive** 모드로 돌아옵니다.
+- Copilot에 `quality-checks`를 만들고 검토를 위해 중단하도록 요청합니다.
+- 함께 제공되는 스크립트로 네 가지 검사를 모두 실행하고, 단일 테스트 파일을 지정하는 인수가 해당 파일만 선택함을 입증합니다.
+- 필터링 기능과 함께 스킬의 체크포인트를 저장합니다.
+
+## 지침, 스크립트, 리소스
+
+스킬은 에이전트가 필요할 때 불러오는 재사용 가능한 작업 지침, 실행 가능한 스크립트, 보조 리소스를 묶습니다. 사용자 지정 에이전트는 전문 역할, 지침, 사용 가능한 도구를 정의합니다. 두 방식은 상호 보완적입니다. 사용자 지정 에이전트도 스킬에 포함된 스크립트를 비롯한 스크립트를 실행할 수 있습니다.
+
+리포지토리 스킬은 `.github/skills//SKILL.md`에 있으며 `name`과 `description` 프런트매터 및 Markdown 지침을 포함합니다. 스크립트와 다른 리소스는 그 옆에 둡니다. 완성된 답을 복사하지 않고 Copilot에 `.github/skills/quality-checks/SKILL.md`와 함께 제공되는 스크립트를 생성하도록 요청합니다. [Agent Skills 명세][skill-spec]에서 형식을 설명합니다.
+
+Copilot은 발견한 스킬의 설명으로 언제 불러올지 판단합니다. 이미 열린 세션에서 새 스킬을 즉시 발견한다고 가정하지 않습니다. 실행 절에서는 명시적으로 읽는 대체 절차를 제공합니다. 이식 가능한 형식이라고 해서 셸이나 프로젝트 필수 조건이 없어지지는 않습니다.
+
+## 스킬 만들기
+
+프롬프트를 보내기 전에 모드 선택기로 필터링 세션을 **Interactive** 모드로 되돌립니다. 현재 체크아웃과 브랜치를 유지합니다. 이 스킬이 이미 있는 이전 템플릿으로 시작했다면 사용자 지정을 덮어쓰지 말고 검토하여 확장합니다.
+
+```plaintext
+.github/skills/quality-checks/SKILL.md와 npm run lint, npm run test:unit, npm run test:e2e, npm run typecheck:all을 호출하는 스크립트 4개를 만들어 주십시오. 먼저 package.json, README, 테스트 설정, 리포지토리 지침을 읽어 주십시오.
+
+현재 환경을 감지해 주십시오. macOS/Linux/WSL이면 Bash .sh 스크립트만, 네이티브 Windows이면 PowerShell .ps1 스크립트만 만들고, 확실하지 않으면 질문해 주십시오. 두 가지 모두 만들지 마십시오. 래퍼는 자신의 위치에서 리포지토리 루트를 찾고, 그곳에 이 프로젝트의 package.json이 있는지 검증한 후 npm을 호출하는 역할로 제한해 주십시오. 루트가 잘못되면 명확한 오류와 함께 실패하도록 해 주십시오. 어떤 작업 디렉터리와 공백이 있는 경로에서도 작동해야 합니다. 출력과 실패 종료 코드를 유지하고 PowerShell 네이티브 명령 실패도 처리해 주십시오. npm의 -- 구분자는 정확히 한 번만 삽입하고, 호출자는 추가 -- 없이 도구의 인수를 직접 전달하도록 해 주십시오. 포트나 프로세스를 관리하지 마십시오.
+
+SKILL.md에 name과 description 프런트매터, 래퍼 4개를 실행하는 지침, 필수 조건, 문제 해결 방법, 기존 단위 테스트 파일 하나를 사용하는 예시를 포함한 이식 가능한 호출 예시를 작성해 주십시오. 모든 Bash 예시는 bash를 명시적으로 호출해야 하며, PowerShell 실행 정책은 절대 우회하지 마십시오. Playwright 서버 재사용을 설명하고, 실제로 직접 시작한 서버만 중지하며 그렇지 않으면 질문하도록 해 주십시오.
+
+스킬과 필요한 스크립트만 만들어 주십시오. 검사나 탐색용 실행을 하거나, 무언가를 설치하거나, 애플리케이션 코드를 변경하거나, 커밋하거나, PR을 열지 마십시오. 검토할 수 있도록 중단해 주십시오.
+```
+
+## 스킬 검토
+
+1. **Changes**를 열어 생성된 파일을 검토합니다. 검토 패널에서 **+**, **File**을 선택한 후 `SKILL.md`나 스크립트 파일명을 검색할 수도 있습니다.
+2. `name`과 `description`이 스킬과 적용 시점을 설명하는지 확인합니다. 메타데이터뿐 아니라 지침도 읽습니다.
+3. 실행 순서가 lint, 단위 테스트, E2E, 타입 검사를 위해 `.github/skills/quality-checks/` 아래에 함께 제공되는 스크립트를 실제로 호출하는지 확인합니다.
+4. 각 래퍼에서 스크립트 위치 기반 루트 탐색과, 찾은 디렉터리에 이 체크아웃에서 의도한 `package.json`이 있는지 명시적으로 확인하는 절차를 살펴봅니다. npm이 상위 디렉터리를 검색하여 명령이 성공한 것은 루트가 올바르다는 증거가 아닙니다. 경로의 따옴표 처리, 인수 전달, 출력 표시, 실패 종료를 확인합니다. PowerShell은 네이티브 npm 실패를 전달해야 합니다.
+5. 문서화된 단일 단위 테스트 파일 실행 예시를 확인합니다. 래퍼가 npm의 `--` 구분자를 삽입하므로 호출자는 다른 구분자 없이 대상 도구의 인수를 직접 전달합니다. 재사용 가능한 지침에는 특정 컴퓨터의 절대 체크아웃 경로를 포함하지 않습니다. 실행 전에 부족한 부분을 수정하도록 Copilot에 요청합니다.
+6. 스크립트는 루트/매니페스트 검증과 기존 npm 검사 실행으로 제한합니다. 포트와 프로세스에 관한 판단은 셸 프로세스 관리 코드가 아니라 SKILL.md에 둡니다. 에이전트가 실제로 시작한 서버만 중지할 수 있는지 확인합니다. 작업 디렉터리나 프로세스 이름이 일치한다고 소유권이 성립하지는 않습니다. 제공한 파일에는 스킬, 필수 래퍼, 필요한 공유 헬퍼만 포함하고 임시 조사 파일이나 디버그 파일은 포함하지 않습니다.
+
+> [!NOTE]
+> 현재 Tailspin Toys에는 Node.js 22.13 이상, 프로젝트 의존성, E2E 검사용 Playwright Chromium이 필요합니다. 체크아웃의 README와 `package.json`에서 필수 조건을 확인합니다. 누락된 필수 조건이나 PowerShell 실행 정책에 의한 차단은 승인된 방법으로 해결해야 합니다. 자동 설치, 정책 우회, 알리지 않고 직접 npm으로 전환하는 방식으로 해결하지 않습니다.
+
+## 스킬 실행
+
+이전 레슨의 개발 서버가 중지되었는지 확인합니다. Playwright는 E2E를 위해 빌드하고 미리 보기를 제공하지만, 로컬 설정은 포트 `4321`의 서버를 재사용할 수 있습니다. 다른 체크아웃의 서버는 이 기능의 유효한 근거가 아닙니다.
+
+App에 `/quality-checks`가 표시되면 선택하여 발견된 스킬을 명시적으로 호출하고 아래 요청을 포함합니다. 발견되지 않았다면 이 세션에서 동일한 요청을 직접 보냅니다. 이 연습에서는 스킬을 읽는 방법을 대체 절차로 사용할 수 있습니다.
+
+```plaintext
+.github/skills/quality-checks/SKILL.md를 읽고 지침에 따라 이 체크아웃의 필터링 기능을 검증해 주십시오. 먼저 각 래퍼의 코드를 검토하여 npm의 상위 디렉터리 패키지 탐색에 의존하지 않고, 이 체크아웃에서 의도한 package.json을 포함하는 디렉터리를 찾으며, 잘못된 루트에서는 명시적으로 실패하도록 처리하는지 확인해 주십시오. 실패를 재현하기 위해 리포지토리 파일을 이동하거나 이름을 바꾸거나 삭제하거나 수정하지 마십시오. 함께 제공되는 lint, 단위 테스트, 엔드투엔드 테스트, 타입 검사 스크립트를 실제로 실행해 주십시오. 문서화된 단일 단위 테스트 파일 실행 예시도 실행하되, npm의 -- 구분자는 래퍼가 담당하므로 대상 도구의 인수를 직접 전달해 주십시오. 테스트 러너의 결과에서 지정한 파일만 실행되었는지 확인하고, 해당 파일명과 실행된 테스트 파일 수를 보고해 주십시오. 인수를 출력하거나 종료 코드 0을 반환하는 것만으로는 올바른 선택을 증명하지 못합니다.
+
+실패, 건너뛴 검사, 누락된 필수 조건을 포함하여 각 스크립트 호출과 결과를 보고해 주십시오. 사용할 수 없는 스킬 스크립트를 알리지 않고 직접 npm 명령으로 대체하지 마십시오. 테스트할 체크아웃과 서버를 식별하고 직접 시작한 서버만 중지하며, 설치하거나 다른 프로세스를 중지하기 전에 질문해 주십시오. 애플리케이션 코드나 브랜치를 변경하거나 커밋, 푸시, 끌어오기 요청 생성을 하지 마십시오.
+```
+
+도구 호출과 출력을 확인합니다. 네 스크립트가 모두 실제로 실행되어야 합니다. 검사 설명이나 건너뛴 검사는 통과가 아닙니다. 단일 파일 예시에서는 요청한 파일명을 러너의 실제 파일별 결과 및 보고한 수와 비교합니다. 해당 파일만 실행되어야 합니다. 다른 파일도 실행되었다면 인수 출력이나 종료 코드 0만으로는 충분하지 않습니다. 실패는 유용한 근거입니다. 스킬을 수정하거나 승인받아 설정 차단 요인을 해결한 다음 영향을 받는 검사를 다시 실행합니다. 관련 없는 프로세스를 중지하거나 포트 충돌을 강제로 없애지 않습니다.
+
+## 체크포인트 저장
+
+스킬과 결과를 검토한 후 로컬 체크포인트를 승인합니다.
+
+```plaintext
+현재 diff를 검토하고 quality-checks 스킬 파일만 포함한 체크포인트 커밋을 만들어 주십시오. 기존 필터링 브랜치를 유지해 주십시오. 푸시하거나 끌어오기 요청을 만들지 마십시오.
+```
+
+스킬 파일은 레슨 8의 기능 PR에 필터링, QA 프로필, 관련 테스트와 함께 포함됩니다. 동일한 세션에서 [레슨 6 - Playwright MCP로 기능 검증][next-lesson]을 계속합니다.
+
+## 더 많은 스킬 예제
+
+이 커뮤니티 예제는 참고 자료이며 추가 작업이 아닙니다. 채택하기 전에 필수 조건과 동작을 검토합니다.
+
+- [기여 워크플로: `make-repo-contribution`][contribution-example].
+- [요구 사항 문서: `prd`][prd-example].
+- [다이어그램과 함께 제공되는 내보내기 스크립트: `drawio`][drawio-example].
+- [브라우저 테스트: `webapp-testing`][browser-example].
+
+업스트림 기여 예제의 이름은 `make-repo-contribution`이며, 이전 Tailspin 템플릿은 `make-contribution`이라는 다른 이름을 사용했습니다. 이 워크숍은 두 기여 스킬 중 어느 것에도 의존하지 않습니다.
+
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/ko-kr/app/5-mcp-playwright.md b/docs/ko-kr/app/5-mcp-playwright.md
deleted file mode 100644
index 40a21566..00000000
--- a/docs/ko-kr/app/5-mcp-playwright.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: "Lesson 5 - Playwright MCP 서버로 테스트"
-description: "GitHub Copilot app에 Playwright MCP 서버를 추가하고 에이전트에게 실제 브라우저에서 필터링 기능을 수동으로 테스트하도록 요청합니다."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-이전 레슨에서는 프로젝트의 자동화된 테스트 도구 모음으로 필터링 기능을 만들고 검증했습니다. 테스트는 코드 검증을 자동화하지만 에이전트가 동작을 직접 확인하게 하는 것도 강력합니다. 에이전트는 자신이 만드는 실제 UI에서 발견한 문제에 대응할 수 있습니다. MCP가 AI 에이전트에 외부 기능을 제공하는 방식을 살펴보고, Copilot이 구축 중인 사이트와 직접 상호 작용할 수 있도록 Playwright MCP 서버를 추가합니다.
-
-이 레슨에서는 다음 작업을 수행합니다.
-
-- Model Context Protocol (MCP)의 개념과 GitHub Copilot app에서 사용하는 방식을 이해합니다.
-- 앱 설정에서 Playwright MCP 서버를 추가합니다.
-- 에이전트에게 브라우저를 조작하여 필터링 기능을 살펴보도록 요청합니다.
-
-## 시나리오
-
-단위 테스트와 엔드투엔드 테스트도 중요하지만 UI 업데이트를 검증하려면 실제로 UI와 상호 작용해야 합니다. Copilot이 사용자처럼 작업 중인 웹사이트를 사용하도록 하여 변경 작업을 더 자동화하고, 업데이트가 예상대로 작동한다는 확신을 높이려고 합니다.
-
-## Model Context Protocol (MCP)이란?
-
-[Model Context Protocol (MCP)][mcp-blog-post]은 AI 에이전트가 외부 도구 및 서비스와 통신하는 방법을 제공합니다. MCP를 사용하면 AI 에이전트가 외부 도구 및 서비스와 실시간으로 통신할 수 있습니다. 따라서 리소스를 사용하여 최신 정보에 접근하고 도구를 사용하여 사용자를 대신해 작업을 수행할 수 있습니다.
-
-이러한 도구와 리소스에는 AI 에이전트와 외부 도구 및 서비스를 연결하는 MCP 서버를 통해 접근합니다. MCP 서버는 AI 에이전트와 외부 도구(예: 기존 API 또는 NPM 패키지 같은 로컬 도구) 간의 통신을 관리합니다. 각 MCP 서버는 AI 에이전트가 접근할 수 있는 서로 다른 도구 및 리소스 집합을 나타냅니다.
-
-널리 사용되는 기존 MCP 서버의 예는 다음과 같습니다.
-
-- [**GitHub MCP Server**](https://github.com/github/github-mcp-server): GitHub 리포지토리 관리를 위한 API 집합에 접근할 수 있게 합니다. AI 에이전트가 새 리포지토리 만들기, 기존 리포지토리 업데이트, 이슈 및 끌어오기 요청 관리 같은 작업을 수행할 수 있습니다.
-- [**Playwright MCP Server**][playwright-mcp-server]: Playwright를 사용하는 브라우저 자동화 기능을 제공합니다. AI 에이전트가 웹페이지 이동, 양식 작성, 버튼 선택 같은 작업을 수행할 수 있습니다.
-
-다양한 도구와 리소스에 접근할 수 있는 다른 MCP 서버도 많습니다. GitHub는 MCP 서버를 쉽게 찾고 생태계에 기여할 수 있도록 [MCP registry](https://github.com/mcp)를 호스팅합니다.
-
-> [!CAUTION]
-> MCP 서버를 프로젝트의 다른 종속성과 동일하게 취급합니다. MCP 서버를 사용하기 전에 소스 코드를 주의 깊게 검토하고, 게시자를 확인하고, 보안 영향을 고려합니다. 신뢰하는 MCP 서버만 사용하고 중요한 리소스나 작업에 대한 접근 권한을 부여할 때 주의합니다.
-
-## Playwright MCP 서버 추가
-
-앱 설정에서 MCP 서버를 추가하고 관리합니다. 앱에는 인기 서버 카탈로그가 포함되어 있으므로 몇 번의 선택만으로 [Playwright MCP 서버][playwright-mcp-server]를 추가할 수 있습니다.
-
-1. Ctrl+,를 선택하여 Copilot app 설정 페이지를 엽니다.
-2. **MCP servers**를 선택합니다.
-3. 검색 대화 상자에 `Playwright`를 입력합니다.
-4. **Popular MCP servers** 목록에서 **Playwright**를 선택합니다.
-5. **Add server**를 선택하여 사용 가능한 MCP 서버 목록에 추가합니다.
-6. Esc를 선택하여 설정 대화 상자를 닫습니다.
-
-이제 Playwright MCP 서버를 추가했습니다.
-
-## Copilot에 Playwright로 기능 탐색 요청
-
-Copilot에 Playwright MCP 서버를 사용하여 기능을 수동으로 테스트하도록 요청합니다.
-
-1. 다음 프롬프트를 사용하여 새 기능을 검증하도록 Copilot에 요청합니다.
-
- ```plaintext
- Start the dev server then use the Playwright MCP server to validate the functionality you just added exists. Use the details in the issue to ensure the newly added behavior matches the specs.
- ```
-
-Copilot은 Playwright MCP 서버를 통해 브라우저를 시작하고 각 단계를 수행한 다음 발견한 내용을 보고합니다. 작업을 수행하기 위해 시스템에서 브라우저가 실제로 열리는 것을 볼 수 있습니다.
-
-2. 이슈의 승인 조건과 비교하여 요약을 읽습니다. 올바르지 않은 부분이 있으면 후속 질문을 하거나 끌어오기 요청을 열기 전에 코드를 수정하도록 요청합니다.
-3. 다음 레슨에서 이 세션을 마무리하므로 세션을 열어 둡니다.
-
-이제 Copilot은 사용자처럼 기능을 살펴보며 브라우저에서도 기능을 검증했습니다.
-
-## 요약 및 다음 단계
-
-GitHub Copilot app에서 Playwright MCP 서버를 사용하여 실제 브라우저로 기능을 살펴봤습니다. 요약하면 다음 작업을 수행했습니다.
-
-- Model Context Protocol (MCP)의 개념과 앱에서 MCP 도구를 제공하는 방식을 배웠습니다.
-- 앱 설정에서 Playwright MCP 서버를 추가했습니다.
-- 에이전트에게 브라우저를 조작하여 필터링 기능을 살펴보도록 요청했습니다.
-
-기능을 구축하고 검증하고 작동하는 모습까지 확인했습니다. 이제 **Agent Merge**를 사용하여 끌어오기 요청을 열고 병합하도록 합니다. [레슨 6 - Agent Merge로 병합][next-lesson]을 계속 진행합니다.
-
-## 리소스
-
-- [MCP란 무엇이며 왜 모두가 이야기할까요?][mcp-blog-post]
-- [Microsoft Playwright MCP Server][playwright-mcp-server]
-- [GitHub Copilot app에서 MCP 서버 구성][customize-app]
-
-[next-lesson]: ../6-agent-merge/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
\ No newline at end of file
diff --git a/docs/ko-kr/app/6-agent-merge.md b/docs/ko-kr/app/6-agent-merge.md
deleted file mode 100644
index f29b33ed..00000000
--- a/docs/ko-kr/app/6-agent-merge.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: "Lesson 6 - Agent Merge로 병합"
-description: "필터링 끌어오기 요청을 열고 My work에서 검토한 다음, Agent Merge가 차단 요소를 수정하고 병합하도록 하여 병합 자동화의 최상위 단계를 경험합니다."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-필터링 기능을 구축하고 검증하고 브라우저에서 작동하는 모습까지 확인했습니다. 마지막 단계는 병합입니다. 이 실습 과정에서 이미 두 번 병합했으며, 두 번 모두 끌어오기 요청을 열고 github.com에서 직접 병합했습니다. 이번에는 앱 안에서 끌어오기 요청의 전체 수명 주기를 관리하는 **Agent Merge**를 사용하여 앱이 번거로운 작업을 처리하게 합니다.
-
-이 레슨에서는 다음 작업을 수행합니다.
-
-- Agent Merge의 개념과 병합 수명 주기를 자동화하는 방식을 알아봅니다.
-- 필터링 세션에서 Agent Merge를 활성화합니다.
-- Agent Merge가 끌어오기 요청을 만들고 CI를 실행한 다음 모든 검사가 통과하면 병합하는 과정을 확인합니다.
-
-## 시나리오
-
-지난 몇 개 모듈에서 코드 생성부터 Copilot이 UI를 직접 검증하도록 하는 것까지 다양한 자동화 수준을 살펴봤습니다. Tailspin Toys는 개발 속도를 더욱 높이기 위해 검토와 검증을 마친 끌어오기 요청을 자동으로 병합할 방법이 있는지 알아보려고 합니다.
-
-## Agent Merge 소개
-
-**Agent Merge**는 Copilot app을 통해 끌어오기 요청을 병합하는 마지막 단계를 자동화합니다. 활성화하면 앱의 세션이 끌어오기 요청을 읽고, 실패한 CI 검사 수정, 검토 의견 대응, 필요할 때 리베이스 수행 등 병합을 차단하는 문제를 해결한 다음 GitHub에서 허용하는 즉시 병합합니다. 백그라운드에서 실행되고 앱을 다시 시작해도 계속 작동하며 끌어오기 요청이 병합되면 자동으로 꺼집니다.
-
-지금까지는 github.com에서 직접 **Merge pull request**를 선택했습니다. Agent Merge는 해당 책임을 에이전트로 옮기므로, 에이전트가 PR 완료 과정을 관리하는 동안 다음 작업으로 넘어갈 수 있습니다. 작업을 검토하고 승인하는 책임은 여전히 사용자에게 있으며, 에이전트는 기계적인 마무리 작업만 처리합니다.
-
-## Agent Merge로 PR 관리
-
-코드를 직접 검토하고 테스트를 실행했으며 Copilot이 UI를 검증하도록 했습니다. 이제 새 코드를 코드베이스에 병합합니다. Agent Merge가 지속적 통합(CI)과 병합 과정을 관리하게 합니다.
-
-1. 이전 모듈에서 필터링 기능을 추가하며 열어 둔 세션으로 돌아갑니다.
-2. 오른쪽 위에서 **Create PR** 옆의 드롭다운을 선택합니다.
-3. **Agent merge**를 선택하여 Agent Merge를 활성화합니다.
-
- 
-
-4. 이제 버튼 텍스트가 **Agent merge**로 바뀝니다.
-5. **Agent merge** 버튼을 선택하여 Agent Merge 프로세스를 시작합니다.
-
-Copilot app이 PR을 만들고 관리하는 프로세스를 시작합니다. 먼저 프로젝트를 탐색하여 PR을 만드는 최적의 방법을 결정한 다음 새 PR을 만듭니다.
-
-잠시 후 Copilot이 다시 작업을 시작하여 PR 조건, 즉 리포지토리의 모든 테스트를 실행하는 CI 프로세스를 확인합니다. 다른 팀 구성원이 남긴 검토, 실행해야 하는 검사(CI 프로세스), PR의 병합 가능 여부를 보고합니다.
-
-6. **Agent merge** 옆의 드롭다운을 선택한 다음 **Merge pull request**를 선택하여 Agent Merge가 끌어오기 요청을 병합하도록 허용합니다.
-
- 
-
-7. 모든 CI 프로세스가 통과하면, 즉 테스트가 성공하면 Copilot이 끌어오기 요청을 병합합니다.
-
-## 요약 및 다음 단계
-
-코드 생성, 코드 테스트와 검증, 끌어오기 요청 프로세스를 포함한 개발 프로세스의 여러 부분을 자동화했습니다. 다음 작업을 수행했습니다.
-
-- Agent Merge의 개념과 병합 수명 주기를 자동화하는 방식을 배웠습니다.
-- 필터링 세션에서 Agent Merge를 활성화했습니다.
-- Agent Merge가 끌어오기 요청을 만들고 CI를 실행한 다음 모든 검사가 통과했을 때 병합하는 과정을 확인했습니다.
-
-다음으로 에이전트와 함께 작업을 계획하고 시각화하는 더 풍부한 방법인 **캔버스**를 살펴봅니다. [레슨 7 - 캔버스로 계획 수립][next-lesson]을 계속 진행합니다.
-
-## 리소스
-
-- [GitHub Copilot app으로 이슈 및 끌어오기 요청 관리][managing-issues-prs]
-- [GitHub Copilot app 정보][about-copilot-app]
-
-[next-lesson]: ../7-canvases/
-[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/ko-kr/app/6-mcp-playwright.md b/docs/ko-kr/app/6-mcp-playwright.md
new file mode 100644
index 00000000..214b810b
--- /dev/null
+++ b/docs/ko-kr/app/6-mcp-playwright.md
@@ -0,0 +1,90 @@
+---
+title: "Lesson 6 - Playwright MCP로 기능 검증"
+description: "Customize에서 Playwright MCP를 구성하고 기존 기능 워크트리의 필터링을 브라우저에서 관찰합니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+이전 레슨에서는 프로젝트의 검사를 quality-checks 스킬로 묶어 실행했습니다. 이제 에이전트가 필터링 UI를 직접 관찰하도록 브라우저 접근 권한을 제공합니다. 동일한 필터링 세션, 워크트리, 브랜치를 유지합니다. 이 레슨은 브라우저 검증 근거를 추가하는 단계이며 다른 기능, 전체 테스트 스위트 실행, PR을 추가하지 않습니다.
+
+이 레슨에서는 다음 작업을 수행합니다.
+
+- Model Context Protocol (MCP)의 개념과 GitHub Copilot app에서 사용하는 방식을 이해합니다.
+- **Customize**에서 Playwright MCP 서버를 추가합니다.
+- 에이전트에게 브라우저를 조작하여 필터링 기능을 살펴보도록 요청합니다.
+
+## 시나리오
+
+단위 테스트와 엔드투엔드 테스트도 중요하지만 UI 업데이트를 검증하려면 실제로 UI와 상호 작용해야 합니다. Copilot이 사용자처럼 작업 중인 웹사이트를 사용하도록 하여 변경 작업을 더 자동화하고, 업데이트가 예상대로 작동한다는 확신을 높이려고 합니다.
+
+## Model Context Protocol (MCP)이란?
+
+[Model Context Protocol (MCP)][mcp-blog-post]은 AI 에이전트가 외부 도구 및 서비스와 통신하는 방법을 제공합니다. MCP를 사용하면 AI 에이전트가 외부 도구 및 서비스와 실시간으로 통신할 수 있습니다. 따라서 리소스를 사용하여 최신 정보에 접근하고 도구를 사용하여 사용자를 대신해 작업을 수행할 수 있습니다.
+
+이러한 도구와 리소스에는 AI 에이전트와 외부 도구 및 서비스를 연결하는 MCP 서버를 통해 접근합니다. MCP 서버는 AI 에이전트와 외부 도구(예: 기존 API 또는 NPM 패키지 같은 로컬 도구) 간의 통신을 관리합니다. 각 MCP 서버는 AI 에이전트가 접근할 수 있는 서로 다른 도구 및 리소스 집합을 나타냅니다.
+
+널리 사용되는 기존 MCP 서버의 예는 다음과 같습니다.
+
+- [**GitHub MCP Server**](https://github.com/github/github-mcp-server): GitHub 리포지토리 관리를 위한 API 집합에 접근할 수 있게 합니다. AI 에이전트가 새 리포지토리 만들기, 기존 리포지토리 업데이트, 이슈 및 끌어오기 요청 관리 같은 작업을 수행할 수 있습니다.
+- [**Playwright MCP Server**][playwright-mcp-server]: Playwright를 사용하는 브라우저 자동화 기능을 제공합니다. AI 에이전트가 웹페이지 이동, 양식 작성, 버튼 선택 같은 작업을 수행할 수 있습니다.
+
+다양한 도구와 리소스에 접근할 수 있는 다른 MCP 서버도 많습니다. GitHub는 MCP 서버를 쉽게 찾고 생태계에 기여할 수 있도록 [MCP registry](https://github.com/mcp)를 호스팅합니다.
+
+> [!CAUTION]
+> MCP 서버를 프로젝트의 다른 종속성과 동일하게 취급합니다. MCP 서버를 사용하기 전에 소스 코드를 주의 깊게 검토하고, 게시자를 확인하고, 보안 영향을 고려합니다. 신뢰하는 MCP 서버만 사용하고 중요한 리소스나 작업에 대한 접근 권한을 부여할 때 주의합니다.
+
+## Playwright MCP 서버 추가
+
+현재 [App 사용자 지정 문서][customize-app]는 MCP 검색 및 관리에 사이드바의 **Customize**를 사용합니다. 리포지토리나 Copilot CLI에 구성한 MCP 서버를 App에서 이미 사용할 수도 있으므로 중복 추가 전에 설치된 서버를 확인합니다.
+
+1. 사이드바에서 **Customize**를 선택합니다.
+2. **MCP**를 선택한 다음 **Installed**에서 기존 Playwright 서버를 확인합니다.
+3. 필요하면 사용 가능한 서버에서 **Playwright**를 찾거나 게시자가 문서화한 사용자 지정 서버 추가 절차를 사용합니다.
+4. 게시자, 구성, 설치 요청을 검토한 후 승인합니다. 안내에 따라 서버를 추가합니다. 조직 정책이나 누락된 필수 조건으로 설정이 차단될 수 있습니다.
+5. **Interactive** 모드를 유지한 채 기존 필터링 세션으로 돌아갑니다. 검증 요청 전에 Playwright MCP 브라우저 도구를 사용할 수 있는지 확인합니다. 설정 문제를 우회하려고 새 기능 워크트리를 만들지 않습니다.
+
+설정이 실패하면 도구 없이 브라우저를 사용했다는 주장을 수락하지 말고 구성이나 권한 문제를 해결합니다. 브라우저 창의 표시 여부는 서버 구성에 따라 달라집니다. 실제 도구 활동과 관찰 결과가 검증 근거입니다.
+
+## Copilot에 Playwright로 기능 탐색 요청
+
+레슨 4에서 저장한 실제 이슈 URL과 승인한 추가 합의 사항을 사용합니다. 에이전트가 자체 서버를 시작하기 전에 이전 레슨에서 수동으로 시작한 개발 서버를 중지합니다. 에이전트는 테스트할 체크아웃과 서버를 식별해야 합니다.
+
+1. 다음 프롬프트를 사용하여 새 기능을 검증하도록 Copilot에 요청합니다.
+
+ ```plaintext
+ 구성된 Playwright MCP 서버를 사용하여 이 이슈를 기준으로 필터링 기능을 관찰해 주십시오: . 계획에서 승인한 추가 합의 사항은 다음과 같습니다: <합의한 추가 사항을 붙여 넣거나 none 작성>. 이 필터링 워크트리와 브랜치를 유지해 주십시오.
+
+ 체크아웃을 식별하고 해당 개발 서버를 시작한 다음 실제 브라우저 도구로 필수 여러 카테고리 선택, 퍼블리셔 필터링, 조합 필터링, 접근성 있는 컨트롤, 합의한 초기화나 빈 결과 동작을 확인해 주십시오. 실패하거나 차단된 검사를 포함하여 기준에 따른 관찰 결과를 보고해 주십시오. 관찰하지 않은 동작을 확인했다고 주장하지 마십시오.
+
+ 이 단계는 브라우저 관찰이며 전체 자동 테스트를 다시 실행하는 단계가 아닙니다. 애플리케이션 코드, 테스트, 스킬, 에이전트 프로필을 변경하거나 커밋, 푸시, PR 생성을 하지 마십시오. 누락된 MCP 도구나 필수 조건은 차단으로 보고하고 설치 전에 질문해 주십시오. 다른 체크아웃의 서버를 재사용하거나 관련 없는 프로세스를 중지하지 마십시오. 완료하면 직접 시작한 서버만 중지해 주십시오.
+ ```
+
+Playwright MCP 도구 호출, 테스트한 URL, 보고한 브라우저 관찰 결과를 살펴봅니다. 소스 코드나 이전 E2E 결과만으로 작성한 설명은 MCP 사용을 입증하지 못합니다.
+
+2. 이슈와 승인한 추가 합의 사항을 기준으로 요약을 읽습니다. 결함이 있으면 범위를 좁힌 수정을 별도로 승인하고 변경된 diff를 검토한 다음 관련 자동 검사와 브라우저 관찰을 반복합니다. 수정 전 근거는 수정된 리비전을 입증하지 못합니다.
+3. 에이전트가 직접 시작한 서버를 중지했는지 확인합니다. 레슨 7에서 QA 프로필을 만들기 전까지 이 필터링 세션을 열어 두고 **Interactive** 모드를 유지합니다.
+
+이 단계는 직접 관찰을 확보하며 자동 테스트 커버리지를 대체하지 않습니다. 실패하거나 차단된 관찰 결과를 QA에서 확인할 수 있도록 남겨 둡니다.
+
+## 요약 및 다음 단계
+
+GitHub Copilot app에서 Playwright MCP 서버를 사용하여 실제 브라우저로 기능을 살펴봤습니다. 요약하면 다음 작업을 수행했습니다.
+
+- Model Context Protocol (MCP)의 개념과 앱에서 MCP 도구를 제공하는 방식을 배웠습니다.
+- **Customize**에서 Playwright MCP 서버를 구성했습니다.
+- 에이전트에게 브라우저를 조작하여 필터링 기능을 살펴보도록 요청했습니다.
+
+다음으로 전문가 프로필을 통해 요구 사항, 브라우저 관찰, 커버리지, 스킬을 결합합니다. 동일한 세션에서 [레슨 7 - QA 에이전트 만들기 및 사용][next-lesson]을 계속 진행합니다. 아직 기능 PR을 만들지 않습니다.
+
+## 리소스
+
+- [MCP란 무엇이며 왜 모두가 이야기할까요?][mcp-blog-post]
+- [Microsoft Playwright MCP Server][playwright-mcp-server]
+- [GitHub Copilot app에서 MCP 서버 구성][customize-app]
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
+[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
\ No newline at end of file
diff --git a/docs/ko-kr/app/7-canvases.md b/docs/ko-kr/app/7-canvases.md
deleted file mode 100644
index dca280c8..00000000
--- a/docs/ko-kr/app/7-canvases.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: "Lesson 7 - 캔버스로 계획 수립"
-description: "GitHub Copilot app에서 공유 에이전트 기반 캔버스를 만들어 에이전트와 함께 작업을 계획하고 추적합니다."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-지금까지 채팅을 통해 에이전트를 지시했습니다. 하지만 많은 작업은 대화가 아니라 보드, 문서, 검사 목록에서 이루어집니다. **캔버스**는 바로 이러한 작업을 위해 앱 안에서 사용자와 에이전트가 함께 사용하는 화면을 제공합니다. 이 레슨에서는 지금까지 처리한 백로그를 계획하고 추적하는 간단한 캔버스를 만듭니다.
-
-이 레슨에서는 다음 작업을 수행합니다.
-
-- 캔버스의 개념과 사용 시점을 이해합니다.
-- 백로그를 분류하는 공유 Kanban 보드 캔버스를 만듭니다.
-- 캔버스를 리포지토리에 저장하고 팀에서 사용할 수 있도록 병합합니다.
-- 새 세션에서 캔버스를 열고 캔버스에서 작업을 시작합니다.
-
-## 시나리오
-
-이슈 목록은 아무리 좋은 상황에서도 부담스러울 수 있습니다. Tailspin Toys 개발자는 이슈를 빠르게 분류하고 Copilot app에서 작업을 시작할 수 있는 도구를 찾고 있습니다.
-
-## 캔버스란?
-
-[캔버스][canvas-docs]는 계획, 분류 보드, 릴리스 검사 목록, 대시보드, 문서 같은 작업 산출물을 위한 공유 대화형 화면입니다. 채팅은 의도를 설명하고 모호한 부분을 함께 추론하는 데 유용하지만 대부분의 작업은 *화면*에서 이루어집니다. 캔버스를 사용하면 해당 화면에서 에이전트와 직접 협업할 수 있습니다.
-
-캔버스는 **양방향**입니다. 에이전트가 작업하면서 캔버스를 업데이트할 수 있고 사용자도 동일한 화면을 편집할 수 있습니다. 캔버스를 만들면 에이전트가 프롬프트와 워크플로를 바탕으로 구축하며, 진행하면서 기능을 추가하거나 제거하거나 수정하도록 요청할 수 있습니다. 캔버스를 만들면 앱의 오른쪽 패널에서 열립니다.
-
-일반적인 예는 다음과 같습니다.
-
-- 하루를 계획하고 이슈와 끌어오기 요청의 우선순위를 정하는 **Markdown 캔버스**
-- 사용자와 에이전트가 카드를 추가하고 열 사이에서 작업을 이동하는 **에이전트 Kanban 보드**
-- 리포지토리의 주요 이슈와 반복되는 주제를 요약하는 **이슈 분류 보드**
-
-## 캔버스를 사용하는 이유
-
-작업에 구조화, 반복, 검증이 필요하고 채팅만으로 충분하지 않다면 캔버스를 사용합니다. 캔버스로 다음 작업을 수행할 수 있습니다.
-
-- 워크플로에 맞는 실제 산출물을 기반으로 에이전트가 작업하게 합니다.
-- 공유 화면에서 작업을 직접 안내하거나 수정한 다음 에이전트가 변경 내용에서 계속 작업하게 합니다.
-- 채팅 응답만 보는 대신 산출물의 눈에 보이는 변경으로 진행 상황을 확인합니다.
-
-## 작업 추적 캔버스 만들기
-
-별점, 문서화 표준, 필터링 기능을 모두 병합하여 많은 작업을 제공했습니다. 하지만 백로그에는 아직 항목이 남아 있습니다. 작업을 빠르게 분류하는 데 도움이 되는 캔버스를 만듭니다.
-
-1. GitHub Copilot app으로 돌아가거나 앱을 엽니다.
-2. **Home screen**을 선택합니다.
-3. 리포지토리로 `tailspin-toys`가 선택되어 있는지 확인합니다.
-4. 프롬프트 상자에서 다음 프롬프트를 사용하여 요구 사항을 충족하는 캔버스를 만듭니다.
-
- ```plaintext
- Create a basic Kanban board canvas that allows me to quickly triage work. Highlight the three issues which are most likely to need attention right now, with the remainder in a second section down below. The top three cards should include a description of the issue's content and a justification of why they're at the top of the list. Each issue should have a button that allows me to add it to the current context for the current session so I can get to work on it straightaway.
- ```
-
-Copilot이 캔버스를 만들기 시작합니다.
-
-> [!NOTE]
-> 이 작업에는 몇 분 정도 걸립니다. 복잡한 작업이므로 첫 번째 버전이 만족스럽지 않을 수 있습니다. 원하는 도구가 완성될 때까지 프롬프트로 계속 개선할 수 있습니다.
-
-## 캔버스를 저장하고 리포지토리에 병합
-
-캔버스는 지침 파일 및 스킬과 마찬가지로 리포지토리의 자산이 될 수 있습니다. Copilot에 캔버스를 리포지토리에 추가하고 병합하도록 요청하여 팀 전체에서 사용하게 합니다.
-
-1. 같은 세션에서 다음 프롬프트를 사용하여 캔버스를 리포지토리에 저장하도록 Copilot에 요청합니다.
-
- ```plaintext
- Let's save this canvas definition to the repository so I can share it with my development team
- ```
-
-2. Copilot이 캔버스 파일을 저장하면 오른쪽 위에서 **Create PR** 옆의 드롭다운을 선택합니다.
-3. **Agent merge**를 선택하여 Agent Merge를 활성화합니다.
-
- 
-
-4. 이제 버튼 텍스트가 **Agent merge**로 바뀝니다.
-5. **Agent merge** 버튼을 선택하여 Agent Merge 프로세스를 시작합니다.
-
-Copilot app이 PR을 만들고 관리하는 프로세스를 시작합니다. 먼저 프로젝트를 탐색하여 PR을 만드는 최적의 방법을 결정한 다음 PR을 만듭니다.
-
-잠시 후 Copilot이 다시 작업을 시작하여 PR 조건, 즉 리포지토리의 모든 테스트를 실행하는 CI 프로세스를 확인합니다. 다른 팀 구성원이 남긴 검토, 실행해야 하는 검사(CI 프로세스), PR의 병합 가능 여부를 보고합니다.
-
-6. **Agent merge** 옆의 드롭다운을 선택한 다음 **Merge pull request**를 선택하여 Agent Merge가 끌어오기 요청을 병합하도록 허용합니다.
-
- 
-
-7. 모든 CI 프로세스가 통과할 때까지 기다립니다. 모두 통과하면 Copilot이 끌어오기 요청을 자동으로 병합합니다.
-
-이제 팀을 위한 새 공유 캔버스를 만들었습니다.
-
-## 캔버스에서 작업
-
-캔버스를 만들었으므로 새 세션을 시작하고 사용해 봅니다.
-
-1. Copilot app에서 **tailspin-toys** 옆의 **New session**을 선택하여 새 세션을 시작합니다.
-2. 다음 프롬프트를 사용하여 분류 캔버스를 열도록 Copilot에 요청합니다.
-
- ```plaintext
- Open the triage issues canvas
- ```
-
-3. 이제 새 세션에서 만든 캔버스가 열리는 것을 확인합니다.
-4. 가장 관심 있는 이슈 중 하나에서 **Add to current context**를 선택합니다.
-5. Copilot이 이슈 작업을 시작합니다.
-
-이제 직접 만든 캔버스를 사용하여 개발 프로세스를 간소화했습니다.
-
-## 요약 및 다음 단계
-
-사용자와 에이전트가 협업하는 공유 화면을 만들었습니다. 다음 작업을 수행했습니다.
-
-- 캔버스의 개념과 사용 시점을 배웠습니다.
-- 에이전트와 공유 Kanban 분류 보드 캔버스를 만들었습니다.
-- Agent Merge를 사용하여 캔버스를 리포지토리에 저장하고 병합했습니다.
-- 새 세션에서 캔버스를 열고 캔버스를 사용하여 작업을 시작했습니다.
-
-백로그를 추적하도록 설정했으므로 지금까지 구축한 항목과 다음 단계를 돌아봅니다. [레슨 8 - 검토 및 다음 단계][next-lesson]를 계속 진행합니다.
-
-## 리소스
-
-- [GitHub Copilot app에서 캔버스 확장 사용][canvas-docs]
-- [Awesome Copilot의 캔버스][awesome-copilot-canvases]
-- [GitHub Copilot app 정보][about-copilot-app]
-
-[next-lesson]: ../8-review/
-[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
-[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/ko-kr/app/7-qa-agent.md b/docs/ko-kr/app/7-qa-agent.md
new file mode 100644
index 00000000..832a64c5
--- /dev/null
+++ b/docs/ko-kr/app/7-qa-agent.md
@@ -0,0 +1,73 @@
+---
+title: "레슨 7 - QA 에이전트 만들기 및 사용"
+description: "테스트 커버리지, quality-checks 스킬, 직접 관찰한 브라우저 근거를 통합하는 요구 사항 우선 QA 프로필을 만듭니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+반복 가능한 검사를 실행하고 Playwright MCP로 필터링을 살펴봤습니다. 이제 **QA 사용자 지정 에이전트**를 만들어 요구 사항, 커버리지, 브라우저 근거를 통합합니다. 필터링 세션, 체크아웃, 브랜치를 유지합니다. 기능 PR은 레슨 8에서 만듭니다.
+
+## QA 프로필 만들기
+
+**Interactive** 모드를 유지합니다. 프로필은 전문가의 역할과 지침을 정의하며, 스킬은 재사용 가능한 작업 지침, 스크립트, 리소스를 묶습니다. QA 에이전트는 스킬과 설정된 MCP 도구를 대체하지 않고 사용합니다.
+
+다음 프롬프트를 보낸 후 실행 전에 정의를 확인합니다.
+
+```plaintext
+.github/agents/qa.agent.md에 재사용 가능한 QA 사용자 지정 에이전트를 만들어 주십시오. 먼저 리포지토리 지침, package.json, 테스트 설정, .github/skills/quality-checks/SKILL.md를 확인해 주십시오. 프로필에 유효한 YAML 프런트매터를 제공하고 name은 QA로, description은 사용할 시점을 설명하도록 설정해 주십시오. 모델을 고정하거나 tools 목록을 추가하지 말고 해당 환경에서 사용할 수 있는 도구와 권한을 상속해 주십시오. 에이전트 정의만 만든 다음 실행 전에 검토할 수 있도록 중단해 주십시오.
+
+에이전트 지침에서 모든 QA 작업을 이슈와 사용자가 제공한 승인된 수락 기준으로 시작하도록 요구해 주십시오. 구현이 아니라 이러한 요구 사항을 기준으로 삼아 주십시오. 요구 사항이 누락되거나 모호하면 질문해 주십시오. 기능과 기존 테스트를 확인하고 각 기준을 적절한 자동 테스트 커버리지 및 관찰 가능한 동작과 연결해 주십시오.
+
+설정된 Playwright MCP 서버를 통한 직접 브라우저 검증과 기존 quality-checks 스킬 및 함께 제공되는 스크립트를 통한 lint, 단위 테스트, 엔드투엔드 테스트, 타입 검사 실행을 요구해 주십시오. 스킬이 자동으로 발견되지 않았다면 명시적으로 읽어 주십시오. 스킬, MCP 도구, 필수 조건, 액세스가 없으면 차단된 상태로 보고해 주십시오. 알리지 않고 다른 워크플로로 대체하거나 건너뛴 검사를 통과로 표시하지 마십시오. 테스트할 체크아웃과 서버를 식별하고, 다른 워크트리의 서버를 재사용하지 않으며, 에이전트가 시작한 서버만 중지하고, 설치하거나 다른 프로세스를 중지하기 전에 질문해 주십시오.
+
+리포지토리 지침에 따라 실제 커버리지 공백에 필요한 최소 테스트를 QA 에이전트가 추가할 수 있도록 해 주십시오. 커버리지가 이미 충분하다면 추가 테스트가 없어도 타당합니다. 검증을 약화하거나 실패하는 테스트를 비활성화하거나 코드에 맞춰 수락 기준을 바꾸거나 제 승인 없이 애플리케이션 코드를 수정하지 마십시오. 변경 후 영향을 받는 검사를 다시 실행하고 변경된 리비전의 최종 검증을 완료해 주십시오. 각 기준을 근거와 통과/실패/차단 상태에 연결하고, 추가한 테스트 또는 추가할 필요가 없었던 이유, 네 가지 검사 결과, 해결되지 않은 결함을 포함하는 간결한 보고서를 요구해 주십시오. GO에는 모든 필수 검사와 근거가 필요하며, 그렇지 않으면 이유와 함께 NO-GO를 보고해야 합니다. QA 중에는 브랜치를 변경하거나 커밋, 푸시, PR 생성 또는 병합을 하거나 추가 에이전트나 스킬을 만들지 마십시오.
+```
+
+## 프로필 검토
+
+**Changes** 또는 파일 검토 패널에서 `.github/agents/qa.agent.md`를 엽니다. `description`은 필수이며, 이 레슨에서는 읽기 쉬운 `name`으로 `QA`도 제공합니다. 고정된 `model`이나 임의로 만든 도구 목록이 없는지 확인합니다. `tools`를 생략하면 사용 가능한 도구를 상속하지만 해당 환경의 권한을 우회하지는 않습니다. 프로덕션 프로필에서는 의도적으로 도구를 제한할 수 있습니다.
+
+지침이 요구 사항에서 시작하고, 실제 MCP 브라우저 작업과 스킬 스크립트를 요구하며, 정당한 테스트 추가만 허용하고, 차단 요인을 사실대로 보고하는지 확인합니다. 전문가 프로필이나 스킬에 별도 컨텍스트 윈도 또는 다른 에이전트의 오케스트레이션이 필수인 것은 아닙니다.
+
+## 이슈에 대한 QA 실행
+
+실행 프롬프트는 프로필을 읽는 기본 에이전트가 아니라 선택된 **QA** 사용자 지정 에이전트를 위한 것입니다. 동일한 필터링 체크아웃과 브랜치를 유지합니다.
+
+1. 현재 세션에서 [App 사용자 지정 문서][customize-app]에 따라 프롬프트 상자의 에이전트 선택기를 열거나 `/agent`를 입력합니다.
+2. **QA**를 선택하고, 실행 프롬프트를 보내기 전에 App이 **QA**를 활성 에이전트로 명확히 표시하는지 확인합니다.
+3. **QA**가 목록에 없거나 활성 상태를 확인할 수 없다면 이 워크트리와 브랜치를 유지한 채 일시 중지하고 진행자에게 질문합니다. 새 기능 세션을 만들거나 근거 없는 다시 불러오기 절차를 만들거나 기본 에이전트에 `qa.agent.md`를 읽으라고 요청하는 방식으로 대체하지 않습니다.
+
+문서에 설명된 선택기는 세션 중 사용할 수 있지만, 새로 만든 리포지토리 프로필의 발견 여부는 App 버전에 따라 달라질 수 있습니다. 파일을 작성한 사실을 활성화의 증거로 취급하지 않습니다.
+
+두 플레이스홀더를 실제 필터링 이슈 URL과 레슨 4에서 승인한 추가 합의 사항으로 바꿉니다. 이슈만으로 요구 사항이 충분하다면 `none`을 사용합니다. 이전 에이전트의 기억에 의존하지 않습니다.
+
+```plaintext
+다음 이슈에 맞게 필터링 기능을 검증해 주십시오: . 계획 중 승인한 추가 수락 기준은 다음과 같습니다: <합의한 추가 내용을 붙여 넣거나 없으면 none 입력>.
+
+Playwright MCP 서버로 동작을 검증하고, 테스트 커버리지를 확인하며, 누락된 커버리지에 대해서만 테스트를 추가하고, quality-checks 스킬을 통해 검증을 실행해 주십시오. 근거, 검사 결과, 차단 요인을 보고해 주십시오. 제 승인 없이 애플리케이션 코드를 변경하지 마십시오. 커밋하거나 끌어오기 요청을 만들지 마십시오.
+```
+
+## 근거 검토
+
+보고서를 이슈와 비교합니다. 각 기준에는 적절한 자동 테스트 커버리지와 관찰 가능한 동작이 필요합니다. 실제 Playwright MCP 도구 작업, 체크아웃과 서버 식별 정보, 네 가지 스킬 스크립트 결과를 모두 확인합니다. 브라우저 검사와 자동 E2E가 오래된 서버나 다른 체크아웃을 재사용해서는 안 됩니다.
+
+추가한 테스트를 검토합니다. 검증을 약화하지 않고 실제 공백을 메워야 합니다. 커버리지가 충분하다면 새 테스트가 없는 것이 올바릅니다. 차단이나 실패에 따른 **NO-GO** 판정은 유효한 결과이며, 근거를 생략해도 된다는 허가가 아닙니다.
+
+QA에서 애플리케이션 결함을 발견하면 범위를 좁힌 수정을 별도로 승인하고, 변경된 리비전에서 영향을 받는 검사와 브라우저 관찰을 다시 실행합니다. 누락된 필수 조건이나 도구에는 명시적인 해결이 필요합니다. 오래된 근거를 변경된 코드의 증거로 취급하지 않습니다.
+
+## 체크포인트 저장
+
+QA가 끝나면 보고서, 이슈 URL, 승인한 추가 합의 사항, 테스트한 리비전을 사용할 수 있도록 보관합니다. 동일한 세션에서 문서에 설명된 에이전트 선택기를 사용해 일반 Copilot 에이전트로 돌아가고 **QA**가 더 이상 선택되어 있지 않은지 확인합니다. 동일한 체크아웃과 브랜치를 유지하며, 다른 기능 세션을 시작하거나 워크트리를 다시 불러오지 않습니다. 일반 에이전트 선택 항목을 찾을 수 없다면 QA에 커밋을 지시하지 말고 일시 중지한 후 진행자에게 질문합니다.
+
+프로필, 테스트 변경, 그 결과로 얻은 근거를 검토한 후 해당 QA 컨텍스트와 함께 일반 에이전트에 체크포인트 요청을 보냅니다.
+
+```plaintext
+현재 diff를 검토하고 QA 에이전트 정의와 승인된 테스트 변경의 체크포인트 커밋을 만들어 주십시오. 기존 필터링 브랜치를 유지해 주십시오. 푸시하거나 끌어오기 요청을 만들지 마십시오.
+```
+
+필터링 기능, 스킬, QA 프로필, 테스트, 현재 검증 근거를 갖추고 [레슨 8 - 기능 PR 생성 및 병합][next-lesson]을 계속합니다.
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/ko-kr/app/8-create-pull-request.md b/docs/ko-kr/app/8-create-pull-request.md
new file mode 100644
index 00000000..865b0575
--- /dev/null
+++ b/docs/ko-kr/app/8-create-pull-request.md
@@ -0,0 +1,90 @@
+---
+title: "Lesson 8 - 기능 PR 만들기 및 병합"
+description: "필터링, 스킬, QA 프로필, 테스트를 함께 검토하고 PR 3을 만든 다음 Agent Merge를 명시적으로 승인합니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+필터링 구현, quality-checks 스킬, QA 프로필, 관련 테스트를 하나의 브랜치에 체크포인트로 저장했습니다. 함께 검토하고 현재 QA 근거를 사용하여 PR 3을 준비합니다. 별점과 지침 PR은 이미 명시적으로 병합했습니다. 이번에는 별도 기능이나 브랜치가 아니라 PR 워크플로 안에서 **Agent Merge**를 사용합니다.
+
+이 레슨에서는 다음 작업을 수행합니다.
+
+- Agent Merge의 개념과 병합 수명 주기를 자동화하는 방식을 알아봅니다.
+- 전체 기능 PR과 검증 근거를 살펴봅니다.
+- 검토한 후에만 Agent Merge를 승인하고 PR 병합을 확인합니다.
+
+## 시나리오
+
+지난 몇 개 모듈에서 코드 생성부터 Copilot이 UI를 직접 검증하도록 하는 것까지 다양한 자동화 수준을 살펴봤습니다. Tailspin Toys는 개발 속도를 더욱 높이기 위해 검토와 검증을 마친 끌어오기 요청을 자동으로 병합할 방법이 있는지 알아보려고 합니다.
+
+## Agent Merge 소개
+
+**Agent Merge**는 Copilot app을 통해 끌어오기 요청을 병합하는 마지막 단계를 자동화합니다. 활성화하면 앱의 세션이 끌어오기 요청을 읽고, 실패한 CI 검사 수정, 검토 의견 대응, 필요할 때 리베이스 수행 등 병합을 차단하는 문제를 해결한 다음 GitHub에서 허용하는 즉시 병합합니다. 백그라운드에서 실행되고 앱을 다시 시작해도 계속 작동하며 끌어오기 요청이 병합되면 자동으로 꺼집니다.
+
+지금까지는 직접 **Merge pull request**를 선택했습니다. Agent Merge가 이 책임을 맡을 수 있지만 코드 편집과 병합에는 명시적 승인이 필요합니다. 병합 권한을 부여하기 전에 허용된 작업과 변경 내용을 검토합니다.
+
+## 전체 마일스톤 검토
+
+레슨 4~7의 필터링 세션을 유지합니다. 마지막 체크포인트뿐 아니라 `main`에 대한 전체 브랜치 diff를 확인합니다. 필터링, `.github/skills/quality-checks/SKILL.md`, 함께 제공되는 스크립트, `.github/agents/qa.agent.md`, 관련 테스트가 포함되어야 합니다.
+
+커밋이나 PR 작업을 요청하기 전에 에이전트 선택기로 **QA**에서 일반 Copilot 에이전트로 돌아가고 **Interactive** 모드를 유지합니다. QA 프로필의 역할은 검증이지 배포가 아닙니다. 선택한 에이전트를 변경해도 필터링 세션, 체크아웃, 브랜치는 변경하지 않습니다.
+
+이 워크숍은 기능 작업과 재사용 가능한 품질 관리 기반을 의도적으로 하나의 PR에 결합합니다. 실제 팀에서는 나눌 수 있지만, 여기서는 브랜치를 쌓거나 PR을 추가하지 않고 체크포인트 커밋으로 검토 가능한 단계를 보존합니다.
+
+레슨 7의 QA 보고서를 검토합니다. 제출할 최종 리비전을 대상으로 네 가지 검사와 관련 브라우저 관찰을 모두 완료했을 때만 근거를 재사용합니다. 코드 변경, 충돌 해결, CI 수정으로 테스트 대상이 바뀌면 관련 검사와 브라우저 관찰을 다시 수행하고 근거를 업데이트합니다. 실패하거나 차단된 **NO-GO** 보고서는 병합 승인이 아닙니다.
+
+diff와 근거가 준비되면 다음을 보냅니다.
+
+```plaintext
+필터링 기능, quality-checks 스킬과 스크립트, QA 에이전트 정의, 관련 테스트를 포함하여 main에 대한 전체 필터링 브랜치 diff를 검토해 주십시오. 이슈 기준, 승인한 추가 합의 사항, 현재 QA 근거를 요약해 주십시오. 최종 리비전에도 적용될 때만 검증을 재사용하고, 오래되거나 누락되거나 실패한 근거가 있으면 진행 전에 보고해 주십시오.
+
+검토한 변경과 검증이 준비되었다면 남아 있는 승인된 마일스톤 변경을 커밋하고 이 브랜치를 푸시한 다음 리포지토리의 PR 템플릿과 실제 필터링 이슈 URL을 사용하여 main을 대상으로 기능 PR 하나를 만들어 주십시오. 이 브랜치의 체크포인트 기록을 유지해 주십시오. 기여 스킬을 사용하거나 다른 브랜치나 PR을 만들거나 아직 병합하지 마십시오.
+```
+
+**My work**에서 PR을 열고 **Files changed**, 설명, 검토, 검사 결과를 살펴봅니다. Tailspin Toys 자체 워크플로 파일과 필수 검사를 확인합니다. 모든 로컬 검사나 브라우저 관찰이 CI에서 실행된다고 가정하지 않습니다. 워크숍 게시용 Astro 빌드와 링크 검사기는 다른 리포지토리의 도구이며 이 기능을 검증하지 않습니다.
+
+## Agent Merge로 PR 관리
+
+기존 PR을 검토한 후 동일한 세션에서 Agent Merge를 구성합니다. 두 번째 PR을 만들지 않습니다.
+
+1. 필터링 세션으로 돌아가 PR 3에 연결되었는지 확인합니다.
+2. 오른쪽 위의 PR 작업 드롭다운을 엽니다. PR이 없을 때는 **Create PR** 옆에 있으며 PR이 연결되면 레이블이 바뀔 수 있습니다.
+3. **Agent merge**를 선택하여 Agent Merge를 활성화합니다.
+
+4. **Address reviews**, **Fix CI failures**, **Resolve conflicts**, **Merge pull request**를 포함한 권한을 검토합니다. 지적 사항이나 검증이 해결되지 않았을 때는 병합 권한을 꺼 둡니다.
+5. 시작 전에 다음 범위와 승인을 보낸 다음 **Agent merge**를 선택합니다.
+
+ ```plaintext
+ Agent Merge로 이 기존 필터링 PR을 관리해 주십시오. 검토나 CI 차단 요인은 이 PR의 범위 안에서만 해결해 주십시오. 테스트나 요구 사항을 약화하지 말고 관련 없는 변경이나 설치 전에 질문해 주십시오. 테스트한 리비전이 변경되면 관련 검사와 브라우저 근거를 업데이트해야 합니다. 이전 QA 결과를 변경된 코드의 증거로 취급하지 마십시오.
+
+ 최종 diff와 근거를 검토한 후 제가 Merge pull request를 명시적으로 활성화할 때까지 병합하지 마십시오. 다른 PR을 만들거나 캔버스 작업을 시작하지 마십시오.
+ ```
+
+6. 후속 변경과 업데이트된 결과를 검토합니다. 최종 diff가 승인되고 필수 CI와 검토를 통과하며 QA 근거가 해당 리비전에 적용되면 **Agent merge** 옆의 드롭다운에서 **Merge pull request**를 선택하여 병합을 명시적으로 승인합니다.
+
+ 
+
+7. GitHub에서 PR 3이 단순히 병합 가능하거나 대기 중이 아니라 **Merged**로 표시되는지 확인합니다. Agent Merge는 리포지토리 보호나 권한 부족을 우회하지 않습니다. 계속하기 전에 차단 요인을 해결합니다.
+
+병합 후에만 캔버스 마일스톤을 시작합니다. 레슨 9는 새 워크트리를 만들고 세션 브랜치를 최신 `origin/main`으로 fast-forward하여 병합된 전체 기능을 포함한 상태에서 캔버스를 시작합니다.
+
+## 요약 및 다음 단계
+
+코드 생성, 코드 테스트와 검증, 끌어오기 요청 프로세스를 포함한 개발 프로세스의 여러 부분을 자동화했습니다. 다음 작업을 수행했습니다.
+
+- Agent Merge의 개념과 병합 수명 주기를 자동화하는 방식을 배웠습니다.
+- 전체 필터링, 스킬, QA 프로필, 테스트 diff를 PR 3으로 검토했습니다.
+- 현재 QA 근거를 재사용하고 CI를 확인한 다음 Agent Merge를 명시적으로 승인했습니다.
+
+다음으로 에이전트와 함께 작업을 계획하고 시각화하는 더 풍부한 방법인 **캔버스**를 살펴봅니다. [레슨 9 - 이슈 분류 캔버스 만들기][next-lesson]를 계속 진행합니다.
+
+## 리소스
+
+- [GitHub Copilot app으로 이슈 및 끌어오기 요청 관리][managing-issues-prs]
+- [GitHub Copilot app 정보][about-copilot-app]
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-canvases/
+[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/ko-kr/app/8-review.md b/docs/ko-kr/app/8-review.md
deleted file mode 100644
index 1b23b940..00000000
--- a/docs/ko-kr/app/8-review.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: "Lesson 8 - 검토 및 다음 단계"
-description: "GitHub Copilot app 실습 과정을 되짚어 보고, 반복 작업을 자동화하고, 다음에 살펴볼 내용을 알아봅니다."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-지난 여러 레슨에서 GitHub Copilot app으로 아이디어를 기능으로 만들고 병합하기까지 다음 작업을 수행했습니다.
-
-- 리포지토리를 연결하고 앱의 워크스페이스와 미리 생성된 백로그를 살펴봤습니다.
-- 직접 작업과 이슈에서 세션을 시작하고 Plan 및 Autopilot 모드로 에이전트의 작업 방식을 제어했습니다.
-- 사용자 지정 지침과 재사용 가능한 스킬로 에이전트를 안내했습니다.
-- Playwright MCP 서버를 사용하여 실제 브라우저에서 작업을 테스트했습니다.
-- 공유 캔버스에서 에이전트와 협업했습니다.
-- GitHub.com에서 직접 병합하는 단계부터 **Agent Merge**가 끌어오기 요청을 병합하는 단계까지 병합 자동화 수준을 높여 변경 내용을 제공했습니다.
-
-이제 반복 작업을 자동화하고 모범 사례를 살펴본 다음 앞으로 진행할 방향을 알아봅니다.
-
-## 반복 작업 자동화
-
-앱은 **자동화**를 통해 일정에 따라 또는 요청 시 에이전트를 실행할 수 있습니다. 새 이슈 분류나 최근 활동 요약 같은 일상적인 작업에 유용합니다. 간단하고 비파괴적인 자동화를 하나 만듭니다.
-
-1. 사이드바에서 **Automations**를 선택한 다음 **New automation**을 선택합니다.
-2. `Recap my recent work` 같은 이름을 지정합니다.
-3. 트리거를 선택합니다. **Manual**은 요청 시 실행하고, **On a schedule**은 자동으로 실행하며, **When an issue is created**는 새 이슈에 반응합니다. 이 레슨에서는 **Manual**을 선택합니다.
-4. 자동화가 내용을 변경할 수 없도록 다음과 같은 읽기 전용 프롬프트를 입력합니다.
-
- ```plaintext
- Summarize the pull requests merged in this repository over the last week, and list any issues still open in the backlog.
- ```
-
-5. 프로젝트(Tailspin Toys 리포지토리)를 선택하고 자동화를 만듭니다.
-6. 요청 시 실행하여 결과를 확인합니다.
-
-> [!TIP]
-> 자동화는 로컬 또는 클라우드에서 실행할 수 있습니다. 일정에 따라 사용자 없이 실행하려면 **Run in the cloud**를 활성화하고 자동화에서 사용할 수 있는 **Tools**를 선택합니다. 출력 결과를 신뢰할 수 있을 때까지 예약 자동화의 범위를 제한하고 비파괴적으로 유지합니다.
-
-## 모범 사례
-
-AI 도구를 사용할 때는 도구를 둘러싼 인프라가 결과의 품질을 좌우합니다. 이 워크숍에서는 지침 파일, 스킬, 사용자 지정 에이전트를 모두 사용했습니다. 이러한 항목에 투자하고 세션 간에 재사용합니다.
-
-작업에 맞는 **모드와 모델**을 선택합니다. 구축 전에 접근 방식을 검토하려면 **Plan**을 사용하고, 범위가 명확한 변경에서 계속 참여하려면 **Interactive**를 사용하며, 범위가 명확하고 격리된 작업에만 **Autopilot**을 사용합니다. 일상적인 편집에는 빠른 모델을 선택하고 복잡한 작업에는 추론 능력이 더 높은 모델을 선택합니다.
-
-컨텍스트는 인프라만큼 중요합니다. 만들려는 *항목*, 그 *이유*, 원하는 *방식*을 명확하게 설명하면 출력이 크게 달라집니다. 빠른 채팅은 아이디어를 전체 세션에 적용하기 전에 범위를 정하기에 적합합니다.
-
-## 더 살펴볼 내용
-
-핵심 워크플로를 모두 살펴봤습니다. 다음 기능도 확인해 볼 만합니다.
-
-- 전체 세션이 필요 없는 빠른 일회성 질문을 위한 **Quick chats**
-- 구축 전에 문제를 함께 검토하고 유용한 피드백을 받기 위한 **Rubber duck**
-- 반복 가능한 전문 작업을 위해 역할, 도구, 지침을 패키지하는 [**Custom agents**][custom-agents]
-- 세션에서 일어난 일을 서술형으로 생성하는 [`/chronicle`][chronicle]
-- Ollama, Foundry Local, LM Studio를 통한 로컬 모델을 포함하여 자체 공급자의 모델을 사용하는 [Bring your own key (BYOK)][byok]
-- GitHub에서 호스팅하는 격리된 환경에서 세션을 실행하는 [Cloud sandboxes][sandboxes]
-- 리포지토리, 세션, 프롬프트에서 바로 앱을 여는 [Deep links][deep-links]
-
-## 다음 단계
-
-어떤 도구든 더 능숙하게 사용하려면 계속 사용해야 합니다. 프로덕션 코드, 취미 프로젝트, 오랫동안 생각만 하고 만들지 못했던 작은 앱에 사용해 봅니다. 배운 내용을 팀과 공유하고 팀의 경험에서도 배웁니다. 언제나 그렇듯 문서를 살펴봅니다.
-
-GitHub Copilot 생태계를 더 살펴보려면 [VS Code 실습 과정](../../vscode/), [Copilot CLI 실습 과정](../../cli/), [Cloud agent 실습 과정](../../cloud/)을 확인합니다.
-
-## 리소스
-
-- [GitHub Copilot app 정보][about-copilot-app]
-- [GitHub Copilot app 시작하기][getting-started]
-- [GitHub Copilot app 사용자 지정][customize]
-- [자동화 사용][using-automations]
-- [캔버스 확장 사용][canvas-docs]
-- [클라우드 및 로컬 샌드박스 정보][sandboxes]
-
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
-[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
-[customize]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
-[using-automations]: https://docs.github.com/copilot/how-tos/github-copilot-app/using-automations
-[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
-[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
-[chronicle]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/chronicle
-[custom-agents]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
-[byok]: https://docs.github.com/copilot/how-tos/github-copilot-app/use-byok-models
-[deep-links]: https://docs.github.com/copilot/how-tos/github-copilot-app/open-with-deep-links
\ No newline at end of file
diff --git a/docs/ko-kr/app/9-canvases.md b/docs/ko-kr/app/9-canvases.md
new file mode 100644
index 00000000..87f86946
--- /dev/null
+++ b/docs/ko-kr/app/9-canvases.md
@@ -0,0 +1,148 @@
+---
+title: "Lesson 9 - 이슈 분류 캔버스 만들기"
+description: "리포지토리에 저장하는 이슈 분류 캔버스를 만들고 검토하여 PR 4를 병합한 다음, 다른 기능을 시작하지 않고 다시 열어 이슈 컨텍스트를 추가합니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+지금까지 채팅을 통해 에이전트를 지시했습니다. 하지만 많은 작업은 대화가 아니라 보드, 문서, 검사 목록에서 이루어집니다. **캔버스**는 바로 이러한 작업을 위해 앱 안에서 사용자와 에이전트가 함께 사용하는 화면을 제공합니다. 이 레슨에서는 지금까지 처리한 백로그를 계획하고 추적하는 간단한 캔버스를 만듭니다.
+
+이 레슨에서는 다음 작업을 수행합니다.
+
+- 캔버스의 개념과 사용 시점을 이해합니다.
+- 백로그를 분류하는 공유 Kanban 보드 캔버스를 만듭니다.
+- 캔버스를 리포지토리에 저장하고 팀에서 사용할 수 있도록 병합합니다.
+- 캔버스를 다시 열고 다른 기능을 구현하지 않은 채 이슈 컨텍스트를 추가합니다.
+
+## 시나리오
+
+이슈 목록을 보면 부담스러울 수 있습니다. Tailspin Toys 개발자는 이슈를 분류하고 세부 정보를 세션 컨텍스트에 추가하는 도구를 원합니다. 컨텍스트 추가는 이슈 구현을 승인하는 것이 아닙니다. 이 실습은 다섯 번째 PR이 아니라 재사용 가능한 보드에서 끝납니다.
+
+## 캔버스란?
+
+[캔버스][canvas-docs]는 계획, 분류 보드, 릴리스 검사 목록, 대시보드, 문서 같은 작업 산출물을 위한 공유 대화형 화면입니다. 채팅은 의도를 설명하고 모호한 부분을 함께 추론하는 데 유용하지만 대부분의 작업은 *화면*에서 이루어집니다. 캔버스를 사용하면 해당 화면에서 에이전트와 직접 협업할 수 있습니다.
+
+캔버스는 **양방향**입니다. 에이전트가 작업하면서 캔버스를 업데이트할 수 있고 사용자도 동일한 화면을 편집할 수 있습니다. 캔버스를 만들면 에이전트가 프롬프트와 워크플로를 바탕으로 구축하며, 진행하면서 기능을 추가하거나 제거하거나 수정하도록 요청할 수 있습니다. 캔버스를 만들면 앱의 오른쪽 패널에서 열립니다.
+
+일반적인 예는 다음과 같습니다.
+
+- 하루를 계획하고 이슈와 끌어오기 요청의 우선순위를 정하는 **Markdown 캔버스**
+- 사용자와 에이전트가 카드를 추가하고 열 사이에서 작업을 이동하는 **에이전트 Kanban 보드**
+- 리포지토리의 주요 이슈와 반복되는 주제를 요약하는 **이슈 분류 보드**
+
+## 캔버스를 사용하는 이유
+
+작업에 구조화, 반복, 검증이 필요하고 채팅만으로 충분하지 않다면 캔버스를 사용합니다. 캔버스로 다음 작업을 수행할 수 있습니다.
+
+- 워크플로에 맞는 실제 산출물을 기반으로 에이전트가 작업하게 합니다.
+- 공유 화면에서 작업을 직접 안내하거나 수정한 다음 에이전트가 변경 내용에서 계속 작업하게 합니다.
+- 채팅 응답만 보는 대신 산출물의 눈에 보이는 변경으로 진행 상황을 확인합니다.
+
+## 작업 추적 캔버스 만들기
+
+PR 3이 병합되었는지 확인합니다. 캔버스를 시작하기 전에 별점, 문서화 표준, 필터링 기능, 품질 스킬, QA 프로필이 모두 `main`에 있어야 합니다. 마지막 PR 마일스톤에 새 세션과 하나의 브랜치를 사용합니다.
+
+1. GitHub Copilot app으로 돌아가거나 앱을 엽니다.
+2. **Home screen**을 선택합니다.
+3. 리포지토리로 `tailspin-toys`가 선택되어 있는지 확인합니다.
+4. **new working tree**와 **Interactive** 모드를 선택합니다. 파일을 만들기 전에 다음 시작 상태 요청을 보냅니다.
+
+ ```plaintext
+ 아무것도 구현하지 않고 이 새 캔버스 세션을 준비해 주십시오. 미커밋 변경이 없는 새 워크트리인지 확인하고 origin을 가져온 다음 현재 세션 브랜치를 origin/main으로 fast-forward해 주십시오. 체크아웃, 브랜치, 일치하는 HEAD 및 origin/main 리비전을 보고해 주십시오. 필터링 PR이 병합되었고 필터링 기능, quality-checks 스킬, QA 프로필이 있는지 확인해 주십시오.
+
+ 체크아웃에 미커밋 변경이나 분기가 있거나 이전 병합이 누락되었으면 중단해 주십시오. 재설정하거나 작업을 버리거나 브랜치를 전환하거나 다른 브랜치를 만들지 마십시오. 시작 상태를 보고한 후 중단해 주십시오.
+ ```
+
+5. 시작 상태 보고서를 확인한 다음 리포지토리에 저장하는 캔버스를 요청합니다.
+
+ ```plaintext
+ App이 지원하는 캔버스 확장 워크플로로 이 리포지토리용 기본 Kanban 이슈 분류 캔버스를 만들어 주십시오. 팀에서 재사용할 수 있도록 정의를 .github/extensions/에 저장해 주십시오. 기존 확장을 살펴보고 보존해 주십시오. 제공된 데이터베이스 탐색기를 덮어쓰지 마십시오.
+
+ 현재 열린 이슈를 읽어 주십시오. 가장 주의가 필요할 가능성이 높은 세 이슈를 강조하고 나머지는 아래에 배치해 주십시오. 강조한 각 이슈의 제목, 내용 요약, URL, 우선순위의 근거를 포함해 주십시오. 순위는 이슈를 변경하라는 지시가 아니라 제안으로 취급해 주십시오.
+
+ 모든 카드에 이슈 세부 정보를 이 세션에만 첨부하는 Add to current context 동작을 제공해 주십시오. 구현을 시작하거나 세션이나 브랜치를 만들거나 이슈 상태를 변경하거나 PR을 만들면 안 됩니다. 캔버스의 범위를 제한하고 키보드로 접근할 수 있게 해 주십시오.
+
+ 생성한 파일을 보여 주고 검토할 수 있도록 캔버스를 열어 주십시오. 애플리케이션 코드를 변경하거나 커밋, 푸시, PR 생성을 하지 마십시오. 설치하거나 의존성을 추가하기 전에 질문해 주십시오.
+ ```
+
+Copilot이 캔버스 파일을 만들고 공유 화면을 엽니다. 동작을 신뢰하기 전에 생성된 확장을 검토합니다. 단순한 그림이 아니라 실행 가능한 리포지토리 콘텐츠입니다.
+
+> [!NOTE]
+> 첫 버전에 개선이 필요하면 이슈 분류 범위 안에서 집중된 개선을 요청합니다. 이 실습을 백로그 이슈 구현으로 바꾸지 않습니다.
+
+## 캔버스 검토 및 사용
+
+1. **Changes**를 열고 캔버스 정의가 사용자나 세션 전용이 아니라 리포지토리의 `.github/extensions/` 아래에 저장되었는지 확인합니다. 기존 확장과 애플리케이션 파일이 변경되지 않았는지 확인합니다.
+2. 보드를 실제 열린 이슈와 비교하고 순위 설명을 평가합니다.
+3. 카드와 컨트롤이 읽기 쉽고 키보드로 사용할 수 있는지 확인합니다.
+4. 이슈의 **Add to current context**를 선택하고 세부 정보만 대화에 들어오는지 확인합니다. 구현이나 이슈 상태 변경이 시작되면 안 됩니다.
+5. 수정 사항을 검토하고 변경된 파일에 적용되는 기존 검증을 실행하도록 Copilot에 요청합니다. 대화형 화면이 열렸다는 이유로 올바르다고 가정하지 말고 결과와 차단 요인을 기록합니다.
+
+## 캔버스를 저장하고 리포지토리에 병합
+
+캔버스는 이미 리포지토리 자산입니다. 검토한 캔버스 작업만 커밋하고 PR 4로 제출합니다.
+
+1. 동일한 세션에서 다음을 보냅니다.
+
+ ```plaintext
+ 리포지토리에 저장한 이슈 분류 캔버스의 diff와 검증 근거를 검토해 주십시오. 승인된 캔버스 파일을 이 세션 브랜치에 커밋하고 푸시한 다음 리포지토리의 PR 템플릿을 사용하여 main을 대상으로 PR 하나를 만들어 주십시오. 캔버스 동작과 이슈 추가가 컨텍스트만 추가함을 어떻게 검증했는지 설명해 주십시오. 아직 병합하거나 백로그 이슈를 구현하지 마십시오.
+ ```
+
+2. **My work**에서 전체 PR diff와 검사를 검토합니다. 캔버스가 포함되어 있고 관련 없는 애플리케이션 작업은 없는지 확인합니다.
+3. 동일한 캔버스 세션에서 PR 작업 드롭다운을 열고 **Agent merge**를 선택합니다. 허용된 작업을 검토하고 최종 결과를 승인할 때까지 **Merge pull request**를 꺼 둡니다.
+4. Agent Merge를 시작하기 전에 범위를 설정합니다.
+
+ ```plaintext
+ Agent Merge로 이 기존 캔버스 PR을 관리해 주십시오. 범위 안의 검토 및 CI 차단 요인만 해결하고 관련 없는 변경이나 설치 전에 질문해 주십시오. 캔버스가 변경되면 관련 검증을 반복하고 근거를 업데이트해 주십시오. 검토 후 제가 Merge pull request를 명시적으로 활성화할 때까지 병합하지 마십시오. 백로그 이슈를 구현하거나 다른 PR을 만들지 마십시오.
+ ```
+
+5. **Agent merge**를 선택하고 후속 변경을 검토합니다. 학습용 리포지토리의 실제 CI 검사를 확인하고 실패를 해결합니다. CI는 캔버스를 직접 사용하는 검증을 대체하지 않습니다.
+
+6. 최종 diff와 현재 근거가 승인되고 필수 검사와 검토를 통과하면 Agent Merge 드롭다운에서 **Merge pull request**를 선택하여 병합을 명시적으로 허용합니다.
+
+ 
+
+7. 계속하기 전에 GitHub에서 PR 4가 **Merged**로 표시되는지 확인합니다.
+
+이제 팀을 위한 새 공유 캔버스를 만들었습니다.
+
+## 다른 기능을 시작하지 않고 캔버스 다시 열기
+
+PR이 병합된 후 동일한 캔버스 세션에서 리포지토리에 저장한 캔버스를 다시 엽니다. 이는 검토 단계이지 다른 브랜치나 PR 마일스톤이 아닙니다.
+
+1. 캔버스 세션으로 돌아가 **Interactive** 모드를 유지하고 캔버스 패널이 아직 열려 있으면 닫습니다.
+2. 다음을 보냅니다.
+
+ ```plaintext
+ 이 동일한 세션에서 리포지토리의 이슈 분류 캔버스를 다시 열어 주십시오. 세부 정보를 확인하기 위해서만 이슈를 컨텍스트에 추가하겠습니다. 파일을 편집하거나 이슈를 구현하거나 상태를 변경하거나 다른 세션이나 브랜치를 만들거나 커밋, 푸시, PR 생성을 하지 마십시오.
+ ```
+
+3. 정의를 다시 생성하지 않고 저장된 캔버스가 다시 열리는지 확인합니다.
+4. 가장 관심 있는 이슈 중 하나에서 **Add to current context**를 선택합니다.
+5. 구현을 시작하지 않고 선택한 이슈의 세부 정보가 컨텍스트에 표시되는지 확인합니다. 여기서 멈춥니다. 워크숍에는 다섯 번이 아니라 네 번의 PR 마일스톤이 있습니다.
+
+이제 직접 만든 캔버스를 사용하여 개발 프로세스를 간소화했습니다.
+
+## 요약 및 다음 단계
+
+사용자와 에이전트가 협업하는 공유 화면을 만들었습니다. 다음 작업을 수행했습니다.
+
+- 캔버스의 개념과 사용 시점을 배웠습니다.
+- 에이전트와 공유 Kanban 분류 보드 캔버스를 만들었습니다.
+- Agent Merge를 사용하여 캔버스를 리포지토리에 저장하고 병합했습니다.
+- 병합된 캔버스를 다시 열고 다른 기능을 시작하지 않은 채 이슈 컨텍스트를 추가했습니다.
+
+백로그를 추적하도록 설정했으므로 지금까지 구축한 항목과 다음 단계를 돌아봅니다. [레슨 10 - 마무리 및 다음 단계][next-lesson]를 계속 진행합니다.
+
+## 리소스
+
+- [GitHub Copilot app에서 캔버스 확장 사용][canvas-docs]
+- [Awesome Copilot의 캔버스][awesome-copilot-canvases]
+- [GitHub Copilot app 정보][about-copilot-app]
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
+[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/ko-kr/app/README.md b/docs/ko-kr/app/README.md
index 60cb1e8f..2f28b558 100644
--- a/docs/ko-kr/app/README.md
+++ b/docs/ko-kr/app/README.md
@@ -3,12 +3,14 @@ slug: ko-kr/app
title: "GitHub Copilot app"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
[**GitHub Copilot app**](https://docs.github.com/copilot/concepts/agents/github-copilot-app)은 Copilot CLI를 기반으로 구축된 데스크톱 애플리케이션으로, 에이전트 기반 개발을 하나의 집중된 워크스페이스에서 수행할 수 있게 해 줍니다. 병렬 에이전트 세션, 전환 가능한 세션 모드, 공유 캔버스, GitHub 이슈 및 끌어오기 요청 기본 관리 기능을 제공합니다. 여기에는 끌어오기 요청의 리베이스, 검토 피드백, CI 수정, 병합 과정을 관리하는 **Agent Merge**도 포함됩니다.
-이 레슨에서는 앱을 설치하고 프로젝트를 설정한 다음, 앱 워크스페이스와 템플릿에서 미리 생성한 백로그를 살펴봅니다. 별점을 추가하는 작은 변경으로 시작한 뒤, 이슈를 바탕으로 사용자 지정 지침 표준을 추가하고, 격리된 에이전트 세션에서 필터링 기능을 구축하고, 재사용 가능한 스킬로 검증합니다. Playwright MCP 서버를 추가하여 실제 브라우저에서 기능을 살펴본 다음, **Agent Merge**가 끌어오기 요청을 병합하는 단계까지 병합 자동화 수준을 높입니다. 마지막으로 공유 캔버스에서 협업하고 반복 작업을 자동화하여 아이디어를 병합된 기능으로 완성하는 전체 과정을 경험합니다.
+설정 레슨 0~1에서 프로젝트와 App 워크스페이스를 준비합니다. 아홉 개의 핵심 모듈인 레슨 2~10은 별점을 추가하는 작은 변경과 실제 코드로 효과를 확인하는 문서화 규칙으로 시작합니다. 그런 다음 필터링을 계획하고 구축하며, 셸 스크립트를 포함하는 quality-checks 스킬을 만들고 실행하고, Playwright MCP로 기능을 관찰하며, 요구 사항과 커버리지를 평가할 QA 사용자 지정 에이전트를 만듭니다. 전체 기능 PR을 검토하고 Agent Merge를 승인한 다음 공유 이슈 분류 캔버스를 만들고 병합합니다.
+
+워크숍에는 네 번의 PR 마일스톤이 있습니다. 별점, 지침과 시연, 필터링과 스킬·QA 프로필·테스트, 마지막으로 캔버스입니다. 각 마일스톤은 업데이트된 `main`에서 시작하며, 모듈별이 아니라 PR별로 하나의 브랜치를 사용합니다. 레슨 4~8은 동일한 필터링 세션, 워크트리, 브랜치를 유지합니다. 캔버스를 다시 열 때는 이슈 컨텍스트만 추가하고 다른 기능이나 다섯 번째 PR을 시작하지 않습니다. 자동화는 추가 실습이 아니라 다음 단계의 링크로 소개합니다.
## 레슨
@@ -16,13 +18,15 @@ lastUpdated: 2026-06-30
|--------|-------|-------------|
| [0. 필수 조건][ex0] | 설정 | Node.js를 설치하고 Tailspin Toys 프로젝트의 복사본 만들기 |
| [1. Copilot app 설치][ex1] | 설정 | 앱을 설치하고 프로젝트를 연결한 다음 워크스페이스 살펴보기 |
-| [2. 첫 번째 에이전트 세션 실행][ex2] | 첫 번째 변경 | 세션을 시작하고 작은 변경을 첫 번째 끌어오기 요청으로 제공하기 |
-| [3. 사용자 지정 지침으로 Copilot 안내][ex3] | 컨텍스트 | 이슈를 바탕으로 문서화 표준을 추가하고 병합하기 |
-| [4. Autopilot으로 기능 구축][ex4] | 핵심 기능 | Plan과 Autopilot으로 필터링 기능을 구축한 다음 스킬로 검증하기 |
-| [5. Playwright MCP로 테스트][ex5] | 외부 도구 | Playwright MCP 서버를 추가하고 브라우저에서 기능 살펴보기 |
-| [6. Agent Merge로 병합][ex6] | 병합 | Agent Merge가 필터링 끌어오기 요청을 수정하고 병합하도록 하기 |
-| [7. 캔버스로 계획 수립][ex7] | 협업 | 작업을 계획하고 추적하는 공유 캔버스 만들기 |
-| [8. 검토 및 다음 단계][ex8] | 요약 | 반복 작업을 자동화하고 다음에 살펴볼 내용 알아보기 |
+| [2. 별점 추가로 작은 성과 얻기][ex2] | 첫 번째 변경 | 기존 별점과 null 대체 표시를 추가하고 PR 1 병합하기 |
+| [3. 사용자 지정 지침으로 Copilot 안내][ex3] | 컨텍스트 | 문서화 표준과 실제 시연을 추가하고 PR 2 병합하기 |
+| [4. Plan과 Autopilot으로 필터링 구축][ex4] | 구현 | 계획을 승인하고 필터링을 구현·검사한 다음 체크포인트 저장하기 |
+| [5. quality-checks 스킬 만들기 및 사용][ex5] | 반복 가능한 검사 | 함께 제공할 셸 스크립트를 만들고 검토하고 실행하기 |
+| [6. Playwright MCP로 기능 검증][ex6] | 브라우저 관찰 | Customize에서 MCP를 구성하고 필터링 동작 살펴보기 |
+| [7. QA 에이전트 만들기 및 사용][ex7] | 요구 사항과 커버리지 | 전문가 프로필을 선택하고 최종 검증 근거 수집하기 |
+| [8. 기능 PR 만들기 및 병합][ex8] | 검토와 병합 | 필터링, 스킬, QA 프로필, 테스트를 검토한 다음 PR 3의 Agent Merge 승인하기 |
+| [9. 이슈 분류 캔버스 만들기][ex9] | 협업 | 리포지토리에 저장하는 캔버스를 PR 4로 공유하고 이슈 컨텍스트 추가하기 |
+| [10. 마무리 및 다음 단계][ex10] | 요약 | 워크플로, 산출물, 추가 리소스 돌아보기 |
## 필수 조건
@@ -50,9 +54,11 @@ lastUpdated: 2026-06-30
[ex2]: 2-add-star-rating/
[ex3]: 3-custom-instructions/
[ex4]: 4-build-filtering/
-[ex5]: 5-mcp-playwright/
-[ex6]: 6-agent-merge/
-[ex7]: 7-canvases/
-[ex8]: 8-review/
+[ex5]: 5-agent-skills/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-canvases/
+[ex10]: 10-review/
[install-git]: https://github.com/git-guides/install-git
[callout-student-plan-education]: https://github.com/education/students
\ No newline at end of file
diff --git a/docs/ko-kr/cli/0-prerequisites.md b/docs/ko-kr/cli/0-prerequisites.md
index 555bd1cd..87f49610 100644
--- a/docs/ko-kr/cli/0-prerequisites.md
+++ b/docs/ko-kr/cli/0-prerequisites.md
@@ -2,7 +2,7 @@
title: "연습 0: 사전 준비"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
Copilot CLI 연습을 시작하기 전에 모든 것을 준비해야 합니다. Tailspin Toys 리포지토리(Repository)의 복사본을 만들고 [코드스페이스][codespaces]를 시작합니다. 다음 연습에서는 해당 코드스페이스의 통합 터미널을 사용해 Copilot CLI를 설치하고 실행합니다.
@@ -11,6 +11,8 @@ Copilot CLI 연습을 시작하기 전에 모든 것을 준비해야 합니다.
앞으로 작성할 코드를 위한 리포지토리 복사본을 만들기 위해 [template][template-repository]에서 새 인스턴스(Instance)를 만듭니다. 새 인스턴스에는 실습에 필요한 파일이 모두 포함되며, 연습을 진행하는 동안 이 리포지토리를 사용합니다.
+템플릿의 새 복사본을 사용합니다. 리포지토리 지침, 애플리케이션 코드, 테스트, CI는 포함되지만 사용자 지정 에이전트나 스킬은 제공되지 않습니다. 이러한 자산은 직접 만듭니다. 이전 복사본으로 돌아온 경우 기존 사용자 지정을 살펴본 후 변경하며, 자신의 작업을 덮어쓰지 않습니다.
+
1. 새 브라우저 창에서 이 실습의 GitHub 리포지토리로 이동합니다: `https://github.com/github-samples/tailspin-toys`.
2. 실습용 리포지토리 페이지에서 **Use this template** 버튼을 선택해 리포지토리 복사본을 만듭니다. 그런 다음 **Create a new repository**를 선택합니다.
@@ -27,6 +29,8 @@ Copilot CLI 연습을 시작하기 전에 모든 것을 준비해야 합니다.
>
> template에서 리포지토리를 만들면 GitHub issue 백로그가 자동으로 생성됩니다. 워크숍 내내 이 issue를 바탕으로 작업하므로 직접 등록할 내용은 없습니다.
+이슈 초기 생성 워크플로가 완료될 때까지 기다린 다음 **Issues** 탭에서 **Allow users to filter games by category and publisher**와 **Update our repository coding standards**를 확인합니다. 연습에서는 추정한 이슈 번호가 아니라 실제 제목과 URL을 사용합니다. 백로그가 없다면 워크플로 결과를 확인한 후 진행합니다.
+
## 코드스페이스 만들기
이제 코드스페이스를 사용해 실습을 진행합니다.
@@ -50,8 +54,8 @@ Copilot CLI 연습을 시작하기 전에 모든 것을 준비해야 합니다.
> [!NOTE]
> 이 워크숍은 코드스페이스 또는 로컬 [dev container][dev-containers] 안에서 실행하도록 설계되었습니다. 두 환경 모두 원활한 진행에 필요한 사전 요구 사항이 모두 설치된 상태를 보장합니다. 로컬에서 실행하고 싶다면 복제한 리포지토리를 VS Code에서 열고, 메시지가 표시되면 **Reopen in Container**를 선택합니다. 그러면 코드스페이스에서 사용하는 것과 동일한 dev container를 VS Code가 빌드합니다.
-[codespaces]: https://github.com/features/codespaces
-[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
+코드스페이스가 준비되면 [연습 1][next-lesson]에서 터미널을 열고 Copilot CLI 설치 전에 리포지토리, 런타임, 인증을 확인합니다.
+
## 요약
축하합니다! 실습용 리포지토리 복사본을 만들었습니다. 또한 Copilot CLI 작업을 시작할 때 사용할 코드스페이스 생성도 시작했습니다.
@@ -69,3 +73,5 @@ Copilot CLI를 설치하고 GitHub 계정으로 인증해 보겠습니다. [연
[template-repository]: https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-template-repository
[codespaces-quickstart]: https://docs.github.com/codespaces/getting-started/quickstart
[next-lesson]: ../1-install-copilot-cli/
+[codespaces]: https://github.com/features/codespaces
+[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
diff --git a/docs/ko-kr/cli/1-install-copilot-cli.md b/docs/ko-kr/cli/1-install-copilot-cli.md
index 97f81415..c03f677d 100644
--- a/docs/ko-kr/cli/1-install-copilot-cli.md
+++ b/docs/ko-kr/cli/1-install-copilot-cli.md
@@ -2,7 +2,7 @@
title: "연습 1 - GitHub Copilot CLI 설치"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
[GitHub Copilot CLI][about-copilot-cli]는 터미널에서 실행되는 강력한 에이전트형 코딩 도우미입니다. 코드베이스를 탐색하고, 코드를 생성하고, 명령을 실행하고, 외부 도구와 상호 작용하는 작업을 모두 명령줄에서 수행할 수 있습니다. 작업을 위임하고, 변경을 요청하고, 흐름을 유지할 수 있습니다. 예상할 수 있듯 첫 단계는 도구를 설치하는 일입니다. 다행히 이미 익숙한 도구로 설치할 수 있습니다.
@@ -21,10 +21,25 @@ lastUpdated: 2026-06-30
Copilot CLI를 설치하기 전에 코드스페이스에서 터미널 창을 열어야 합니다.
-1. 아직 열지 않았다면 코드스페이스로 돌아갑니다.
+1. 코드스페이스로 돌아가 설정이 완료될 때까지 기다립니다.
2. Ctrl+`를 눌러 터미널 창을 엽니다.
3. VS Code 창 하단에 터미널 패널이 나타나는지 확인합니다.
+## 학습 환경 확인
+
+코드스페이스 터미널에서 워크숍 콘텐츠 리포지토리가 아니라 자신의 Tailspin Toys 리포지토리에 있는지 확인합니다. `README.md`와 `package.json`에서 설정 및 검사 명령을 읽습니다. 현재 Tailspin Toys에는 Node.js 22.13 이상, 프로젝트 의존성, E2E 테스트용 Playwright Chromium이 필요합니다.
+
+```bash
+pwd
+git remote -v
+node --version
+gh auth status
+```
+
+GitHub CLI(`gh`)는 PR과 CI를 확인하는 데 유용합니다. 인증되지 않았다면 `gh auth login`을 실행하고 브라우저 안내를 따릅니다. 계정이 이 리포지토리에 브랜치를 푸시하고 PR을 생성하고 병합할 수 있는지 확인합니다. 조직 정책에 따라 다른 검토자가 필요할 수 있습니다. 코드 변경을 시작하기 전에 리포지토리 설정 안내에 따라 누락된 필수 조건을 해결하고, 설치 내용을 검토한 후 승인합니다.
+
+CLI는 시작한 체크아웃에서 실행됩니다. 대화를 시작해도 격리된 워크트리(Worktree)가 자동으로 생성되지는 않습니다. 이 워크숍에서는 PR 마일스톤마다 하나의 브랜치를 사용합니다. 먼저 별점과 지침 실증을 병합한 후 연습 4~8에서 동일한 필터링 브랜치를 유지합니다.
+
## Copilot CLI 설치
Copilot CLI는 [npm][install-npm], [WinGet][install-winget], [Homebrew][install-homebrew]로 설치할 수 있습니다. GitHub Codespaces에는 Node.js가 이미 설치되어 있으므로 npm을 사용해 Copilot CLI를 설치합니다.
@@ -35,7 +50,7 @@ Copilot CLI는 [npm][install-npm], [WinGet][install-winget], [Homebrew][install-
node --version
```
- 버전 22 이상(예: `v22.x.x`)이 표시되어야 합니다.
+ CLI 자체의 요구 사항이 다르더라도 Tailspin Toys에는 버전 22.13 이상이 필요합니다. 버전이 너무 낮다면 학습용 리포지토리의 설정 안내를 따릅니다.
2. npm을 사용해 코드스페이스에 Copilot CLI를 전역 설치합니다.
@@ -51,8 +66,8 @@ Copilot CLI는 [npm][install-npm], [WinGet][install-winget], [Homebrew][install-
버전 번호(예: `v1.0.XX`)가 표시되어야 합니다.
-> [!TIP]
-> 권한 오류가 발생하면 일부 시스템에서는 `sudo npm install -g @github/copilot`를 사용해야 할 수 있습니다. 하지만 GitHub Codespaces에서는 일반적으로 필요하지 않습니다.
+> [!NOTE]
+> 권한 오류로 설치가 실패하면 익숙하지 않은 명령을 관리자 권한으로 다시 실행하지 말고 npm 설정을 확인하거나 워크숍 진행자에게 도움을 요청합니다.
## GitHub로 인증하기
@@ -85,22 +100,39 @@ Copilot CLI를 처음 실행하면 GitHub 계정으로 인증하라는 메시지
2. 이 워크숍에서는 계속 이 리포지토리에서 작업하므로 **Yes, and remember this folder for future sessions**를 선택합니다.
3. 간단한 질문을 해 Copilot이 작동하는지 확인합니다.
- ```
- What files are in this project?
+ ```plaintext
+ 이 프로젝트에는 어떤 파일이 있습니까?
```
4. Copilot이 리포지토리를 탐색하고 프로젝트 구조 요약을 제공해야 합니다.
5. `/help` 명령으로 사용 가능한 slash commands를 확인합니다.
- ```
+ ```text
/help
```
-6. 터미널에서 다음 명령을 입력해 Copilot CLI를 종료합니다. 이후 연습에서 다시 Copilot CLI로 돌아옵니다.
+6. Copilot 프롬프트에서 다음 명령을 입력해 이 세션을 종료합니다. 첫 변경은 새 세션에서 시작합니다.
+ ```text
+ /exit
```
- exit
- ```
+
+## 모드와 권한 이해
+
+Copilot CLI는 시작한 디렉터리와 Git 브랜치에서 작업합니다. 디렉터리를 신뢰하면 리포지토리 컨텍스트를 사용할 수 있지만, 모든 도구 작업을 승인하는 것과는 다릅니다. 파일 변경, 셸 명령, GitHub 작업에 대한 권한 요청을 검토합니다.
+
+학습용 리포지토리 루트에서 다음 명령으로 코드 연습을 시작합니다.
+
+```bash
+copilot --enable-all-github-mcp-tools
+```
+
+GitHub MCP 서버는 기본 제공됩니다. 이 플래그는 이슈와 PR 작업에 필요한 전체 도구를 노출하지만, 인증과 리포지토리 권한 및 도구 승인은 계속 적용됩니다. 플래그 자체가 커밋이나 PR을 승인하지는 않습니다.
+
+Shift+Tab으로 일반 **Interactive**, **Plan**, **Autopilot** 모드를 순환합니다. 요청 전에 모드 표시를 확인합니다. 초기 변경에서는 Interactive를 유지하고, 필터링은 구축 전에 계획하며, 사용자 지정을 만들고 검토하기 전에는 명시적으로 Interactive로 돌아옵니다.
+
+> [!CAUTION]
+> 모드와 권한 설정은 다릅니다. Autopilot은 자율적으로 작업을 계속하며, `--allow-all`과 별칭 `--yolo`는 모든 도구, 경로, URL 권한을 부여합니다. 이 워크숍은 매번 무제한 권한으로 세션을 시작할 것을 요구하지 않습니다. 코드스페이스에서도 액세스를 허용하기 전에 범위를 검토합니다.
## 요약 및 다음 단계
@@ -111,7 +143,7 @@ Copilot CLI를 처음 실행하면 GitHub 계정으로 인증하라는 메시지
- Copilot CLI가 작업할 디렉터리를 신뢰하도록 설정합니다.
- 설치가 올바르게 작동하는지 확인합니다.
-이제 Copilot CLI가 설치되었으니, Copilot에 프로젝트 컨텍스트를 제공해 보겠습니다. [연습 2 - CLI로 커스텀 지침 사용하기][next-lesson]로 계속 진행합니다.
+Copilot CLI를 설치했으므로 [연습 2 - 별점 추가로 작은 성과 얻기][next-lesson]에서 검토하기 쉬운 작은 변경을 수행합니다.
## 리소스
@@ -120,7 +152,7 @@ Copilot CLI를 처음 실행하면 GitHub 계정으로 인증하라는 메시지
- [Copilot CLI 사용하기][using-copilot-cli]
[previous-lesson]: ../0-prerequisites/
-[next-lesson]: ../2-custom-instructions/
+[next-lesson]: ../2-add-star-rating/
[install-copilot-cli]: https://docs.github.com/copilot/how-tos/set-up/install-copilot-cli
[install-npm]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-npm-all-platforms
[install-winget]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-winget-windows
diff --git a/docs/ko-kr/cli/10-review.md b/docs/ko-kr/cli/10-review.md
new file mode 100644
index 00000000..e7dd1e55
--- /dev/null
+++ b/docs/ko-kr/cli/10-review.md
@@ -0,0 +1,67 @@
+---
+title: "연습 10 - 마무리 및 다음 단계"
+description: "공통 개발 워크플로, 재사용 가능한 자산, 세 번의 CLI 끌어오기 요청 마일스톤을 검토합니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Copilot CLI를 사용하여 작은 변경에서 재사용 가능한 검증을 갖춘 계획된 기능으로 발전했습니다. 연습 0~1의 설정으로 환경을 준비했고, 연습 2~10의 아홉 개 핵심 모듈에서 완전한 개발 워크플로를 배웠습니다.
+
+## 세 번의 PR 마일스톤 검토
+
+| 마일스톤 | 병합한 결과 | 검토 습관 |
+| --- | --- | --- |
+| PR 1: 별점 | 게임 카드에 기존 `starRating` 표시, `null`이면 `No rating yet` 표시 | 변경 범위를 제한하고 두 경우 모두 검증합니다 |
+| PR 2: 사용자 지정 지침 | 범위를 좁힌 문서화 규칙과 작은 실제 코드 실증 | 채팅 예시뿐 아니라 지침이 실제 코드를 개선하는지 확인합니다 |
+| PR 3: 필터링과 검증 | 필터링, quality-checks 스킬, QA 프로필, 관련 테스트 | 병합 전에 모든 체크포인트, 현재 QA 근거, CI를 검토합니다 |
+
+처음 두 PR은 각각 병합한 후 업데이트된 `main`에서 다음 마일스톤을 시작했습니다. 연습 4~8은 하나의 브랜치와 체크아웃을 공유했습니다. 체크포인트 커밋으로 진행 상황을 보존하고 모듈마다 PR을 만들지는 않았습니다. 조작 방법 연습에서도 다른 기능이나 PR을 시작하지 않았습니다.
+
+## 공통 자산 검토
+
+터미널 인터페이스를 통해 [Copilot App 워크숍][app-workshop]과 같은 핵심 결과를 얻었습니다.
+
+- **리포지토리 지침**은 프로젝트 컨텍스트와 표준을 설명하며, 경로별 지침은 관련 파일의 세부 사항을 추가합니다.
+- **필터링 구현과 테스트**는 이슈와 계획 중 승인한 추가 합의 사항을 충족합니다.
+- **quality-checks 스킬**은 재사용 가능한 지침과 프로젝트의 네 가지 검사를 실행하는 실제 셸 스크립트를 묶습니다.
+- **Playwright MCP 설정**은 직접 관찰을 위한 브라우저 도구를 제공합니다. 이 CLI 흐름에서는 기능 PR이 아니라 사용자 설정에 저장됩니다.
+- **QA 사용자 지정 에이전트**는 요구 사항에서 시작하여 커버리지를 확인하고, 스킬과 브라우저 도구를 사용하며, 사실에 맞는 결과를 보고하는 재사용 가능한 역할을 정의합니다.
+- **PR과 검증 근거**는 검토한 변경을 테스트 결과, 브라우저 관찰, 한계, CI와 연결합니다.
+
+스킬은 단순한 명령 목록이 아니며, 프로필도 단순한 파일명이 아닙니다. 생성된 자산을 검토하고 실제 실행을 확인했으며, 사용자 지정 에이전트를 선택한 후 그 보고서를 활용했습니다.
+
+## 검증 목적 구분
+
+계획으로 구현 전에 요구 사항을 명확히 했습니다. Autopilot은 범위가 제한된 계획을 수행했고, Interactive로 돌아와 사용자 지정 작성 전에 의식적인 검토 시점을 되찾았습니다.
+
+구현 단계에서는 스킬이 생기기 전부터 기존 npm 검사를 사용했습니다. 스킬 연습에서는 함께 제공되는 스크립트와 인수 전달이 작동함을 확인했습니다. MCP는 전체 스위트 반복 대신 직접적인 브라우저 상호 작용을 보여 주었습니다. QA는 기준, 커버리지, 브라우저 근거, 스킬로 실행하는 네 가지 검사를 통합했습니다. PR에서는 여전히 유효한 QA 결과를 재사용했고 CI는 제출된 리비전을 검사했습니다.
+
+실패와 차단 요인도 유용한 결과입니다. 브라우저 도구 누락, 건너뛴 테스트, 오래된 서버, 해결되지 않은 요구 사항은 **NO-GO**를 의미하며 기준을 낮춰도 된다는 뜻이 아닙니다. 실제 공백이 있을 때 테스트를 추가합니다. 기존 커버리지가 충분하다면 테스트를 추가하지 않는 것이 올바른 판단입니다.
+
+## 앞으로도 유지할 습관
+
+- Copilot에 이슈, 변경 이유, 명확한 경계를 제공합니다.
+- 자율 작업을 승인하기 전에 계획을 검토합니다.
+- 생성한 지침, 스킬, 프로필을 실행 전에 확인합니다.
+- 결과가 어떤 체크아웃, 브랜치, 서버, 리비전을 설명하는지 파악합니다.
+- 정당한 최소 수정만 적용하고 변경 후 근거를 갱신합니다.
+- 설치, 파괴적 작업, 공유, PR 병합은 명시적으로 승인합니다.
+
+## 학습 계속하기
+
+[Copilot App 워크숍][app-workshop]은 그래픽 인터페이스로 공통 결과에 도달하고 캔버스 마일스톤을 추가합니다. [VS Code 워크숍][vscode-workshop]과 [Cloud 에이전트 워크숍][cloud-workshop]에서는 에이전트와 작업하는 다른 방법을 살펴봅니다.
+
+[Awesome Copilot][awesome-copilot]에서 지침, 스킬, 사용자 지정 에이전트 예제를 찾습니다. [연습 5의 스킬 예제][skill-examples]에는 기여 워크플로, 요구 사항 문서, 다이어그램, 브라우저 테스트가 있습니다. 커뮤니티 콘텐츠를 채택하기 전에 필수 조건과 동작을 검토합니다.
+
+일상적인 참조에는 [CLI 명령 참조][cli-reference], [에이전트 스킬 문서][agent-skills], [사용자 지정 에이전트 문서][custom-agents]를 활용합니다. 범위가 제한된 작업으로 계속 실험하고 검토한 자료만 승인된 경로로 공유합니다.
+
+[previous-lesson]: ../9-slash-commands/
+[app-workshop]: ../../app/
+[vscode-workshop]: ../../vscode/
+[cloud-workshop]: ../../cloud/
+[skill-examples]: ../5-agent-skills/#더-많은-스킬-예제
+[awesome-copilot]: https://github.com/github/awesome-copilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
+[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
+[custom-agents]: https://docs.github.com/copilot/concepts/agents/copilot-cli/about-custom-agents
diff --git a/docs/ko-kr/cli/2-add-star-rating.md b/docs/ko-kr/cli/2-add-star-rating.md
new file mode 100644
index 00000000..2eab211b
--- /dev/null
+++ b/docs/ko-kr/cli/2-add-star-rating.md
@@ -0,0 +1,83 @@
+---
+title: "연습 2 - 별점 추가로 작은 성과 얻기"
+description: "기존 게임 별점을 표시하고 변경을 검토·검증한 후 첫 번째 끌어오기 요청을 병합합니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+이해하고 검증할 수 있는 작은 변경부터 시작합니다. Tailspin Toys는 이미 각 게임의 `starRating`을 저장하고 상세 페이지에 표시합니다. 게임 카드에도 이 기존 값을 표시하고, 아직 평가되지 않은 게임에는 명확한 메시지를 보여 줍니다.
+
+이 연습에서는 다음을 수행합니다.
+
+- Interactive CLI 세션에서 범위를 좁힌 변경을 요청합니다.
+- diff를 검토하고 평가된 카드와 미평가 카드를 검증합니다.
+- 커밋하고 PR 1을 생성, 검토, 병합합니다.
+
+## 첫 마일스톤 시작
+
+학습용 리포지토리 루트에서 작업 트리에 미커밋 변경이 없는지 확인하고, `main`을 업데이트한 후 브랜치를 만듭니다. `git status`에 예상하지 못한 변경이 표시되면 전환 전에 해결합니다. 변경을 버리지 않습니다.
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-star-rating
+copilot --enable-all-github-mcp-tools
+```
+
+메시지가 표시되면 리포지토리를 신뢰합니다. **Interactive** 모드인지 확인하고 `/model`로 사용 가능한 모델을 살펴보거나 **Auto**를 선택합니다. 도구 승인 요청이 표시되면 검토합니다.
+
+## 변경 요청
+
+다음 프롬프트를 보냅니다.
+
+```plaintext
+게임 카드에 각 게임의 별점을 표시해 주십시오. Game 타입에는 이미 starRating 필드가 있습니다. 5점 만점의 숫자이며 아직 평가되지 않은 게임은 null입니다. src/components/GameCard.astro의 각 카드에 표시하고, starRating이 null이면 대신 "No rating yet"을 표시해 주십시오. 변경을 작게 유지하고 카드 레이아웃을 재구성하지 마십시오.
+
+리포지토리 지침을 살펴보고 따라 주십시오. 기존 데이터 모델을 사용하고 별점 API, 새 스키마, 관련 없는 기능을 추가하지 마십시오. 평가된 경우와 미평가 경우에 적절한 테스트를 추가하거나 업데이트해 주십시오. 아직 커밋, 푸시, 끌어오기 요청 생성을 하지 마십시오.
+```
+
+Copilot은 편집 전에 기존 타입과 컴포넌트를 확인해야 합니다. 최종 응답뿐 아니라 도구 작업도 읽습니다. 자신감 있는 요약이 구현의 정확성을 증명하지는 않습니다.
+
+## 검토 및 검증
+
+1. `/diff`를 입력하고 편집기나 diff 보기에서 변경된 파일을 모두 확인합니다.
+2. 카드가 기존 `starRating`을 사용하고, 5점 만점의 값을 표시하며, `null`이면 `No rating yet`을 표시하는지 확인합니다. 참·거짓 변환만으로 검사하면 숫자 0을 미평가로 잘못 처리할 수 있습니다.
+3. 카드 레이아웃을 유지하고, 별 기호나 색상만이 아니라 의미 있는 텍스트 레이블로 별점을 전달하는지 확인합니다.
+4. 기존 검사로 변경을 검증하도록 Copilot에 요청합니다.
+
+ ```plaintext
+ package.json과 테스트 설정을 살펴본 다음, 이 카드 변경에 적합한 lint, 타입 검사, 기존 단위 또는 E2E 테스트를 실행해 주십시오. 숫자 별점과 null 대체 표시를 모두 검증하고, 누락된 커버리지나 차단된 검사도 포함하여 정확한 명령과 결과를 보고해 주십시오. 설치하거나 브랜치를 변경하거나 커밋, 푸시, PR 생성을 하지 마십시오.
+ ```
+
+5. 명령 출력과 테스트 변경을 검토합니다. 제공 전에 실패를 해결하고, 누락된 필수 조건을 설치하기 전에 질문합니다.
+
+브라우저에서 카드를 관찰하려면 같은 체크아웃에서 두 번째 터미널을 열고 실행합니다.
+
+```bash
+npm run dev
+```
+
+코드스페이스의 **Ports** 패널에서 전달된 포트를 엽니다. 홈 페이지에서 평가된 카드를 확인합니다. 현재 시드 데이터에 미평가 예제가 없다면 `null`을 검증하는 자동 테스트 픽스처(Fixture)를 요구합니다. 미평가 카드를 관찰했다고 주장하지 않습니다. E2E 검사 전이나 연습을 마치기 전에 개발 서버 터미널에서 Ctrl+C로 서버를 중지합니다. Playwright 자동 테스트가 다른 체크아웃의 서버를 재사용해서는 안 됩니다.
+
+## PR 1 생성 및 병합
+
+변경 검토와 검사 통과 후 이 마일스톤을 별도로 승인합니다.
+
+```plaintext
+현재 diff와 검사 결과를 검토해 주십시오. 검토한 별점 변경과 테스트만 커밋하고 현재 브랜치를 푸시한 후 main을 대상으로 끌어오기 요청을 만들어 주십시오. 리포지토리에 PR 템플릿이 있다면 사용해 주십시오. 변경 요약과 실제 검증 결과를 포함해 주십시오. PR을 병합하거나 다른 작업을 시작하지 마십시오.
+```
+
+반환된 PR URL을 엽니다. 에이전트 요약뿐 아니라 **Files changed**와 검사 결과를 확인합니다. CI를 해석할 때는 Tailspin 리포지토리의 워크플로 정의를 검토합니다. CI는 브라우저 관찰을 대체하지 않습니다. 실패를 해결하고 변경된 코드를 재검증합니다.
+
+PR이 리포지토리의 검토 및 검사 요구 사항을 충족하면 **Merge pull request**를 선택하고 GitHub에서 병합을 확정합니다. 브랜치 보호에 따라 다른 검토자가 필요하면 승인을 기다립니다. 진행 전에 PR이 **Merged**인지 확인합니다.
+
+`/exit`로 Copilot 세션을 종료합니다. 다음 연습에서는 지침 브랜치를 만들기 전에 로컬 `main`을 업데이트합니다. 병합되지 않은 이 기능 브랜치에서 시작하지 않습니다.
+
+## 요약 및 다음 단계
+
+범위가 제한된 프롬프트, 코드 검토, 검증 근거, PR 병합이라는 첫 주기를 완료했습니다. 다음에는 [사용자 지정 지침으로 Copilot을 안내하고][next-lesson], 두 번째 작은 PR에서 문서화 규칙을 실증합니다.
+
+[previous-lesson]: ../1-install-copilot-cli/
+[next-lesson]: ../3-custom-instructions/
diff --git a/docs/ko-kr/cli/2-custom-instructions.md b/docs/ko-kr/cli/2-custom-instructions.md
deleted file mode 100644
index 6603b934..00000000
--- a/docs/ko-kr/cli/2-custom-instructions.md
+++ /dev/null
@@ -1,241 +0,0 @@
----
-title: "연습 2 - 커스텀 지침(Copilot CLI)"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-[← 이전 연습: Copilot CLI 설치][previous-lesson] · [다음 연습: CLI로 코드 생성하기 →][next-lesson]
-
-생성형 AI로 작업할 때는 컨텍스트가 핵심입니다. 작업을 특정 방식으로 수행해야 하거나 Copilot이 알아야 할 배경 정보가 있다면, 그 컨텍스트를 사용할 수 있게 해야 합니다. Copilot을 돕는 여러 도구가 있으며, 이 워크숍 전반에서 이를 살펴봅니다. 먼저 [instruction files][instruction-files]부터 시작합니다. Instruction files는 일반적으로 코드 자체를 어떻게 구성해야 하는지에 초점을 맞춥니다. 이를 통해 Copilot은 원하는 코드가 *무엇인지*뿐 아니라 *어떻게* 구조화되어야 하는지도 이해할 수 있습니다.
-
-이 연습에서는 다음을 수행합니다.
-
-- 리포지토리 커스텀 지침과 경로 범위 지침 파일을 통해 프로젝트별 컨텍스트, 코딩 가이드라인, 문서화 표준이 Copilot에 전달되는 방식을 살펴봅니다.
-- 현재 지침이 적용된 상태에서 필터링을 위한 첫 번째 데이터 조각인 publishers helper를 생성합니다.
-- `.github/copilot-instructions.md`에 새로운 리포지토리 전체 표준을 추가합니다.
-- 후속 프롬프트를 실행하고 재생성된 코드가 새 표준을 따르는 모습을 확인합니다.
-- 다음 연습에서 이어서 사용할 수 있도록 지침 업데이트와 helper를 커밋합니다.
-
-> [!CAUTION]
-> 생성된 코드는 설정한 표준 일부와 다를 수 있습니다. Copilot은 비결정적입니다. 목표는 출력이 문자 단위로 완전히 일치하는 것이 아니라, 지침을 업데이트한 뒤 동작 경향이 어떻게 바뀌는지 확인하는 것입니다.
-
-## 지침 파일
-
-### 시나리오
-
-훌륭한 개발 조직답게 Tailspin Toys에는 개발 관행에 대한 가이드라인과 요구 사항이 있습니다. 여기에는 다음이 포함됩니다.
-
-- 데이터 계층에는 항상 단위 테스트가 필요합니다.
-- UI는 dark mode여야 하며 현대적인 느낌을 제공해야 합니다.
-- 코드 문서는 TSDoc doc comments 형태로 추가해야 합니다.
-- 각 파일의 맨 앞에는 파일의 역할을 설명하는 주석 블록을 추가해야 합니다.
-
-Instruction files를 사용하면 Copilot이 이러한 관행에 맞춰 작업을 수행하는 데 필요한 정보를 갖추도록 할 수 있습니다.
-
-### 커스텀 지침
-
-커스텀 지침을 사용하면 Copilot에 컨텍스트와 선호 사항을 제공하여 코딩 스타일과 요구 사항을 더 잘 이해하도록 도울 수 있습니다. 이 기능은 더 관련성 높은 제안과 코드 스니펫을 얻도록 Copilot의 방향을 조정하는 강력한 방법입니다. 선호하는 코딩 규칙, 라이브러리, 코드에 포함하고 싶은 주석 유형까지 지정할 수 있습니다. 전체 리포지토리에 대한 지침을 만들 수도 있고, 작업 수준 컨텍스트를 위해 특정 파일 형식에 대한 지침을 만들 수도 있습니다.
-
-지침 파일에는 두 가지 유형이 있습니다.
-
-- `.github/copilot-instructions.md`는 리포지토리에 대한 **모든** 요청에서 Copilot으로 전송되는 단일 지침 파일입니다. 이 파일에는 프로젝트 수준 정보, 즉 Copilot에 보내는 대부분의 채팅 또는 CLI 요청에 공통으로 관련된 컨텍스트를 담아야 합니다. 사용 중인 기술 스택, 빌드 중인 내용의 개요, 모범 사례, 기타 전역 가이드라인이 여기에 포함될 수 있습니다.
-- `.github/instructions/*.instructions.md` 파일은 특정 작업이나 파일 형식을 위해 만들 수 있습니다. TypeScript나 Astro 같은 특정 언어에 대한 지침을 제공하거나, UI 컴포넌트 또는 새로운 단위 테스트 세트 생성 같은 작업에 대한 지침을 제공할 수 있습니다.
-
-> [!NOTE]
-> IDE에서 작업할 때 지침 파일은 Copilot Chat의 코드 생성에만 사용되며, code completions나 next-edit suggestions에는 사용되지 않습니다.
->
-> Copilot Chat, Copilot CLI, Copilot cloud agent는 코드를 생성할 때 리포지토리 수준 지침과 `applyTo` front matter가 있는 `*.instructions.md` 파일을 모두 사용합니다.
->
-> 또한 Copilot은 AGENTS.md와 CLAUDE.md를 포함한 [다른 표준의 지침 파일도 지원합니다][custom-instructions-support].
-
-### 지침 파일 관리 모범 사례
-
-지침 파일을 만드는 방법 전체를 이 워크숍에서 모두 다루지는 않습니다. 하지만 샘플 프로젝트에 포함된 예시는 대표적인 접근 방식을 보여 줍니다. 높은 수준에서 보면 다음과 같습니다.
-
-- `copilot-instructions.md`의 지침은 빌드 중인 내용의 설명, 프로젝트 구조, 전역 코딩 표준처럼 프로젝트 수준 가이드에 집중합니다.
-- `*.instructions.md` 파일은 파일 형식(단위 테스트, Astro 컴포넌트, 데이터 계층)이나 특정 작업에 대한 구체적인 지침을 제공하는 데 사용합니다.
-- 자연어를 사용합니다. 가이드는 명확하게 유지합니다. 코드가 어떻게 보여야 하는지와 어떻게 보이면 안 되는지에 대한 예시를 제공합니다.
-
-AI를 사용하는 방법이 하나로 정해져 있지 않듯, 지침 파일을 만드는 방법도 하나로 정해져 있지 않습니다. 실험을 통해 프로젝트에 가장 잘 맞는 방식을 찾게 됩니다.
-
-> [!TIP]
-> GitHub Copilot을 사용하는 모든 프로젝트에는 탄탄한 instruction files 모음이 있어야 합니다. 이 프로젝트의 instruction files를 살펴보면 [UI 업데이트][ui-instructions]와 [Astro][astro-instructions]를 포함해 다양한 작업 유형에 대한 파일이 있다는 점을 확인할 수 있습니다.
->
-> Copilot은 instruction files 생성도 도와줄 수 있습니다. 각 표면마다 노출 방식은 다르지만(예: VS Code의 **Configure Chat → Generate Agent Instructions**, Copilot CLI의 `/init`) 관련이 있는 경우 현재 사용 중인 표면의 연습에서 이를 안내합니다.
->
-> 템플릿이나 시작점을 찾고 있나요? Instruction files, custom agents, 기타 리소스를 모아 둔 리포지토리인 [awesome-copilot][awesome-copilot]을 살펴봅니다.
-
-[ui-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/ui.instructions.md
-[astro-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/astro.instructions.md
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[custom-instructions-support]: https://docs.github.com/copilot/reference/custom-instructions-support
-## 이 프로젝트의 커스텀 지침 파일 살펴보기
-
-잠시 시간을 내어 이 리포지토리에 포함된 지침 파일을 읽어 봅니다. 핵심 `copilot-instructions.md` 하나와 다양한 작업을 위한 `*.instructions.md` 파일 모음이 있습니다. 편집기 또는 GitHub 웹 UI에서 열어 봅니다.
-
-1. `.github/copilot-instructions.md`를 엽니다.
-2. 파일을 살펴보면서 프로젝트의 간단한 설명과 **Agent notes**, **Code standards**, **Scripts**, **Repository Structure** 같은 섹션을 확인합니다. **Code standards** 아래에 중첩된 **GitHub Actions Workflows** 가이드가 있다는 점에 주목합니다. 이 내용은 Copilot과 상호 작용할 때 전반적으로 적용됩니다.
-3. `.github/instructions` 폴더를 열어 둘러봅니다. Astro 파일, Drizzle 데이터 계층, 테스트 등 다양한 지침이 있는지 확인합니다.
-4. `.github/instructions/unit-tests.instructions.md`를 엽니다. 상단의 `applyTo` 필드를 확인합니다. 이 필드는 지침이 적용될 파일을 결정하는 glob(리포지토리 루트 기준)을 설정합니다. 여기서는 모든 TypeScript test 파일(예: `**/*.test.ts`와 일치하는 파일)에 적용됩니다.
-5. 이 프로젝트에서 단위 테스트를 만들 때 적용되는 구체적인 지침을 확인합니다.
-6. 마지막으로 `.github/instructions/drizzle.instructions.md`를 열고 맨 아래로 스크롤합니다. 다른 지침 파일(`unit-tests.instructions.md` 등)과 프로젝트의 기존 파일에 대한 링크가 있는지 확인합니다. 이렇게 하면 더 큰 지침 세트를 더 작고 재사용 가능한 파일로 나눌 수 있고, 코드 생성 시 Copilot이 따를 예시를 가리킬 수 있습니다. (해당 경로는 리포지토리 루트가 아니라 지침 파일 기준 상대 경로입니다.)
-
-> [!NOTE]
-> `copilot-instructions.md`의 **Code formatting requirements** 섹션에는 프로젝트 코딩 표준이 문서화되어 있지만, 아직 코드 내부 문서화는 요구하지 않습니다. 다음 단계에서 TSDoc doc comments와 파일 주석 헤더에 대한 규칙을 추가합니다.
-
-## 브랜치 만들기
-
-코드를 변경할 예정이므로 작업용 브랜치를 만듭니다.
-
-1. 코드스페이스 터미널에서 새 브랜치를 만들고 전환합니다.
-
- ```bash
- git checkout -b update-custom-instructions
- ```
-
-2. Copilot CLI가 설치 및 인증되었는지 확인합니다.
-
- ```bash
- copilot --version
- ```
-
- 명령을 찾을 수 없거나 아직 로그인하지 않았다면 [연습 1 - GitHub Copilot CLI 설치](../1-install-copilot-cli/)로 돌아갑니다.
-
-## 지침을 업데이트하기 *전*에 Copilot CLI 사용하기
-
-커스텀 지침의 영향을 확인하려면 먼저 현재 지침이 적용된 상태에서 코드를 생성합니다. 이후 파일을 업데이트하고 후속 프롬프트를 실행합니다.
-
-> [!TIP]
-> **Copilot CLI 세션 시작하기**
->
-> 아래 연습을 시작하기 전에 코드스페이스로 돌아가 터미널을 엽니다(이미 열려 있지 않다면 Ctrl+`). 그런 다음 `--yolo`와 `--enable-all-github-mcp-tools`를 사용해 Copilot CLI를 시작합니다.
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 이 프로젝트의 가장 최근 세션을 새로 시작하지 않고 이어서 사용하려면 `copilot --yolo --enable-all-github-mcp-tools --continue`를 실행합니다. 이전 연습에서 Copilot CLI가 이미 실행 중이라면 `/clear`를 보내 새 대화를 시작합니다.
->
-> `--enable-all-github-mcp-tools`는 현재 세션에서 읽기/쓰기 GitHub MCP 도구를 활성화하므로, 워크숍 흐름 중 Copilot이 백로그를 읽고 pull request를 열 수 있습니다.
-
-> [!CAUTION]
-> `--yolo`는 전체 자동 권한(`--allow-all-tools`, `--allow-all-paths`, `--allow-all-urls`)을 활성화합니다. Codespace나 VM 같은 격리된 환경에서만 사용하고, 일상적인 개발을 위한 기본 별칭으로는 절대 설정하지 않습니다. 자세한 내용은 [Allowing and denying tool use][allow-all-warning]를 참고합니다.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. Copilot CLI 세션이 **repository root**에서 실행 중인지 확인합니다. 그래야 `.github/copilot-instructions.md`를 자동으로 불러옵니다.
-2. Copilot CLI 프롬프트에서 필터링 UI가 사용할 publishers helper를 생성해 달라고 요청합니다.
-
- ```plaintext
- Create a new data-access helper at src/lib/publishers.ts to return a list of all publishers. It should return the name and id for all publishers. Do not run the tests yet.
- ```
-
-3. Copilot CLI는 프로젝트를 탐색하고, 계획을 제안하고, 이 `--yolo` 세션에서 파일을 작성합니다. 터미널 출력의 변경 내용을 확인한 뒤 편집기에서 검토합니다.
-4. 편집기에서 생성된 `src/lib/publishers.ts`를 엽니다.
-5. helper가 첫 번째 인수로 `db` client를 받고, publisher의 typed array를 반환하는 typed function이라는 점을 확인합니다. 이는 `src/lib/*.ts`에 적용되는 `.github/instructions/drizzle.instructions.md`의 데이터 계층 규칙에서 비롯됩니다.
-6. 생성된 코드에 TSDoc doc comments와 파일 수준 주석 헤더가 **없다**는 점을 확인합니다.
-
-> [!CAUTION]
-> Copilot은 확률적으로 동작하므로, 지시하지 않았더라도 doc comments를 추가할 가능성이 있습니다. 그런 경우에도 괜찮습니다. 지침 업데이트 후 *일관성*이 향상되는 점이 핵심입니다.
-
-## 새로운 리포지토리 표준 추가하기
-
-앞서 설명했듯이 `.github/copilot-instructions.md`는 Copilot에 프로젝트 수준 정보를 제공하도록 설계되었습니다. 이제 리포지토리 코딩 표준을 문서화해 코드 제안을 개선해 보겠습니다.
-
-1. `.github/copilot-instructions.md`를 다시 엽니다.
-2. **Code formatting requirements** 섹션을 찾습니다. 대략 27번째 줄 근처에 있을 것입니다. 이 섹션이 프로젝트의 코딩 표준을 문서화하고 있지만, 아직 코드 내부 문서화 규칙이 없기 때문에 생성된 helper에 doc comments가 없었다는 점을 확인합니다.
-3. 기존 표준 바로 아래에 다음 markdown 줄을 추가해 Copilot이 파일 주석 헤더와 TSDoc doc comments를 넣도록 지시합니다.
-
- ```markdown
- - Every exported function should have a TSDoc comment describing its purpose, parameters, and return value.
- - Before imports or any code, add a comment block to the file that explains its purpose.
- ```
-
-4. `copilot-instructions.md`를 저장합니다.
-
-> [!TIP]
-> 이전 연습에서 본 것처럼 지침 파일은 전역 가이드를 위한 리포지토리 수준(`.github/copilot-instructions.md`)으로 만들 수도 있고, 특정 언어, 파일 형식, 작업을 위한 `*.instructions.md` 파일로 만들 수도 있습니다. 방금 추가한 doc comment 규칙처럼 프로젝트 전반에 적용되는 표준은 리포지토리 수준 파일에 두는 것이 적절합니다.
-
-## 프롬프트를 다시 실행하고 변화를 관찰하기
-
-이제 지침에 doc comment 규칙이 추가되었으므로 방금 생성한 publishers 파일을 Copilot CLI로 업데이트해 보겠습니다. 동일한 표준 지시가 다시 작성된 코드에도 적용됩니다.
-
-1. Copilot CLI 세션에서 `/clear`를 보내 새 대화를 시작합니다.
-2. 다음 프롬프트를 보냅니다.
-
- ```plaintext
- Update src/lib/publishers.ts to follow the latest documentation conventions in .github/copilot-instructions.md.
- ```
-
-3. 편집이 완료되면 `src/lib/publishers.ts`를 다시 엽니다.
-4. 이제 파일 맨 앞에 다음과 비슷한 주석 블록이 추가된 점을 확인합니다.
-
- ```typescript
- /**
- * Publisher data-access helpers for the Tailspin Toys Crowd Funding platform.
- * Provides functions to retrieve publisher information from the database.
- */
- ```
-
-5. 생성된 함수에 이제 다음과 비슷한 TSDoc doc comment가 포함된 점을 확인합니다.
-
- ```typescript
- /**
- * Returns a list of all publishers with their id and name.
- *
- * @param db - The Drizzle database client.
- * @returns A promise that resolves to an array of publisher objects.
- */
- ```
-
-6. 업데이트된 파일은 그대로 유지합니다. 다음 연습에서 이 파일을 기반으로 첫 번째 데이터 조각을 확장합니다.
-
-## 첫 번째 필터링 조각 커밋 및 푸시하기
-
-1. 터미널에서 변경된 파일을 확인합니다.
-
- ```bash
- git status
- ```
-
-2. 지침 업데이트와 helper를 stage합니다.
-
- ```bash
- git add .github/copilot-instructions.md src/lib/publishers.ts
- ```
-
-3. 변경 사항을 커밋합니다.
-
- ```bash
- git commit -m "Add doc comment standards and publishers helper foundation"
- ```
-
-4. 브랜치를 푸시합니다.
-
- ```bash
- git push -u origin update-custom-instructions
- ```
-
-## 요약 및 다음 단계
-
-이 프로젝트의 지침 파일을 통해 Copilot이 어떻게 컨텍스트를 받아들이는지 살펴본 다음, Copilot CLI를 사용해 다음을 수행했습니다.
-
-- 기존 지침을 바탕으로 필터링용 publishers data-access helper 기반을 생성했습니다.
-- `.github/copilot-instructions.md`에 새로운 리포지토리 전체 표준을 추가했습니다.
-- 후속 프롬프트를 실행하고 재생성된 코드가 새 표준을 따르는 모습을 확인했습니다.
-- 지침 업데이트와 helper 기반을 모두 커밋하고 푸시했습니다.
-
-다음으로는 [코드 생성 연습][next-lesson]에서 백로그 작업을 구현하면서 이 지침을 적용합니다.
-
-## 리소스
-
-- [GitHub Copilot 사용자 지정을 위한 instruction files][instruction-files]
-- [커스텀 지침 작성 모범 사례][instructions-best-practices]
-- [Copilot용 더 나은 커스텀 지침을 작성하는 5가지 팁][copilot-instructions-five-tips]
-- [Instruction files와 기타 리소스를 모아 둔 Awesome Copilot][awesome-copilot]
-
-[previous-lesson]: ../1-install-copilot-cli/
-[next-lesson]: ../3-generating-code/
-[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
-[instructions-best-practices]: https://docs.github.com/enterprise-cloud@latest/copilot/using-github-copilot/coding-agent/best-practices-for-using-copilot-to-work-on-tasks#adding-custom-instructions-to-your-repository
-[copilot-instructions-five-tips]: https://github.blog/ai-and-ml/github-copilot/5-tips-for-writing-better-custom-instructions-for-copilot/
diff --git a/docs/ko-kr/cli/3-custom-instructions.md b/docs/ko-kr/cli/3-custom-instructions.md
new file mode 100644
index 00000000..d2ca3feb
--- /dev/null
+++ b/docs/ko-kr/cli/3-custom-instructions.md
@@ -0,0 +1,109 @@
+---
+title: "연습 3 - 사용자 지정 지침으로 Copilot 안내"
+description: "범위를 좁힌 문서화 규칙을 추가하고 기존 코드에 적용하여 실증한 후 두 번째 끌어오기 요청을 병합합니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+컨텍스트는 Copilot이 *무엇을* 만들지뿐 아니라 팀이 *어떻게* 코드를 작성하기를 기대하는지도 이해하게 합니다. 범위를 좁힌 문서화 규칙을 추가하고 실제 코드에 미치는 효과를 확인한 후, 지침과 실증을 PR 2로 함께 병합합니다.
+
+이 연습에서는 다음을 수행합니다.
+
+- 리포지토리 전체 지침과 경로별 지침을 살펴봅니다.
+- 필터링을 미리 구현하지 않고 문서화 표준을 추가합니다.
+- 작은 기존 헬퍼나 컴포넌트에서 표준을 실증합니다.
+- 지침 마일스톤을 검증하고 병합합니다.
+
+## 지침 살펴보기
+
+리포지토리에는 이미 두 가지 유용한 지침이 있습니다.
+
+- `.github/copilot-instructions.md`는 기술 스택, 구조, 공통 관행 등 리포지토리 전체의 컨텍스트를 제공합니다.
+- `.github/instructions/*.instructions.md`는 특정 범위의 지침을 제공합니다. 프런트매터의 `applyTo` glob이 지침을 적용할 파일을 식별합니다.
+
+편집기에서 다음 파일을 엽니다.
+
+1. `.github/copilot-instructions.md`를 읽고 현재 코딩 및 검증 표준을 찾습니다.
+2. `.github/instructions/`에서 Astro, 데이터 계층, 테스트 지침을 살펴봅니다.
+3. `unit-tests.instructions.md`에서 `applyTo` 패턴과 테스트 규칙을 확인합니다.
+4. `drizzle.instructions.md`에서 데이터 접근 패턴과 예제 참조를 확인합니다.
+
+리포지토리 전체 지침은 간결하게 유지하고, 파일별 세부 사항은 해당 범위의 파일에 두며, 같은 규칙의 상충하는 복사본을 피합니다. [GitHub 지침 지원 참조][instruction-support]에서 각 환경이 지원하는 지침 형식을 설명합니다.
+
+> [!NOTE]
+> 지침은 생성에 영향을 주지만 준수를 보장하지 않습니다. 지침 내용과 코드에 미치는 효과를 모두 검토합니다. Copilot이 이미 좋은 주석을 작성한다면, 이 연습은 규칙을 명시적이고 반복 가능하게 만드는 과정입니다. 변경 전후의 실패를 억지로 만드는 과정이 아닙니다.
+
+## 병합된 PR 1에서 시작
+
+별점 PR이 병합되었는지 확인합니다. 학습용 리포지토리 터미널에서 업데이트된 `main`을 기반으로 다음 마일스톤을 시작합니다.
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c update-custom-instructions
+copilot --enable-all-github-mcp-tools
+```
+
+작업 트리에 미커밋 변경이 있거나 pull이 실패하면 해당 상태를 해결한 후 계속합니다. **Interactive** 모드를 유지합니다.
+
+리포지토리의 **Issues** 탭에서 **Update our repository coding standards**를 찾아 실제 URL을 복사합니다. 이 이슈는 의도를 설명하고, 내보낸 데이터 계층 함수와 컴포넌트 계약을 문서화하며, 주석을 최신 상태로 유지하는 넓은 맥락을 제공합니다. 이 연습은 문서화의 제한된 일부를 다루며, 리포지토리 전체 리팩터링이나 이슈의 모든 기준을 완료하겠다는 약속이 아닙니다.
+
+## 문서화 규칙 추가
+
+플레이스홀더를 실제 이슈 URL로 바꾸고 보냅니다.
+
+```plaintext
+컨텍스트를 위해 다음 코딩 표준 이슈를 읽어 주십시오: . 기존 리포지토리 전체 지침과 범위별 지침을 살펴봐 주십시오. 범위를 좁힌 문서화 규칙을 추가해 주십시오. 코드를 반복하지 말고 의도를 설명하고, db/와 src/lib/에서 내보낸 함수의 목적·매개변수·반환값을 TSDoc/JSDoc으로 문서화하고, 재사용 가능한 Astro 컴포넌트의 Props 계약을 문서화하며, 관련 코드가 바뀔 때 주석도 최신 상태로 유지하도록 해 주십시오.
+
+각 규칙을 적절한 기존 지침 파일에 두고 중복이나 모순을 피해 주십시오. 기존 포맷 및 lint 표준을 유지하고, 적절한 경우 README에 문서화 규칙을 링크하거나 요약해 주십시오. 변경을 문서화 표준으로 제한하고 포맷 도구를 이전하거나 리포지토리 전체를 다시 작성하지 마십시오. 스킬이나 에이전트를 만들거나 필터링을 구현하거나 커밋, 푸시, PR 생성을 하지 마십시오. 실증 전에 지침을 검토할 수 있도록 중단해 주십시오.
+```
+
+diff를 확인합니다. 규칙은 유용한 주석을 장려해야 하며, 모든 파일에 상용구 헤더를 요구하거나 명백한 코드를 반복하는 주석을 요구해서는 안 됩니다. 진행 전에 수정을 요청합니다.
+
+## 실제 코드에서 규칙 실증
+
+리포지토리를 살펴본 후 작은 기존 내보낸 헬퍼나 재사용 가능한 컴포넌트를 선택합니다. 퍼블리셔 헬퍼일 필요는 없으며, `src/lib/publishers.ts`가 이미 존재해야 한다는 요구 사항도 없습니다.
+
+다음을 보냅니다.
+
+```plaintext
+업데이트된 지침을 사용하여 더 명확한 문서화가 도움이 될 작은 기존 내보낸 헬퍼 또는 재사용 가능한 Astro 컴포넌트를 하나 선택해 주십시오. 런타임 동작을 바꾸거나 필터링 기능을 추가하지 않고 해당 파일에 규칙을 직접 적용해 주십시오. 어떤 지침이 변경을 이끌었는지 설명하고 커밋이나 PR 생성 전에 중단해 주십시오.
+```
+
+실제로 변경된 파일을 엽니다. 헬퍼라면 주석이 매개변수, 반환값, 주입되는 데이터베이스 인수를 정확히 설명하는지 확인합니다. 컴포넌트라면 `Props` 계약이 문서화되었는지 확인합니다. 주석 블록 유무만 보지 말고 설명과 코드가 일치하는지 확인합니다.
+
+> [!TIP]
+> 채팅의 예시 코드 조각은 실증이 아닙니다. 실제 리포지토리 변경을 확인합니다. 선택한 코드가 이미 규칙을 충족한다면 중복 주석을 추가하지 말고 개선할 이유가 있는 다른 작은 기존 대상을 선택합니다.
+
+## PR 2 검증 및 병합
+
+검토한 변경을 검증하도록 Copilot에 요청합니다.
+
+```plaintext
+지침 변경과 작은 문서화 실증을 검토해 주십시오. 런타임 동작이 바뀌지 않았는지 확인해 주십시오. package.json을 확인하고 npm run lint와 npm run typecheck:all을 실행하며, 코드 변경상 필요한 경우 영향을 받는 기존 테스트도 실행해 주십시오. 정확한 명령과 결과를 보고해 주십시오. 아직 설치하거나 스킬을 만들거나 커밋, 푸시, PR 생성을 하지 마십시오.
+```
+
+실패를 해결하고 최종 diff를 확인합니다. 그런 다음 마일스톤을 승인합니다.
+
+```plaintext
+검토한 문서화 지침, 직접 관련된 README 업데이트, 작은 코드 실증만 커밋해 주십시오. 현재 브랜치를 푸시하고 리포지토리 PR 템플릿에 따라 main을 대상으로 PR을 만들어 주십시오. 검증 결과를 포함하고 코딩 표준 이슈에 대한 부분적 기여로 참조해 주십시오. 모든 이슈 기준을 실제로 충족하지 않았다면 이슈 종료 키워드를 사용하지 마십시오. 병합하거나 필터링을 시작하지 마십시오.
+```
+
+PR URL을 열고 **Files changed**와 CI를 검토합니다. 필수 검사와 검토가 모두 통과한 후 GitHub에서 병합하고 PR 2가 **Merged**인지 확인합니다. `/exit`로 CLI 세션을 종료합니다. 이 PR이 병합되기 전에는 다음 마일스톤을 시작하지 않습니다.
+
+## 요약 및 다음 단계
+
+문서화 규칙과 실제 실증이 이제 `main`에 있습니다. 다음에는 병합된 상태를 기반으로 새 브랜치를 만들어 [Plan과 Autopilot으로 필터링을 구축합니다][next-lesson].
+
+## 리소스
+
+- [리포지토리 사용자 지정 지침 추가][repository-instructions]에서는 리포지토리 전체와 경로별 지침을 설명합니다.
+- [Awesome Copilot][awesome-copilot]의 예제는 무조건 채택하지 말고 검토하고 조정하여 사용합니다.
+
+[previous-lesson]: ../2-add-star-rating/
+[next-lesson]: ../4-build-filtering/
+[instruction-support]: https://docs.github.com/copilot/reference/custom-instructions-support
+[repository-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
+[awesome-copilot]: https://github.com/github/awesome-copilot
diff --git a/docs/ko-kr/cli/3-generating-code.md b/docs/ko-kr/cli/3-generating-code.md
deleted file mode 100644
index 4dfa4c62..00000000
--- a/docs/ko-kr/cli/3-generating-code.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: "연습 3 - GitHub Copilot CLI로 프로젝트 기능 추가하기"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-예상할 수 있듯이 GitHub Copilot CLI로 수행하는 핵심 작업은 프로젝트에 기능, 동작, 코드를 추가하는 일입니다. 이제 백로그의 issue 중 하나를 가져와 Copilot이 구현을 도와주도록 해보겠습니다.
-
-## 시나리오
-
-이제 프로젝트의 필터링 작업을 마무리할 차례입니다. 백로그에는 이미 필터링 issue가 있고, 이전 연습에서 foundation helper도 만들었습니다. Copilot이 issue 세부 정보를 가져오고, 기존 작업을 고려한 뒤, 남은 기능을 구현하도록 해보겠습니다.
-
-이 연습에서는 다음을 수행합니다.
-
-- Plan mode를 사용해 필터링 기능 구현 계획을 생성합니다.
-- Copilot으로 웹 사이트에 필터링을 추가하는 데 필요한 코드를 생성합니다.
-
-이 연습이 끝나면 프로젝트에 새로운 기능이 추가됩니다.
-
-## Plan mode 활용하기
-
-AI의 가장 뛰어난 활용 방식 중 하나는 계획 수립입니다. 무엇을 만들고 싶은지 대략적인 개념은 있지만 아이디어를 정리할 대상이 필요할 때가 많습니다. AI 도구는 후속 질문을 하고, 빠진 구성 요소나 잠재적인 함정을 함께 검토하면서 생각을 구체화하도록 도와줍니다. Copilot CLI는 이 과정을 지원하기 위해 plan mode를 제공합니다. 또한 계획 수립에 들인 시간은 Copilot이 요구 사항에 더 잘 맞는 코드를 생성하는 데 도움이 됩니다.
-
-Copilot CLI의 plan mode를 사용해 새 기능 생성 과정을 시작합니다.
-
-> [!TIP]
-> **Copilot CLI 세션 시작하기**
->
-> 아래 연습을 시작하기 전에 코드스페이스로 돌아가 터미널을 엽니다(이미 열려 있지 않다면 Ctrl+`). 그런 다음 `--yolo`와 `--enable-all-github-mcp-tools`를 사용해 Copilot CLI를 시작합니다.
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 이 프로젝트의 가장 최근 세션을 새로 시작하지 않고 이어서 사용하려면 `copilot --yolo --enable-all-github-mcp-tools --continue`를 실행합니다. 이전 연습에서 Copilot CLI가 이미 실행 중이라면 `/clear`를 보내 새 대화를 시작합니다.
->
-> `--enable-all-github-mcp-tools`는 현재 세션에서 읽기/쓰기 GitHub MCP 도구를 활성화하므로, 워크숍 흐름 중 Copilot이 백로그를 읽고 pull request를 열 수 있습니다.
-
-> [!CAUTION]
-> `--yolo`는 전체 자동 권한(`--allow-all-tools`, `--allow-all-paths`, `--allow-all-urls`)을 활성화합니다. Codespace나 VM 같은 격리된 환경에서만 사용하고, 일상적인 개발을 위한 기본 별칭으로는 절대 설정하지 않습니다. 자세한 내용은 [Allowing and denying tool use][allow-all-warning]를 참고합니다.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. Copilot CLI에 다음 프롬프트를 입력해 필터링 issue를 바탕으로 계획을 생성합니다.
-
- ```
- /plan Retrieve the issue on the repository related to adding filtering. We already added a publishers helper in src/lib/publishers.ts, so treat that as existing work and plan the remaining updates (games filtering logic, UI, and tests).
- ```
-
-2. Copilot이 계획을 세우는 동안 후속 질문을 할 수 있습니다. 질문이 나오면 원하는 구현 방식에 맞게 답변합니다.
-3. 계획이 생성되면 설계 청사진을 검토합니다. 데이터 계층과 UI 전반의 남은 변경 사항, 그리고 테스트 생성이 권장되는 것을 확인할 수 있습니다.
-4. Copilot CLI는 계획에 대한 추가 피드백을 제공할 수 있는 기능도 제공합니다. 안내된 영역으로 커서를 이동한 뒤 제안을 입력하면 Copilot이 이를 반영한 새 버전의 계획을 제시합니다.
-5. 계획이 만족스럽다면 Copilot이 제공하는 옵션을 선택해 새 기능 구현을 시작합니다.
-
-> [!NOTE]
-> Copilot은 확률적으로 동작하므로, 정확한 텍스트와 제공되는 옵션은 달라질 수 있습니다. 하지만 구현을 시작하는 옵션이 표시되며 대체로 다음과 비슷한 문구를 보게 됩니다.
->
-> `Yes, and switch to autopilot mode`.
->
-> Copilot은 위 예시처럼 [autopilot mode](https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot)를 활성화하는 옵션을 제안할 수 있습니다. Autopilot mode를 사용하면 Copilot CLI가 각 단계마다 입력을 기다리지 않고 작업을 진행합니다. 처음 지시를 주면 Copilot CLI가 작업이 완료되었다고 판단할 때까지 각 단계를 자율적으로 처리합니다. 현재는 격리된 환경에서 작업하므로 autopilot을 실행하고 모든 도구를 허용해도 괜찮습니다.
-
-6. Copilot이 파일 생성을 시작합니다.
-
-> [!NOTE]
-> 이 작업은 몇 분 정도 걸릴 수 있습니다. Copilot이 파일을 수정하고 생성하며, 테스트를 업데이트 및 생성하고, 모든 테스트를 실행해 성공 여부를 확인하는 모습을 보게 됩니다. 지금까지 살펴본 내용을 되돌아보거나 잠시 음료를 즐기기 좋은 시간입니다.
-
-## 코드 검토하기
-
-AI가 생성한 코드는 운영 환경에 병합하기 전에 반드시 검토해야 합니다. 이제 Copilot이 기능 구현 과정에서 생성하거나 수정한 파일을 살펴보겠습니다.
-
-1. Copilot CLI에서 다음 명령을 사용해 "diff" 또는 코드 변경 사항을 표시합니다.
-
- ```
- /diff
- ```
-
-2. 변경된 파일을 확인합니다. 화살표 키로 좌우 이동하면서 서로 다른 파일을 볼 수 있습니다. 새 필터 컨트롤과 클라이언트 측 필터링이 들어간 게임 목록 페이지, `src/lib/games.ts`, `games.test.ts` 같은 테스트 파일이 업데이트된 것을 확인할 수 있습니다. Copilot이 전체 구현에 맞춰 기존 helper를 조정했다면 `publishers.ts`가 수정된 경우도 있을 수 있습니다.
-
-## 요약 및 다음 단계
-
-이제 Copilot CLI의 도움으로 웹 사이트에 필터링 기능을 추가했습니다. 구체적으로 다음을 수행했습니다.
-
-- Plan mode를 사용해 필터링 기능 구현 계획을 생성했습니다.
-- Copilot을 사용해 웹 사이트에 필터링을 추가하는 데 필요한 코드를 생성했습니다.
-
-물론 다음 단계는 실제로 동작하는지 확인하는 것입니다. Pull request를 열기 전에 [Playwright MCP server로 기능 테스트하기][next-lesson]로 이동해 검증해 보겠습니다.
-
-## 리소스
-
-- [Copilot CLI 사용하기][using-copilot-cli]
-- [Copilot CLI 소개][about-copilot-cli]
-- [Copilot CLI의 컨텍스트 관리][context-management]
-
-[previous-lesson]: ../2-custom-instructions/
-[next-lesson]: ../4-mcp/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
diff --git a/docs/ko-kr/cli/4-build-filtering.md b/docs/ko-kr/cli/4-build-filtering.md
new file mode 100644
index 00000000..759e0f43
--- /dev/null
+++ b/docs/ko-kr/cli/4-build-filtering.md
@@ -0,0 +1,102 @@
+---
+title: "연습 4 - Plan과 Autopilot으로 필터링 구축"
+description: "필터링 요구 사항에 합의하고 구현 계획을 승인한 후 코드를 검증하고 기능 브랜치에 체크포인트를 저장합니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+이제 사용자가 카테고리와 퍼블리셔로 게임을 필터링하는 더 큰 기능을 구축합니다. 코딩 전에 계획하고 **Autopilot**을 명시적으로 승인한 후 구현을 검토하고 테스트하며 체크포인트를 저장합니다. 이 연습에서는 스킬, QA 에이전트, 기능 PR을 만들지 않습니다.
+
+## 필터링 마일스톤 시작
+
+PR 1과 PR 2가 병합되었는지 확인합니다. 학습용 리포지토리 터미널에서 실행합니다.
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-game-filtering
+copilot --enable-all-github-mcp-tools
+```
+
+작업 트리에 미커밋 변경이 없고 `main`에서 성공적으로 업데이트한 경우에만 계속합니다. 연습 4~8은 동일한 브랜치와 체크아웃을 사용합니다. 이후 체크포인트 커밋에서 스킬과 QA 프로필을 추가합니다. 연습마다 브랜치를 만들지 않습니다.
+
+## 실제 이슈 가져오기
+
+리포지토리의 **Issues** 탭에서 **Allow users to filter games by category and publisher**를 찾아 URL을 복사합니다. 템플릿의 파일명이나 이슈 번호로 자신의 복사본에서 이슈를 식별할 수 있다고 가정하지 않습니다.
+
+현재 이슈는 다음을 요구합니다.
+
+- 하나 이상의 카테고리를 선택합니다.
+- 퍼블리셔로 필터링하고 카테고리와 조합합니다.
+- 두 필터를 모두 지원하는 데이터 접근 헬퍼를 `src/lib/`에 둡니다.
+- 키보드 탐색, 적절한 ARIA, 보이는 포커스 상태, `data-testid` 속성을 갖춘 접근성 있는 컨트롤을 제공합니다.
+- 헬퍼는 Vitest 단위 테스트로, 필터링 동작은 Playwright E2E 테스트로 검증합니다.
+
+실제 이슈를 기준으로 읽습니다. 이슈 URL과 승인한 추가 합의 사항을 연습 7의 QA 프롬프트에서 사용할 수 있도록 보관합니다.
+
+## 코딩 전에 계획
+
+Shift+Tab으로 **Plan** 모드를 선택하거나 `/plan`으로 시작합니다. 이슈 플레이스홀더를 바꾸고 보냅니다.
+
+```plaintext
+다음 이슈에 설명된 필터링 기능을 계획해 주십시오: . 변경을 제안하기 전에 이슈, 리포지토리 지침, 기존 데이터 접근 헬퍼, UI, 테스트를 읽어 주십시오. 현재 체크아웃을 기준으로 삼고 퍼블리셔 헬퍼가 이미 만들어졌다고 가정하지 마십시오.
+
+여러 카테고리 선택, 퍼블리셔 필터링, 두 조건의 조합, 데이터 접근 지원, 접근성 있는 컨트롤, 단위/E2E 커버리지를 다뤄 주십시오. 여러 카테고리의 조합 방식, 필터 해제, 빈 결과 등 지정되지 않은 동작은 질문하고 승인된 계획과 함께 결정을 기록해 주십시오. 불필요한 서버 API를 도입하지 말고 정적 Astro 아키텍처를 유지해 주십시오.
+
+현재 브랜치에서 구현하도록 계획하고, 필요한 단위 및 E2E 테스트와 npm run lint, npm run test:unit, npm run test:e2e, npm run typecheck:all을 통한 검증을 포함해 주십시오. 먼저 필수 조건과 서버 소유권을 확인하고, 소프트웨어를 설치하거나 관련 없는 프로세스를 중지하지 말고 차단 요인을 보고해 주십시오.
+
+계획에 다음 실행 경계를 포함해 주십시오. 제가 승인한 후에는 필터링 기능과 필요한 테스트만 구현하고 검사를 실행한 다음 검토할 수 있도록 중단해 주십시오. quality-checks 스킬, QA 에이전트, 이후 워크숍에서 다룰 다른 자산을 만들지 마십시오. 브랜치를 변경하거나 커밋, 푸시, PR 생성 또는 병합을 하지 마십시오.
+
+제가 계획을 승인하기 전에는 애플리케이션 코드를 편집하거나 구현을 시작하지 마십시오.
+```
+
+후속 질문에 답합니다. 나중에 숨겨진 수락 기준을 추가하지 않습니다. 구현, 브라우저 검사, QA가 동일한 요구 사항을 사용할 수 있도록 합의한 답변을 이슈 URL과 함께 저장합니다.
+
+계획에서 데이터 계층 및 UI 변경, 테스트, 접근성 있는 컨트롤, 병합한 문서화 규칙을 검토합니다. 네 가지 검사 모두, 검토를 위한 중단 조건, 이후 워크숍 자산·브랜치 변경·커밋·푸시·PR 작업 금지가 명시되어 있는지 확인합니다. 제한이나 기준이 누락되었거나 이슈 범위 밖의 작업을 제안하면 승인 전에 수정을 요청합니다.
+
+## Autopilot 명시적 승인
+
+계획에 검토한 범위와 실행 경계가 포함된 후에만 계획 승인 옵션 **Accept plan and build on autopilot**을 사용합니다. 버전에 따라 문구가 다르면 **Autopilot**으로 전환하는 옵션을 명시적으로 선택하고 모드 표시를 확인합니다. 승인하면 범위가 제한된 계획의 실행이 시작됩니다. 작업 시작 후 프롬프트로 제한을 추가하는 방식에 의존하지 않습니다.
+
+> [!CAUTION]
+> Autopilot은 도구 권한뿐 아니라 작업의 지속을 제어합니다. 선택 전에 권한 대화 상자를 검토합니다. 전체 권한은 도구, 경로, URL 액세스를 허용하며, 제한된 권한은 승인이 필요한 작업을 차단할 수 있습니다. 코드스페이스가 비밀을 노출하거나 관련 없는 리소스를 변경해도 된다는 허가는 아닙니다. 건너뛴 검사를 통과로 처리하지 말고 차단된 액세스를 신중하게 해결합니다.
+
+작업과 명령 결과를 살펴봅니다. Autopilot은 계획을 완료하기 전에 연속 실행 한도에서 멈추거나 차단 요인을 보고할 수 있습니다. 동일한 범위를 유지하면서 상태를 검토한 후 계속하도록 승인합니다.
+
+## Interactive로 돌아와 검토
+
+구현이 멈추면 추가 프롬프트를 보내기 전에 Shift+Tab으로 **Interactive** 모드로 돌아옵니다. 작업 후에도 Autopilot이 활성 상태일 수 있습니다. 자동으로 전환되었다고 가정하지 않습니다.
+
+`/diff`를 입력하고 변경된 모든 파일을 확인합니다. 구현을 이슈 및 승인한 추가 합의 사항과 비교합니다.
+
+- 사용자가 합의한 대로 여러 카테고리를 선택하고 퍼블리셔로 필터링하며 두 조건을 조합할 수 있습니까?
+- 데이터 접근 헬퍼가 UI만 바꾸는 것이 아니라 실제로 필터를 지원합니까?
+- 컨트롤에 의미 있는 레이블, 키보드 지원, 보이는 포커스, 안정적인 테스트 식별자가 있습니까?
+- 기존 검증을 약화하지 않고 합의한 필터 해제 및 빈 결과를 포함해 테스트가 동작을 검증합니까?
+- 코드가 문서화 규칙을 따르고 정적 앱 아키텍처를 유지합니까?
+
+네 가지 npm 검사 모두의 근거를 검토합니다. 아직 `quality-checks`를 만들지 않았으므로 검사는 직접 실행합니다. Playwright E2E 설정은 빌드하고 미리 보기를 제공합니다. 오래된 콘텐츠를 재사용하지 않도록 스위트 실행 전에 직접 시작한 개발 서버만 중지합니다. 포트 충돌이나 브라우저 누락은 해결해야 할 차단 요인이며, 다른 프로세스를 종료하거나 통과를 주장할 이유가 아닙니다.
+
+필요하면 범위를 좁힌 수정을 요청하고 영향을 받는 검사를 다시 실행하여 최종 구현의 검증을 완료합니다. 직접 브라우저 관찰은 연습 6에서 수행하며, 이번 자동 검증과는 목적이 다릅니다.
+
+## 구현 체크포인트 저장
+
+diff와 결과에 문제가 없다면 로컬 체크포인트를 승인합니다.
+
+```plaintext
+현재 diff와 검증 결과를 검토해 주십시오. 검토한 필터링 구현과 테스트만 포함한 체크포인트 커밋을 만들어 주십시오. 현재 필터링 브랜치와 체크아웃을 유지해 주십시오. 아직 푸시하거나 PR을 생성하거나 스킬 또는 QA 에이전트를 만들지 마십시오.
+```
+
+테스트한 리비전을 기록하고 이슈 URL과 승인한 추가 합의 사항을 보관합니다. **Interactive**를 유지하고 동일한 체크아웃에서 [연습 5 - quality-checks 스킬 만들기 및 사용][next-lesson]을 계속합니다.
+
+## 리소스
+
+- [Autopilot 모드 및 권한][autopilot]에서는 자율적인 작업 지속과 Interactive로 돌아가는 방법을 설명합니다.
+- [Copilot CLI 명령 참조][cli-reference]에는 현재 모드 조작 방법과 명령이 나열되어 있습니다.
+
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
+[autopilot]: https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/ko-kr/cli/4-mcp.md b/docs/ko-kr/cli/4-mcp.md
deleted file mode 100644
index e696b6b8..00000000
--- a/docs/ko-kr/cli/4-mcp.md
+++ /dev/null
@@ -1,158 +0,0 @@
----
-title: "연습 4 - Playwright MCP server로 기능 테스트하기"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-방금 Copilot CLI로 필터링 기능을 생성했습니다. Pull request를 열기 전에 브라우저에서 실제로 동작하는지 확인해야 합니다. 직접 앱을 눌러 보며 확인하는 대신 **Playwright MCP server**를 연결해 Copilot이 실제 브라우저를 제어하면서 기능을 테스트하도록 해보겠습니다.
-
-이 연습에서는 다음을 수행합니다.
-
-- Model Context Protocol(MCP)이 무엇인지 이해하고, MCP server가 Copilot CLI를 어떻게 확장하는지 살펴봅니다.
-- Playwright MCP server를 Copilot CLI에 추가합니다.
-- 브라우저에서 필터링 기능을 수동 테스트하도록 Copilot에 요청합니다.
-
-## Model Context Protocol(MCP)이란 무엇인가요?
-
-[Model Context Protocol(MCP)](https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/)은 AI agent가 외부 도구 및 서비스와 통신할 수 있는 방법을 제공합니다. MCP를 사용하면 AI agent는 외부 도구와 서비스를 실시간으로 사용할 수 있습니다. 이를 통해 최신 정보에 접근하고(resources 사용), 작업을 대신 수행하도록(tools 사용) 할 수 있습니다.
-
-이러한 도구와 리소스는 MCP server를 통해 접근합니다. MCP server는 AI agent와 외부 도구 및 서비스 사이의 브리지 역할을 합니다. MCP server는 AI agent와 외부 도구(기존 API 또는 NPM package 같은 로컬 도구 등) 간의 통신을 관리합니다. 각 MCP server는 AI agent가 접근할 수 있는 서로 다른 도구와 리소스 집합을 나타냅니다.
-
-널리 사용되는 MCP server 예시는 다음과 같습니다.
-
-- **[GitHub MCP Server](https://github.com/github/github-mcp-server)**: GitHub 리포지토리를 관리하기 위한 API 집합에 접근할 수 있게 해줍니다. 새 리포지토리 생성, 기존 리포지토리 업데이트, issue 및 pull request 관리 같은 작업을 AI agent가 수행할 수 있습니다.
-- **[Playwright MCP Server](https://github.com/microsoft/playwright-mcp)**: Playwright를 사용한 브라우저 자동화 기능을 제공합니다. 웹 페이지 탐색, 양식 입력, 버튼 선택 같은 작업을 AI agent가 수행할 수 있습니다.
-
-서로 다른 도구와 리소스에 접근할 수 있게 해주는 다른 MCP server도 많이 있습니다. GitHub는 검색성과 생태계 기여를 높이기 위해 [MCP registry](https://github.com/mcp)를 제공합니다.
-
-> [!CAUTION]
-> 보안 측면에서 MCP server는 프로젝트의 다른 dependency와 동일하게 취급해야 합니다. MCP server를 사용하기 전에 소스 코드를 신중히 검토하고, 게시자를 확인하며, 보안 영향을 고려합니다. 신뢰할 수 있는 MCP server만 사용하고, 민감한 리소스나 작업에 대한 액세스를 부여할 때는 특히 주의합니다.
-
-> [!NOTE]
-> [GitHub MCP server][github-mcp-server]는 Copilot CLI에 **기본 내장**되어 있습니다. 별도 설정 없이 바로 사용할 수 있으며, 워크숍 전반에서 Copilot이 리포지토리를 읽고 쓰고 있었던 것도 이 서버 덕분입니다. 이 연습에서는 Copilot에 브라우저를 제공하기 위해 두 번째 서버인 Playwright를 추가합니다.
-
-## Playwright MCP server 추가하기
-
-서버를 추가하는 가장 빠른 방법은 대화형 `/mcp add` 명령입니다. Copilot이 제어할 수 있는 브라우저를 제공하는 [Playwright MCP server][playwright-mcp-server]를 등록합니다.
-
-> [!TIP]
-> **Copilot CLI 세션 시작하기**
->
-> 아래 연습을 시작하기 전에 코드스페이스로 돌아가 터미널을 엽니다(이미 열려 있지 않다면 Ctrl+`). 그런 다음 `--yolo`와 `--enable-all-github-mcp-tools`를 사용해 Copilot CLI를 시작합니다.
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 이 프로젝트의 가장 최근 세션을 새로 시작하지 않고 이어서 사용하려면 `copilot --yolo --enable-all-github-mcp-tools --continue`를 실행합니다. 이전 연습에서 Copilot CLI가 이미 실행 중이라면 `/clear`를 보내 새 대화를 시작합니다.
->
-> `--enable-all-github-mcp-tools`는 현재 세션에서 읽기/쓰기 GitHub MCP 도구를 활성화하므로, 워크숍 흐름 중 Copilot이 백로그를 읽고 pull request를 열 수 있습니다.
-
-> [!CAUTION]
-> `--yolo`는 전체 자동 권한(`--allow-all-tools`, `--allow-all-paths`, `--allow-all-urls`)을 활성화합니다. Codespace나 VM 같은 격리된 환경에서만 사용하고, 일상적인 개발을 위한 기본 별칭으로는 절대 설정하지 않습니다. 자세한 내용은 [Allowing and denying tool use][allow-all-warning]를 참고합니다.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. Copilot CLI 세션에서 다음을 입력합니다.
-
- ```text
- /mcp add
- ```
-
-2. 구성 양식이 나타나면 Tab으로 필드 사이를 이동하면서 다음과 같이 입력합니다.
-
- - **Server Name**: `playwright`
- - **Server Type**: **Local**(또는 **STDIO**로 표시됨)을 선택합니다.
- - **Command**: `npx @playwright/mcp@latest --headless`
- - **Tools**: 서버의 모든 도구를 허용하기 위해 `*` 그대로 둡니다.
-
-3. Ctrl+S를 눌러 저장합니다. 서버가 추가되고 즉시 사용할 수 있습니다. 재시작은 필요하지 않습니다.
-
-`--headless` 플래그는 Playwright가 표시 창 없이 브라우저를 실행하도록 지정합니다. 데스크톱을 표시할 수 없는 코드스페이스 안에서는 이 설정이 필요합니다. 내부적으로는 다음 내용이 `~/.copilot/mcp-config.json` 파일에 기록됩니다.
-
-```json
-{
- "mcpServers": {
- "playwright": {
- "type": "local",
- "command": "npx",
- "args": ["@playwright/mcp@latest", "--headless"],
- "tools": ["*"]
- }
- }
-}
-```
-
-4. MCP server 목록을 확인해 서버가 등록되어 활성 상태인지 검증합니다.
-
- ```text
- /mcp show
- ```
-
-5. 기본 제공 `github` server와 함께 `playwright`가 표시되어야 합니다.
-
-> [!NOTE]
-> Tailspin Toys 프로젝트는 이미 end-to-end 테스트에 Playwright를 사용하므로, Playwright에 필요한 브라우저가 대체로 이미 설치되어 있습니다. 나중에 Copilot이 브라우저가 없다고 보고하면 `npx playwright install chromium`를 실행하도록 요청한 뒤 다시 시도합니다.
-
-## 웹 사이트 시작하기
-
-Playwright MCP server가 테스트를 수행하려면 실행 중인 앱이 필요합니다. Copilot CLI에서 작업하는 동안 계속 실행되도록 **별도의** 터미널에서 Astro dev server를 시작합니다.
-
-1. Ctrl+`를 선택해 코드스페이스에서 새 터미널을 엽니다.
-2. 웹 사이트를 시작합니다.
-
- ```bash
- npm run dev
- ```
-
-3. 이 터미널은 계속 실행된 상태로 둡니다. `Astro server: http://localhost:4321` 배너가 표시되면 앱이 준비된 것입니다.
-
-## 필터링 기능 테스트하기
-
-Copilot CLI 세션으로 돌아가 Copilot에 기능 테스트를 요청합니다.
-
-[Playwright MCP server][playwright-mcp-server]는 Copilot이 실제 브라우저를 제어할 수 있게 해줍니다. 직접 앱을 눌러 보며 작업을 확인하는 대신, agent가 페이지를 열고, 탐색하고, 필터를 적용하고, 결과를 다시 읽어 준 다음, 본 내용을 요약할 수 있습니다. 대화를 벗어나지 않고 기능이 기대대로 동작하는지 확인하는 가장 빠른 방법입니다.
-
-내부적으로 Playwright MCP server는 스크린샷이 아니라 페이지의 [accessibility tree][playwright-mcp-server]를 기반으로 동작합니다. 즉, agent는 보조 기술이 처리하는 방식과 유사하게 구조화되고 레이블이 지정된 요소(버튼, 링크, 목록 항목)를 기준으로 추론합니다. 따라서 빠른 기능 점검이 가벼운 접근성 sanity check 역할도 함께 합니다.
-
-서버가 연결되고 앱이 실행 중인 상태에서 Copilot에게 방금 만든 필터링 기능을 검증해 달라고 요청합니다.
-
-```text
-Using the Playwright MCP server, open a browser to the running app at http://localhost:4321 and verify the new game filtering feature:
-
-1. Go to the games page and note how many games are listed.
-2. Apply a category filter and confirm the list updates to only show games in that category.
-3. Clear it, then apply a publisher filter and confirm the list updates to that publisher.
-4. Combine a category and a publisher filter and confirm the results respect both.
-
-Report what you observe at each step, and call out anything that does not behave as expected.
-```
-
-Copilot은 Playwright MCP server를 통해 브라우저를 실행하고, 각 단계를 수행한 뒤, 확인한 내용을 보고합니다. 요약 내용을 issue의 acceptance criteria와 비교해 보고, 어긋나는 부분이 있으면 후속 질문을 하거나 pull request를 열기 전에 코드를 수정하도록 다시 요청합니다.
-
-> [!NOTE]
-> 이 테스트를 수행하려면 앱이 `http://localhost:4321`에서 실행 중이어야 합니다. Dev server를 중지했다면 프롬프트를 보내기 전에 다시 시작합니다. Copilot이 처음으로 Playwright MCP server를 사용할 때 브라우저를 다운로드해야 할 수도 있습니다. 브라우저가 없다고 보고하면 `npx playwright install chromium`를 실행하도록 요청한 뒤 다시 시도합니다.
-
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
-## 요약 및 다음 단계
-
-축하합니다. Copilot CLI에서 Playwright MCP server를 사용해 기능을 수동으로 테스트했습니다. 정리하면 다음을 수행했습니다.
-
-- Model Context Protocol(MCP)이 무엇인지 학습하고, MCP server가 Copilot CLI를 어떻게 확장하는지 살펴보았습니다.
-- `/mcp add`로 Playwright MCP server를 추가했습니다.
-- 기능을 배포하기 전에 Copilot에게 브라우저를 제어해 필터링 기능을 검증하도록 요청했습니다.
-
-이제 기능이 동작함을 확인했으니, 다음 연습으로 이동해 [에이전트 스킬의 도움을 받아 pull request를 열 수 있습니다][next-lesson].
-
-## 리소스
-
-- [MCP가 대체 무엇이고 왜 모두가 이야기할까요?][mcp-blog-post]
-- [Microsoft Playwright MCP Server][playwright-mcp-server]
-- [Copilot CLI용 MCP server 추가하기][cli-add-mcp]
-- [GitHub MCP Server][github-mcp-server]
-
-[previous-lesson]: ../3-generating-code/
-[next-lesson]: ../5-agent-skills/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[github-mcp-server]: https://github.com/github/github-mcp-server
-[cli-add-mcp]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
diff --git a/docs/ko-kr/cli/5-agent-skills.md b/docs/ko-kr/cli/5-agent-skills.md
index 48c8f6bb..2412463b 100644
--- a/docs/ko-kr/cli/5-agent-skills.md
+++ b/docs/ko-kr/cli/5-agent-skills.md
@@ -1,119 +1,93 @@
---
-title: "연습 5 - 에이전트 스킬 사용하기"
+title: "연습 5 - quality-checks 스킬 만들기 및 사용"
+description: "재사용 가능한 셸 스크립트 기반 품질 검사를 Copilot에 요청하고, 스킬을 검토한 후 필터링 브랜치에서 실행합니다."
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
-앱 개발에는 빌드 생성, 테스트 실행, pull request 작성처럼 반복 가능한 작업이 자주 포함됩니다. **에이전트 스킬(Agent Skills)**을 사용하면 Copilot과 다른 AI agent에 이러한 작업을 수행하는 방법에 대한 가이드를 제공할 수 있습니다. 스킬은 agent가 필요할 때 불러올 수 있는 지침, 스크립트, 리소스 폴더입니다. [Agent Skills는 오픈 표준][agent-skills-repo]이며, 여러 agent에서 사용됩니다. 따라서 동일한 스킬을 Copilot Chat in agent mode, Copilot cloud agent, Copilot CLI, GitHub Copilot app 전반에서 사용할 수 있습니다.
+필터링 기능을 구현하고 기존 npm 명령으로 검사했습니다. 이제 이러한 검사를 재사용 가능한 **에이전트 스킬**로 묶습니다. 연습 4~8에서 동일한 필터링 세션과 브랜치를 유지합니다. 이 연습에서는 끌어오기 요청을 만들지 않습니다.
-스킬은 프로젝트의 `.github/skills` 폴더 또는 전역 `~/.copilot/skills`에 저장됩니다. 각 스킬은 YAML frontmatter(`name`과 `description`)가 포함된 `SKILL.md` 파일과 그 뒤에 이어지는 markdown 지침으로 구성된 폴더입니다.
-
-```yaml
----
-name: make-contribution
-description: All changes to code must follow the guidance documented in the repository. Before any issue is filed, branch is made, commits generated, or pull request (or PR) created, a search must be done to ensure the right steps are followed. Whenever asked to create an issue, commit messages, to push code, or create a PR, use this skill so everything is done correctly.
----
-```
-
-스킬에는 스크립트, asset, 참고 자료를 담은 하위 폴더도 포함될 수 있습니다. 전체 구조는 [agent skills specification][agent-skills-spec]에서 다룹니다.
+이 연습에서는 다음을 수행합니다.
-> [!TIP]
-> 스킬은 동적으로 로드됩니다. 어떤 스킬이 적용되는지는 agent가 `description` 필드를 기준으로 판단합니다. 시나리오별로 명확한 설명이 있어야 실제로 사용되는 스킬이 되고, 그렇지 않으면 무시될 수 있습니다.
+- 사용자 지정을 만들기 전에 **Interactive** 모드로 돌아옵니다.
+- Copilot에 `quality-checks`를 만들고 검토를 위해 중단하도록 요청합니다.
+- 함께 제공되는 스크립트로 네 가지 검사를 모두 실행하고, 단일 테스트 파일을 지정하는 인수가 해당 파일만 선택함을 입증합니다.
+- 필터링 기능과 함께 스킬의 체크포인트를 저장합니다.
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
-이제 스킬이 팀의 사양에 맞는 pull request를 보장하는 방법을 살펴보겠습니다.
+## 지침, 스크립트, 리소스
-## 시나리오
+스킬은 에이전트가 필요할 때 불러오는 재사용 가능한 작업 지침, 실행 가능한 스크립트, 보조 리소스를 묶습니다. 사용자 지정 에이전트는 전문 역할, 지침, 사용 가능한 도구를 정의합니다. 두 방식은 상호 보완적입니다. 사용자 지정 에이전트도 스킬에 포함된 스크립트를 비롯한 스크립트를 실행할 수 있습니다.
-팀에는 pull request(PR)에 대한 다음 요구 사항이 있습니다.
+리포지토리 스킬은 `.github/skills//SKILL.md`에 있으며 `name`과 `description` 프런트매터 및 Markdown 지침을 포함합니다. 스크립트와 다른 리소스는 그 옆에 둡니다. 완성된 답을 복사하지 않고 Copilot에 `.github/skills/quality-checks/SKILL.md`와 함께 제공되는 스크립트를 생성하도록 요청합니다. [Agent Skills 명세][skill-spec]에서 형식을 설명합니다.
-- 명확한 커밋 메시지를 사용하고, 파일은 논리적으로 그룹화해야 합니다.
-- PR을 만들기 전에 모든 테스트가 통과해야 합니다.
-- 각 PR에는 다음 섹션이 포함되어야 합니다.
- - 변경이 필요한 이유에 대한 설명
- - 변경된 파일 개요
- - 중요한 코드 블록 스니펫
- - 수행한 변경 사항을 묶어 설명하는 세부 내용
+Copilot은 발견한 스킬의 설명으로 언제 불러올지 판단합니다. 이미 열린 세션에서 새 스킬을 즉시 발견한다고 가정하지 않습니다. 실행 절에서는 명시적으로 읽는 대체 절차를 제공합니다. 이식 가능한 형식이라고 해서 셸이나 프로젝트 필수 조건이 없어지지는 않습니다.
-팀은 Copilot으로 코드와 PR을 생성하고 있으므로, AI 도구가 이러한 요구 사항을 따르도록 보장하고 싶어 합니다.
+## 스킬 만들기
-이 연습에서는 다음을 수행합니다.
+프롬프트를 보내기 전에 **Interactive** 모드로 돌아옵니다. 현재 체크아웃과 브랜치를 유지합니다. 이 스킬이 이미 있는 이전 템플릿으로 시작했다면 사용자 지정을 덮어쓰지 말고 검토하여 확장합니다.
-- Pull request 생성을 위한 기존 스킬을 살펴봅니다.
-- AI agent가 스킬을 활용하는 방식을 학습합니다.
-- 스킬의 도움으로 가이드라인에 맞는 PR을 만듭니다.
+```plaintext
+.github/skills/quality-checks/SKILL.md와 npm run lint, npm run test:unit, npm run test:e2e, npm run typecheck:all을 호출하는 스크립트 4개를 만들어 주십시오. 먼저 package.json, README, 테스트 설정, 리포지토리 지침을 읽어 주십시오.
-## 스킬 실행하기
+현재 환경을 감지해 주십시오. macOS/Linux/WSL이면 Bash .sh 스크립트만, 네이티브 Windows이면 PowerShell .ps1 스크립트만 만들고, 확실하지 않으면 질문해 주십시오. 두 가지 모두 만들지 마십시오. 래퍼는 자신의 위치에서 리포지토리 루트를 찾고, 그곳에 이 프로젝트의 package.json이 있는지 검증한 후 npm을 호출하는 역할로 제한해 주십시오. 루트가 잘못되면 명확한 오류와 함께 실패하도록 해 주십시오. 어떤 작업 디렉터리와 공백이 있는 경로에서도 작동해야 합니다. 출력과 실패 종료 코드를 유지하고 PowerShell 네이티브 명령 실패도 처리해 주십시오. npm의 -- 구분자는 정확히 한 번만 삽입하고, 호출자는 추가 -- 없이 도구의 인수를 직접 전달하도록 해 주십시오. 포트나 프로세스를 관리하지 마십시오.
-스킬은 agent가 필요하다고 판단할 때 동적으로 로드됩니다. 어떤 스킬을 사용할지는 `SKILL.md` 파일의 설명에 따라 결정됩니다. 따라서 스킬의 사용 사례를 정의하는 명확한 설명을 작성하는 것이 중요합니다.
+SKILL.md에 name과 description 프런트매터, 래퍼 4개를 실행하는 지침, 필수 조건, 문제 해결 방법, 기존 단위 테스트 파일 하나를 사용하는 예시를 포함한 이식 가능한 호출 예시를 작성해 주십시오. 모든 Bash 예시는 bash를 명시적으로 호출해야 하며, PowerShell 실행 정책은 절대 우회하지 마십시오. Playwright 서버 재사용을 설명하고, 실제로 직접 시작한 서버만 중지하며 그렇지 않으면 질문하도록 해 주십시오.
-## PR 스킬 살펴보기
+스킬과 필요한 스크립트만 만들어 주십시오. 검사나 탐색용 실행을 하거나, 무언가를 설치하거나, 애플리케이션 코드를 변경하거나, 커밋하거나, PR을 열지 마십시오. 검토할 수 있도록 중단해 주십시오.
+```
-Tailspin Toys에는 PR 생성에 대한 요구 사항이 있으므로, AI 도구가 이러한 가이드라인을 따르는 PR을 생성할 수 있도록 도와주는 스킬을 만들었습니다. 이 스킬이 무엇을 하는지 이해하기 위해 내용을 살펴보겠습니다.
+## 스킬 검토
-1. `.github/skills/make-contribution/SKILL.md`를 엽니다.
-2. 이름과 설명을 확인합니다. 설명이 pull request 생성 또는 코드 커밋 요청이 있을 때 사용해야 하는 시나리오를 어떻게 강조하는지 확인합니다.
-3. 스킬 내용을 읽어 봅니다. 브랜치 생성 방식, 커밋 생성 방식, pull request 내용에 관한 규칙이 정의되어 있음을 확인합니다.
+1. 편집기에서 `.github/skills/quality-checks/SKILL.md`와 함께 제공되는 스크립트를 열고 diff를 확인합니다.
+2. `name`과 `description`이 스킬과 적용 시점을 설명하는지 확인합니다. 메타데이터뿐 아니라 지침도 읽습니다.
+3. 실행 순서가 lint, 단위 테스트, E2E, 타입 검사를 위해 `.github/skills/quality-checks/` 아래에 함께 제공되는 스크립트를 실제로 호출하는지 확인합니다.
+4. 각 래퍼에서 스크립트 위치 기반 루트 탐색과, 찾은 디렉터리에 이 체크아웃에서 의도한 `package.json`이 있는지 명시적으로 확인하는 절차를 살펴봅니다. npm이 상위 디렉터리를 검색하여 명령이 성공한 것은 루트가 올바르다는 증거가 아닙니다. 경로의 따옴표 처리, 인수 전달, 출력 표시, 실패 종료를 확인합니다. PowerShell은 네이티브 npm 실패를 전달해야 합니다.
+5. 문서화된 단일 단위 테스트 파일 실행 예시를 확인합니다. 래퍼가 npm의 `--` 구분자를 삽입하므로 호출자는 다른 구분자 없이 대상 도구의 인수를 직접 전달합니다. 재사용 가능한 지침에는 특정 컴퓨터의 절대 체크아웃 경로를 포함하지 않습니다. 실행 전에 부족한 부분을 수정하도록 Copilot에 요청합니다.
+6. 스크립트는 루트/매니페스트 검증과 기존 npm 검사 실행으로 제한합니다. 포트와 프로세스에 관한 판단은 셸 프로세스 관리 코드가 아니라 SKILL.md에 둡니다. 에이전트가 실제로 시작한 서버만 중지할 수 있는지 확인합니다. 작업 디렉터리나 프로세스 이름이 일치한다고 소유권이 성립하지는 않습니다. 제공한 파일에는 스킬, 필수 래퍼, 필요한 공유 헬퍼만 포함하고 임시 조사 파일이나 디버그 파일은 포함하지 않습니다.
-## 스킬 사용하기
+> [!NOTE]
+> 현재 Tailspin Toys에는 Node.js 22.13 이상, 프로젝트 의존성, E2E 검사용 Playwright Chromium이 필요합니다. 체크아웃의 README와 `package.json`에서 필수 조건을 확인합니다. 누락된 필수 조건이나 PowerShell 실행 정책에 의한 차단은 승인된 방법으로 해결해야 합니다. 자동 설치, 정책 우회, 알리지 않고 직접 npm으로 전환하는 방식으로 해결하지 않습니다.
-앞서 강조했듯이 스킬은 Copilot CLI가 자동으로 호출합니다. 따라서 Copilot에게 PR 생성을 요청하기만 하면 됩니다.
+## 스킬 실행
-> [!TIP]
-> **Copilot CLI 세션 시작하기**
->
-> 아래 연습을 시작하기 전에 코드스페이스로 돌아가 터미널을 엽니다(이미 열려 있지 않다면 Ctrl+`). 그런 다음 `--yolo`와 `--enable-all-github-mcp-tools`를 사용해 Copilot CLI를 시작합니다.
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 이 프로젝트의 가장 최근 세션을 새로 시작하지 않고 이어서 사용하려면 `copilot --yolo --enable-all-github-mcp-tools --continue`를 실행합니다. 이전 연습에서 Copilot CLI가 이미 실행 중이라면 `/clear`를 보내 새 대화를 시작합니다.
->
-> `--enable-all-github-mcp-tools`는 현재 세션에서 읽기/쓰기 GitHub MCP 도구를 활성화하므로, 워크숍 흐름 중 Copilot이 백로그를 읽고 pull request를 열 수 있습니다.
+이전 연습의 개발 서버가 중지되었는지 확인합니다. Playwright는 E2E를 위해 빌드하고 미리 보기를 제공하지만, 로컬 설정은 포트 `4321`의 서버를 재사용할 수 있습니다. 다른 체크아웃의 서버는 이 기능의 유효한 근거가 아닙니다.
-> [!CAUTION]
-> `--yolo`는 전체 자동 권한(`--allow-all-tools`, `--allow-all-paths`, `--allow-all-urls`)을 활성화합니다. Codespace나 VM 같은 격리된 환경에서만 사용하고, 일상적인 개발을 위한 기본 별칭으로는 절대 설정하지 않습니다. 자세한 내용은 [Allowing and denying tool use][allow-all-warning]를 참고합니다.
+Copilot CLI에 `/quality-checks`가 표시되면 선택하여 발견된 스킬을 명시적으로 호출하고 아래 요청을 포함합니다. 발견되지 않았다면 이 세션에서 동일한 요청을 직접 보냅니다. 이 연습에서는 스킬을 읽는 방법을 대체 절차로 사용할 수 있습니다.
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. 다음 프롬프트를 사용해 Copilot에게 PR 생성을 요청합니다.
+```plaintext
+.github/skills/quality-checks/SKILL.md를 읽고 지침에 따라 이 체크아웃의 필터링 기능을 검증해 주십시오. 먼저 각 래퍼의 코드를 검토하여 npm의 상위 디렉터리 패키지 탐색에 의존하지 않고, 이 체크아웃에서 의도한 package.json을 포함하는 디렉터리를 찾으며, 잘못된 루트에서는 명시적으로 실패하도록 처리하는지 확인해 주십시오. 실패를 재현하기 위해 리포지토리 파일을 이동하거나 이름을 바꾸거나 삭제하거나 수정하지 마십시오. 함께 제공되는 lint, 단위 테스트, 엔드투엔드 테스트, 타입 검사 스크립트를 실제로 실행해 주십시오. 문서화된 단일 단위 테스트 파일 실행 예시도 실행하되, npm의 -- 구분자는 래퍼가 담당하므로 대상 도구의 인수를 직접 전달해 주십시오. 테스트 러너의 결과에서 지정한 파일만 실행되었는지 확인하고, 해당 파일명과 실행된 테스트 파일 수를 보고해 주십시오. 인수를 출력하거나 종료 코드 0을 반환하는 것만으로는 올바른 선택을 증명하지 못합니다.
- ```
- Can you please create a pull request for me!
- ```
+실패, 건너뛴 검사, 누락된 필수 조건을 포함하여 각 스크립트 호출과 결과를 보고해 주십시오. 사용할 수 없는 스킬 스크립트를 알리지 않고 직접 npm 명령으로 대체하지 마십시오. 테스트할 체크아웃과 서버를 식별하고 직접 시작한 서버만 중지하며, 설치하거나 다른 프로세스를 중지하기 전에 질문해 주십시오. 애플리케이션 코드나 브랜치를 변경하거나 커밋, 푸시, 끌어오기 요청 생성을 하지 마십시오.
+```
-2. Copilot이 요청을 확인합니다. 잠시 후 Copilot이 **make-contribution** 스킬을 사용 중이라고 표시하는 것을 확인할 수 있습니다.
+도구 호출과 출력을 확인합니다. 네 스크립트가 모두 실제로 실행되어야 합니다. 검사 설명이나 건너뛴 검사는 통과가 아닙니다. 단일 파일 예시에서는 요청한 파일명을 러너의 실제 파일별 결과 및 보고한 수와 비교합니다. 해당 파일만 실행되어야 합니다. 다른 파일도 실행되었다면 인수 출력이나 종료 코드 0만으로는 충분하지 않습니다. 실패는 유용한 근거입니다. 스킬을 수정하거나 승인받아 설정 차단 요인을 해결한 다음 영향을 받는 검사를 다시 실행합니다. 관련 없는 프로세스를 중지하거나 포트 충돌을 강제로 없애지 않습니다.
-3. Copilot은 이어서 스킬의 지침을 따릅니다. 먼저 테스트를 실행한 뒤 브랜치, 커밋, 그리고 최종적으로 PR을 생성합니다.
-4. PR이 생성되면 리포지토리로 돌아가 PR을 엽니다. 섹션이 스킬에 정의된 가이드라인을 따르고 있으며, 팀이 제시한 요구 사항과 일치하는지 확인합니다.
-5. 다음 연습으로 넘어가기 전에 이 필터링 PR과 접근성 작업을 분리하기 위해 로컬 작업 공간을 `main`에서 새 브랜치로 초기화합니다.
+## 체크포인트 저장
- ```bash
- git checkout main
- git pull
- git checkout -b accessibility-cli
- ```
+스킬과 결과를 검토한 후 로컬 체크포인트를 승인합니다.
-## 요약 및 다음 단계
+```plaintext
+현재 diff를 검토하고 quality-checks 스킬 파일만 포함한 체크포인트 커밋을 만들어 주십시오. 기존 필터링 브랜치를 유지해 주십시오. 푸시하거나 끌어오기 요청을 만들지 마십시오.
+```
-에이전트 스킬의 도움으로 문서화된 요구 사항을 충족하는 새로운 PR을 만들었습니다. 다음을 수행했습니다.
+스킬 파일은 연습 8의 기능 PR에 필터링, QA 프로필, 관련 테스트와 함께 포함됩니다. 동일한 체크아웃에서 [연습 6 - Playwright MCP로 기능 검증][next-lesson]을 계속합니다.
-- Pull request 생성을 위한 기존 스킬을 살펴보았습니다.
-- AI agent가 스킬을 활용하는 방식을 학습했습니다.
-- 스킬의 도움으로 가이드라인에 맞는 PR을 만들었습니다.
+## 더 많은 스킬 예제
-스킬은 특정 작업에 적합하지만, 더 강력한 작업을 수행하려면 [custom agents][next-lesson]를 활용해야 합니다. 다음으로 이를 살펴보겠습니다.
+이 커뮤니티 예제는 참고 자료이며 추가 작업이 아닙니다. 채택하기 전에 필수 조건과 동작을 검토합니다.
-## 리소스
+- [기여 워크플로: `make-repo-contribution`][contribution-example].
+- [요구 사항 문서: `prd`][prd-example].
+- [다이어그램과 함께 제공되는 내보내기 스크립트: `drawio`][drawio-example].
+- [브라우저 테스트: `webapp-testing`][browser-example].
-- [에이전트 스킬 소개][about-agent-skills]
-- [Agent Skills Specification][agent-skills-spec]
-- [Agent Skills Repository][agent-skills-repo]
-- [Awesome-copilot의 Agent Skills][awesome-copilot-skills]
+업스트림 기여 예제의 이름은 `make-repo-contribution`이며, 이전 Tailspin 템플릿은 `make-contribution`이라는 다른 이름을 사용했습니다. 이 워크숍은 두 기여 스킬 중 어느 것에도 의존하지 않습니다.
-[previous-lesson]: ../4-mcp/
-[next-lesson]: ../6-custom-agents/
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[awesome-copilot-skills]: https://github.com/github/awesome-copilot/tree/main/skills
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/ko-kr/cli/6-custom-agents.md b/docs/ko-kr/cli/6-custom-agents.md
deleted file mode 100644
index ddb510e4..00000000
--- a/docs/ko-kr/cli/6-custom-agents.md
+++ /dev/null
@@ -1,113 +0,0 @@
----
-title: "연습 6 - GitHub Copilot CLI로 커스텀 에이전트 사용하기"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-## 커스텀 에이전트란 무엇인가요?
-
-GitHub Copilot의 [커스텀 에이전트][custom-agents-concept]를 사용하면 개발 워크플로 안의 특정 작업이나 도메인에 맞춘 전문 AI 도우미를 만들 수 있습니다. 리포지토리의 `.github/agents` 폴더 안에 있는 markdown 파일로 agent를 정의하면, 특정 종류의 작업을 더 효과적으로 수행하도록 Copilot을 이끄는 집중된 지침, 모범 사례, 코딩 패턴, 도메인별 지식을 제공할 수 있습니다. 팀은 전문성을 재사용 가능한 agent로 체계화할 수 있습니다. 예를 들어 [WCAG][wcag] 준수를 강제하는 접근성 agent, 보안 코딩 관행을 따르는 보안 agent, 일관된 테스트 패턴을 유지하는 테스트 agent 등을 만들 수 있습니다.
-
-커스텀 에이전트는 프로젝트의 `.github/agents` 폴더 또는 전역 `~/.copilot/agents`의 markdown 파일로 정의합니다. 각 파일에는 최소한 `name`과 `description`이 포함된 YAML frontmatter가 있고, 그 뒤에 agent의 동작, 전문성, 지침을 정의하는 markdown 프롬프트가 이어집니다.
-
-### 커스텀 에이전트와 에이전트 스킬 비교하기
-
-커스텀 에이전트와 [에이전트 스킬][agent-skills-concept] 사이에는 개념적으로 겹치는 부분이 있습니다. 둘 다 주로 markdown 파일로 정의되며 AI에게 작업 수행 방법을 알려 줍니다. 가장 깔끔하게 구분하면 **커스텀 에이전트**는 작업자이고, **스킬**은 도구입니다.
-
-커스텀 에이전트는 자체 컨텍스트 창을 가지며, 작업을 수행하는 과정에서 스킬(심지어 다른 agent까지도)을 오케스트레이션하도록 설계됩니다. 이 실습에서 접근성 커스텀 에이전트는 접근성 가이드라인을 기준으로 사이트를 검토하고 업데이트합니다. 이 과정에서 pull request 워크플로 스킬이나 테스트 실행 및 관리를 담당하는 스킬 같은 도구를 호출할 수도 있습니다.
-
-> [!NOTE]
-> 커스텀 에이전트를 작성하는 유일한 "정답"은 없습니다. AI의 다른 작업과 마찬가지로, 환경과 시나리오에 가장 잘 맞는 방식을 찾기 위해 테스트하고 반복해 보아야 합니다.
-
-[custom-agents-concept]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
-[agent-skills-concept]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[wcag]: https://www.w3.org/WAI/standards-guidelines/wcag/
-## 시나리오
-
-많은 웹 애플리케이션이 모든 사용자에게 접근 가능하지 못하며, 지금 작업 중인 웹 사이트도 예외는 아닙니다. 커스텀 에이전트를 사용해 접근성 문제를 식별하고 해결해 보겠습니다.
-
-Tailspin Toys는 시각 능력이나 선호도와 관계없이 모든 사용자가 crowdfunding platform을 이용할 수 있도록 보장하는 데 전념하고 있습니다. 최근 사용자 피드백에 따르면 현재 dark theme는 텍스트와 배경색 사이의 대비가 충분하지 않아 일부 사용자가 읽기 어렵다고 느끼고 있습니다. 이 접근성 문제를 해결하기 위해 디자인 팀은 사용자가 켜고 끌 수 있는 high-contrast mode 구현을 요청했습니다.
-
-접근성은 매우 중요하므로 가능한 한 빠르게 구현하고 싶습니다. 커스텀 에이전트를 활용해 이 기능을 생성합니다.
-이 연습에서는 다음을 수행합니다.
-
-- 커스텀 에이전트를 살펴봅니다.
-- 커스텀 에이전트를 활성화하고 Copilot CLI를 사용해 작업을 할당합니다.
-
-## 접근성 커스텀 에이전트 검토하기
-
-접근성을 위해 이미 커스텀 에이전트가 준비되어 있습니다. Copilot을 어떻게 안내하는지 이해하기 위해 내용을 검토해 보겠습니다.
-
-1. `.github/agents/accessibility.md`를 엽니다.
-2. `name`과 `description` 필드가 포함된 YAML frontmatter를 확인합니다.
-
-> [!CAUTION]
-> `name`과 `description`이 포함된 frontmatter는 커스텀 에이전트에 필수입니다.
-
-3. 이어지는 섹션을 훑어보며 다음 내용을 확인합니다.
- - 접근 가능한 웹 사이트를 위한 코드를 생성할 때의 핵심 책임
- - 접근성 모범 사례
- - HTML, CSS, JavaScript용 코드 예시
- - 흔한 함정과 실수 목록
-
-## Copilot CLI에서 커스텀 에이전트 사용하기
-
-Copilot CLI에서는 `/agent` 명령으로 커스텀 에이전트를 시작할 수 있습니다. 이제 웹 사이트에 접근성 점검을 수행해 보겠습니다.
-
-> [!TIP]
-> **Copilot CLI 세션 시작하기**
->
-> 아래 연습을 시작하기 전에 코드스페이스로 돌아가 터미널을 엽니다(이미 열려 있지 않다면 Ctrl+`). 그런 다음 `--yolo`와 `--enable-all-github-mcp-tools`를 사용해 Copilot CLI를 시작합니다.
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 이 프로젝트의 가장 최근 세션을 새로 시작하지 않고 이어서 사용하려면 `copilot --yolo --enable-all-github-mcp-tools --continue`를 실행합니다. 이전 연습에서 Copilot CLI가 이미 실행 중이라면 `/clear`를 보내 새 대화를 시작합니다.
->
-> `--enable-all-github-mcp-tools`는 현재 세션에서 읽기/쓰기 GitHub MCP 도구를 활성화하므로, 워크숍 흐름 중 Copilot이 백로그를 읽고 pull request를 열 수 있습니다.
-
-> [!CAUTION]
-> `--yolo`는 전체 자동 권한(`--allow-all-tools`, `--allow-all-paths`, `--allow-all-urls`)을 활성화합니다. Codespace나 VM 같은 격리된 환경에서만 사용하고, 일상적인 개발을 위한 기본 별칭으로는 절대 설정하지 않습니다. 자세한 내용은 [Allowing and denying tool use][allow-all-warning]를 참고합니다.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. Copilot CLI의 프롬프트 창에 `/agent`를 입력하고 Enter를 눌러 agent 목록을 엽니다.
-2. 사용 가능한 agent 목록에서 **Accessibility agent**를 선택합니다.
-3. 다음 프롬프트를 사용해 접근성 agent에게 접근성 백로그 항목을 검토하고 수정 사항을 생성해 달라고 요청합니다.
-
- ```
- Perform an accessibility review of the site. Pull the related issue down from the repository for details. Implement a high-contrast mode toggle that persists the user's preference across page reloads. Ensure there are e2e tests for any updates made to the project. Then create a PR with the updates.
- ```
-
-4. Copilot이 작업을 시작합니다. 먼저 issue를 가져오고, 검토를 수행하고, 업데이트를 생성하고, 마지막으로 PR을 만듭니다. PR을 만들 때 프로젝트의 PR 전용 스킬을 사용하는 점도 확인할 수 있습니다.
-
-> [!NOTE]
-> 이 과정은 몇 분 정도 걸릴 수 있습니다. 지금까지 학습한 내용을 되돌아보거나, 음료를 즐기거나, Copilot CLI에서 사용할 수 있는 추가 명령을 다루는 다음 모듈을 미리 살펴보기에 좋은 시간입니다.
-
-## 요약 및 다음 단계
-
-이 연습에서는 GitHub Copilot의 [커스텀 에이전트][custom-agents]를 살펴보았습니다. 커스텀 에이전트는 특정 작업과 도메인에 맞춘 전문 AI 도우미입니다. 커스텀 에이전트를 사용하면 팀의 전문성과 표준을 재사용 가능한 agent로 체계화해 Copilot이 특정 유형의 작업을 더 효과적으로 수행하도록 안내할 수 있습니다.
-
-다음 개념을 살펴보았습니다.
-
-- 커스텀 에이전트가 어떻게 정의되는지
-- Copilot CLI에서 커스텀 에이전트를 사용하는 방법
-
-다음으로는 [몇 가지 slash commands][next-lesson]를 살펴보며 Copilot CLI의 추가 팁을 알아보겠습니다.
-
-## 리소스
-
-- [커스텀 에이전트][custom-agents]
-- [리포지토리용 커스텀 에이전트 만들기][creating-custom-agents]
-- [Awesome-copilot의 커스텀 에이전트][awesome-copilot-agents]
-- [조직에서 커스텀 에이전트를 사용하기 위한 준비][org-custom-agents]
-- [엔터프라이즈에서 커스텀 에이전트를 사용하기 위한 준비][enterprise-custom-agents]
-
-[previous-lesson]: ../5-agent-skills/
-[next-lesson]: ../7-slash-commands/
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[creating-custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/create-custom-agents
-[awesome-copilot-agents]: https://github.com/github/awesome-copilot/tree/main/agents
-[org-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-organization/prepare-for-custom-agents
-[enterprise-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/prepare-for-custom-agents
diff --git a/docs/ko-kr/cli/6-mcp-playwright.md b/docs/ko-kr/cli/6-mcp-playwright.md
new file mode 100644
index 00000000..7cb90363
--- /dev/null
+++ b/docs/ko-kr/cli/6-mcp-playwright.md
@@ -0,0 +1,83 @@
+---
+title: "연습 6 - Playwright MCP로 기능 검증"
+description: "MCP로 브라우저를 연결하고 관찰한 필터링 동작을 이슈 및 승인된 계획과 비교합니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+필터링 구현과 quality-checks 스킬은 이미 자동 검증을 거쳤습니다. 이제 Copilot에 브라우저를 제공하고 기능을 직접 관찰하도록 요청합니다. 이 연습은 **Model Context Protocol(MCP)** 상호 작용을 실증하며, 전체 테스트 스위트를 다시 실행하는 과정이 아닙니다.
+
+동일한 필터링 체크아웃과 브랜치에서 **Interactive** 모드를 유지합니다. MCP 설정으로 새 기능 마일스톤을 시작하지 않습니다.
+
+## MCP가 추가하는 기능
+
+[MCP][mcp-overview]는 서버를 통해 에이전트를 외부 도구와 컨텍스트에 연결합니다. 기본 제공 GitHub MCP 서버로 이슈와 PR을 다룰 수 있습니다. [Playwright MCP 서버][playwright-mcp]는 페이지 열기, 접근성 요소 확인, 탐색, 컨트롤 조작을 위한 브라우저 도구를 제공합니다.
+
+브라우저의 접근성 스냅샷은 에이전트가 컨트롤을 식별하는 데 도움이 되지만 완전한 접근성 준수를 증명하지는 않습니다. 일반적인 “좋아 보입니다”라는 응답을 수락하지 말고 실제 작업과 관찰을 이슈 요구 사항과 비교합니다.
+
+> [!CAUTION]
+> MCP 서버를 프로젝트 의존성처럼 다룹니다. 활성화 전에 게시자, 소스, 권한, 패키지 다운로드를 검토합니다. 조직 정책이 실행 가능한 서버를 제한할 수 있습니다. 커밋하는 설정에 자격 증명을 넣거나 연습을 끝내기 위해 알 수 없는 도구를 승인하지 않습니다.
+
+## Playwright MCP 설정
+
+1. 기존 CLI 세션에서 `/mcp`를 입력해 설정된 서버를 확인합니다. 작동하는 Playwright 설정이 있다면 중복 추가하지 말고 재사용합니다.
+2. 필요하면 `/mcp add`를 입력하고 Tab으로 양식을 이동합니다.
+3. **Server Name**은 `playwright`, **Server Type**은 **STDIO**(또는 **Local**), **Command**는 `npx @playwright/mcp@latest --headless`로 설정합니다.
+4. 검토한 이 브라우저 서버의 **Tools**를 `*`로 설정합니다. 도구를 사용할 수 있게 하지만 CLI의 권한 제어를 대체하지는 않습니다.
+5. 패키지와 시작 명령을 검토한 후 Ctrl+S로 저장합니다. 등록하면 서버가 시작되며 패키지를 다운로드할 수 있습니다. 설정 내용을 이해하고 승인하며 패키지 프롬프트에 응답합니다.
+6. `/mcp show playwright`를 입력하고 서버가 연결되었으며 브라우저 도구를 사용할 수 있는지 확인합니다.
+
+헤드리스 브라우저는 데스크톱 창이 필요하지 않아 Codespaces에 적합합니다. 대화형 추가 절차는 `~/.copilot/mcp-config.json`에 설정을 저장하고 CLI를 재시작하지 않아도 서버를 사용할 수 있게 합니다. 이는 사용자 설정이며 기능 PR에 포함할 파일이 아닙니다. [MCP 설정 가이드][mcp-setup]에서 필드와 설정 소스를 설명합니다.
+
+> [!NOTE]
+> 프로젝트 E2E 의존성과 MCP 브라우저는 관련이 있지만 다른 설정이 필요할 수 있습니다. 브라우저나 시스템 의존성이 없다면 실제 오류를 확인하고 승인받아 해당 필수 조건을 해결합니다. 브라우저를 자동으로 설치하거나 서버 연결만으로 브라우저 실행이 가능하다고 판단하지 않습니다.
+
+## 올바른 앱 시작
+
+동일한 필터링 체크아웃에서 별도 터미널을 엽니다. 디렉터리와 브랜치를 확인한 후 앱을 시작합니다.
+
+```bash
+pwd
+git branch --show-current
+npm run dev
+```
+
+서버 출력에서 실제 로컬 URL을 확인합니다. 코드스페이스에서는 MCP 서버와 앱이 같은 환경에서 실행되므로, 전달된 브라우저 URL이 필요하다고 가정하지 말고 보통 `http://localhost:4321`인 로컬 URL을 사용합니다.
+
+포트가 사용 중이거나 Astro가 다른 포트를 선택하면 서버 소유자를 식별한 후 진행합니다. 알 수 없는 서버를 재사용하거나 종료하지 않습니다. 방금 시작한 프로세스의 URL을 사용하고 테스트하는 동안 해당 터미널을 열어 둡니다.
+
+## 필터링 동작 관찰
+
+플레이스홀더를 실제 이슈 URL, 연습 4에서 승인한 추가 합의 사항, 앱 URL로 바꿉니다.
+
+```plaintext
+설정된 Playwright MCP 서버를 사용하여 다음 이슈에 맞게 필터링 기능을 검증해 주십시오: . 계획 중 승인한 추가 합의 사항은 다음과 같습니다: <합의한 추가 내용을 붙여 넣거나 없으면 none 입력>. 이 체크아웃의 앱은 에서 실행 중입니다. 결과를 신뢰하기 전에 테스트할 체크아웃, 브랜치, 서버를 확인해 주십시오.
+
+게임 페이지를 열고 필터링되지 않은 상태를 기록한 다음, 하나의 카테고리와 여러 카테고리를 차례로 선택하고, 퍼블리셔 필터를 적용하며, 카테고리와 퍼블리셔 선택을 조합해 주십시오. 승인한 기준에 따라 필터 해제와 빈 결과 동작을 확인해 주십시오. 컨트롤 레이블, 키보드 조작, 보이는 포커스를 확인해 주십시오. 표시된 결과를 선택한 필터 및 원본 데이터와 비교하고, 컨트롤이 바뀌었다는 이유만으로 성공을 추론하지 마십시오.
+
+실제 브라우저 도구를 조작하고 각 기준에서 관찰한 내용을 보고하며 실패나 누락된 근거를 명확히 표시해 주십시오. 이 브라우저 연습만을 위해 전체 테스트 스위트를 다시 실행하거나 애플리케이션 코드를 변경하거나 테스트나 사용자 지정을 만들거나 브랜치를 변경하거나 커밋, 푸시, PR 생성을 하지 마십시오. 설치하거나 다른 프로세스를 중지하기 전에 질문해 주십시오.
+```
+
+브라우저 도구 호출과 보고서를 확인합니다. Copilot이 실제로 여러 카테고리를 선택하고 퍼블리셔와 조합했습니까? 반환된 게임이 합의한 동작과 일치합니까? 보고서가 관찰 가능한 브라우저 동작을 데이터 계층 및 자동 테스트 커버리지와 구분합니까?
+
+실패하면 관찰한 동작을 기록합니다. 범위를 좁힌 애플리케이션 수정은 별도로 승인하고, 영향을 받는 브라우저 검사와 자동 검사를 반복합니다. 구현에 맞춰 수락 기준을 바꾸거나 오래된 근거를 변경된 코드의 검증으로 계산하지 않습니다.
+
+## 직접 시작한 서버 중지 및 계속 진행
+
+개발 서버를 시작한 터미널에서 Ctrl+C로 서버를 중지합니다. Playwright MCP 설정은 계속 사용할 수 있도록 유지합니다. 연습 7에서는 최신 브라우저 관찰과 자동 E2E 검사를 조율합니다. 오래된 개발 서버나 다른 체크아웃의 앱을 재사용해서는 안 됩니다.
+
+QA 프로필을 만들기 전에 **Interactive**를 유지합니다. 다른 PR이나 브랜치를 만들지 않고 브라우저 동작을 관찰했습니다. 다음에는 [QA 에이전트를 만들어 사용하여][next-lesson] 요구 사항, 커버리지, 스킬, 최종 근거를 통합합니다.
+
+## 리소스
+
+- [Copilot CLI에 MCP 서버 추가][mcp-setup]에서는 설정과 관리를 설명합니다.
+- [Microsoft Playwright MCP][playwright-mcp]에서는 브라우저 설정과 도구를 설명합니다.
+- [GitHub MCP 레지스트리][mcp-registry]에는 평가할 수 있는 다른 서버가 나열되어 있습니다.
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-overview]: https://docs.github.com/copilot/concepts/context/mcp
+[mcp-setup]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
+[playwright-mcp]: https://github.com/microsoft/playwright-mcp
+[mcp-registry]: https://github.com/mcp
diff --git a/docs/ko-kr/cli/7-qa-agent.md b/docs/ko-kr/cli/7-qa-agent.md
new file mode 100644
index 00000000..e804c216
--- /dev/null
+++ b/docs/ko-kr/cli/7-qa-agent.md
@@ -0,0 +1,77 @@
+---
+title: "연습 7 - QA 에이전트 만들기 및 사용"
+description: "테스트 커버리지, quality-checks 스킬, 직접 관찰한 브라우저 근거를 통합하는 요구 사항 우선 QA 프로필을 만듭니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+반복 가능한 검사를 실행하고 Playwright MCP로 필터링을 살펴봤습니다. 이제 **QA 사용자 지정 에이전트**를 만들어 요구 사항, 커버리지, 브라우저 근거를 통합합니다. 필터링 세션, 체크아웃, 브랜치를 유지합니다. 기능 PR은 연습 8에서 만듭니다.
+
+## QA 프로필 만들기
+
+**Interactive** 모드를 유지합니다. 프로필은 전문가의 역할과 지침을 정의하며, 스킬은 재사용 가능한 작업 지침, 스크립트, 리소스를 묶습니다. QA 에이전트는 스킬과 설정된 MCP 도구를 대체하지 않고 사용합니다.
+
+다음 프롬프트를 보낸 후 실행 전에 정의를 확인합니다.
+
+```plaintext
+.github/agents/qa.agent.md에 재사용 가능한 QA 사용자 지정 에이전트를 만들어 주십시오. 먼저 리포지토리 지침, package.json, 테스트 설정, .github/skills/quality-checks/SKILL.md를 확인해 주십시오. 프로필에 유효한 YAML 프런트매터를 제공하고 name은 QA로, description은 사용할 시점을 설명하도록 설정해 주십시오. 모델을 고정하거나 tools 목록을 추가하지 말고 해당 환경에서 사용할 수 있는 도구와 권한을 상속해 주십시오. 에이전트 정의만 만든 다음 실행 전에 검토할 수 있도록 중단해 주십시오.
+
+에이전트 지침에서 모든 QA 작업을 이슈와 사용자가 제공한 승인된 수락 기준으로 시작하도록 요구해 주십시오. 구현이 아니라 이러한 요구 사항을 기준으로 삼아 주십시오. 요구 사항이 누락되거나 모호하면 질문해 주십시오. 기능과 기존 테스트를 확인하고 각 기준을 적절한 자동 테스트 커버리지 및 관찰 가능한 동작과 연결해 주십시오.
+
+설정된 Playwright MCP 서버를 통한 직접 브라우저 검증과 기존 quality-checks 스킬 및 함께 제공되는 스크립트를 통한 lint, 단위 테스트, 엔드투엔드 테스트, 타입 검사 실행을 요구해 주십시오. 스킬이 자동으로 발견되지 않았다면 명시적으로 읽어 주십시오. 스킬, MCP 도구, 필수 조건, 액세스가 없으면 차단된 상태로 보고해 주십시오. 알리지 않고 다른 워크플로로 대체하거나 건너뛴 검사를 통과로 표시하지 마십시오. 테스트할 체크아웃과 서버를 식별하고, 다른 워크트리의 서버를 재사용하지 않으며, 에이전트가 시작한 서버만 중지하고, 설치하거나 다른 프로세스를 중지하기 전에 질문해 주십시오.
+
+리포지토리 지침에 따라 실제 커버리지 공백에 필요한 최소 테스트를 QA 에이전트가 추가할 수 있도록 해 주십시오. 커버리지가 이미 충분하다면 추가 테스트가 없어도 타당합니다. 검증을 약화하거나 실패하는 테스트를 비활성화하거나 코드에 맞춰 수락 기준을 바꾸거나 제 승인 없이 애플리케이션 코드를 수정하지 마십시오. 변경 후 영향을 받는 검사를 다시 실행하고 변경된 리비전의 최종 검증을 완료해 주십시오. 각 기준을 근거와 통과/실패/차단 상태에 연결하고, 추가한 테스트 또는 추가할 필요가 없었던 이유, 네 가지 검사 결과, 해결되지 않은 결함을 포함하는 간결한 보고서를 요구해 주십시오. GO에는 모든 필수 검사와 근거가 필요하며, 그렇지 않으면 이유와 함께 NO-GO를 보고해야 합니다. QA 중에는 브랜치를 변경하거나 커밋, 푸시, PR 생성 또는 병합을 하거나 추가 에이전트나 스킬을 만들지 마십시오.
+```
+
+## 프로필 검토
+
+편집기에서 `.github/agents/qa.agent.md`를 열고 diff를 확인합니다. `description`은 필수이며, 이 연습에서는 읽기 쉬운 `name`으로 `QA`도 제공합니다. 고정된 `model`이나 임의로 만든 도구 목록이 없는지 확인합니다. `tools`를 생략하면 사용 가능한 도구를 상속하지만 해당 환경의 권한을 우회하지는 않습니다. 프로덕션 프로필에서는 의도적으로 도구를 제한할 수 있습니다.
+
+지침이 요구 사항에서 시작하고, 실제 MCP 브라우저 작업과 스킬 스크립트를 요구하며, 정당한 테스트 추가만 허용하고, 차단 요인을 사실대로 보고하는지 확인합니다. 전문가 프로필이나 스킬에 별도 컨텍스트 윈도 또는 다른 에이전트의 오케스트레이션이 필수인 것은 아닙니다.
+
+## 이슈에 대한 QA 실행
+
+실행 프롬프트는 프로필을 읽는 기본 에이전트가 아니라 선택된 **QA** 사용자 지정 에이전트를 위한 것입니다. 다른 기능 브랜치를 만들지 않고 동일한 체크아웃에서 새 CLI 대화를 시작하여 새 프로필을 불러옵니다.
+
+1. 필터링 이슈 URL과 승인한 추가 합의 사항을 보관합니다. 현재 에이전트가 완료될 때까지 기다린 후 `/exit`를 입력해 터미널로 돌아옵니다.
+2. `git branch --show-current`와 `git status --short`로 여전히 필터링 리포지토리 디렉터리와 동일한 브랜치에 있는지 확인합니다. 브랜치를 전환하거나 워크트리를 만들지 않습니다.
+3. 리포지토리 프로필로 CLI를 시작합니다.
+
+ ```shell
+ copilot --agent qa
+ ```
+
+4. 실행 전에 CLI가 **QA**를 선택된 에이전트로 표시하는지 확인합니다. [CLI 명령 참조][cli-reference]에는 `--agent`가 설명되어 있습니다. 프로필을 작성하거나 읽는 것만으로 활성화되지는 않습니다. 선택이 실패하거나 에이전트가 설정된 Playwright MCP 도구와 스킬에 액세스할 수 없다면 일시 중지하고 진행자와 차단 요인을 해결합니다.
+
+두 플레이스홀더를 실제 필터링 이슈 URL과 연습 4에서 승인한 추가 합의 사항으로 바꿉니다. 이슈만으로 요구 사항이 충분하다면 `none`을 사용합니다. 이전 에이전트의 기억에 의존하지 않습니다.
+
+```plaintext
+다음 이슈에 맞게 필터링 기능을 검증해 주십시오: . 계획 중 승인한 추가 수락 기준은 다음과 같습니다: <합의한 추가 내용을 붙여 넣거나 없으면 none 입력>.
+
+Playwright MCP 서버로 동작을 검증하고, 테스트 커버리지를 확인하며, 누락된 커버리지에 대해서만 테스트를 추가하고, quality-checks 스킬을 통해 검증을 실행해 주십시오. 근거, 검사 결과, 차단 요인을 보고해 주십시오. 제 승인 없이 애플리케이션 코드를 변경하지 마십시오. 커밋하거나 끌어오기 요청을 만들지 마십시오.
+```
+
+## 근거 검토
+
+보고서를 이슈와 비교합니다. 각 기준에는 적절한 자동 테스트 커버리지와 관찰 가능한 동작이 필요합니다. 실제 Playwright MCP 도구 작업, 체크아웃과 서버 식별 정보, 네 가지 스킬 스크립트 결과를 모두 확인합니다. 브라우저 검사와 자동 E2E가 오래된 서버나 다른 체크아웃을 재사용해서는 안 됩니다.
+
+추가한 테스트를 검토합니다. 검증을 약화하지 않고 실제 공백을 메워야 합니다. 커버리지가 충분하다면 새 테스트가 없는 것이 올바릅니다. 차단이나 실패에 따른 **NO-GO** 판정은 유효한 결과이며, 근거를 생략해도 된다는 허가가 아닙니다.
+
+QA에서 애플리케이션 결함을 발견하면 범위를 좁힌 수정을 별도로 승인하고, 변경된 리비전에서 영향을 받는 검사와 브라우저 관찰을 다시 실행합니다. 누락된 필수 조건이나 도구에는 명시적인 해결이 필요합니다. 오래된 근거를 변경된 코드의 증거로 취급하지 않습니다.
+
+## 체크포인트 저장
+
+QA가 끝나면 이슈 URL, 승인한 추가 합의 사항, 테스트한 리비전, 브라우저 관찰, 검사 결과를 포함한 보고서를 보관합니다. `/exit`를 입력한 후 동일한 디렉터리와 브랜치에서 `--agent` 없이 `copilot`을 시작하여 일반 대화로 돌아옵니다. 해당 컨텍스트를 다시 제공합니다. 새 대화는 QA 대화의 근거를 상속하지 않습니다.
+
+프로필, 테스트 변경, 그 결과로 얻은 근거를 검토한 후 일반 에이전트에 다음 요청을 보냅니다.
+
+```plaintext
+현재 diff를 검토하고 QA 에이전트 정의와 승인된 테스트 변경의 체크포인트 커밋을 만들어 주십시오. 기존 필터링 브랜치를 유지해 주십시오. 푸시하거나 끌어오기 요청을 만들지 마십시오.
+```
+
+필터링 기능, 스킬, QA 프로필, 테스트, 현재 검증 근거를 갖추고 [연습 8 - 기능 PR 생성 및 병합][next-lesson]을 계속합니다.
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/ko-kr/cli/7-slash-commands.md b/docs/ko-kr/cli/7-slash-commands.md
deleted file mode 100644
index c01136b0..00000000
--- a/docs/ko-kr/cli/7-slash-commands.md
+++ /dev/null
@@ -1,176 +0,0 @@
----
-title: "연습 7 - GitHub Copilot CLI의 슬래시 명령"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-좋은 CLI 도구라면 그렇듯 GitHub Copilot CLI에도 다양한 slash commands가 포함되어 있습니다. 이 명령은 고급 기능, "내부 동작" 정보, 추가 구성 옵션을 제공합니다. 이미 `/clear`로 컨텍스트를 지우고 `/mcp`로 MCP server를 검사하는 방법을 살펴보았습니다. 이제 `/context`, `/model`, `/share`, `/delegate`를 포함한 몇 가지 강력한 명령을 더 살펴보겠습니다.
-
-## 시나리오
-
-이제 핵심 CLI 흐름은 모두 살펴보았습니다. 이번에는 세션 공유, 모델 전환, [Copilot cloud agent][about-cloud-agent]에 작업 위임 같은 추가 기능을 알아보겠습니다.
-
-이 연습에서는 다음을 사용합니다.
-
-- `/share`로 세션을 팀과 공유할 수 있도록 GitHub gist를 만듭니다.
-- `/context`로 Copilot CLI가 현재 사용 중인 컨텍스트를 확인합니다.
-- `/model`로 사용 가능한 모델 목록을 확인하고 원한다면 다른 모델을 선택합니다.
-- `/delegate`로 선택적으로 작업을 cloud agent에 넘깁니다. 이 기능을 사용하려면 cloud agent가 필요하며, Copilot Student, Pro, Pro+, Business, Enterprise에서 사용할 수 있습니다. 즉 Copilot Free를 제외한 모든 플랜에서 사용할 수 있습니다.
-
-## 세션 공유하기
-
-AI 도구를 포함해 어떤 도구든 잘 활용하는 것은 하나의 기술입니다. 팀으로 함께 작업하면서 서로의 학습 내용을 공유하는 것은 모두의 경험을 개선하고 더 높은 품질의 코드를 생성하는 가장 좋은 방법입니다. 이를 지원하기 위해 Copilot CLI는 `/share` 명령을 제공합니다. `/share` 명령은 세션에서 사용한 프롬프트와 Copilot이 따랐던 로직을 포함해 세션 세부 정보를 담은 markdown 파일이나 GitHub gist를 생성할 수 있습니다.
-
-이제 팀과 공유할 수 있는 GitHub gist를 만들어 보겠습니다.
-
-> [!TIP]
-> **Copilot CLI 세션 시작하기**
->
-> 아래 연습을 시작하기 전에 코드스페이스로 돌아가 터미널을 엽니다(이미 열려 있지 않다면 Ctrl+`). 그런 다음 `--yolo`와 `--enable-all-github-mcp-tools`를 사용해 Copilot CLI를 시작합니다.
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 이 프로젝트의 가장 최근 세션을 새로 시작하지 않고 이어서 사용하려면 `copilot --yolo --enable-all-github-mcp-tools --continue`를 실행합니다. 이전 연습에서 Copilot CLI가 이미 실행 중이라면 `/clear`를 보내 새 대화를 시작합니다.
->
-> `--enable-all-github-mcp-tools`는 현재 세션에서 읽기/쓰기 GitHub MCP 도구를 활성화하므로, 워크숍 흐름 중 Copilot이 백로그를 읽고 pull request를 열 수 있습니다.
-
-> [!CAUTION]
-> `--yolo`는 전체 자동 권한(`--allow-all-tools`, `--allow-all-paths`, `--allow-all-urls`)을 활성화합니다. Codespace나 VM 같은 격리된 환경에서만 사용하고, 일상적인 개발을 위한 기본 별칭으로는 절대 설정하지 않습니다. 자세한 내용은 [Allowing and denying tool use][allow-all-warning]를 참고합니다.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-1. Copilot CLI 프롬프트 창에서 다음 명령을 보냅니다.
-
- ```
- /share gist
- ```
-
-2. 잠시 후 Copilot이 gist를 만들고 링크를 표시합니다.
-3. 링크 텍스트를 복사합니다.
-4. 새 브라우저 탭에 링크를 붙여 넣어 gist를 살펴봅니다. gist에 전송된 프롬프트, 사용한 스킬과 agent, Copilot의 사고 과정, 로컬에서 실행한 명령의 코드와 결과까지 강조되어 있는 점을 확인합니다.
-
-`/share`가 생성하는 gist와 markdown 파일은 코드가 어떻게 생성되었는지 문서화하거나, 원하는 결과를 얻기 위해 Copilot으로 어떤 작업을 수행했는지 팀과 공유하는 용도로 사용할 수 있습니다.
-
-## Copilot CLI의 컨텍스트 살펴보기
-
-더 크거나 복잡한 작업을 수행할 때는 모델의 최대 context window에 도달할 수 있습니다. 창의 정확한 크기는 사용 중인 모델과 Copilot CLI 버전에 따라 달라집니다. Context window가 가득 차면 Copilot CLI는 이를 자동으로 compact하여 정보를 요약하고 현재 작업과 관련이 없다고 판단한 항목을 제거합니다. Slash commands를 사용하면 현재 컨텍스트 상태를 확인할 수도 있고 수동으로 compact할 수도 있습니다. 이제 context window를 살펴보겠습니다.
-
-1. Copilot CLI 프롬프트 창에서 다음 명령을 보냅니다.
-
- ```
- /context
- ```
-
-2. 잠시 후 Copilot CLI가 현재 컨텍스트를 시각적으로 표현한 결과를 생성합니다.
-
- 
-
-3. 표시된 모델(이미지와 다를 수 있음)과 현재 사용된 token 비율을 확인합니다. 나머지 정보는 다음을 보여 줍니다.
-
- | 제목 | 설명 |
- | ------------ | ------------------------------------------------------ |
- | System/Tools | 지침 파일, 파일 내용, 도구 정의 |
- | Messages | 사용자와 Copilot 간의 대화 기록 |
- | Buffer | 응답 생성을 위해 Copilot CLI가 예약한 공간 |
- | Free space | 남아 있는 여유 공간 |
-
-4. 다음 slash command를 Copilot CLI에 보내 대화 기록을 compact합니다.
-
- ```
- /compact
- ```
-
-5. 완료되면 다음 명령을 보내 현재 컨텍스트 통계를 다시 표시합니다.
-
- ```
- /context
- ```
-
-6. 컨텍스트 변화에 주목합니다. 현재 context window가 상대적으로 작을 가능성이 높으므로 큰 차이가 없을 수도 있습니다.
-
-> [!NOTE]
-> Copilot CLI는 컨텍스트가 가득 차면 자동으로 compact를 수행합니다. 용량이 100%에 가까워지면 프롬프트 창 바로 위에 비율을 표시합니다. 일반적으로는 비동기적으로 compact를 수행하므로, 작업 중에도 계속 Copilot과 상호 작용할 수 있습니다. 다만 작업을 수행하는 동안 몇 초간 실행 중인 작업을 차단할 수도 있습니다.
-
-### 컨텍스트 사용 모범 사례
-
-대부분의 세션에서는 Copilot이 별도 지시 없이도 컨텍스트를 효율적으로 관리합니다. 하지만 다음과 같이 히스토리를 직접 지우거나 compact하도록 지시하고 싶어지는 상황도 있을 수 있습니다.
-
-- 애플리케이션의 다른 부분이나 관련 없는 작업으로 전환하는 경우, 오래되고 관련 없는 컨텍스트가 Copilot을 혼란스럽게 하지 않도록 `/clear`를 사용해 새로 시작할 수 있습니다.
-- 최대 context window에 가까워지고 있다면 `/compact`로 수동으로 컨텍스트를 정리해 시점을 직접 제어할 수 있습니다.
-
-> [!CAUTION]
-> 다시 말해 대부분의 시간에는 Copilot이 직접 컨텍스트를 관리합니다. 오래된 정보 때문에 Copilot이 약간 혼란스러워 보이거나 관련 없는 작업으로 전환하려는 경우에만 수동 명령 사용을 고려합니다.
-
-## 모델 선택하기
-
-모델마다 강점이 다르고, 개발자마다 선호도도 다릅니다. Copilot CLI는 사용 가능한 모델을 나열하고 원하는 모델을 선택할 수 있게 해줍니다.
-
-1. Copilot CLI에 다음 slash command를 보내 모델 목록을 표시합니다.
-
- ```
- /model
- ```
-
-2. 모델 목록을 확인합니다. 각 모델 옆에는 이름과 요청당 비용 modifier가 함께 표시됩니다.
-3. 원한다면 새 모델을 선택합니다. 아니면 Esc를 선택해 모델 목록을 종료합니다.
-
-> [!CAUTION]
-> Copilot CLI의 모델 선택은 유지됩니다.
-
-## Cloud agent에 위임하기(선택 사항)
-
-터미널에서 계속 작업하고 싶지만 더 오래 걸리는 작업은 Copilot cloud agent에 넘기고 싶을 때가 있습니다. `/delegate` 명령은 현재 Copilot CLI 세션을 GitHub.com으로 보내고, cloud agent가 이를 받아 비동기적으로 작업한 뒤 완료되면 pull request를 엽니다.
-
-> [!NOTE]
-> `/delegate`에는 cloud agent가 필요합니다. Copilot Student, Pro, Pro+, Business, Enterprise에서 사용할 수 있으며, Copilot Free에서는 사용할 수 없습니다. 액세스 권한이 없다면 이 섹션을 읽고 실습 단계는 건너뜁니다.
-
-1. 워크숍에서 누적된 컨텍스트가 함께 위임되지 않도록 먼저 현재 세션을 지웁니다.
-
- ```
- /clear
- ```
-
-2. 범위가 작고 명확한 프롬프트를 보냅니다. 예를 들어 백로그에 있는 pagination stretch goal을 위임할 수 있습니다.
-
- ```
- Implement pagination on the game list page so it shows a fixed number of games per page with Previous and Next controls, and add tests.
- ```
-
-3. 다음 slash command를 보내 세션을 cloud agent에 넘기고, 위임할 프롬프트를 확인합니다.
-
- ```
- /delegate
- ```
-
-4. 브라우저에서 [Copilot agents](https://github.com/copilot/agents)를 열어 진행 상황을 모니터링합니다.
-5. 이 harness에서는 pull request가 완료될 때까지 기다릴 필요는 없습니다. 나중에 다시 돌아와도 됩니다. 비동기 agent 작업 관리 방법을 더 깊이 알아보고 싶다면 [Cloud agent harness](../../cloud/)를 계속 진행합니다.
-
-## 요약 및 다음 단계
-
-Copilot CLI의 slash commands를 사용하면 구성을 변경하고, 세션을 공유하고, Copilot이 내부적으로 어떻게 동작하는지에 대한 정보를 얻을 수 있습니다. 이 연습에서는 다음을 사용하거나 살펴보았습니다.
-
-- `/share`로 세션을 팀과 공유할 GitHub gist를 만들었습니다.
-- `/context`로 Copilot CLI가 현재 사용 중인 컨텍스트를 확인했습니다.
-- `/model`로 사용 가능한 모델 목록을 살펴보고 원한다면 새 모델을 선택할 수 있음을 확인했습니다.
-- `/delegate`를 cloud agent로 연결하는 선택적 브리지로 학습했습니다.
-
-물론 더 많은 slash commands가 있으며, Copilot CLI로 탐색할 내용도 더 많습니다. 마지막으로 [학습한 내용을 검토하고][next-lesson] 학습을 계속하기 위한 다음 단계를 살펴보며 여정을 마무리하겠습니다.
-
-## 리소스
-
-- [Copilot CLI 사용하기][using-copilot-cli]
-- [Copilot CLI 소개][about-copilot-cli]
-- [Copilot CLI의 컨텍스트 관리][context-management]
-- [Copilot CLI로 세션 공유하기][share-sessions]
-- [Copilot CLI에서 모델 선택하기][selecting-models]
-
-[previous-lesson]: ../6-custom-agents/
-[next-lesson]: ../8-review/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[about-cloud-agent]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
-[share-sessions]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#share-sessions
-[selecting-models]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#select-an-llm
diff --git a/docs/ko-kr/cli/8-create-pull-request.md b/docs/ko-kr/cli/8-create-pull-request.md
new file mode 100644
index 00000000..15e72980
--- /dev/null
+++ b/docs/ko-kr/cli/8-create-pull-request.md
@@ -0,0 +1,99 @@
+---
+title: "연습 8 - 기능 PR 생성 및 병합"
+description: "전체 필터링 마일스톤을 검토하고 현재 QA 근거를 재사용한 후 CI와 검토를 거쳐 세 번째 끌어오기 요청을 병합합니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+이제 필터링 마일스톤을 PR 3으로 통합합니다. 연습 4~7에서 사용한 브랜치와 체크아웃을 유지합니다. 여기에는 필터링 구현, quality-checks 스킬과 스크립트, QA 프로필, 관련 테스트가 포함됩니다.
+
+리포지토리 규칙을 사용하는 일반적인 범위 제한 PR 요청입니다. 기여 스킬은 필요하지 않습니다.
+
+> [!NOTE]
+> 실제 팀은 기능과 재사용 가능한 품질 인프라를 분리할 수 있습니다. 이 워크숍은 하나의 기능 PR에서 전체 워크플로를 보여 주기 위해 의도적으로 통합합니다. 이전 별점과 지침 PR은 이미 `main`에 병합되어 있어야 하며, 관련 없는 작업으로 다시 포함되어서는 안 됩니다.
+
+## 준비 상태와 근거 확인
+
+1. QA 판정과 요구 사항별 근거 매핑을 검토합니다. **NO-GO**, 브라우저 근거 누락, 필수 검사 건너뛰기는 병합 전에 해결해야 할 차단 요인입니다.
+2. lint, 단위 테스트, E2E, 타입 검사 네 가지가 실제로 quality-checks 스킬을 통해 실행되었는지 확인합니다.
+3. 테스트한 리비전과 검사 이후의 변경을 검토합니다. 테스트한 코드, 테스트, 검증 스크립트가 변경되지 않았을 때만 현재 QA 근거를 재사용합니다. 파일 내용이 같다면 체크포인트 커밋만으로 근거가 무효화되지는 않지만, 코드 변경은 근거를 무효화합니다.
+4. 구현이나 테스트 입력이 변경되었다면 관련 스킬 검사와 브라우저 관찰을 다시 실행하고 근거를 갱신합니다. 현재 QA 결과가 여전히 적용된다면 PR을 생성한다는 이유만으로 전체 스위트를 다시 실행하지 않습니다.
+5. 최근 체크포인트나 미커밋 변경뿐 아니라 전체 브랜치 diff를 확인합니다.
+
+동일한 체크아웃의 다른 터미널에서 실행합니다.
+
+```bash
+git status
+git fetch origin
+git log --oneline origin/main..HEAD
+git diff --stat origin/main...HEAD
+git --no-pager diff origin/main...HEAD
+```
+
+점 세 개를 사용하는 diff는 `origin/main`과의 공통 조상 이후 이 브랜치의 변경을 이전 체크포인트까지 포함하여 보여 줍니다. 의도한 필터링 마일스톤만 포함하는지 확인합니다. 새 파일도 확인합니다. 예상하지 못한 추적되지 않은 파일이나 미커밋 파일은 스테이징 전에 검토해야 합니다.
+
+## PR 3 요청
+
+연습 7에서는 체크포인트 전에 일반 **Interactive** 세션으로 돌아왔습니다. QA 프로필이 더 이상 활성 상태가 아니고 필터링 체크아웃과 브랜치가 변경되지 않았다면 그 세션을 계속합니다. 이슈 URL, 계획 중 승인한 추가 합의 사항, 테스트한 리비전과 검사 결과를 포함한 현재 QA 보고서를 준비합니다.
+
+QA 프로필은 QA 중 커밋과 PR 작업을 금지합니다. 아직 활성 상태라면 PR을 요청하기 전에 일반 세션으로 돌아옵니다.
+
+1. QA가 유휴 상태가 될 때까지 기다린 다음 CLI 프롬프트에 `/exit`를 입력합니다. 다른 세션이 활성 상태라 CLI가 계속 열려 있다면 해당 작업을 마치거나 보존합니다. 그 후 일반 프롬프트로 돌아와 Ctrl+D를 눌러 이 CLI 인스턴스를 종료합니다.
+2. 셸 프롬프트에서 동일한 필터링 체크아웃과 브랜치를 유지합니다. 둘을 확인한 후 `--agent qa`나 재개 플래그 없이 새로운 일반 세션을 시작합니다.
+
+ ```bash
+ pwd
+ git branch --show-current
+ git status
+ copilot
+ ```
+
+3. **Interactive** 모드이고 QA 프로필이 더 이상 활성 상태가 아닌지 확인합니다. 다른 워크트리를 만들거나 브랜치를 변경하거나 QA 세션을 재개하지 않습니다.
+
+아래의 모든 플레이스홀더를 실제 이슈 URL, 승인한 추가 합의 사항, 현재 QA 근거로 바꿉니다. 연습 7의 일반 세션을 유지했더라도 명시적으로 제공합니다. 새 대화가 QA 세션의 기억에 의존해서는 안 됩니다.
+
+```plaintext
+다음 이슈의 필터링 기능 PR을 준비해 주십시오: . 계획 중 승인한 추가 수락 기준은 다음과 같습니다: <합의한 추가 내용을 붙여 넣거나 없으면 none 입력>. 현재 QA 근거는 다음과 같습니다: <테스트한 리비전, 브라우저 관찰, 커버리지 평가, 네 가지 검사 결과, 한계를 포함한 QA 보고서 붙여 넣기>.
+
+체크아웃과 현재 필터링 브랜치를 확인해 주십시오. main에 대한 전체 diff, 마일스톤의 모든 체크포인트 커밋, git status, 리포지토리 PR 템플릿, 제공된 QA 근거를 확인해 주십시오. 검토한 필터링 구현, quality-checks 스킬과 함께 제공되는 스크립트, QA 에이전트 정의, 관련 테스트만 포함해 주십시오.
+
+QA 결과가 최종 파일 내용을 여전히 설명하는 동안에는 재사용해 주십시오. 이후 코드, 테스트, 검증 스크립트가 바뀌었다면 보고하고, 최신 결과로 제시하기 전에 스킬을 통한 관련 검사와 영향을 받는 브라우저 검증을 실행해 주십시오. 실패하거나 차단되거나 건너뛴 검사를 통과로 표시하지 마십시오.
+
+필요하다면 검토한 마일스톤의 남은 변경을 커밋하고 현재 브랜치를 푸시한 후, 리포지토리 규칙에 따라 main을 대상으로 PR 하나를 만들어 주십시오. 이슈와 승인된 기준, 구현 요약, 추가한 테스트 또는 추가할 필요가 없었던 이유, 브라우저 관찰, 네 가지 검사 결과, 남은 한계를 포함해 주십시오. 병합하거나 다른 브랜치를 만들거나 기여 스킬을 호출하거나 다른 기능을 시작하지 마십시오.
+```
+
+## PR과 CI 검토
+
+반환된 URL을 열고 전체 PR의 **Files changed**를 확인합니다. 스킬의 스크립트와 QA 프로필이 포함되었는지, 자격 증명, 로컬 MCP 설정, 관련 없는 파일, 생성된 보고서, 의존성 설치 변경이 diff에 섞이지 않았는지 확인합니다.
+
+PR의 **Checks** 탭을 사용하거나 기능 브랜치의 터미널에서 다음 명령을 실행합니다.
+
+```bash
+gh pr view
+gh pr diff
+gh pr checks --watch
+```
+
+초록색 배지가 모든 종류의 검증을 포함한다고 가정하지 말고 리포지토리의 `.github/workflows/`를 확인합니다. 현재 Tailspin **Run tests** 워크플로는 빌드된 정적 사이트를 대상으로 lint, 타입 검사, Vitest 단위 테스트, Playwright E2E 테스트를 실행합니다. 이는 QA 보고서의 직접적인 MCP 브라우저 관찰을 대체하지 않습니다. 워크숍 사이트의 Astro 빌드와 링크 검사는 다른 리포지토리를 검증합니다.
+
+검사가 실패하면 로그를 확인하고 원인을 해결합니다. 범위를 좁힌 수정은 푸시 전에 업데이트된 리비전에서 검토하고 재검증해야 합니다. `main` 변경으로 충돌을 해결하면서 기능이 바뀌었다면 영향을 받는 근거도 갱신합니다. 필요한 사람의 검토를 기다립니다. 에이전트 자체의 승인은 브랜치 보호를 무시하지 못합니다.
+
+## 병합 및 로컬 main 업데이트
+
+PR이 모든 검토와 검사 요구 사항을 충족하면 GitHub에서 **Merge pull request**를 명시적으로 선택하고 병합을 확정합니다. PR 3이 **Merged**인지 확인합니다.
+
+`/exit`로 CLI 세션을 종료합니다. 작업 트리에 미커밋 변경이 없는 상태에서 로컬 체크아웃을 업데이트합니다.
+
+```bash
+git status
+git switch main
+git pull --ff-only
+```
+
+다음 연습에는 새 브랜치가 필요하지 않습니다. 이제 별점, 지침과 실증, 필터링과 품질 스킬·QA 프로필·테스트라는 정확히 세 개의 워크숍 PR을 병합했습니다.
+
+[연습 9 - 슬래시 명령과 CLI 옵션 살펴보기][next-lesson]로 계속합니다. 또 다른 구현 작업이 아니라 범위를 제한하여 CLI 조작 방법을 살펴봅니다.
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-slash-commands/
diff --git a/docs/ko-kr/cli/8-review.md b/docs/ko-kr/cli/8-review.md
deleted file mode 100644
index be6b5ec5..00000000
--- a/docs/ko-kr/cli/8-review.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: "연습 8 - 검토 및 다음 단계"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-지난 여러 연습에서 다음을 포함해 GitHub Copilot CLI의 가장 일반적인 사용 사례를 살펴보았습니다.
-
-- GitHub 및 다른 MCP server와 상호 작용하기
-- 지침 파일을 사용해 코드 생성을 안내하기
-- 스킬을 구현해 Copilot CLI 도구 상자에 새 도구를 추가하기
-- 고급 작업과 더 복잡한 작업을 위해 커스텀 agent 호출하기
-- Slash commands를 사용해 세션을 관리하고, 선택적으로 `/delegate`를 통해 cloud agent로 다시 연결하기
-
-이제 몇 가지 slash commands, 모범 사례, 다음 단계를 정리해 보겠습니다.
-
-## 슬래시 명령
-
-Copilot CLI에는 이를 제어하거나 내부에서 무슨 일이 일어나고 있는지 확인할 수 있는 다양한 slash commands가 있습니다. 이미 현재 컨텍스트를 지우고 새 채팅을 시작하는 `/clear`, MCP server를 검사하고 관리하는 `/mcp`를 사용해 보았습니다. 추가로 유용할 수 있는 명령은 다음과 같습니다.
-
-| 명령 | 설명 |
-| ------------------ | ------------------------------------------------------------- |
-| `/add-dir` | Copilot의 신뢰 목록에 디렉터리를 추가합니다 |
-| `/clear`, `/new` | 대화 기록을 지우고 새로 시작합니다 |
-| `/compact` | 컨텍스트 창 사용량을 줄이기 위해 대화 기록을 요약합니다 |
-| `/context` | 컨텍스트 창 token 사용량과 시각화를 보여 줍니다 |
-| `/diff` | 현재 디렉터리에서 이루어진 변경 사항을 검토합니다 |
-| `/model` | 사용할 AI 모델을 선택합니다(Claude Sonnet, GPT-5 등) |
-| `/plan ` | 코딩 전에 구현 계획을 만듭니다 |
-| `/review ` | 변경 사항을 분석하도록 코드 리뷰 agent를 실행합니다 |
-| `/delegate` | 비동기 처리를 위해 작업을 Copilot cloud agent에 위임합니다 |
-| `/session` | 세션 정보와 작업 공간 요약을 보여 줍니다 |
-| `/share` | 세션을 markdown 파일 또는 GitHub gist로 공유합니다 |
-| `/skills` | 향상된 기능을 위한 스킬을 관리합니다 |
-| `/usage` | 세션 사용량 지표와 통계를 표시합니다 |
-
-> [!TIP]
-> `/help`를 사용하면 전체 명령 목록과 keyboard shortcuts를 확인할 수 있습니다.
-
-## 모범 사례
-
-어떤 AI 도구를 사용하든, 그 결과물의 품질은 기반 인프라에 크게 좌우됩니다. 강력한 지침 파일, 커스텀 에이전트, 에이전트 스킬은 모두 중요한 역할을 하며, 이 워크숍에서 각각을 살펴보았습니다. [Awesome-copilot][awesome-copilot]은 템플릿을 찾기에 좋은 자료이며, Copilot 자체도 시작점을 마련할 수 있도록 이러한 요소를 스캐폴드해 줄 수 있습니다.
-
-인프라만큼이나 컨텍스트도 중요합니다. *무엇을* 만들고 싶은지, *왜* 필요한지, *어떻게* 만들고 싶은지를 명확하게 설명하면 결과가 크게 달라집니다. Copilot에 도움이 될 만한 정보라면 반드시 전달합니다.
-
-## 다음 단계
-
-도구 사용 능력을 향상하는 가장 좋은 방법은 계속 사용하는 것입니다. 운영 코드에도, 취미 프로젝트에도, 오랫동안 마음속에 있었지만 아직 만들지 못한 작은 앱에도 사용해 봅니다. 학습한 내용을 팀과 공유하고, 팀으로부터도 배웁니다. 그리고 늘 그렇듯 문서를 계속 탐색합니다.
-
-GitHub Copilot 생태계를 더 살펴보고 싶다면 [VS Code harness](../../vscode/) 또는 [Cloud agent harness](../../cloud/)를 확인합니다.
-
-## 리소스
-
-- [Copilot CLI 소개][about-copilot-cli]
-- [Copilot CLI 사용하기][using-copilot-cli]
-- [Awesome Copilot 리포지토리][awesome-copilot]
-- [커스텀 지침 가이드][repo-instructions]
-- [에이전트 스킬 문서][agent-skills]
-- [커스텀 에이전트 문서][custom-agents]
-- [MCP 사양][mcp-spec]
-
-[previous-lesson]: ../7-slash-commands/
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[repo-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
-[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[mcp-spec]: https://modelcontextprotocol.io/
diff --git a/docs/ko-kr/cli/9-slash-commands.md b/docs/ko-kr/cli/9-slash-commands.md
new file mode 100644
index 00000000..5065845e
--- /dev/null
+++ b/docs/ko-kr/cli/9-slash-commands.md
@@ -0,0 +1,88 @@
+---
+title: "연습 9 - 슬래시 명령과 CLI 옵션 살펴보기"
+description: "다른 기능을 시작하지 않고 컨텍스트, 모델과 세션 조작, 공유 대상, CLI 플래그를 확인합니다."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+세 번의 PR 마일스톤을 완료했습니다. 이제 세션을 이해하고 관리하는 데 도움이 되는 CLI 조작 방법을 살펴봅니다. 이 연습에서는 다른 기능을 구현하거나 작업을 위임하거나 다른 PR을 만들지 않습니다.
+
+업데이트된 학습용 체크아웃에서 **Interactive** 모드로 `copilot`을 시작합니다. `/help`와 [명령 참조][cli-reference]를 사용하여 설치된 버전이 지원하는 명령을 확인합니다. 현재 문서에는 설치된 버전보다 새로운 조작 방법이 설명되어 있을 수 있습니다.
+
+## 컨텍스트와 세션 정보 확인
+
+1. 범위가 제한된 읽기 전용 요청을 보냅니다.
+
+ ```plaintext
+ 리포지토리의 지침 파일, quality-checks 스킬, QA 프로필을 요약해 주십시오. 필터링 검증에 어떻게 도움이 되는지 설명해 주십시오. 파일을 수정하거나 검사를 실행하거나 작업을 위임하거나 커밋하거나 PR을 만들지 마십시오.
+ ```
+
+2. `/context`를 입력해 컨텍스트 윈도 사용량을 확인합니다. 메시지, 지침, 도구 정의가 컨텍스트를 어떻게 사용하는지 살펴봅니다.
+3. `/compact`를 입력하고 다시 `/context`를 입력합니다. 압축은 기록을 요약하여 크기를 줄입니다. 짧은 세션에서는 변화가 작을 수 있습니다.
+4. `/session`으로 현재 세션을 확인하고 `/usage`로 사용량 정보를 확인합니다.
+
+압축이 요구 사항 제공을 대체하지는 않습니다. 작업이나 에이전트를 바꿀 때 이슈 URL, 승인된 기준, 체크아웃 식별 정보, 관련 근거를 명시적으로 전달합니다.
+
+`/clear`는 새 대화를 시작하지만 파일을 되돌리거나 Git 브랜치를 전환하지는 않습니다. `/resume`은 이전 작업으로 돌아가기 위한 세션 선택기를 엽니다. 선택기를 살펴본 후 Esc를 눌러 다른 작업을 재개하지 않고 닫습니다. 수락 기준의 유일한 사본을 지우거나 대화를 재개하면 오래된 검증도 여전히 유효하다고 가정하지 않습니다.
+
+## 모델과 모드 확인
+
+`/model`을 입력하여 제공되는 경우 **Auto**를 포함해 계정에서 사용 가능한 모델을 확인합니다. 선택 세부 사항과 사용량 정보를 읽습니다. 모델 가용성과 가격은 바뀔 수 있습니다. Esc를 눌러 모델을 변경하지 않고 선택기를 닫습니다. 모델을 변경했다면 표시된 선택과 해당 CLI 버전의 적용 범위를 확인합니다.
+
+Shift+Tab으로 **Interactive**, **Plan**, **Autopilot**을 순환하며 모드 표시를 확인한 후, 구현 프롬프트를 보내지 않고 **Interactive**로 돌아옵니다. 다음 차이를 기억합니다.
+
+- Plan은 코딩 전에 작업에 합의하기 위한 모드입니다.
+- Autopilot은 승인된 범위 제한 작업을 계속합니다.
+- Interactive는 의식적인 검토와 결정 시점을 제공합니다.
+- 권한은 허용되는 도구 작업을 별도로 제어합니다.
+
+## 명령줄 옵션 확인
+
+별도 터미널에서 실행합니다.
+
+```bash
+copilot --help
+```
+
+문서에 나오는 다음 옵션을 설치된 버전의 도움말과 비교합니다.
+
+| 옵션 | 목적 |
+| --- | --- |
+| `--model MODEL` | 실행할 모델을 선택합니다. 먼저 가용성을 확인합니다 |
+| `--agent AGENT` | 실행할 사용자 지정 에이전트를 선택합니다 |
+| `-p PROMPT` | 프롬프트를 프로그래밍 방식으로 실행하고 완료되면 종료합니다 |
+| `--output-format json` | 한 줄에 JSON 객체 하나씩 구조화된 JSONL을 출력합니다 |
+| `--resume` | 기존 세션을 재개합니다 |
+| `--enable-all-github-mcp-tools` | 기본 제공 GitHub MCP의 전체 도구를 노출합니다 |
+
+이 옵션은 이해할 조작 방법이며 새 작업을 시작하라는 뜻이 아닙니다. 프로그래밍 방식 모드는 실제 도구 작업을 실행할 수 있습니다. JSON 출력 형식이 요청을 읽기 전용으로 만들지는 않습니다. 에이전트 선택은 [연습 7][qa-lesson]에서 검증한 워크플로를 따릅니다. 사용자 지정 에이전트 활성화를 기본 에이전트에게 프로필을 읽으라고 요청하는 방식으로 대체해서는 안 됩니다. 권한과 액세스 제한은 계속 적용됩니다.
+
+## 공유 전 검토
+
+`/share`는 세션 내용을 여러 대상으로 보낼 수 있습니다. [CLI 명령 참조][cli-reference]에는 Markdown 내보내기용 `/share file [session|research] [PATH]`와 gist 게시용 `/share gist [session|research]`가 설명되어 있습니다. 하위 명령이 없으면 현재 문서상으로는 로그인 및 동기화 상태에서 공유 가능한 GitHub 링크를 만들고, 그렇지 않으면 Markdown으로 내보냅니다. 내용 미리 보기만 한다고 가정하여 하위 명령 없이 실행하지 않습니다.
+
+이 워크숍에서는 게시하는 대신 로컬 세션 내보내기와 파일명을 명시적으로 선택합니다.
+
+```text
+/share file session cli-session-review.md
+```
+
+내보낸 파일을 편집기에서 열고 실제 내용을 확인합니다. 프롬프트, 응답, 도구 출력, 파일 경로, 리포지토리 데이터, 자격 증명이나 개인 정보를 검토합니다. 모든 내부 단계가 포함되었거나 민감한 내용이 자동으로 제거되었다고 가정하지 않습니다.
+
+> [!CAUTION]
+> Gist나 공유 링크는 외부 공개입니다. 비밀 gist는 비공개 액세스 제어가 아닙니다. URL을 아는 사람은 누구나 볼 수 있습니다. 공유 전에 대상, 수신자, 권한, 조직 정책을 확인합니다. 민감한 내용을 제거해야 한다면 검토하고 해당 내용을 제거한 자료만 승인된 경로로 공유하며, 그 후 원본 세션을 게시하지 않습니다.
+
+이 내보내기 파일을 기능 PR과 리포지토리 기록에 포함하지 않습니다. 확인한 후 방금 생성한 파일을 삭제하거나 승인된 로컬 메모 위치로 옮깁니다. 관련 없는 파일은 삭제하지 않습니다.
+
+Cloud 위임은 원격 작업과 추가 PR을 생성할 수 있으므로 여기서는 `/delegate`를 실행하지 않습니다. [Cloud 에이전트 워크숍][cloud-workshop]에서 해당 별도 워크플로를 다룹니다.
+
+## 요약 및 다음 단계
+
+다른 기능을 시작하지 않고 컨텍스트, 사용량, 모델과 모드 조작, 명령줄 옵션, 공유 대상을 확인했습니다. [연습 10 - 마무리 및 다음 단계][next-lesson]에서 구축한 워크플로와 자산을 검토합니다.
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[qa-lesson]: ../7-qa-agent/
+[cloud-workshop]: ../../cloud/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/ko-kr/cli/README.md b/docs/ko-kr/cli/README.md
index 82f069d0..f0f86057 100644
--- a/docs/ko-kr/cli/README.md
+++ b/docs/ko-kr/cli/README.md
@@ -3,12 +3,12 @@ slug: ko-kr/cli
title: "GitHub Copilot CLI"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
[**GitHub Copilot CLI**](https://docs.github.com/copilot/concepts/agents/about-copilot-cli)는 터미널에서 GitHub Copilot을 에이전트형 코딩 도우미로 사용할 수 있게 해줍니다. 코드베이스를 탐색하고, 코드를 생성하고, 명령을 실행하고, 외부 도구에 연결하는 작업을 모두 명령줄에서 처리하므로 그래픽 편집기로 전환하지 않고도 작업 흐름을 유지할 수 있습니다.
-이 연습 전체에서 Copilot CLI를 설치하고 인증한 다음, 커스텀 지침으로 프로젝트 컨텍스트를 제공한 뒤 plan mode를 사용해 의도적으로 기능을 생성합니다. 이어서 Playwright MCP server를 연결해 실제 브라우저에서 해당 기능을 테스트하고, 재사용 가능한 agent skills와 custom agents로 Copilot을 확장합니다. 마지막으로 slash commands로 컨텍스트, 모델, 공유를 관리하는 방법을 살펴보고, 완성한 내용을 검토합니다.
+연습 0~1에서 설정한 후 연습 2~10의 아홉 개 핵심 모듈을 완료합니다. 별점 추가로 작은 성과를 얻고, 문서화 지침을 정립한 다음, **Plan**과 **Autopilot** 모드로 필터링을 구축합니다. 이어서 재사용 가능한 quality-checks 스킬을 만들고 Playwright MCP로 동작을 검증하며 QA 에이전트를 만들어 기능을 제공합니다. 마지막으로 CLI 조작 방법과 완성한 내용을 살펴봅니다.
## 연습
@@ -16,13 +16,21 @@ lastUpdated: 2026-06-30
|----------|-------|-------------|
| [0. 사전 준비][ex0] | 설정 | 리포지토리(Repository)와 코드스페이스(Codespace)를 만듭니다 |
| [1. Copilot CLI 설치][ex1] | 설치 | Copilot CLI를 설치하고 인증합니다 |
-| [2. 커스텀 지침][ex2] | 컨텍스트 | 지침을 추가하고 Copilot CLI가 이를 따르는 모습을 확인합니다 |
-| [3. 코드 생성][ex3] | 코드 생성 | plan mode를 사용해 기능을 생성합니다 |
-| [4. Playwright MCP로 테스트][ex4] | 외부 도구 | Playwright MCP server를 추가하고 브라우저에서 기능을 테스트합니다 |
-| [5. 에이전트 스킬][ex5] | 스킬 | 특화된 스킬로 Copilot을 강화합니다 |
-| [6. 커스텀 에이전트][ex6] | 에이전트 | 커스텀 에이전트를 검토하고 사용합니다 |
-| [7. 슬래시 명령][ex7] | CLI 기능 | 컨텍스트, 모델, 공유, 그리고 선택적으로 cloud agent 위임을 살펴봅니다 |
-| [8. 검토][ex8] | 요약 | 핵심 개념과 다음 단계를 검토합니다 |
+| [2. 별점 추가로 작은 성과 얻기][ex2] | 첫 변경 | 기존 별점을 표시하고 검증한 후 PR 1을 병합합니다 |
+| [3. 사용자 지정 지침으로 Copilot 안내][ex3] | 컨텍스트 | 문서화 규칙을 추가하고 실증한 후 PR 2를 병합합니다 |
+| [4. Plan과 Autopilot으로 필터링 구축][ex4] | 구현 | 계획을 검토하고 Autopilot을 승인한 후 테스트하고 체크포인트를 저장합니다 |
+| [5. quality-checks 스킬 만들기 및 사용][ex5] | 스킬 | 셸 스크립트를 포함한 검사를 생성하고 검토하고 실행합니다 |
+| [6. Playwright MCP로 기능 검증][ex6] | 브라우저 도구 | 실제 브라우저에서 필터링 동작을 관찰합니다 |
+| [7. QA 에이전트 만들기 및 사용][ex7] | 에이전트 | 요구 사항과 커버리지를 평가하고 최종 근거를 수집합니다 |
+| [8. 기능 PR 생성 및 병합][ex8] | 제공 | 필터링과 재사용 가능한 사용자 지정을 PR 3에서 함께 검토합니다 |
+| [9. 슬래시 명령과 CLI 옵션 살펴보기][ex9] | CLI 조작 | 컨텍스트, 모델, 세션, 공유 대상을 확인합니다 |
+| [10. 마무리 및 다음 단계][ex10] | 요약 | 공통 자산과 세 번의 PR 마일스톤을 검토합니다 |
+
+## 브랜치와 끌어오기 요청
+
+별점, 지침과 작은 실증, 필터링과 quality-checks 스킬·QA 프로필·관련 테스트를 담은 세 개의 끌어오기 요청을 병합합니다. 처음 두 PR은 각각 병합한 후 업데이트된 `main`에서 다음 마일스톤을 시작합니다.
+
+연습 4~8은 하나의 기능 브랜치와 체크아웃을 공유합니다. 진행 중 체크포인트 커밋을 저장합니다. 스킬 생성, MCP 설정, QA 선택 시 새 기능 브랜치를 만들지 않습니다. 연습 9에서는 다른 기능이나 PR을 시작하지 않고 조작 방법을 살펴봅니다.
## 사전 준비
@@ -46,10 +54,12 @@ lastUpdated: 2026-06-30
[ex0]: 0-prerequisites/
[ex1]: 1-install-copilot-cli/
-[ex2]: 2-custom-instructions/
-[ex3]: 3-generating-code/
-[ex4]: 4-mcp/
+[ex2]: 2-add-star-rating/
+[ex3]: 3-custom-instructions/
+[ex4]: 4-build-filtering/
[ex5]: 5-agent-skills/
-[ex6]: 6-custom-agents/
-[ex7]: 7-slash-commands/
-[ex8]: 8-review/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-slash-commands/
+[ex10]: 10-review/
diff --git a/docs/pt-br/README.md b/docs/pt-br/README.md
index 6e3709b9..67cb5910 100644
--- a/docs/pt-br/README.md
+++ b/docs/pt-br/README.md
@@ -3,7 +3,7 @@ slug: pt-br
title: "Mãos à obra com os agentes do GitHub Copilot"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
As adições recentes aos recursos do GitHub Copilot oferecem ferramentas avançadas para apoiar pessoas desenvolvedoras durante todo o ciclo de vida de desenvolvimento de software (SDLC). Isso inclui trabalhar com problemas e solicitações de pull no GitHub, interagir com serviços externos e, é claro, criar código. Este laboratório explora esses recursos e apresenta casos de uso reais e dicas para aproveitar as ferramentas ao máximo.
@@ -17,19 +17,19 @@ As adições recentes aos recursos do GitHub Copilot oferecem ferramentas avanç
O GitHub Copilot acompanha você onde quer que trabalhe. Escolha o ambiente que corresponde à forma como você quer desenvolver e conclua os exercícios usando um backlog compartilhado da Tailspin Toys. Cada ambiente começa com sua própria configuração, para que você possa ir direto ao que escolheu.
-### 🖥️ [VS Code](../vscode/)
+### 🖥️ [VS Code](vscode/)
GitHub Copilot no **Visual Studio Code** e no GitHub Codespaces. Trabalhe com o modo de agente do Copilot Chat, servidores MCP e agentes personalizados sem sair do editor que você já usa — ideal para integrar a assistência de IA diretamente ao seu IDE.
### 💻 [Copilot CLI](cli/)
-**GitHub Copilot CLI** — um assistente baseado em agentes que é executado no terminal. Instale-o, conecte servidores MCP, gere código com o modo de planejamento e crie suas próprias habilidades, agentes personalizados e comandos de barra, tudo pela linha de comando.
+**GitHub Copilot CLI** — um assistente baseado em agentes que é executado no terminal. Após a configuração, siga nove módulos principais: entregue uma melhoria rápida de avaliações por estrelas, estabeleça instruções, planeje e crie a filtragem, crie uma skill quality-checks, valide pelo MCP do Playwright, crie um agente QA e faça o merge do recurso. Termine com os controles da CLI e um resumo. O fluxo tem três marcos de pull request.
### 🤖 [Aplicativo Copilot](app/)
-O **aplicativo GitHub Copilot** — um aplicativo para desktop criado com base no Copilot CLI. Execute sessões paralelas de agentes, alterne entre modos de sessão, colabore em telas e gerencie problemas e solicitações de pull do GitHub de forma nativa — incluindo o **Agent Merge**, que conduz uma solicitação de pull por rebases, comentários de revisão, correções de CI e mesclagem.
+O **aplicativo GitHub Copilot** — um aplicativo para desktop criado com base no Copilot CLI. Siga a mesma configuração e os nove módulos principais do fluxo de avaliações por estrelas, instruções, filtragem, skill, MCP, QA e PR do recurso, usando as sessões isoladas do aplicativo e o **Agent Merge**. Crie e integre um canvas salvo no repositório como quarto marco de pull request e conclua com o resumo.
-### ☁️ [Agente de nuvem do Copilot](../cloud/)
+### ☁️ [Agente de nuvem do Copilot](cloud/)
**Agente de nuvem do Copilot** — um programador parceiro assíncrono que trabalha em problemas do GitHub em segundo plano. Atribua tarefas, oriente-o com agentes personalizados, acompanhe o progresso no painel de agentes e revise as solicitações de pull que ele abre.
diff --git a/docs/pt-br/app/0-prerequisites.md b/docs/pt-br/app/0-prerequisites.md
index 13492034..6439b13e 100644
--- a/docs/pt-br/app/0-prerequisites.md
+++ b/docs/pt-br/app/0-prerequisites.md
@@ -15,18 +15,18 @@ Nesta lição, você vai:
## Instalar o Node.js
-Em várias lições, você pedirá a um agente que crie recursos e execute localmente o conjunto de testes do Tailspin Toys. Para isso, é necessário o [**Node.js**][nodejs], o único ambiente de execução exigido pelo projeto. Instale a versão **22 ou posterior**; a versão **LTS** atual é uma escolha segura.
+Em várias lições, você pedirá a um agente que crie recursos e execute localmente o conjunto de testes do Tailspin Toys. Para isso, é necessário o [**Node.js**][nodejs]. Use **Node.js 22.13 ou posterior** e confirme a versão compatível em `package.json` e README da sua cópia de trabalho.
A opção mais simples em todas as plataformas é o instalador oficial:
1. No sistema operacional, abra uma janela de terminal usando o Windows Terminal, o Terminal do macOS ou o aplicativo que você costuma usar.
-2. Execute o comando a seguir para confirmar que você tem o Node.js 22 ou posterior instalado:
+2. Execute o comando a seguir para confirmar que você tem o Node.js 22.13 ou posterior instalado:
```shell
node --version
```
-3. Se você vir `v22` ou um número maior, pule para a próxima seção.
+3. Se a versão informada for pelo menos `v22.13.0` e compatível com o projeto, pule para a próxima seção.
> [!TIP]
> Você só precisa concluir estas etapas se não tiver o Node instalado ou se precisar atualizá-lo.
@@ -41,10 +41,10 @@ A opção mais simples em todas as plataformas é o instalador oficial:
node --version
```
-9. Você deve ver `v22.x.x` ou posterior.
+9. Confirme que a versão informada é pelo menos `v22.13.0` e compatível com o projeto.
-> [!TIP]
-> Prefere contêineres? Se você tem o [**Docker**][docker], pode usar o [contêiner de desenvolvimento][dev-containers] do repositório em vez de instalar o Node.js localmente. Ele já inclui o Node. Você não precisa dos dois.
+> [!IMPORTANT]
+> Este percurso do aplicativo usa worktrees locais. Um runtime instalado apenas em um contêiner não está disponível para essas sessões locais. Cada worktree também precisa das dependências do projeto e do Chromium do Playwright para verificações E2E. Siga o README do repositório do participante ao preparar um worktree e revise qualquer solicitação de instalação antes de aprová-la.
## Configurar o repositório do laboratório
@@ -64,6 +64,8 @@ Você trabalhará na sua própria cópia do projeto Tailspin Toys. Crie-a agora
> [!NOTE]
> Quando você cria o repositório a partir do modelo, um backlog de issues do GitHub é criado automaticamente. Você trabalhará com essas issues durante todo o workshop e não precisará criar nenhuma.
+Use uma cópia nova do modelo revisado: ele inclui instruções do repositório, código da aplicação, testes e uma extensão de canvas existente, mas não inclui agentes personalizados nem skills. Você criará sua própria skill quality-checks e um perfil QA durante o workshop. Se usar uma cópia mais antiga, examine as personalizações existentes em vez de sobrescrevê-las.
+
## Resumo e próximos passos
Tudo pronto! Você instalou o Node.js para criar e testar o projeto no seu computador e criou sua própria cópia do repositório Tailspin Toys a partir do modelo.
@@ -79,7 +81,5 @@ Em seguida, você instalará o aplicativo GitHub Copilot, conectará o repositó
[next-lesson]: ../1-install-copilot-app/
[nodejs]: https://nodejs.org/
[node-download]: https://nodejs.org/en/download
-[docker]: https://www.docker.com/products/docker-desktop/
-[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
[template-repository]: https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-template-repository
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/pt-br/app/1-install-copilot-app.md b/docs/pt-br/app/1-install-copilot-app.md
index 22bf82e5..d7065f63 100644
--- a/docs/pt-br/app/1-install-copilot-app.md
+++ b/docs/pt-br/app/1-install-copilot-app.md
@@ -41,23 +41,23 @@ Como você pode imaginar, a primeira etapa para usar o aplicativo GitHub Copilot
Com o projeto conectado, reserve um momento para conhecer o espaço de trabalho. O aplicativo organiza tudo em algumas áreas na barra lateral:
-- **Sessions**: onde os agentes trabalham. Cada sessão é executada em seu próprio espaço de trabalho isolado, permitindo executar várias sessões ao mesmo tempo sem que as alterações entrem em conflito. Você iniciará sua primeira sessão na próxima lição.
+- **Sessions**: onde os agentes trabalham. Neste workshop, escolha **new working tree** para que cada marco de PR tenha uma cópia de trabalho e uma branch isoladas. Existem outras opções de espaço de trabalho, mas elas não são usadas aqui.
- **Quick chats**: conversas leves para perguntas e brainstorming que não precisam de branch ou espaço de trabalho próprios. Você experimentará uma ao final desta lição.
- **My work**: suas issues e pull requests, exibidos por meio da **integração nativa com o GitHub**. Nessa área, você pode procurar e filtrar issues e pull requests, verificar o status da CI, iniciar uma sessão a partir de uma issue e revisar pull requests sem sair do aplicativo.
-- **Automations**: tarefas de agente salvas que são executadas em uma agenda ou sob demanda. Você criará uma perto do fim deste percurso.
+- **Customize**: descubra e gerencie servidores MCP, skills e canvases. Você usará essa área para configurar o MCP do Playwright.
+- **Automations**: tarefas de agente salvas que são executadas em uma agenda ou sob demanda. O encerramento traz links para elas como próximo passo, não como outro exercício do workshop.
### Localizar o backlog criado pelo modelo
Como o aplicativo tem integração nativa com o GitHub, o trabalho pendente no repositório aparece dentro dele. Quando você criou o repositório a partir do modelo, um backlog de issues foi criado. Vamos confirmar que ele está disponível.
1. Selecione **My work** na barra lateral.
-2. O modelo criou oito issues no seu backlog. Este módulo foca nas três a seguir — confirme que você consegue vê-las:
+2. Encontre estas issues pelo título em vez de presumir seus números:
- Allow users to filter games by category and publisher
- Update our repository coding standards
- - Implement pagination on the game list page
-3. Selecione uma issue para ler os detalhes. Cada issue também serve como ponto de partida para uma sessão de agente. Você começará a trabalhar com elas mais adiante neste percurso.
+3. Selecione uma issue para ler os detalhes. Cada issue também serve como ponto de partida para uma sessão de agente. Você começará a trabalhar com elas mais adiante neste percurso. Outras issues do backlog fornecem contexto para o canvas, não outra tarefa de implementação.
> [!NOTE]
> A lista de itens em My work é filtrada automaticamente para exibir somente itens dos repositórios adicionados ao aplicativo Copilot. Quer ver itens de trabalho de outros repositórios? Adicione-os ao aplicativo.
@@ -70,7 +70,7 @@ Uma ótima maneira de se familiarizar com o aplicativo é usá-lo para saber mai
2. Pergunte ao aplicativo como funcionam as próprias sessões:
```plaintext
- How does the GitHub Copilot app use worktrees?
+ Como o aplicativo GitHub Copilot usa worktrees?
```
3. Leia a resposta na visualização da conversa. Você verá que cada sessão é executada em seu próprio git worktree isolado, o que permite executar vários agentes em paralelo sem que as alterações entrem em conflito. Você pode continuar a conversa ou iniciar um novo chat a qualquer momento.
@@ -84,7 +84,13 @@ Parabéns! Você instalou o aplicativo GitHub Copilot, conectou o projeto e expl
- conhecer o espaço de trabalho e localizar o backlog criado em **My work**.
- usar um chat rápido para fazer uma pergunta rápida e descartável.
-Em seguida, você iniciará sua primeira sessão de agente e fará a primeira alteração no projeto: exibir uma avaliação por estrelas nos cards dos jogos. Continue para a [Lição 2 - Executar sua primeira sessão de agente][next-lesson].
+## Manter os marcos de PR separados
+
+Você fará o merge de quatro PRs: avaliações por estrelas; instruções com uma pequena demonstração; filtragem com a skill, o perfil QA e os testes; e, por fim, o canvas de triagem. Use uma branch por marco de PR. As Lições 4–8 permanecem na mesma sessão, worktree e branch de filtragem, com commits de checkpoint em vez de PRs adicionais.
+
+Um novo worktree do aplicativo pode começar com um estado local desatualizado. Antes de editar arquivos em cada novo marco, busque as atualizações do repositório e avance a branch da nova sessão por fast-forward até o `origin/main` mais recente. As próximas lições mostram isso explicitamente. Não empilhe branches, não aplique cherry-pick de trabalhos anteriores nem mude uma sessão de filtragem ativa para outra branch.
+
+Em seguida, você iniciará sua primeira sessão de agente e fará a primeira alteração no projeto: exibir uma avaliação por estrelas nos cards dos jogos. Continue para a [Lição 2 - Adicionar avaliações por estrelas: uma melhoria rápida][next-lesson].
## Recursos
@@ -92,7 +98,7 @@ Em seguida, você iniciará sua primeira sessão de agente e fará a primeira al
- [Introdução ao aplicativo GitHub Copilot][getting-started]
- [Trabalhar com sessões de agente no aplicativo GitHub Copilot][agent-sessions]
-[ex0]: ../0-prerequisites/
+[previous-lesson]: ../0-prerequisites/
[next-lesson]: ../2-add-star-rating/
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
diff --git a/docs/pt-br/app/10-review.md b/docs/pt-br/app/10-review.md
new file mode 100644
index 00000000..fbc78050
--- /dev/null
+++ b/docs/pt-br/app/10-review.md
@@ -0,0 +1,87 @@
+---
+title: "Lição 10 - Revisão e próximos passos"
+description: "Recapitule os nove módulos principais do aplicativo, os quatro marcos de PR e o fluxo reutilizável de qualidade e explore outros recursos."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Nas últimas lições, você levou um recurso da ideia ao merge com o aplicativo GitHub Copilot. Nesse processo, você:
+
+- conectou um repositório e conheceu o espaço de trabalho do aplicativo e o backlog criado pelo modelo.
+- iniciou sessões a partir de uma tarefa direta e de issues e usou os modos Plan e Autopilot para controlar como o agente trabalha.
+- orientou o agente com instruções personalizadas e depois pediu que ele criasse uma skill reutilizável com scripts de shell que você revisou e executou para lint, testes de unidade, testes de ponta a ponta e verificações de tipos.
+- testou o trabalho com o servidor MCP do Playwright em um navegador real.
+- criou e selecionou um agente personalizado QA para avaliar requisitos, cobertura, resultados dos scripts da skill e evidências do navegador.
+- colaborou com o agente em um canvas compartilhado.
+- fez o merge explicitamente dos primeiros PRs por conta própria e depois autorizou o **Agent Merge** nos fluxos de PR do recurso e do canvas.
+
+As Lições 0–1 de configuração levaram aos nove módulos principais, as Lições 2–10. Reserve um momento para revisar os artefatos e os próximos passos; este encerramento não inicia outra tarefa prática.
+
+## O que você entregou
+
+O workshop tem quatro marcos de PR, cada um em sua própria branch a partir de `main` atualizado:
+
+1. **Avaliações por estrelas:** exibir o `starRating` existente e um estado explícito sem avaliação nos cards dos jogos.
+2. **Instruções e demonstração:** adicionar a convenção de documentação e verificar seu efeito em uma pequena alteração real de código.
+3. **Filtragem e fluxo de qualidade:** implementar a issue, criar a skill `quality-checks` com scripts de shell e o perfil QA e incluir os testes associados.
+4. **Canvas de triagem salvo no repositório:** compartilhar um quadro que adiciona contexto de issues sem implementar automaticamente outro recurso.
+
+As Lições 4–8 usaram a mesma sessão, worktree e branch de filtragem. Os commits de checkpoint preservaram o progresso dentro do PR 3; skills, configuração MCP e QA não precisaram de branches de recurso separadas. Cada marco posterior começou apenas depois do merge do PR anterior e da atualização da branch da nova sessão a partir de `origin/main`.
+
+## Diferentes tipos de verificação
+
+Os primeiros recursos usaram as verificações npm existentes. A filtragem acrescentou sua inspeção manual no navegador. A skill tornou as quatro verificações repetíveis por meio de scripts incluídos, o MCP acrescentou observações diretas do agente no navegador e o QA combinou requisitos e cobertura com a verificação final. O PR reutilizou evidências de QA apenas enquanto elas se aplicavam à revisão enviada.
+
+Os testes adicionados devem cobrir lacunas reais; uma execução de QA que não precisa de testes novos pode estar correta. Ferramentas ausentes, verificações ignoradas e falhas são bloqueios visíveis, não aprovações. Revise código e evidências antes de autorizar o merge e atualize as evidências afetadas após alterações.
+
+## Boas práticas
+
+Ao usar qualquer ferramenta de IA, a infraestrutura ao redor dela influencia a qualidade dos resultados. Você criou instruções, uma skill e um perfil QA neste workshop; revise-os e reutilize-os entre sessões. Agentes personalizados definem papéis especializados e instruções, com ferramentas disponíveis conforme a configuração e as permissões do ambiente; skills reúnem instruções reutilizáveis para tarefas, scripts executáveis e recursos de apoio carregados sob demanda. Um agente personalizado também pode executar scripts, incluindo os que fazem parte de uma skill. Confirme a execução real dos scripts e a seleção do agente personalizado em vez de confiar em uma descrição convincente.
+
+Associe o **modo e o modelo** à tarefa. Use **Plan** para analisar uma abordagem antes de desenvolver, **Interactive** para acompanhar alterações específicas e **Autopilot** somente para tarefas isoladas e com escopo bem definido. Escolha um modelo mais rápido para edições rotineiras e um modelo mais avançado, com maior esforço de raciocínio, para trabalhos complexos.
+
+O contexto continua tão importante quanto a infraestrutura. Descrever claramente *o que* você quer criar, *por que* e *como* muda significativamente o resultado. Os chats rápidos são ótimos para definir o escopo de uma ideia antes de transformá-la em uma sessão completa.
+
+## Mais recursos para explorar
+
+Você percorreu o fluxo de trabalho principal. Veja outros recursos que valem a pena conhecer:
+
+- **Quick chats** para perguntas rápidas e descartáveis que não exigem uma sessão completa.
+- [**Automações**][using-automations] para tarefas recorrentes ou sob demanda, como resumir trabalhos recentes. Revise a agenda, as permissões e o escopo antes de adotar uma; criar uma automação é um próximo passo, não parte deste workshop.
+- **Rubber duck** para analisar um problema e receber feedback relevante antes de começar a desenvolver.
+- [**Agentes personalizados**][custom-agents] para empacotar uma função, suas ferramentas e instruções para trabalhos especializados e repetíveis.
+- [`/chronicle`][chronicle] para gerar uma narrativa do que aconteceu em uma sessão.
+- [Bring your own key (BYOK)][byok] para usar modelos do seu próprio provedor, incluindo modelos locais por meio de Ollama, Foundry Local ou LM Studio.
+- [Sandboxes na nuvem][sandboxes] para executar sessões em um ambiente isolado hospedado pelo GitHub.
+- [Deep links][deep-links] para abrir o aplicativo diretamente em um repositório, uma sessão ou um prompt.
+
+## Próximos passos
+
+A melhor maneira de melhorar com qualquer ferramenta é continuar usando-a. Use-a em código de produção, em projetos pessoais ou naquele pequeno aplicativo que você planeja criar há anos. Compartilhe o que aprendeu com sua equipe e aprenda com as experiências dela. E, como sempre, explore a documentação.
+
+Para conhecer melhor o ecossistema do GitHub Copilot, confira o [percurso do VS Code][vscode-harness], o [percurso do Copilot CLI][cli-harness] ou o [percurso do agente de nuvem][cloud-harness].
+
+## Recursos
+
+- [Sobre o aplicativo GitHub Copilot][about-copilot-app]
+- [Introdução ao aplicativo GitHub Copilot][getting-started]
+- [Personalizar o aplicativo GitHub Copilot][customize]
+- [Usar automações][using-automations]
+- [Trabalhar com extensões de canvas][canvas-docs]
+- [Sobre sandboxes locais e na nuvem][sandboxes]
+
+[previous-lesson]: ../9-canvases/
+[vscode-harness]: ../../vscode/
+[cli-harness]: ../../cli/
+[cloud-harness]: ../../cloud/
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
+[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
+[customize]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
+[using-automations]: https://docs.github.com/copilot/how-tos/github-copilot-app/using-automations
+[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
+[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
+[chronicle]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/chronicle
+[custom-agents]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
+[byok]: https://docs.github.com/copilot/how-tos/github-copilot-app/use-byok-models
+[deep-links]: https://docs.github.com/copilot/how-tos/github-copilot-app/open-with-deep-links
\ No newline at end of file
diff --git a/docs/pt-br/app/2-add-star-rating.md b/docs/pt-br/app/2-add-star-rating.md
index 3a546d52..4650904a 100644
--- a/docs/pt-br/app/2-add-star-rating.md
+++ b/docs/pt-br/app/2-add-star-rating.md
@@ -1,5 +1,5 @@
---
-title: "Lição 2 - Executar sua primeira sessão de agente"
+title: "Lição 2 - Adicionar avaliações por estrelas: uma melhoria rápida"
description: "Inicie sua primeira sessão de agente no aplicativo GitHub Copilot, faça uma pequena alteração nos cards dos jogos e integre-a como seu primeiro pull request."
authors:
- geektrainer
@@ -22,7 +22,7 @@ Cada jogo no Tailspin Toys pode ter uma avaliação por estrelas, que já aparec
## Anatomia de uma sessão
-Uma **sessão** é uma conversa com um agente executada em seu próprio espaço de trabalho isolado. Cada sessão recebe um **git worktree e uma branch dedicados**, o que permite executar várias sessões ao mesmo tempo, uma adicionando um recurso e outra corrigindo um bug, sem que as alterações entrem em conflito. Suas sessões aparecem na barra lateral agrupadas por repositório. Selecione qualquer uma delas para acessá-la.
+Uma **sessão** é uma conversa com um agente. Neste workshop, você escolhe **new working tree**, dando à sessão uma cópia de trabalho e uma branch dedicadas. Isso isola cada marco de PR sem uma branch separada para cada lição. Suas sessões aparecem na barra lateral agrupadas por repositório. Selecione qualquer uma delas para acessá-la.
Em uma sessão, você verá três elementos: a **conversa** com o agente, a **atividade de ferramentas** do agente enquanto ele explora e edita arquivos e a lista de **arquivos alterados** com os respectivos diffs.
@@ -36,16 +36,20 @@ Vamos iniciar uma nova sessão para começar a explorar o projeto e implementar
-4. Use o prompt a seguir para solicitar a alteração:
+4. Escolha **new working tree** e o modo **Interactive** abaixo da caixa de prompt. Use o prompt a seguir para solicitar a alteração:
```plaintext
- On the game cards, show each game's star rating. The Game type already includes a starRating field — it's a number out of 5, or null when a game hasn't been rated yet. Display it on each card in src/components/GameCard.astro, and when starRating is null show "No rating yet" instead. Keep the change small and don't restructure the card layout.
+ Antes de editar, identifique esta cópia de trabalho e a branch, confirme que é um worktree novo e limpo, busque as atualizações de origin e avance a branch desta sessão por fast-forward até origin/main. Confirme que HEAD corresponde a origin/main. Pare e explique se houver alterações pendentes, divergências ou se não for possível atualizar; não redefina nem descarte trabalho.
+
+ Nos cards dos jogos, mostre a avaliação por estrelas de cada jogo. O tipo Game já inclui um campo starRating: um número em uma escala de cinco, ou null quando o jogo ainda não foi avaliado. Exiba-o em cada card em src/components/GameCard.astro e, quando starRating for null, mostre "No rating yet". Mantenha a alteração pequena e não reestruture o layout do card nem altere o modelo de dados.
+
+ Siga as instruções do repositório, adicione ou atualize os testes adequados e execute as verificações npm existentes relevantes. Examine os pré-requisitos e pergunte antes de instalar qualquer coisa. Relate os arquivos alterados e os resultados das verificações e pare para minha revisão. Não faça commit, push, não abra um pull request nem implemente outro recurso.
```
> [!NOTE]
> Observe que o prompt contém o nome do arquivo que o Copilot deve atualizar. Embora não seja obrigatório especificar os arquivos que o Copilot deve incluir no trabalho, indicar a direção certa ajuda o Copilot a gerar código mais rapidamente e reduz o uso de tokens.
-5. Selecione Enter para enviar o prompt ao Copilot.
+5. Pressione Enter para enviar o prompt ao Copilot.
O aplicativo Copilot começa criando um novo worktree, uma cópia isolada do projeto. Em seguida, ele explora o projeto, localiza os arquivos que precisam ser atualizados e cria o código necessário para adicionar o novo recurso. Você acabou de adicionar um recurso com o aplicativo Copilot.
@@ -76,7 +80,9 @@ Todas as alterações geradas por IA devem ser revisadas antes do merge, mesmo a
## Verificar as alterações
-Não devemos apenas ler o código e presumir que ele funciona. Também precisamos testar tudo visualmente. Para isso, iniciaremos o aplicativo no terminal e confirmaremos o funcionamento. O aplicativo Copilot inclui um terminal.
+Revise os resultados das verificações automatizadas do agente antes de abrir um navegador. Confirme que os testes cobrem um `starRating` numérico e a alternativa para `null`, usando os scripts npm existentes do projeto em vez de uma skill que ainda não existe. Um pré-requisito ausente ou uma verificação ignorada não conta como aprovação.
+
+Depois, examine o aplicativo manualmente pelo terminal integrado da sessão. Identifique o worktree antes de iniciar o servidor e não reutilize um servidor de outra cópia de trabalho.
1. No painel de revisão à direita do aplicativo Copilot, selecione **Terminal**. Se não houver um botão **Terminal**, selecione **+** (identificado como **Open in panel**) e depois selecione **Terminal**.
@@ -89,26 +95,30 @@ Não devemos apenas ler o código e presumir que ele funciona. Também precisamo
```
3. Quando o servidor iniciar, o que levará apenas alguns instantes, abra uma janela do navegador.
-4. Acesse http://localhost:4321.
-5. Agora você deve ver avaliações por estrelas em todos os jogos da página inicial.
+4. Abra a URL local exibida pelo servidor, normalmente `http://localhost:4321`. Se a porta estiver ocupada, identifique seu responsável em vez de interromper um processo não relacionado.
+5. Confirme que os cards de jogos avaliados mostram a nota em uma escala de cinco. Quando houver dados sem avaliação, confirme que **No rating yet** aparece; caso contrário, use o teste automatizado para verificar o caso null em vez de afirmar que o observou.
6. Volte à janela do terminal.
-7. Selecione Ctrl+C para interromper o servidor de desenvolvimento.
+7. Pressione Control+C (Mac) ou Ctrl+C (Windows/Linux) para interromper o servidor de desenvolvimento que você iniciou.
## Abrir e fazer merge do primeiro pull request
-A alteração está correta. Agora é hora de entregá-la. Você pedirá ao agente que abra um pull request e depois fará a revisão e o merge no github.com. Por enquanto, gerenciaremos esse processo manualmente. Em uma próxima lição, veremos como o Copilot pode automatizar parte desse trabalho.
+A alteração está correta. Agora é hora de entregar o PR 1. Primeiro, autorize o commit e o PR separadamente da implementação:
+
+```plaintext
+Revise o diff completo da alteração de avaliações por estrelas e seus testes, resuma a verificação e faça commit das alterações revisadas na branch desta sessão. Envie a branch e crie um pull request destinado a main usando o modelo de PR do repositório. Não faça o merge.
+```
-1. No canto superior direito, selecione **Create PR**.
+1. Abra o link do PR criado na sessão. Se o aplicativo apresentar uma confirmação **Create PR**, selecione-a para aprovar a solicitação em vez de criar um segundo PR.
2. Se solicitado, selecione **Sign in with your browser** e siga as instruções para se autenticar.
3. O Copilot começará a criar o PR.
-Após a criação do PR, o Copilot monitorará os fluxos de trabalho do repositório que precisam ser executados. Depois de alguns instantes, o botão no canto superior direito mudará para **Ready to merge**, indicando que o PR está pronto para o merge.
+Após a criação do PR, examine o diff completo e as verificações em **My work**. Leia os resultados dos fluxos de trabalho do repositório do participante; aguarde as verificações e revisões obrigatórias e resolva falhas antes do merge. **Ready to merge** não substitui a revisão da alteração ou das evidências locais.
4. Selecione o indicador **PR** logo acima do chat para abrir o PR no painel de revisão e visualizá-lo. Faça as revisões necessárias nesse painel.
5. Quando estiver tudo pronto, selecione **Ready to merge**.
6. Na nova caixa de diálogo, selecione **Merge pull request** para fazer o merge do pull request.
-Você acaba de enviar um novo recurso para o site.
+Confirme que o PR 1 foi integrado a `main` antes de continuar. Fazer merge no repositório do participante não implanta um site por si só. A próxima lição inicia um worktree novo e o atualiza a partir de `origin/main` para incluir esse PR.
## Resumo e próximos passos
@@ -118,7 +128,7 @@ Você iniciou sua primeira sessão de agente e entregou sua primeira alteração
- orientou o agente a fazer uma alteração pequena e específica nos cards dos jogos.
- revisou a alteração na visualização de diff do espaço de trabalho.
- executou o aplicativo localmente para confirmar a avaliação por estrelas no navegador.
-- abriu um pull request e fez o merge por conta própria no github.com.
+- abriu o PR 1, revisou as verificações e fez o merge explicitamente.
Em seguida, você usará o aplicativo para adicionar um padrão de instruções personalizadas ao repositório, começando por uma das issues do backlog. Continue para a [Lição 3 - Orientar o Copilot com instruções personalizadas][next-lesson].
@@ -129,6 +139,7 @@ Em seguida, você usará o aplicativo para adicionar um padrão de instruções
- [Gerenciar issues e pull requests com o aplicativo GitHub Copilot][managing-issues-prs]
[prior-lesson]: ../1-install-copilot-app/#instalar-e-configurar-o-aplicativo-github-copilot
+[previous-lesson]: ../1-install-copilot-app/
[next-lesson]: ../3-custom-instructions/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
diff --git a/docs/pt-br/app/3-custom-instructions.md b/docs/pt-br/app/3-custom-instructions.md
index 91363726..56407a9e 100644
--- a/docs/pt-br/app/3-custom-instructions.md
+++ b/docs/pt-br/app/3-custom-instructions.md
@@ -1,9 +1,9 @@
---
title: "Lição 3 - Orientar o Copilot com instruções personalizadas"
-description: "Use o aplicativo GitHub Copilot para adicionar ao repositório um padrão de instruções personalizadas, começando por uma issue do backlog e fazendo o merge da alteração como um pull request."
+description: "Adicione um padrão de documentação, demonstre-o em uma pequena função auxiliar ou componente existente e integre ambos como segundo pull request."
authors:
- geektrainer
-lastUpdated: 2026-07-09
+lastUpdated: 2026-09-11
---
O contexto é fundamental ao trabalhar com IA generativa. Se uma tarefa precisa ser realizada de determinada maneira ou se há informações de apoio que o Copilot deve conhecer, esse contexto precisa estar disponível. Uma das ferramentas mais eficientes para isso são os [arquivos de instruções][instruction-files], que descrevem não apenas *qual* código você deseja, mas *como* ele deve ser estruturado. Nesta lição, você adicionará um padrão de documentação ao repositório. Você fará isso da mesma forma que realizará a maior parte do trabalho daqui em diante: começando por uma issue do backlog e permitindo que o agente faça a alteração.
@@ -12,15 +12,17 @@ Nesta lição, você vai:
- explorar como as instruções do repositório e os arquivos de instruções com escopo de caminho chegam ao agente.
- iniciar uma sessão a partir da issue de instruções no backlog.
-- pedir ao agente que adicione um padrão de documentação a `.github/copilot-instructions.md`.
-- revisar a alteração e fazer o merge dela como um pull request.
+- pedir ao agente que adicione um padrão de documentação específico aos arquivos de instruções adequados do repositório.
+- demonstrar o padrão com uma pequena alteração real de código, validá-la e fazer o merge do PR 2.
## Cenário
Como toda boa equipe de desenvolvimento, a Tailspin Toys tem diretrizes e requisitos para as práticas de desenvolvimento. Entre eles estão:
-- A documentação deve ser adicionada ao código na forma de comentários de documentação TSDoc.
-- A formatação deve ser documentada e aplicada por meio de linting.
+- Os comentários devem explicar a intenção e as decisões não óbvias, em vez de repetir o código.
+- As funções exportadas em `db/` e `src/lib/` devem documentar seu propósito, parâmetros e valores de retorno com TSDoc/JSDoc, incluindo um argumento `db` injetável quando presente.
+- Os componentes reutilizáveis de Astro devem documentar seus contratos de `Props`, e os comentários devem ser mantidos atualizados quando o código relacionado mudar.
+- As orientações existentes de formatação e lint devem ser preservadas.
Com os arquivos de instruções, você garantirá que o Copilot tenha as informações certas para executar as tarefas de acordo com as práticas destacadas.
@@ -28,13 +30,13 @@ Com os arquivos de instruções, você garantirá que o Copilot tenha as informa
As instruções personalizadas permitem fornecer contexto e preferências ao Copilot para que ele compreenda melhor seu estilo de programação e seus requisitos. Esse recurso ajuda a orientar o Copilot para obter sugestões e trechos de código mais relevantes. Você pode especificar convenções de código, bibliotecas e até os tipos de comentários que deseja incluir no código. É possível criar instruções para todo o repositório ou para tipos de arquivo específicos, fornecendo contexto no nível da tarefa.
-Há dois tipos de arquivos de instruções:
+O projeto usa dois tipos de arquivos de instruções:
- `.github/copilot-instructions.md`, um único arquivo de instruções enviado ao Copilot em **todas** as solicitações do repositório. Esse arquivo deve conter informações no nível do projeto, ou seja, contexto relevante para a maioria das solicitações enviadas ao Copilot pelo chat ou pela CLI. Isso pode incluir a pilha de tecnologias usada, uma visão geral do que está sendo criado, boas práticas e outras orientações globais.
- Os arquivos `.github/instructions/*.instructions.md` podem ser criados para tarefas ou tipos de arquivo específicos. Você pode usá-los para fornecer diretrizes para determinadas linguagens, como TypeScript ou Astro, ou para tarefas como criar um componente de interface ou um novo conjunto de testes de unidade.
> [!NOTE]
-> O Copilot também oferece suporte a outros padrões para incorporar orientações por meio de AGENTS.md, CLAUDE.md e GEMINI.md, garantindo que ele sempre tenha o contexto correto.
+> Outros formatos de instruções e seu suporte variam conforme o ambiente. Consulte a [referência de suporte a instruções personalizadas][custom-instructions-support] antes de depender de um formato específico.
### Boas práticas para gerenciar arquivos de instruções
@@ -74,49 +76,55 @@ Reserve um momento para ler os arquivos de instruções incluídos no repositór
11. Por fim, abra `.github/instructions/drizzle.instructions.md` e role até o final. Observe os links para outros arquivos de instruções, como `unit-tests.instructions.md`, e para arquivos existentes no projeto. Isso permite dividir conjuntos maiores de instruções em arquivos menores e reutilizáveis e indicar ao Copilot exemplos a serem seguidos ao gerar código. Os caminhos ali são relativos ao arquivo de instruções, e não à raiz do repositório.
> [!NOTE]
-> A seção **Code formatting requirements** em `copilot-instructions.md` documenta os padrões de código do projeto, mas ainda não exige documentação no código. Nas próximas etapas, você adicionará regras para comentários de documentação TSDoc e cabeçalhos de comentários nos arquivos.
+> Compare as orientações existentes com a issue real de padrões de código antes de adicionar regras. Esta lição foca em comentários que explicam intenção, documentação de funções exportadas da camada de dados e contratos de `Props` de Astro, não em cabeçalhos obrigatórios para todos os arquivos ou comentários que repetem o código.
## Começar pela issue de instruções
-Na lição anterior, você iniciou uma sessão com um prompt direto. No entanto, a maior parte do trabalho começa com uma issue. Vamos criar uma nova sessão com base em uma issue criada para atualizar os arquivos de instruções e depois solicitar a atualização.
+Confirme que o PR 1 foi integrado antes de criar esta sessão. Inicie um worktree novo para o PR 2; não continue na branch de avaliações por estrelas. A maior parte do trabalho começa com uma issue, então use a issue de padrões de código para fornecer os requisitos.
> [!NOTE]
> Como os arquivos de instruções têm grande impacto no código gerado pelo Copilot, é preciso garantir que eles orientem o Copilot com clareza. Permitir que o Copilot crie uma primeira versão, como você fará nesta lição, é uma ótima abordagem. Depois, revise o resultado para confirmar que as atualizações atendem aos requisitos.
1. Selecione **My work** na barra lateral.
2. Selecione a issue intitulada **Update our repository coding standards** para abri-la.
-3. Selecione **New session** no canto superior direito para iniciar uma nova sessão com base na issue.
+3. Selecione **New session** no canto superior direito, escolha **new working tree** e selecione o modo **Interactive**.
-4. Use o prompt a seguir para solicitar que o Copilot atualize os arquivos de instruções de acordo com os requisitos documentados na issue:
+4. Use o prompt a seguir. Atualizar a branch da nova sessão antes de editar faz com que a versão integrada mais recente de `main` seja o ponto de partida real, mesmo se a cópia local do aplicativo estiver desatualizada:
- ```plaintext
- Following this issue, make the updates to the instructions files in this project to meet the requirements documented. Don't create the PR quite yet!
- ```
+ ```plaintext
+ Antes de editar, identifique esta cópia de trabalho e a branch, confirme que é um worktree novo e limpo, busque as atualizações de origin e avance a branch desta sessão por fast-forward até origin/main. Confirme que HEAD corresponde a origin/main e inclui o PR integrado de avaliações por estrelas. Pare se houver alterações pendentes, divergências ou se esse merge estiver ausente; não redefina, não descarte trabalho nem crie outra branch.
+
+ Leia a issue "Update our repository coding standards" e as instruções existentes do repositório. Adicione uma convenção de documentação específica: explique a intenção em vez da mecânica; documente funções exportadas em db/ e src/lib/ com TSDoc/JSDoc cobrindo propósito, parâmetros, retornos e argumentos db injetáveis quando presentes; documente os contratos de Props dos componentes reutilizáveis de Astro; e mantenha os comentários atualizados quando o código relacionado mudar.
+
+ Coloque cada regra no arquivo de instruções existente adequado, sem duplicações ou contradições, e inclua um link ou resumo do padrão atualizado em README. Preserve as orientações existentes de formatação e lint. Não exija cabeçalhos para todos os arquivos, não migre ferramentas de formatação, não reescreva a documentação de toda a aplicação nem implemente a filtragem. Mostre o diff das instruções e pare para revisão. Não crie uma skill ou agente, não faça commit, push nem crie um PR.
+ ```
O Copilot fará as atualizações.
## Revisar a alteração
-Vamos ler as atualizações feitas pelo Copilot e também pedir um exemplo do código que ele passará a gerar com base nas instruções atualizadas.
+Leia as orientações atualizadas e demonstre seu efeito em um arquivo real. Apenas um trecho proposto não demonstra que as instruções do repositório influenciaram uma alteração de código.
1. Selecione **Changes** no canto superior direito para abrir as alterações no código.
-2. Revise o arquivo de instruções atualizado. Confirme se ele contém as diretrizes para adicionar documentação e comentários ao código.
+2. Revise os arquivos de instruções atualizados e a referência em README. Confirme que as regras correspondem à filosofia de comentários, à documentação de funções exportadas e aos contratos de componentes da issue, sem inventar uma exigência geral de cabeçalhos de arquivo.
> [!NOTE]
> Como a IA é probabilística, e não determinística, o texto exato pode variar.
-3. Use o prompt a seguir para pedir ao Copilot que crie um exemplo do código que passará a gerar:
+3. Após revisar as instruções, solicite uma demonstração com escopo limitado nesta mesma sessão:
+
+ ```plaintext
+ Demonstre a convenção de documentação atualizada em uma pequena função auxiliar TypeScript exportada existente em db/ ou src/lib/, ou em um componente reutilizável de Astro. Examine o repositório para escolher um arquivo existente adequado; não presuma que existe uma função auxiliar de distribuidoras. Faça uma pequena melhoria de legibilidade que preserve o comportamento e aplique as orientações relevantes de documentação de funções ou contratos de Props. Explique intenções não óbvias sem adicionar comentários que apenas repitam o código.
- ```plaintext
- Do not make any updates, but show me what the code would look like. Based on the new instructions, if I asked Copilot to create a new library component to return all Publishers what would that code look like?
- ```
+ Limite a alteração a essa demonstração e aos testes diretamente relevantes. Não implemente a filtragem nem crie um recurso novo. Execute as verificações npm existentes relevantes, relate o que mudou e como a instrução afetou o código e pare para revisão. Pergunte antes de instalar qualquer coisa. Não faça commit, push nem crie um PR.
+ ```
-4. Revise o código proposto pelo Copilot. Observe os comentários de documentação TSDoc e o comentário de cabeçalho do arquivo, exatamente como solicitado pelas instruções atualizadas.
+4. Revise o diff real do arquivo, não apenas a resposta do chat. Verifique se a documentação explica o comportamento real e se a melhoria de legibilidade o preserva. Revise os resultados relevantes de testes, lint e verificação de tipos; resolva falhas antes de continuar.
Você atualizou os arquivos de instruções do projeto e viu o impacto que eles terão.
@@ -124,17 +132,23 @@ Você atualizou os arquivos de instruções do projeto e viu o impacto que eles
Os arquivos de instruções se tornam ativos do repositório, portanto são compartilhados com o restante da equipe. Vamos criar um PR com esse trabalho, como faríamos com qualquer outro ativo.
-1. No canto superior direito, selecione **Create PR**.
+Primeiro, autorize as instruções e a demonstração revisadas em conjunto:
+
+```plaintext
+Revise o diff completo das instruções de padrões de código, da referência em README e da demonstração de código com escopo limitado, incluindo os testes relacionados. Resuma a verificação e faça commit dessas alterações revisadas na branch desta sessão. Envie a branch e crie um único pull request destinado a main, usando o modelo de PR do repositório e vinculando a issue de padrões de código. Descreva isso como contribuição parcial, a menos que todos os critérios de aceitação da issue sejam atendidos; não use palavras-chave de fechamento para trabalho incompleto. Não faça o merge.
+```
+
+1. Abra o link do PR na sessão. Se o aplicativo apresentar uma confirmação **Create PR**, selecione-a sem criar um PR duplicado.
2. Se solicitado, selecione **Sign in with your browser** e siga as instruções para se autenticar.
3. O Copilot começará a criar o PR.
-Após a criação do PR, o Copilot monitorará os fluxos de trabalho do repositório que precisam ser executados. Depois de alguns instantes, o botão no canto superior direito mudará para **Ready to merge**, indicando que o PR está pronto para o merge.
+Examine o diff completo do PR em **My work**, incluindo as alterações de instruções e código. Revise os resultados de CI do repositório do participante e as revisões obrigatórias. Resolva falhas antes de selecionar **Ready to merge**; a CI não substitui a demonstração nem sua revisão.
4. Selecione **Ready to merge**.
5. Na nova caixa de diálogo, selecione **Merge pull request** para fazer o merge do pull request.
> [!NOTE]
-> Depois que o padrão for integrado à branch padrão, ele fará parte do projeto para toda a equipe e para cada nova sessão. Quando você iniciar a sessão de filtragem na próxima lição a partir de uma branch padrão atualizada, o agente seguirá esse padrão automaticamente. O código TypeScript gerado incluirá comentários de documentação TSDoc sem que você precise solicitá-los, uma demonstração pequena, mas concreta, de como as instruções moldam o código gerado.
+> Confirme que o PR 2 foi integrado a `main` antes de iniciar a filtragem. Apenas um worktree novo não garante código atualizado: na Lição 4, você buscará as atualizações e avançará a branch da nova sessão por fast-forward até `origin/main`, verificando se os dois merges anteriores estão presentes antes de planejar.
## Resumo e próximos passos
@@ -142,10 +156,10 @@ Você explorou como o aplicativo obtém contexto dos arquivos de instruções e
- explorou o arquivo `copilot-instructions.md` do repositório e os arquivos `*.instructions.md` com escopo de caminho.
- iniciou uma sessão a partir da issue de instruções no backlog.
-- pediu ao agente que adicionasse um padrão de documentação a `.github/copilot-instructions.md`.
-- revisou a alteração e fez o merge dela como um pull request.
+- pediu ao agente que adicionasse regras de documentação específicas aos arquivos de instruções adequados e as referenciasse em README.
+- examinou o efeito do padrão em uma alteração real de código, validou o resultado e integrou ambos como PR 2.
-Em seguida, você criará o recurso de filtragem em uma nova sessão e verá como ele adota o padrão que acabou de integrar. Continue para a [Lição 4 - Criar um recurso com o Autopilot][next-lesson].
+Em seguida, você criará o recurso de filtragem em uma nova sessão e verificará se ele segue o padrão que acabou de integrar. Continue para a [Lição 4 - Criar a filtragem com Plan e Autopilot][next-lesson].
## Recursos
@@ -154,6 +168,7 @@ Em seguida, você criará o recurso de filtragem em uma nova sessão e verá com
- [Boas práticas para criar instruções personalizadas][instructions-best-practices]
- [Awesome Copilot — uma coleção de arquivos de instruções e outros recursos][awesome-copilot]
+[previous-lesson]: ../2-add-star-rating/
[next-lesson]: ../4-build-filtering/
[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/pt-br/app/4-build-filtering.md b/docs/pt-br/app/4-build-filtering.md
index d36228c4..e5e3aecb 100644
--- a/docs/pt-br/app/4-build-filtering.md
+++ b/docs/pt-br/app/4-build-filtering.md
@@ -1,186 +1,122 @@
---
-title: "Lição 4 - Criar um recurso com o Autopilot"
-description: "Use os modos Plan e Autopilot no aplicativo GitHub Copilot para criar um recurso estático de filtragem no lado do cliente, observar como ele herda seu padrão de documentação e verificá-lo com uma skill de agente."
+title: "Lição 4 - Criar a filtragem com Plan e Autopilot"
+description: "Planeje a filtragem a partir da issue, aprove o Autopilot explicitamente, valide com as verificações npm existentes e uma visita manual ao navegador e salve um checkpoint."
authors:
- geektrainer
-lastUpdated: 2026-07-13
+lastUpdated: 2026-09-11
---
-Até agora, fizemos algumas pequenas atualizações no projeto. No entanto, alterações mais robustas exigem um processo mais completo. O aplicativo GitHub Copilot foi criado para trabalhar com nosso fluxo existente e ajudar a garantir que criemos as soluções certas da maneira correta. Esta é a primeira de três lições nas quais você seguirá um processo típico de desenvolvimento, começando por usar uma issue para gerar um novo recurso e uma skill de agente para executar os testes de validação e os linters.
+Você integrou as avaliações por estrelas e o padrão de documentação com sua demonstração de código. Agora crie o recurso de filtragem. Este é o início de um marco de PR maior: mantenha esta mesma sessão, worktree e branch durante as Lições 4–8.
Nesta lição, você vai:
-- iniciar uma nova sessão a partir da issue de filtragem.
-- usar o modo **Plan** para planejar o recurso e depois o **Autopilot** para criá-lo.
-- confirmar que o código gerado segue o padrão de documentação integrado anteriormente.
-- verificar o trabalho com a skill `quality-checks` do projeto.
+- partir de `main` atualizado e ler a issue real de filtragem.
+- resolver os requisitos no modo **Plan** antes de aprovar explicitamente o **Autopilot**.
+- revisar a filtragem e os testes e executar as quatro verificações npm existentes.
+- visitar o recurso manualmente no navegador e salvar um checkpoint.
-## Cenário
+A skill, a validação MCP, o perfil QA e o PR do recurso vêm nos próximos módulos. Não os crie durante esta etapa de implementação.
-A página inicial lista todos os jogos, mas os visitantes não conseguem restringir a lista. A issue de filtragem solicita que eles possam filtrar jogos por **categoria** e **distribuidora**. Vamos usar o Copilot para implementar essa funcionalidade.
-
-## Contexto
+## Modos de sessão
-Introduzir agentes de programação com IA no fluxo de desenvolvimento não muda os fundamentos. Na verdade, eles se tornam ainda mais importantes. A maioria das pessoas desenvolvedoras segue um fluxo semelhante a este:
+O seletor de modo abaixo do prompt controla a autonomia do agente:
-1. Abrir uma issue com os detalhes do que precisa ser feito.
-2. Criar um plano do que precisa ser desenvolvido.
-3. Criar e revisar o código.
-4. Executar os testes para validar o código.
-5. Validar manualmente a nova funcionalidade.
-6. Criar um pull request (PR).
-7. Depois que o código for revisado e o processo de integração contínua for concluído com êxito, fazer o merge do código.
+- **Interactive** mantém você envolvido enquanto o agente trabalha e solicita informações.
+- **Plan** prepara um plano para revisão antes da implementação.
+- **Autopilot** implementa e itera de forma autônoma dentro do escopo e das permissões aprovados.
-> [!NOTE]
-> Os detalhes exatos variam de acordo com sua equipe e organização, mas a maioria dos fluxos será uma variação do processo descrito acima.
+Planeje primeiro, aprove explicitamente e volte ao Interactive antes de criar personalizações reutilizáveis.
-Ao seguir essa abordagem padrão, você garante que o código gerado por IA atenda aos requisitos definidos e passe pelo mesmo processo de avaliação do código escrito manualmente.
+## Partir de main atualizado
-## Modos de sessão
+Confirme que o PR 1 e o PR 2 foram integrados no GitHub. Crie um worktree novo para a filtragem em vez de continuar em qualquer uma das branches anteriores.
-O **modo de sessão** controla o grau de autonomia do agente. Você pode defini-lo no menu suspenso abaixo do campo de prompt e alterá-lo a qualquer momento:
+1. Selecione **My work** e encontre **Allow users to filter games by category and publisher** pelo título. Abra a issue e copie sua URL real; os números de issue variam entre repositórios.
+2. Selecione **New session** e escolha **new working tree**. Mantenha o modo **Interactive** para atualizar o estado inicial.
-- **Interactive**: você e o agente trabalham em conjunto. O agente sugere alterações e aguarda sua orientação antes de prosseguir.
-- **Plan**: o agente cria primeiro um plano. Você revisa e aprova o plano antes que o agente o execute.
-- **Autopilot**: o agente trabalha com total autonomia, escrevendo código, executando testes e iterando sem aguardar sua orientação.
+ 
-## Planejar o recurso de filtragem
+3. Envie esta solicitação de preparação antes de planejar ou editar:
-O melhor momento para detectar um possível problema é antes que qualquer código seja escrito, e a melhor maneira de fazer isso é planejar com antecedência. Ao planejar com o Copilot, você pedirá que ele gere um conjunto de etapas e documente a abordagem que seguirá. Em seguida, poderá revisar o plano e fazer sugestões para melhorá-lo antes de permitir que o Copilot gere o código com base nele.
-
-Vamos abrir a issue, iniciar uma nova sessão e criar um plano alternando para o modo Plan e fazendo a solicitação.
+ ```plaintext
+ Prepare esta nova sessão de filtragem sem implementar nada. Identifique a cópia de trabalho e a branch, confirme que o worktree está limpo, busque as atualizações de origin e avance a branch desta sessão por fast-forward até origin/main. Confirme que HEAD corresponde a origin/main e inclui os PRs integrados de avaliações por estrelas e padrões de código.
-1. Selecione **My work** na aba de navegação.
-2. Selecione a issue intitulada **Allow users to filter games by category and publisher**.
-3. Selecione **New session** no canto superior direito.
+ Pare e explique se houver alterações pendentes, divergências ou se algum dos merges estiver ausente. Não redefina nem descarte trabalho, não mude de branch, não crie outra branch nem edite arquivos da aplicação. Informe a revisão inicial.
+ ```
- 
+4. Verifique o estado inicial informado. Apenas buscar atualizações não atualiza o worktree: a branch da sessão atual deve avançar por fast-forward e seu `HEAD` deve corresponder ao `origin/main` obtido antes de começar o trabalho.
-4. Selecione Shift+Tab até que o modo exibido seja **Plan**.
+## Planejar o recurso de filtragem
- 
+Mude o seletor de modo para **Plan**. Substitua o marcador da issue abaixo pela URL que você copiou.
-5. Envie o prompt a seguir. A issue de filtragem já está no contexto da sessão porque você iniciou a partir dela:
+```plaintext
+Planeje o recurso de filtragem a partir desta issue: . Leia todos os critérios de aceitação e as instruções do repositório e examine a aplicação estática Astro atual, suas funções auxiliares de acesso a dados e os testes existentes. Não implemente ainda.
- ```plaintext
- Plan the work based on the requirements documented in the issue. Please ask any clarifying questions you might have as you build the plan.
- ```
+Cubra a seleção de várias categorias, a filtragem por distribuidora, a combinação de categorias e distribuidora, as funções auxiliares de acesso a dados adequadas, os controles acessíveis e a cobertura de unidade e de ponta a ponta exigida pela issue. Pergunte para que eu esclareça comportamentos não especificados, como a combinação de várias categorias, a limpeza dos filtros e os resultados vazios, em vez de inventar requisitos silenciosamente. Não introduza uma API de servidor, a menos que os requisitos e a arquitetura existente justifiquem.
-6. O agente pode fazer perguntas complementares enquanto cria o plano. Responda com base em como você criaria o recurso.
+Proponha um plano de implementação e verificação com escopo limitado que siga a convenção de documentação do repositório e adicione ou atualize os testes de unidade e de ponta a ponta necessários. Após confirmar os comandos em package.json, planeje executar npm run lint, npm run test:unit, npm run test:e2e e npm run typecheck:all com as ferramentas existentes do projeto. Registre a URL da issue e meus esclarecimentos aprovados no plano para que eu possa reutilizá-los no QA.
-> [!NOTE]
-> Como o Copilot é probabilístico, as perguntas complementares exatas podem variar. Na verdade, ele pode não fazer nenhuma pergunta. Isso é perfeitamente normal.
+Inclua estas medidas de segurança de execução no plano antes da minha aprovação: identifique a cópia de trabalho e o servidor em teste; examine os pré-requisitos antes de executar verificações; pergunte antes de instalar software, dependências ou navegadores; não reutilize o servidor de outro worktree; pare apenas os servidores que você iniciou; e relate outros conflitos de porta em vez de interromper processos não relacionados. Pré-requisitos ausentes e verificações ignoradas devem ser relatados como bloqueios, não como verificações aprovadas.
-7. Ao terminar, o Copilot apresentará um resumo do plano. Revise-o. Ele deve propor a criação de consultas, a adição de controles de filtro e, naturalmente, testes. Se desejar, forneça feedback para refiná-lo. O agente incorporará suas sugestões em uma nova versão.
+Inclua este limite de implementação no plano: depois que eu aprovar explicitamente o Autopilot, implemente apenas o recurso de filtragem acordado e seus testes neste mesmo worktree e branch, execute as quatro verificações, relate a implementação e todos os resultados, incluindo falhas ou bloqueios, e pare para minha revisão e verificação manual no navegador. Não crie skills ou agentes personalizados, não configure MCP, não mude de branch, não faça commit, push nem abra um PR durante a implementação. A verificação manual no navegador e o commit de checkpoint ocorrerão depois, sob minha orientação separada.
-## Criar com o Autopilot
+Por enquanto, permaneça no modo Plan e pare com o plano para minha revisão. Não implemente, não crie skills ou agentes personalizados, não configure MCP, não mude de branch, não faça commit, push nem abra um PR.
+```
-Com o plano pronto, vamos permitir que o Copilot crie a implementação.
+Responda às perguntas de esclarecimento e compare o plano com a issue. Procure as alterações de acesso a dados, os controles acessíveis e os testes, em vez de aceitar uma implementação apenas de interface. Guarde a URL real da issue e os esclarecimentos aprovados do plano para as Lições 6 e 7; use `none` quando não forem necessários critérios adicionais.
-1. Na lista de opções da caixa de diálogo **Plan summary**, selecione a opção mais próxima de **Approve and implement with autopilot**.
+Antes de aprovar, confirme que o próprio plano contém as quatro verificações, a convenção de documentação, as medidas de segurança de pré-requisitos e servidores, a exigência de manter o mesmo worktree e branch e a parada após implementação e verificação. Ele deve proibir skills, agentes e configuração MCP posteriores, commits, pushes e PRs durante a implementação. Se faltar algum limite, peça um plano revisado ainda no modo **Plan** e examine a revisão antes de aprovar.
-O Copilot começará a trabalhar na implementação.
+## Aprovar o Autopilot explicitamente
-> [!NOTE]
-> Se o Copilot não começar a criar automaticamente o código necessário, você poderá solicitar isso com um prompt como "Go ahead and start building out the plan!".
->
-> A criação das atualizações necessárias levará vários minutos. O agente edita e cria arquivos, escreve e executa testes e faz iterações. Este é um bom momento para refletir sobre o que você explorou até agora ou fazer uma pausa.
+Somente depois que o plano revisado contiver seus requisitos e todos os limites de execução, selecione **Approve and implement with autopilot** nos controles de aprovação do plano, ou a opção explícita equivalente de Autopilot exibida na sua versão. Confirme que o indicador de modo mostra **Autopilot**.
-## Revisar as alterações
+A aprovação pode iniciar a execução imediatamente. Portanto, todo o escopo de implementação, as regras de segurança e os limites de parada precisam estar no plano revisado antes da aprovação; não dependa de adicioná-los em uma mensagem posterior quando a execução já começou.
-Todo código gerado por IA precisa ser revisado antes do merge. Vamos revisar o código e executar o site para confirmar que tudo está correto.
+O Autopilot pode escrever código e testes e iterar sobre falhas, mas essa permissão não autoriza concluir os próximos módulos do workshop. Um pré-requisito ausente é um bloqueio a resolver com aprovação, não uma verificação aprovada.
-1. Selecione **Changes** no canto superior direito para abrir as alterações no código.
+## Revisar e verificar a implementação
- 
+1. Abra **Changes** e examine a implementação da filtragem e os testes.
+2. Compare o resultado com a issue e os esclarecimentos aprovados, incluindo combinações de várias categorias e distribuidoras. Verifique se as funções auxiliares novas ou modificadas seguem o padrão de documentação da Lição 3.
+3. Examine a saída real dos comandos das quatro verificações npm. Elas são executadas diretamente agora porque você ainda não criou a skill quality-checks.
+4. Resolva falhas e execute novamente as verificações afetadas antes de aceitar a implementação. A configuração E2E do Playwright faz o build e serve uma prévia, podendo reutilizar um servidor local; confirme que o servidor testado pertence a este worktree, não a uma lição anterior.
-2. Revise as alterações. Você deverá ver novos arquivos TypeScript e Astro, além de arquivos de teste. Observe que as novas funções auxiliares incluem comentários de documentação TSDoc e um comentário de cabeçalho do arquivo. O padrão de documentação integrado na Lição 3 foi aplicado automaticamente, sem que você precisasse solicitá-lo.
-3. No painel de revisão à direita do aplicativo Copilot, selecione **Terminal**. Se não houver um botão **Terminal**, selecione **+** (identificado como **Open in panel**) e depois selecione **Terminal**.
+## Verificar o recurso manualmente
- 
+Volte a sessão ao modo **Interactive** antes da revisão manual e mantenha-o para a Lição 5.
-4. Digite o comando a seguir na janela do terminal para iniciar o servidor de desenvolvimento do aplicativo Web:
+1. Abra **Terminal** no painel de revisão desta sessão. Se necessário, selecione **+** e depois **Terminal**.
+2. Confirme que o terminal está no worktree de filtragem e execute:
```shell
npm run dev
```
-5. Quando o servidor iniciar, o que levará apenas alguns instantes, abra uma janela do navegador.
-6. Acesse http://localhost:4321.
-7. Agora você deve ver filtros disponíveis na página inicial.
-8. Se algo não estiver correto, peça ao Copilot que faça as atualizações.
-9. Quando estiver tudo certo, volte à janela do terminal.
-10. Selecione Ctrl+C para interromper o servidor de desenvolvimento.
+3. Abra no navegador a URL exibida por esse servidor, normalmente `http://localhost:4321`. Se a porta estiver ocupada, identifique seu responsável em vez de interromper um processo não relacionado ou presumir que o servidor existente contém suas alterações.
+4. Exercite a seleção de categorias, a seleção de distribuidora e sua combinação conforme o comportamento aprovado. Verifique o acesso por teclado e os comportamentos acordados para limpeza dos filtros e resultados vazios.
+5. Se algo falhar, solicite uma correção específica, revise o diff, execute novamente as verificações automatizadas afetadas e repita as verificações relevantes no navegador.
+6. Volte ao terminal e pressione Control+C (Mac) ou Ctrl+C (Windows/Linux) para parar o servidor que você iniciou. Confirme que ele parou antes da execução E2E do próximo módulo.
-## Verificar o trabalho com a skill quality-checks
+Esta é sua observação manual no navegador. A observação no navegador conduzida pelo agente via MCP vem na Lição 6.
-Você poderia apenas examinar o diff e considerar o trabalho concluído, mas a equipe definiu um padrão de qualidade e uma maneira repetível de verificá-lo.
+## Salvar um checkpoint
-As **skills de agente** permitem fornecer ao Copilot orientações sobre como executar tarefas repetíveis, como executar testes, gerar builds ou criar pull requests. Uma skill é uma pasta de instruções, scripts e recursos que o agente pode carregar sob demanda. [Agent Skills é um padrão aberto][agent-skills-repo] usado por vários agentes. Por isso, a mesma skill funciona no Copilot Chat em modo de agente, no agente de nuvem do Copilot, no Copilot CLI e no aplicativo GitHub Copilot.
+Após revisar as alterações e a verificação, autorize um commit local:
-As skills ficam na pasta `.github/skills` de um projeto ou globalmente em `~/.copilot/skills`. Cada skill é uma pasta que contém um arquivo `SKILL.md` com frontmatter YAML, formado por `name` e `description`, seguido pelas instruções em Markdown:
-
-```yaml
----
-name: quality-checks
-description: Run the project's test suites and linter to verify code changes are ready to commit, push, or merge.
----
+```plaintext
+Revise o diff atual e crie um commit de checkpoint para a implementação da filtragem e seus testes. Mantenha esta mesma branch e worktree de filtragem. Não crie skills ou agentes, não configure MCP, não faça push nem abra um pull request.
```
-As skills também podem incluir subpastas com scripts, ativos e materiais de referência. A estrutura completa é descrita na [especificação de skills de agente][agent-skills-spec].
-
-> [!TIP]
-> As skills são carregadas dinamicamente. O agente decide qual skill se aplica com base no campo `description`. Uma descrição clara e específica para o cenário é o que diferencia uma skill usada de uma ignorada.
-
-## Explorar a skill quality-checks
-
-Vamos explorar a skill para entender o que ela faz.
-
-1. Se o painel de revisão ainda não estiver visível, abra-o selecionando **Toggle review panel** no canto superior direito.
-
- 
-
-2. Selecione **+** para adicionar um novo item ao painel de revisão.
-3. Selecione **File**.
-4. Pesquise `SKILL.md`.
-5. Selecione `SKILL.md .github/skills/quality-checks` na lista de arquivos para abri-lo.
-6. Observe `name` e `description`. A descrição informa ao agente *quando* usar a skill: sempre que alterações no código precisarem ser testadas, verificadas por lint ou validadas antes de um commit, push ou merge.
-7. Leia a skill. Observe que ela documenta qual script executa cada conjunto, como testes de unidade, testes de ponta a ponta do Playwright e ESLint, em que ordem e como depurar falhas comuns. Assim, o agente executa as verificações da maneira definida pela equipe, em vez de tentar adivinhar.
-
-## Executar as verificações
-
-Na mesma sessão de filtragem, peça ao agente que verifique o trabalho. Você não precisará nomear a skill, pois o agente a associará à sua solicitação.
-
-1. Volte ao aplicativo Copilot.
-2. Chame diretamente a skill usando o comando de barra `/quality-checks` e selecione Enter.
-3. Seguindo a skill, o agente executa os testes de unidade, o linter e os testes de ponta a ponta e relata os resultados. Se algo falhar, peça que ele corrija o problema e execute novamente as verificações até que tudo passe.
-4. **Mantenha esta sessão aberta.** Na próxima lição, você adicionará o servidor MCP do Playwright e o usará para ver o recurso de filtragem funcionando em um navegador real.
-
-## Resumo e próximos passos
-
-Você criou um recurso real de ponta a ponta e o verificou de acordo com o padrão da equipe. Especificamente, você:
-
-- iniciou uma nova sessão a partir da issue de filtragem em um projeto atualizado.
-- usou o modo Plan para planejar o recurso e o Autopilot para criá-lo.
-- confirmou que o código auxiliar gerado seguiu o padrão de documentação integrado na Lição 3.
-- verificou o trabalho com a skill `quality-checks`.
-
-Em seguida, você conectará o servidor MCP do Playwright e pedirá ao agente que explore o recurso de filtragem em um navegador real. Continue para a [Lição 5 - Testar com o servidor MCP do Playwright][next-lesson].
+Este checkpoint faz parte do PR 3, não de um PR separado. Permaneça no modo **Interactive**, na mesma sessão, para a [Lição 5 - Criar e usar uma skill quality-checks][next-lesson].
## Recursos
- [Trabalhar com sessões de agente no aplicativo GitHub Copilot][agent-sessions]
-- [Sobre Agent Skills][about-agent-skills]
-- [Personalizar o aplicativo GitHub Copilot][customize-app]
- [Sobre sandboxes locais e na nuvem para o GitHub Copilot][sandboxes]
-[ex0]: ../0-prerequisites/
-[ex2]: ../2-add-star-rating/
-[ex3]: ../3-custom-instructions/
-[next-lesson]: ../5-mcp-playwright/
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
\ No newline at end of file
diff --git a/docs/pt-br/app/5-agent-skills.md b/docs/pt-br/app/5-agent-skills.md
new file mode 100644
index 00000000..e129634c
--- /dev/null
+++ b/docs/pt-br/app/5-agent-skills.md
@@ -0,0 +1,93 @@
+---
+title: "Lição 5 - Criar e usar uma skill quality-checks"
+description: "Peça ao Copilot que crie verificações de qualidade reutilizáveis com scripts de shell incluídos, examine a skill e execute-a na branch de filtragem."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Seu recurso de filtragem está implementado e verificado com os comandos npm existentes. Agora você reunirá essas verificações em uma **skill de agente** reutilizável. Permaneça na mesma sessão e branch de filtragem durante as Lições 4–8; esta lição não cria um pull request.
+
+Nesta lição, você vai:
+
+- voltar ao modo **Interactive** antes de criar personalizações.
+- pedir ao Copilot que crie `quality-checks` e pare para você examiná-la.
+- executar as quatro verificações pelos scripts incluídos e comprovar que um argumento que indica um único arquivo de teste seleciona apenas esse arquivo.
+- salvar um checkpoint da skill junto com o recurso de filtragem.
+
+## Instruções, scripts e recursos
+
+Skills reúnem instruções de tarefas reutilizáveis, scripts executáveis e recursos de apoio que um agente carrega sob demanda. Agentes personalizados definem papéis especializados, instruções e ferramentas disponíveis. Eles são complementares: um agente personalizado pode executar scripts, incluindo os fornecidos com uma skill.
+
+Uma skill do repositório fica em `.github/skills//SKILL.md`, com `name` e `description` no frontmatter e instruções em Markdown. Scripts e outros recursos ficam ao lado desse arquivo. Você pedirá ao Copilot que gere `.github/skills/quality-checks/SKILL.md` e seus scripts incluídos, em vez de copiar uma solução pronta. A [especificação de Agent Skills][skill-spec] descreve o formato.
+
+O Copilot usa a descrição de uma skill descoberta para decidir quando carregá-la. Não presuma que uma skill nova seja descoberta imediatamente em uma sessão já aberta; a seção de execução inclui uma alternativa de leitura explícita. Um formato portável não elimina os pré-requisitos do shell ou do projeto.
+
+## Criar a skill
+
+Volte a sessão de filtragem ao modo **Interactive** usando o seletor de modo antes de enviar o prompt. Mantenha a cópia de trabalho e a branch atuais. Se você começou com um modelo antigo que já tem essa skill, examine-a e amplie-a em vez de sobrescrever suas personalizações.
+
+```plaintext
+Crie .github/skills/quality-checks/SKILL.md e quatro scripts que encapsulem npm run lint, npm run test:unit, npm run test:e2e e npm run typecheck:all. Leia primeiro package.json, README, a configuração de testes e as instruções do repositório.
+
+Detecte este ambiente. Crie SOMENTE scripts Bash .sh para macOS/Linux/WSL OU scripts PowerShell .ps1 para Windows nativo; pergunte se houver dúvida. Não crie ambos. Limite os wrappers a resolver a raiz do repositório a partir da própria localização, verificar se o package.json deste projeto está lá e invocar npm. Falhe com uma mensagem clara se a raiz for inválida. Suporte qualquer diretório de trabalho e caminhos com espaços. Preserve a saída e os códigos de saída de falhas, incluindo falhas de comandos nativos do PowerShell. Insira o separador -- do npm exatamente uma vez; quem invocar os scripts deve fornecer os argumentos da ferramenta diretamente, sem outro --. Não gerencie portas nem processos.
+
+Inclua em SKILL.md um frontmatter com name e description, instruções para executar os quatro wrappers, pré-requisitos, solução de problemas e exemplos portáveis que incluam um arquivo existente de testes de unidade. Todos os exemplos de Bash devem invocar bash explicitamente; nunca contorne a política de execução do PowerShell. Explique a reutilização de servidores do Playwright: pare apenas servidores que você realmente iniciou; caso contrário, pergunte.
+
+Crie apenas a skill e os scripts necessários. Não execute verificações nem sondagens, não instale nada, não altere código da aplicação, não faça commit nem abra um PR. Pare para que eu possa examinar os arquivos.
+```
+
+## Examinar a skill
+
+1. Abra **Changes** para revisar os arquivos gerados. Você também pode usar **+**, **File** no painel de revisão e pesquisar `SKILL.md` ou os nomes dos scripts.
+2. Verifique se `name` e `description` descrevem a skill e quando ela se aplica. Leia as instruções, não apenas os metadados.
+3. Confirme que a sequência de execução realmente invoca os scripts incluídos em `.github/skills/quality-checks/` para lint, testes de unidade, E2E e verificação de tipos.
+4. Examine em cada wrapper a resolução da raiz relativa ao script e uma verificação explícita de que o diretório calculado contém o `package.json` pretendido desta cópia de trabalho. Um comando bem-sucedido porque o npm pesquisa em diretórios ancestrais não comprova que a raiz está correta. Verifique caminhos entre aspas, encaminhamento de argumentos, saída visível e códigos de saída em caso de falha; o PowerShell precisa propagar falhas nativas do npm.
+5. Verifique o exemplo documentado de um único arquivo de testes de unidade. O wrapper insere o separador `--` do npm, então quem o invoca passa os argumentos da ferramenta de destino diretamente, sem outro separador. Mantenha as instruções reutilizáveis sem caminhos absolutos da cópia de trabalho específicos de uma máquina. Peça ao Copilot que corrija as lacunas antes de executar qualquer coisa.
+6. Limite os scripts à validação da raiz e do manifesto e à execução das verificações npm existentes. As decisões sobre portas e processos pertencem a SKILL.md, não a código de gerenciamento de processos em shell. Confirme que apenas servidores realmente iniciados pelo agente podem ser parados; a correspondência do diretório de trabalho ou do nome do processo não determina a quem ele pertence. Os arquivos entregues devem conter apenas a skill, os wrappers necessários e qualquer helper compartilhado necessário, sem arquivos temporários de sondagem ou depuração.
+
+> [!NOTE]
+> O Tailspin Toys atualmente exige Node.js 22.13 ou posterior, as dependências do projeto e o Chromium do Playwright para verificações E2E. Confirme os pré-requisitos em README e `package.json` da sua cópia de trabalho. Pré-requisitos ausentes ou uma política de execução do PowerShell que bloqueie a execução precisam de uma resolução aprovada, não de instalação automática, de contorno da política ou de troca silenciosa para npm direto.
+
+## Executar a skill
+
+Confirme que o servidor de desenvolvimento da lição anterior parou. O Playwright compila e serve uma prévia para E2E, mas sua configuração local pode reutilizar um servidor na porta `4321`. Um servidor de outra cópia de trabalho não é evidência válida para seu recurso.
+
+Se o aplicativo oferecer `/quality-checks`, selecione-o para invocar explicitamente a skill descoberta e inclua a solicitação abaixo. Se ela não tiver sido descoberta, envie a mesma solicitação diretamente nesta sessão; ler a skill é uma alternativa suportada nesta lição.
+
+```plaintext
+Leia .github/skills/quality-checks/SKILL.md e siga as instruções para validar o recurso de filtragem nesta cópia de trabalho. Primeiro examine o código de cada wrapper para verificar se ele calcula o diretório que contém o package.json pretendido desta cópia de trabalho e falha explicitamente para uma raiz inválida, em vez de depender da descoberta de pacotes em diretórios ancestrais pelo npm. Não mova, renomeie, exclua nem modifique arquivos do repositório para simular falhas. Execute realmente os scripts incluídos para lint, testes de unidade, testes de ponta a ponta e verificações de tipos. Execute também o exemplo documentado de um único arquivo de testes de unidade, passando os argumentos da ferramenta de destino diretamente porque o wrapper é responsável pelo separador -- do npm. Verifique nos resultados do executor de testes se APENAS o arquivo indicado foi executado e relate o nome desse arquivo e a quantidade de arquivos de teste executados. Exibir os argumentos ou retornar o código de saída 0 não comprova, por si só, que a seleção está correta.
+
+Relate cada invocação de script e seu resultado, incluindo falhas, verificações ignoradas ou pré-requisitos ausentes. Não substitua silenciosamente um script inutilizável da skill por comandos npm diretos. Identifique a cópia de trabalho e o servidor em teste, pare apenas os servidores que você iniciou e pergunte antes de instalar algo ou parar outro processo. Não altere código da aplicação, não mude de branch, não faça commit, push nem abra um pull request.
+```
+
+Examine as chamadas de ferramentas e a saída. Os quatro scripts precisam realmente executar; uma descrição das verificações ou uma verificação ignorada não equivale à aprovação. Para o exemplo de um único arquivo, compare o nome do arquivo solicitado com os resultados reais por arquivo do executor e a quantidade relatada: apenas esse arquivo deve executar. Exibir os argumentos ou retornar o código de saída 0 é insuficiente se outros arquivos também executaram. Uma falha é evidência útil: corrija a skill ou resolva o bloqueio de configuração com aprovação e execute novamente as verificações afetadas. Não pare processos não relacionados nem force a resolução de um conflito de porta.
+
+## Salvar um checkpoint
+
+Após revisar a skill e seus resultados, autorize um checkpoint local:
+
+```plaintext
+Revise o diff atual e crie um commit de checkpoint apenas para os arquivos da skill quality-checks. Mantenha a branch de filtragem existente. Não faça push nem crie um pull request.
+```
+
+Os arquivos da skill acompanharão a filtragem, o perfil de QA e os testes associados no PR do recurso na Lição 8. Continue nesta mesma sessão com a [Lição 6 - Validar a funcionalidade com o MCP do Playwright][next-lesson].
+
+## Mais exemplos de skills
+
+Estes exemplos da comunidade são referências, não tarefas adicionais. Revise seus pré-requisitos e comportamento antes de adotá-los:
+
+- [Fluxo de contribuição: `make-repo-contribution`][contribution-example].
+- [Documentos de requisitos: `prd`][prd-example].
+- [Diagramas e um script de exportação incluído: `drawio`][drawio-example].
+- [Testes de navegador: `webapp-testing`][browser-example].
+
+O exemplo original de contribuição se chama `make-repo-contribution`; modelos antigos do Tailspin usavam outro nome, `make-contribution`. Este workshop não depende de nenhuma dessas skills de contribuição.
+
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/pt-br/app/5-mcp-playwright.md b/docs/pt-br/app/5-mcp-playwright.md
deleted file mode 100644
index 1f9ea34e..00000000
--- a/docs/pt-br/app/5-mcp-playwright.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: "Lição 5 - Testar com o servidor MCP do Playwright"
-description: "Adicione o servidor MCP do Playwright ao aplicativo GitHub Copilot e peça ao agente que teste manualmente o recurso de filtragem em um navegador real."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-Na lição anterior, você criou e verificou o recurso de filtragem com o conjunto de testes automatizados do projeto. Os testes automatizam a validação do código, mas permitir que o agente confirme o comportamento é uma abordagem eficiente. Assim, o agente pode responder a problemas identificados na própria interface que está criando. Vamos explorar como o MCP dá aos agentes de IA acesso a recursos externos e adicionar o servidor MCP do Playwright para permitir que o Copilot interaja diretamente com o site que você está desenvolvendo.
-
-Nesta lição, você vai:
-
-- entender o que é o Model Context Protocol (MCP) e como o aplicativo GitHub Copilot o utiliza.
-- adicionar o servidor MCP do Playwright nas configurações do aplicativo.
-- pedir ao agente que controle um navegador e explore o recurso de filtragem.
-
-## Cenário
-
-Embora os testes de unidade e de ponta a ponta sejam importantes, validar atualizações na interface exige interagir com ela. Você quer permitir que o Copilot use o site em desenvolvimento como uma pessoa usuária faria, automatizando ainda mais o processo de alteração e aumentando a confiança de que as atualizações se comportam conforme o esperado.
-
-## O que é o Model Context Protocol (MCP)?
-
-O [Model Context Protocol (MCP)][mcp-blog-post] oferece aos agentes de IA uma forma de se comunicar com ferramentas e serviços externos em tempo real. Isso permite que eles acessem informações atualizadas, usando recursos, e realizem ações em seu nome, usando ferramentas.
-
-Essas ferramentas e esses recursos são acessados por meio de um servidor MCP, que funciona como uma ponte entre o agente de IA e as ferramentas e os serviços externos. O servidor MCP é responsável por gerenciar essa comunicação, seja com APIs existentes ou com ferramentas locais, como pacotes NPM. Cada servidor MCP representa um conjunto diferente de ferramentas e recursos que o agente de IA pode acessar.
-
-Alguns servidores MCP conhecidos são:
-
-- [**GitHub MCP Server**](https://github.com/github/github-mcp-server): oferece acesso a um conjunto de APIs para gerenciar repositórios do GitHub. Ele permite que o agente de IA realize ações como criar repositórios, atualizar repositórios existentes e gerenciar issues e pull requests.
-- [**Playwright MCP Server**][playwright-mcp-server]: oferece recursos de automação de navegador usando o Playwright. Ele permite que o agente de IA realize ações como acessar páginas Web, preencher formulários e selecionar botões.
-
-Há muitos outros servidores MCP que fornecem acesso a diferentes ferramentas e recursos. O GitHub mantém um [registro de MCP](https://github.com/mcp) para facilitar a descoberta e as contribuições ao ecossistema.
-
-> [!CAUTION]
-> Trate os servidores MCP como qualquer outra dependência do projeto. Antes de usar um servidor MCP, revise cuidadosamente o código-fonte, verifique quem o publicou e considere as implicações de segurança. Use apenas servidores MCP confiáveis e tenha cuidado ao conceder acesso a recursos ou operações confidenciais.
-
-## Adicionar o servidor MCP do Playwright
-
-Você adiciona e gerencia servidores MCP nas configurações do aplicativo. O aplicativo inclui um catálogo de servidores conhecidos, portanto o [servidor MCP do Playwright][playwright-mcp-server] está a poucas seleções de distância.
-
-1. Selecione Ctrl+, para abrir a página de configurações do aplicativo Copilot.
-2. Selecione **MCP servers**.
-3. Na caixa de diálogo de pesquisa, digite `Playwright`.
-4. Selecione **Playwright** na lista de **Popular MCP servers**.
-5. Selecione **Add server** para adicioná-lo à lista de servidores MCP disponíveis.
-6. Selecione Esc para fechar a caixa de diálogo de configurações.
-
-Você adicionou o servidor MCP do Playwright.
-
-## Pedir ao Copilot que explore o recurso com o Playwright
-
-Vamos pedir ao Copilot que teste manualmente o recurso usando o servidor MCP do Playwright.
-
-1. Use o prompt a seguir para pedir ao Copilot que valide a nova funcionalidade:
-
- ```plaintext
- Start the dev server then use the Playwright MCP server to validate the functionality you just added exists. Use the details in the issue to ensure the newly added behavior matches the specs.
- ```
-
-O Copilot iniciará um navegador por meio do servidor MCP do Playwright, percorrerá cada etapa e relatará o que encontrou. Você verá um navegador ser aberto no sistema para executar as tarefas.
-
-2. Leia o resumo e compare-o aos critérios de aceitação da issue. Se algo parecer incorreto, faça perguntas complementares ou peça que o agente corrija o código antes de abrir um pull request.
-3. Mantenha esta sessão aberta, pois vamos concluí-la na próxima lição.
-
-O Copilot também validou a funcionalidade no navegador, explorando o recurso como uma pessoa usuária faria.
-
-## Resumo e próximos passos
-
-Parabéns! Você usou o servidor MCP do Playwright para explorar o recurso em um navegador real a partir do aplicativo GitHub Copilot. Recapitulando, você:
-
-- aprendeu o que é o Model Context Protocol (MCP) e como o aplicativo disponibiliza ferramentas MCP.
-- adicionou o servidor MCP do Playwright nas configurações do aplicativo.
-- pediu ao agente que controlasse um navegador e explorasse o recurso de filtragem.
-
-O recurso está criado, verificado e funcionando. Agora é hora de entregá-lo usando o **Agent Merge** para abrir e fazer o merge do pull request. Continue para a [Lição 6 - Fazer merge com o Agent Merge][next-lesson].
-
-## Recursos
-
-- [O que é MCP e por que todos estão falando sobre ele?][mcp-blog-post]
-- [Servidor MCP do Microsoft Playwright][playwright-mcp-server]
-- [Configurar servidores MCP no aplicativo GitHub Copilot][customize-app]
-
-[next-lesson]: ../6-agent-merge/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
\ No newline at end of file
diff --git a/docs/pt-br/app/6-agent-merge.md b/docs/pt-br/app/6-agent-merge.md
deleted file mode 100644
index 44e61b3d..00000000
--- a/docs/pt-br/app/6-agent-merge.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: "Lição 6 - Fazer merge com o Agent Merge"
-description: "Abra o pull request de filtragem, revise-o em My work e permita que o Agent Merge corrija o que estiver bloqueando e faça o merge para você, no nível mais alto da automação de merge."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-O recurso de filtragem está criado, verificado e funcionando em um navegador. A última etapa é fazer o merge. Você já fez isso duas vezes neste percurso. Nas duas ocasiões, abriu o pull request e fez o merge por conta própria no github.com. Desta vez, o aplicativo fará o trabalho operacional com o **Agent Merge**, que conduz todo o ciclo de vida de um pull request dentro do aplicativo.
-
-Nesta lição, você vai:
-
-- aprender o que é o Agent Merge e como ele automatiza o ciclo de vida do merge.
-- habilitar o Agent Merge na sessão de filtragem.
-- observar como ele cria o pull request, executa a CI e faz o merge quando todas as verificações passam.
-
-## Cenário
-
-Nos últimos módulos, você explorou vários níveis de automação, desde a criação de código até permitir que o Copilot valide diretamente uma interface. Para acelerar ainda mais o desenvolvimento, a Tailspin Toys quer descobrir se pull requests já avaliados e validados podem ter o merge feito automaticamente.
-
-## Apresentação do Agent Merge
-
-O **Agent Merge** permite automatizar a etapa final de integração de um pull request por meio do aplicativo Copilot. Quando você o habilita, a sessão do aplicativo lê o pull request, resolve o que estiver bloqueando o merge, como verificações de CI com falha, comentários de revisão e a necessidade de rebase, e faz o merge assim que o GitHub permite. Ele é executado em segundo plano, continua funcionando após reinicializações do aplicativo e é desativado automaticamente quando o pull request é integrado.
-
-Até aqui, você selecionou **Merge pull request** no github.com. O Agent Merge transfere essa responsabilidade ao agente, permitindo que você passe para a próxima tarefa enquanto ele conduz o PR até a conclusão. Você ainda revisa e aprova o trabalho; o agente apenas cuida das etapas operacionais finais.
-
-## Usar o Agent Merge para gerenciar o PR
-
-Você revisou o código manualmente, executou testes e permitiu que o Copilot validasse a interface. Agora é hora de integrar o novo código à base de código. Vamos permitir que o Agent Merge conduza o PR pela integração contínua (CI) e faça o merge.
-
-1. Volte à sessão mantida aberta no módulo anterior, na qual você estava adicionando a funcionalidade de filtragem.
-2. No canto superior direito, selecione o menu suspenso ao lado de **Create PR**.
-3. Selecione **Agent merge** para habilitá-lo.
-
- 
-
-4. O texto do botão mudará para **Agent merge**.
-5. Selecione o botão **Agent merge** para iniciar o processo.
-
-O aplicativo Copilot começará a criar e gerenciar o PR. Primeiro, ele explora o projeto para determinar a melhor maneira de criar um PR e depois cria o novo PR.
-
-Após alguns instantes, você verá que o Copilot voltou a trabalhar, agora analisando as condições do PR, incluindo o processo de CI que executa todos os testes do repositório. Ele informará o status das revisões deixadas por outras pessoas da equipe, das verificações que precisam ser executadas e da possibilidade de fazer o merge do PR.
-
-6. Permita que o Agent Merge faça o merge do pull request selecionando o menu suspenso ao lado de **Agent merge** e depois **Merge pull request**.
-
- 
-
-7. Quando todos os processos de CI estiverem verdes, indicando que os testes passaram, o Copilot fará o merge do pull request.
-
-## Resumo e próximos passos
-
-Você automatizou várias partes do processo de desenvolvimento, incluindo a geração, o teste e a validação de código e, agora, o processo de pull request. Você:
-
-- aprendeu o que é o Agent Merge e como ele automatiza o ciclo de vida do merge.
-- habilitou o Agent Merge na sessão de filtragem.
-- observou como ele criou o pull request, executou a CI e fez o merge quando todas as verificações passaram.
-
-Em seguida, você explorará **canvases**, uma maneira mais completa de planejar e visualizar o trabalho com o agente. Continue para a [Lição 7 - Planejar com canvases][next-lesson].
-
-## Recursos
-
-- [Gerenciar issues e pull requests com o aplicativo GitHub Copilot][managing-issues-prs]
-- [Sobre o aplicativo GitHub Copilot][about-copilot-app]
-
-[next-lesson]: ../7-canvases/
-[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/pt-br/app/6-mcp-playwright.md b/docs/pt-br/app/6-mcp-playwright.md
new file mode 100644
index 00000000..86ef1bac
--- /dev/null
+++ b/docs/pt-br/app/6-mcp-playwright.md
@@ -0,0 +1,90 @@
+---
+title: "Lição 6 - Validar a funcionalidade com o MCP do Playwright"
+description: "Configure o MCP do Playwright pelo Customize e observe a filtragem no navegador, no worktree existente do recurso."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Na lição anterior, você reuniu e executou as verificações do projeto por meio da skill quality-checks. Agora dê ao agente acesso a um navegador para observar diretamente a interface de filtragem. Permaneça na mesma sessão, worktree e branch de filtragem. Esta lição acrescenta evidências do navegador, não outro recurso, uma nova execução de toda a suíte de testes ou um PR.
+
+Nesta lição, você vai:
+
+- entender o que é o Model Context Protocol (MCP) e como o aplicativo GitHub Copilot o utiliza.
+- adicionar o servidor MCP do Playwright pelo **Customize**.
+- pedir ao agente que controle um navegador e explore o recurso de filtragem.
+
+## Cenário
+
+Embora os testes de unidade e de ponta a ponta sejam importantes, validar atualizações na interface exige interagir com ela. Você quer permitir que o Copilot use o site em desenvolvimento como uma pessoa usuária faria, automatizando ainda mais o processo de alteração e aumentando a confiança de que as atualizações se comportam conforme o esperado.
+
+## O que é o Model Context Protocol (MCP)?
+
+O [Model Context Protocol (MCP)][mcp-blog-post] oferece aos agentes de IA uma forma de se comunicar com ferramentas e serviços externos em tempo real. Isso permite que eles acessem informações atualizadas, usando recursos, e realizem ações em seu nome, usando ferramentas.
+
+Essas ferramentas e esses recursos são acessados por meio de um servidor MCP, que funciona como uma ponte entre o agente de IA e as ferramentas e os serviços externos. O servidor MCP é responsável por gerenciar essa comunicação, seja com APIs existentes ou com ferramentas locais, como pacotes NPM. Cada servidor MCP representa um conjunto diferente de ferramentas e recursos que o agente de IA pode acessar.
+
+Alguns servidores MCP conhecidos são:
+
+- [**GitHub MCP Server**](https://github.com/github/github-mcp-server): oferece acesso a um conjunto de APIs para gerenciar repositórios do GitHub. Ele permite que o agente de IA realize ações como criar repositórios, atualizar repositórios existentes e gerenciar issues e pull requests.
+- [**Playwright MCP Server**][playwright-mcp-server]: oferece recursos de automação de navegador usando o Playwright. Ele permite que o agente de IA realize ações como acessar páginas Web, preencher formulários e selecionar botões.
+
+Há muitos outros servidores MCP que fornecem acesso a diferentes ferramentas e recursos. O GitHub mantém um [registro de MCP](https://github.com/mcp) para facilitar a descoberta e as contribuições ao ecossistema.
+
+> [!CAUTION]
+> Trate os servidores MCP como qualquer outra dependência do projeto. Antes de usar um servidor MCP, revise cuidadosamente o código-fonte, verifique quem o publicou e considere as implicações de segurança. Use apenas servidores MCP confiáveis e tenha cuidado ao conceder acesso a recursos ou operações confidenciais.
+
+## Adicionar o servidor MCP do Playwright
+
+A [documentação atual de personalização do aplicativo][customize-app] usa **Customize** na barra lateral para descobrir e gerenciar MCP. Servidores MCP configurados para seus repositórios ou para o Copilot CLI já podem estar disponíveis no aplicativo; examine os servidores instalados antes de adicionar um duplicado.
+
+1. Selecione **Customize** na barra lateral.
+2. Selecione **MCP** e verifique em **Installed** se já existe um servidor Playwright.
+3. Se necessário, encontre **Playwright** entre os servidores disponíveis ou use o fluxo de servidor personalizado documentado pelo publicador.
+4. Revise o publicador, a configuração e as solicitações de instalação antes de aprová-las. Siga as instruções para adicionar o servidor; políticas da organização ou pré-requisitos ausentes podem bloquear a configuração.
+5. Volte à sessão de filtragem existente e mantenha o modo **Interactive**. Confirme que as ferramentas de navegador do MCP do Playwright estão disponíveis antes de solicitar a validação. Não crie um novo worktree do recurso como solução alternativa de configuração.
+
+Se a configuração falhar, resolva o problema de configuração ou permissão em vez de aceitar uma afirmação de que o agente navegou sem ferramentas. A visibilidade do navegador depende da configuração do servidor; a atividade real das ferramentas e as observações são as evidências.
+
+## Pedir ao Copilot que explore o recurso com o Playwright
+
+Use a URL real da issue e os esclarecimentos aprovados salvos na Lição 4. Pare qualquer servidor de desenvolvimento manual das lições anteriores antes de o agente iniciar o próprio servidor. Ele deve identificar a cópia de trabalho e o servidor em teste.
+
+1. Use o prompt a seguir para pedir ao Copilot que valide a nova funcionalidade:
+
+ ```plaintext
+ Use o servidor MCP do Playwright configurado para observar o recurso de filtragem conforme esta issue: . Estes são meus esclarecimentos de planejamento aprovados: . Permaneça neste worktree e branch de filtragem.
+
+ Identifique a cópia de trabalho, inicie seu servidor de desenvolvimento e use ferramentas reais de navegador para exercitar a seleção de várias categorias, a filtragem por distribuidora, a filtragem combinada, os controles acessíveis e qualquer comportamento acordado de limpeza de filtros ou resultados vazios. Relate observações em relação aos critérios, incluindo falhas ou verificações bloqueadas. Não afirme comportamentos que não observou.
+
+ Esta etapa é uma observação no navegador, não outra execução automatizada completa de testes. Não altere código da aplicação, testes, skills ou perfis de agente, não faça commit, push nem crie um PR. Relate ferramentas MCP ou pré-requisitos ausentes como bloqueios e pergunte antes de instalar qualquer coisa. Não reutilize o servidor de outra cópia de trabalho nem interrompa processos não relacionados. Ao terminar, pare apenas o servidor que você iniciou.
+ ```
+
+Examine as chamadas de ferramentas MCP do Playwright, a URL em teste e as observações relatadas do navegador. Uma narrativa baseada apenas no código-fonte ou em resultados E2E anteriores não demonstra o uso de MCP.
+
+2. Compare o resumo com a issue e os esclarecimentos aprovados. Se houver um defeito, autorize uma correção específica separadamente, revise o diff alterado e repita as verificações automatizadas e observações do navegador relevantes. Evidências anteriores à correção não comprovam a revisão resultante.
+3. Confirme que o agente parou o próprio servidor. Mantenha esta sessão de filtragem aberta e permaneça no modo **Interactive** antes de criar o perfil QA na Lição 7.
+
+Esta etapa estabelece observação direta, não substitui a cobertura automatizada. Falhas ou observações bloqueadas permanecem visíveis para o QA.
+
+## Resumo e próximos passos
+
+Parabéns! Você usou o servidor MCP do Playwright para explorar o recurso em um navegador real a partir do aplicativo GitHub Copilot. Recapitulando, você:
+
+- aprendeu o que é o Model Context Protocol (MCP) e como o aplicativo disponibiliza ferramentas MCP.
+- configurou o servidor MCP do Playwright pelo **Customize**.
+- pediu ao agente que controlasse um navegador e explorasse o recurso de filtragem.
+
+Em seguida, reúna os requisitos, as observações do navegador, a cobertura e a skill em um perfil especializado. Continue nesta mesma sessão para a [Lição 7 - Criar e usar um agente QA][next-lesson]. Não crie o PR do recurso ainda.
+
+## Recursos
+
+- [O que é MCP e por que todos estão falando sobre ele?][mcp-blog-post]
+- [Servidor MCP do Microsoft Playwright][playwright-mcp-server]
+- [Configurar servidores MCP no aplicativo GitHub Copilot][customize-app]
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
+[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
\ No newline at end of file
diff --git a/docs/pt-br/app/7-canvases.md b/docs/pt-br/app/7-canvases.md
deleted file mode 100644
index abbd6aa6..00000000
--- a/docs/pt-br/app/7-canvases.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: "Lição 7 - Planejar com canvases"
-description: "Crie um canvas compartilhado e orientado por agentes no aplicativo GitHub Copilot para planejar e acompanhar seu trabalho junto com o agente."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-Até agora, você orientou agentes pelo chat. No entanto, grande parte do trabalho não acontece em uma conversa, mas em um quadro, documento ou checklist. Os **canvases** oferecem a você e ao agente uma superfície compartilhada exatamente para esse tipo de trabalho, dentro do aplicativo. Nesta lição, você criará um canvas simples para planejar e acompanhar o backlog no qual vem trabalhando.
-
-Nesta lição, você vai:
-
-- entender o que é um canvas e quando usá-lo.
-- criar um canvas compartilhado de quadro Kanban para fazer a triagem do backlog.
-- salvar o canvas no repositório e integrá-lo para a equipe.
-- abrir o canvas em uma nova sessão e começar a trabalhar a partir dele.
-
-## Cenário
-
-Analisar uma lista de issues pode ser uma tarefa desafiadora, mesmo nas melhores condições. As pessoas desenvolvedoras da Tailspin Toys procuram uma ferramenta que permita fazer rapidamente a triagem de issues e começar a trabalhar nelas no aplicativo Copilot.
-
-## O que é um canvas?
-
-Um [canvas][canvas-docs] é uma superfície interativa e compartilhada para um artefato de trabalho, como um plano, um quadro de triagem, um checklist de lançamento, um painel ou um documento. Embora o chat seja ótimo para descrever intenções e analisar ambiguidades, a maior parte do trabalho acontece em uma *superfície*. Os canvases permitem colaborar com o agente diretamente nessa superfície.
-
-Os canvases são **bidirecionais**: o agente pode atualizar o canvas enquanto trabalha, e você pode editar a mesma superfície. Quando você cria um canvas, o agente o desenvolve com base no prompt e no fluxo de trabalho. Você pode pedir que ele adicione, remova ou revise recursos durante o processo. Depois de criado, o canvas é aberto no painel direito do aplicativo.
-
-Alguns exemplos comuns incluem:
-
-- **Canvases Markdown** para planejar o dia e priorizar issues e pull requests.
-- **Quadros Kanban agênticos** nos quais pessoas e agentes adicionam cards e movem o trabalho entre colunas.
-- **Quadros de triagem de issues** que resumem as principais issues e os temas recorrentes de um repositório.
-
-## Por que usar um canvas?
-
-Use um canvas quando uma tarefa exigir estrutura, iteração e verificação e o chat não for suficiente. Um canvas permite:
-
-- fundamentar o trabalho do agente em um artefato real adequado ao seu fluxo de trabalho.
-- orientar ou corrigir o trabalho diretamente na superfície compartilhada e depois permitir que o agente continue a partir das suas alterações.
-- acompanhar o progresso como alterações visíveis em um artefato, e não apenas como respostas no chat.
-
-## Criar um canvas para acompanhar o trabalho
-
-Você já entregou muitos recursos: a avaliação por estrelas, o padrão de documentação e o recurso de filtragem foram integrados. No entanto, ainda há itens no backlog. Vamos criar um canvas para ajudar a fazer rapidamente a triagem do trabalho.
-
-1. Volte ao aplicativo GitHub Copilot ou abra-o.
-2. Selecione **Home screen**.
-3. Verifique se `tailspin-toys` está selecionado como repositório.
-4. Na caixa de prompt, use o prompt a seguir para criar um canvas que atenda às nossas necessidades:
-
- ```plaintext
- Create a basic Kanban board canvas that allows me to quickly triage work. Highlight the three issues which are most likely to need attention right now, with the remainder in a second section down below. The top three cards should include a description of the issue's content and a justification of why they're at the top of the list. Each issue should have a button that allows me to add it to the current context for the current session so I can get to work on it straightaway.
- ```
-
-O Copilot começará a criar o canvas.
-
-> [!NOTE]
-> A criação levará alguns minutos. Como essa é uma tarefa complexa, talvez a primeira versão não atenda a todas as suas expectativas. Você pode continuar enviando prompts para criar a ferramenta ideal para suas necessidades.
-
-## Salvar o canvas e integrá-lo ao repositório
-
-Os canvases podem se tornar ativos do repositório, assim como arquivos de instruções e skills. Vamos pedir ao Copilot que adicione o canvas ao repositório e faça o merge para que toda a equipe possa usá-lo.
-
-1. Na mesma sessão, peça ao Copilot que salve o canvas no repositório usando o prompt a seguir:
-
- ```plaintext
- Let's save this canvas definition to the repository so I can share it with my development team
- ```
-
-2. Depois que o Copilot salvar os arquivos do canvas, selecione o menu suspenso ao lado de **Create PR** no canto superior direito.
-3. Selecione **Agent merge** para habilitá-lo.
-
- 
-
-4. O texto do botão mudará para **Agent merge**.
-5. Selecione o botão **Agent merge** para iniciar o processo.
-
-O aplicativo Copilot começará a criar e gerenciar o PR. Primeiro, ele explora o projeto para determinar a melhor maneira de criar um PR e depois cria o pull request.
-
-Após alguns instantes, você verá que o Copilot voltou a trabalhar, agora analisando as condições do PR, incluindo o processo de CI que executa todos os testes do repositório. Ele informará o status das revisões deixadas por outras pessoas da equipe, das verificações que precisam ser executadas e da possibilidade de fazer o merge do PR.
-
-6. Permita que o Agent Merge faça o merge do pull request selecionando o menu suspenso ao lado de **Agent merge** e depois **Merge pull request**.
-
- 
-
-7. Aguarde até que todos os processos de CI sejam concluídos com êxito e fiquem verdes. Quando isso acontecer, o Copilot fará o merge do pull request automaticamente.
-
-Você criou um novo canvas compartilhado para a equipe.
-
-## Trabalhar no canvas
-
-Com o canvas criado, vamos iniciar uma nova sessão e usá-lo.
-
-1. No aplicativo Copilot, inicie uma nova sessão selecionando **New session** ao lado de **tailspin-toys**.
-2. Peça ao Copilot que abra o canvas de triagem usando o prompt a seguir:
-
- ```plaintext
- Open the triage issues canvas
- ```
-
-3. O canvas criado será aberto nessa nova sessão.
-4. Selecione **Add to current context** em uma das issues que mais lhe interessam.
-5. O Copilot começará a trabalhar na issue.
-
-Você usou um canvas criado por você para otimizar o processo de desenvolvimento.
-
-## Resumo e próximos passos
-
-Você criou uma superfície compartilhada na qual você e o agente podem colaborar. Você:
-
-- aprendeu o que são canvases e quando usá-los.
-- criou com o agente um canvas compartilhado de quadro Kanban para triagem.
-- salvou o canvas no repositório e fez o merge dele com o Agent Merge.
-- abriu o canvas em uma nova sessão e o usou para começar a trabalhar.
-
-Com o backlog acompanhado, é hora de revisar tudo o que você criou e decidir os próximos passos. Continue para a [Lição 8 - Revisão e próximos passos][next-lesson].
-
-## Recursos
-
-- [Trabalhar com extensões de canvas no aplicativo GitHub Copilot][canvas-docs]
-- [Canvases no Awesome Copilot][awesome-copilot-canvases]
-- [Sobre o aplicativo GitHub Copilot][about-copilot-app]
-
-[next-lesson]: ../8-review/
-[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
-[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/pt-br/app/7-qa-agent.md b/docs/pt-br/app/7-qa-agent.md
new file mode 100644
index 00000000..1ccea645
--- /dev/null
+++ b/docs/pt-br/app/7-qa-agent.md
@@ -0,0 +1,73 @@
+---
+title: "Lição 7 - Criar e usar um agente de QA"
+description: "Crie um perfil de QA que parta dos requisitos e combine cobertura de testes, a skill quality-checks e evidências diretas do navegador."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Você executou verificações repetíveis e explorou a filtragem pelo MCP do Playwright. Agora crie um **agente personalizado de QA** para reunir os requisitos, a cobertura e as evidências do navegador. Mantenha a sessão, a cópia de trabalho e a branch de filtragem; o PR do recurso vem na Lição 8.
+
+## Criar o perfil de QA
+
+Permaneça no modo **Interactive**. Um perfil define o papel e as instruções de um especialista; uma skill reúne instruções de tarefas reutilizáveis, scripts e recursos. O agente de QA usará sua skill e as ferramentas MCP configuradas em vez de substituí-las.
+
+Envie este prompt e examine a definição antes de executá-la:
+
+```plaintext
+Crie um agente personalizado de QA reutilizável em .github/agents/qa.agent.md. Primeiro examine as instruções do repositório, package.json, a configuração de testes e .github/skills/quality-checks/SKILL.md. Forneça ao perfil um frontmatter YAML válido com name definido como QA e uma description que explique quando usá-lo. Não fixe um modelo nem adicione uma lista tools; herde as ferramentas e permissões disponíveis no ambiente. Crie apenas a definição do agente e pare para que eu possa examiná-la antes de executá-lo.
+
+Nas instruções do agente, exija que toda tarefa de QA comece pela issue e por quaisquer critérios de aceitação aprovados fornecidos pelo usuário. Trate esses requisitos como fonte de verdade, não a implementação. Pergunte quando faltarem requisitos ou eles forem ambíguos. Examine o recurso e os testes existentes e mapeie cada critério à cobertura automatizada adequada e ao comportamento observável.
+
+Exija validação direta no navegador pelo servidor MCP do Playwright configurado e execução de lint, testes de unidade, testes de ponta a ponta e verificações de tipos pela skill quality-checks existente e seus scripts incluídos. Leia a skill explicitamente se ela não tiver sido descoberta automaticamente. Relate skills, ferramentas MCP, pré-requisitos ou acesso ausentes como bloqueios; não substitua silenciosamente o fluxo por outro nem rotule verificações ignoradas como aprovadas. Identifique a cópia de trabalho e o servidor em teste, evite reutilizar o servidor de outro worktree, pare apenas os servidores iniciados pelo agente e pergunte antes de qualquer instalação ou de parar outro processo.
+
+Permita que o agente de QA adicione os menores testes necessários para lacunas reais de cobertura, seguindo as instruções do repositório; não adicionar testes é válido quando a cobertura já é adequada. Não enfraqueça asserções, não desative testes com falha, não altere critérios de aceitação para corresponder ao código nem modifique código da aplicação sem minha aprovação. Após alterações, execute novamente as verificações afetadas e conclua a verificação final da revisão resultante. Exija um relatório conciso que mapeie critérios a evidências e ao status aprovado/reprovado/bloqueado, liste os testes adicionados ou explique por que nenhum foi necessário, relate os resultados das quatro verificações e identifique defeitos não resolvidos. GO exige todas as verificações e evidências obrigatórias; caso contrário, relate NO-GO e o motivo. Não mude de branch, não faça commit, push, não abra ou integre PRs nem crie agentes ou skills adicionais durante QA.
+```
+
+## Examinar o perfil
+
+Abra `.github/agents/qa.agent.md` em **Changes** ou no painel de revisão de arquivos. `description` é obrigatório; esta lição também fornece `QA` como `name` legível. Confirme que não há um `model` fixado nem uma lista de ferramentas inventada. Omitir `tools` herda as ferramentas disponíveis; não contorna as permissões do ambiente. Perfis de produção podem restringir ferramentas deliberadamente.
+
+Confirme que as instruções começam pelos requisitos, exigem atividade real no navegador via MCP e scripts da skill, permitem apenas adições justificadas de testes e relatam bloqueios com veracidade. Nem um perfil especializado nem uma skill exige uma janela de contexto separada ou a orquestração de outros agentes.
+
+## Executar QA em relação à issue
+
+O prompt de execução é para o agente personalizado **QA** selecionado, não para o agente padrão lendo um perfil. Mantenha a mesma cópia de trabalho e branch de filtragem.
+
+1. Na sessão atual, abra o seletor de agentes na caixa do prompt ou digite `/agent`, conforme a [documentação de personalização do aplicativo][customize-app].
+2. Selecione **QA** e verifique se o aplicativo identifica visivelmente **QA** como agente ativo antes de enviar o prompt de execução.
+3. Se **QA** não estiver listado ou você não conseguir confirmar que está ativo, pause e peça ajuda à pessoa que conduz o workshop, mantendo este worktree e branch. Não crie outra sessão de recurso, não invente uma sequência de recarga nem substitua esta etapa por um pedido ao agente padrão para ler `qa.agent.md`.
+
+O seletor documentado está disponível durante uma sessão, mas a descoberta de um perfil de repositório recém-criado pode depender da versão do aplicativo. Não trate a criação do arquivo como prova de ativação.
+
+Substitua os dois marcadores pela URL real da issue de filtragem e os esclarecimentos aprovados na Lição 4, ou por `none` quando a issue estiver completa. Não dependa da memória do agente anterior.
+
+```plaintext
+Verifique o recurso de filtragem em relação a esta issue: . Estes são os critérios de aceitação adicionais que aprovei durante o planejamento: .
+
+Valide o comportamento com o servidor MCP do Playwright, examine a cobertura de testes, adicione testes apenas para lacunas de cobertura e execute a validação pela skill quality-checks. Relate evidências, resultados das verificações e bloqueios. Não altere código da aplicação sem minha aprovação, não crie um commit nem abra um pull request.
+```
+
+## Revisar as evidências
+
+Compare o relatório com a issue: cada critério precisa de cobertura automatizada adequada e comportamento observável. Examine a atividade real das ferramentas MCP do Playwright, a identidade da cópia de trabalho e do servidor e os resultados dos quatro scripts da skill. As verificações no navegador e E2E automatizadas não devem reutilizar um servidor desatualizado ou outra cópia de trabalho.
+
+Revise os testes adicionados: eles devem cobrir lacunas reais sem enfraquecer asserções. Não adicionar testes é correto quando a cobertura é adequada. Um parecer **NO-GO** por bloqueio ou falha é um resultado válido, não permissão para ignorar evidências.
+
+Se QA identificar um defeito na aplicação, aprove separadamente uma correção específica e execute novamente as verificações e observações no navegador afetadas na revisão resultante. Pré-requisitos ou ferramentas ausentes precisam de uma resolução explícita. Não trate evidências antigas como prova de código alterado.
+
+## Salvar um checkpoint
+
+Quando QA terminar, mantenha disponíveis o relatório, a URL da issue, os esclarecimentos aprovados e a revisão testada. Na mesma sessão, use o seletor de agentes documentado para voltar ao agente padrão do Copilot e confirme que **QA** não está mais selecionado. Mantenha a mesma cópia de trabalho e branch; não inicie outra sessão de recurso nem recarregue o worktree. Se não encontrar a opção do agente padrão, pause e peça ajuda à pessoa que conduz o workshop em vez de enviar instruções de commit ao QA.
+
+Após revisar o perfil, quaisquer alterações de testes e as evidências resultantes, envie a solicitação de checkpoint ao agente padrão com esse contexto de QA:
+
+```plaintext
+Revise o diff atual e crie um commit de checkpoint para a definição do agente de QA e quaisquer alterações de testes aprovadas. Permaneça na branch de filtragem existente. Não faça push nem abra um pull request.
+```
+
+Continue na [Lição 8 - Criar e integrar o PR do recurso][next-lesson] com o recurso de filtragem, a skill, o perfil de QA, os testes e as evidências atuais de verificação.
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/pt-br/app/8-create-pull-request.md b/docs/pt-br/app/8-create-pull-request.md
new file mode 100644
index 00000000..34372126
--- /dev/null
+++ b/docs/pt-br/app/8-create-pull-request.md
@@ -0,0 +1,89 @@
+---
+title: "Lição 8 - Criar e integrar o PR do recurso"
+description: "Revise a filtragem, a skill, o perfil QA e os testes em conjunto, crie o PR 3 e autorize explicitamente o Agent Merge."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+A implementação da filtragem, a skill quality-checks, o perfil QA e os testes associados estão salvos em commits de checkpoint em uma única branch. Revise-os em conjunto e use as evidências atuais de QA para preparar o PR 3. Você já fez o merge explicitamente dos PRs de avaliações por estrelas e instruções. Desta vez, usará o **Agent Merge** dentro do fluxo de PR, não como um recurso ou uma branch separados.
+
+Nesta lição, você vai:
+
+- aprender o que é o Agent Merge e como ele automatiza o ciclo de vida do merge.
+- examinar o PR completo do recurso e as evidências de verificação.
+- autorizar o Agent Merge somente após a revisão e confirmar que o PR foi integrado.
+
+## Cenário
+
+Nos últimos módulos, você explorou vários níveis de automação, desde a criação de código até permitir que o Copilot valide diretamente uma interface. Para acelerar ainda mais o desenvolvimento, a Tailspin Toys quer descobrir se pull requests já avaliados e validados podem ter o merge feito automaticamente.
+
+## Apresentação do Agent Merge
+
+O **Agent Merge** permite automatizar a etapa final de integração de um pull request por meio do aplicativo Copilot. Quando você o habilita, a sessão do aplicativo lê o pull request, resolve o que estiver bloqueando o merge, como verificações de CI com falha, comentários de revisão e a necessidade de rebase, e faz o merge assim que o GitHub permite. Ele é executado em segundo plano, continua funcionando após reinicializações do aplicativo e é desativado automaticamente quando o pull request é integrado.
+
+Até aqui, você selecionou **Merge pull request** por conta própria. O Agent Merge pode assumir essa responsabilidade, mas sua capacidade de editar código e fazer merge ainda exige autorização explícita. Revise as ações permitidas e o trabalho antes de conceder permissão de merge.
+
+## Revisar o marco completo
+
+Permaneça na sessão de filtragem das Lições 4–7. Verifique o diff completo da branch em relação a `main`, não apenas o último checkpoint: ele deve conter a filtragem, `.github/skills/quality-checks/SKILL.md`, os scripts incluídos, `.github/agents/qa.agent.md` e os testes associados.
+
+Use o seletor de agentes para voltar de **QA** ao agente geral do Copilot antes de solicitar commits ou ações de PR e mantenha o modo **Interactive**. O trabalho do perfil QA era verificar, não entregar. Mudar o agente selecionado não deve mudar a sessão, a cópia de trabalho ou a branch de filtragem.
+
+Este workshop combina deliberadamente o trabalho do recurso e a infraestrutura reutilizável de qualidade em um PR. Uma equipe de produção poderia separá-los; aqui, os commits de checkpoint preservam etapas revisáveis sem branches empilhadas ou PRs adicionais.
+
+Revise o relatório de QA da Lição 7. Reutilize suas evidências apenas se cobrirem a revisão final a ser enviada, com as quatro verificações e as observações relevantes no navegador concluídas. Se alterações de código, conflitos ou correções de CI modificarem o que foi testado, repita as verificações e observações afetadas e atualize as evidências. Um relatório **NO-GO** com falhas ou bloqueios não é aprovação de merge.
+
+Quando o diff e as evidências estiverem prontos, envie:
+
+```plaintext
+Revise o diff completo da branch de filtragem em relação a main, incluindo o recurso de filtragem, a skill quality-checks e seus scripts, a definição do agente QA e os testes associados. Resuma os critérios da issue, os esclarecimentos aprovados e as evidências atuais de QA. Reutilize a verificação apenas se ela ainda se aplicar à revisão final; relate evidências desatualizadas, ausentes ou com falhas antes de prosseguir.
+
+Se as alterações revisadas e a verificação estiverem prontas, faça commit de quaisquer alterações aprovadas restantes do marco, envie esta branch e crie um único PR do recurso destinado a main, usando o modelo de PR do repositório e a URL real da issue de filtragem. Mantenha o histórico de checkpoints nesta branch. Não use uma skill de contribuição, não crie outra branch ou PR nem faça o merge ainda.
+```
+
+Abra o PR em **My work** e examine **Files changed**, a descrição, as revisões e os resultados das verificações. Examine os próprios arquivos de fluxo de trabalho do Tailspin Toys e as verificações obrigatórias; não presuma que toda verificação local ou observação do navegador é executada na CI. O build Astro e o verificador de links que publicam o workshop pertencem a outro repositório e não validam este recurso.
+
+## Usar o Agent Merge para gerenciar o PR
+
+Após revisar o PR existente, configure o Agent Merge nesta mesma sessão. Não crie um segundo PR.
+
+1. Volte à sessão de filtragem e confirme que ela está vinculada ao PR 3.
+2. Abra o menu suspenso de ações de PR no canto superior direito. Antes de existir um PR, ele fica ao lado de **Create PR**; o rótulo pode mudar quando um PR está vinculado.
+3. Selecione **Agent merge** para habilitá-lo.
+4. Revise as permissões disponíveis, incluindo **Address reviews**, **Fix CI failures**, **Resolve conflicts** e **Merge pull request**. Mantenha a permissão de merge desativada enquanto houver achados ou verificações pendentes.
+5. Antes de iniciá-lo, envie o escopo e a autorização a seguir e selecione **Agent merge**:
+
+ ```plaintext
+ Gerencie este PR de filtragem existente com o Agent Merge. Resolva bloqueios de revisão ou CI apenas dentro do escopo deste PR. Não enfraqueça testes ou requisitos e pergunte antes de alterações não relacionadas ou instalações. Qualquer alteração na revisão testada exige atualizar as verificações relevantes e as evidências do navegador; não trate resultados antigos de QA como prova de código alterado.
+
+ Não faça o merge até eu habilitar explicitamente Merge pull request após revisar o diff final e as evidências. Não crie outro PR nem comece a tarefa do canvas.
+ ```
+
+6. Revise as alterações posteriores e os resultados atualizados. Quando o diff final estiver aprovado, a CI e as revisões obrigatórias passarem e as evidências de QA se aplicarem àquela revisão, autorize explicitamente o merge selecionando o menu suspenso ao lado de **Agent merge** e depois **Merge pull request**.
+
+ 
+
+7. Confirme que o GitHub mostra o PR 3 como **Merged**, não apenas apto para merge ou na fila. O Agent Merge não contorna proteções do repositório nem permissões ausentes; resolva esses bloqueios antes de continuar.
+
+Somente após esse merge você deve iniciar o marco do canvas. A Lição 9 cria um worktree novo e avança sua branch de sessão por fast-forward até o `origin/main` mais recente para que o canvas comece com o recurso completo integrado.
+
+## Resumo e próximos passos
+
+Você automatizou várias partes do processo de desenvolvimento, incluindo a geração, o teste e a validação de código e, agora, o processo de pull request. Você:
+
+- aprendeu o que é o Agent Merge e como ele automatiza o ciclo de vida do merge.
+- revisou o diff completo de filtragem, skill, perfil QA e testes como PR 3.
+- reutilizou as evidências atuais de QA, examinou a CI e autorizou explicitamente o Agent Merge.
+
+Em seguida, você explorará **canvases**, uma maneira mais completa de planejar e visualizar o trabalho com o agente. Continue para a [Lição 9 - Criar um canvas de triagem][next-lesson].
+
+## Recursos
+
+- [Gerenciar issues e pull requests com o aplicativo GitHub Copilot][managing-issues-prs]
+- [Sobre o aplicativo GitHub Copilot][about-copilot-app]
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-canvases/
+[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/pt-br/app/8-review.md b/docs/pt-br/app/8-review.md
deleted file mode 100644
index 704a1783..00000000
--- a/docs/pt-br/app/8-review.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: "Lição 8 - Revisão e próximos passos"
-description: "Recapitule o percurso do aplicativo GitHub Copilot, automatize trabalhos recorrentes e explore os próximos passos."
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-Nas últimas lições, você levou um recurso da ideia ao merge com o aplicativo GitHub Copilot. Nesse processo, você:
-
-- conectou um repositório e conheceu o espaço de trabalho do aplicativo e o backlog criado pelo modelo.
-- iniciou sessões a partir de uma tarefa direta e de issues e usou os modos Plan e Autopilot para controlar como o agente trabalha.
-- orientou o agente com instruções personalizadas e uma skill reutilizável.
-- testou o trabalho com o servidor MCP do Playwright em um navegador real.
-- colaborou com o agente em um canvas compartilhado.
-- entregou alterações avançando por níveis de automação de merge, desde fazer o merge por conta própria no github.com até permitir que o **Agent Merge** integrasse um pull request.
-
-Vamos automatizar parte do trabalho recorrente, analisar boas práticas e explorar os próximos passos.
-
-## Automatizar trabalhos recorrentes
-
-O aplicativo pode executar agentes para você em uma agenda ou sob demanda por meio de **automações**, ideais para tarefas rotineiras como fazer a triagem de novas issues ou recapitular atividades recentes. Vamos criar uma automação simples e não destrutiva.
-
-1. Selecione **Automations** na barra lateral e depois selecione **New automation**.
-2. Dê um nome a ela, como `Recap my recent work`.
-3. Escolha um gatilho. **Manual** permite executá-la sob demanda; **On a schedule** a executa automaticamente; **When an issue is created** reage a novas issues. Escolha **Manual** para esta lição.
-4. Insira um prompt somente leitura para impedir que a automação faça alterações. Por exemplo:
-
- ```plaintext
- Summarize the pull requests merged in this repository over the last week, and list any issues still open in the backlog.
- ```
-
-5. Escolha o projeto, ou seja, seu repositório Tailspin Toys, e crie a automação.
-6. Execute-a sob demanda para ver o resultado.
-
-> [!TIP]
-> As automações podem ser executadas localmente ou na nuvem. Habilite **Run in the cloud** e escolha as **Tools** que uma automação pode usar quando quiser que ela seja executada sem supervisão e de acordo com uma agenda. Mantenha as automações agendadas com escopo limitado e sem ações destrutivas até confiar nos resultados.
-
-## Boas práticas
-
-Ao usar qualquer ferramenta de IA, a infraestrutura ao redor dela influencia a qualidade dos resultados. Arquivos de instruções, skills e agentes personalizados tiveram uma função neste workshop. Invista neles e reutilize-os entre as sessões.
-
-Associe o **modo e o modelo** à tarefa. Use **Plan** para analisar uma abordagem antes de desenvolver, **Interactive** para acompanhar alterações específicas e **Autopilot** somente para tarefas isoladas e com escopo bem definido. Escolha um modelo mais rápido para edições rotineiras e um modelo mais avançado, com maior esforço de raciocínio, para trabalhos complexos.
-
-O contexto continua tão importante quanto a infraestrutura. Descrever claramente *o que* você quer criar, *por que* e *como* muda significativamente o resultado. Os chats rápidos são ótimos para definir o escopo de uma ideia antes de transformá-la em uma sessão completa.
-
-## Mais recursos para explorar
-
-Você percorreu o fluxo de trabalho principal. Veja outros recursos que valem a pena conhecer:
-
-- **Quick chats** para perguntas rápidas e descartáveis que não exigem uma sessão completa.
-- **Rubber duck** para analisar um problema e receber feedback relevante antes de começar a desenvolver.
-- [**Agentes personalizados**][custom-agents] para empacotar uma função, suas ferramentas e instruções para trabalhos especializados e repetíveis.
-- [`/chronicle`][chronicle] para gerar uma narrativa do que aconteceu em uma sessão.
-- [Bring your own key (BYOK)][byok] para usar modelos do seu próprio provedor, incluindo modelos locais por meio de Ollama, Foundry Local ou LM Studio.
-- [Sandboxes na nuvem][sandboxes] para executar sessões em um ambiente isolado hospedado pelo GitHub.
-- [Deep links][deep-links] para abrir o aplicativo diretamente em um repositório, uma sessão ou um prompt.
-
-## Próximos passos
-
-A melhor maneira de melhorar com qualquer ferramenta é continuar usando-a. Use-a em código de produção, em projetos pessoais ou naquele pequeno aplicativo que você planeja criar há anos. Compartilhe o que aprendeu com sua equipe e aprenda com as experiências dela. E, como sempre, explore a documentação.
-
-Para conhecer melhor o ecossistema do GitHub Copilot, confira o [percurso do VS Code](../../vscode/), o [percurso do Copilot CLI](../../cli/) ou o [percurso do agente de nuvem](../../cloud/).
-
-## Recursos
-
-- [Sobre o aplicativo GitHub Copilot][about-copilot-app]
-- [Introdução ao aplicativo GitHub Copilot][getting-started]
-- [Personalizar o aplicativo GitHub Copilot][customize]
-- [Usar automações][using-automations]
-- [Trabalhar com extensões de canvas][canvas-docs]
-- [Sobre sandboxes locais e na nuvem][sandboxes]
-
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
-[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
-[customize]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
-[using-automations]: https://docs.github.com/copilot/how-tos/github-copilot-app/using-automations
-[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
-[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
-[chronicle]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/chronicle
-[custom-agents]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
-[byok]: https://docs.github.com/copilot/how-tos/github-copilot-app/use-byok-models
-[deep-links]: https://docs.github.com/copilot/how-tos/github-copilot-app/open-with-deep-links
\ No newline at end of file
diff --git a/docs/pt-br/app/9-canvases.md b/docs/pt-br/app/9-canvases.md
new file mode 100644
index 00000000..3d82363f
--- /dev/null
+++ b/docs/pt-br/app/9-canvases.md
@@ -0,0 +1,148 @@
+---
+title: "Lição 9 - Criar um canvas de triagem"
+description: "Crie e revise um canvas de triagem salvo no repositório, integre o PR 4 e reabra-o para adicionar contexto de issues sem iniciar outro recurso."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Até agora, você orientou agentes pelo chat. No entanto, grande parte do trabalho não acontece em uma conversa, mas em um quadro, documento ou checklist. Os **canvases** oferecem a você e ao agente uma superfície compartilhada exatamente para esse tipo de trabalho, dentro do aplicativo. Nesta lição, você criará um canvas simples para planejar e acompanhar o backlog no qual vem trabalhando.
+
+Nesta lição, você vai:
+
+- entender o que é um canvas e quando usá-lo.
+- criar um canvas compartilhado de quadro Kanban para fazer a triagem do backlog.
+- salvar o canvas no repositório e integrá-lo para a equipe.
+- reabrir o canvas e adicionar contexto de issues sem implementar outro recurso.
+
+## Cenário
+
+Analisar uma lista de issues pode ser desafiador. As pessoas desenvolvedoras da Tailspin Toys querem uma ferramenta para fazer a triagem de issues e adicionar seus detalhes ao contexto de uma sessão. Adicionar contexto não autoriza implementar uma issue; este exercício termina com um quadro reutilizável, não com um quinto PR.
+
+## O que é um canvas?
+
+Um [canvas][canvas-docs] é uma superfície interativa e compartilhada para um artefato de trabalho, como um plano, um quadro de triagem, um checklist de lançamento, um painel ou um documento. Embora o chat seja ótimo para descrever intenções e analisar ambiguidades, a maior parte do trabalho acontece em uma *superfície*. Os canvases permitem colaborar com o agente diretamente nessa superfície.
+
+Os canvases são **bidirecionais**: o agente pode atualizar o canvas enquanto trabalha, e você pode editar a mesma superfície. Quando você cria um canvas, o agente o desenvolve com base no prompt e no fluxo de trabalho. Você pode pedir que ele adicione, remova ou revise recursos durante o processo. Depois de criado, o canvas é aberto no painel direito do aplicativo.
+
+Alguns exemplos comuns incluem:
+
+- **Canvases Markdown** para planejar o dia e priorizar issues e pull requests.
+- **Quadros Kanban agênticos** nos quais pessoas e agentes adicionam cards e movem o trabalho entre colunas.
+- **Quadros de triagem de issues** que resumem as principais issues e os temas recorrentes de um repositório.
+
+## Por que usar um canvas?
+
+Use um canvas quando uma tarefa exigir estrutura, iteração e verificação e o chat não for suficiente. Um canvas permite:
+
+- fundamentar o trabalho do agente em um artefato real adequado ao seu fluxo de trabalho.
+- orientar ou corrigir o trabalho diretamente na superfície compartilhada e depois permitir que o agente continue a partir das suas alterações.
+- acompanhar o progresso como alterações visíveis em um artefato, e não apenas como respostas no chat.
+
+## Criar um canvas para acompanhar o trabalho
+
+Confirme que o PR 3 foi integrado. As avaliações por estrelas, o padrão de documentação, o recurso de filtragem, a skill de qualidade e o perfil QA devem estar em `main` antes de iniciar o canvas. Use uma sessão nova e uma branch para este último marco de PR.
+
+1. Volte ao aplicativo GitHub Copilot ou abra-o.
+2. Selecione **Home screen**.
+3. Verifique se `tailspin-toys` está selecionado como repositório.
+4. Escolha **new working tree** e o modo **Interactive**. Envie esta solicitação de estado inicial antes de criar arquivos:
+
+ ```plaintext
+ Prepare esta nova sessão de canvas sem implementar nada. Confirme que este é um worktree novo e limpo, busque as atualizações de origin e avance a branch da sessão atual por fast-forward até origin/main. Informe a cópia de trabalho, a branch e as revisões correspondentes de HEAD e origin/main. Verifique se o PR de filtragem foi integrado e se o recurso de filtragem, a skill quality-checks e o perfil QA estão presentes.
+
+ Pare se houver alterações pendentes, divergências ou se o merge anterior estiver ausente. Não redefina, não descarte trabalho, não mude de branch nem crie outra branch. Pare após informar o estado inicial.
+ ```
+
+5. Verifique o relatório do estado inicial e solicite o canvas salvo no repositório:
+
+ ```plaintext
+ Crie um canvas Kanban básico de triagem salvo neste repositório usando o fluxo de extensões de canvas suportado pelo aplicativo. Salve sua definição em .github/extensions/ para que a equipe possa reutilizá-lo. Examine as extensões existentes e preserve-as; não sobrescreva o explorador de banco de dados incluído.
+
+ Leia as issues abertas atuais. Destaque as três com maior probabilidade de precisar de atenção e mostre as demais abaixo. Inclua em cada issue destacada o título, o resumo do conteúdo, a URL e uma justificativa para sua prioridade. Trate a classificação como sugestão, não como instrução para alterar issues.
+
+ Dê a cada card uma ação Add to current context que anexe os detalhes da issue apenas a esta sessão. Ela não deve iniciar a implementação, criar sessões ou branches, alterar o estado da issue nem criar PRs. Mantenha o escopo do canvas limitado e torne-o acessível por teclado.
+
+ Mostre os arquivos gerados e abra o canvas para inspeção. Não altere código da aplicação, não faça commit, push nem crie um PR. Pergunte antes de instalar qualquer coisa ou adicionar dependências.
+ ```
+
+O Copilot cria os arquivos do canvas e abre a superfície compartilhada. Revise a extensão gerada antes de confiar em suas ações; ela é conteúdo executável do repositório, não apenas uma imagem.
+
+> [!NOTE]
+> Se a primeira versão precisar de melhorias, solicite alterações específicas dentro do escopo de triagem. Não transforme este exercício na implementação de uma issue do backlog.
+
+## Inspecionar e exercitar o canvas
+
+1. Abra **Changes** e confirme que a definição do canvas está salva no repositório em `.github/extensions/`, não apenas para seu usuário ou sessão. Verifique se as extensões existentes e os arquivos da aplicação permanecem inalterados.
+2. Compare o quadro com as issues abertas reais e avalie as explicações da classificação.
+3. Verifique se os cards e controles são legíveis e utilizáveis por teclado.
+4. Selecione **Add to current context** em uma issue e confirme que apenas seus detalhes entram na conversa. Nenhuma implementação ou alteração de estado da issue deve começar.
+5. Revise as correções e peça ao Copilot que execute a validação existente aplicável aos arquivos alterados. Registre resultados e bloqueios, em vez de presumir que uma superfície interativa está correta apenas porque abriu.
+
+## Salvar o canvas e integrá-lo ao repositório
+
+O canvas já é um ativo do repositório. Faça commit e envie apenas o trabalho revisado do canvas como PR 4:
+
+1. Na mesma sessão, envie:
+
+ ```plaintext
+ Revise o diff do canvas de triagem salvo no repositório e suas evidências de validação. Faça commit dos arquivos aprovados do canvas na branch desta sessão, envie-a e crie um único PR destinado a main usando o modelo de PR do repositório. Descreva o comportamento do canvas e como verificamos que adicionar uma issue apenas adiciona contexto. Não faça o merge ainda nem implemente uma issue do backlog.
+ ```
+
+2. Revise o diff completo do PR e as verificações em **My work**. Confirme que ele contém o canvas, não trabalho da aplicação não relacionado.
+3. Na mesma sessão do canvas, abra o menu suspenso de ações de PR e selecione **Agent merge**. Revise as ações permitidas e mantenha **Merge pull request** desativado até aprovar o resultado final.
+4. Defina o escopo antes de iniciar o Agent Merge:
+
+ ```plaintext
+ Gerencie este PR de canvas existente com o Agent Merge. Resolva apenas bloqueios de revisão e CI dentro do escopo; pergunte antes de alterações não relacionadas ou instalações. Se o canvas mudar, repita a validação afetada e atualize as evidências. Não faça o merge até eu habilitar explicitamente Merge pull request após a revisão. Não implemente issues do backlog nem crie outro PR.
+ ```
+
+5. Selecione **Agent merge** e revise as alterações posteriores. Examine as verificações reais de CI do repositório do participante e resolva falhas; a CI não substitui o exercício do canvas.
+
+6. Quando o diff final e as evidências atuais estiverem aprovados e as verificações e revisões obrigatórias passarem, autorize explicitamente o Agent Merge a fazer o merge selecionando seu menu suspenso e depois **Merge pull request**.
+
+ 
+
+7. Confirme que o GitHub mostra o PR 4 como **Merged** antes de continuar.
+
+Você criou um novo canvas compartilhado para a equipe.
+
+## Reabrir o canvas sem iniciar outro recurso
+
+Reabra o canvas salvo no repositório na mesma sessão do canvas após o merge do PR. Esta é uma etapa de inspeção, não outra branch ou marco de PR.
+
+1. Volte à sessão do canvas, mantenha o modo **Interactive** e feche o painel do canvas se ainda estiver aberto.
+2. Envie:
+
+ ```plaintext
+ Reabra o canvas de triagem do repositório nesta mesma sessão. Adicionarei uma issue ao contexto apenas para examinar seus detalhes. Não edite arquivos, não implemente a issue, não altere seu estado, não crie outra sessão ou branch, não faça commit, push nem abra um PR.
+ ```
+
+3. Confirme que o canvas salvo abre novamente sem regenerar sua definição.
+4. Selecione **Add to current context** em uma das issues que mais lhe interessam.
+5. Confirme que os detalhes da issue selecionada aparecem no contexto sem iniciar a implementação. Pare aqui: o workshop tem quatro marcos de PR, não cinco.
+
+Você usou um canvas criado por você para otimizar o processo de desenvolvimento.
+
+## Resumo e próximos passos
+
+Você criou uma superfície compartilhada na qual você e o agente podem colaborar. Você:
+
+- aprendeu o que são canvases e quando usá-los.
+- criou com o agente um canvas compartilhado de quadro Kanban para triagem.
+- salvou o canvas no repositório e fez o merge dele com o Agent Merge.
+- reabriu o canvas integrado e adicionou contexto de issues sem iniciar outro recurso.
+
+Com o backlog acompanhado, é hora de revisar tudo o que você criou e decidir os próximos passos. Continue para a [Lição 10 - Revisão e próximos passos][next-lesson].
+
+## Recursos
+
+- [Trabalhar com extensões de canvas no aplicativo GitHub Copilot][canvas-docs]
+- [Canvases no Awesome Copilot][awesome-copilot-canvases]
+- [Sobre o aplicativo GitHub Copilot][about-copilot-app]
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
+[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/pt-br/app/README.md b/docs/pt-br/app/README.md
index 82e8ba78..afd949e8 100644
--- a/docs/pt-br/app/README.md
+++ b/docs/pt-br/app/README.md
@@ -3,12 +3,14 @@ slug: pt-br/app
title: "Aplicativo GitHub Copilot"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
O [**aplicativo GitHub Copilot**](https://docs.github.com/copilot/concepts/agents/github-copilot-app) é um aplicativo para desktop criado com base no Copilot CLI que reúne o desenvolvimento orientado por agentes em um espaço de trabalho único e focado. Ele oferece sessões paralelas de agentes, modos de sessão alternáveis, canvases compartilhados e gerenciamento nativo de issues e pull requests do GitHub, incluindo o **Agent Merge**, que conduz um pull request por rebases, feedback de revisão, correções de CI e merge.
-Ao longo destas lições, você instalará o aplicativo e configurará o projeto. Depois, conhecerá o espaço de trabalho do aplicativo e o backlog que o modelo criou para você. Você começará com uma pequena alteração, adicionando uma avaliação por estrelas, e então adicionará a partir de uma issue um padrão de instruções personalizadas, criará um recurso de filtragem em uma sessão isolada de agente e o verificará com uma skill reutilizável. Você adicionará o servidor MCP do Playwright para explorar o recurso em um navegador real e, em seguida, avançará por níveis de automação de merge até que o **Agent Merge** conclua o merge do pull request. Por fim, você colaborará em um canvas compartilhado e automatizará trabalhos recorrentes, completando todo o ciclo, da ideia ao recurso integrado.
+As Lições 0–1 de configuração preparam o projeto e o espaço de trabalho do aplicativo. Os nove módulos principais, as Lições 2–10, começam com uma melhoria rápida de avaliações por estrelas e uma convenção de documentação demonstrada em código real. Depois, você planejará e criará a filtragem, criará e executará uma skill quality-checks com scripts de shell, observará o recurso pelo MCP do Playwright e criará um agente personalizado QA para avaliar requisitos e cobertura. Você revisará o PR completo do recurso e autorizará o Agent Merge e, depois, criará e integrará um canvas compartilhado de triagem.
+
+O workshop tem quatro marcos de PR: avaliações por estrelas; instruções com sua demonstração; filtragem com a skill, o perfil QA e os testes; e, por fim, o canvas. Comece cada marco a partir de `main` atualizado, usando uma branch por PR em vez de uma por módulo. As Lições 4–8 permanecem na mesma sessão, worktree e branch de filtragem. Reabrir o canvas adiciona contexto de issues sem iniciar outro recurso ou um quinto PR. As automações são vinculadas como próximo passo, não como exercício adicional.
## Lições
@@ -16,13 +18,15 @@ Ao longo destas lições, você instalará o aplicativo e configurará o projeto
|--------|-------|-------------|
| [0. Pré-requisitos][ex0] | Configuração | Instale o Node.js e crie sua cópia do projeto Tailspin Toys |
| [1. Instalar o aplicativo Copilot][ex1] | Configuração | Instale o aplicativo, conecte seu projeto e conheça o espaço de trabalho |
-| [2. Executar sua primeira sessão de agente][ex2] | Primeira alteração | Inicie uma sessão e entregue uma pequena alteração como seu primeiro pull request |
-| [3. Orientar o Copilot com instruções personalizadas][ex3] | Contexto | Adicione a partir de uma issue um padrão de documentação e faça o merge |
-| [4. Criar um recurso com o Autopilot][ex4] | Recurso principal | Use Plan e Autopilot para criar a filtragem e verifique-a com uma skill |
-| [5. Testar com o MCP do Playwright][ex5] | Ferramentas externas | Adicione o servidor MCP do Playwright e explore o recurso em um navegador |
-| [6. Fazer merge com o Agent Merge][ex6] | Merge | Permita que o Agent Merge corrija e integre o pull request de filtragem |
-| [7. Planejar com canvases][ex7] | Colaboração | Crie um canvas compartilhado para planejar e acompanhar seu trabalho |
-| [8. Revisão e próximos passos][ex8] | Resumo | Automatize tarefas recorrentes e explore os próximos passos |
+| [2. Adicionar avaliações por estrelas: uma melhoria rápida][ex2] | Primeira alteração | Exiba as avaliações existentes e a alternativa para null e integre o PR 1 |
+| [3. Orientar o Copilot com instruções personalizadas][ex3] | Contexto | Adicione um padrão de documentação e uma demonstração real e integre o PR 2 |
+| [4. Criar a filtragem com Plan e Autopilot][ex4] | Implementação | Aprove o plano, implemente e verifique a filtragem e salve um checkpoint |
+| [5. Criar e usar uma skill quality-checks][ex5] | Verificações repetíveis | Crie, revise e execute os scripts de shell incluídos |
+| [6. Validar a funcionalidade com o MCP do Playwright][ex6] | Observação no navegador | Configure MCP pelo Customize e examine o comportamento da filtragem |
+| [7. Criar e usar um agente QA][ex7] | Requisitos e cobertura | Selecione um perfil especializado e reúna evidências de verificação final |
+| [8. Criar e integrar o PR do recurso][ex8] | Revisão e merge | Revise a filtragem, a skill, o perfil QA e os testes e autorize o Agent Merge para o PR 3 |
+| [9. Criar um canvas de triagem][ex9] | Colaboração | Compartilhe um canvas salvo no repositório no PR 4 e adicione contexto de issues |
+| [10. Revisão e próximos passos][ex10] | Resumo | Revise o fluxo, os artefatos e outros recursos |
## Pré-requisitos
@@ -50,9 +54,11 @@ Antes de participar deste workshop, verifique se você tem:
[ex2]: 2-add-star-rating/
[ex3]: 3-custom-instructions/
[ex4]: 4-build-filtering/
-[ex5]: 5-mcp-playwright/
-[ex6]: 6-agent-merge/
-[ex7]: 7-canvases/
-[ex8]: 8-review/
+[ex5]: 5-agent-skills/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-canvases/
+[ex10]: 10-review/
[install-git]: https://github.com/git-guides/install-git
[callout-student-plan-education]: https://github.com/education/students
\ No newline at end of file
diff --git a/docs/pt-br/cli/0-prerequisites.md b/docs/pt-br/cli/0-prerequisites.md
index a3ee88c9..e9e32331 100644
--- a/docs/pt-br/cli/0-prerequisites.md
+++ b/docs/pt-br/cli/0-prerequisites.md
@@ -2,7 +2,7 @@
title: "Lição 0: Pré-requisitos"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
Antes de começar as lições do Copilot CLI, você precisa deixar tudo pronto. Você criará sua própria cópia do repositório Tailspin Toys e iniciará um [codespace][codespaces], cujo terminal integrado será usado para instalar e executar o Copilot CLI na próxima lição.
@@ -11,6 +11,8 @@ Antes de começar as lições do Copilot CLI, você precisa deixar tudo pronto.
Para criar uma cópia do repositório para o código que você desenvolverá, crie uma instância a partir do [modelo][template-repository]. A nova instância conterá todos os arquivos necessários para o laboratório, e você a usará ao longo das lições.
+Use uma cópia nova do modelo. Ele inclui instruções do repositório, código da aplicação, testes e CI, mas não agentes personalizados ou skills. Você criará esses ativos. Se estiver voltando a uma cópia antiga, examine as personalizações existentes antes de alterá-las; não sobrescreva seu trabalho.
+
1. Em uma nova janela do navegador, acesse o repositório do GitHub deste laboratório: `https://github.com/github-samples/tailspin-toys`.
2. Crie sua própria cópia do repositório selecionando o botão **Use this template** na página do repositório do laboratório. Em seguida, selecione **Create a new repository**.
@@ -27,6 +29,8 @@ Para criar uma cópia do repositório para o código que você desenvolverá, cr
>
> Quando você cria o repositório a partir do modelo, um backlog de issues do GitHub é criado automaticamente. Você trabalhará com essas issues durante todo o workshop e não precisará criar nada por conta própria.
+Aguarde o término do fluxo de criação inicial de issues e verifique na aba **Issues** se aparecem **Allow users to filter games by category and publisher** e **Update our repository coding standards**. Use seus títulos e URLs reais nas lições, não números de issue presumidos. Se o backlog estiver ausente, examine o resultado do fluxo antes de prosseguir.
+
## Criar um codespace
Agora, você usará um codespace para concluir as lições do laboratório.
@@ -53,6 +57,8 @@ A criação do codespace levará alguns minutos, embora ainda seja muito mais r
[codespaces]: https://github.com/features/codespaces
[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
+Quando o codespace estiver pronto, a [Lição 1][next-lesson] abrirá o terminal e verificará o repositório, o ambiente de execução e a autenticação antes de instalar o Copilot CLI.
+
## Resumo
Parabéns, você criou uma cópia do repositório do laboratório! Você também iniciou a criação do seu codespace, que será usado quando começar a trabalhar com o Copilot CLI.
diff --git a/docs/pt-br/cli/1-install-copilot-cli.md b/docs/pt-br/cli/1-install-copilot-cli.md
index 65c00b37..acebd40f 100644
--- a/docs/pt-br/cli/1-install-copilot-cli.md
+++ b/docs/pt-br/cli/1-install-copilot-cli.md
@@ -2,7 +2,7 @@
title: "Lição 1 - Instalar o GitHub Copilot CLI"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
O [GitHub Copilot CLI][about-copilot-cli] é um poderoso assistente de programação baseado em agentes que é executado no terminal, permitindo explorar bases de código, gerar código, executar comandos e interagir com ferramentas externas — tudo pela linha de comando. Ele permite delegar tarefas, solicitar alterações e manter o foco. Como você pode imaginar, o primeiro passo é instalar a ferramenta. Felizmente, isso pode ser feito com ferramentas que você já conhece.
@@ -21,10 +21,25 @@ Sua equipe está começando a usar agentes de IA para avançar em um backlog cre
Antes de instalar o Copilot CLI, você precisa abrir uma janela de terminal no codespace.
-1. Volte ao codespace, caso ainda não esteja nele.
+1. Volte ao codespace e aguarde o término da configuração.
2. Abra uma janela de terminal pressionando Ctrl+`.
3. Você verá um painel de terminal aparecer na parte inferior da janela do VS Code.
+## Confirmar o ambiente do participante
+
+No terminal do codespace, confirme que você está no próprio repositório Tailspin Toys, não no repositório de conteúdo do workshop. Leia o `README.md` e o `package.json` para conhecer a configuração e os comandos de verificação. O Tailspin Toys atualmente exige Node.js 22.13 ou posterior, as dependências do projeto e o Chromium do Playwright para testes E2E.
+
+```bash
+pwd
+git remote -v
+node --version
+gh auth status
+```
+
+A GitHub CLI (`gh`) ajudará a examinar PRs e CI. Se faltar autenticação, use `gh auth login` e siga as instruções do navegador. Confirme que sua conta pode enviar branches e criar e integrar PRs neste repositório; políticas da organização podem exigir outro revisor. Resolva pré-requisitos ausentes usando as instruções de configuração do repositório antes de alterar código e revise qualquer instalação antes de autorizá-la.
+
+A CLI atua na cópia de trabalho em que você a inicia; começar uma conversa não cria automaticamente um worktree isolado. Este workshop usa uma branch por marco de PR. Você integrará primeiro as avaliações por estrelas e a demonstração de instruções e manterá a mesma branch de filtragem durante as Lições 4–8.
+
## Instalar o Copilot CLI
Você pode instalar o Copilot CLI por [npm][install-npm], [WinGet][install-winget] e [Homebrew][install-homebrew]. Como o GitHub Codespaces já inclui o Node.js, você usará o npm para instalar o Copilot CLI.
@@ -35,7 +50,7 @@ Você pode instalar o Copilot CLI por [npm][install-npm], [WinGet][install-winge
node --version
```
- Você deve ver a versão 22 ou posterior, por exemplo `v22.x.x`.
+ O Tailspin Toys exige a versão 22.13 ou posterior, mesmo que o requisito da própria CLI seja diferente. Siga as instruções de configuração do repositório do participante se a sua versão for antiga demais.
2. Instale o Copilot CLI globalmente no codespace com npm:
@@ -51,8 +66,8 @@ Você pode instalar o Copilot CLI por [npm][install-npm], [WinGet][install-winge
Você deve ver o número da versão exibido, por exemplo `v1.0.XX`.
-> [!TIP]
-> Se você encontrar erros de permissão, talvez precise usar `sudo npm install -g @github/copilot` em alguns sistemas. No entanto, isso não deve ser necessário no GitHub Codespaces.
+> [!NOTE]
+> Se a instalação falhar por erro de permissão, examine a configuração do npm ou peça ajuda à pessoa que conduz o workshop, em vez de executar novamente um comando desconhecido com privilégios elevados.
## Autenticar com o GitHub
@@ -85,22 +100,39 @@ Agora que você está no prompt do Copilot CLI pela primeira vez, vamos confiar
2. Neste workshop, selecione **Yes, and remember this folder for future sessions**, já que você trabalhará neste repositório ao longo de toda a atividade.
3. Faça uma pergunta simples ao Copilot para verificar se tudo funciona:
- ```
- What files are in this project?
+ ```plaintext
+ Quais arquivos existem neste projeto?
```
4. O Copilot deverá explorar o repositório e fornecer um resumo da estrutura do projeto.
5. Experimente o comando `/help` para ver os comandos de barra disponíveis:
- ```
+ ```text
/help
```
-6. Saia do Copilot CLI digitando o comando a seguir no terminal. Voltaremos ao Copilot CLI em uma lição futura.
+6. Saia desta sessão digitando o comando a seguir no prompt do Copilot. Você iniciará uma sessão nova para a primeira alteração.
+ ```text
+ /exit
```
- exit
- ```
+
+## Entender modos e permissões
+
+O Copilot CLI trabalha no diretório e na branch Git em que você o inicia. Confiar em um diretório permite usar o contexto do repositório; isso não equivale a aprovar todas as ações de ferramentas. Revise solicitações de permissão para alterações de arquivos, comandos de shell e operações do GitHub.
+
+Inicie as lições de código a partir da raiz do repositório do participante com:
+
+```bash
+copilot --enable-all-github-mcp-tools
+```
+
+O servidor MCP do GitHub é integrado. Essa opção expõe todas as suas ferramentas para trabalhar com issues e PRs; autenticação, permissões do repositório e aprovações de ferramentas continuam se aplicando. Ela não autoriza um commit ou PR por si só.
+
+Use Shift+Tab para alternar entre os modos padrão **Interactive**, **Plan** e **Autopilot**. Verifique o indicador de modo antes de enviar uma solicitação. Você manterá Interactive nas primeiras alterações, planejará a filtragem antes de criá-la e voltará explicitamente a Interactive antes de criar e revisar personalizações.
+
+> [!CAUTION]
+> As configurações de modo e permissão são diferentes. O Autopilot continua trabalhando de forma autônoma; `--allow-all` e seu alias `--yolo` concedem todas as permissões de ferramentas, caminhos e URLs. Este workshop não exige iniciar todas as sessões com permissões irrestritas. Revise o escopo antes de conceder acesso, mesmo dentro de um codespace.
## Resumo e próximos passos
@@ -111,7 +143,7 @@ Parabéns! Você instalou e autenticou o GitHub Copilot CLI com sucesso. Você a
- confiar em um diretório para o Copilot CLI trabalhar com ele.
- verificar se a instalação está funcionando corretamente.
-Agora que o Copilot CLI está instalado, vamos fornecer ao Copilot algum contexto sobre o projeto. Continue para a [Lição 2 - Instruções personalizadas com a CLI][next-lesson].
+Agora que o Copilot CLI está instalado, faça uma alteração pequena e revisável na [Lição 2 - Adicionar avaliações por estrelas: uma melhoria rápida][next-lesson].
## Recursos
@@ -120,7 +152,7 @@ Agora que o Copilot CLI está instalado, vamos fornecer ao Copilot algum context
- [Usar o Copilot CLI][using-copilot-cli]
[previous-lesson]: ../0-prerequisites/
-[next-lesson]: ../2-custom-instructions/
+[next-lesson]: ../2-add-star-rating/
[install-copilot-cli]: https://docs.github.com/copilot/how-tos/set-up/install-copilot-cli
[install-npm]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-npm-all-platforms
[install-winget]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-winget-windows
diff --git a/docs/pt-br/cli/10-review.md b/docs/pt-br/cli/10-review.md
new file mode 100644
index 00000000..2e0b3f49
--- /dev/null
+++ b/docs/pt-br/cli/10-review.md
@@ -0,0 +1,67 @@
+---
+title: "Lição 10 - Revisão e próximos passos"
+description: "Revise o fluxo de desenvolvimento compartilhado, os ativos reutilizáveis e os três marcos de pull request da CLI."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Você usou o Copilot CLI para passar de uma pequena alteração a um recurso planejado com verificação reutilizável. A configuração nas Lições 0–1 preparou seu ambiente; os nove módulos principais nas Lições 2–10 ensinaram um fluxo completo de desenvolvimento.
+
+## Revisar os três marcos de PR
+
+| Marco | Resultado integrado | Hábito de revisão |
+| --- | --- | --- |
+| PR 1: avaliações por estrelas | O `starRating` existente aparece nos cards dos jogos, incluindo `No rating yet` para `null` | Manter a alteração delimitada e verificar ambos os casos |
+| PR 2: instruções personalizadas | Uma convenção de documentação específica e uma pequena demonstração em código real | Verificar se as instruções melhoram código real, não apenas exemplos no chat |
+| PR 3: filtragem e verificação | Filtragem, a skill quality-checks, o perfil de QA e os testes associados | Revisar todos os checkpoints, as evidências atuais de QA e a CI antes do merge |
+
+Os dois primeiros PRs foram integrados antes de iniciar o próximo marco a partir de `main` atualizado. As Lições 4–8 compartilharam uma branch e uma cópia de trabalho. Commits de checkpoint preservaram o progresso sem criar um PR para cada módulo. A lição de controles não iniciou outro recurso ou PR.
+
+## Revisar os ativos compartilhados
+
+Estes são os mesmos resultados principais do [workshop do aplicativo Copilot][app-workshop], alcançados por uma interface de terminal:
+
+- **As instruções do repositório** explicam o contexto e os padrões do projeto; instruções com escopo de caminho acrescentam detalhes para os arquivos relevantes.
+- **A implementação de filtragem e os testes** atendem à issue e aos esclarecimentos aprovados durante o planejamento.
+- **A skill quality-checks** reúne instruções reutilizáveis e scripts reais de shell que executam as quatro verificações do projeto.
+- **A configuração do MCP do Playwright** fornece ferramentas de navegador para observação direta. Neste fluxo da CLI, ela fica na configuração do usuário, não no PR do recurso.
+- **O agente personalizado de QA** define um papel reutilizável que parte dos requisitos, verifica a cobertura, usa a skill e as ferramentas de navegador e relata resultados verdadeiros.
+- **O PR e as evidências de verificação** conectam as alterações revisadas aos resultados de testes, observações no navegador, limitações e CI.
+
+Uma skill é mais do que uma lista de comandos, e um perfil é mais do que um nome de arquivo. Você examinou os ativos gerados, confirmou a execução real e selecionou o agente personalizado antes de confiar no relatório.
+
+## Distinguir as finalidades da validação
+
+O planejamento esclareceu os requisitos antes da implementação. O Autopilot executou esse plano delimitado; voltar a Interactive restabeleceu pontos deliberados de revisão antes de criar personalizações.
+
+A implementação usou as verificações npm existentes antes de haver uma skill. A lição da skill comprovou que seus scripts incluídos e o encaminhamento de argumentos funcionavam. O MCP demonstrou interação direta com o navegador em vez de repetir uma suíte completa. QA combinou critérios, cobertura, evidências de navegador e as quatro verificações executadas pela skill. O PR reutilizou os resultados atuais de QA enquanto a CI verificou a revisão enviada.
+
+Falhas e bloqueios são resultados úteis. Ferramentas de navegador ausentes, testes ignorados, servidores desatualizados ou um requisito não resolvido significam **NO-GO**, não permissão para reduzir o padrão. Adições de testes se justificam por lacunas reais; não adicionar testes é correto quando a cobertura existente é adequada.
+
+## Levar estes hábitos adiante
+
+- Forneça ao Copilot a issue, o motivo da alteração e limites claros.
+- Revise os planos antes de aprovar trabalho autônomo.
+- Examine instruções, skills e perfis gerados antes de executá-los.
+- Saiba a qual cópia de trabalho, branch, servidor e revisão um resultado se refere.
+- Use a menor correção justificada e atualize as evidências após alterações.
+- Mantenha explícitas as instalações, ações destrutivas, compartilhamentos e merges de PR.
+
+## Continuar aprendendo
+
+O [workshop do aplicativo Copilot][app-workshop] alcança os resultados compartilhados por sua interface gráfica e adiciona um marco de canvas. O [workshop do VS Code][vscode-workshop] e o [workshop do agente de nuvem][cloud-workshop] exploram outras formas de trabalhar com agentes.
+
+Use o [Awesome Copilot][awesome-copilot] para encontrar exemplos de instruções, skills e agentes personalizados. Os [exemplos de skills da Lição 5][skill-examples] incluem fluxos de contribuição, documentos de requisitos, diagramas e testes de navegador. Revise os pré-requisitos e o comportamento antes de adotar conteúdo da comunidade.
+
+Para referência diária, consulte a [referência de comandos da CLI][cli-reference], a [documentação de skills de agente][agent-skills] e a [documentação de agentes personalizados][custom-agents]. Continue experimentando em tarefas delimitadas e compartilhe apenas material revisado por canais aprovados.
+
+[previous-lesson]: ../9-slash-commands/
+[app-workshop]: ../../app/
+[vscode-workshop]: ../../vscode/
+[cloud-workshop]: ../../cloud/
+[skill-examples]: ../5-agent-skills/#mais-exemplos-de-skills
+[awesome-copilot]: https://github.com/github/awesome-copilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
+[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
+[custom-agents]: https://docs.github.com/copilot/concepts/agents/copilot-cli/about-custom-agents
diff --git a/docs/pt-br/cli/2-add-star-rating.md b/docs/pt-br/cli/2-add-star-rating.md
new file mode 100644
index 00000000..c1d4ddf4
--- /dev/null
+++ b/docs/pt-br/cli/2-add-star-rating.md
@@ -0,0 +1,83 @@
+---
+title: "Lição 2 - Adicionar avaliações por estrelas: uma melhoria rápida"
+description: "Exiba as avaliações existentes dos jogos, revise e valide a alteração e integre seu primeiro pull request."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Comece com uma pequena alteração que você possa entender e verificar. O Tailspin Toys já armazena o `starRating` de cada jogo e o mostra na página de detalhes. Você exibirá esse valor existente nos cards dos jogos, incluindo uma mensagem clara quando um jogo não tiver avaliação.
+
+Nesta lição, você vai:
+
+- solicitar uma alteração específica em uma sessão Interactive da CLI.
+- examinar o diff e verificar cards com e sem avaliação.
+- fazer commit, abrir, revisar e integrar o PR 1.
+
+## Iniciar o primeiro marco
+
+Na raiz do repositório do participante, confirme que a árvore de trabalho está limpa, atualize `main` e crie uma branch. Se `git status` mostrar alterações inesperadas, resolva-as antes de mudar de branch; não as descarte.
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-star-rating
+copilot --enable-all-github-mcp-tools
+```
+
+Confie no repositório quando solicitado. Verifique se está no modo **Interactive** e use `/model` para examinar os modelos disponíveis ou selecionar **Auto**. Revise as aprovações de ferramentas conforme aparecerem.
+
+## Solicitar a alteração
+
+Envie este prompt:
+
+```plaintext
+Nos cards dos jogos, mostre a avaliação por estrelas de cada jogo. O tipo Game já inclui um campo starRating: um número em uma escala de cinco, ou null quando o jogo ainda não foi avaliado. Exiba-o em cada card em src/components/GameCard.astro e, quando starRating for null, mostre "No rating yet". Mantenha a alteração pequena e não reestruture o layout do card.
+
+Examine e siga as instruções do repositório. Use o modelo de dados existente; não adicione uma API de avaliações, um novo esquema ou um recurso não relacionado. Adicione ou atualize os testes adequados para os casos com e sem avaliação. Não faça commit, push nem abra um pull request ainda.
+```
+
+O Copilot deve examinar o tipo e o componente existentes antes de editar. Leia a atividade das ferramentas, além da resposta final. Um resumo confiante não comprova que a implementação está correta.
+
+## Revisar e validar
+
+1. Digite `/diff` e examine todos os arquivos alterados no editor ou na visualização de diff.
+2. Confirme que o card usa o `starRating` existente, exibe um valor em uma escala de cinco e mostra `No rating yet` para `null`. Uma verificação baseada apenas na conversão do valor para verdadeiro ou falso pode tratar incorretamente o zero numérico como ausência de avaliação.
+3. Verifique se a alteração preserva o layout do card e dá à avaliação um rótulo de texto significativo, em vez de depender apenas de uma estrela ou cor.
+4. Peça ao Copilot que verifique a alteração usando as verificações existentes:
+
+ ```plaintext
+ Examine package.json e a configuração de testes e execute lint, verificações de tipos e os testes de unidade ou E2E existentes adequados a esta alteração de card. Verifique tanto as avaliações numéricas quanto a alternativa para null; relate os comandos exatos e os resultados, incluindo lacunas de cobertura ou verificações bloqueadas. Não instale nada, não mude de branch, não faça commit, push nem abra um PR.
+ ```
+
+5. Revise a saída dos comandos e as alterações de testes. Resolva falhas antes da entrega; pergunte antes de instalar pré-requisitos ausentes.
+
+Para observar o card em um navegador, abra um segundo terminal nesta mesma cópia de trabalho e execute:
+
+```bash
+npm run dev
+```
+
+Abra a porta encaminhada no painel **Ports** do codespace. Examine os cards avaliados na página inicial. Se os dados iniciais atuais não tiverem exemplo sem avaliação, exija um teste automatizado com dados que cubram `null`; não afirme que observou um card sem avaliação. Pare o servidor de desenvolvimento com Ctrl+C no terminal dele antes de verificações E2E ou de sair da lição. Os testes automatizados do Playwright não devem reutilizar um servidor de outra cópia de trabalho.
+
+## Criar e integrar o PR 1
+
+Após revisar a alteração e passar nas verificações, autorize este marco separadamente:
+
+```plaintext
+Revise o diff atual e os resultados das verificações. Faça commit apenas da alteração revisada de avaliações por estrelas e seus testes, envie a branch atual e crie um pull request para main usando o modelo de PR deste repositório, se existir. Inclua o resumo da alteração e os resultados reais de verificação. Não integre o PR nem comece outra tarefa.
+```
+
+Abra a URL retornada do PR. Examine **Files changed** e os resultados das verificações, não apenas o resumo do agente. Revise as definições dos fluxos de trabalho do repositório Tailspin ao interpretar a CI; ela não substitui sua observação no navegador. Resolva falhas e verifique novamente o código alterado.
+
+Quando o PR atender aos requisitos de revisão e verificação do repositório, selecione **Merge pull request** e confirme o merge no GitHub. Se a proteção de branch exigir outro revisor, aguarde essa aprovação. Confirme que o PR está **Merged** antes de continuar.
+
+Saia da sessão do Copilot com `/exit`. Na próxima lição, você atualizará o `main` local antes de criar a branch de instruções; não a inicie a partir desta branch de recurso ainda não integrada.
+
+## Resumo e próximos passos
+
+Você concluiu o primeiro ciclo: um prompt com escopo limitado, código revisado, evidências de verificação e um PR integrado. Em seguida, [oriente o Copilot com instruções personalizadas][next-lesson] e demonstre uma convenção de documentação em um segundo PR pequeno.
+
+[previous-lesson]: ../1-install-copilot-cli/
+[next-lesson]: ../3-custom-instructions/
diff --git a/docs/pt-br/cli/2-custom-instructions.md b/docs/pt-br/cli/2-custom-instructions.md
deleted file mode 100644
index 20837dcf..00000000
--- a/docs/pt-br/cli/2-custom-instructions.md
+++ /dev/null
@@ -1,243 +0,0 @@
----
-title: "Lição 2 - Instruções personalizadas (Copilot CLI)"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-[Lição anterior: Instalar o Copilot CLI ←][previous-lesson] · [Próxima lição: Gerar código com a CLI →][next-lesson]
-
-O contexto é essencial ao trabalhar com IA generativa. Se uma tarefa precisar ser executada de uma maneira específica — ou se houver informações de contexto que o Copilot deva conhecer — você deve garantir que esse contexto esteja disponível. Há várias ferramentas para ajudar o Copilot, e você as explorará ao longo deste workshop. Vamos começar pelos [arquivos de instruções][instruction-files], que normalmente se concentram em como o próprio código deve ser estruturado. Isso ajuda o Copilot a entender não apenas *o que* você quer, mas também *como* o código deve ser organizado.
-
-Nesta lição, você irá:
-
-- explorar como o contexto específico do projeto, as diretrizes de programação e os padrões de documentação chegam ao Copilot por meio de instruções personalizadas do repositório e de arquivos de instrução com escopo por caminho,
-- gerar a primeira parte dos dados de filtragem (um helper de editoras) com as instruções *atuais* em vigor,
-- adicionar um novo padrão válido para todo o repositório em `.github/copilot-instructions.md`,
-- executar um prompt de acompanhamento e observar o código regenerado adotar o novo padrão,
-- fazer commit das atualizações de instruções e do helper para que a próxima lição possa se apoiar nelas.
-
-> [!CAUTION]
-> O código gerado pode divergir de alguns dos padrões que você definir. O Copilot é não determinístico. O objetivo é observar a *tendência* de mudança de comportamento após atualizar as instruções, e não reproduzir a saída caractere por caractere.
-
-## Arquivos de instruções
-
-### Cenário
-
-Como toda boa equipe de desenvolvimento, a Tailspin Toys tem um conjunto de diretrizes e requisitos para as práticas de desenvolvimento. Entre eles:
-
-- A camada de dados sempre precisa de testes unitários.
-- A interface do usuário deve usar modo escuro e ter um visual moderno.
-- A documentação deve ser adicionada ao código na forma de comentários TSDoc.
-- Um bloco de comentários deve ser adicionado ao início de cada arquivo para descrever o que ele faz.
-
-Com o uso de arquivos de instruções, você garantirá que o Copilot tenha as informações corretas para executar as tarefas de acordo com as práticas destacadas.
-
-### Instruções personalizadas
-
-As instruções personalizadas permitem fornecer contexto e preferências ao Copilot, para que ele entenda melhor seu estilo de programação e seus requisitos. Esse é um recurso poderoso para orientar o Copilot a gerar sugestões e trechos de código mais relevantes. Você pode especificar suas convenções de programação preferidas, bibliotecas e até os tipos de comentários que gosta de incluir no código. É possível criar instruções para todo o repositório ou para tipos específicos de arquivo, oferecendo contexto no nível da tarefa.
-
-Há dois tipos de arquivos de instruções:
-
-- `.github/copilot-instructions.md`, um único arquivo de instruções enviado ao Copilot em **toda** solicitação do repositório. Esse arquivo deve conter informações no nível do projeto — contexto relevante para a maioria das solicitações enviadas ao Copilot por chat ou pela CLI. Isso pode incluir a stack usada, uma visão geral do que está sendo criado, boas práticas e outras orientações globais.
-- Arquivos `.github/instructions/*.instructions.md` podem ser criados para tarefas ou tipos de arquivo específicos. Você pode usá-los para fornecer orientações para determinadas linguagens, como TypeScript ou Astro, ou para tarefas como criar um componente de UI ou um novo conjunto de testes unitários.
-
-> [!NOTE]
-> Ao trabalhar no IDE, os arquivos de instruções são usados apenas para geração de código no Copilot Chat — não para autocompletar nem para sugestões da próxima edição.
->
-> O Copilot Chat, o Copilot CLI e o agente de nuvem do Copilot usam tanto os arquivos no nível do repositório quanto os arquivos `*.instructions.md` (com frontmatter `applyTo`) ao gerar código.
->
-> Por fim, o Copilot [também oferece suporte a arquivos de instruções que seguem outros padrões][custom-instructions-support], incluindo arquivos `AGENTS.md` e `CLAUDE.md`.
-
-### Boas práticas para gerenciar arquivos de instruções
-
-Uma discussão completa sobre como criar arquivos de instruções está além do escopo deste workshop. Ainda assim, os exemplos fornecidos no projeto de exemplo mostram uma abordagem representativa. Em alto nível:
-
-- Mantenha as instruções em `copilot-instructions.md` focadas em orientações no nível do projeto, como uma descrição do que está sendo criado, a estrutura do projeto e padrões globais de programação.
-- Use arquivos `*.instructions.md` para fornecer instruções específicas para tipos de arquivo (testes unitários, componentes Astro, a camada de dados) ou para tarefas específicas.
-- Use linguagem natural. Mantenha as orientações claras. Forneça exemplos de como o código deve — e não deve — ser escrito.
-
-Não existe uma forma única de criar arquivos de instruções, assim como não existe uma forma única de usar IA. Com experimentação, você descobrirá o que funciona melhor para o seu projeto.
-
-> [!TIP]
-> Todo projeto que usa o GitHub Copilot deveria ter uma coleção robusta de arquivos de instruções. Ao explorar os arquivos deste projeto, você pode notar que há instruções para vários tipos de tarefas, incluindo [atualizações de UI][ui-instructions] e [Astro][astro-instructions].
->
-> O Copilot também pode ajudar a gerar arquivos de instruções para você. Cada superfície expõe isso de uma forma diferente, por exemplo **Configure Chat → Generate Agent Instructions** no VS Code ou `/init` no Copilot CLI — a lição do ambiente em que você está destacará isso quando for relevante.
->
-> Procura modelos ou um ponto de partida? Explore o [awesome-copilot][awesome-copilot], um repositório repleto de arquivos de instruções, agentes personalizados e outros recursos.
-
-[ui-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/ui.instructions.md
-[astro-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/astro.instructions.md
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[custom-instructions-support]: https://docs.github.com/copilot/reference/custom-instructions-support
-
-## Explorar os arquivos de instruções personalizadas deste projeto
-
-Reserve um momento para ler os arquivos de instruções incluídos neste repositório — há um `copilot-instructions.md` principal e uma coleção de arquivos `*.instructions.md` para várias tarefas. Abra-os no editor ou na interface web do GitHub.
-
-1. Abra `.github/copilot-instructions.md`.
-2. Explore o arquivo e observe a breve descrição do projeto, além de seções como **Agent notes**, **Code standards**, **Scripts** e **Repository Structure**. Em **Code standards**, observe a orientação aninhada de **GitHub Actions Workflows**. Tudo isso se aplica a qualquer interação sua com o Copilot.
-3. Abra a pasta `.github/instructions` e explore seu conteúdo. Observe que há instruções para arquivos Astro, para a camada de dados com Drizzle, para testes e muito mais.
-4. Abra `.github/instructions/unit-tests.instructions.md`. Observe o campo `applyTo` no topo — ele define um glob (relativo à raiz do repositório) que determina a quais arquivos as instruções se aplicam. Aqui, qualquer arquivo de teste TypeScript, por exemplo um que corresponda a `**/*.test.ts`, será incluído.
-5. Observe as instruções específicas para criar testes unitários neste projeto.
-6. Por fim, abra `.github/instructions/drizzle.instructions.md` e role até o final. Observe os links para outros arquivos de instruções, como `unit-tests.instructions.md`, e para arquivos existentes no projeto. Isso permite dividir conjuntos maiores de instruções em arquivos menores e reutilizáveis, além de apontar o Copilot para exemplos a serem seguidos na geração de código. (Nesse caso, os caminhos são relativos ao arquivo de instruções, e não à raiz do repositório.)
-
-> [!NOTE]
-> A seção **Code formatting requirements** em `copilot-instructions.md` documenta os padrões de programação do projeto, mas ainda não exige documentação no código. Nas próximas etapas, você adicionará regras para comentários TSDoc e cabeçalhos de comentário no nível do arquivo.
-
-## Criar uma branch
-
-Você fará alterações no código, então crie uma branch para trabalhar.
-
-1. No terminal do codespace, crie e troque para uma nova branch:
-
- ```bash
- git checkout -b update-custom-instructions
- ```
-
-2. Confirme que o Copilot CLI está instalado e autenticado:
-
- ```bash
- copilot --version
- ```
-
- Se o comando não for encontrado ou se você ainda não tiver feito login, volte para a [Lição 1 - Instalar o GitHub Copilot CLI](../1-install-copilot-cli/).
-
-## Usar o Copilot CLI *antes* de atualizar as instruções
-
-Para ver o impacto das instruções personalizadas, comece gerando código com as instruções atuais em vigor. Mais tarde, você atualizará o arquivo e executará um prompt de acompanhamento.
-
-> [!TIP]
-> **Inicie uma sessão do Copilot CLI**
->
-> Antes de iniciar os exercícios abaixo, volte ao codespace e abra um terminal (Ctrl+`, se ainda não houver um aberto). Em seguida, inicie o Copilot CLI com `--yolo` e `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar a sessão mais recente deste projeto em vez de iniciar uma nova, execute `copilot --yolo --enable-all-github-mcp-tools --continue`. Se o Copilot CLI já estiver em execução por causa de uma lição anterior, envie `/clear` para começar uma conversa limpa.
->
-> `--enable-all-github-mcp-tools` habilita as ferramentas GitHub MCP de leitura e escrita para a sessão atual, para que o Copilot possa ler seu backlog e abrir pull requests durante o fluxo do workshop.
-
-> [!CAUTION]
-> `--yolo` habilita permissões automáticas completas (`--allow-all-tools`, `--allow-all-paths` e `--allow-all-urls`). Use-o apenas em um ambiente isolado, como um Codespace ou uma VM, e nunca o defina como alias padrão no seu desenvolvimento diário. Consulte [Allowing and denying tool use][allow-all-warning] para saber mais.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. Verifique se a sessão do Copilot CLI está em execução a partir da **raiz do repositório**, para que ela carregue `.github/copilot-instructions.md` automaticamente.
-2. No prompt do Copilot CLI, peça que ele gere o helper de editoras que a UI de filtragem usará:
-
- ```plaintext
- Create a new data-access helper at src/lib/publishers.ts to return a list of all publishers. It should return the name and id for all publishers. Do not run the tests yet.
- ```
-
-3. O Copilot CLI explorará o projeto, proporá um plano e escreverá o arquivo nesta sessão com `--yolo`. Acompanhe as alterações na saída do terminal e depois revise o resultado no editor.
-4. Abra no editor o arquivo gerado `src/lib/publishers.ts`.
-5. Observe que o helper é uma função tipada que recebe um cliente `db` como primeiro argumento e retorna um array tipado de editoras — isso vem das convenções da camada de dados em `.github/instructions/drizzle.instructions.md` (que se aplica a `src/lib/*.ts`).
-6. Observe que no código gerado **faltam** comentários TSDoc e um cabeçalho de comentário no nível do arquivo.
-
-> [!CAUTION]
-> O Copilot é probabilístico — há uma chance de ele adicionar comentários de documentação mesmo sem receber essa instrução. Se isso acontecer, tudo bem. O principal aprendizado continua sendo a melhora de *consistência* depois da atualização das instruções.
-
-## Adicionar um novo padrão ao repositório
-
-Como destacado anteriormente, `.github/copilot-instructions.md` foi criado para fornecer informações no nível do projeto ao Copilot. Vamos garantir que os padrões de programação do repositório estejam documentados para melhorar as sugestões de código.
-
-1. Abra novamente `.github/copilot-instructions.md`.
-2. Localize a seção **Code formatting requirements**, que deve estar perto da linha 27. Observe como ela documenta os padrões de programação do projeto, mas ainda não traz nenhuma regra para documentação no código, e é por isso que o helper gerado não tinha comentários de documentação.
-3. Adicione as linhas de markdown a seguir logo abaixo dos padrões existentes para instruir o Copilot a incluir cabeçalhos de comentário no arquivo e comentários TSDoc:
-
- ```markdown
- - Every exported function should have a TSDoc comment describing its purpose, parameters, and return value.
- - Before imports or any code, add a comment block to the file that explains its purpose.
- ```
-
-4. Salve `copilot-instructions.md`.
-
-> [!TIP]
-> Como você viu na lição anterior, arquivos de instruções podem ser criados no nível do repositório (`.github/copilot-instructions.md`) para orientações globais, ou como arquivos `*.instructions.md` para linguagens, tipos de arquivo ou tarefas específicas. O arquivo do repositório é o local certo para padrões válidos em todo o projeto, como a regra de comentários de documentação que você acabou de adicionar.
-
-## Executar o prompt novamente e observar a mudança
-
-Agora que as instruções incluem uma regra para comentários de documentação, peça ao Copilot CLI para atualizar o arquivo de editoras que você acabou de gerar. A mesma diretriz de padrões orientará a reescrita.
-
-1. Envie `/clear` na sessão do Copilot CLI para começar com uma conversa limpa.
-2. Envie o prompt a seguir:
-
- ```plaintext
- Update src/lib/publishers.ts to follow the latest documentation conventions in .github/copilot-instructions.md.
- ```
-
-3. Aguarde a edição terminar e depois abra novamente `src/lib/publishers.ts`.
-4. Observe que o arquivo agora começa com um bloco de comentários parecido com este:
-
- ```typescript
- /**
- * Helpers de acesso a dados de editoras para a plataforma de financiamento coletivo Tailspin Toys.
- * Fornece funções para recuperar informações de editoras do banco de dados.
- */
- ```
-
-5. Observe que a função gerada agora inclui um comentário TSDoc parecido com este:
-
- ```typescript
- /**
- * Retorna uma lista de todas as editoras com id e nome.
- *
- * @param db - O cliente de banco de dados Drizzle.
- * @returns Uma promessa que resolve para um array de objetos de editora.
- */
- ```
-
-6. Mantenha esse arquivo atualizado como está. Essa é a primeira parte dos dados em que você se apoiará na próxima lição.
-
-## Fazer commit e push desta primeira parte da filtragem
-
-1. No terminal, verifique os arquivos alterados:
-
- ```bash
- git status
- ```
-
-2. Adicione a atualização das instruções e o helper à área de stage:
-
- ```bash
- git add .github/copilot-instructions.md src/lib/publishers.ts
- ```
-
-3. Faça commit das alterações:
-
- ```bash
- git commit -m "Add doc comment standards and publishers helper foundation"
- ```
-
-4. Envie a branch:
-
- ```bash
- git push -u origin update-custom-instructions
- ```
-
-## Resumo e próximos passos
-
-Você explorou como o Copilot recebe contexto dos arquivos de instruções deste projeto e depois usou o Copilot CLI para:
-
-- gerar a base de um helper de acesso a dados de editoras para a filtragem com as instruções *existentes*,
-- adicionar um novo padrão válido para todo o repositório em `.github/copilot-instructions.md`,
-- executar um prompt de acompanhamento e observar o código regenerado adotar o novo padrão,
-- fazer commit e push tanto da atualização das instruções quanto da base do helper.
-
-Em seguida, você aplicará essas instruções ao implementar trabalho do backlog na [lição de geração de código][next-lesson].
-
-## Recursos
-
-- [Arquivos de instruções para personalização do GitHub Copilot][instruction-files]
-- [Boas práticas para criar instruções personalizadas][instructions-best-practices]
-- [5 dicas para escrever instruções personalizadas melhores para o Copilot][copilot-instructions-five-tips]
-- [Awesome Copilot — uma coleção de arquivos de instruções e outros recursos][awesome-copilot]
-
-[previous-lesson]: ../1-install-copilot-cli/
-[next-lesson]: ../3-generating-code/
-[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
-[instructions-best-practices]: https://docs.github.com/enterprise-cloud@latest/copilot/using-github-copilot/coding-agent/best-practices-for-using-copilot-to-work-on-tasks#adding-custom-instructions-to-your-repository
-[copilot-instructions-five-tips]: https://github.blog/ai-and-ml/github-copilot/5-tips-for-writing-better-custom-instructions-for-copilot/
diff --git a/docs/pt-br/cli/3-custom-instructions.md b/docs/pt-br/cli/3-custom-instructions.md
new file mode 100644
index 00000000..f80b6f84
--- /dev/null
+++ b/docs/pt-br/cli/3-custom-instructions.md
@@ -0,0 +1,109 @@
+---
+title: "Lição 3 - Orientar o Copilot com instruções personalizadas"
+description: "Adicione uma convenção de documentação específica, demonstre-a em código existente e integre o segundo pull request."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+O contexto ajuda o Copilot a entender não apenas *o que* criar, mas *como* sua equipe espera que o código seja escrito. Você adicionará uma convenção de documentação específica, observará seu efeito em código real e integrará as instruções e a demonstração juntas como PR 2.
+
+Nesta lição, você vai:
+
+- explorar instruções gerais do repositório e com escopo de caminho.
+- adicionar um padrão de documentação sem implementar a filtragem antes da hora.
+- demonstrar o padrão em uma pequena função auxiliar ou componente existente.
+- validar e integrar o marco de instruções.
+
+## Explorar as instruções
+
+O repositório já contém dois tipos úteis de instruções:
+
+- `.github/copilot-instructions.md` fornece contexto geral do repositório, como tecnologias, estrutura e práticas comuns.
+- `.github/instructions/*.instructions.md` fornece orientações de escopo limitado. Um glob `applyTo` no frontmatter identifica os arquivos aos quais as instruções se aplicam.
+
+Abra estes arquivos no editor:
+
+1. Leia `.github/copilot-instructions.md` e localize os padrões atuais de código e verificação.
+2. Explore `.github/instructions/`, incluindo as orientações de Astro, camada de dados e testes.
+3. Em `unit-tests.instructions.md`, examine o padrão `applyTo` e as convenções de teste.
+4. Em `drizzle.instructions.md`, examine os padrões de acesso a dados e as referências a exemplos.
+
+Mantenha as instruções gerais concisas, coloque detalhes específicos de arquivos no arquivo de escopo relevante e evite cópias conflitantes da mesma regra. A [referência de suporte a instruções do GitHub][instruction-support] explica quais formatos cada ambiente suporta.
+
+> [!NOTE]
+> As instruções influenciam a geração; elas não garantem conformidade. Sua revisão verificará tanto o texto das instruções quanto seu efeito no código. Se o Copilot já produzir bons comentários, o objetivo da lição é tornar a convenção explícita e repetível, não forçar uma falha para comparar antes e depois.
+
+## Partir do PR 1 integrado
+
+Confirme que o PR de avaliações por estrelas foi integrado. No terminal do repositório do participante, inicie o próximo marco a partir de `main` atualizado:
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c update-custom-instructions
+copilot --enable-all-github-mcp-tools
+```
+
+Se a árvore de trabalho não estiver limpa ou a atualização falhar, resolva esse estado antes de continuar. Permaneça no modo **Interactive**.
+
+Na aba **Issues** do repositório, encontre **Update our repository coding standards** e copie sua URL real. A issue fornece o contexto mais amplo: explicar a intenção, documentar funções exportadas da camada de dados e contratos de componentes e manter os comentários atualizados. Esta lição aborda uma parte limitada da documentação, não uma refatoração de todo o repositório ou a promessa de concluir todos os critérios da issue.
+
+## Adicionar a convenção de documentação
+
+Substitua o marcador pela URL real da issue e envie:
+
+```plaintext
+Leia esta issue de padrões de código como contexto: . Examine as instruções existentes do repositório e de escopo limitado. Adicione uma convenção de documentação específica: explique a intenção em vez de repetir o código, documente funções exportadas em db/ e src/lib/ com TSDoc/JSDoc cobrindo propósito, parâmetros e valores de retorno, documente os contratos de Props dos componentes reutilizáveis de Astro e mantenha os comentários atualizados quando o código relacionado mudar.
+
+Coloque cada regra no arquivo de instruções existente adequado e evite duplicações ou contradições. Preserve os padrões existentes de formatação e lint; inclua um link ou resumo da convenção de documentação em README quando apropriado. Limite esta alteração ao padrão de documentação, não a uma migração de ferramentas de formatação ou reescrita de todo o repositório. Não crie uma skill ou agente, não implemente a filtragem, não faça commit, push nem abra um PR. Pare para que eu possa examinar as instruções antes da demonstração.
+```
+
+Examine o diff. A convenção deve incentivar comentários úteis, não exigir um cabeçalho genérico em todos os arquivos ou comentários que apenas repitam código óbvio. Peça correções antes de prosseguir.
+
+## Demonstrar a convenção em código real
+
+Escolha uma pequena função auxiliar exportada ou um componente reutilizável existente após examinar o repositório. Não precisa ser uma função auxiliar de distribuidoras, e não há exigência de que `src/lib/publishers.ts` já exista.
+
+Envie:
+
+```plaintext
+Usando as instruções atualizadas, selecione uma pequena função auxiliar exportada ou componente reutilizável de Astro existente que se beneficiaria de uma documentação mais clara. Aplique a convenção diretamente a esse arquivo sem mudar o comportamento em execução ou adicionar filtragem. Explique qual instrução orientou a alteração e pare antes de fazer commit ou abrir um PR.
+```
+
+Abra o arquivo real alterado. Para uma função auxiliar, verifique se os comentários descrevem corretamente os parâmetros, o valor de retorno e qualquer argumento de banco de dados injetado. Para um componente, verifique se seu contrato de `Props` está documentado. Confirme que a explicação corresponde ao código, em vez de apenas procurar um bloco de comentários.
+
+> [!TIP]
+> Um trecho ilustrativo no chat não é a demonstração: examine uma alteração real do repositório. Se o código selecionado já atender à convenção, escolha outro alvo pequeno existente em que uma melhoria seja justificada, em vez de adicionar comentários redundantes.
+
+## Validar e integrar o PR 2
+
+Peça ao Copilot que valide as alterações revisadas:
+
+```plaintext
+Revise as alterações de instruções e a pequena demonstração de documentação. Confirme que o comportamento em execução não mudou. Examine package.json, execute npm run lint e npm run typecheck:all e execute os testes existentes afetados quando a alteração de código justificar. Relate os comandos exatos e os resultados. Não instale nada, não crie uma skill, não faça commit, push nem abra um PR ainda.
+```
+
+Resolva falhas e examine o diff final. Depois, autorize o marco:
+
+```plaintext
+Faça commit apenas das instruções de documentação revisadas, da atualização diretamente relacionada de README e da pequena demonstração de código. Envie a branch atual e crie um PR para main seguindo o modelo de PR do repositório. Inclua os resultados de verificação e referencie a issue de padrões de código como contribuição parcial; não use uma palavra-chave de fechamento, a menos que todos os critérios da issue estejam realmente satisfeitos. Não faça o merge nem comece a filtragem.
+```
+
+Abra a URL do PR, examine **Files changed** e revise a CI. Depois que todas as verificações e revisões obrigatórias passarem, faça o merge no GitHub e confirme que o PR 2 está **Merged**. Saia da sessão da CLI com `/exit`. Não inicie o próximo marco até este PR ser integrado.
+
+## Resumo e próximos passos
+
+A convenção de documentação e uma demonstração real agora estão em `main`. Em seguida, você [criará a filtragem com Plan e Autopilot][next-lesson] em uma branch nova baseada nesse estado integrado.
+
+## Recursos
+
+- [Adicionar instruções personalizadas ao repositório][repository-instructions] explica orientações gerais e com escopo de caminho.
+- [Awesome Copilot][awesome-copilot] oferece exemplos para revisar e adaptar, não adotar cegamente.
+
+[previous-lesson]: ../2-add-star-rating/
+[next-lesson]: ../4-build-filtering/
+[instruction-support]: https://docs.github.com/copilot/reference/custom-instructions-support
+[repository-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
+[awesome-copilot]: https://github.com/github/awesome-copilot
diff --git a/docs/pt-br/cli/3-generating-code.md b/docs/pt-br/cli/3-generating-code.md
deleted file mode 100644
index a2427acd..00000000
--- a/docs/pt-br/cli/3-generating-code.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: "Lição 3 - Adicionar recursos ao projeto com o GitHub Copilot CLI"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-Como você pode imaginar, uma das principais tarefas realizadas com o GitHub Copilot CLI é adicionar recursos, funcionalidades e código a um projeto. Vamos pegar uma das issues do seu backlog e pedir ao Copilot que ajude a implementá-la.
-
-## Cenário
-
-Chegou a hora de concluir a filtragem no projeto. Você já tem a issue de filtragem no backlog e um helper de base da lição anterior. Vamos fazer o Copilot recuperar os detalhes da issue, considerar o trabalho existente e criar a funcionalidade restante.
-
-Nesta lição, você irá:
-
-- usar o modo plan para gerar um plano de implementação da funcionalidade de filtragem.
-- gerar o código necessário para adicionar a filtragem ao site com o Copilot.
-
-Ao final desta lição, você terá adicionado uma nova funcionalidade ao projeto.
-
-## Usar o modo plan
-
-Um dos melhores usos da IA é o planejamento. Muitas vezes, você tem uma boa ideia do que quer criar, mas só precisa trocar algumas ideias. Ferramentas de IA podem ajudar a organizar melhor o raciocínio ao fazer perguntas de acompanhamento e analisar diferentes armadilhas ou componentes ausentes. Para apoiar esse processo, o Copilot CLI oferece um modo plan. Além disso, o tempo dedicado ao planejamento ajudará o Copilot a gerar um código que corresponda melhor aos requisitos definidos.
-
-Você iniciará o processo de criação da nova funcionalidade usando o modo plan no Copilot CLI.
-
-> [!TIP]
-> **Inicie uma sessão do Copilot CLI**
->
-> Antes de iniciar os exercícios abaixo, volte ao codespace e abra um terminal (Ctrl+`, se ainda não houver um aberto). Em seguida, inicie o Copilot CLI com `--yolo` e `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar a sessão mais recente deste projeto em vez de iniciar uma nova, execute `copilot --yolo --enable-all-github-mcp-tools --continue`. Se o Copilot CLI já estiver em execução por causa de uma lição anterior, envie `/clear` para começar uma conversa limpa.
->
-> `--enable-all-github-mcp-tools` habilita as ferramentas GitHub MCP de leitura e escrita para a sessão atual, para que o Copilot possa ler seu backlog e abrir pull requests durante o fluxo do workshop.
-
-> [!CAUTION]
-> `--yolo` habilita permissões automáticas completas (`--allow-all-tools`, `--allow-all-paths` e `--allow-all-urls`). Use-o apenas em um ambiente isolado, como um Codespace ou uma VM, e nunca o defina como alias padrão no seu desenvolvimento diário. Consulte [Allowing and denying tool use][allow-all-warning] para saber mais.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. Digite o prompt a seguir no Copilot CLI para criar um plano com base na issue de filtragem:
-
- ```
- /plan Retrieve the issue on the repository related to adding filtering. We already added a publishers helper in src/lib/publishers.ts, so treat that as existing work and plan the remaining updates (games filtering logic, UI, and tests).
- ```
-
-2. O Copilot pode fazer perguntas de acompanhamento enquanto monta o plano. Quando isso acontecer, responda com base em como você implementaria a funcionalidade.
-3. Quando o plano for gerado, revise o esboço. Você deverá notar que ele recomenda as mudanças restantes na camada de dados e na interface, além da geração de testes.
-4. O Copilot CLI oferecerá a opção de fornecer feedback adicional sobre o plano. Você pode mover o cursor para baixo até a seção indicada e então digitar suas sugestões. O Copilot incorporará suas observações em uma nova versão do plano.
-5. Quando estiver satisfeito, selecione a opção oferecida pelo Copilot para começar a criar o novo recurso.
-
-> [!NOTE]
-> Como o Copilot é probabilístico, o texto exato e as opções apresentadas variam. Ainda assim, você verá uma opção para iniciar a implementação semelhante a:
->
-> `Yes, and switch to autopilot mode`.
->
-> O Copilot pode oferecer a opção de habilitar o [autopilot mode](https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot), como mostrado no exemplo acima. O modo autopilot permite que o Copilot CLI avance em uma tarefa sem esperar sua entrada após cada etapa. Depois que você fornece a instrução inicial, o Copilot CLI trabalha de forma autônoma em cada etapa até considerar a tarefa concluída. Como estamos em um ambiente isolado, não há problema em usar o autopilot e permitir todas as ferramentas.
-
-6. O Copilot começará a gerar os arquivos.
-
-> [!NOTE]
-> Essa operação provavelmente levará vários minutos. Você verá o Copilot editar e criar arquivos, atualizar e gerar testes e executar todos os testes para garantir que tudo funcione. Este é um bom momento para refletir sobre o que você explorou até aqui ou aproveitar uma bebida.
-
-## Revisar o código
-
-Todo código gerado por IA deve ser revisado antes de ser enviado para produção. Vamos aproveitar este momento para explorar os arquivos que o Copilot criou e modificou ao implementar o novo recurso.
-
-1. Use o Copilot CLI para exibir o diff ou as alterações de código usando o comando a seguir no Copilot CLI:
-
- ```
- /diff
- ```
-
-2. Observe quais arquivos foram alterados. Use as setas do teclado para alternar entre eles. Você deverá ver atualizações em arquivos como a página de listagem de jogos, onde ficam os novos controles de filtro e a filtragem no cliente, além de `src/lib/games.ts` e testes como `games.test.ts`. Também pode haver atualizações em `publishers.ts` se o Copilot refinar o helper existente para alinhá-lo à implementação completa.
-
-## Resumo e próximos passos
-
-Agora você adicionou a funcionalidade de filtragem ao site com a ajuda do Copilot CLI. Em especial, você:
-
-- usou o modo plan para gerar um plano de implementação da funcionalidade de filtragem.
-- gerou o código necessário para adicionar a filtragem ao site com o Copilot.
-
-Claro, o próximo passo é garantir que tudo funcione. Vamos [testar o recurso com o servidor MCP do Playwright][next-lesson] antes de abrir um pull request.
-
-## Recursos
-
-- [Usar o Copilot CLI][using-copilot-cli]
-- [Sobre o Copilot CLI][about-copilot-cli]
-- [Gerenciamento de contexto no Copilot CLI][context-management]
-
-[previous-lesson]: ../2-custom-instructions/
-[next-lesson]: ../4-mcp/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
diff --git a/docs/pt-br/cli/4-build-filtering.md b/docs/pt-br/cli/4-build-filtering.md
new file mode 100644
index 00000000..7ad04c3a
--- /dev/null
+++ b/docs/pt-br/cli/4-build-filtering.md
@@ -0,0 +1,102 @@
+---
+title: "Lição 4 - Criar a filtragem com Plan e Autopilot"
+description: "Acorde os requisitos de filtragem, aprove um plano de implementação, valide o código e salve um checkpoint na branch do recurso."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Agora crie o recurso maior: permitir que os usuários filtrem jogos por categoria e distribuidora. Você planejará antes de programar, autorizará explicitamente o **Autopilot**, revisará e testará a implementação e salvará um checkpoint. Esta lição não cria a skill, o agente de QA ou o PR do recurso.
+
+## Iniciar o marco de filtragem
+
+Confirme que os PRs 1 e 2 estão integrados. No terminal do repositório do participante:
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-game-filtering
+copilot --enable-all-github-mcp-tools
+```
+
+Continue apenas com uma árvore de trabalho limpa e uma atualização bem-sucedida a partir de `main`. As Lições 4–8 usam esta mesma branch e cópia de trabalho. Os próximos commits de checkpoint adicionarão a skill e o perfil de QA; não crie uma branch por lição.
+
+## Recuperar a issue real
+
+Encontre **Allow users to filter games by category and publisher** na aba **Issues** do repositório e copie a URL. Não presuma que o nome de arquivo do modelo ou um número de issue identifica a issue na sua cópia.
+
+A issue atual exige:
+
+- selecionar uma ou mais categorias.
+- filtrar por distribuidora e combinar com as categorias.
+- funções auxiliares de acesso a dados em `src/lib/` que suportem ambos os filtros.
+- controles acessíveis com navegação por teclado, ARIA apropriado, estados de foco visíveis e atributos `data-testid`.
+- cobertura unitária com Vitest para as funções auxiliares e cobertura E2E com Playwright para o comportamento de filtragem.
+
+Leia a issue atual como fonte de verdade. Mantenha sua URL e todos os esclarecimentos aprovados disponíveis para o prompt de QA da Lição 7.
+
+## Planejar antes de programar
+
+Use Shift+Tab para selecionar o modo **Plan**, ou comece com `/plan`. Substitua o marcador da issue e envie:
+
+```plaintext
+Planeje o recurso de filtragem descrito nesta issue: . Leia a issue, as instruções do repositório, as funções auxiliares de acesso a dados existentes, a interface e os testes antes de propor alterações. Trate a cópia de trabalho atual como ponto de partida; não presuma que uma função auxiliar de distribuidoras já foi criada.
+
+Cubra seleção de múltiplas categorias, filtragem por distribuidora, sua combinação, suporte de acesso a dados, controles acessíveis e cobertura unitária/E2E. Peça que eu esclareça comportamentos não especificados, como a combinação de múltiplas categorias, a limpeza de filtros e resultados vazios; registre as decisões com o plano aprovado. Preserve a arquitetura estática do Astro em vez de introduzir uma API de servidor desnecessária.
+
+Planeje a implementação na branch atual, incluindo os testes de unidade e E2E necessários e a verificação com npm run lint, npm run test:unit, npm run test:e2e e npm run typecheck:all. Examine primeiro os pré-requisitos e a quem pertence o servidor; relate bloqueios em vez de instalar software ou parar processos não relacionados.
+
+Inclua estes limites de execução no plano: depois que eu aprovar, implemente apenas o recurso de filtragem e os testes necessários, execute as verificações e pare para que eu possa revisar. Não crie a skill quality-checks, um agente de QA ou outros ativos de lições posteriores. Não mude de branch, não faça commit, push nem abra ou integre um PR.
+
+Não edite código da aplicação nem comece a implementação até eu aprovar o plano.
+```
+
+Responda às perguntas de acompanhamento. Não adicione critérios de aceitação ocultos depois: salve as respostas acordadas com a URL da issue para que implementação, verificações no navegador e QA usem os mesmos requisitos.
+
+Revise se o plano inclui alterações na camada de dados e na interface, testes, controles acessíveis e a convenção de documentação integrada. Confirme que inclui explicitamente as quatro verificações, a parada para revisão e as proibições de criar ativos posteriores do workshop, mudar de branch, fazer commits, pushes e operações de PR. Peça revisões antes da aprovação se faltar algum limite ou critério ou se o plano propuser trabalho fora da issue.
+
+## Aprovar explicitamente o Autopilot
+
+Somente depois que o plano incluir o escopo e os limites de execução revisados, use a opção de aprovação **Accept plan and build on autopilot**. Se a sua versão usar outro texto, selecione explicitamente a opção que muda para **Autopilot** e verifique o indicador de modo. A aprovação inicia a execução do plano delimitado; não dependa de um prompt posterior para adicionar limites depois que o trabalho começar.
+
+> [!CAUTION]
+> O Autopilot controla a continuidade do trabalho, não apenas as permissões de ferramentas. Revise a caixa de diálogo de permissões antes de escolher. Permissões completas permitem acesso a ferramentas, caminhos e URLs; permissões limitadas podem bloquear ações que exigem aprovação. Um codespace não dá permissão para expor segredos ou alterar recursos não relacionados. Resolva deliberadamente o acesso bloqueado em vez de tratar verificações ignoradas como aprovadas.
+
+Monitore o trabalho e os resultados dos comandos. O Autopilot pode pausar em um limite de continuação ou relatar um bloqueio antes de concluir o plano. Revise esse estado antes de autorizar a continuação, preservando o mesmo escopo.
+
+## Voltar a Interactive e revisar
+
+Quando a implementação parar, use Shift+Tab para voltar ao modo **Interactive** antes de enviar outros prompts. O Autopilot pode continuar ativo após uma tarefa; não presuma que voltou automaticamente.
+
+Digite `/diff` e examine todos os arquivos alterados. Compare a implementação com a issue e os esclarecimentos aprovados:
+
+- Os usuários conseguem selecionar múltiplas categorias, filtrar por distribuidora e combiná-las conforme acordado?
+- As funções auxiliares de acesso a dados realmente suportam os filtros, em vez de mudar apenas a interface?
+- Os controles têm rótulos significativos, suporte de teclado, foco visível e identificadores de teste estáveis?
+- Os testes verificam comportamento, incluindo os casos acordados de limpeza e resultados vazios, sem enfraquecer as asserções existentes?
+- O código segue a convenção de documentação e preserva a arquitetura estática da aplicação?
+
+Revise as evidências das quatro verificações npm. Você ainda não criou `quality-checks`, então essas verificações são executadas diretamente. A configuração E2E do Playwright compila e serve uma prévia; antes de executar a suíte, pare apenas um servidor de desenvolvimento que você iniciou para impedir a reutilização de conteúdo desatualizado. Um conflito de porta ou navegador ausente é um bloqueio a resolver, não motivo para encerrar outro processo ou afirmar que uma verificação passou.
+
+Peça correções específicas se necessário, execute novamente as verificações afetadas e garanta que a implementação final tenha verificação completa. A observação direta no navegador vem na Lição 6; ela tem uma finalidade diferente desta verificação automatizada.
+
+## Salvar o checkpoint de implementação
+
+Quando o diff e os resultados forem satisfatórios, autorize um checkpoint local:
+
+```plaintext
+Revise o diff atual e os resultados de verificação. Crie um commit de checkpoint contendo apenas a implementação de filtragem revisada e seus testes. Mantenha a branch e a cópia de trabalho de filtragem atuais. Não faça push, não abra um PR nem crie a skill ou o agente de QA ainda.
+```
+
+Registre a revisão testada e mantenha a URL da issue e os esclarecimentos aprovados. Permaneça em **Interactive** e continue nesta mesma cópia de trabalho com a [Lição 5 - Criar e usar uma skill quality-checks][next-lesson].
+
+## Recursos
+
+- [Modo Autopilot e permissões][autopilot] explica a continuação autônoma e a volta a Interactive.
+- [Referência de comandos do Copilot CLI][cli-reference] lista os controles de modo e comandos atuais.
+
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
+[autopilot]: https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/pt-br/cli/4-mcp.md b/docs/pt-br/cli/4-mcp.md
deleted file mode 100644
index a644eecc..00000000
--- a/docs/pt-br/cli/4-mcp.md
+++ /dev/null
@@ -1,160 +0,0 @@
----
-title: "Lição 4 - Testar seu recurso com o servidor MCP do Playwright"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-Você acabou de gerar o recurso de filtragem com o Copilot CLI. Antes de abrir um pull request, confirme que tudo funciona no navegador. Em vez de testar o aplicativo manualmente, você conectará o **servidor MCP do Playwright** e deixará o Copilot controlar um navegador real para testar o recurso.
-
-Nesta lição, você irá:
-
-- entender o que é o Model Context Protocol (MCP) e como os servidores MCP ampliam o Copilot CLI.
-- adicionar o servidor MCP do Playwright ao Copilot CLI.
-- pedir ao Copilot que o use para testar manualmente o recurso de filtragem em um navegador.
-
-## O que é o Model Context Protocol (MCP)?
-
-O [Model Context Protocol (MCP)](https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/) fornece aos agentes de IA uma maneira de se comunicar com ferramentas e serviços externos. Ao usar o MCP, agentes de IA podem se comunicar com ferramentas e serviços externos em tempo real. Isso permite acessar informações atualizadas, por meio de recursos, e executar ações em seu nome, por meio de ferramentas.
-
-Essas ferramentas e esses recursos são acessados por um servidor MCP, que atua como ponte entre o agente de IA e as ferramentas e serviços externos. O servidor MCP é responsável por gerenciar a comunicação entre o agente de IA e as ferramentas externas, como APIs existentes ou ferramentas locais, como pacotes NPM. Cada servidor MCP representa um conjunto diferente de ferramentas e recursos que o agente de IA pode acessar.
-
-Alguns servidores MCP populares são:
-
-- **[GitHub MCP Server](https://github.com/github/github-mcp-server)**: este servidor fornece acesso a um conjunto de APIs para gerenciar seus repositórios do GitHub. Ele permite que o agente de IA execute ações como criar novos repositórios, atualizar os existentes e gerenciar issues e pull requests.
-- **[Playwright MCP Server](https://github.com/microsoft/playwright-mcp)**: este servidor fornece automação de navegador com Playwright. Ele permite que o agente de IA execute ações como navegar por páginas web, preencher formulários e selecionar botões.
-
-Há muitos outros servidores MCP disponíveis que fornecem acesso a diferentes ferramentas e recursos. O GitHub mantém um [registro MCP](https://github.com/mcp) para facilitar a descoberta e a contribuição para o ecossistema.
-
-> [!CAUTION]
-> Em termos de segurança, trate servidores MCP como qualquer outra dependência do projeto. Antes de usar um servidor MCP, revise o código-fonte com cuidado, verifique quem o publicou e considere as implicações de segurança. Use apenas servidores MCP em que você confie e tenha cautela ao conceder acesso a recursos ou operações sensíveis.
-
-> [!NOTE]
-> O [GitHub MCP server][github-mcp-server] já vem **integrado** ao Copilot CLI — ele já está disponível sem configuração, e é assim que o Copilot vem lendo e escrevendo no seu repositório ao longo do workshop. Nesta lição, você adicionará um *segundo* servidor, o Playwright, para dar ao Copilot acesso a um navegador.
-
-## Adicionar o servidor MCP do Playwright
-
-A forma mais rápida de adicionar um servidor é com o comando interativo `/mcp add`. Você registrará o [Playwright MCP server][playwright-mcp-server], que dá ao Copilot um navegador que ele pode controlar.
-
-> [!TIP]
-> **Inicie uma sessão do Copilot CLI**
->
-> Antes de iniciar os exercícios abaixo, volte ao codespace e abra um terminal (Ctrl+`, se ainda não houver um aberto). Em seguida, inicie o Copilot CLI com `--yolo` e `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar a sessão mais recente deste projeto em vez de iniciar uma nova, execute `copilot --yolo --enable-all-github-mcp-tools --continue`. Se o Copilot CLI já estiver em execução por causa de uma lição anterior, envie `/clear` para começar uma conversa limpa.
->
-> `--enable-all-github-mcp-tools` habilita as ferramentas GitHub MCP de leitura e escrita para a sessão atual, para que o Copilot possa ler seu backlog e abrir pull requests durante o fluxo do workshop.
-
-> [!CAUTION]
-> `--yolo` habilita permissões automáticas completas (`--allow-all-tools`, `--allow-all-paths` e `--allow-all-urls`). Use-o apenas em um ambiente isolado, como um Codespace ou uma VM, e nunca o defina como alias padrão no seu desenvolvimento diário. Consulte [Allowing and denying tool use][allow-all-warning] para saber mais.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. Na sua sessão do Copilot CLI, digite:
-
- ```text
- /mcp add
- ```
-
-2. Um formulário de configuração será exibido. Use Tab para mover entre os campos e preencha-o assim:
-
- - **Server Name**: `playwright`
- - **Server Type**: selecione **Local** (também rotulado como **STDIO**)
- - **Command**: `npx @playwright/mcp@latest --headless`
- - **Tools**: deixe `*` para permitir todas as ferramentas do servidor
-
-3. Pressione Ctrl+S para salvar. O servidor será adicionado e ficará disponível imediatamente — não é necessário reiniciar.
-
-A flag `--headless` instrui o Playwright a executar o navegador sem janela visível, o que é necessário em um codespace, onde não existe uma área de trabalho para exibição. Nos bastidores, isso grava o servidor no arquivo `~/.copilot/mcp-config.json`:
-
-```json
-{
- "mcpServers": {
- "playwright": {
- "type": "local",
- "command": "npx",
- "args": ["@playwright/mcp@latest", "--headless"],
- "tools": ["*"]
- }
- }
-}
-```
-
-4. Confirme que o servidor está registrado e ativo listando seus servidores MCP:
-
- ```text
- /mcp show
- ```
-
-5. Você deverá ver `playwright` listado ao lado do servidor interno `github`.
-
-> [!NOTE]
-> O projeto Tailspin Toys já usa o Playwright para testes de ponta a ponta, então o navegador de que o Playwright precisa normalmente já está instalado. Se mais tarde o Copilot informar que falta um navegador, peça que ele execute `npx playwright install chromium` e tente novamente.
-
-## Iniciar o site
-
-O servidor MCP do Playwright precisa de um aplicativo em execução para testar. Inicie o servidor de desenvolvimento do Astro em um **terminal separado** para que ele continue em execução enquanto você trabalha no Copilot CLI.
-
-1. Abra um novo terminal no codespace pressionando Ctrl+`.
-2. Inicie o site:
-
- ```bash
- npm run dev
- ```
-
-3. Deixe esse terminal em execução. Quando você vir o banner `Astro server: http://localhost:4321`, o aplicativo estará pronto.
-
-## Testar o recurso de filtragem
-
-Volte à sessão do Copilot CLI e peça ao Copilot para testar o recurso.
-
-O [Playwright MCP server][playwright-mcp-server] dá ao Copilot um navegador real para controlar. Em vez de você verificar manualmente o aplicativo, o agente pode abrir uma página, navegar, aplicar filtros e informar o resultado — depois resumir o que viu. Essa é a maneira mais rápida de confirmar que um recurso se comporta como esperado sem sair da conversa.
-
-Internamente, o servidor MCP do Playwright trabalha a partir da [árvore de acessibilidade][playwright-mcp-server] da página, em vez de usar capturas de tela. Isso significa que o agente raciocina sobre elementos estruturados e rotulados, como botões, links e itens de lista, da mesma forma que tecnologias assistivas fazem. Assim, uma verificação funcional rápida também funciona como uma checagem básica de acessibilidade.
-
-Com o servidor conectado e o aplicativo em execução, peça ao Copilot para exercitar o recurso de filtragem que você acabou de criar:
-
-```text
-Using the Playwright MCP server, open a browser to the running app at http://localhost:4321 and verify the new game filtering feature:
-
-1. Go to the games page and note how many games are listed.
-2. Apply a category filter and confirm the list updates to only show games in that category.
-3. Clear it, then apply a publisher filter and confirm the list updates to that publisher.
-4. Combine a category and a publisher filter and confirm the results respect both.
-
-Report what you observe at each step, and call out anything that does not behave as expected.
-```
-
-O Copilot iniciará um navegador por meio do servidor MCP do Playwright, executará cada etapa e informará o que encontrou. Leia o resumo em comparação com os critérios de aceitação da issue. Se algo parecer incorreto, faça perguntas de acompanhamento ou peça que ele corrija o código antes de abrir um pull request.
-
-> [!NOTE]
-> O aplicativo precisa estar em execução em `http://localhost:4321` para este teste. Se você tiver parado o servidor de desenvolvimento, inicie-o novamente antes de enviar o prompt. Na primeira vez em que o Copilot usar o servidor MCP do Playwright, talvez seja necessário baixar um navegador. Se ele informar que falta um navegador, peça que execute `npx playwright install chromium` e tente novamente.
-
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
-
-## Resumo e próximos passos
-
-Parabéns, você usou o servidor MCP do Playwright para testar manualmente o recurso com o Copilot CLI. Para recapitular, você:
-
-- aprendeu o que é o Model Context Protocol (MCP) e como os servidores MCP ampliam o Copilot CLI.
-- adicionou o servidor MCP do Playwright com `/mcp add`.
-- pediu ao Copilot que controlasse um navegador e verificasse o recurso de filtragem antes da entrega.
-
-Agora que você confirmou que o recurso funciona, pode continuar para a próxima lição, na qual [abrirá um pull request com a ajuda de uma skill de agente][next-lesson].
-
-## Recursos
-
-- [O que é MCP e por que todo mundo está falando sobre isso?][mcp-blog-post]
-- [Servidor MCP do Microsoft Playwright][playwright-mcp-server]
-- [Adicionar servidores MCP ao Copilot CLI][cli-add-mcp]
-- [Servidor MCP do GitHub][github-mcp-server]
-
-[previous-lesson]: ../3-generating-code/
-[next-lesson]: ../5-agent-skills/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[github-mcp-server]: https://github.com/github/github-mcp-server
-[cli-add-mcp]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
diff --git a/docs/pt-br/cli/5-agent-skills.md b/docs/pt-br/cli/5-agent-skills.md
index 058c1cd4..54b4c94b 100644
--- a/docs/pt-br/cli/5-agent-skills.md
+++ b/docs/pt-br/cli/5-agent-skills.md
@@ -1,121 +1,93 @@
---
-title: "Lição 5 - Usar skills de agente"
+title: "Lição 5 - Criar e usar uma skill quality-checks"
+description: "Peça ao Copilot que crie verificações de qualidade reutilizáveis com scripts de shell incluídos, examine a skill e execute-a na branch de filtragem."
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
-No desenvolvimento de aplicativos, é comum lidar com tarefas repetíveis, como gerar builds, executar testes ou criar pull requests. **Agent Skills** permitem orientar o Copilot — e outros agentes de IA — sobre como executar essas tarefas. Uma skill é uma pasta de instruções, scripts e recursos que o agente pode carregar sob demanda. O [Agent Skills][agent-skills-repo] é um padrão aberto usado por uma variedade de agentes, portanto a mesma skill pode funcionar no Copilot Chat em modo agente, no agente de nuvem do Copilot, no Copilot CLI e no aplicativo GitHub Copilot.
+Seu recurso de filtragem está implementado e verificado com os comandos npm existentes. Agora você reunirá essas verificações em uma **skill de agente** reutilizável. Permaneça na mesma sessão e branch de filtragem durante as Lições 4–8; esta lição não cria um pull request.
-As skills ficam na pasta `.github/skills` de um projeto, ou globalmente em `~/.copilot/skills`. Cada skill é uma pasta que contém um arquivo `SKILL.md` com frontmatter YAML, incluindo `name` e `description`, seguido das instruções em markdown:
+Nesta lição, você vai:
-```yaml
----
-name: make-contribution
-description: All changes to code must follow the guidance documented in the repository. Before any issue is filed, branch is made, commits generated, or pull request (or PR) created, a search must be done to ensure the right steps are followed. Whenever asked to create an issue, commit messages, to push code, or create a PR, use this skill so everything is done correctly.
----
-```
-
-As skills também podem incluir subpastas com scripts, assets e material de referência. A estrutura completa é abordada na [especificação de Agent Skills][agent-skills-spec].
-
-> [!TIP]
-> As skills são carregadas dinamicamente. O agente decide qual skill se aplica com base no campo `description` — uma descrição clara e específica para o cenário é o que diferencia uma skill usada de uma skill ignorada.
+- voltar ao modo **Interactive** antes de criar personalizações.
+- pedir ao Copilot que crie `quality-checks` e pare para você examiná-la.
+- executar as quatro verificações pelos scripts incluídos e comprovar que um argumento que indica um único arquivo de teste seleciona apenas esse arquivo.
+- salvar um checkpoint da skill junto com o recurso de filtragem.
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
+## Instruções, scripts e recursos
-Vamos explorar como uma skill pode garantir que pull requests sigam as especificações definidas pela equipe.
+Skills reúnem instruções de tarefas reutilizáveis, scripts executáveis e recursos de apoio que um agente carrega sob demanda. Agentes personalizados definem papéis especializados, instruções e ferramentas disponíveis. Eles são complementares: um agente personalizado pode executar scripts, incluindo os fornecidos com uma skill.
-## Cenário
+Uma skill do repositório fica em `.github/skills//SKILL.md`, com `name` e `description` no frontmatter e instruções em Markdown. Scripts e outros recursos ficam ao lado desse arquivo. Você pedirá ao Copilot que gere `.github/skills/quality-checks/SKILL.md` e seus scripts incluídos, em vez de copiar uma solução pronta. A [especificação de Agent Skills][skill-spec] descreve o formato.
-A equipe tem um conjunto de requisitos para pull requests (PR):
+O Copilot usa a descrição de uma skill descoberta para decidir quando carregá-la. Não presuma que uma skill nova seja descoberta imediatamente em uma sessão já aberta; a seção de execução inclui uma alternativa de leitura explícita. Um formato portável não elimina os pré-requisitos do shell ou do projeto.
-- mensagens de commit claras, com arquivos agrupados de forma lógica.
-- todos os testes devem passar antes da criação de um PR.
-- cada PR deve conter as seções a seguir:
- - uma descrição do motivo das alterações.
- - uma visão geral dos arquivos alterados.
- - trechos de blocos de código importantes.
- - detalhes das alterações agrupados de forma coerente.
+## Criar a skill
-Como a equipe está usando o Copilot para gerar código e PRs, ela quer garantir que as ferramentas de IA sigam esses requisitos.
+Volte ao modo **Interactive** antes de enviar o prompt. Mantenha a cópia de trabalho e a branch atuais. Se você começou com um modelo antigo que já tem essa skill, examine-a e amplie-a em vez de sobrescrever suas personalizações.
-Nesta lição, você irá:
+```plaintext
+Crie .github/skills/quality-checks/SKILL.md e quatro scripts que encapsulem npm run lint, npm run test:unit, npm run test:e2e e npm run typecheck:all. Leia primeiro package.json, README, a configuração de testes e as instruções do repositório.
-- explorar uma skill existente para criar pull requests.
-- aprender como as skills são usadas pelo agente de IA.
-- criar um PR que siga as diretrizes com a ajuda da skill.
+Detecte este ambiente. Crie SOMENTE scripts Bash .sh para macOS/Linux/WSL OU scripts PowerShell .ps1 para Windows nativo; pergunte se houver dúvida. Não crie ambos. Limite os wrappers a resolver a raiz do repositório a partir da própria localização, verificar se o package.json deste projeto está lá e invocar npm. Falhe com uma mensagem clara se a raiz for inválida. Suporte qualquer diretório de trabalho e caminhos com espaços. Preserve a saída e os códigos de saída de falhas, incluindo falhas de comandos nativos do PowerShell. Insira o separador -- do npm exatamente uma vez; quem invocar os scripts deve fornecer os argumentos da ferramenta diretamente, sem outro --. Não gerencie portas nem processos.
-## Executar skills
+Inclua em SKILL.md um frontmatter com name e description, instruções para executar os quatro wrappers, pré-requisitos, solução de problemas e exemplos portáveis que incluam um arquivo existente de testes de unidade. Todos os exemplos de Bash devem invocar bash explicitamente; nunca contorne a política de execução do PowerShell. Explique a reutilização de servidores do Playwright: pare apenas servidores que você realmente iniciou; caso contrário, pergunte.
-As skills são carregadas dinamicamente quando o agente determina que elas são necessárias. A decisão sobre quais skills usar é guiada pela descrição no arquivo `SKILL.md`. Por isso, é importante ter descrições claras que definam o caso de uso da skill.
-
-## Explorar a skill de PR
-
-Como a Tailspin Toys tem um conjunto de requisitos para criar PRs, ela criou uma skill para ajudar ferramentas de IA a gerar PRs que sigam essas diretrizes. Vamos explorar a skill para entender o que ela fará.
+Crie apenas a skill e os scripts necessários. Não execute verificações nem sondagens, não instale nada, não altere código da aplicação, não faça commit nem abra um PR. Pare para que eu possa examinar os arquivos.
+```
-1. Abra `.github/skills/make-contribution/SKILL.md`.
-2. Observe o nome e a descrição. Perceba como a descrição destaca o cenário em que a skill deve ser usada, isto é, sempre que houver uma solicitação para criar um pull request ou fazer commit de código.
-3. Leia a skill inteira. Observe como as regras definem a criação de branches, a geração de commits e o conteúdo do pull request.
+## Examinar a skill
-## Usar a skill
+1. Abra `.github/skills/quality-checks/SKILL.md` e seus scripts incluídos no editor e examine o diff.
+2. Verifique se `name` e `description` descrevem a skill e quando ela se aplica. Leia as instruções, não apenas os metadados.
+3. Confirme que a sequência de execução realmente invoca os scripts incluídos em `.github/skills/quality-checks/` para lint, testes de unidade, E2E e verificação de tipos.
+4. Examine em cada wrapper a resolução da raiz relativa ao script e uma verificação explícita de que o diretório calculado contém o `package.json` pretendido desta cópia de trabalho. Um comando bem-sucedido porque o npm pesquisa em diretórios ancestrais não comprova que a raiz está correta. Verifique caminhos entre aspas, encaminhamento de argumentos, saída visível e códigos de saída em caso de falha; o PowerShell precisa propagar falhas nativas do npm.
+5. Verifique o exemplo documentado de um único arquivo de testes de unidade. O wrapper insere o separador `--` do npm, então quem o invoca passa os argumentos da ferramenta de destino diretamente, sem outro separador. Mantenha as instruções reutilizáveis sem caminhos absolutos da cópia de trabalho específicos de uma máquina. Peça ao Copilot que corrija as lacunas antes de executar qualquer coisa.
+6. Limite os scripts à validação da raiz e do manifesto e à execução das verificações npm existentes. As decisões sobre portas e processos pertencem a SKILL.md, não a código de gerenciamento de processos em shell. Confirme que apenas servidores realmente iniciados pelo agente podem ser parados; a correspondência do diretório de trabalho ou do nome do processo não determina a quem ele pertence. Os arquivos entregues devem conter apenas a skill, os wrappers necessários e qualquer helper compartilhado necessário, sem arquivos temporários de sondagem ou depuração.
-Como destacado anteriormente, as skills são invocadas automaticamente pelo Copilot CLI. Portanto, basta pedir que o Copilot crie um PR.
+> [!NOTE]
+> O Tailspin Toys atualmente exige Node.js 22.13 ou posterior, as dependências do projeto e o Chromium do Playwright para verificações E2E. Confirme os pré-requisitos em README e `package.json` da sua cópia de trabalho. Pré-requisitos ausentes ou uma política de execução do PowerShell que bloqueie a execução precisam de uma resolução aprovada, não de instalação automática, de contorno da política ou de troca silenciosa para npm direto.
-> [!TIP]
-> **Inicie uma sessão do Copilot CLI**
->
-> Antes de iniciar os exercícios abaixo, volte ao codespace e abra um terminal (Ctrl+`, se ainda não houver um aberto). Em seguida, inicie o Copilot CLI com `--yolo` e `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar a sessão mais recente deste projeto em vez de iniciar uma nova, execute `copilot --yolo --enable-all-github-mcp-tools --continue`. Se o Copilot CLI já estiver em execução por causa de uma lição anterior, envie `/clear` para começar uma conversa limpa.
->
-> `--enable-all-github-mcp-tools` habilita as ferramentas GitHub MCP de leitura e escrita para a sessão atual, para que o Copilot possa ler seu backlog e abrir pull requests durante o fluxo do workshop.
+## Executar a skill
-> [!CAUTION]
-> `--yolo` habilita permissões automáticas completas (`--allow-all-tools`, `--allow-all-paths` e `--allow-all-urls`). Use-o apenas em um ambiente isolado, como um Codespace ou uma VM, e nunca o defina como alias padrão no seu desenvolvimento diário. Consulte [Allowing and denying tool use][allow-all-warning] para saber mais.
+Confirme que o servidor de desenvolvimento da lição anterior parou. O Playwright compila e serve uma prévia para E2E, mas sua configuração local pode reutilizar um servidor na porta `4321`. Um servidor de outra cópia de trabalho não é evidência válida para seu recurso.
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
+Se o Copilot CLI oferecer `/quality-checks`, selecione-o para invocar explicitamente a skill descoberta e inclua a solicitação abaixo. Se ela não tiver sido descoberta, envie a mesma solicitação diretamente nesta sessão; ler a skill é uma alternativa suportada nesta lição.
-1. Peça que o Copilot crie um PR usando o prompt a seguir:
+```plaintext
+Leia .github/skills/quality-checks/SKILL.md e siga as instruções para validar o recurso de filtragem nesta cópia de trabalho. Primeiro examine o código de cada wrapper para verificar se ele calcula o diretório que contém o package.json pretendido desta cópia de trabalho e falha explicitamente para uma raiz inválida, em vez de depender da descoberta de pacotes em diretórios ancestrais pelo npm. Não mova, renomeie, exclua nem modifique arquivos do repositório para simular falhas. Execute realmente os scripts incluídos para lint, testes de unidade, testes de ponta a ponta e verificações de tipos. Execute também o exemplo documentado de um único arquivo de testes de unidade, passando os argumentos da ferramenta de destino diretamente porque o wrapper é responsável pelo separador -- do npm. Verifique nos resultados do executor de testes se APENAS o arquivo indicado foi executado e relate o nome desse arquivo e a quantidade de arquivos de teste executados. Exibir os argumentos ou retornar o código de saída 0 não comprova, por si só, que a seleção está correta.
- ```
- Can you please create a pull request for me!
- ```
+Relate cada invocação de script e seu resultado, incluindo falhas, verificações ignoradas ou pré-requisitos ausentes. Não substitua silenciosamente um script inutilizável da skill por comandos npm diretos. Identifique a cópia de trabalho e o servidor em teste, pare apenas os servidores que você iniciou e pergunte antes de instalar algo ou parar outro processo. Não altere código da aplicação, não mude de branch, não faça commit, push nem abra um pull request.
+```
-2. O Copilot reconhecerá a solicitação. Após alguns instantes, você verá o Copilot indicar que está usando a skill **make-contribution**.
+Examine as chamadas de ferramentas e a saída. Os quatro scripts precisam realmente executar; uma descrição das verificações ou uma verificação ignorada não equivale à aprovação. Para o exemplo de um único arquivo, compare o nome do arquivo solicitado com os resultados reais por arquivo do executor e a quantidade relatada: apenas esse arquivo deve executar. Exibir os argumentos ou retornar o código de saída 0 é insuficiente se outros arquivos também executaram. Uma falha é evidência útil: corrija a skill ou resolva o bloqueio de configuração com aprovação e execute novamente as verificações afetadas. Não pare processos não relacionados nem force a resolução de um conflito de porta.
-3. O Copilot seguirá as instruções da skill. Ele começará executando os testes, depois criará uma branch, fará commits e, por fim, abrirá o PR.
-4. Quando o PR for criado, volte ao repositório e abra-o. Observe como as seções seguem as diretrizes definidas na skill e atendem aos requisitos da equipe.
-5. Antes de passar para a próxima lição, redefina seu workspace local para uma branch nova criada a partir de `main`, para manter o trabalho de acessibilidade separado deste PR de filtragem:
+## Salvar um checkpoint
- ```bash
- git checkout main
- git pull
- git checkout -b accessibility-cli
- ```
+Após revisar a skill e seus resultados, autorize um checkpoint local:
-## Resumo e próximos passos
+```plaintext
+Revise o diff atual e crie um commit de checkpoint apenas para os arquivos da skill quality-checks. Mantenha a branch de filtragem existente. Não faça push nem crie um pull request.
+```
-Com a ajuda de uma skill de agente, você criou um novo PR que segue requisitos documentados. Você:
+Os arquivos da skill acompanharão a filtragem, o perfil de QA e os testes associados no PR do recurso na Lição 8. Continue nesta mesma cópia de trabalho com a [Lição 6 - Validar a funcionalidade com o MCP do Playwright][next-lesson].
-- explorou uma skill existente para criar pull requests.
-- aprendeu como as skills são usadas pelo agente de IA.
-- criou um PR que segue as diretrizes com a ajuda da skill.
+## Mais exemplos de skills
-As skills são perfeitas para tarefas, mas, para operações mais robustas, vale aproveitar [agentes personalizados][next-lesson], que serão o próximo tópico.
+Estes exemplos da comunidade são referências, não tarefas adicionais. Revise seus pré-requisitos e comportamento antes de adotá-los:
-## Recursos
+- [Fluxo de contribuição: `make-repo-contribution`][contribution-example].
+- [Documentos de requisitos: `prd`][prd-example].
+- [Diagramas e um script de exportação incluído: `drawio`][drawio-example].
+- [Testes de navegador: `webapp-testing`][browser-example].
-- [Sobre Agent Skills][about-agent-skills]
-- [Especificação de Agent Skills][agent-skills-spec]
-- [Repositório Agent Skills][agent-skills-repo]
-- [Agent Skills no awesome-copilot][awesome-copilot-skills]
+O exemplo original de contribuição se chama `make-repo-contribution`; modelos antigos do Tailspin usavam outro nome, `make-contribution`. Este workshop não depende de nenhuma dessas skills de contribuição.
-[previous-lesson]: ../4-mcp/
-[next-lesson]: ../6-custom-agents/
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[awesome-copilot-skills]: https://github.com/github/awesome-copilot/tree/main/skills
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/pt-br/cli/6-custom-agents.md b/docs/pt-br/cli/6-custom-agents.md
deleted file mode 100644
index e4705cfc..00000000
--- a/docs/pt-br/cli/6-custom-agents.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: "Lição 6 - Agentes personalizados com o GitHub Copilot CLI"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-## O que são agentes personalizados?
-
-[Agentes personalizados][custom-agents-concept] no GitHub Copilot permitem criar assistentes de IA especializados e adaptados a tarefas ou domínios específicos do seu fluxo de desenvolvimento. Ao definir agentes por meio de arquivos markdown na pasta `.github/agents` do repositório, você fornece ao Copilot instruções direcionadas, boas práticas, padrões de código e conhecimento específico do domínio para orientá-lo a executar determinados tipos de trabalho com mais eficácia. As equipes podem transformar sua experiência em agentes reutilizáveis — um agente de acessibilidade que aplica conformidade com a [WCAG][wcag], um agente de segurança que segue práticas de programação segura ou um agente de testes que mantém padrões consistentes.
-
-Agentes personalizados são definidos por arquivos markdown na pasta `.github/agents` do projeto, ou globalmente em `~/.copilot/agents`. Cada arquivo tem frontmatter YAML com pelo menos `name` e `description`, seguido de um prompt em markdown que define o comportamento, a especialização e as instruções do agente.
-
-### Agentes personalizados em comparação com skills de agente
-
-Há alguma sobreposição lógica entre agentes personalizados e [skills de agente][agent-skills-concept]. Ambos são definidos principalmente com arquivos markdown e dizem à IA como executar operações. A forma mais clara de diferenciá-los é: um **agente personalizado** é o executor, e as **skills** são ferramentas.
-
-Agentes personalizados têm sua própria janela de contexto e são criados para orquestrar skills, e até outros agentes, como parte do trabalho. Neste laboratório, o agente personalizado de acessibilidade revisa e atualiza o site com base em diretrizes de acessibilidade; como parte desse trabalho, ele poderia chamar skills como uma skill de fluxo de pull request ou outra que execute e gerencie testes.
-
-> [!NOTE]
-> Não existe uma única forma "correta" de criar um agente personalizado. Como em qualquer coisa relacionada à IA, teste e itere para descobrir o que funciona melhor nos seus ambientes e cenários.
-
-[custom-agents-concept]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
-[agent-skills-concept]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[wcag]: https://www.w3.org/WAI/standards-guidelines/wcag/
-
-## Cenário
-
-Muitos aplicativos web ainda não são acessíveis para todas as pessoas usuárias, e o site em que você está trabalhando não é exceção. Você usará um agente personalizado para identificar e corrigir problemas de acessibilidade.
-
-A Tailspin Toys está comprometida em garantir que sua plataforma de financiamento coletivo seja acessível a todas as pessoas usuárias, independentemente de suas capacidades visuais ou preferências. Comentários recentes de usuários destacaram que algumas pessoas têm dificuldade para ler o tema escuro atual por causa do contraste insuficiente entre as cores de texto e de fundo. Para tratar essa preocupação de acessibilidade, a equipe de design solicitou a implementação de um modo de alto contraste que usuários possam ativar e desativar.
-
-Como a acessibilidade é crítica, você quer garantir que isso seja implementado o mais rápido possível. Você usará um agente personalizado para gerar essa funcionalidade.
-
-Nesta lição, você irá:
-
-- explorar agentes personalizados.
-- habilitar um agente personalizado e atribuir uma tarefa a ele usando o Copilot CLI.
-
-## Revisar o agente personalizado de acessibilidade
-
-Um agente personalizado de acessibilidade já foi criado para você. Vamos revisar o conteúdo para entender como ele orientará o Copilot.
-
-1. Abra `.github/agents/accessibility.md`.
-2. Observe o frontmatter YAML com os campos `name` e `description`.
-
-> [!CAUTION]
-> O frontmatter com `name` e `description` é obrigatório para agentes personalizados.
-
-3. A partir daí, revise as seções seguintes, que destacam:
- - responsabilidades principais ao gerar código para um site acessível.
- - boas práticas de acessibilidade.
- - exemplos de código em HTML, CSS e JavaScript.
- - uma lista de armadilhas e erros comuns.
-
-## Usar um agente personalizado no Copilot CLI
-
-Você pode iniciar um agente personalizado no Copilot CLI com o comando `/agent`. Vamos fazer uma revisão de acessibilidade no site.
-
-> [!TIP]
-> **Inicie uma sessão do Copilot CLI**
->
-> Antes de iniciar os exercícios abaixo, volte ao codespace e abra um terminal (Ctrl+`, se ainda não houver um aberto). Em seguida, inicie o Copilot CLI com `--yolo` e `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar a sessão mais recente deste projeto em vez de iniciar uma nova, execute `copilot --yolo --enable-all-github-mcp-tools --continue`. Se o Copilot CLI já estiver em execução por causa de uma lição anterior, envie `/clear` para começar uma conversa limpa.
->
-> `--enable-all-github-mcp-tools` habilita as ferramentas GitHub MCP de leitura e escrita para a sessão atual, para que o Copilot possa ler seu backlog e abrir pull requests durante o fluxo do workshop.
-
-> [!CAUTION]
-> `--yolo` habilita permissões automáticas completas (`--allow-all-tools`, `--allow-all-paths` e `--allow-all-urls`). Use-o apenas em um ambiente isolado, como um Codespace ou uma VM, e nunca o defina como alias padrão no seu desenvolvimento diário. Consulte [Allowing and denying tool use][allow-all-warning] para saber mais.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. Abra a lista de agentes digitando `/agent` na janela de prompt do Copilot CLI e pressionando Enter.
-2. Selecione o **Accessibility agent** na lista de agentes disponíveis.
-3. Use o prompt a seguir para pedir que o agente de acessibilidade faça uma revisão e gere correções para o item de backlog relacionado à acessibilidade:
-
- ```
- Perform an accessibility review of the site. Pull the related issue down from the repository for details. Implement a high-contrast mode toggle that persists the user's preference across page reloads. Ensure there are e2e tests for any updates made to the project. Then create a PR with the updates.
- ```
-
-4. O Copilot começará a trabalhar na tarefa. Ele recuperará a issue, fará a revisão, gerará as atualizações e, por fim, criará o PR. Você também deve notar que, ao criar o PR, ele usa a skill do projeto voltada a pull requests.
-
-> [!NOTE]
-> Esse processo provavelmente levará alguns minutos. É um bom momento para refletir sobre tudo o que você aprendeu, aproveitar uma bebida ou adiantar a próxima lição, que apresenta alguns comandos adicionais disponíveis no Copilot CLI.
-
-## Resumo e próximos passos
-
-Esta lição explorou [agentes personalizados][custom-agents] no GitHub Copilot, assistentes de IA especializados e adaptados a tarefas e domínios específicos. Com agentes personalizados, você pode transformar a experiência e os padrões da sua equipe em agentes reutilizáveis que orientam o Copilot a executar determinados tipos de trabalho com mais eficácia.
-
-Você explorou estes conceitos:
-
-- como agentes personalizados são definidos.
-- usar um agente personalizado no Copilot CLI.
-
-Em seguida, vamos explorar [alguns comandos de barra][next-lesson] para aprender outros truques do Copilot CLI.
-
-## Recursos
-
-- [Agentes personalizados][custom-agents]
-- [Criar agentes personalizados para um repositório][creating-custom-agents]
-- [Agentes personalizados no awesome-copilot][awesome-copilot-agents]
-- [Preparar o uso de agentes personalizados na sua organização][org-custom-agents]
-- [Preparar o uso de agentes personalizados na sua empresa][enterprise-custom-agents]
-
-[previous-lesson]: ../5-agent-skills/
-[next-lesson]: ../7-slash-commands/
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[creating-custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/create-custom-agents
-[awesome-copilot-agents]: https://github.com/github/awesome-copilot/tree/main/agents
-[org-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-organization/prepare-for-custom-agents
-[enterprise-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/prepare-for-custom-agents
diff --git a/docs/pt-br/cli/6-mcp-playwright.md b/docs/pt-br/cli/6-mcp-playwright.md
new file mode 100644
index 00000000..96e25dc1
--- /dev/null
+++ b/docs/pt-br/cli/6-mcp-playwright.md
@@ -0,0 +1,83 @@
+---
+title: "Lição 6 - Validar a funcionalidade com o MCP do Playwright"
+description: "Conecte um navegador via MCP e compare o comportamento observado da filtragem com a issue e o plano aprovado."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Sua implementação de filtragem e a skill quality-checks já têm verificação automatizada. Agora dê um navegador ao Copilot e peça que observe a funcionalidade diretamente. Esta lição demonstra a interação por **Model Context Protocol (MCP)**, não outra execução completa da suíte de testes.
+
+Permaneça no modo **Interactive** na mesma cópia de trabalho e branch de filtragem. A configuração do MCP não inicia um novo marco de recurso.
+
+## O que o MCP acrescenta
+
+O [MCP][mcp-overview] conecta um agente a ferramentas e contexto externos por meio de servidores. O servidor MCP do GitHub integrado permite ao Copilot trabalhar com issues e PRs. O [servidor MCP do Playwright][playwright-mcp] fornece ferramentas de navegador para abrir páginas, examinar elementos acessíveis, navegar e interagir com controles.
+
+O snapshot de acessibilidade do navegador ajuda o agente a identificar controles, mas não comprova conformidade completa de acessibilidade. Compare ações e observações reais com os requisitos da issue em vez de aceitar um “parece bom” genérico.
+
+> [!CAUTION]
+> Trate um servidor MCP como uma dependência do projeto: revise o publicador, o código-fonte, as permissões e qualquer download de pacote antes de habilitá-lo. Políticas da organização podem restringir quais servidores podem executar. Não coloque credenciais em configurações versionadas nem aprove ferramentas desconhecidas apenas para concluir a lição.
+
+## Configurar o MCP do Playwright
+
+1. Na sessão existente da CLI, digite `/mcp` para examinar os servidores configurados. Reutilize uma configuração funcional do Playwright em vez de adicionar uma duplicada.
+2. Se necessário, digite `/mcp add` e use Tab para percorrer o formulário.
+3. Defina **Server Name** como `playwright`, **Server Type** como **STDIO** (ou **Local**) e **Command** como `npx @playwright/mcp@latest --headless`.
+4. Defina **Tools** como `*` para este servidor de navegador revisado. Isso disponibiliza suas ferramentas; não substitui os controles de permissão da CLI.
+5. Depois de revisar o pacote e seu comando de inicialização, pressione Ctrl+S para salvar. O registro inicia o servidor e pode baixar o pacote; aprove essa configuração deliberadamente e responda a qualquer solicitação do pacote.
+6. Digite `/mcp show playwright` e confirme que o servidor está conectado e suas ferramentas de navegador estão disponíveis.
+
+O navegador headless não precisa de uma janela de desktop, o que é adequado ao Codespaces. O fluxo interativo de adição salva a configuração em `~/.copilot/mcp-config.json` e disponibiliza o servidor sem reiniciar a CLI. Essa é uma configuração do usuário, não um arquivo para incluir no PR do recurso. O [guia de configuração do MCP][mcp-setup] documenta os campos e as fontes de configuração.
+
+> [!NOTE]
+> As dependências E2E do projeto e o navegador do MCP estão relacionados, mas podem exigir configurações diferentes. Se faltar um navegador ou uma dependência do sistema, examine o erro real e resolva o pré-requisito específico com aprovação. Não instale navegadores automaticamente nem presuma que um servidor conectado comprova que ele pode iniciar um.
+
+## Iniciar a aplicação correta
+
+Abra outro terminal nesta mesma cópia de trabalho de filtragem. Confirme o diretório e a branch e depois inicie a aplicação:
+
+```bash
+pwd
+git branch --show-current
+npm run dev
+```
+
+Leia a URL local real na saída do servidor. No codespace, o servidor MCP e a aplicação executam no mesmo ambiente, então use essa URL local, normalmente `http://localhost:4321`, em vez de presumir que uma URL de navegador encaminhada seja necessária.
+
+Se a porta estiver ocupada ou o Astro escolher outra porta, identifique a quem pertence o servidor antes de continuar. Não reutilize um servidor desconhecido nem o encerre. Use a URL do processo que você acabou de iniciar e mantenha esse terminal aberto durante os testes.
+
+## Observar o comportamento de filtragem
+
+Substitua os marcadores pela URL real da issue, os esclarecimentos aprovados na Lição 4 e a URL da aplicação:
+
+```plaintext
+Use o servidor MCP do Playwright configurado para validar o recurso de filtragem em relação a esta issue: . Estes são os esclarecimentos aprovados durante o planejamento: . A aplicação desta cópia de trabalho está executando em . Confirme a cópia de trabalho, a branch e o servidor em teste antes de confiar nos resultados.
+
+Abra a página de jogos, observe o estado sem filtros, selecione uma e depois múltiplas categorias, aplique um filtro de distribuidora e combine as seleções de categoria e distribuidora. Exercite a limpeza e os resultados vazios conforme os critérios aprovados. Verifique os rótulos dos controles, a operação por teclado e o foco visível. Compare os resultados exibidos com os filtros selecionados e os dados de origem; não deduza sucesso apenas porque um controle mudou.
+
+Use ações reais das ferramentas de navegador e relate o que observou para cada critério, marcando claramente falhas ou evidências ausentes. Não execute outra suíte completa de testes apenas por esta lição de navegador, não altere código da aplicação, não crie testes ou personalizações, não mude de branch, não faça commit, push nem abra um PR. Pergunte antes de instalar algo ou parar outro processo.
+```
+
+Examine as chamadas de ferramentas do navegador e o relatório. O Copilot realmente selecionou múltiplas categorias e as combinou com uma distribuidora? Os jogos retornados correspondem ao comportamento acordado? O relatório distingue o comportamento observável no navegador da cobertura da camada de dados e dos testes automatizados?
+
+Se algo falhar, registre o comportamento observado. Autorize separadamente qualquer correção específica da aplicação e depois repita as verificações de navegador e automatizadas afetadas. Não altere os critérios de aceitação para corresponder à implementação nem conte evidências antigas como verificação de código alterado.
+
+## Parar o próprio servidor e continuar
+
+Pare o servidor de desenvolvimento com Ctrl+C no terminal em que o iniciou. Mantenha a configuração do MCP do Playwright disponível. A Lição 7 coordenará novas observações no navegador e verificações E2E automatizadas, que não devem reutilizar um servidor de desenvolvimento desatualizado nem a aplicação de outra cópia de trabalho.
+
+Permaneça em **Interactive** antes de criar o perfil de QA. Você observou o comportamento no navegador sem criar outro PR ou branch; em seguida, [crie e use um agente de QA][next-lesson] para combinar requisitos, cobertura, a skill e as evidências finais.
+
+## Recursos
+
+- [Adicionar servidores MCP ao Copilot CLI][mcp-setup] documenta configuração e gerenciamento.
+- [Microsoft Playwright MCP][playwright-mcp] documenta a configuração e as ferramentas de navegador.
+- [Registro MCP do GitHub][mcp-registry] lista outros servidores para avaliar.
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-overview]: https://docs.github.com/copilot/concepts/context/mcp
+[mcp-setup]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
+[playwright-mcp]: https://github.com/microsoft/playwright-mcp
+[mcp-registry]: https://github.com/mcp
diff --git a/docs/pt-br/cli/7-qa-agent.md b/docs/pt-br/cli/7-qa-agent.md
new file mode 100644
index 00000000..9beb6010
--- /dev/null
+++ b/docs/pt-br/cli/7-qa-agent.md
@@ -0,0 +1,77 @@
+---
+title: "Lição 7 - Criar e usar um agente de QA"
+description: "Crie um perfil de QA que parta dos requisitos e combine cobertura de testes, a skill quality-checks e evidências diretas do navegador."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Você executou verificações repetíveis e explorou a filtragem pelo MCP do Playwright. Agora crie um **agente personalizado de QA** para reunir os requisitos, a cobertura e as evidências do navegador. Mantenha a sessão, a cópia de trabalho e a branch de filtragem; o PR do recurso vem na Lição 8.
+
+## Criar o perfil de QA
+
+Permaneça no modo **Interactive**. Um perfil define o papel e as instruções de um especialista; uma skill reúne instruções de tarefas reutilizáveis, scripts e recursos. O agente de QA usará sua skill e as ferramentas MCP configuradas em vez de substituí-las.
+
+Envie este prompt e examine a definição antes de executá-la:
+
+```plaintext
+Crie um agente personalizado de QA reutilizável em .github/agents/qa.agent.md. Primeiro examine as instruções do repositório, package.json, a configuração de testes e .github/skills/quality-checks/SKILL.md. Forneça ao perfil um frontmatter YAML válido com name definido como QA e uma description que explique quando usá-lo. Não fixe um modelo nem adicione uma lista tools; herde as ferramentas e permissões disponíveis no ambiente. Crie apenas a definição do agente e pare para que eu possa examiná-la antes de executá-lo.
+
+Nas instruções do agente, exija que toda tarefa de QA comece pela issue e por quaisquer critérios de aceitação aprovados fornecidos pelo usuário. Trate esses requisitos como fonte de verdade, não a implementação. Pergunte quando faltarem requisitos ou eles forem ambíguos. Examine o recurso e os testes existentes e mapeie cada critério à cobertura automatizada adequada e ao comportamento observável.
+
+Exija validação direta no navegador pelo servidor MCP do Playwright configurado e execução de lint, testes de unidade, testes de ponta a ponta e verificações de tipos pela skill quality-checks existente e seus scripts incluídos. Leia a skill explicitamente se ela não tiver sido descoberta automaticamente. Relate skills, ferramentas MCP, pré-requisitos ou acesso ausentes como bloqueios; não substitua silenciosamente o fluxo por outro nem rotule verificações ignoradas como aprovadas. Identifique a cópia de trabalho e o servidor em teste, evite reutilizar o servidor de outro worktree, pare apenas os servidores iniciados pelo agente e pergunte antes de qualquer instalação ou de parar outro processo.
+
+Permita que o agente de QA adicione os menores testes necessários para lacunas reais de cobertura, seguindo as instruções do repositório; não adicionar testes é válido quando a cobertura já é adequada. Não enfraqueça asserções, não desative testes com falha, não altere critérios de aceitação para corresponder ao código nem modifique código da aplicação sem minha aprovação. Após alterações, execute novamente as verificações afetadas e conclua a verificação final da revisão resultante. Exija um relatório conciso que mapeie critérios a evidências e ao status aprovado/reprovado/bloqueado, liste os testes adicionados ou explique por que nenhum foi necessário, relate os resultados das quatro verificações e identifique defeitos não resolvidos. GO exige todas as verificações e evidências obrigatórias; caso contrário, relate NO-GO e o motivo. Não mude de branch, não faça commit, push, não abra ou integre PRs nem crie agentes ou skills adicionais durante QA.
+```
+
+## Examinar o perfil
+
+Abra `.github/agents/qa.agent.md` no editor e examine o diff. `description` é obrigatório; esta lição também fornece `QA` como `name` legível. Confirme que não há um `model` fixado nem uma lista de ferramentas inventada. Omitir `tools` herda as ferramentas disponíveis; não contorna as permissões do ambiente. Perfis de produção podem restringir ferramentas deliberadamente.
+
+Confirme que as instruções começam pelos requisitos, exigem atividade real no navegador via MCP e scripts da skill, permitem apenas adições justificadas de testes e relatam bloqueios com veracidade. Nem um perfil especializado nem uma skill exige uma janela de contexto separada ou a orquestração de outros agentes.
+
+## Executar QA em relação à issue
+
+O prompt de execução é para o agente personalizado **QA** selecionado, não para o agente padrão lendo um perfil. Inicie uma conversa nova da CLI na mesma cópia de trabalho para carregar o novo perfil sem criar outra branch de recurso.
+
+1. Preserve a URL da issue de filtragem e os esclarecimentos aprovados. Aguarde o agente atual terminar e digite `/exit` para voltar ao terminal.
+2. Confirme que você ainda está no diretório do repositório de filtragem e na mesma branch com `git branch --show-current` e `git status --short`. Não mude de branch nem crie um worktree.
+3. Inicie a CLI com o perfil do repositório:
+
+ ```shell
+ copilot --agent qa
+ ```
+
+4. Verifique se a CLI identifica **QA** como agente selecionado antes de executá-lo. A [referência de comandos da CLI][cli-reference] documenta `--agent`; escrever ou ler o perfil não é, por si só, ativação. Se a seleção falhar ou o agente não conseguir acessar as ferramentas MCP do Playwright configuradas e a skill, pause e resolva esse bloqueio com a pessoa que conduz o workshop.
+
+Substitua os dois marcadores pela URL real da issue de filtragem e os esclarecimentos aprovados na Lição 4, ou por `none` quando a issue estiver completa. Não dependa da memória do agente anterior.
+
+```plaintext
+Verifique o recurso de filtragem em relação a esta issue: . Estes são os critérios de aceitação adicionais que aprovei durante o planejamento: .
+
+Valide o comportamento com o servidor MCP do Playwright, examine a cobertura de testes, adicione testes apenas para lacunas de cobertura e execute a validação pela skill quality-checks. Relate evidências, resultados das verificações e bloqueios. Não altere código da aplicação sem minha aprovação, não crie um commit nem abra um pull request.
+```
+
+## Revisar as evidências
+
+Compare o relatório com a issue: cada critério precisa de cobertura automatizada adequada e comportamento observável. Examine a atividade real das ferramentas MCP do Playwright, a identidade da cópia de trabalho e do servidor e os resultados dos quatro scripts da skill. As verificações no navegador e E2E automatizadas não devem reutilizar um servidor desatualizado ou outra cópia de trabalho.
+
+Revise os testes adicionados: eles devem cobrir lacunas reais sem enfraquecer asserções. Não adicionar testes é correto quando a cobertura é adequada. Um parecer **NO-GO** por bloqueio ou falha é um resultado válido, não permissão para ignorar evidências.
+
+Se QA identificar um defeito na aplicação, aprove separadamente uma correção específica e execute novamente as verificações e observações no navegador afetadas na revisão resultante. Pré-requisitos ou ferramentas ausentes precisam de uma resolução explícita. Não trate evidências antigas como prova de código alterado.
+
+## Salvar um checkpoint
+
+Quando QA terminar, preserve o relatório com a URL da issue, os esclarecimentos aprovados, a revisão testada, as observações no navegador e os resultados das verificações. Digite `/exit` e inicie `copilot` sem `--agent` no mesmo diretório e branch para voltar a uma conversa normal. Forneça esse contexto novamente; a conversa nova não herda as evidências da conversa de QA.
+
+Após revisar o perfil, quaisquer alterações de testes e as evidências resultantes, envie a solicitação abaixo ao agente normal:
+
+```plaintext
+Revise o diff atual e crie um commit de checkpoint para a definição do agente de QA e quaisquer alterações de testes aprovadas. Permaneça na branch de filtragem existente. Não faça push nem abra um pull request.
+```
+
+Continue na [Lição 8 - Criar e integrar o PR do recurso][next-lesson] com o recurso de filtragem, a skill, o perfil de QA, os testes e as evidências atuais de verificação.
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/pt-br/cli/7-slash-commands.md b/docs/pt-br/cli/7-slash-commands.md
deleted file mode 100644
index b37b4de0..00000000
--- a/docs/pt-br/cli/7-slash-commands.md
+++ /dev/null
@@ -1,177 +0,0 @@
----
-title: "Lição 7 - Comandos de barra no GitHub Copilot CLI"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-Como toda boa ferramenta de CLI, o GitHub Copilot CLI inclui vários comandos de barra para interação. Esses comandos expõem funcionalidades avançadas, informações de bastidores ou opções adicionais de configuração. Você já explorou alguns deles, como `/clear` para limpar o contexto e `/mcp` para inspecionar servidores MCP. Agora, vamos explorar outros comandos poderosos, incluindo `/context`, `/model`, `/share` e `/delegate`.
-
-## Cenário
-
-Você concluiu os fluxos centrais da CLI. Agora, vamos conhecer algumas capacidades adicionais — compartilhar sessões, trocar de modelo e delegar tarefas ao [agente de nuvem do Copilot][about-cloud-agent].
-
-Nesta lição, você usará:
-
-- `/share` para criar uma GitHub gist e compartilhar sua sessão com a equipe.
-- `/context` para ver o contexto que o Copilot CLI está usando no momento.
-- `/model` para explorar a lista de modelos disponíveis e selecionar outro, se quiser.
-- `/delegate` para, opcionalmente, encaminhar uma tarefa ao agente de nuvem. Isso requer o agente de nuvem, disponível nos planos Copilot Student, Pro, Pro+, Business ou Enterprise — todos, exceto Copilot Free.
-
-## Compartilhar uma sessão
-
-Usar qualquer ferramenta, inclusive uma ferramenta de IA, é uma habilidade. Trabalhar em equipe e compartilhar aprendizados é a melhor forma de melhorar a experiência de todas as pessoas e gerar código de maior qualidade. Para apoiar isso, o Copilot CLI oferece o comando `/share`. O comando `/share` pode gerar um arquivo markdown ou uma GitHub gist com os detalhes da sessão, incluindo os prompts usados e a lógica seguida pelo Copilot.
-
-Vamos criar uma GitHub gist que você poderia compartilhar com a equipe.
-
-> [!TIP]
-> **Inicie uma sessão do Copilot CLI**
->
-> Antes de iniciar os exercícios abaixo, volte ao codespace e abra um terminal (Ctrl+`, se ainda não houver um aberto). Em seguida, inicie o Copilot CLI com `--yolo` e `--enable-all-github-mcp-tools`:
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> Para retomar a sessão mais recente deste projeto em vez de iniciar uma nova, execute `copilot --yolo --enable-all-github-mcp-tools --continue`. Se o Copilot CLI já estiver em execução por causa de uma lição anterior, envie `/clear` para começar uma conversa limpa.
->
-> `--enable-all-github-mcp-tools` habilita as ferramentas GitHub MCP de leitura e escrita para a sessão atual, para que o Copilot possa ler seu backlog e abrir pull requests durante o fluxo do workshop.
-
-> [!CAUTION]
-> `--yolo` habilita permissões automáticas completas (`--allow-all-tools`, `--allow-all-paths` e `--allow-all-urls`). Use-o apenas em um ambiente isolado, como um Codespace ou uma VM, e nunca o defina como alias padrão no seu desenvolvimento diário. Consulte [Allowing and denying tool use][allow-all-warning] para saber mais.
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. Na janela de prompt do Copilot CLI, envie o comando a seguir:
-
- ```
- /share gist
- ```
-
-2. Em poucos instantes, o Copilot criará uma gist e exibirá o link.
-3. Copie o texto do link.
-4. Em uma nova guia do navegador, cole o link para explorar a gist. Observe como a gist destaca os prompts enviados, as skills e os agentes usados, o processo de raciocínio do Copilot e até o código e os resultados de comandos executados localmente.
-
-As gists e os arquivos markdown gerados por `/share` podem ser usados para documentar como o código foi criado ou para compartilhar com a equipe como determinadas ações foram executadas para obter os resultados desejados com o Copilot.
-
-## Explorar o contexto do Copilot CLI
-
-Ao trabalhar em tarefas maiores ou mais complexas, você pode atingir o limite da janela de contexto do modelo. O tamanho exato dessa janela varia de acordo com o modelo usado e a versão do Copilot CLI. Quando a janela de contexto fica cheia, o Copilot CLI a compacta automaticamente, resumindo as informações e removendo tudo o que considerar irrelevante para a tarefa atual. Você pode ver o estado atual do contexto e também compactá-lo manualmente com comandos de barra. Vamos explorar a janela de contexto.
-
-1. Na janela de prompt do Copilot CLI, envie o comando a seguir:
-
- ```
- /context
- ```
-
-2. Em poucos instantes, o Copilot CLI gerará uma representação visual do contexto atual:
-
- 
-
-3. Observe o modelo exibido, que pode ser diferente do mostrado na imagem, e a porcentagem atual de tokens usados. O restante das informações destaca:
-
- | Título | Descrição |
- | ------------ | ------------------------------------------------------ |
- | System/Tools | Arquivos de instruções, conteúdo de arquivos e definições de ferramentas |
- | Messages | Histórico da conversa entre você e o Copilot |
- | Buffer | Espaço reservado pelo Copilot CLI para gerar respostas |
- | Free space | Espaço livre restante |
-
-4. Compacte o histórico da conversa enviando o seguinte comando de barra ao Copilot CLI:
-
- ```
- /compact
- ```
-
-5. Quando a operação terminar, envie o comando a seguir para exibir novamente as estatísticas atuais do contexto:
-
- ```
- /context
- ```
-
-6. Observe a mudança no contexto. Talvez ela não seja drástica, já que a janela de contexto provavelmente ainda está relativamente pequena neste momento.
-
-> [!NOTE]
-> O Copilot CLI compactará o contexto automaticamente quando ele estiver cheio. Ao se aproximar de 100% da capacidade, ele exibirá a porcentagem logo acima da janela de prompt. Normalmente, a compactação acontece de forma assíncrona, permitindo que você continue interagindo com o Copilot enquanto ele faz esse trabalho. No entanto, em alguns casos ele pode bloquear uma operação em andamento por vários segundos durante o processo.
-
-### Boas práticas com contexto
-
-Na maioria das sessões, o contexto será gerenciado com eficiência pelo próprio Copilot sem orientações específicas. Mesmo assim, pode haver situações em que você decida instruir manualmente o Copilot a limpar ou compactar o histórico:
-
-- Se você for mudar para outra parte do aplicativo ou para uma tarefa não relacionada, pode usar `/clear` para começar de novo e evitar confundir o Copilot com contexto antigo e irrelevante.
-- Se você estiver se aproximando do limite máximo da janela de contexto, pode usar `/compact` manualmente para controlar quando a compactação acontecerá.
-
-> [!CAUTION]
-> Novamente, na maior parte do tempo, o Copilot gerenciará o contexto sem interação direta sua. Se você perceber que o Copilot está um pouco confuso por causa de informações antigas, ou estiver prestes a mudar para uma tarefa sem relação com a atual, considere usar os comandos manuais.
-
-## Escolher seu modelo
-
-Modelos diferentes têm pontos fortes diferentes, e pessoas desenvolvedoras diferentes têm preferências diferentes. O Copilot CLI permite listar e selecionar o modelo que você quer usar.
-
-1. Exiba a lista de modelos enviando o comando de barra a seguir ao Copilot CLI:
-
- ```
- /model
- ```
-
-2. Observe a lista de modelos. Cada modelo exibirá tanto seu nome quanto o modificador de custo por solicitação.
-3. Se quiser, selecione um novo modelo. Ou pressione Esc para sair da lista.
-
-> [!CAUTION]
-> A seleção de modelo persiste no Copilot CLI.
-
-## Delegar ao agente de nuvem (opcional)
-
-Há situações em que você quer continuar trabalhando no terminal, mas precisa delegar uma tarefa mais demorada ao agente de nuvem do Copilot. O comando `/delegate` envia a sessão atual do Copilot CLI para o GitHub.com, onde o agente de nuvem a assume, trabalha de forma assíncrona e abre um pull request quando termina.
-
-> [!NOTE]
-> `/delegate` requer o agente de nuvem, disponível nos planos Copilot Student, Pro, Pro+, Business ou Enterprise — todos, exceto Copilot Free. Se você não tiver acesso, leia esta seção e pule a parte prática.
-
-1. Primeiro, limpe a sessão atual para evitar delegar o contexto acumulado do workshop:
-
- ```
- /clear
- ```
-
-2. Envie um prompt pequeno e bem delimitado. Por exemplo, você pode delegar a meta extra de paginação do seu backlog:
-
- ```
- Implement pagination on the game list page so it shows a fixed number of games per page with Previous and Next controls, and add tests.
- ```
-
-3. Envie o comando de barra a seguir para entregar a sessão ao agente de nuvem e confirme o prompt que deseja delegar:
-
- ```
- /delegate
- ```
-
-4. Abra [Copilot agents](https://github.com/copilot/agents) no navegador para acompanhar o progresso.
-5. Você não precisa esperar a conclusão do pull request neste percurso. Pode voltar a ele mais tarde. Se quiser se aprofundar no gerenciamento de trabalho assíncrono com agentes, continue no [percurso do agente de nuvem](../../cloud/).
-
-## Resumo e próximos passos
-
-Usar comandos de barra no Copilot CLI permite configurá-lo, compartilhar sessões e obter informações internas sobre como o Copilot está trabalhando. Nesta lição, você usou ou explorou:
-
-- `/share` para criar uma GitHub gist e compartilhar sua sessão com a equipe.
-- `/context` para ver o contexto que o Copilot CLI está usando no momento.
-- `/model` para explorar a lista de modelos disponíveis e selecionar outro, se quiser.
-- `/delegate` como uma ponte opcional para o agente de nuvem.
-
-É claro que há mais comandos de barra disponíveis e muito mais para explorar no Copilot CLI. Vamos encerrar essa jornada [revendo o que aprendemos][next-lesson] e vendo alguns próximos passos para continuar aprendendo.
-
-## Recursos
-
-- [Usar o Copilot CLI][using-copilot-cli]
-- [Sobre o Copilot CLI][about-copilot-cli]
-- [Gerenciamento de contexto no Copilot CLI][context-management]
-- [Compartilhar sessões com o Copilot CLI][share-sessions]
-- [Selecionar modelos no Copilot CLI][selecting-models]
-
-[previous-lesson]: ../6-custom-agents/
-[next-lesson]: ../8-review/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[about-cloud-agent]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
-[share-sessions]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#share-sessions
-[selecting-models]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#select-an-llm
diff --git a/docs/pt-br/cli/8-create-pull-request.md b/docs/pt-br/cli/8-create-pull-request.md
new file mode 100644
index 00000000..e4cbd7f1
--- /dev/null
+++ b/docs/pt-br/cli/8-create-pull-request.md
@@ -0,0 +1,99 @@
+---
+title: "Lição 8 - Criar e integrar o PR do recurso"
+description: "Revise todo o marco de filtragem, reutilize as evidências atuais de QA e integre o terceiro pull request após a CI e a revisão."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Agora reúna o marco de filtragem no PR 3. Permaneça na branch e na cópia de trabalho usadas nas Lições 4–7. Elas contêm a implementação de filtragem, a skill quality-checks e seus scripts, o perfil de QA e os testes associados.
+
+Esta é uma solicitação normal de PR com escopo delimitado que usa as convenções do repositório. Ela não exige uma skill de contribuição.
+
+> [!NOTE]
+> Uma equipe de produção poderia separar um recurso da infraestrutura de qualidade reutilizável. Este workshop os combina deliberadamente para mostrar o fluxo completo em um único PR de recurso. Os PRs anteriores de avaliações por estrelas e instruções já devem estar integrados em `main`, não aparecer novamente como trabalho não relacionado.
+
+## Verificar prontidão e evidências
+
+1. Revise o parecer de QA e o mapeamento entre requisitos e evidências. Um **NO-GO**, evidências de navegador ausentes ou uma verificação obrigatória ignorada é um bloqueio a resolver antes do merge.
+2. Confirme que as quatro verificações realmente foram executadas pela skill quality-checks: lint, testes de unidade, E2E e verificações de tipos.
+3. Revise a revisão testada e quaisquer alterações posteriores às verificações. Reutilize as evidências atuais de QA apenas enquanto o código testado, os testes e os scripts de verificação permanecerem inalterados. Um commit de checkpoint por si só não invalida conteúdos idênticos dos arquivos, mas alterações de código invalidam.
+4. Se a implementação ou as entradas testadas mudaram, execute novamente as verificações relevantes da skill e as observações no navegador e atualize as evidências. Não repita toda a suíte apenas porque está abrindo um PR quando os resultados atuais de QA ainda se aplicam.
+5. Examine o diff completo da branch, não apenas o último checkpoint ou as alterações sem commit.
+
+Em outro terminal na mesma cópia de trabalho:
+
+```bash
+git status
+git fetch origin
+git log --oneline origin/main..HEAD
+git diff --stat origin/main...HEAD
+git --no-pager diff origin/main...HEAD
+```
+
+A comparação com três pontos mostra as alterações desta branch desde o ancestral comum com `origin/main`, incluindo checkpoints anteriores. Verifique se inclui apenas o marco de filtragem pretendido. Examine também os arquivos novos; arquivos inesperados não rastreados ou sem commit precisam ser revisados antes de adicioná-los à área de preparação.
+
+## Solicitar o PR 3
+
+A Lição 7 retornou você a uma sessão **Interactive** normal antes do checkpoint. Continue nessa sessão estabelecida se o perfil de QA não estiver mais ativo e a cópia de trabalho e a branch de filtragem estiverem inalteradas. Mantenha disponíveis a URL da issue, os esclarecimentos aprovados no planejamento e o relatório atual de QA, incluindo a revisão testada e os resultados das verificações.
+
+O perfil de QA proíbe ações de commit e PR durante QA. Se ele ainda estiver ativo, volte a uma sessão normal antes de solicitar o PR:
+
+1. Aguarde QA ficar ocioso e digite `/exit` no prompt da CLI. Se a CLI continuar aberta porque outra sessão está ativa, conclua ou preserve esse trabalho antes de voltar ao prompt normal e pressionar Ctrl+D para encerrar esta instância da CLI.
+2. No prompt do shell, permaneça na mesma cópia de trabalho e branch de filtragem. Confirme sua identidade e inicie uma sessão normal nova sem `--agent qa` nem uma opção de retomada:
+
+ ```bash
+ pwd
+ git branch --show-current
+ git status
+ copilot
+ ```
+
+3. Confirme que você está no modo **Interactive** e que o perfil de QA não está mais ativo. Não crie outro worktree, não mude de branch nem retome a sessão de QA.
+
+Substitua todos os marcadores abaixo pela URL real da issue, os esclarecimentos aprovados e as evidências atuais de QA. Forneça-os explicitamente mesmo se tiver permanecido na sessão normal da Lição 7; uma conversa nova não deve depender da memória da sessão de QA.
+
+```plaintext
+Prepare o PR do recurso de filtragem para esta issue: . Estes são os critérios de aceitação adicionais que aprovei durante o planejamento: . Estas são as evidências atuais de QA: .
+
+Confirme a cópia de trabalho e a branch de filtragem atual. Examine o diff completo em relação a main, todos os commits de checkpoint do marco, git status, o modelo de PR do repositório e as evidências de QA fornecidas. Inclua apenas a implementação de filtragem revisada, a skill quality-checks e os scripts incluídos, a definição do agente de QA e os testes associados.
+
+Reutilize os resultados de QA enquanto eles ainda descreverem o conteúdo final dos arquivos. Se código, testes ou scripts de verificação mudaram depois, relate isso e execute as verificações relevantes pela skill e a validação de navegador afetada antes de apresentá-los como atuais. Não rotule verificações com falha, bloqueadas ou ignoradas como aprovadas.
+
+Faça commit de quaisquer alterações revisadas restantes do marco, se necessário, envie esta branch atual e crie um único PR para main seguindo as convenções do repositório. Inclua a issue e os critérios aprovados, o resumo da implementação, os testes adicionados ou por que nenhum foi necessário, as observações no navegador, os resultados das quatro verificações e as limitações restantes. Não faça o merge, não crie outra branch, não invoque uma skill de contribuição nem comece outro recurso.
+```
+
+## Revisar o PR e a CI
+
+Abra a URL retornada e examine **Files changed** em todo o PR. Verifique se os scripts da skill e o perfil de QA estão incluídos e se nenhuma credencial, configuração local do MCP, arquivo não relacionado, relatório gerado ou instalação de dependência entrou no diff.
+
+Use a aba **Checks** do PR ou execute estes comandos no terminal na branch do recurso:
+
+```bash
+gh pr view
+gh pr diff
+gh pr checks --watch
+```
+
+Examine `.github/workflows/` no seu repositório em vez de presumir que um indicador verde cobre todos os tipos de verificação. O fluxo atual **Run tests** do Tailspin executa lint, verificações de tipos, testes de unidade do Vitest e testes E2E do Playwright contra o site estático compilado. Ele não substitui as observações diretas no navegador via MCP do relatório de QA. A compilação Astro e as verificações de links do site do workshop validam outro repositório.
+
+Se uma verificação falhar, examine os logs e resolva a causa. Uma correção específica precisa ser revisada e verificada novamente na revisão atualizada antes do push. Se `main` mudar e a resolução de um conflito alterar o recurso, atualize também as evidências afetadas. Aguarde qualquer revisão humana obrigatória; a aprovação do próprio agente não substitui a proteção de branch.
+
+## Integrar e atualizar o main local
+
+Quando o PR atender a todos os requisitos de revisão e verificação, escolha explicitamente **Merge pull request** no GitHub e confirme o merge. Verifique se o PR 3 está **Merged**.
+
+Saia da sessão da CLI com `/exit`. Com a árvore de trabalho limpa, atualize a cópia local:
+
+```bash
+git status
+git switch main
+git pull --ff-only
+```
+
+Não é necessária uma branch nova para a próxima lição. Você integrou exatamente três PRs do workshop: avaliações por estrelas; instruções e uma demonstração; e filtragem com a skill de qualidade, o perfil de QA e os testes.
+
+Continue na [Lição 9 - Explorar comandos de barra e opções da CLI][next-lesson] para um percurso delimitado pelos controles da CLI, não outra tarefa de implementação.
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-slash-commands/
diff --git a/docs/pt-br/cli/8-review.md b/docs/pt-br/cli/8-review.md
deleted file mode 100644
index fe6450da..00000000
--- a/docs/pt-br/cli/8-review.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: "Lição 8 - Revisão e próximos passos"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-Ao longo das últimas lições, você explorou alguns dos casos de uso mais comuns do GitHub Copilot CLI, incluindo:
-
-- interagir com o GitHub e outros servidores MCP.
-- usar arquivos de instruções para orientar a geração de código.
-- implementar skills para adicionar ferramentas ao conjunto de recursos do Copilot CLI.
-- chamar agentes personalizados para tarefas avançadas e mais complexas.
-- usar comandos de barra para gerenciar sua sessão e, opcionalmente, voltar ao agente de nuvem por meio de `/delegate`.
-
-Vamos falar sobre alguns comandos de barra, boas práticas e próximos passos.
-
-## Comandos de barra
-
-O Copilot CLI oferece uma série de comandos de barra para interação, inclusive aqueles que permitem configurá-lo ou ver o que acontece nos bastidores. Você já usou `/clear` para iniciar um novo chat, limpando o contexto atual, e `/mcp` para inspecionar e gerenciar servidores MCP. Alguns outros que podem ser úteis são:
-
-| Comando | Descrição |
-| ------------------ | ------------------------------------------------------------- |
-| `/add-dir` | Adicionar um diretório à lista de confiança do Copilot |
-| `/clear`, `/new` | Limpar o histórico da conversa e começar de novo |
-| `/compact` | Resumir o histórico da conversa para reduzir o uso da janela de contexto |
-| `/context` | Mostrar o uso de tokens da janela de contexto e sua visualização |
-| `/diff` | Revisar as alterações feitas no diretório atual |
-| `/model` | Selecionar o modelo de IA a usar (Claude Sonnet, GPT-5 etc.) |
-| `/plan ` | Criar um plano de implementação antes de programar |
-| `/review ` | Executar o agente de revisão de código para analisar alterações |
-| `/delegate` | Delegar a tarefa ao agente de nuvem do Copilot para processamento assíncrono |
-| `/session` | Mostrar informações da sessão e um resumo do workspace |
-| `/share` | Compartilhar a sessão em um arquivo markdown ou em uma GitHub gist |
-| `/skills` | Gerenciar skills para ampliar recursos |
-| `/usage` | Exibir métricas e estatísticas de uso da sessão |
-
-> [!TIP]
-> Use `/help` para ver a lista completa de comandos disponíveis e atalhos de teclado.
-
-## Boas práticas
-
-Ao usar qualquer ferramenta de IA, a infraestrutura por trás dela influencia a qualidade do que você recebe. Arquivos de instruções robustos, agentes personalizados e skills de agente fazem parte dessa base — e você explorou cada um deles neste workshop. O [awesome-copilot][awesome-copilot] é uma boa fonte de modelos, e o próprio Copilot pode gerar essas estruturas para você como ponto de partida.
-
-O contexto continua sendo tão importante quanto a infraestrutura. Descrever com clareza *o que* você quer criar, *por que* e *como* muda significativamente a saída. Se alguma informação puder ajudar o Copilot, forneça-a.
-
-## Próximos passos
-
-A melhor forma de melhorar suas habilidades com qualquer ferramenta é continuar usando essa ferramenta. Use-a em código de produção, em projetos pessoais, naquele pequeno aplicativo em que você pensa há anos mas nunca parou para criar. Compartilhe seus aprendizados com a equipe e aprenda com ela. E, como sempre, explore a documentação.
-
-Se quiser explorar mais do ecossistema do GitHub Copilot, confira o [percurso do VS Code](../../vscode/) ou o [percurso do agente de nuvem](../../cloud/).
-
-## Recursos
-
-- [Sobre o Copilot CLI][about-copilot-cli]
-- [Usar o Copilot CLI][using-copilot-cli]
-- [Repositório Awesome Copilot][awesome-copilot]
-- [Guia de instruções personalizadas][repo-instructions]
-- [Documentação de Agent Skills][agent-skills]
-- [Documentação de agentes personalizados][custom-agents]
-- [Especificação do MCP][mcp-spec]
-
-[previous-lesson]: ../7-slash-commands/
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[repo-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
-[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[mcp-spec]: https://modelcontextprotocol.io/
diff --git a/docs/pt-br/cli/9-slash-commands.md b/docs/pt-br/cli/9-slash-commands.md
new file mode 100644
index 00000000..83af517b
--- /dev/null
+++ b/docs/pt-br/cli/9-slash-commands.md
@@ -0,0 +1,88 @@
+---
+title: "Lição 9 - Explorar comandos de barra e opções da CLI"
+description: "Examine contexto e controles de modelo e sessão, revise destinos de compartilhamento e explore opções da CLI sem iniciar outro recurso."
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+Os três marcos de PR estão completos. Agora explore os controles da CLI que ajudam a entender e gerenciar uma sessão. Esta lição não implementa outro recurso, não delega trabalho nem abre outro PR.
+
+Na cópia de trabalho atualizada do participante, inicie `copilot` no modo **Interactive**. Use `/help` e a [referência de comandos][cli-reference] para confirmar quais comandos a versão instalada suporta; a documentação atual pode descrever controles mais novos do que a sua instalação.
+
+## Examinar contexto e informações da sessão
+
+1. Envie uma solicitação delimitada, somente de leitura:
+
+ ```plaintext
+ Resuma os arquivos de instruções do repositório, a skill quality-checks e o perfil de QA. Explique como eles apoiam a verificação da filtragem. Não modifique arquivos, não execute verificações, não delegue trabalho, não faça commit nem abra um PR.
+ ```
+
+2. Digite `/context` para examinar o uso da janela de contexto. Observe como mensagens, instruções e definições de ferramentas consomem contexto.
+3. Digite `/compact` e depois `/context` novamente. A compactação resume o histórico para reduzir seu tamanho; uma sessão curta pode mostrar pouca mudança.
+4. Digite `/session` para examinar a sessão atual e `/usage` para consultar informações de uso.
+
+A compactação não substitui o fornecimento de requisitos. Ao mudar de tarefa ou agente, forneça explicitamente a URL da issue, os critérios aprovados, a identidade da cópia de trabalho e as evidências relevantes.
+
+`/clear` inicia uma conversa nova; não desfaz arquivos nem muda de branch Git. `/resume` abre o seletor de sessões para retornar a trabalhos anteriores. Explore o seletor e pressione Esc para sair sem retomar outra tarefa. Não apague a única cópia dos critérios de aceitação nem presuma que retomar uma conversa significa que sua verificação antiga ainda está atualizada.
+
+## Examinar modelos e modos
+
+Digite `/model` para examinar os modelos disponíveis para sua conta, incluindo **Auto** onde for oferecido. Leia os detalhes de seleção e as informações de uso; a disponibilidade e os preços dos modelos podem mudar. Pressione Esc para sair do seletor sem mudar o modelo. Se você o alterar, confirme a seleção exibida e o escopo que sua versão da CLI aplica.
+
+Use Shift+Tab para examinar o indicador de modo ao alternar entre **Interactive**, **Plan** e **Autopilot** e volte a **Interactive** sem enviar um prompt de implementação. Lembre-se da distinção:
+
+- Plan serve para acordar o trabalho antes de programar.
+- Autopilot continua uma tarefa aprovada e delimitada.
+- Interactive oferece pontos deliberados de revisão e decisão.
+- As permissões controlam separadamente quais ações de ferramentas são permitidas.
+
+## Examinar opções de linha de comando
+
+Em outro terminal, execute:
+
+```bash
+copilot --help
+```
+
+Compare estas opções documentadas com a ajuda da versão instalada:
+
+| Opção | Finalidade |
+| --- | --- |
+| `--model MODEL` | Escolher o modelo para uma invocação; confirme a disponibilidade primeiro |
+| `--agent AGENT` | Selecionar um agente personalizado para uma invocação |
+| `-p PROMPT` | Executar um prompt programaticamente e sair quando ele terminar |
+| `--output-format json` | Emitir saída JSONL estruturada, um objeto JSON por linha |
+| `--resume` | Retomar uma sessão existente |
+| `--enable-all-github-mcp-tools` | Expor o conjunto completo de ferramentas MCP do GitHub integradas |
+
+São controles para entender, não outra tarefa para iniciar. O modo programático pode executar ações reais de ferramentas; um formato de saída JSON não torna uma solicitação somente de leitura. A seleção de agente segue o fluxo verificado da [Lição 7][qa-lesson], não é motivo para substituir a ativação do agente personalizado por um pedido ao agente padrão para ler o perfil. As permissões e o acesso continuam se aplicando.
+
+## Revisar antes de compartilhar
+
+`/share` pode enviar o conteúdo da sessão a diferentes destinos. A [referência de comandos da CLI][cli-reference] documenta `/share file [session|research] [PATH]` para exportação Markdown e `/share gist [session|research]` para publicar gists. Sem subcomando, o comportamento documentado atualmente cria um link compartilhável do GitHub quando você está conectado e sincronizado e recorre à exportação Markdown caso contrário. Não execute o comando sem argumentos presumindo que ele apenas exibe uma prévia.
+
+Neste workshop, selecione explicitamente uma exportação local da sessão e um nome de arquivo em vez de publicar:
+
+```text
+/share file session cli-session-review.md
+```
+
+Abra o arquivo exportado no editor e examine o que ele realmente contém. Revise prompts, respostas, saída de ferramentas, caminhos de arquivos, dados do repositório e quaisquer credenciais ou informações pessoais. Não presuma que a exportação contém todos os passos internos ou que removeu automaticamente o conteúdo sensível.
+
+> [!CAUTION]
+> Um gist ou link compartilhado é uma divulgação externa. Um gist secreto não é controle de acesso privado: qualquer pessoa com sua URL pode vê-lo. Confirme o destino, os destinatários, as permissões e a política da organização antes de compartilhar. Se precisar ocultar informações, compartilhe apenas o arquivo revisado e sanitizado por um canal aprovado; não publique a sessão original depois.
+
+Mantenha essa exportação fora do PR do recurso e do histórico do repositório. Após examiná-la, remova o arquivo que acabou de gerar ou mova-o para seu local aprovado de notas locais. Não remova arquivos não relacionados.
+
+A delegação para a nuvem pode criar trabalho remoto e um PR adicional, então não execute `/delegate` aqui. O [workshop do agente de nuvem][cloud-workshop] cobre esse fluxo separado.
+
+## Resumo e próximos passos
+
+Você examinou contexto, uso, controles de modelos e modos, opções de linha de comando e destinos de compartilhamento sem iniciar outro recurso. Continue na [Lição 10 - Revisão e próximos passos][next-lesson] para revisar o fluxo e os ativos que criou.
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[qa-lesson]: ../7-qa-agent/
+[cloud-workshop]: ../../cloud/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/pt-br/cli/README.md b/docs/pt-br/cli/README.md
index 0844114e..3733fc89 100644
--- a/docs/pt-br/cli/README.md
+++ b/docs/pt-br/cli/README.md
@@ -3,12 +3,12 @@ slug: pt-br/cli
title: "CLI do GitHub Copilot"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
O **[GitHub Copilot CLI](https://docs.github.com/copilot/concepts/agents/about-copilot-cli)** coloca o GitHub Copilot no seu terminal como um assistente de programação baseado em agentes. Ele explora bases de código, gera código, executa comandos e se conecta a ferramentas externas — tudo pela linha de comando, para que você mantenha o foco sem trocar para um editor gráfico.
-Ao longo destas lições, você instalará e autenticará o Copilot CLI, depois fornecerá contexto do projeto com instruções personalizadas antes de usar o modo plan para gerar um recurso de forma deliberada. Você conectará o servidor MCP do Playwright para testar esse recurso em um navegador real e, em seguida, ampliará o Copilot com skills de agente reutilizáveis e agentes personalizados. Por fim, você explorará comandos de barra para gerenciar contexto, modelos e compartilhamento, e concluirá com uma revisão do que criou.
+Após a configuração nas Lições 0–1, você concluirá nove módulos principais nas Lições 2–10. Comece com uma melhoria rápida de avaliações por estrelas, estabeleça instruções de documentação e crie a filtragem com os modos **Plan** e **Autopilot**. Depois, crie uma skill quality-checks reutilizável, valide o comportamento com o MCP do Playwright, crie um agente de QA e entregue o recurso. Termine explorando os controles da CLI e revisando o que criou.
## Lições
@@ -16,13 +16,21 @@ Ao longo destas lições, você instalará e autenticará o Copilot CLI, depois
|----------|-------|-------------|
| [0. Pré-requisitos][ex0] | Configuração | Crie seu repositório e seu codespace |
| [1. Instalar o Copilot CLI][ex1] | Instalação | Instale e autentique o Copilot CLI |
-| [2. Instruções personalizadas][ex2] | Contexto | Adicione uma instrução e veja como o Copilot CLI a segue |
-| [3. Geração de código][ex3] | Geração de código | Use o modo plan e gere recursos |
-| [4. Testar com o MCP do Playwright][ex4] | Ferramentas externas | Adicione o servidor MCP do Playwright e teste seu recurso em um navegador |
-| [5. Skills de agente][ex5] | Skills | Aprimore o Copilot com skills especializadas |
-| [6. Agentes personalizados][ex6] | Agentes | Revise e use agentes personalizados |
-| [7. Comandos de barra][ex7] | Recursos da CLI | Explore contexto, modelos, compartilhamento e a delegação opcional para o agente de nuvem |
-| [8. Revisão][ex8] | Resumo | Revise os principais conceitos e os próximos passos |
+| [2. Adicionar avaliações por estrelas: uma melhoria rápida][ex2] | Primeira alteração | Exiba avaliações existentes, valide e integre o PR 1 |
+| [3. Orientar o Copilot com instruções personalizadas][ex3] | Contexto | Adicione uma convenção de documentação, demonstre-a e integre o PR 2 |
+| [4. Criar a filtragem com Plan e Autopilot][ex4] | Implementação | Revise um plano, aprove o Autopilot, teste e salve um checkpoint |
+| [5. Criar e usar uma skill quality-checks][ex5] | Skills | Gere, examine e execute verificações com scripts de shell incluídos |
+| [6. Validar a funcionalidade com o MCP do Playwright][ex6] | Ferramentas de navegador | Observe o comportamento de filtragem em um navegador real |
+| [7. Criar e usar um agente de QA][ex7] | Agentes | Audite requisitos e cobertura e reúna as evidências finais |
+| [8. Criar e integrar o PR do recurso][ex8] | Entrega | Revise a filtragem e as personalizações reutilizáveis juntas no PR 3 |
+| [9. Explorar comandos de barra e opções da CLI][ex9] | Controles da CLI | Examine contexto, modelos, sessões e destinos de compartilhamento |
+| [10. Revisão e próximos passos][ex10] | Resumo | Revise os ativos comuns e os três marcos de PR |
+
+## Branches e pull requests
+
+Você integrará três pull requests: avaliações por estrelas; instruções e uma pequena demonstração; e filtragem com a skill quality-checks, o perfil de QA e os testes associados. Integre cada um dos dois primeiros PRs antes de iniciar o próximo marco a partir de `main` atualizado.
+
+As Lições 4–8 compartilham uma branch de recurso e uma cópia de trabalho. Salve commits de checkpoint ao longo do caminho; criar a skill, configurar o MCP e selecionar QA não inicia novas branches de recurso. A Lição 9 explora os controles sem iniciar outro recurso ou PR.
## Pré-requisitos
@@ -44,11 +52,13 @@ Antes de participar deste workshop, verifique se você tem:
[ex0]: 0-prerequisites/
[ex1]: 1-install-copilot-cli/
-[ex2]: 2-custom-instructions/
-[ex3]: 3-generating-code/
-[ex4]: 4-mcp/
+[ex2]: 2-add-star-rating/
+[ex3]: 3-custom-instructions/
+[ex4]: 4-build-filtering/
[ex5]: 5-agent-skills/
-[ex6]: 6-custom-agents/
-[ex7]: 7-slash-commands/
-[ex8]: 8-review/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-slash-commands/
+[ex10]: 10-review/
[callout-student-plan-education]: https://github.com/education/students
diff --git a/docs/vscode/4-custom-agents.md b/docs/vscode/4-custom-agents.md
index 7a762452..a824fb74 100644
--- a/docs/vscode/4-custom-agents.md
+++ b/docs/vscode/4-custom-agents.md
@@ -9,13 +9,13 @@ lastUpdated: 2026-06-30
[Custom agents][custom-agents-concept] in GitHub Copilot allow you to create specialized AI assistants tailored to specific tasks or domains within your development workflow. By defining agents through markdown files in the `.github/agents` folder of your repository, you can provide Copilot with focused instructions, best practices, coding patterns, and domain-specific knowledge that guide it to perform particular types of work more effectively. Teams can codify their expertise into reusable agents — an accessibility agent that enforces [WCAG][wcag] compliance, a security agent that follows secure coding practices, or a testing agent that maintains consistent test patterns.
-Custom agents are defined by markdown files in the `.github/agents` folder of your project, or globally in `~/.copilot/agents`. Each file has YAML frontmatter with at least a `name` and `description`, followed by a markdown prompt that defines the agent's behavior, expertise, and instructions.
+Custom agents are defined by `.agent.md` files in the `.github/agents` folder of your project. Each file has YAML frontmatter with a required `description`, followed by a Markdown prompt that defines the agent's behavior, expertise, and instructions. This exercise also supplies an optional, readable `name` so you can recognize the agent in the picker.
### Custom agents compared with agent skills
-There's some logical overlap between custom agents and [agent skills][agent-skills-concept]. Both are primarily defined with markdown files and tell an AI how to perform operations. The cleanest way to separate them: a **custom agent** is the worker, and **skills** are tools.
+There's some logical overlap between custom agents and [agent skills][agent-skills-concept]. A **custom agent** defines a specialized role, instructions, and available tools. A **skill** packages task-specific instructions and can include scripts and supporting resources.
-Custom agents have their own context window and are built to orchestrate skills (and even other agents) as part of doing their work. In this lab, the accessibility custom agent reviews and updates the site against accessibility guidelines; as part of that work it could call skills such as a pull-request workflow skill or one that runs and manages tests.
+Agents can run scripts directly through available tools, or follow a skill when one is available. Selecting a custom agent does not inherently create a separate context window or require orchestration of other agents. In this lab, you'll create an accessibility profile and use the project's existing npm checks directly; no skill from another workshop harness is required.
> [!NOTE]
> There's no single "right" way to author a custom agent. As with anything in AI, test and iterate to find what works for your environments and scenarios.
@@ -30,12 +30,12 @@ Tailspin Toys is committed to ensuring their crowdfunding platform is accessible
Because accessibility is critical, you want to ensure this is implemented as quickly as possible. You're going to utilize a custom agent to generate the functionality.
In this exercise, you will:
-- review an existing accessibility custom agent.
+- create and review an accessibility custom agent.
- use the accessibility agent in Copilot Chat to implement a high-contrast mode.
-## Reviewing the accessibility custom agent
+## Creating and reviewing the accessibility custom agent
-A custom agent has already been created for you for accessibility. Let's review the contents to understand how it will guide Copilot.
+The template does not supply custom agents or skills. You'll generate an accessibility profile, review its instructions, then select it for the implementation task.
Return to your codespace, then open a terminal and switch to a fresh branch off `main` for the accessibility work (you'll keep the filtering PR from Exercise 3 separate):
@@ -45,34 +45,44 @@ git pull
git checkout -b accessibility-vscode
```
-1. Open `.github/agents/accessibility.md`.
-2. Note the YAML frontmatter with the `name` and `description` fields.
+1. Open Copilot Chat and select the built-in **Agent** from the agents dropdown.
+2. Send this creation prompt:
-> [!CAUTION]
-> The frontmatter with `name` and `description` is required for custom agents.
+ ```plaintext
+ Create an accessibility custom agent at .github/agents/accessibility.agent.md. Inspect the repository instructions, package.json, existing components, styles, and tests first. Give it valid YAML frontmatter with name: Accessibility agent and a description explaining when to use it. Omit model and tools so it uses the selected model and available tools.
+
+ Write reusable instructions for implementing and reviewing accessible Astro UI changes: semantic HTML, keyboard access, visible focus, accessible control names and states, and WCAG contrast guidance. Follow the user's requirements and repository conventions, make focused changes, and add or update relevant tests. Require direct execution of npm run lint, npm run test:unit, npm run test:e2e, and npm run typecheck:all, with accurate pass/fail/blocked results and explicit reporting of any browser checks not performed. Do not depend on supplied agents or skills. Ask before installing dependencies or stopping an existing server.
+
+ Create only this profile and stop for my review. Do not implement high-contrast mode yet, change branches, commit, push, or create a pull request.
+ ```
+
+3. Open `.github/agents/accessibility.agent.md` and review its YAML and instructions. Confirm the `description` explains its purpose and the `name` is `Accessibility agent`. Check that it covers the accessibility practices and direct npm checks requested above, without adding unrelated workflows.
+4. Review and save any necessary corrections before continuing. Keep this profile and the upcoming feature changes on `accessibility-vscode`.
+
+> [!NOTE]
+> `description` is required; `name` is optional, but intentionally provided here. Omitting `tools` allows the available tools rather than restricting them; your normal tool permissions still apply.
-3. From there, scan and review the next sections which highlight:
- - Core responsibilities when generating code for an accessible website.
- - Best practices for accessibility.
- - Code examples for HTML, CSS, and JavaScript.
- - A list of common pitfalls and mistakes.
## Using the custom agent in Copilot Chat
-VS Code surfaces every custom agent defined in `.github/agents` in the agents dropdown at the bottom of the Copilot Chat view. You can select a custom agent to scope a chat session to that agent's instructions and tooling.
+VS Code discovers workspace custom agents in `.github/agents`. Use the agents dropdown in Copilot Chat to select the saved profile, as described in the [VS Code custom-agent documentation][custom-agents-vscode].
> [!TIP]
> **Open Copilot Chat**
>
> Before you start the exercises below, return to your codespace, open the Copilot Chat panel, and select **New Chat** to start a clean conversation. Mode and model selection vary per exercise — each step calls those out where it matters.
-1. Select **Agent** from the agents dropdown in the Chat view if it isn't already selected.
+
+1. Stay in the same codespace and on `accessibility-vscode`; do not create another branch for agent selection.
-2. Select the agents dropdown at the bottom of the chat view (it shows the active agent — by default, this is **default**).
-3. Select **Accessibility agent** from the list of available agents.
+2. Open the agents dropdown in the Chat view.
+3. Select **Accessibility agent** and confirm that the picker now shows it as the active agent before sending the task.
+
+ If it is missing, confirm the file is saved in this workspace at `.github/agents/accessibility.agent.md`, review its frontmatter, and check **Configure Custom Agents** in the dropdown. Do not continue until you can select it. Asking the default agent to read the file does not activate the custom agent.
+
4. Send the following prompt to the accessibility agent:
- ```
+ ```plaintext
Add a high-contrast mode to the site. There should be a toggle for high contrast which the user can set, and the setting should persist across page reloads using local storage on the browser.
```
@@ -90,7 +100,7 @@ This lesson explored [custom agents][custom-agents] in GitHub Copilot, specializ
You explored these concepts:
-- how custom agents are defined.
+- creating and reviewing a custom-agent profile.
- using a custom agent in Copilot Chat agent mode.
Next, you'll [monitor and steer the agent's work][next-lesson] — reviewing the changes as they happen and adding a light-mode toggle to the same session.
@@ -112,6 +122,6 @@ Next, you'll [monitor and steer the agent's work][next-lesson] — reviewing the
[next-lesson]: ../5-managing-agents/
[custom-agents]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
[creating-custom-agents-ide]: https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/create-custom-agents-in-your-ide
-[custom-agents-vscode]: https://code.visualstudio.com/docs/copilot/customization/custom-agents
+[custom-agents-vscode]: https://code.visualstudio.com/docs/agent-customization/custom-agents
[custom-agents-config]: https://docs.github.com/copilot/reference/custom-agents-configuration
[awesome-copilot-agents]: https://github.com/github/awesome-copilot/tree/main/agents
diff --git a/docs/vscode/5-managing-agents.md b/docs/vscode/5-managing-agents.md
index 0af014e6..616a4430 100644
--- a/docs/vscode/5-managing-agents.md
+++ b/docs/vscode/5-managing-agents.md
@@ -55,9 +55,10 @@ Now that high-contrast mode is in place, you'll extend the same conversation to
Before committing the work, take a quick pass over everything the agent touched.
1. Open the **Source Control** view in VS Code.
-2. Review the full list of changed files. You should see updates to the Astro components, styles, and any related tests.
+2. Review the full list of changed files. You should see the new `.github/agents/accessibility.agent.md` profile alongside updates to the Astro components, styles, and any related tests.
3. Open a couple of the changed files and walk through the diffs. Confirm the accessibility patterns from the custom agent are reflected — ARIA attributes, keyboard navigation, semantic HTML, and persistence via local storage.
-4. When you're satisfied, stage and commit the changes from the Source Control panel. You'll publish them in [the next lesson][next-lesson].
+4. Have the agent run `npm run lint`, `npm run test:unit`, `npm run test:e2e`, and `npm run typecheck:all` directly, then review the tool output and resolve failures or missing prerequisites. No skill from the CLI or App harness is required.
+5. When you're satisfied with the changes and verification, stage and commit the profile and feature changes on the same `accessibility-vscode` branch from the Source Control panel. You'll publish them in [the next lesson][next-lesson].
## Summary and next steps
diff --git a/docs/vscode/6-iterating.md b/docs/vscode/6-iterating.md
index edb501d4..36c49efc 100644
--- a/docs/vscode/6-iterating.md
+++ b/docs/vscode/6-iterating.md
@@ -21,7 +21,7 @@ The high-contrast and light-mode toggles you implemented with the accessibility
1. Return to your codespace.
2. Open the **Source Control** view in VS Code.
-3. Confirm your accessibility changes are committed. If you have uncommitted changes from Exercise 5, stage and commit them now with a descriptive message such as `Add high-contrast and light-mode toggles`.
+3. Confirm your accessibility changes and `.github/agents/accessibility.agent.md` are committed on `accessibility-vscode`. If you have uncommitted changes from Exercise 5, verify them with the existing npm checks, then stage and commit them with a descriptive message such as `Add high-contrast and light-mode toggles`.
4. Publish the branch by selecting **Publish Branch** (or use the **...** menu → **Push**).
5. VS Code will offer to open the new branch on github.com. Accept the prompt, or navigate to your repository manually and select **Compare & pull request** on the branch banner.
6. Set a clear title (for example, `Add high-contrast and light-mode toggles`) and a short description summarizing what was done and why.
@@ -57,7 +57,7 @@ Congratulations — you've completed the VS Code harness! Through this lab you:
- **Used Playwright MCP to manually test your feature.** You added the Playwright MCP server and let Copilot drive a browser to verify your filtering feature before opening a pull request.
- **Drove agent mode through coordinated changes across the stack.** You added a filter feature that touched the client, the server, and the tests in a single session.
-- **Used a custom agent.** You selected the accessibility-focused custom agent from the agent picker and watched it implement high-contrast mode against the repository.
+- **Created and used a custom agent.** You generated and reviewed the accessibility profile, selected it from the agent picker, and watched it implement high-contrast mode against the repository.
- **Managed and steered an agent session.** You reviewed proposed changes inline, accepted what you wanted, and extended the session with a light-mode follow-up.
- **Closed the loop with a pull request.** You published your local work and reviewed it end-to-end the way your team would.
diff --git a/docs/vscode/README.md b/docs/vscode/README.md
index 911eb0a1..a192fac9 100644
--- a/docs/vscode/README.md
+++ b/docs/vscode/README.md
@@ -8,7 +8,7 @@ lastUpdated: 2026-06-30
**[GitHub Copilot Chat](https://code.visualstudio.com/docs/copilot/chat/copilot-chat)** in VS Code brings GitHub Copilot into the code editor you already use. Working in Visual Studio Code (and GitHub Codespaces), you'll drive Copilot Chat in agent mode, connect external tools through MCP, and rely on custom agents — all without leaving your IDE, where Copilot has full view of your files, terminal, and problems.
-You'll start by adding custom instructions and watching Copilot follow them, then use agent mode to build a filtering feature across the UI, data layer, and tests. Next you'll connect the Playwright MCP server and let Copilot drive a browser to test your feature before opening a pull request. Finally, you'll review and use a custom agent for accessibility work, then monitor, steer, and iterate on Copilot's changes — all without leaving the editor.
+You'll start by adding custom instructions and watching Copilot follow them, then use agent mode to build a filtering feature across the UI, data layer, and tests. Next you'll connect the Playwright MCP server and let Copilot drive a browser to test your feature before opening a pull request. Finally, you'll create, review, and use a custom agent for accessibility work, then monitor, steer, and iterate on Copilot's changes — all without leaving the editor.
## Exercises
@@ -18,7 +18,7 @@ You'll start by adding custom instructions and watching Copilot follow them, the
| [1. Custom instructions][ex1] | Context | Add and verify custom instructions in VS Code |
| [2. Agent Mode][ex2] | Code Generation | Build a filtering feature with agent mode |
| [3. MCP with Playwright][ex3] | External Tools | Test your feature in a browser with the Playwright MCP server |
-| [4. Custom Agents][ex4] | Specialized Agents | Review and use custom agents |
+| [4. Custom Agents][ex4] | Specialized Agents | Create, review, and use a custom agent |
| [5. Managing Agents][ex5] | Monitoring | Monitor and steer agent sessions |
| [6. Iterating][ex6] | Review | Review Copilot's work locally and choose next steps |
diff --git a/docs/zh-cn/README.md b/docs/zh-cn/README.md
index d3fc1484..6768ade9 100644
--- a/docs/zh-cn/README.md
+++ b/docs/zh-cn/README.md
@@ -3,7 +3,7 @@ slug: zh-cn
title: "动手实践 GitHub Copilot 智能体"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
GitHub Copilot 最近新增的功能为开发人员提供了贯穿整个软件开发生命周期 (SDLC) 的强大工具，包括处理 GitHub 上的议题和拉取请求、与外部服务交互，当然也包括创建代码。本实验将探索这些功能，并通过实际用例和技巧，帮助你充分发挥这些工具的价值。
@@ -23,11 +23,11 @@ GitHub Copilot 最近新增的功能为开发人员提供了贯穿整个软件
### 💻 [Copilot CLI](cli/)
-**GitHub Copilot CLI** 是一款在终端中运行的智能体助手。安装后，可以连接 MCP 服务器、使用计划模式生成代码，还能完全通过命令行构建自己的技能、自定义智能体和斜杠命令。
+**GitHub Copilot CLI** 是一款在终端中运行的智能体助手。完成设置后，学习九个核心模块：添加星级评分快速上手，建立指令，规划并构建筛选功能，创建 quality-checks 技能，通过 Playwright MCP 验证，创建 QA 智能体，再合并功能。最后探索 CLI 控件并进行总结。整个流程有三个拉取请求里程碑。
### 🤖 [Copilot App](app/)
-**GitHub Copilot app** 是一款基于 Copilot CLI 构建的桌面应用。它支持并行运行智能体会话、切换会话模式、在画布上协作，以及直接管理 GitHub 议题和拉取请求。其中包括 **Agent Merge**，可引导拉取请求完成变基、处理审查反馈、修复 CI 问题并最终合并。
+**GitHub Copilot app** 是一款基于 Copilot CLI 构建的桌面应用。使用应用的隔离会话和 **Agent Merge**，按相同的设置和九个核心模块完成星级评分、指令、筛选功能、技能、MCP、QA 和功能 PR 工作流。创建并合并保存在存储库中的画布，完成第四个拉取请求里程碑，然后总结。
### ☁️ [Copilot Cloud Agent](../cloud/)
diff --git a/docs/zh-cn/app/0-prerequisites.md b/docs/zh-cn/app/0-prerequisites.md
index b23c75d0..33ccf52c 100644
--- a/docs/zh-cn/app/0-prerequisites.md
+++ b/docs/zh-cn/app/0-prerequisites.md
@@ -15,18 +15,18 @@ GitHub Copilot app 是一款桌面应用，作为 Copilot 和 GitHub 的中央
## 安装 Node.js
-多节课程会要求智能体构建功能，并在本地运行 Tailspin Toys 测试套件。这需要项目唯一依赖的运行时 [**Node.js**][nodejs]。请安装 **22 或更高版本**；当前的 **LTS** 版本是稳妥的选择。
+多节课程会要求智能体构建功能，并在本地运行 Tailspin Toys 测试套件。这需要 [**Node.js**][nodejs]。使用 **Node.js 22.13 或更高版本**，并查看当前检出项目的 `package.json` 和 README，确认支持的版本。
所有平台上最简单的方式都是使用官方安装程序：
1. 在操作系统中使用 Windows Terminal、macOS 终端或常用工具打开终端窗口。
-2. 运行以下命令，确认已安装 Node.js 22 或更高版本：
+2. 运行以下命令，确认已安装 Node.js 22.13 或更高版本：
```shell
node --version
```
-3. 如果看到 `v22` 或更高版本号，可以跳到下一节。
+3. 如果显示的版本至少为 `v22.13.0`，且项目支持该版本，可以跳到下一节。
> [!TIP]
> 仅当尚未安装 Node 或需要更新时，才需要完成以下步骤。
@@ -41,10 +41,10 @@ GitHub Copilot app 是一款桌面应用，作为 Copilot 和 GitHub 的中央
node --version
```
-9. 应会看到 `v22.x.x` 或更高版本。
+9. 确认显示的版本至少为 `v22.13.0`，且项目支持该版本。
-> [!TIP]
-> 更喜欢容器？如果已安装 [**Docker**][docker]，可以使用存储库的[开发容器][dev-containers]，无需在本地安装 Node.js。开发容器已包含 Node，两种方式无需同时使用。
+> [!IMPORTANT]
+> App 学习路径使用本地工作树。仅安装在容器中的运行时无法供这些本地会话使用。每个工作树还需要项目依赖项及用于 E2E 检查的 Playwright Chromium。准备工作树时，请遵循练习存储库的 README，并在批准前审查所有安装请求。
## 设置实验存储库
@@ -64,6 +64,8 @@ GitHub Copilot app 是一款桌面应用，作为 Copilot 和 GitHub 的中央
> [!NOTE]
> 通过模板创建存储库时，系统会自动创建一组 GitHub 议题作为待办事项。整个研讨会都会使用这些议题，无需自行创建。
+使用修订后模板的新副本：其中包含存储库指令、应用代码、测试和现有画布扩展，但不附带自定义智能体或技能。你将在研讨会中创建自己的 quality-checks 技能和 QA 配置文件。如果使用旧副本，应先检查现有自定义配置，而不是直接覆盖。
+
## 总结与后续步骤
准备工作已完成。你安装了 Node.js，因此可以在本机构建和测试项目；还通过模板创建了自己的 Tailspin Toys 存储库副本。
@@ -79,7 +81,5 @@ GitHub Copilot app 是一款桌面应用，作为 Copilot 和 GitHub 的中央
[next-lesson]: ../1-install-copilot-app/
[nodejs]: https://nodejs.org/
[node-download]: https://nodejs.org/en/download
-[docker]: https://www.docker.com/products/docker-desktop/
-[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
[template-repository]: https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-template-repository
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/zh-cn/app/1-install-copilot-app.md b/docs/zh-cn/app/1-install-copilot-app.md
index 0d9564e9..c524cd84 100644
--- a/docs/zh-cn/app/1-install-copilot-app.md
+++ b/docs/zh-cn/app/1-install-copilot-app.md
@@ -41,23 +41,23 @@ lastUpdated: 2026-07-09
连接项目后，花一点时间熟悉工作区。应用将功能组织在侧边栏的以下几个区域：
-- **Sessions**：智能体执行工作的区域。每个会话都在独立工作区中运行，因此可以同时运行多个会话，且更改不会发生冲突。下一课将启动第一个会话。
+- **Sessions**：智能体执行工作的区域。本研讨会请选择 **new working tree**，为每个 PR 里程碑提供隔离的检出目录和分支。应用还有其他工作区选项，但本研讨会不使用它们。
- **Quick chats**：适合提问和集思广益的轻量对话，无需单独创建分支或工作区。本课结束时会进行一次快速聊天。
- **My work**：通过应用的 **GitHub 原生集成**显示议题和拉取请求。在这里，无需离开应用即可浏览和筛选议题与拉取请求、检查 CI 状态、从议题启动会话以及审查拉取请求。
-- **Automations**：可按计划或按需运行的已保存智能体任务。本学习路径接近结束时会创建一个自动化任务。
+- **Customize**：发现和管理 MCP 服务器、技能及画布。你将使用它配置 Playwright MCP。
+- **Automations**：可按计划或按需运行的已保存智能体任务。总结课程会将其作为后续方向提供链接，而不再添加研讨会练习。
### 查找模板创建的待办事项
由于应用与 GitHub 原生集成，存储库中待处理的工作会直接显示在应用内。通过模板创建存储库时，系统已生成一组议题。现在确认它们是否存在。
1. 在侧边栏中选择 **My work**。
-2. 模板在待办列表中创建了八个议题。本课程聚焦以下三个，确认它们可见：
+2. 按标题查找以下议题，不要假设议题编号：
- Allow users to filter games by category and publisher
- Update our repository coding standards
- - Implement pagination on the game list page
-3. 选择一个议题以阅读详细信息。每个议题也可以作为智能体会话的启动点，后续课程会从这些议题开始工作。
+3. 选择一个议题以阅读详细信息。每个议题也可以作为智能体会话的启动点，后续课程会从这些议题开始工作。其他待办议题用于为画布提供上下文，而不是另一项实现任务。
> [!NOTE]
> My work 中的项目会自动筛选，仅显示已添加到 Copilot app 的存储库中的项目。要查看其他存储库中的工作项，请将相应存储库添加到应用。
@@ -70,7 +70,7 @@ lastUpdated: 2026-07-09
2. 询问应用自身的会话工作方式：
```plaintext
- How does the GitHub Copilot app use worktrees?
+ GitHub Copilot app 如何使用工作树？
```
3. 在对话视图中阅读回复。每个会话都在独立的 git 工作树中运行，因此可以并行运行多个智能体，而不会造成更改冲突。你可以随时继续对话或开始新聊天。
@@ -84,7 +84,13 @@ lastUpdated: 2026-07-09
- 熟悉工作区，并在 **My work** 中找到模板创建的待办事项。
- 使用快速聊天提出一次性问题。
-接下来，你将启动第一个智能体会话，并对项目进行第一次更改，即在游戏卡片上显示星级评分。继续学习[第 2 课 - 运行第一个智能体会话][next-lesson]。
+## 分开管理 PR 里程碑
+
+你将合并四个 PR：星级评分；指令及小型示例改动；筛选功能及技能、QA 配置文件和测试；最后是分类画布。每个 PR 里程碑使用一个分支。第 4–8 课沿用同一筛选会话、工作树和分支，以检查点提交保存进度，而不额外创建 PR。
+
+新的 App 工作树可能从过时的本地状态开始。每个新里程碑在编辑文件前，都应获取存储库更新，并将新会话分支快进到最新的 `origin/main`。后续课程会明确展示这些步骤。不要堆叠分支、挑选之前的提交，也不要将进行中的筛选会话切换到其他分支。
+
+接下来，你将启动第一个智能体会话，并对项目进行第一次更改，即在游戏卡片上显示星级评分。继续学习[第 2 课 - 添加星级评分：快速上手][next-lesson]。
## 资源
@@ -92,7 +98,7 @@ lastUpdated: 2026-07-09
- [GitHub Copilot app 入门][getting-started]
- [在 GitHub Copilot app 中使用智能体会话][agent-sessions]
-[ex0]: ../0-prerequisites/
+[previous-lesson]: ../0-prerequisites/
[next-lesson]: ../2-add-star-rating/
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
diff --git a/docs/zh-cn/app/8-review.md b/docs/zh-cn/app/10-review.md
similarity index 50%
rename from docs/zh-cn/app/8-review.md
rename to docs/zh-cn/app/10-review.md
index c00c5c7b..8a753922 100644
--- a/docs/zh-cn/app/8-review.md
+++ b/docs/zh-cn/app/10-review.md
@@ -1,44 +1,43 @@
---
-title: "第 8 课 - 回顾与后续步骤"
-description: "回顾 GitHub Copilot app 学习路径，自动执行重复性工作，并探索后续方向。"
+title: "第 10 课 - 总结与后续步骤"
+description: "回顾 App 的九个核心模块、四个 PR 里程碑和可复用质量工作流，再探索更多资源。"
authors:
- geektrainer
-lastUpdated: 2026-07-09
+lastUpdated: 2026-09-11
---
在过去几节课程中，你使用 GitHub Copilot app 将一项功能从构想推进到合并，包括：
- 连接存储库，并熟悉应用工作区和模板创建的待办事项。
- 从直接任务和议题启动会话，并使用 Plan 和 Autopilot 模式控制智能体的工作方式。
-- 使用自定义指令和可复用技能引导智能体。
+- 使用自定义指令引导智能体，再让它创建包含 shell 脚本的可复用技能，审查并运行这些脚本，完成 lint、单元测试、端到端测试和类型检查。
- 使用 Playwright MCP 服务器在真实浏览器中测试工作。
+- 创建并选择 QA 自定义智能体，以评估需求、覆盖情况、技能脚本结果和浏览器证据。
- 在共享画布上与智能体协作。
-- 逐步提高更改交付的合并自动化程度，从自行在 github.com 上合并，到让 **Agent Merge** 完成拉取请求。
+- 明确执行早期 PR 的合并，再在功能和画布 PR 工作流中授权 **Agent Merge**。
-接下来自动执行一些重复性工作、讨论最佳实践，并了解后续方向。
+完成设置课程第 0–1 课后，你学习了九个核心模块，即第 2–10 课。现在回顾产出和后续方向；本总结不再启动新的动手任务。
-## 自动执行重复性工作
+## 交付的内容
-应用可通过**自动化**按计划或按需运行智能体，非常适合对新议题进行分类或汇总近期活动等日常任务。接下来创建一个简单的非破坏性自动化任务。
+本研讨会有四个 PR 里程碑，每个里程碑都从更新后的 `main` 开始，使用各自的分支：
-1. 在侧边栏中选择 **Automations**，再选择 **New automation**。
-2. 为其指定名称，例如 `Recap my recent work`。
-3. 选择触发器。**Manual** 支持按需运行；**On a schedule** 会自动运行；**When an issue is created** 会在创建新议题时响应。本课请选择 **Manual**。
-4. 输入只读提示词，确保自动化任务无法更改任何内容，例如：
+1. **星级评分**：在游戏卡片上显示现有的 `starRating`，以及明确的未评分状态。
+2. **指令及示例改动**：添加文档约定，并通过一个小型的真实代码改动验证其效果。
+3. **筛选功能及质量工作流**：实现议题需求，创建包含 shell 脚本的 `quality-checks` 技能和 QA 配置文件，并包含相关测试。
+4. **保存在存储库中的分类画布**：共享一个添加议题上下文的看板，而不自动实现其他功能。
- ```plaintext
- Summarize the pull requests merged in this repository over the last week, and list any issues still open in the backlog.
- ```
+第 4–8 课使用同一筛选会话、工作树和分支。检查点提交在 PR 3 内保留进度；技能、MCP 配置和 QA 无需单独的功能分支。每个后续里程碑都在前一个 PR 合并，且新会话分支从 `origin/main` 更新后才开始。
-5. 选择项目（你的 Tailspin Toys 存储库）并创建自动化任务。
-6. 按需运行该任务以查看结果。
+## 不同类型的验证
-> [!TIP]
-> 自动化任务可以在本地或云中运行。如果希望自动化任务按计划无人值守运行，请启用 **Run in the cloud**，并选择允许它使用的 **Tools**。在信任其输出之前，应确保计划任务范围明确且不具破坏性。
+早期功能使用现有 npm 检查。筛选功能增加了手动浏览器检查。技能通过随附脚本让四项检查可重复执行，MCP 增加了智能体的直接浏览器观察，QA 则将需求和覆盖情况与最终验证结合起来。PR 仅在 QA 证据仍适用于所提交的修订版本时才复用它。
+
+新增测试应填补真实缺口；不需要新增测试的 QA 运行也可能完全正确。缺少工具、跳过检查和失败都是需要明确报告的阻塞项，而不是通过。授权合并前审查代码和证据，并在改动后更新受影响的证据。
## 最佳实践
-使用任何 AI 工具时，其周边基础设施都会影响输出质量。指令文件、技能和自定义智能体都在本研讨会中发挥了作用。应投入精力完善这些资产，并在会话间复用。
+使用任何 AI 工具时，其周边基础设施都会影响输出质量。本研讨会中，你创建了指令、技能和 QA 配置文件；应审查它们，并在会话间复用。自定义智能体定义专业角色和指令，可用工具由配置和操作环境权限决定；技能则将可复用的任务指令、可执行脚本和辅助资源打包，供按需加载。自定义智能体也能执行脚本，包括技能随附的脚本。确认脚本实际执行且自定义智能体确已选中，而不是仅凭令人信服的描述作出判断。
根据任务选择适合的**模式和模型**。使用 **Plan** 在构建前思考方法；使用 **Interactive** 参与范围明确的更改；仅对范围清晰且彼此隔离的任务使用 **Autopilot**。日常编辑可选择更快的模型，复杂工作则选择推理能力更强的模型并提高推理强度。
@@ -49,6 +48,7 @@ lastUpdated: 2026-07-09
你已经了解核心工作流。以下功能也值得探索：
- **Quick chats**：适合不需要完整会话的一次性问题。
+- [**Automations**][using-automations]：用于重复性或按需任务，例如汇总近期工作。采用前审查计划、权限和范围；创建自动化任务属于后续方向，不是本研讨会的一部分。
- **Rubber duck**：用于分析问题，并在构建前获得高信噪比反馈。
- [**Custom agents**][custom-agents]：将角色、工具和指令打包，以便重复执行专业工作。
- [`/chronicle`][chronicle]：生成会话过程的叙述。
@@ -60,7 +60,7 @@ lastUpdated: 2026-07-09
熟练使用任何工具的最佳方式都是持续使用。可将它用于生产代码、业余项目，或那个构思多年却始终没有动手构建的小应用。与团队分享经验，也向团队学习。并且一如既往地探索文档。
-要探索 GitHub Copilot 生态系统的更多内容，请查看 [VS Code 学习路径](../../vscode/)、[Copilot CLI 学习路径](../../cli/)或 [Cloud agent 学习路径](../../cloud/)。
+要探索 GitHub Copilot 生态系统的更多内容，请查看 [VS Code 学习路径][vscode-harness]、[Copilot CLI 学习路径][cli-harness]或 [Cloud agent 学习路径][cloud-harness]。
## 资源
@@ -71,6 +71,10 @@ lastUpdated: 2026-07-09
- [使用画布扩展][canvas-docs]
- [关于云沙盒和本地沙盒][sandboxes]
+[previous-lesson]: ../9-canvases/
+[vscode-harness]: ../../vscode/
+[cli-harness]: ../../cli/
+[cloud-harness]: ../../cloud/
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
[getting-started]: https://docs.github.com/copilot/how-tos/github-copilot-app/getting-started
[customize]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/zh-cn/app/2-add-star-rating.md b/docs/zh-cn/app/2-add-star-rating.md
index 632d0194..b7d7c1c1 100644
--- a/docs/zh-cn/app/2-add-star-rating.md
+++ b/docs/zh-cn/app/2-add-star-rating.md
@@ -1,5 +1,5 @@
---
-title: "第 2 课 - 运行第一个智能体会话"
+title: "第 2 课 - 添加星级评分：快速上手"
description: "在 GitHub Copilot app 中启动第一个智能体会话，对游戏卡片进行一项小改动，并通过第一个拉取请求合并更改。"
authors:
- geektrainer
@@ -22,7 +22,7 @@ Tailspin Toys 中的每款游戏都可以有星级评分，该评分已显示在
## 会话剖析
-**会话**是与智能体的对话，在独立工作区中运行。每个会话都有**专用的 git 工作树和分支**，因此可以同时运行多个会话，例如一个添加功能，另一个修复 bug，而不会造成更改冲突。会话按存储库分组显示在侧边栏中，选择任一会话即可切换。
+**会话**是与智能体的对话。本研讨会选择 **new working tree**，为会话提供专用的检出目录和分支。这样可以隔离每个 PR 里程碑，而无需为每课单独创建分支。会话按存储库分组显示在侧边栏中，选择任一会话即可切换。
会话中包含三类内容：与智能体的**对话**、智能体探索和编辑文件时的**工具活动**，以及带有差异的**已更改文件**列表。
@@ -36,16 +36,20 @@ Tailspin Toys 中的每款游戏都可以有星级评分，该评分已显示在
-4. 使用以下提示词请求更改：
+4. 在提示框下方选择 **new working tree** 和 **Interactive** 模式。使用以下提示词请求更改：
```plaintext
- On the game cards, show each game's star rating. The Game type already includes a starRating field — it's a number out of 5, or null when a game hasn't been rated yet. Display it on each card in src/components/GameCard.astro, and when starRating is null show "No rating yet" instead. Keep the change small and don't restructure the card layout.
+ 编辑前，确定当前检出目录和分支，确认这是一个干净的新工作树，获取 origin，并将当前会话分支快进到 origin/main。确认 HEAD 与 origin/main 一致。如果工作树不干净、已发生分叉或无法更新，停止并说明原因；不要重置或丢弃工作。
+
+ 在游戏卡片上显示每款游戏的星级评分。Game 类型已包含 starRating 字段，表示满分为 5 的评分，游戏尚未评分时为 null。在 src/components/GameCard.astro 的每张卡片上显示评分；当 starRating 为 null 时，改为显示 "No rating yet"。保持改动小，不要重构卡片布局或更改数据模型。
+
+ 遵循存储库指令，添加或更新适当的测试，并运行相关的现有 npm 检查。检查先决条件，并在安装任何内容前先询问。报告更改的文件和检查结果，然后停止，供我审查。不要提交、推送、打开拉取请求或实现其他功能。
```
> [!NOTE]
> 请注意，提示词包含了 Copilot 要更新的文件名。虽然不要求指定 Copilot 应在工作中包含哪些文件，但指出正确方向既能帮助 Copilot 快速生成代码，也能减少令牌用量。
-5. 选择 Enter 将提示词发送给 Copilot。
+5. 按 Enter 将提示词发送给 Copilot。
Copilot app 首先创建新的工作树，即项目的隔离副本。随后，它会探索项目，找到添加新功能所需更新的文件，然后创建必要的代码。现在，你已经使用 Copilot app 添加了一项新功能。
@@ -76,7 +80,9 @@ Copilot app 首先创建新的工作树，即项目的隔离副本。随后，
## 检查更改
-当然，不能只阅读代码就假定它能正常工作，还应进行视觉测试。为此，需要从终端启动应用，再确认一切正常。Copilot app 恰好内置了终端。
+打开浏览器前，先审查智能体的自动化检查结果。确认测试覆盖数值类型的 `starRating` 和 `null` 回退状态，并使用项目现有的 npm 脚本，而不是尚未创建的技能。缺少先决条件或跳过检查不算通过。
+
+然后使用会话内置的终端手动检查应用。启动服务器前先确定工作树，不要复用其他检出目录的服务器。
1. 在 Copilot app 右侧的审查面板中选择 **Terminal**。如果没有 **Terminal** 按钮，请选择 **+**（标记为 **Open in panel**），再选择 **Terminal**。
@@ -89,26 +95,30 @@ Copilot app 首先创建新的工作树，即项目的隔离副本。随后，
```
3. 服务器启动后（只需片刻），打开浏览器窗口。
-4. 转到 [http://localhost:4321](http://localhost:4321)。
-5. 现在应能在主页上的所有游戏中看到星级评分。
+4. 打开服务器输出的本地 URL，通常是 `http://localhost:4321`。如果端口已被占用，应先确认其归属，而不是停止无关进程。
+5. 确认已评分的游戏卡片显示满分为五分的评分值。如果有未评分数据，确认显示 **No rating yet**；否则，使用自动化测试验证空值情况，不要声称已亲眼观察到它。
6. 返回终端窗口。
-7. 选择 Ctrl+C 停止开发服务器。
+7. 按 Control+C（Mac）或 Ctrl+C（Windows/Linux），停止自己启动的开发服务器。
## 打开并合并第一个拉取请求
-更改看起来没有问题，现在可以交付。你将要求智能体打开拉取请求，然后在 github.com 上自行审查并合并。目前先手动管理此流程，后续课程将探索 Copilot 如何自动处理其中部分工作。
+更改看起来没有问题，现在可以交付 PR 1。先单独授权提交和创建 PR，不要与实现授权混在一起：
+
+```plaintext
+审查星级评分改动及其测试的完整差异，汇总验证结果，并在当前会话分支上提交已审查的更改。推送分支，并使用存储库的 PR 模板创建以 main 为目标的拉取请求。不要合并。
+```
-1. 在右上角选择 **Create PR**。
+1. 打开会话中已创建的 PR 链接。如果应用显示 **Create PR** 确认提示，选择它以批准请求，不要创建第二个 PR。
2. 如果系统提示，请选择 **Sign in with your browser**，并按照提示完成身份验证。
3. Copilot 开始创建 PR。
-PR 创建后，Copilot 会监视存储库中需要运行的工作流。片刻后，右上角的按钮会变为 **Ready to merge**，表示 PR 已可合并。
+PR 创建后，在 **My work** 中检查完整的 PR 差异和检查结果。阅读练习存储库的工作流结果，等待必需的检查和审查完成，并在合并前解决失败项。**Ready to merge** 不能替代对更改或本地验证证据的审查。
4. 选择聊天上方的 **PR** 气泡，在审查窗格中打开并查看拉取请求。可根据需要在此审查 PR。
5. 准备好后，选择 **Ready to merge**。
6. 在新对话框窗口中选择 **Merge pull request**，合并拉取请求。
-现在，新功能已推送到网站。
+确认 PR 1 已合并到 `main` 后再继续。合并练习存储库本身并不会部署网站。下一课会创建新工作树，并从 `origin/main` 更新，以包含此 PR。
## 总结与后续步骤
@@ -118,7 +128,7 @@ PR 创建后，Copilot 会监视存储库中需要运行的工作流。片刻后
- 指示智能体对游戏卡片进行一项范围明确的小改动。
- 在工作区差异视图中审查了更改。
- 在本地运行应用，并在浏览器中确认了星级评分。
-- 打开并自行在 github.com 上合并了拉取请求。
+- 打开了 PR 1，审查了检查结果，并明确执行了合并。
接下来，你将从待办事项中的一个议题开始，使用应用向存储库添加自定义指令标准。继续学习[第 3 课 - 使用自定义指令引导 Copilot][next-lesson]。
@@ -129,6 +139,7 @@ PR 创建后，Copilot 会监视存储库中需要运行的工作流。片刻后
- [使用 GitHub Copilot app 管理议题和拉取请求][managing-issues-prs]
[prior-lesson]: ../1-install-copilot-app/#安装并配置-github-copilot-app
+[previous-lesson]: ../1-install-copilot-app/
[next-lesson]: ../3-custom-instructions/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
diff --git a/docs/zh-cn/app/3-custom-instructions.md b/docs/zh-cn/app/3-custom-instructions.md
index 5ab57279..04948f8e 100644
--- a/docs/zh-cn/app/3-custom-instructions.md
+++ b/docs/zh-cn/app/3-custom-instructions.md
@@ -1,9 +1,9 @@
---
title: "第 3 课 - 使用自定义指令引导 Copilot"
-description: "使用 GitHub Copilot app 向存储库添加自定义指令标准，从待办议题开始，并通过拉取请求合并更改。"
+description: "添加文档标准，在一个现有的小型辅助函数或组件上展示其效果，并通过第二个拉取请求一并合并。"
authors:
- geektrainer
-lastUpdated: 2026-07-09
+lastUpdated: 2026-09-11
---
使用生成式 AI 时，上下文至关重要。如果任务需要以特定方式完成，或 Copilot 应了解一些背景信息，就应提供这些上下文。[指令文件][instruction-files]是实现此目的最强大的工具之一，它不仅说明需要什么代码，还说明代码应如何组织。本课将向存储库添加文档标准，并采用后续大多数工作的方式：从待办议题开始，让智能体完成更改。
@@ -12,15 +12,17 @@ lastUpdated: 2026-07-09
- 探索存储库指令和路径范围指令文件如何传递给智能体。
- 从待办事项中的指令议题启动会话。
-- 要求智能体向 `.github/copilot-instructions.md` 添加文档标准。
-- 审查更改，并通过拉取请求合并更改。
+- 要求智能体向适当的存储库指令文件添加范围明确的文档标准。
+- 通过一个小型的真实代码改动展示标准的效果，完成验证，并合并 PR 2。
## 场景
与所有优秀的开发团队一样，Tailspin Toys 针对开发实践制定了一组准则和要求，其中包括：
-- 应以 TSDoc 文档注释的形式向代码添加文档。
-- 应记录格式规范，并通过 lint 强制执行。
+- 注释应说明意图和不明显的决策，而不是复述代码。
+- `db/` 和 `src/lib/` 中导出的函数应使用 TSDoc/JSDoc 记录用途、参数和返回值；如果存在可注入的 `db` 参数，也应记录。
+- 可复用的 Astro 组件应记录其 `Props` 契约，并在相关代码变化时同步更新注释。
+- 应保留现有格式和 lint 指导。
通过指令文件，可以确保 Copilot 获得正确的信息，按照这些实践完成任务。
@@ -28,13 +30,13 @@ lastUpdated: 2026-07-09
自定义指令可向 Copilot 提供上下文和偏好，使其更好地理解编码风格与要求。这项强大功能可引导 Copilot 提供更相关的建议和代码片段。你可以指定首选编码约定、库，甚至希望代码中包含的注释类型。可以为整个存储库创建指令，也可以针对特定文件类型提供任务级上下文。
-指令文件分为两类：
+项目使用两类指令文件：
- `.github/copilot-instructions.md`：每次针对存储库的请求都会发送给 Copilot 的单个指令文件。此文件应包含项目级信息，即与大多数发送给 Copilot 的聊天或 CLI 请求相关的上下文，例如所用技术栈、正在构建的内容概述、最佳实践和其他全局指导。
- `.github/instructions/*.instructions.md`：可针对特定任务或文件类型创建。可以用它们为特定语言（如 TypeScript 或 Astro）提供准则，也可以为创建 UI 组件或一组新单元测试等任务提供指导。
> [!NOTE]
-> Copilot 还支持通过 AGENTS.md、CLAUDE.md 和 GEMINI.md 等其他标准引入指令指导，确保 Copilot 始终具有正确的上下文。
+> 其他指令格式及支持情况因操作环境而异。依赖某种格式前，请查阅[自定义指令支持参考][custom-instructions-support]。
### 管理指令文件的最佳实践
@@ -74,49 +76,55 @@ lastUpdated: 2026-07-09
11. 最后，打开 `.github/instructions/drizzle.instructions.md` 并滚动到底部。注意其中指向其他指令文件（如 `unit-tests.instructions.md`）和项目现有文件的链接。这样可以将较大的指令集拆分为较小的可复用文件，并让 Copilot 在生成代码时参考示例。（其中的路径相对于指令文件，而非存储库根目录。）
> [!NOTE]
-> `copilot-instructions.md` 中的 **Code formatting requirements** 部分记录了项目编码标准，但尚未要求代码内文档。接下来，你将添加 TSDoc 文档注释和文件注释标头的规则。
+> 添加规则前，将现有指导与实际编码标准议题进行比较。本课关注说明意图的注释、导出的数据层函数文档和 Astro `Props` 契约，而不是统一要求文件标头或复述代码的注释。
## 从指令议题开始
-上一课通过直接提示词启动了会话。不过，大多数工作都从议题开始。接下来，根据用于更新指令文件的议题创建新会话，再请求更新。
+创建此会话前，确认 PR 1 已合并。为 PR 2 创建新工作树，不要继续使用星级评分分支。大多数工作都从议题开始，因此使用编码标准议题提供需求。
> [!NOTE]
> 指令文件对 Copilot 生成的代码影响很大，因此应确保它们能清晰地引导 Copilot。让 Copilot 创建第一版（正如本课将要做的），再由你审查更新是否满足要求，是一种有效方法。
1. 在侧边栏中选择 **My work**。
2. 选择标题为 **Update our repository coding standards** 的议题，将其打开。
-3. 选择右上角的 **New session**，根据该议题启动新会话。
+3. 选择右上角的 **New session**，选择 **new working tree**，再选择 **Interactive** 模式。
-4. 使用以下提示词，请求 Copilot 更新指令文件以满足议题中记录的要求：
+4. 使用以下提示词。即使应用的本地检出内容已过时，编辑前更新新会话分支，也能确保实际起点是最新合并后的 `main`：
- ```plaintext
- Following this issue, make the updates to the instructions files in this project to meet the requirements documented. Don't create the PR quite yet!
- ```
+ ```plaintext
+ 编辑前，确定当前检出目录和分支，确认这是一个干净的新工作树，获取 origin，并将当前会话分支快进到 origin/main。确认 HEAD 与 origin/main 一致，并包含已合并的星级评分 PR。如果工作树不干净、已发生分叉或缺少该合并，停止；不要重置、丢弃工作或创建其他分支。
+
+ 阅读议题 "Update our repository coding standards" 和现有存储库指令。添加范围明确的文档约定：说明意图而不是机械过程；使用 TSDoc/JSDoc 记录 db/ 和 src/lib/ 中导出函数的用途、参数、返回值，以及存在时可注入的 db 参数；记录可复用 Astro 组件的 Props 契约；并在相关代码变化时同步更新注释。
+
+ 将每条规则放入适当的现有指令文件，避免重复或矛盾，并在 README 中链接到或概述更新后的标准。保留现有格式和 lint 指导。不要统一要求文件标头、迁移格式工具、重写整个应用的文档或实现筛选功能。向我展示指令差异，然后停止，供我审查。不要创建技能或智能体、提交、推送或创建 PR。
+ ```
Copilot 会进行更新。
## 审查更改
-接下来阅读 Copilot 所做的更新，并要求它提供根据更新后指令生成的代码示例。
+阅读更新后的指导，再通过真实文件展示其效果。仅提供建议代码片段，无法证明存储库指令影响了代码改动。
1. 选择右上角的 **Changes**，打开代码更改。
-2. 审查更新后的指令文件，确认其中包含有关向代码添加文档和注释的准则。
+2. 审查更新后的指令文件和 README 引用。确认规则符合议题的注释理念、导出函数文档要求和组件契约，不要自行添加统一的文件标头要求。
> [!NOTE]
> AI 具有概率性而非确定性，因此实际文本会有所不同。
-3. 使用以下提示词，要求 Copilot 创建它现在会生成的代码示例：
+3. 审查指令后，在同一会话中请求一个范围明确的示例改动：
+
+ ```plaintext
+ 在 db/ 或 src/lib/ 中一个现有的小型导出 TypeScript 辅助函数，或一个可复用 Astro 组件上展示更新后的文档约定。检查存储库，选择合适的现有文件；不要假设已有 publishers 辅助函数。进行一项不改变行为的小型可读性改进，并应用相关函数文档或 Props 契约指导。解释不明显的意图，不添加仅复述代码的注释。
- ```plaintext
- Do not make any updates, but show me what the code would look like. Based on the new instructions, if I asked Copilot to create a new library component to return all Publishers what would that code look like?
- ```
+ 将更改限制在该示例及直接相关的测试内。不要实现筛选功能或创建新功能。运行相关的现有 npm 检查，报告更改内容及指令如何影响代码，然后停止，供我审查。在安装任何内容前先询问。不要提交、推送或创建 PR。
+ ```
-4. 审查 Copilot 提议的代码。注意其中包含 TSDoc 文档注释和文件标头注释，这正是更新后的指令所要求的内容。
+4. 审查实际文件差异，而不只是聊天回复。检查文档是否说明了真实行为，以及可读性改动是否保留了原有行为。审查相关测试、lint 和类型检查结果，解决失败项后再继续。
现在，你已更新项目中的指令文件，并了解了更新带来的影响。
@@ -124,17 +132,23 @@ Copilot 会进行更新。
指令文件会成为存储库中的资产，与团队其他成员共享。接下来像处理任何其他资产一样，为此次工作创建 PR。
-1. 在右上角选择 **Create PR**。
+先一并授权已审查的指令和示例改动：
+
+```plaintext
+审查编码标准指令、README 引用和范围明确的代码示例的完整差异，包括相关测试。汇总验证结果，并在当前会话分支上提交这些已审查的更改。推送分支，使用存储库的 PR 模板创建一个以 main 为目标的拉取请求，并关联编码标准议题。除非满足议题的每项验收标准，否则将其描述为部分贡献；不要为未完成的工作使用关闭议题的关键字。不要合并。
+```
+
+1. 打开会话中的 PR 链接。如果应用显示 **Create PR** 确认提示，选择它，不要创建重复的 PR。
2. 如果系统提示，请选择 **Sign in with your browser**，并按照提示完成身份验证。
3. Copilot 开始创建 PR。
-PR 创建后，Copilot 会监视存储库中需要运行的工作流。片刻后，右上角的按钮会变为 **Ready to merge**，表示 PR 已可合并。
+在 **My work** 中检查完整的 PR 差异，包括指令和代码更改。审查练习存储库的 CI 结果及必需的审查。在选择 **Ready to merge** 前解决失败项；CI 不能替代示例改动或你的审查。
4. 选择 **Ready to merge**。
5. 在新对话框窗口中选择 **Merge pull request**，合并拉取请求。
> [!NOTE]
-> 标准合并到默认分支后，便会成为每位成员和每个新会话的项目组成部分。下一课从最新默认分支启动筛选会话时，智能体会自动遵循此标准。生成的 TypeScript 无需提示便会包含 TSDoc 文档注释。这是指令影响代码生成的一个虽小但真实的示例。
+> 开始筛选功能前，确认 PR 2 已合并到 `main`。仅创建新工作树并不能保证代码是最新的：第 4 课会先获取更新，将新会话分支快进到 `origin/main`，并在规划前确认前两个合并都已包含在内。
## 总结与后续步骤
@@ -142,10 +156,10 @@ PR 创建后，Copilot 会监视存储库中需要运行的工作流。片刻后
- 探索了存储库中的 `copilot-instructions.md` 和路径范围 `*.instructions.md` 文件。
- 从待办事项中的指令议题启动了会话。
-- 要求智能体向 `.github/copilot-instructions.md` 添加文档标准。
-- 审查了更改，并通过拉取请求将其合并。
+- 要求智能体向适当的指令文件添加范围明确的文档规则，并从 README 引用这些规则。
+- 检查了标准对真实代码改动的影响，验证了结果，并通过 PR 2 一并合并。
-接下来，你将在新会话中构建筛选功能，并观察它如何采用刚合并的标准。继续学习[第 4 课 - 使用 Autopilot 构建功能][next-lesson]。
+接下来，你将在新会话中构建筛选功能，并检查它是否遵循刚合并的标准。继续学习[第 4 课 - 使用 Plan 和 Autopilot 构建筛选功能][next-lesson]。
## 资源
@@ -154,6 +168,7 @@ PR 创建后，Copilot 会监视存储库中需要运行的工作流。片刻后
- [创建自定义指令的最佳实践][instructions-best-practices]
- [Awesome Copilot：指令文件和其他资源集合][awesome-copilot]
+[previous-lesson]: ../2-add-star-rating/
[next-lesson]: ../4-build-filtering/
[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/zh-cn/app/4-build-filtering.md b/docs/zh-cn/app/4-build-filtering.md
index 653e19d1..ca2301cf 100644
--- a/docs/zh-cn/app/4-build-filtering.md
+++ b/docs/zh-cn/app/4-build-filtering.md
@@ -1,186 +1,122 @@
---
-title: "第 4 课 - 使用 Autopilot 构建功能"
-description: "在 GitHub Copilot app 中使用 Plan 和 Autopilot 模式构建静态客户端筛选功能，观察它如何继承文档标准，并使用智能体技能进行验证。"
+title: "第 4 课 - 使用 Plan 和 Autopilot 构建筛选功能"
+description: "根据议题规划筛选功能，明确批准 Autopilot，使用现有 npm 检查和手动浏览器访问进行验证，并保存检查点。"
authors:
- geektrainer
-lastUpdated: 2026-07-13
+lastUpdated: 2026-09-11
---
-本项目已完成一些小更新。但更复杂的更改需要更完善的流程。GitHub Copilot app 可以配合现有流程，确保以正确的方式构建正确的内容。这是连续三节课程中的第一节，你将遵循典型开发流程：先使用议题生成新功能，再使用智能体技能运行验证测试和 lint。
+你已合并星级评分、文档标准及其代码示例。现在开始构建筛选功能。这是一个较大 PR 里程碑的起点：第 4–8 课始终沿用同一会话、工作树和分支。
本课将介绍如何：
-- 从筛选议题启动新会话。
-- 使用 **Plan** 模式规划功能，再通过 **Autopilot** 构建功能。
-- 确认生成的代码遵循之前合并的文档标准。
-- 使用项目的 `quality-checks` 技能验证工作。
+- 从更新后的 `main` 开始，并阅读实际的筛选议题。
+- 在 **Plan** 模式中明确需求，再明确批准 **Autopilot**。
+- 审查筛选功能和测试，然后运行四项现有 npm 检查。
+- 在浏览器中手动检查功能，并保存检查点。
-## 场景
+技能、MCP 验证、QA 配置文件及功能 PR 将在后续模块中完成。不要在此实现步骤中提前创建它们。
-主页列出了所有游戏，但访问者无法缩小列表范围。筛选议题要求允许用户按**类别**和**发行商**筛选游戏。接下来使用 Copilot 实现该功能。
-
-## 背景
+## 会话模式
-将 AI 编码智能体引入开发流程不会改变基本原则。事实上，这些原则反而更加重要。大多数开发人员遵循类似以下的流程：
+提示框下方的模式选择器控制智能体的自主程度：
-1. 打开已创建的议题，查看需要完成的工作详情。
-2. 为需要构建的内容制定计划。
-3. 构建并审查代码。
-4. 运行测试以验证代码。
-5. 手动验证新功能。
-6. 创建拉取请求 (PR)。
-7. 代码通过审查且持续集成流程成功后，合并代码。
+- **Interactive** 让你在智能体工作和请求输入时持续参与。
+- **Plan** 在实现前准备计划，供你审查。
+- **Autopilot** 在批准的范围和权限内自主实现并迭代。
-> [!NOTE]
-> 具体流程会因团队和组织而异，但大多数流程都是以上主题的变体。
+先规划，再明确批准，创建可复用的自定义配置前切回 Interactive。
-坚持这种标准方法，可以确保 AI 生成的代码满足既定要求，并经过与手写代码相同的审查流程。
+## 从更新后的 main 开始
-## 会话模式
+确认 PR 1 和 PR 2 已在 GitHub 上合并。为筛选功能创建新工作树，不要继续使用之前的任一分支。
-**会话模式**控制智能体的自主程度。可以从提示词字段下方的下拉菜单中设置模式，并随时更改：
+1. 选择 **My work**，按标题找到 **Allow users to filter games by category and publisher**。打开议题并复制其实际 URL；不同存储库中的议题编号可能不同。
+2. 选择 **New session**，再选择 **new working tree**。更新基线时保持 **Interactive** 模式。
-- **Interactive**：你与智能体协同工作。智能体提出更改建议，并等待输入后再继续。
-- **Plan**：智能体先创建计划。你审查并批准计划后，智能体才会执行。
-- **Autopilot**：智能体完全自主工作，包括编写代码、运行测试和迭代，无需等待输入。
+ 
-## 规划筛选功能
+3. 在规划或编辑前发送以下准备请求：
-发现潜在问题的最佳时机是在编写任何代码之前，而提前规划正是最好的方法。让 Copilot 进行规划时，它会生成一组步骤，并记录将采用的方法。你可以审查计划并提出改进建议，然后让 Copilot 根据计划生成代码。
-
-接下来打开议题、启动新会话，再切换到 Plan 模式并发出请求，以创建计划。
+ ```plaintext
+ 准备这个新的筛选会话，不要实现任何内容。确定检出目录和分支，确认工作树干净，获取 origin，并将当前会话分支快进到 origin/main。确认 HEAD 与 origin/main 一致，并包含已合并的星级评分和编码标准 PR。
-1. 在导航选项卡中选择 **My work**。
-2. 选择标题为 **Allow users to filter games by category and publisher** 的议题。
-3. 选择右上角的 **New session**。
+ 如果检出目录不干净、已发生分叉或缺少任一合并，停止并说明原因。不要重置或丢弃工作、切换分支、创建其他分支或编辑应用文件。报告基线修订版本。
+ ```
- 
+4. 检查报告中的基线。仅获取更新不会更新工作树：工作开始前，当前会话分支必须完成快进，且其 `HEAD` 必须与获取后的 `origin/main` 一致。
-4. 选择 Shift+Tab，直到模式显示为 **Plan**。
+## 规划筛选功能
- 
+将模式选择器切换为 **Plan**。把下方的议题占位符替换为刚复制的 URL。
-5. 发送以下提示词。由于会话从筛选议题启动，因此该议题已在会话上下文中：
+```plaintext
+根据此议题规划筛选功能：。阅读完整验收标准和存储库指令，然后检查当前的静态 Astro 应用、现有数据访问辅助函数及测试。暂时不要实现。
- ```plaintext
- Plan the work based on the requirements documented in the issue. Please ask any clarifying questions you might have as you build the plan.
- ```
+涵盖议题要求的多类别选择、发行商筛选、类别与发行商组合筛选、适当的数据访问辅助函数、无障碍控件，以及单元测试和端到端测试覆盖。对于未明确的行为，例如多个类别如何组合、清除筛选和空结果，请让我决定，不要悄悄编造需求。除非需求和现有架构确有依据，否则不要引入服务器 API。
-6. 智能体在制定计划时可能会提出后续问题。根据你会如何构建功能来回答这些问题。
+提出范围明确的实现和验证计划，遵循存储库文档约定，并添加或更新必要的单元测试和端到端测试。在 package.json 中确认命令后，计划使用项目现有工具运行 npm run lint、npm run test:unit、npm run test:e2e 和 npm run typecheck:all。将议题 URL 和我批准的澄清内容记录在计划中，以便用于 QA。
-> [!NOTE]
-> Copilot 具有概率性，因此它提出的具体后续问题会有所不同。事实上，它可能不会提出任何问题，这完全正常。
+在我批准前，将以下执行保障纳入计划：确定被测检出目录和服务器；运行检查前检查先决条件；安装软件、依赖项或浏览器前先询问；不要复用其他工作树的服务器；仅停止自己启动的服务器；报告其他端口冲突，不要停止无关进程。必须将缺少先决条件和跳过检查报告为阻塞项，而不是通过。
-7. 完成后，Copilot 会提供计划摘要。审查该计划，应会看到构建查询、添加筛选控件和测试的建议。可以根据需要提供反馈来完善计划，智能体会将建议纳入新版本。
+将以下实现边界纳入计划：在我明确批准 Autopilot 后，仅在同一工作树和分支上实现约定的筛选功能及其测试，运行四项检查，报告实现情况和全部检查结果，包括失败或阻塞项，然后停止，供我审查并进行手动浏览器检查。实现期间不要创建技能或自定义智能体、配置 MCP、更改分支、提交、推送或打开 PR。手动浏览器检查和检查点提交将在之后由我单独指示。
-## 使用 Autopilot 构建
+目前保持 Plan 模式，完成计划后停止，供我审查。不要实现、创建技能或自定义智能体、配置 MCP、更改分支、提交、推送或打开 PR。
+```
-计划创建后，让 Copilot 构建实现。
+回答澄清问题，并根据议题审查计划。检查其中是否包含数据访问改动、无障碍控件和测试，不要接受仅实现 UI 的方案。保存计划中的实际议题 URL 和批准的澄清内容，以供第 6 课和第 7 课使用；如果无需附加标准，使用 `none`。
-1. 在 **Plan summary** 对话框的选项列表中，选择最接近 **Approve and implement with autopilot** 的选项。
+批准前，确认计划本身包含四项检查、文档约定、先决条件和服务器保障、保持同一工作树及分支的要求，以及实现和验证后停止的边界。计划必须禁止在实现期间提前创建技能、智能体、设置 MCP、提交、推送和创建 PR。如果缺少任何边界，保持 **Plan** 模式请求修订计划，检查修订版后再批准。
-Copilot 将开始实现。
+## 明确批准 Autopilot
-> [!NOTE]
-> 如果 Copilot 未自动开始创建所需代码，可以使用类似 "Go ahead and start building out the plan!" 的提示词让它继续。
->
-> 创建所需更新需要几分钟。智能体会编辑和创建文件、编写并运行测试，以及进行迭代。此时可以回顾目前探索的内容，或稍作休息。
+只有经过审查的计划已包含需求和全部执行边界，才能在计划批准控件中选择 **Approve and implement with autopilot**，或当前版本中等效的明确 Autopilot 选项。确认模式指示器显示 **Autopilot**。
-## 审查更改
+批准后可能立即开始执行。因此，所有实现范围、安全规则和停止边界都必须在批准前写入已审查的计划；不要依赖执行开始后再通过后续消息补充。
-所有 AI 生成的代码在合并前都需要审查。接下来审查代码并运行网站，确保一切正常。
+Autopilot 可以编写代码和测试，并针对失败进行迭代，但这并不意味着获准完成后续研讨会模块。缺少先决条件是需要获批后解决的阻塞项，不是通过了检查。
-1. 选择右上角的 **Changes**，打开代码更改。
+## 审查并验证实现
- 
+1. 打开 **Changes**，检查筛选实现和测试。
+2. 对照议题和批准的澄清内容检查结果，包括多类别及发行商组合。检查新增或修改的辅助函数是否遵循第 3 课的文档标准。
+3. 查看全部四项 npm 检查的实际命令输出。此时直接运行命令，因为尚未创建 quality-checks 技能。
+4. 接受实现前，解决失败项并重新运行受影响的检查。Playwright 的 E2E 配置会构建并提供预览服务，且可能复用本地服务器；确保被测服务器属于此工作树，而不是之前的课程。
-2. 审查更改。应会看到新的 TypeScript、Astro 和测试文件。注意，新辅助函数包含 TSDoc 文档注释和文件标头注释。这是第 3 课中合并的文档标准，无需提示便已自动应用。
-3. 在 Copilot app 右侧的审查面板中选择 **Terminal**。如果没有 **Terminal** 按钮，请选择 **+**（标记为 **Open in panel**），再选择 **Terminal**。
+## 手动检查功能
- 
+手动审查前，将会话切回 **Interactive** 模式，并在第 5 课中保持该模式。
-4. 在终端窗口中输入以下命令，启动 Web 应用的开发服务器：
+1. 在此会话的审查面板中打开 **Terminal**。如有需要，选择 **+**，再选择 **Terminal**。
+2. 确认终端位于筛选工作树中，然后运行：
```shell
npm run dev
```
-5. 服务器启动后（只需片刻），打开浏览器窗口。
-6. 转到 [http://localhost:4321](http://localhost:4321)。
-7. 现在应能在主页上看到筛选器。
-8. 如果有任何问题，可以要求 Copilot 进行更新。
-9. 满意后，返回终端窗口。
-10. 选择 Ctrl+C 停止开发服务器。
+3. 在浏览器中打开此服务器输出的 URL，通常是 `http://localhost:4321`。如果端口已被占用，应先确定其归属，不要停止无关进程，也不要假定现有服务器包含本次更改。
+4. 按批准的行为测试类别选择、发行商选择及两者组合。检查键盘访问，以及约定的清除筛选和空结果行为。
+5. 如果发现失败，请求针对性修正，审查差异，重新运行受影响的自动化检查，再重复相关浏览器检查。
+6. 返回终端，按 Control+C（Mac）或 Ctrl+C（Windows/Linux），停止自己启动的服务器。下一模块运行 E2E 前，确认服务器已停止。
-## 使用 quality-checks 技能验证工作
+这是你的手动浏览器观察。第 6 课才会通过 MCP 由智能体观察浏览器。
-可以仅查看差异就认为工作完成，但团队已经定义了质量标准和可重复的检查方式。
+## 保存检查点
-**智能体技能**可指导 Copilot 如何执行重复性任务，例如运行测试、生成构建或创建拉取请求。技能是一个包含指令、脚本和资源的文件夹，智能体可以按需加载。[Agent Skills 是一项开放标准][agent-skills-repo]，适用于多种智能体，因此同一技能可在智能体模式下的 Copilot Chat、Copilot cloud agent、Copilot CLI 和 GitHub Copilot app 中使用。
+审查更改和验证结果后，授权创建本地提交：
-技能位于项目的 `.github/skills` 文件夹或全局 `~/.copilot/skills` 中。每个技能都在一个文件夹中，其中包含具有 YAML frontmatter（`name` 和 `description`）及 Markdown 指令的 `SKILL.md` 文件：
-
-```yaml
----
-name: quality-checks
-description: Run the project's test suites and linter to verify code changes are ready to commit, push, or merge.
----
+```plaintext
+审查当前差异，为筛选实现及其测试创建检查点提交。保持同一筛选分支和工作树。不要创建技能或智能体、配置 MCP、推送或打开拉取请求。
```
-技能还可包含脚本、资产和参考资料子文件夹。[智能体技能规范][agent-skills-spec]介绍了完整结构。
-
-> [!TIP]
-> 技能会动态加载。智能体根据 `description` 字段决定适用的技能。清晰且针对具体场景的说明决定了技能是会被使用还是被忽略。
-
-## 探索 quality-checks 技能
-
-接下来探索该技能，了解其作用。
-
-1. 如果审查面板尚不可见，请选择右上角的 **Toggle review panel** 将其打开。
-
- 
-
-2. 选择 **+**，向审查面板添加新项目。
-3. 选择 **File**。
-4. 搜索 `SKILL.md`。
-5. 从文件列表中选择 `SKILL.md .github/skills/quality-checks` 将其打开。
-6. 注意 `name` 和 `description`。说明会告知智能体*何时*使用该技能，即每当代码更改需要在提交、推送或合并前进行测试、lint 或验证时。
-7. 阅读该技能。它记录了哪个脚本运行哪个套件（单元测试、Playwright 端到端测试、ESLint）、运行顺序，以及如何调试常见故障。因此，智能体会按团队规定的方式运行检查，而不是猜测。
-
-## 运行检查
-
-在同一筛选会话中，要求智能体验证工作。你无需说出技能名称，智能体会根据请求进行匹配。
-
-1. 返回 Copilot app。
-2. 使用 slash command `/quality-checks` 直接调用技能，然后选择 Enter。
-3. 智能体按照技能运行单元测试、lint 和端到端测试，并报告结果。如果有任何失败，请要求它修复问题并重新运行检查，直到全部通过。
-4. **保持此会话打开。**下一课将添加 Playwright MCP 服务器，并使用它在真实浏览器中查看筛选功能。
-
-## 总结与后续步骤
-
-你端到端构建了一项真实功能，并按照团队的质量标准进行了验证。具体而言，你：
-
-- 从最新项目的筛选议题启动了新会话。
-- 使用 Plan 模式规划功能，并使用 Autopilot 构建功能。
-- 确认生成的辅助函数遵循第 3 课中合并的文档标准。
-- 使用 `quality-checks` 技能验证了工作。
-
-接下来，你将连接 Playwright MCP 服务器，并要求智能体在真实浏览器中探索筛选功能。继续学习[第 5 课 - 使用 Playwright MCP 服务器测试][next-lesson]。
+此检查点属于 PR 3，而不是单独的 PR。保持 **Interactive** 模式，在同一会话中继续学习[第 5 课 - 创建并使用 quality-checks 技能][next-lesson]。
## 资源
- [在 GitHub Copilot app 中使用智能体会话][agent-sessions]
-- [关于 Agent Skills][about-agent-skills]
-- [自定义 GitHub Copilot app][customize-app]
- [关于 GitHub Copilot 的云沙盒和本地沙盒][sandboxes]
-[ex0]: ../0-prerequisites/
-[ex2]: ../2-add-star-rating/
-[ex3]: ../3-custom-instructions/
-[next-lesson]: ../5-mcp-playwright/
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
[agent-sessions]: https://docs.github.com/copilot/how-tos/github-copilot-app/agent-sessions
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
[sandboxes]: https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
\ No newline at end of file
diff --git a/docs/zh-cn/app/5-agent-skills.md b/docs/zh-cn/app/5-agent-skills.md
new file mode 100644
index 00000000..fca44943
--- /dev/null
+++ b/docs/zh-cn/app/5-agent-skills.md
@@ -0,0 +1,93 @@
+---
+title: "第 5 课 - 创建并使用 quality-checks 技能"
+description: "让 Copilot 创建带有配套 shell 脚本的可复用质量检查技能，检查技能内容，并在筛选功能分支上执行。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+筛选功能已经实现，并已使用现有 npm 命令完成检查。现在，将这些检查封装为可复用的**智能体技能**。第 4–8 课始终使用同一个筛选功能会话和分支；本课不创建 pull request。
+
+在本课中，将：
+
+- 在创建自定义配置前返回 **Interactive** 模式。
+- 让 Copilot 创建 `quality-checks`，然后停下来供你检查。
+- 通过配套脚本执行全部四项检查，并证明单文件测试参数只会选中指定文件。
+- 在筛选功能分支上为技能创建检查点。
+
+## 指令、脚本和资源
+
+技能将可复用的任务指令、可执行脚本和辅助资源打包，供智能体按需加载。自定义智能体定义专业角色、指令和可用工具。两者相辅相成：自定义智能体可以执行脚本，包括技能附带的脚本。
+
+存储库技能位于 `.github/skills//SKILL.md`，包含带有 `name` 和 `description` 的 frontmatter 以及 Markdown 指令。脚本和其他资源存放在旁边。这里将让 Copilot 生成 `.github/skills/quality-checks/SKILL.md` 及其配套脚本，而不是复制现成答案。[Agent Skills 规范][skill-spec]介绍了这种格式。
+
+Copilot 根据已发现技能的描述，决定何时加载它。不要假定新技能会立即被已打开的会话发现；运行部分提供了明确读取技能的备用方式。格式可移植并不意味着无需满足 shell 或项目的前提条件。
+
+## 创建技能
+
+发送提示前，通过模式选择器将筛选功能会话切回 **Interactive** 模式。保持当前检出目录和分支。如果使用的旧版模板已经包含此技能，应先检查并扩展它，而不是覆盖已有的自定义内容。
+
+```plaintext
+创建 .github/skills/quality-checks/SKILL.md 和四个封装脚本，分别调用 npm run lint、npm run test:unit、npm run test:e2e 和 npm run typecheck:all。先阅读 package.json、README、测试配置和存储库指令。
+
+识别当前环境。macOS/Linux/WSL 只创建 Bash .sh 脚本，原生 Windows 只创建 PowerShell .ps1 脚本；如果无法确定，先询问。不要同时创建两种实现。封装脚本仅负责根据自身位置解析存储库根目录，验证该目录包含本项目的 package.json，然后调用 npm。根目录无效时，应明确报错并失败退出。支持任意工作目录和包含空格的路径。保留输出和失败退出代码，包括 PowerShell 原生命令的失败。npm 的 -- 分隔符只插入一次；调用方直接提供工具参数，不再添加 --。不要管理端口或进程。
+
+在 SKILL.md 中提供 name 和 description frontmatter、运行全部四个封装脚本的指令、前提条件、故障排查方法，以及包含一个现有单元测试文件的可移植调用示例。所有 Bash 示例都必须显式调用 bash；绝不绕过 PowerShell 执行策略。解释 Playwright 的服务器复用：只停止确实由自己启动的服务器，否则先询问。
+
+只创建技能和必需的脚本。不要运行检查或探测，不要安装任何内容、修改应用代码、提交或创建 PR。然后停止，等待检查。
+```
+
+## 检查技能
+
+1. 打开 **Changes** 查看生成的文件。也可以在审查面板中依次选择 **+**、**File**，然后搜索 `SKILL.md` 或脚本文件名。
+2. 检查 `name` 和 `description` 是否说明了技能及其适用场景。阅读指令，不要只看元数据。
+3. 确认执行顺序确实调用 `.github/skills/quality-checks/` 下的配套脚本，执行 lint、单元测试、E2E 和类型检查。
+4. 检查每个封装脚本是否根据自身位置解析根目录，并明确检查推导出的目录是否包含此检出目录中预期的 `package.json`。命令因 npm 搜索祖先目录而成功，并不能证明根目录正确。检查路径是否加引号、参数是否转发、输出是否可见，以及失败时是否正确退出；PowerShell 必须传递原生 npm 命令的失败状态。
+5. 检查文档中只运行一个单元测试文件的示例。封装脚本负责插入 npm 的 `--` 分隔符，因此调用方应直接传递目标工具的参数，不再添加分隔符。可复用指令中不应包含特定机器的检出目录绝对路径。在运行任何内容之前，让 Copilot 修正遗漏或问题。
+6. 脚本应仅负责根目录和清单文件验证，以及运行现有 npm 检查。端口和进程相关决策应放在 SKILL.md 中，而不是通过 shell 进程管理代码实现。确认只有智能体实际启动的服务器才可以停止；工作目录或进程名称匹配不能证明归属。交付的文件应仅包含技能、必需的封装脚本和必要的共享辅助文件，不含临时探测或调试文件。
+
+> [!NOTE]
+> 当前 Tailspin Toys 需要 Node.js 22.13 或更高版本、项目依赖项，以及用于 E2E 检查的 Playwright Chromium。在检出目录的 README 和 `package.json` 中确认前提条件。缺少前提条件或 PowerShell 执行策略阻止运行时，需要经批准的解决方案，而不是自动安装、绕过策略或悄悄改为直接运行 npm。
+
+## 运行技能
+
+确认上一课的开发服务器已停止。Playwright 会为 E2E 构建并提供预览服务，但其本地配置可以复用端口 `4321` 上的服务器。其他检出目录的服务器不能为当前功能提供有效证据。
+
+如果 app 提供 `/quality-checks`，选择它来显式调用已发现的技能，并附上以下请求。如果未发现技能，直接在此会话中发送相同请求；本练习支持通过读取技能的方式运行它。
+
+```plaintext
+读取 .github/skills/quality-checks/SKILL.md，并按照其中的指令验证此检出目录中的筛选功能。先检查每个封装脚本的代码，确认其推导出的目录包含此检出目录中预期的 package.json，且根目录无效时会明确报错并失败退出，而不是依赖 npm 在祖先目录中查找包。不要为模拟失败而移动、重命名、删除或修改存储库文件。实际运行其配套脚本，执行 lint、单元测试、端到端测试和类型检查。同时运行文档中只运行一个单元测试文件的示例，直接传递目标工具的参数，因为 npm 的 -- 分隔符由封装脚本负责。根据测试运行器的结果，确认仅运行了指定文件，并报告该文件名及实际执行的测试文件数量。仅回显参数或返回退出代码 0，不能证明文件选择正确。
+
+报告每次脚本调用及其结果，包括失败、跳过的检查或缺失的前提条件。不要在技能脚本无法使用时悄悄改为直接运行 npm 命令。确认待测试的检出目录和服务器，只停止你启动的服务器，并在安装任何内容或停止其他进程前询问。不要修改应用代码、切换分支、提交、推送或创建 pull request。
+```
+
+检查工具调用和输出。四个脚本都必须实际执行；描述检查内容或跳过检查都不算通过。对于单文件示例，将请求的文件名与运行器实际输出的文件结果及报告的数量进行比较：应只运行该文件。如果还运行了其他文件，回显参数或退出代码 0 都不足以证明正确。失败是有用的证据：修正技能，或在获批后解决环境配置阻碍，再重新运行受影响的检查。不要停止无关进程，也不要强行消除端口冲突。
+
+## 保存检查点
+
+检查技能及其运行结果后，授权创建本地检查点：
+
+```plaintext
+检查当前差异，仅为 quality-checks 技能文件创建检查点提交。保留现有筛选功能分支。不要推送或创建 pull request。
+```
+
+技能文件将与筛选功能、QA 配置和相关测试一起纳入第 8 课的功能 PR。继续在同一会话中完成[第 6 课 - 使用 Playwright MCP 验证功能][next-lesson]。
+
+## 更多技能示例
+
+以下社区示例仅供参考，不是额外任务。采用前先检查其前提条件和行为：
+
+- [贡献工作流：`make-repo-contribution`][contribution-example]。
+- [需求文档：`prd`][prd-example]。
+- [图表及配套导出脚本：`drawio`][drawio-example]。
+- [浏览器测试：`webapp-testing`][browser-example]。
+
+上游贡献示例名为 `make-repo-contribution`；旧版 Tailspin 模板使用另一个名称 `make-contribution`。本工作坊不依赖其中任何一个贡献技能。
+
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/zh-cn/app/5-mcp-playwright.md b/docs/zh-cn/app/5-mcp-playwright.md
deleted file mode 100644
index 5e288516..00000000
--- a/docs/zh-cn/app/5-mcp-playwright.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: "第 5 课 - 使用 Playwright MCP 服务器测试"
-description: "将 Playwright MCP 服务器添加到 GitHub Copilot app，并要求智能体在真实浏览器中手动测试筛选功能。"
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-上一课使用项目的自动化测试套件创建并验证了筛选功能。测试可以自动验证代码，但让智能体确认行为同样很有价值。智能体可以对它在实际 UI 中发现的问题作出响应。接下来探索 MCP 如何让 AI 智能体访问外部功能，并添加 Playwright MCP 服务器，使 Copilot 可以直接与正在构建的网站交互。
-
-本课将介绍如何：
-
-- 了解模型上下文协议 (MCP) 及 GitHub Copilot app 如何使用它。
-- 从应用设置中添加 Playwright MCP 服务器。
-- 要求智能体操控浏览器并探索筛选功能。
-
-## 场景
-
-单元测试和端到端测试很重要，但验证 UI 更新需要实际与 UI 交互。你希望 Copilot 能像用户一样使用正在开发的网站，以进一步自动执行更改并提高对更新符合预期的信心。
-
-## 什么是模型上下文协议 (MCP)？
-
-[模型上下文协议 (MCP)][mcp-blog-post] 为 AI 智能体提供了与外部工具和服务通信的方式。借助 MCP，AI 智能体可以实时与外部工具和服务通信。这让它们既能访问最新信息（使用资源），也能代表你执行操作（使用工具）。
-
-这些工具和资源通过 MCP 服务器访问。MCP 服务器是 AI 智能体与外部工具和服务之间的桥梁，负责管理双方的通信。外部工具可以是现有 API，也可以是 NPM 包等本地工具。每个 MCP 服务器代表 AI 智能体可访问的一组不同工具和资源。
-
-以下是两种常用的现有 MCP 服务器：
-
-- [**GitHub MCP Server**](https://github.com/github/github-mcp-server)：提供一组用于管理 GitHub 存储库的 API。AI 智能体可以创建新存储库、更新现有存储库，以及管理议题和拉取请求。
-- [**Playwright MCP Server**][playwright-mcp-server]：使用 Playwright 提供浏览器自动化功能。AI 智能体可以转到网页、填写表单和选择按钮。
-
-还有许多其他 MCP 服务器可用于访问不同的工具和资源。GitHub 托管了一个 [MCP registry](https://github.com/mcp)，以提高生态系统的可发现性并促进贡献。
-
-> [!CAUTION]
-> 应像对待项目中的任何其他依赖项一样对待 MCP 服务器。使用前请仔细审查其源代码、验证发布者并考虑安全影响。仅使用可信的 MCP 服务器，并谨慎授予对敏感资源或操作的访问权限。
-
-## 添加 Playwright MCP 服务器
-
-可以在应用设置中添加和管理 MCP 服务器。应用内置了常用服务器目录，只需几个步骤即可添加 [Playwright MCP 服务器][playwright-mcp-server]。
-
-1. 选择 Ctrl+, 打开 Copilot app 设置页面。
-2. 选择 **MCP servers**。
-3. 在搜索对话框中输入 `Playwright`。
-4. 从 **Popular MCP servers** 列表中选择 **Playwright**。
-5. 选择 **Add server**，将其添加到可用 MCP 服务器列表。
-6. 选择 Esc 关闭设置对话框。
-
-现在，Playwright MCP 服务器已添加。
-
-## 要求 Copilot 通过 Playwright 探索功能
-
-接下来要求 Copilot 使用 Playwright MCP 服务器手动测试该功能。
-
-1. 使用以下提示词，要求 Copilot 验证新功能：
-
- ```plaintext
- Start the dev server then use the Playwright MCP server to validate the functionality you just added exists. Use the details in the issue to ensure the newly added behavior matches the specs.
- ```
-
-Copilot 将通过 Playwright MCP 服务器启动浏览器、逐步执行每项操作并报告发现的结果。你会实际看到它在系统上打开浏览器执行任务。
-
-2. 对照议题中的验收标准阅读摘要。如果发现问题，请提出后续问题，或要求它在打开拉取请求前修复代码。
-3. 保持此会话打开，下一课将完成该会话。
-
-现在，Copilot 已像用户一样探索功能，并在浏览器中验证了其行为。
-
-## 总结与后续步骤
-
-你使用 Playwright MCP 服务器，从 GitHub Copilot app 在真实浏览器中探索了功能。总结来说，你：
-
-- 了解了模型上下文协议 (MCP)，以及应用如何提供 MCP 工具。
-- 从应用设置中添加了 Playwright MCP 服务器。
-- 要求智能体操控浏览器并探索筛选功能。
-
-功能已构建、验证并确认可以正常工作。现在可以使用 **Agent Merge** 打开并合并拉取请求。继续学习[第 6 课 - 使用 Agent Merge 合并][next-lesson]。
-
-## 资源
-
-- [MCP 是什么？为什么每个人都在谈论它？][mcp-blog-post]
-- [Microsoft Playwright MCP Server][playwright-mcp-server]
-- [在 GitHub Copilot app 中配置 MCP 服务器][customize-app]
-
-[next-lesson]: ../6-agent-merge/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
-[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
\ No newline at end of file
diff --git a/docs/zh-cn/app/6-agent-merge.md b/docs/zh-cn/app/6-agent-merge.md
deleted file mode 100644
index 6001d43d..00000000
--- a/docs/zh-cn/app/6-agent-merge.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: "第 6 课 - 使用 Agent Merge 合并"
-description: "打开筛选功能的拉取请求，在 My work 中进行审查，并让 Agent Merge 修复阻塞项并完成合并，这是合并自动化阶梯的最高一级。"
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-筛选功能已构建、验证，并确认可以在浏览器中正常工作。最后一步是将其合并。在本学习路径中，你已经合并过两次，每次都是自行打开拉取请求并在 github.com 上合并。这一次将使用 **Agent Merge** 让应用处理繁重工作。它可以在应用内管理拉取请求的整个生命周期。
-
-本课将介绍如何：
-
-- 了解 Agent Merge 及其如何自动执行合并生命周期。
-- 在筛选会话中启用 Agent Merge。
-- 观察它创建拉取请求、运行 CI，并在所有检查通过后合并。
-
-## 场景
-
-在前几课中，你探索了不同程度的自动化，从创建代码到让 Copilot 直接验证 UI。为了进一步加快开发速度，Tailspin Toys 希望了解是否可以自动合并经过审查和验证的拉取请求。
-
-## Agent Merge 简介
-
-通过 **Agent Merge**，可以使用 Copilot app 自动执行拉取请求落地前的最后阶段。启用后，应用会话会读取拉取请求并处理阻塞项，包括修复失败的 CI 检查、响应审查意见，以及在需要时变基。GitHub 允许后，它会立即合并。该功能在后台运行，应用重启后仍会继续，并在拉取请求合并后自动关闭。
-
-此前，你一直在 github.com 上自行选择 **Merge pull request**。Agent Merge 将这项责任交给智能体，因此它可以管理 PR 直至完成，而你可以继续处理下一项任务。你仍需审查并批准工作，智能体只负责机械性的收尾步骤。
-
-## 使用 Agent Merge 管理 PR
-
-你已手动审查代码、运行测试，甚至让 Copilot 验证了 UI。现在可以将新代码合并到代码库。接下来让 agent merge 管理 PR 的持续集成 (CI) 流程并完成合并。
-
-1. 返回上一课中用于添加筛选功能且仍保持打开的会话。
-2. 在右上角选择 **Create PR** 旁的下拉菜单。
-3. 选择 **Agent merge** 以启用 agent merge。
-
- 
-
-4. 按钮文本现在会变为 **Agent merge**。
-5. 选择 **Agent merge** 按钮，启动 agent merge 流程。
-
-Copilot app 随即开始创建并管理 PR。它先探索项目以确定创建 PR 的最佳方式，然后创建新 PR。
-
-片刻后，Copilot 会再次开始工作并查看 PR 条件，即运行存储库全部测试的 CI 流程。它会报告其他团队成员留下的审查状态、需要运行的检查（CI 流程），以及 PR 是否可合并。
-
-6. 选择 **Agent merge** 旁的下拉菜单，再选择 **Merge pull request**，允许 agent merge 合并拉取请求。
-
- 
-
-7. 所有 CI 流程变为绿色（表示测试通过）后，Copilot 会合并拉取请求。
-
-## 总结与后续步骤
-
-你已自动执行开发流程中的多个环节，包括生成代码、测试和验证代码，以及拉取请求流程。你：
-
-- 了解了 Agent Merge 及其如何自动执行合并生命周期。
-- 在筛选会话中启用了 Agent Merge。
-- 观察了它创建拉取请求、运行 CI，并在所有检查通过后完成合并。
-
-接下来，你将探索**画布**，这是一种与智能体共同规划和可视化工作的更丰富方式。继续学习[第 7 课 - 使用画布规划][next-lesson]。
-
-## 资源
-
-- [使用 GitHub Copilot app 管理议题和拉取请求][managing-issues-prs]
-- [关于 GitHub Copilot app][about-copilot-app]
-
-[next-lesson]: ../7-canvases/
-[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/zh-cn/app/6-mcp-playwright.md b/docs/zh-cn/app/6-mcp-playwright.md
new file mode 100644
index 00000000..42cd0885
--- /dev/null
+++ b/docs/zh-cn/app/6-mcp-playwright.md
@@ -0,0 +1,90 @@
+---
+title: "第 6 课 - 使用 Playwright MCP 验证功能"
+description: "通过 Customize 配置 Playwright MCP，在现有功能工作树中通过浏览器观察筛选功能。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+上一课通过 quality-checks 技能封装并运行了项目检查。现在让智能体访问浏览器，直接观察筛选 UI。保持同一筛选会话、工作树和分支。本课添加浏览器证据，而不是另一个功能、一次完整测试套件运行或一个 PR。
+
+本课将介绍如何：
+
+- 了解模型上下文协议 (MCP) 及 GitHub Copilot app 如何使用它。
+- 通过 **Customize** 添加 Playwright MCP 服务器。
+- 要求智能体操控浏览器并探索筛选功能。
+
+## 场景
+
+单元测试和端到端测试很重要，但验证 UI 更新需要实际与 UI 交互。你希望 Copilot 能像用户一样使用正在开发的网站，以进一步自动执行更改并提高对更新符合预期的信心。
+
+## 什么是模型上下文协议 (MCP)？
+
+[模型上下文协议 (MCP)][mcp-blog-post] 为 AI 智能体提供了与外部工具和服务通信的方式。借助 MCP，AI 智能体可以实时与外部工具和服务通信。这让它们既能访问最新信息（使用资源），也能代表你执行操作（使用工具）。
+
+这些工具和资源通过 MCP 服务器访问。MCP 服务器是 AI 智能体与外部工具和服务之间的桥梁，负责管理双方的通信。外部工具可以是现有 API，也可以是 NPM 包等本地工具。每个 MCP 服务器代表 AI 智能体可访问的一组不同工具和资源。
+
+以下是两种常用的现有 MCP 服务器：
+
+- [**GitHub MCP Server**](https://github.com/github/github-mcp-server)：提供一组用于管理 GitHub 存储库的 API。AI 智能体可以创建新存储库、更新现有存储库，以及管理议题和拉取请求。
+- [**Playwright MCP Server**][playwright-mcp-server]：使用 Playwright 提供浏览器自动化功能。AI 智能体可以转到网页、填写表单和选择按钮。
+
+还有许多其他 MCP 服务器可用于访问不同的工具和资源。GitHub 托管了一个 [MCP registry](https://github.com/mcp)，以提高生态系统的可发现性并促进贡献。
+
+> [!CAUTION]
+> 应像对待项目中的任何其他依赖项一样对待 MCP 服务器。使用前请仔细审查其源代码、验证发布者并考虑安全影响。仅使用可信的 MCP 服务器，并谨慎授予对敏感资源或操作的访问权限。
+
+## 添加 Playwright MCP 服务器
+
+当前的 [App 自定义文档][customize-app]使用侧边栏中的 **Customize** 来发现和管理 MCP。在存储库或 Copilot CLI 中配置的 MCP 服务器可能已在 App 中可用；添加前先检查已安装的服务器，避免重复。
+
+1. 在侧边栏中选择 **Customize**。
+2. 选择 **MCP**，再检查 **Installed** 中是否已有 Playwright 服务器。
+3. 如有需要，在可用服务器中找到 **Playwright**，或使用发布者文档说明的自定义服务器流程。
+4. 批准前审查发布者、配置和所有安装提示。按提示添加服务器；组织策略或缺少先决条件可能阻止设置。
+5. 返回现有筛选会话，保持 **Interactive** 模式。请求验证前，确认 Playwright MCP 浏览器工具可用。不要通过创建新的功能工作树来绕过设置问题。
+
+如果设置失败，应解决配置或权限问题，不要接受智能体未使用工具却声称已浏览的说法。浏览器是否可见取决于服务器配置；实际工具活动和观察结果才是证据。
+
+## 要求 Copilot 通过 Playwright 探索功能
+
+使用第 4 课保存的实际议题 URL 和批准的澄清内容。在智能体启动自己的服务器前，停止之前课程中手动启动的开发服务器。智能体必须确定被测检出目录和服务器。
+
+1. 使用以下提示词，要求 Copilot 验证新功能：
+
+ ```plaintext
+ 使用已配置的 Playwright MCP 服务器，根据此议题观察筛选功能：。以下是我批准的规划澄清内容：<粘贴约定的澄清内容，或填写 none>。保持当前筛选工作树和分支。
+
+ 确定检出目录，启动其开发服务器，并使用实际浏览器工具测试所要求的多类别选择、发行商筛选、组合筛选、无障碍控件，以及约定的清除筛选或空结果行为。根据验收标准报告观察结果，包括失败或受阻的检查。不要声称观察到了未实际观察的行为。
+
+ 此步骤是浏览器观察，不是再次运行完整自动化测试。不要更改应用代码、测试、技能或智能体配置文件，不要提交、推送或创建 PR。将缺少 MCP 工具或先决条件报告为受阻，并在安装任何内容前先询问。不要复用其他检出目录的服务器，也不要停止无关进程。完成后仅停止自己启动的服务器。
+ ```
+
+检查 Playwright MCP 工具调用、被测 URL 和报告中的浏览器观察结果。仅根据源代码或此前 E2E 结果撰写的描述，不能证明使用了 MCP。
+
+2. 对照议题和批准的澄清内容阅读摘要。如果发现缺陷，单独授权针对性修复，审查更改的差异，并重复相关自动化检查和浏览器观察。修复前的证据不能证明修复后版本的状态。
+3. 确认智能体已停止自己启动的服务器。保持筛选会话打开，并在第 7 课创建 QA 配置文件前保持 **Interactive** 模式。
+
+此阶段提供直接观察，不能替代自动化覆盖。失败或受阻的观察结果应保留，供 QA 使用。
+
+## 总结与后续步骤
+
+你使用 Playwright MCP 服务器，从 GitHub Copilot app 在真实浏览器中探索了功能。总结来说，你：
+
+- 了解了模型上下文协议 (MCP)，以及应用如何提供 MCP 工具。
+- 通过 **Customize** 配置了 Playwright MCP 服务器。
+- 要求智能体操控浏览器并探索筛选功能。
+
+接下来，通过专业配置文件将需求、浏览器观察、覆盖情况和技能结合起来。在同一会话中继续学习[第 7 课 - 创建并使用 QA 智能体][next-lesson]。暂时不要创建功能 PR。
+
+## 资源
+
+- [MCP 是什么？为什么每个人都在谈论它？][mcp-blog-post]
+- [Microsoft Playwright MCP Server][playwright-mcp-server]
+- [在 GitHub Copilot app 中配置 MCP 服务器][customize-app]
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
+[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
\ No newline at end of file
diff --git a/docs/zh-cn/app/7-canvases.md b/docs/zh-cn/app/7-canvases.md
deleted file mode 100644
index 0affd8dd..00000000
--- a/docs/zh-cn/app/7-canvases.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: "第 7 课 - 使用画布规划"
-description: "在 GitHub Copilot app 中创建智能体驱动的共享画布，与智能体共同规划和跟踪工作。"
-authors:
- - geektrainer
-lastUpdated: 2026-07-09
----
-
-此前，你通过聊天指挥智能体。但许多工作并不只存在于对话中，而是呈现在看板、文档或检查清单上。借助**画布**，你和智能体可以直接在应用内共享一个适合此类工作的界面。本课将创建一个简单画布，用于规划和跟踪一直在处理的待办事项。
-
-本课将介绍如何：
-
-- 了解画布是什么以及何时使用画布。
-- 创建共享的看板画布以对待办事项进行分类。
-- 将画布保存到存储库，并为团队合并更改。
-- 在新会话中打开画布，并从中开始工作。
-
-## 场景
-
-即使一切顺利，查看一长串议题也可能让人望而生畏。Tailspin Toys 的开发人员一直在寻找一种工具，用于快速对议题进行分类，并在 Copilot app 中着手处理。
-
-## 什么是画布？
-
-[画布][canvas-docs]是用于工作工件的共享交互式界面，例如计划、分类看板、发布检查清单、仪表板或文档。聊天非常适合描述意图和分析模糊问题，但大多数工作发生在具体的*界面*上。画布让你可以直接在该界面上与智能体协作。
-
-画布支持**双向交互**：智能体可以在工作过程中更新画布，你也可以自行编辑同一个界面。创建画布时，智能体会根据提示词和工作流进行构建；之后，可以要求它添加、删除或修改功能。画布创建后会在应用右侧面板中打开。
-
-常见示例包括：
-
-- 用于规划当天工作以及确定议题和拉取请求优先级的 **Markdown 画布**。
-- 由人员和智能体添加卡片并在列之间移动工作的**智能体看板**。
-- 汇总存储库重要议题和重复出现主题的**议题分类看板**。
-
-## 为什么使用画布？
-
-当任务需要结构、迭代和验证，且仅靠聊天不足以完成时，可以使用画布。画布让你能够：
-
-- 让智能体基于符合工作流的实际工件开展工作。
-- 直接在共享界面上引导或纠正工作，再让智能体从更改处继续。
-- 通过工件的可见更改检查进度，而不只是查看聊天回复。
-
-## 创建画布来跟踪工作
-
-你已经交付了许多内容：星级评分、文档标准和筛选功能都已合并。但待办事项中仍有其他工作。接下来创建画布，以便快速对这些工作进行分类。
-
-1. 返回（或打开）GitHub Copilot app。
-2. 选择 **Home screen**。
-3. 确保为存储库选择了 `tailspin-toys`。
-4. 在提示框中使用以下提示词，创建满足需求的画布：
-
- ```plaintext
- Create a basic Kanban board canvas that allows me to quickly triage work. Highlight the three issues which are most likely to need attention right now, with the remainder in a second section down below. The top three cards should include a description of the issue's content and a justification of why they're at the top of the list. Each issue should have a button that allows me to add it to the current context for the current session so I can get to work on it straightaway.
- ```
-
-Copilot 将开始创建画布。
-
-> [!NOTE]
-> 此过程需要几分钟。由于任务较复杂，第一版可能无法完全令人满意。可以继续发送提示词，逐步构建理想的工具。
-
-## 保存画布并合并到存储库
-
-与指令文件和技能一样，画布也可以成为存储库中的资产。接下来要求 Copilot 将画布添加到存储库并合并，让整个团队都能使用。
-
-1. 在同一会话中使用以下提示词，要求 Copilot 将画布保存到存储库：
-
- ```plaintext
- Let's save this canvas definition to the repository so I can share it with my development team
- ```
-
-2. Copilot 保存画布文件后，选择右上角 **Create PR** 旁的下拉菜单。
-3. 选择 **Agent merge** 以启用 agent merge。
-
- 
-
-4. 按钮文本现在会变为 **Agent merge**。
-5. 选择 **Agent merge** 按钮，启动 agent merge 流程。
-
-Copilot app 会开始创建并管理 PR。它先探索项目以确定创建 PR 的最佳方式，然后创建 PR。
-
-片刻后，Copilot 会再次开始工作并查看 PR 条件，即运行存储库全部测试的 CI 流程。它会报告其他团队成员留下的审查状态、需要运行的检查（CI 流程），以及 PR 是否可合并。
-
-6. 选择 **Agent merge** 旁的下拉菜单，再选择 **Merge pull request**，允许 agent merge 合并拉取请求。
-
- 
-
-7. 等待所有 CI 流程通过（变为绿色）。全部通过后，Copilot 会自动合并拉取请求。
-
-现在，你已经为团队创建了新的共享画布。
-
-## 在画布中工作
-
-画布创建后，接下来启动新会话并开始使用。
-
-1. 在 Copilot app 中，选择 **tailspin-toys** 旁的 **New session** 启动新会话。
-2. 使用以下提示词，要求 Copilot 打开分类画布：
-
- ```plaintext
- Open the triage issues canvas
- ```
-
-3. 现在应会看到所构建的画布已在新会话中打开。
-4. 在最感兴趣的一个议题上选择 **Add to current context**。
-5. Copilot 将开始处理该议题。
-
-现在，你已使用自己创建的画布简化了开发流程。
-
-## 总结与后续步骤
-
-你创建了一个可与智能体协作的共享界面。你：
-
-- 了解了画布是什么以及何时使用画布。
-- 与智能体共同创建了共享的看板分类画布。
-- 使用 Agent Merge 将画布保存并合并到存储库。
-- 在新会话中打开画布，并使用它开始工作。
-
-待办事项现已得到跟踪。接下来回顾已构建的所有内容，并了解后续方向。继续学习[第 8 课 - 回顾与后续步骤][next-lesson]。
-
-## 资源
-
-- [在 GitHub Copilot app 中使用画布扩展][canvas-docs]
-- [Awesome Copilot 上的画布][awesome-copilot-canvases]
-- [关于 GitHub Copilot app][about-copilot-app]
-
-[next-lesson]: ../8-review/
-[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
-[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
-[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/zh-cn/app/7-qa-agent.md b/docs/zh-cn/app/7-qa-agent.md
new file mode 100644
index 00000000..d877b608
--- /dev/null
+++ b/docs/zh-cn/app/7-qa-agent.md
@@ -0,0 +1,73 @@
+---
+title: "第 7 课 - 创建并使用 QA 智能体"
+description: "创建以需求为先的 QA 配置，将测试覆盖、quality-checks 技能和直接浏览器验证证据结合起来。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+你已运行可重复的检查，并通过 Playwright MCP 探索了筛选功能。现在创建一个 **QA 自定义智能体**，将需求、覆盖情况和浏览器验证证据结合起来。保留筛选功能会话、检出目录和分支；到第 8 课再创建功能 PR。
+
+## 创建 QA 配置
+
+保持 **Interactive** 模式。配置定义专业角色及其指令；技能封装可复用的任务指令、脚本和资源。QA 智能体将使用你的技能和已配置的 MCP 工具，而不是取代它们。
+
+发送以下提示，然后在运行前检查定义：
+
+```plaintext
+在 .github/agents/qa.agent.md 中创建可复用的 QA 自定义智能体。先检查存储库指令、package.json、测试配置和 .github/skills/quality-checks/SKILL.md。为配置提供有效的 YAML frontmatter，其中 name 为 QA，description 说明适用场景。不要固定模型或添加 tools 列表；继承当前使用环境的可用工具和权限。只创建智能体定义，然后停止，让我在运行前检查。
+
+在智能体指令中，要求每项 QA 任务都从用户提供的 issue 和已批准的验收标准出发。以这些需求而非实现为准。需求缺失或不明确时要询问。检查功能及现有测试，将每项标准映射到适当的自动化覆盖和可观察的行为。
+
+要求通过已配置的 Playwright MCP 服务器直接进行浏览器验证，并通过现有 quality-checks 技能及其配套脚本执行 lint、单元测试、端到端测试和类型检查。如果技能尚未被自动发现，则明确读取技能。缺少技能、MCP 工具、前提条件或访问权限时，报告为受阻；不要悄悄改用其他工作流，也不要把跳过的检查标记为通过。确认待测试的检出目录和服务器，避免复用其他工作树的服务器，只停止智能体自己启动的服务器，并在任何安装或停止其他进程前询问。
+
+允许 QA 智能体遵循存储库指令，为确实存在的覆盖缺口添加最少的必要测试；覆盖已经充分时，不添加测试也是有效结果。不要弱化断言、禁用失败测试、为迎合代码而修改验收标准，或未经我批准修改应用代码。更改后，重新运行受影响的检查，并对更改后的版本完成最终验证。要求提供简明报告，将标准映射到证据和通过/失败/受阻状态，列出新增测试或解释为何不需要，报告全部四项检查结果，并指出尚未解决的缺陷。只有具备所有必需的检查和证据，才能给出 GO；否则报告 NO-GO 并说明原因。QA 期间不要切换分支、提交、推送、创建或合并 PR，也不要创建其他智能体或技能。
+```
+
+## 检查配置
+
+在 **Changes** 或文件审查面板中打开 `.github/agents/qa.agent.md`。`description` 是必需字段；本课还将易读的 `name` 设置为 `QA`。确认没有固定 `model`，也没有虚构工具列表。省略 `tools` 会继承可用工具，但不会绕过使用环境的权限。生产配置可以有意限制工具。
+
+确认指令从需求出发，要求实际使用 MCP 浏览器工具和技能脚本，只允许有充分理由的测试补充，并如实报告阻碍。专业角色配置和技能都不要求独立的上下文窗口，也不要求编排其他智能体。
+
+## 根据 issue 运行 QA
+
+运行提示应发送给选中的 **QA** 自定义智能体，而不是让默认智能体读取配置。保持同一筛选功能检出目录和分支。
+
+1. 在当前会话中，打开提示框中的智能体选择器，或按 [app 自定义文档][customize-app]所述输入 `/agent`。
+2. 选择 **QA**，并在发送运行提示前确认 app 明确显示 **QA** 为当前活动智能体。
+3. 如果列表中没有 **QA**，或无法确认它已激活，暂停并向讲师求助，同时保留此工作树和分支。不要创建新的功能会话、虚构重新加载步骤，也不要改为让默认智能体读取 `qa.agent.md`。
+
+文档中的选择器可在会话期间使用，但能否发现新建的存储库配置取决于 app 版本。不要把写入文件当作已激活的证明。
+
+将两个占位符替换为实际筛选功能 issue 的 URL 和第 4 课中批准的澄清内容；如果 issue 已完整说明需求，则填写 `none`。不要依赖前一个智能体的记忆。
+
+```plaintext
+根据此 issue 验证筛选功能：。以下是我在规划期间批准的补充验收标准：<粘贴约定的澄清内容，或填写 none>。
+
+使用 Playwright MCP 服务器验证行为，检查测试覆盖，仅针对覆盖缺口添加测试，并通过 quality-checks 技能运行验证。报告证据、检查结果和阻碍。未经我批准，不要修改应用代码。不要创建提交或 pull request。
+```
+
+## 审查证据
+
+对照 issue 检查报告：每项标准都需要适当的自动化覆盖和可观察的行为。检查实际的 Playwright MCP 工具活动、检出目录和服务器身份，以及全部四项技能脚本结果。浏览器检查和自动化 E2E 不得复用过时的服务器或其他检出目录。
+
+审查新增测试：它们应填补真正的缺口，而不是弱化断言。覆盖充分时，不新增测试是正确做法。因受阻或失败而给出 **NO-GO** 是有效结果，不代表可以跳过证据。
+
+如果 QA 发现应用缺陷，另行批准针对性修复，并在更改后的版本上重新执行受影响的检查和浏览器观察。缺少前提条件或工具时，需要明确的解决方案。不要将旧证据当作更改后代码的证明。
+
+## 保存检查点
+
+QA 完成后，保留其报告、issue URL、已批准的澄清内容和测试过的版本，以便后续使用。在同一会话中，使用文档中介绍的智能体选择器返回普通 Copilot 智能体，并确认 **QA** 已不再选中。保持同一检出目录和分支；不要启动其他功能会话或重新加载工作树。如果找不到普通智能体选项，暂停并向讲师求助，不要向 QA 发送提交指令。
+
+审查配置、测试更改及相应证据后，将检查点请求连同这些 QA 上下文一起发送给普通智能体：
+
+```plaintext
+检查当前差异，为 QA 智能体定义和已批准的测试更改创建检查点提交。保留现有筛选功能分支。不要推送或创建 pull request。
+```
+
+带着筛选功能、技能、QA 配置、测试和当前验证证据，继续完成[第 8 课 - 创建并合并功能 PR][next-lesson]。
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[customize-app]: https://docs.github.com/copilot/how-tos/github-copilot-app/customize-github-copilot-app
diff --git a/docs/zh-cn/app/8-create-pull-request.md b/docs/zh-cn/app/8-create-pull-request.md
new file mode 100644
index 00000000..50321d1d
--- /dev/null
+++ b/docs/zh-cn/app/8-create-pull-request.md
@@ -0,0 +1,89 @@
+---
+title: "第 8 课 - 创建并合并功能 PR"
+description: "一并审查筛选功能、技能、QA 配置文件和测试，创建 PR 3，并明确授权 Agent Merge。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+筛选实现、quality-checks 技能、QA 配置文件及相关测试已通过检查点提交保存在同一分支上。一并审查这些内容，并使用当前 QA 证据准备 PR 3。你已经明确合并了星级评分和指令 PR。这次将在 PR 工作流中使用 **Agent Merge**，而不是为其创建单独的功能或分支。
+
+本课将介绍如何：
+
+- 了解 Agent Merge 及其如何自动执行合并生命周期。
+- 检查完整的功能 PR 和验证证据。
+- 审查后再授权 Agent Merge，并确认 PR 已合并。
+
+## 场景
+
+在前几课中，你探索了不同程度的自动化，从创建代码到让 Copilot 直接验证 UI。为了进一步加快开发速度，Tailspin Toys 希望了解是否可以自动合并经过审查和验证的拉取请求。
+
+## Agent Merge 简介
+
+通过 **Agent Merge**，可以使用 Copilot app 自动执行拉取请求落地前的最后阶段。启用后，应用会话会读取拉取请求并处理阻塞项，包括修复失败的 CI 检查、响应审查意见，以及在需要时变基。GitHub 允许后，它会立即合并。该功能在后台运行，应用重启后仍会继续，并在拉取请求合并后自动关闭。
+
+此前，你一直自行选择 **Merge pull request**。Agent Merge 可以承担这项工作，但它编辑代码和合并的能力仍需要明确授权。授予合并权限前，先审查它允许执行的操作及工作内容。
+
+## 审查完整的里程碑
+
+留在第 4–7 课的筛选会话中。检查相对于 `main` 的完整分支差异，而不只是最新检查点：其中应包含筛选功能、`.github/skills/quality-checks/SKILL.md`、随附脚本、`.github/agents/qa.agent.md` 和相关测试。
+
+请求提交或 PR 操作前，使用智能体选择器从 **QA** 切回通用 Copilot 智能体，并保持 **Interactive** 模式。QA 配置文件的职责是验证，而不是交付。更换所选智能体不得改变筛选会话、检出目录或分支。
+
+本研讨会有意将功能工作和可复用质量基础设施放在同一个 PR 中。生产团队可能会将两者拆分；这里使用检查点提交保留便于审查的步骤，无需堆叠分支或额外创建 PR。
+
+审查第 7 课的 QA 报告。只有报告涵盖待提交的最终修订版本，且已完成全部四项检查和相关浏览器观察，才能复用其中的证据。如果代码改动、冲突解决或 CI 修复改变了被测内容，应重新运行受影响的检查和浏览器观察，并更新证据。失败或受阻的 **NO-GO** 报告不代表批准合并。
+
+差异和证据准备就绪后，发送：
+
+```plaintext
+审查筛选分支相对于 main 的完整差异，包括筛选功能、quality-checks 技能及脚本、QA 智能体定义和相关测试。汇总议题标准、批准的澄清内容及当前 QA 证据。仅在验证仍适用于最终修订版本时复用；继续前报告过时、缺失或失败的证据。
+
+如果已审查的更改和验证已就绪，提交剩余的已批准里程碑更改，推送当前分支，并使用存储库的 PR 模板和实际筛选议题 URL，创建一个以 main 为目标的功能 PR。保留当前分支上的检查点历史。不要使用贡献技能、创建其他分支或 PR，也不要合并。
+```
+
+在 **My work** 中打开 PR，检查 **Files changed**、描述、审查和检查结果。查看 Tailspin Toys 自己的工作流文件和必需检查；不要假设每项本地检查或浏览器观察都会在 CI 中运行。研讨会发布站点的 Astro 构建和链接检查器属于另一个存储库，不能验证此功能。
+
+## 使用 Agent Merge 管理 PR
+
+审查现有 PR 后，在同一会话中配置 Agent Merge。不要创建第二个 PR。
+
+1. 返回筛选会话，确认其已关联 PR 3。
+2. 打开右上角的 PR 操作下拉菜单。PR 创建前，它位于 **Create PR** 旁；关联 PR 后，标签可能变化。
+3. 选择 **Agent merge** 以启用 agent merge。
+4. 审查可用权限，包括 **Address reviews**、**Fix CI failures**、**Resolve conflicts** 和 **Merge pull request**。发现的问题或验证尚未解决时，保持合并权限关闭。
+5. 启动前，发送以下范围和授权说明，再选择 **Agent merge**：
+
+ ```plaintext
+ 使用 Agent Merge 管理此现有筛选 PR。仅在该 PR 范围内处理审查或 CI 阻塞项。不要弱化测试或需求，并在无关更改或安装前先询问。只要被测修订版本发生改动，就需要更新相关检查和浏览器证据；不要将旧 QA 结果当作更改后代码的证明。
+
+ 在我审查最终差异和证据并明确启用 Merge pull request 前，不要合并。不要创建其他 PR 或开始画布任务。
+ ```
+
+6. 审查后续更改和更新后的结果。最终差异获批、必需的 CI 和审查通过，且 QA 证据适用于该修订版本后，选择 **Agent merge** 旁的下拉菜单，再选择 **Merge pull request**，明确授权合并。
+
+ 
+
+7. 确认 GitHub 显示 PR 3 为 **Merged**，而不只是可合并或已排队。Agent Merge 不会绕过存储库保护或缺失的权限；解决这些阻塞项后再继续。
+
+只有合并完成后，才能开始画布里程碑。第 9 课会创建新工作树，并将其会话分支快进到最新的 `origin/main`，确保画布工作从完整合并后的功能状态开始。
+
+## 总结与后续步骤
+
+你已自动执行开发流程中的多个环节，包括生成代码、测试和验证代码，以及拉取请求流程。你：
+
+- 了解了 Agent Merge 及其如何自动执行合并生命周期。
+- 将筛选功能、技能、QA 配置文件和测试的完整差异作为 PR 3 进行了审查。
+- 复用了当前 QA 证据，检查了 CI，并明确授权了 Agent Merge。
+
+接下来，你将探索**画布**，这是一种与智能体共同规划和可视化工作的更丰富方式。继续学习[第 9 课 - 创建分类画布][next-lesson]。
+
+## 资源
+
+- [使用 GitHub Copilot app 管理议题和拉取请求][managing-issues-prs]
+- [关于 GitHub Copilot app][about-copilot-app]
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-canvases/
+[managing-issues-prs]: https://docs.github.com/copilot/how-tos/github-copilot-app/managing-issues-and-pull-requests
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/zh-cn/app/9-canvases.md b/docs/zh-cn/app/9-canvases.md
new file mode 100644
index 00000000..6b59aa12
--- /dev/null
+++ b/docs/zh-cn/app/9-canvases.md
@@ -0,0 +1,148 @@
+---
+title: "第 9 课 - 创建分类画布"
+description: "创建并审查保存在存储库中的分类画布，合并 PR 4，再重新打开画布以添加议题上下文，而不开始其他功能。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+此前，你通过聊天指挥智能体。但许多工作并不只存在于对话中，而是呈现在看板、文档或检查清单上。借助**画布**，你和智能体可以直接在应用内共享一个适合此类工作的界面。本课将创建一个简单画布，用于规划和跟踪一直在处理的待办事项。
+
+本课将介绍如何：
+
+- 了解画布是什么以及何时使用画布。
+- 创建共享的看板画布以对待办事项进行分类。
+- 将画布保存到存储库，并为团队合并更改。
+- 重新打开画布并添加议题上下文，而不实现其他功能。
+
+## 场景
+
+查看一长串议题可能让人望而生畏。Tailspin Toys 的开发人员希望有一个工具来分类议题，并将其详情加入会话上下文。添加上下文并不代表授权实现该议题；本练习以可复用的看板结束，而不是创建第五个 PR。
+
+## 什么是画布？
+
+[画布][canvas-docs]是用于工作工件的共享交互式界面，例如计划、分类看板、发布检查清单、仪表板或文档。聊天非常适合描述意图和分析模糊问题，但大多数工作发生在具体的*界面*上。画布让你可以直接在该界面上与智能体协作。
+
+画布支持**双向交互**：智能体可以在工作过程中更新画布，你也可以自行编辑同一个界面。创建画布时，智能体会根据提示词和工作流进行构建；之后，可以要求它添加、删除或修改功能。画布创建后会在应用右侧面板中打开。
+
+常见示例包括：
+
+- 用于规划当天工作以及确定议题和拉取请求优先级的 **Markdown 画布**。
+- 由人员和智能体添加卡片并在列之间移动工作的**智能体看板**。
+- 汇总存储库重要议题和重复出现主题的**议题分类看板**。
+
+## 为什么使用画布？
+
+当任务需要结构、迭代和验证，且仅靠聊天不足以完成时，可以使用画布。画布让你能够：
+
+- 让智能体基于符合工作流的实际工件开展工作。
+- 直接在共享界面上引导或纠正工作，再让智能体从更改处继续。
+- 通过工件的可见更改检查进度，而不只是查看聊天回复。
+
+## 创建画布来跟踪工作
+
+确认 PR 3 已合并。开始画布工作前，星级评分、文档标准、筛选功能、质量技能和 QA 配置文件必须都已进入 `main`。为这个最终 PR 里程碑使用一个新会话和一个分支。
+
+1. 返回（或打开）GitHub Copilot app。
+2. 选择 **Home screen**。
+3. 确保为存储库选择了 `tailspin-toys`。
+4. 选择 **new working tree** 和 **Interactive** 模式。创建任何文件前，发送以下基线请求：
+
+ ```plaintext
+ 准备这个新的画布会话，不要实现任何内容。确认这是一个干净的新工作树，获取 origin，并将当前会话分支快进到 origin/main。报告检出目录、分支，以及相互一致的 HEAD 和 origin/main 修订版本。验证筛选 PR 已合并，且筛选功能、quality-checks 技能和 QA 配置文件均已存在。
+
+ 如果检出目录不干净、已发生分叉或缺少之前的合并，停止。不要重置、丢弃工作、切换分支或创建其他分支。报告基线后停止。
+ ```
+
+5. 检查基线报告，再请求创建保存在存储库中的画布：
+
+ ```plaintext
+ 使用 App 支持的画布扩展工作流，为此存储库创建一个基本的 Kanban 分类画布，并将其保存在存储库中。将定义保存到 .github/extensions/ 下，以便团队复用。检查并保留现有扩展；不要覆盖随附的数据库浏览器。
+
+ 阅读当前未关闭的议题。突出显示最可能需要关注的三个，其余议题放在下方。每个突出显示的议题都应包含标题、内容摘要、URL 和优先级理由。将排序视为建议，而不是修改议题的指令。
+
+ 为每张卡片提供 Add to current context 操作，仅将议题详情加入当前会话。此操作不得开始实现、创建会话或分支、修改议题状态或创建 PR。保持画布范围明确，并支持键盘操作。
+
+ 向我展示生成的文件，并打开画布供我检查。不要更改应用代码、提交、推送或创建 PR。在安装任何内容或添加依赖项前先询问。
+ ```
+
+Copilot 会创建画布文件并打开共享界面。信任其操作前，先审查生成的扩展；它是可执行的存储库内容，而不只是一幅图。
+
+> [!NOTE]
+> 如果第一版需要改进，在分类任务范围内请求针对性调整。不要把本练习变成实现某个待办议题。
+
+## 检查并操作画布
+
+1. 打开 **Changes**，确认画布定义保存在存储库的 `.github/extensions/` 下，而不是仅保存到用户或会话。检查现有扩展和应用文件是否保持不变。
+2. 将看板与实际未关闭的议题进行比较，并评估排序说明。
+3. 检查卡片和控件是否清晰可读，且支持键盘操作。
+4. 为一个议题选择 **Add to current context**，确认只有议题详情进入对话，不应开始实现或更改议题状态。
+5. 审查所有修正，并让 Copilot 对更改的文件运行适用的现有验证。记录结果和阻塞项，不要仅因为交互界面能打开就假定它正确。
+
+## 保存画布并合并到存储库
+
+画布已经是存储库资产。仅将已审查的画布工作提交为 PR 4：
+
+1. 在同一会话中发送：
+
+ ```plaintext
+ 审查保存在存储库中的分类画布差异及其验证证据。在当前会话分支上提交已批准的画布文件，推送分支，并使用存储库的 PR 模板创建一个以 main 为目标的 PR。描述画布行为，以及我们如何验证添加议题只会添加上下文。暂时不要合并，也不要实现待办议题。
+ ```
+
+2. 在 **My work** 中审查完整的 PR 差异和检查结果。确认其中包含画布，而不是无关的应用工作。
+3. 在同一画布会话中打开 PR 操作下拉菜单，选择 **Agent merge**。审查其允许执行的操作，在批准最终结果前保持 **Merge pull request** 关闭。
+4. 启动 Agent Merge 前明确范围：
+
+ ```plaintext
+ 使用 Agent Merge 管理此现有画布 PR。仅处理范围内的审查和 CI 阻塞项；在无关更改或安装前先询问。如果画布发生变化，重复受影响的验证并更新证据。在我审查后明确启用 Merge pull request 前，不要合并。不要实现待办议题或创建其他 PR。
+ ```
+
+5. 选择 **Agent merge**，审查后续更改。检查练习存储库实际的 CI 检查并解决失败项；CI 不能替代实际操作画布进行验证。
+
+6. 最终差异和当前证据获批，且必需的检查和审查通过后，选择 Agent Merge 下拉菜单，再选择 **Merge pull request**，明确允许合并。
+
+ 
+
+7. 确认 GitHub 显示 PR 4 为 **Merged** 后再继续。
+
+现在，你已经为团队创建了新的共享画布。
+
+## 重新打开画布，但不开始其他功能
+
+画布 PR 合并后，在同一画布会话中重新打开保存在存储库中的画布。这是检查步骤，而不是另一个分支或 PR 里程碑。
+
+1. 返回画布会话，保持 **Interactive** 模式；如果画布面板仍打开，先关闭它。
+2. 发送：
+
+ ```plaintext
+ 在同一会话中重新打开存储库的分类画布。我会将一个议题加入上下文，仅用于检查其详情。不要编辑文件、实现议题、更改其状态、创建其他会话或分支、提交、推送或打开 PR。
+ ```
+
+3. 确认已保存的画布再次打开，而没有重新生成其定义。
+4. 在最感兴趣的一个议题上选择 **Add to current context**。
+5. 确认所选议题的详情出现在上下文中，而没有开始实现。到此停止：本研讨会有四个 PR 里程碑，而不是五个。
+
+现在，你已使用自己创建的画布简化了开发流程。
+
+## 总结与后续步骤
+
+你创建了一个可与智能体协作的共享界面。你：
+
+- 了解了画布是什么以及何时使用画布。
+- 与智能体共同创建了共享的看板分类画布。
+- 使用 Agent Merge 将画布保存并合并到存储库。
+- 重新打开已合并的画布，添加议题上下文，而不启动其他功能。
+
+待办事项现已得到跟踪。接下来回顾已构建的所有内容，并了解后续方向。继续学习[第 10 课 - 总结与后续步骤][next-lesson]。
+
+## 资源
+
+- [在 GitHub Copilot app 中使用画布扩展][canvas-docs]
+- [Awesome Copilot 上的画布][awesome-copilot-canvases]
+- [关于 GitHub Copilot app][about-copilot-app]
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[canvas-docs]: https://docs.github.com/copilot/how-tos/github-copilot-app/working-with-canvas-extensions
+[awesome-copilot-canvases]: https://awesome-copilot.github.com/extensions/
+[about-copilot-app]: https://docs.github.com/copilot/concepts/agents/github-copilot-app
\ No newline at end of file
diff --git a/docs/zh-cn/app/README.md b/docs/zh-cn/app/README.md
index 106881c3..0da89e43 100644
--- a/docs/zh-cn/app/README.md
+++ b/docs/zh-cn/app/README.md
@@ -3,12 +3,14 @@ slug: zh-cn/app
title: "GitHub Copilot app"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
[**GitHub Copilot app**](https://docs.github.com/copilot/concepts/agents/github-copilot-app) 是一款基于 Copilot CLI 构建的桌面应用，可将智能体驱动的开发集中到一个专注的工作区。它支持并行智能体会话、可切换的会话模式、共享画布，以及原生的 GitHub 议题和拉取请求管理功能。其中包括 **Agent Merge**，可处理拉取请求的变基、审查反馈、CI 修复与合并。
-在这些课程中，你将安装应用并设置项目，然后熟悉应用工作区和模板为你创建的待办事项。你会先完成一项小改动，即添加星级评分；再根据议题添加自定义指令标准，在隔离的智能体会话中构建筛选功能，并使用可复用技能进行验证。随后，你将添加 Playwright MCP 服务器，在真实浏览器中探索该功能，并逐步提高合并自动化程度，最终由 **Agent Merge** 合并拉取请求。最后，你将通过共享画布协作并自动执行重复性工作，完整体验从构想到功能合并的流程。
+设置课程第 0–1 课帮助你准备项目和 App 工作区。九个核心模块，即第 2–10 课，从添加星级评分快速上手，再通过真实代码展示文档约定。随后规划并构建筛选功能，创建并执行包含 shell 脚本的 quality-checks 技能，通过 Playwright MCP 观察功能，再创建 QA 自定义智能体来评估需求和覆盖情况。你将审查完整的功能 PR 并授权 Agent Merge，最后创建并合并共享分类画布。
+
+本研讨会有四个 PR 里程碑：星级评分；指令及示例改动；筛选功能及技能、QA 配置文件和测试；最后是画布。每个里程碑都从更新后的 `main` 开始，每个 PR 使用一个分支，而不是每个模块一个分支。第 4–8 课沿用同一筛选会话、工作树和分支。重新打开画布只添加议题上下文，不启动其他功能或第五个 PR。自动化任务作为后续方向提供链接，而不是额外练习。
## 课程
@@ -16,13 +18,15 @@ lastUpdated: 2026-06-30
|--------|-------|-------------|
| [0. 先决条件][ex0] | 设置 | 安装 Node.js，并创建自己的 Tailspin Toys 项目副本 |
| [1. 安装 Copilot app][ex1] | 设置 | 安装应用、连接项目并熟悉工作区 |
-| [2. 运行第一个智能体会话][ex2] | 首次更改 | 启动会话，并通过第一个拉取请求交付一项小改动 |
-| [3. 使用自定义指令引导 Copilot][ex3] | 上下文 | 根据议题添加文档标准并合并更改 |
-| [4. 使用 Autopilot 构建功能][ex4] | 核心功能 | 使用 Plan 和 Autopilot 构建筛选功能，再通过技能进行验证 |
-| [5. 使用 Playwright MCP 测试][ex5] | 外部工具 | 添加 Playwright MCP 服务器，并在浏览器中探索功能 |
-| [6. 使用 Agent Merge 合并][ex6] | 合并 | 让 Agent Merge 修复并合并筛选功能的拉取请求 |
-| [7. 使用画布规划][ex7] | 协作 | 创建共享画布来规划和跟踪工作 |
-| [8. 回顾与后续步骤][ex8] | 总结 | 自动执行重复性任务，并探索后续内容 |
+| [2. 添加星级评分：快速上手][ex2] | 首次更改 | 显示现有评分和空值回退状态，再合并 PR 1 |
+| [3. 使用自定义指令引导 Copilot][ex3] | 上下文 | 添加文档标准和真实示例改动，再合并 PR 2 |
+| [4. 使用 Plan 和 Autopilot 构建筛选功能][ex4] | 实现 | 批准计划，实现并检查筛选功能，保存检查点 |
+| [5. 创建并使用 quality-checks 技能][ex5] | 可重复检查 | 创建、审查并执行随附的 shell 脚本 |
+| [6. 使用 Playwright MCP 验证功能][ex6] | 浏览器观察 | 通过 Customize 配置 MCP，并检查筛选行为 |
+| [7. 创建并使用 QA 智能体][ex7] | 需求与覆盖 | 选择专业配置文件，收集最终验证证据 |
+| [8. 创建并合并功能 PR][ex8] | 审查与合并 | 审查筛选功能、技能、QA 配置文件和测试，再为 PR 3 授权 Agent Merge |
+| [9. 创建分类画布][ex9] | 协作 | 通过 PR 4 共享保存在存储库中的画布，并添加议题上下文 |
+| [10. 总结与后续步骤][ex10] | 总结 | 回顾工作流、产出及更多资源 |
## 先决条件
@@ -50,9 +54,11 @@ lastUpdated: 2026-06-30
[ex2]: 2-add-star-rating/
[ex3]: 3-custom-instructions/
[ex4]: 4-build-filtering/
-[ex5]: 5-mcp-playwright/
-[ex6]: 6-agent-merge/
-[ex7]: 7-canvases/
-[ex8]: 8-review/
+[ex5]: 5-agent-skills/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-canvases/
+[ex10]: 10-review/
[install-git]: https://github.com/git-guides/install-git
[callout-student-plan-education]: https://github.com/education/students
\ No newline at end of file
diff --git a/docs/zh-cn/cli/0-prerequisites.md b/docs/zh-cn/cli/0-prerequisites.md
index 0bc2d6a8..8c2fd273 100644
--- a/docs/zh-cn/cli/0-prerequisites.md
+++ b/docs/zh-cn/cli/0-prerequisites.md
@@ -2,7 +2,7 @@
title: "练习 0：先决条件"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
开始 Copilot CLI 练习前，需要先完成环境准备。将先创建 Tailspin Toys 存储库的个人副本，再启动一个 [codespace][codespaces]。下一节练习会使用其中集成的终端来安装并运行 Copilot CLI。
@@ -11,6 +11,8 @@ lastUpdated: 2026-06-30
为了给即将编写的代码创建一份存储库副本，需要基于 [模板][template-repository] 创建一个实例。这个新实例会包含实验所需的全部文件，后续练习都会在其中完成。
+使用模板的新副本。其中包含存储库指令、应用代码、测试和 CI，但不附带自定义智能体或技能。你将自行创建这些资产。如果回到旧副本，应先检查现有自定义配置再修改，不要覆盖自己的工作。
+
1. 在新的浏览器窗口中，访问本实验的 GitHub 存储库：`https://github.com/github-samples/tailspin-toys`。
2. 在实验存储库页面上，选择 **Use this template** 按钮创建自己的存储库副本。然后选择 **Create a new repository**。
@@ -27,6 +29,8 @@ lastUpdated: 2026-06-30
>
> 通过模板创建存储库时，系统会自动创建一组 GitHub issue 作为积压工作。整个工作坊都会围绕这些 issue 展开，无需手动新建。
+等待议题初始化工作流完成，再到 **Issues** 选项卡中查找 **Allow users to filter games by category and publisher** 和 **Update our repository coding standards**。课程中使用它们的实际标题和 URL，不要假设议题编号。如果待办事项缺失，应先检查工作流结果再继续。
+
## 创建 codespace
接下来，将使用 codespace 完成实验练习。
@@ -50,8 +54,7 @@ codespace 的创建需要几分钟，但仍然比手动安装所有服务快得
> [!NOTE]
> 本工作坊设计为在 codespace 或本地 [dev container][dev-containers] 中运行。这两种方式都能确保环境已安装顺畅体验所需的全部先决条件。如果更希望在本地运行，请在 VS Code 中打开克隆后的存储库，并在出现提示时选择 **Reopen in Container**——VS Code 会构建与 codespace 相同的 dev container。
-[codespaces]: https://github.com/features/codespaces
-[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
+codespace 准备就绪后，[练习 1][next-lesson]将打开其终端，在安装 Copilot CLI 前检查存储库、运行时和身份验证。
## 总结
@@ -70,3 +73,5 @@ codespace 的创建需要几分钟，但仍然比手动安装所有服务快得
[template-repository]: https://docs.github.com/repositories/creating-and-managing-repositories/creating-a-template-repository
[codespaces-quickstart]: https://docs.github.com/codespaces/getting-started/quickstart
[next-lesson]: ../1-install-copilot-cli/
+[codespaces]: https://github.com/features/codespaces
+[dev-containers]: https://code.visualstudio.com/docs/devcontainers/containers
diff --git a/docs/zh-cn/cli/1-install-copilot-cli.md b/docs/zh-cn/cli/1-install-copilot-cli.md
index 31795df0..1990f5d4 100644
--- a/docs/zh-cn/cli/1-install-copilot-cli.md
+++ b/docs/zh-cn/cli/1-install-copilot-cli.md
@@ -2,7 +2,7 @@
title: "练习 1 - 安装 GitHub Copilot CLI"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
[GitHub Copilot CLI][about-copilot-cli] 是一个功能强大的代理式编码助手，可在终端中运行，让开发者通过命令行探索代码库、生成代码、运行命令并与外部工具交互。它可以帮助分担任务、请求变更，并保持专注。第一步自然是安装这个工具，好在可以使用已经熟悉的工具来完成。
@@ -21,10 +21,25 @@ lastUpdated: 2026-06-30
安装 Copilot CLI 前，需要先在 codespace 中打开终端窗口。
-1. 如果当前不在 codespace 中，请先返回。
+1. 返回 codespace，等待设置完成。
2. 按 Ctrl+\` 打开终端窗口。
3. 应该会在 VS Code 窗口底部看到终端面板。
+## 确认练习环境
+
+在 codespace 终端中，确认当前位于自己的 Tailspin Toys 存储库，而不是研讨会内容存储库。阅读其中的 `README.md` 和 `package.json`，了解设置和检查命令。当前 Tailspin Toys 需要 Node.js 22.13 或更高版本、项目依赖项，以及用于 E2E 测试的 Playwright Chromium。
+
+```bash
+pwd
+git remote -v
+node --version
+gh auth status
+```
+
+GitHub CLI（`gh`）可帮助检查 PR 和 CI。如果尚未完成身份验证，使用 `gh auth login` 并遵循浏览器指引。确认当前账户能够在此存储库中推送分支、创建及合并 PR；组织策略可能要求其他审查者参与。开始代码更改前，按存储库设置说明解决缺失的先决条件，并在授权安装前进行审查。
+
+CLI 使用启动时所在的检出目录；开始对话不会自动创建隔离的工作树。本研讨会为每个 PR 里程碑使用一个分支。先合并星级评分和指令示例，再在练习 4–8 中保持同一筛选分支。
+
## 安装 Copilot CLI
可以通过 [npm][install-npm]、[WinGet][install-winget] 和 [Homebrew][install-homebrew] 安装 Copilot CLI。由于 GitHub Codespaces 已预装 Node.js，本练习使用 npm 安装 Copilot CLI。
@@ -35,7 +50,7 @@ lastUpdated: 2026-06-30
node --version
```
- 应看到版本 22 或更高（例如 `v22.x.x`）。
+ Tailspin Toys 需要 22.13 或更高版本，即使 CLI 自身的要求有所不同。如果版本过旧，请遵循练习存储库的设置说明。
2. 使用 npm 在 codespace 中全局安装 Copilot CLI：
@@ -51,8 +66,8 @@ lastUpdated: 2026-06-30
应看到显示的版本号（例如 `v1.0.XX`）。
-> [!TIP]
-> 如果遇到权限错误，在某些系统中可能需要使用 `sudo npm install -g @github/copilot`。不过在 GitHub Codespaces 中通常不需要这样做。
+> [!NOTE]
+> 如果安装因权限错误而失败，应检查 npm 配置或向研讨会导师求助，而不是提升权限后重新运行不熟悉的命令。
## 使用 GitHub 完成验证
@@ -85,22 +100,39 @@ lastUpdated: 2026-06-30
2. 对于本工作坊，请选择 **Yes, and remember this folder for future sessions**，因为后续会持续在这个存储库中工作。
3. 向 Copilot 提一个简单问题，确认它运行正常：
- ```
- What files are in this project?
+ ```plaintext
+ 这个项目中有哪些文件？
```
4. Copilot 应该会探索存储库，并给出项目结构摘要。
5. 试用 `/help` 命令查看可用的斜杠命令：
- ```
+ ```text
/help
```
-6. 在终端中输入以下命令退出 Copilot CLI。后续练习还会回到 Copilot CLI。
+6. 在 Copilot 提示符处输入以下命令，退出此会话。你将为第一次更改启动新会话。
+ ```text
+ /exit
```
- exit
- ```
+
+## 了解模式和权限
+
+Copilot CLI 在启动时所在的目录和 Git 分支中工作。信任目录使其能够使用存储库上下文，但不等于批准所有工具操作。应审查文件更改、shell 命令和 GitHub 操作的权限请求。
+
+从练习存储库根目录启动代码练习：
+
+```bash
+copilot --enable-all-github-mcp-tools
+```
+
+GitHub MCP 服务器是内置的。此标志提供完整工具集，供处理议题和 PR；身份验证、存储库权限和工具批准仍然适用。该标志本身并不授权提交或创建 PR。
+
+使用 Shift+Tab 在标准 **Interactive**、**Plan** 和 **Autopilot** 模式之间切换。发送请求前检查模式指示器。早期更改保持 Interactive，构建筛选功能前先规划，创建和审查自定义配置前明确切回 Interactive。
+
+> [!CAUTION]
+> 模式和权限设置是两回事。Autopilot 会自主持续工作；`--allow-all` 及其别名 `--yolo` 则授予全部工具、路径和 URL 权限。本研讨会不要求每个会话都使用无限制权限启动。即使在 codespace 中，授予访问权限前也应审查范围。
## 总结和后续步骤
@@ -111,7 +143,7 @@ lastUpdated: 2026-06-30
- 信任一个目录，以便 Copilot CLI 可以处理其中内容。
- 确认安装运行正常。
-现在 Copilot CLI 已安装完成，接下来为 Copilot 提供一些项目上下文。继续前往[练习 2 - 通过 CLI 使用自定义说明][next-lesson]。
+现在 Copilot CLI 已安装完成，前往[练习 2 - 添加星级评分：快速上手][next-lesson]，完成一项便于审查的小改动。
## 资源
@@ -120,7 +152,7 @@ lastUpdated: 2026-06-30
- [使用 Copilot CLI][using-copilot-cli]
[previous-lesson]: ../0-prerequisites/
-[next-lesson]: ../2-custom-instructions/
+[next-lesson]: ../2-add-star-rating/
[install-copilot-cli]: https://docs.github.com/copilot/how-tos/set-up/install-copilot-cli
[install-npm]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-npm-all-platforms
[install-winget]: https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli#installing-with-winget-windows
diff --git a/docs/zh-cn/cli/10-review.md b/docs/zh-cn/cli/10-review.md
new file mode 100644
index 00000000..0c1e0d82
--- /dev/null
+++ b/docs/zh-cn/cli/10-review.md
@@ -0,0 +1,67 @@
+---
+title: "练习 10 - 总结与后续步骤"
+description: "回顾共同的开发工作流、可复用产出和 CLI 的三个拉取请求里程碑。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+你已使用 Copilot CLI，从一个小改动推进到经过规划、具有可复用验证方式的功能。练习 0–1 的设置准备了环境；练习 2–10 的九个核心模块展示了完整开发工作流。
+
+## 回顾三个 PR 里程碑
+
+| 里程碑 | 合并后的结果 | 审查习惯 |
+| --- | --- | --- |
+| PR 1：星级评分 | 在游戏卡片上显示现有 `starRating`，包括在 `null` 时显示 `No rating yet` | 保持改动范围明确，验证两种情况 |
+| PR 2：自定义指令 | 范围明确的文档约定和小型真实代码示例 | 检查指令是否改善实际代码，而不只是聊天示例 |
+| PR 3：筛选功能及验证 | 筛选功能、quality-checks 技能、QA 配置文件和相关测试 | 合并前审查全部检查点、当前 QA 证据和 CI |
+
+前两个 PR 都在下一个里程碑从更新后的 `main` 开始之前完成了合并。练习 4–8 共用一个分支和检出目录。检查点提交保留进度，无需为每个模块创建 PR。控件练习没有启动其他功能或 PR。
+
+## 回顾共同产出
+
+这些与 [Copilot app 研讨会][app-workshop]的核心成果相同，只是通过终端界面完成：
+
+- **存储库指令**说明项目上下文和标准；路径范围指令为相关文件补充细节。
+- **筛选实现和测试**满足议题及规划时批准的澄清内容。
+- **quality-checks 技能**封装可复用指令和实际 shell 脚本，用于运行项目的四项检查。
+- **Playwright MCP 配置**提供直接观察所需的浏览器工具。在此 CLI 流程中，它属于用户配置，而不是功能 PR。
+- **QA 自定义智能体**定义可复用角色：从需求出发，检查覆盖情况，使用技能和浏览器工具，并如实报告结果。
+- **PR 和验证证据**将已审查的更改与测试结果、浏览器观察、限制和 CI 联系起来。
+
+技能不只是一份命令列表，配置文件也不只是一个文件名。在依赖报告前，你检查了生成的资产、确认了实际执行，并选择了自定义智能体。
+
+## 区分各阶段的验证目的
+
+规划在实现前明确了需求。Autopilot 执行范围明确的计划；切回 Interactive，则在编写自定义配置前恢复了明确的审查节点。
+
+实现阶段在任何技能存在之前使用现有 npm 检查。技能练习证明了随附脚本和参数转发可用。MCP 展示直接浏览器交互，而不是重复完整套件。QA 将标准、覆盖情况、浏览器证据和全部四项技能驱动的检查结合起来。PR 复用当前 QA 结果，同时由 CI 检查提交的修订版本。
+
+失败和阻塞项都是有用的结果。缺少浏览器工具、跳过测试、服务器内容过时或需求未明确，都意味着 **NO-GO**，而不是允许降低标准。新增测试必须针对真实缺口；现有覆盖充分时，不添加测试才是正确做法。
+
+## 延续这些习惯
+
+- 向 Copilot 提供议题、更改原因和明确边界。
+- 批准自主工作前审查计划。
+- 运行前检查生成的指令、技能和配置文件。
+- 清楚结果对应哪个检出目录、分支、服务器和修订版本。
+- 采用确有必要的最小修正，并在更改后更新证据。
+- 明确授权安装、破坏性操作、共享和 PR 合并。
+
+## 继续学习
+
+[Copilot app 研讨会][app-workshop]通过图形界面实现共同成果，并增加画布里程碑。[VS Code 研讨会][vscode-workshop]和 [Cloud agent 研讨会][cloud-workshop]探索与智能体协作的其他方式。
+
+使用 [Awesome Copilot][awesome-copilot] 查找指令、技能和自定义智能体示例。[练习 5 中的技能示例][skill-examples]包括贡献工作流、需求文档、图表和浏览器测试。采用社区内容前，审查先决条件和行为。
+
+日常使用时可查阅 [CLI 命令参考][cli-reference]、[智能体技能文档][agent-skills]和[自定义智能体文档][custom-agents]。继续在范围明确的任务中尝试，并仅通过批准的渠道共享已审查材料。
+
+[previous-lesson]: ../9-slash-commands/
+[app-workshop]: ../../app/
+[vscode-workshop]: ../../vscode/
+[cloud-workshop]: ../../cloud/
+[skill-examples]: ../5-agent-skills/#更多技能示例
+[awesome-copilot]: https://github.com/github/awesome-copilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
+[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
+[custom-agents]: https://docs.github.com/copilot/concepts/agents/copilot-cli/about-custom-agents
diff --git a/docs/zh-cn/cli/2-add-star-rating.md b/docs/zh-cn/cli/2-add-star-rating.md
new file mode 100644
index 00000000..bcaefbac
--- /dev/null
+++ b/docs/zh-cn/cli/2-add-star-rating.md
@@ -0,0 +1,83 @@
+---
+title: "练习 2 - 添加星级评分：快速上手"
+description: "显示现有游戏评分，审查并验证更改，再合并第一个拉取请求。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+从一个容易理解和验证的小改动开始。Tailspin Toys 已存储每款游戏的 `starRating`，并在详情页上显示。你将在游戏卡片上显示这个现有值，并在游戏没有评分时给出明确提示。
+
+在本练习中，将：
+
+- 在 Interactive CLI 会话中请求范围明确的更改。
+- 检查差异，验证已评分和未评分的卡片。
+- 提交、打开、审查并合并 PR 1。
+
+## 开始第一个里程碑
+
+在练习存储库根目录中，确认工作树干净，更新 `main`，再创建分支。如果 `git status` 显示意外更改，应先解决再切换，不要丢弃这些更改。
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-star-rating
+copilot --enable-all-github-mcp-tools
+```
+
+出现提示时信任存储库。确认处于 **Interactive** 模式，并使用 `/model` 查看可用模型或选择 **Auto**。工具批准请求出现时，逐一审查。
+
+## 请求更改
+
+发送以下提示词：
+
+```plaintext
+在游戏卡片上显示每款游戏的星级评分。Game 类型已包含 starRating 字段，表示满分为 5 的评分，游戏尚未评分时为 null。在 src/components/GameCard.astro 的每张卡片上显示评分；当 starRating 为 null 时，改为显示 "No rating yet"。保持改动小，不要重构卡片布局。
+
+检查并遵循存储库指令。使用现有数据模型，不要添加评分 API、新的数据库模式或无关功能。为已评分和未评分情况添加或更新适当的测试。暂时不要提交、推送或打开拉取请求。
+```
+
+Copilot 应先检查现有类型和组件，再进行编辑。除了最终回复，也要阅读工具活动。充满信心的摘要并不能证明实现正确。
+
+## 审查并验证
+
+1. 输入 `/diff`，在编辑器或差异视图中检查每个更改的文件。
+2. 确认卡片使用现有的 `starRating`，显示满分为 5 的评分值，并在 `null` 时显示 `No rating yet`。仅使用真值判断可能将数值零误判为未评分。
+3. 检查更改是否保留卡片布局，并为评分提供有意义的文本标签，而不只依赖星形符号或颜色。
+4. 让 Copilot 使用现有检查验证更改：
+
+ ```plaintext
+ 检查 package.json 和测试配置，然后运行适合此次卡片改动的 lint、类型检查，以及现有单元测试或 E2E 测试。验证数值评分和 null 回退状态；报告确切命令和结果，包括覆盖缺口或受阻的检查。不要安装任何内容、更改分支、提交、推送或打开 PR。
+ ```
+
+5. 审查命令输出和测试更改。交付前解决失败项；安装缺失的先决条件前先询问。
+
+要在浏览器中观察卡片，在同一检出目录中打开第二个终端并运行：
+
+```bash
+npm run dev
+```
+
+在 codespace 的 **Ports** 面板中打开转发的端口。检查主页上的已评分卡片。如果当前种子数据中没有未评分示例，应要求使用自动化测试夹具覆盖 `null`，不要声称已观察到未评分卡片。运行 E2E 检查或离开本练习前，在开发服务器所在终端按 Ctrl+C 停止它。Playwright 自动化测试不得复用其他检出目录的服务器。
+
+## 创建并合并 PR 1
+
+审查更改且检查通过后，单独授权此里程碑：
+
+```plaintext
+审查当前差异和检查结果。仅提交已审查的星级评分改动及其测试，推送当前分支，并创建以 main 为目标的拉取请求；如果存储库有 PR 模板，使用该模板。包含更改摘要和实际验证结果。不要合并 PR 或开始其他任务。
+```
+
+打开返回的 PR URL。检查 **Files changed** 和检查结果，而不只是智能体的摘要。解读 CI 时，阅读 Tailspin 存储库的工作流定义；CI 不能替代浏览器观察。解决失败项，并重新验证更改后的代码。
+
+PR 满足存储库的审查和检查要求后，选择 **Merge pull request** 并在 GitHub 上确认合并。如果分支保护要求其他审查者参与，等待其批准。确认 PR 为 **Merged** 后再继续。
+
+使用 `/exit` 退出 Copilot 会话。下一练习会先更新本地 `main`，再创建指令分支；不要从这个尚未合并的功能分支开始。
+
+## 总结与后续步骤
+
+你已完成第一个循环：范围明确的提示词、已审查的代码、验证证据和已合并的 PR。接下来，[使用自定义指令引导 Copilot][next-lesson]，并在第二个小型 PR 中展示文档约定的效果。
+
+[previous-lesson]: ../1-install-copilot-cli/
+[next-lesson]: ../3-custom-instructions/
diff --git a/docs/zh-cn/cli/2-custom-instructions.md b/docs/zh-cn/cli/2-custom-instructions.md
deleted file mode 100644
index 81464ddd..00000000
--- a/docs/zh-cn/cli/2-custom-instructions.md
+++ /dev/null
@@ -1,243 +0,0 @@
----
-title: "练习 2 - 自定义说明（Copilot CLI）"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-[← 上一课：安装 Copilot CLI][previous-lesson] · [下一课：使用 CLI 生成代码 →][next-lesson]
-
-使用生成式 AI 时，上下文至关重要。如果某项任务需要按特定方式完成，或者存在 Copilot 应该知道的背景信息，就需要确保这些上下文可用。本工作坊会探索几种帮助 Copilot 的工具。这里先从[说明文件][instruction-files]开始，它们通常关注代码本身应如何组织。这能帮助 Copilot 不仅理解想要*什么*代码，也理解代码应当*如何*组织。
-
-在本练习中，将：
-
-- 了解项目专属上下文、编码准则和文档标准如何通过存储库自定义说明及按路径限定范围的说明文件传递给 Copilot；
-- 在当前说明已生效的前提下，生成过滤功能的第一块数据切片（publisher helper）；
-- 向 `.github/copilot-instructions.md` 添加一项新的全库标准；
-- 运行后续提示，观察重新生成的代码如何采用这项新标准；
-- 提交说明更新和 helper，为下一节练习做好准备。
-
-> [!CAUTION]
-> 生成的代码可能与设定的某些标准不完全一致。Copilot 是非确定性的。这里的目标是观察更新说明后行为变化的*趋势*，而不是逐字符匹配输出。
-
-## 说明文件
-
-### 场景
-
-和优秀的开发团队一样，Tailspin Toys 也有一套开发实践准则和要求，包括：
-
-- 数据层始终需要单元测试。
-- UI 应使用深色模式，并具有现代感。
-- 应以 TSDoc 文档注释的形式为代码添加文档。
-- 每个文件顶部都应添加一段注释，说明该文件的作用。
-
-通过使用说明文件，可以确保 Copilot 拥有正确的信息，从而按照这些实践要求完成任务。
-
-### 自定义说明
-
-自定义说明可用于向 Copilot 提供上下文和偏好，帮助它更好地理解编码风格和需求。这是一项非常强大的功能，能够引导 Copilot 给出更相关的建议和代码片段。可以指定偏好的编码约定、库，甚至希望包含的注释类型。既可以为整个存储库创建说明，也可以为特定文件类型创建说明，以提供任务级上下文。
-
-说明文件分为两类：
-
-- `.github/copilot-instructions.md`：这是一个针对整个存储库**每次**请求都会发送给 Copilot 的单一说明文件。这个文件应包含项目级信息——也就是大多数发送给 Copilot 的聊天或 CLI 请求都会用到的上下文。可以包括所用技术栈、构建内容概览、最佳实践以及其他全局指导。
-- `.github/instructions/*.instructions.md`：可针对特定任务或文件类型创建。可以用来为特定语言（如 TypeScript 或 Astro）提供指导，也可以针对创建 UI 组件或新增一组单元测试等任务提供指导。
-
-> [!NOTE]
-> 在 IDE 中工作时，说明文件仅用于 Copilot Chat 的代码生成——不会用于代码补全或下一次编辑建议。
->
-> Copilot Chat、Copilot CLI 和 Copilot cloud agent 在生成代码时都会使用存储库级说明文件以及 `*.instructions.md` 文件（带 `applyTo` front matter）。
->
-> 此外，Copilot [还支持采用其他标准的说明文件][custom-instructions-support]，包括 `AGENTS.md` 和 `CLAUDE.md` 文件。
-
-### 管理说明文件的最佳实践
-
-关于如何创建说明文件的完整讨论超出了本工作坊范围。不过，示例项目中的例子展示了一种具有代表性的做法。从高层来看：
-
-- 将 `copilot-instructions.md` 中的说明聚焦于项目级指导，例如构建内容说明、项目结构和全局编码标准。
-- 使用 `*.instructions.md` 文件为特定文件类型（单元测试、Astro 组件、数据层）或特定任务提供具体说明。
-- 使用自然语言。保持指导清晰。提供代码应该如何写以及不应该如何写的示例。
-
-创建说明文件没有唯一正确的方法，就像使用 AI 也没有唯一正确的方法一样。通过不断实验，会逐渐找到最适合项目的方式。
-
-> [!TIP]
-> 每个使用 GitHub Copilot 的项目都应该具备一套完善的说明文件。查看本项目中的这些文件时，可能会注意到其中覆盖了许多任务类型，包括 [UI 更新][ui-instructions] 和 [Astro][astro-instructions]。
->
-> Copilot 也可以帮助生成说明文件。不同界面对这一功能的暴露方式不同（例如 VS Code 中的 **Configure Chat → Generate Agent Instructions**，或 Copilot CLI 中的 `/init`）——所在路径的课程会在相关位置指出。
->
-> 想找模板或起点？可以看看 [awesome-copilot][awesome-copilot]，这是一个汇集说明文件、自定义智能体和其他资源的存储库。
-
-[ui-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/ui.instructions.md
-[astro-instructions]: https://github.com/github-samples/tailspin-toys/blob/main/.github/instructions/astro.instructions.md
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[custom-instructions-support]: https://docs.github.com/copilot/reference/custom-instructions-support
-
-## 探索本项目中的自定义说明文件
-
-花一点时间阅读此存储库随附的说明文件——其中包含一个核心 `copilot-instructions.md`，以及一组面向不同任务的 `*.instructions.md` 文件。可以在编辑器中打开它们，也可以在 GitHub Web UI 中查看。
-
-1. 打开 `.github/copilot-instructions.md`。
-2. 浏览该文件，注意其中对项目的简要说明，以及 **Agent notes**、**Code standards**、**Scripts** 和 **Repository Structure** 等部分。在 **Code standards** 下，还要注意嵌套的 **GitHub Actions Workflows** 指导。这些内容适用于与 Copilot 的任何交互。
-3. 打开 `.github/instructions` 文件夹并浏览。可以看到其中包含针对 Astro 文件、Drizzle 数据层、测试等内容的说明。
-4. 打开 `.github/instructions/unit-tests.instructions.md`。注意顶部的 `applyTo` 字段——它设置了一个相对于存储库根目录的 glob，用于决定这些说明适用于哪些文件。在这里，任何 TypeScript 测试文件（例如匹配 `**/*.test.ts` 的文件）都会匹配。
-5. 注意其中针对为本项目创建单元测试的专门说明。
-6. 最后，打开 `.github/instructions/drizzle.instructions.md` 并滚动到底部。注意其中链接到了其他说明文件（如 `unit-tests.instructions.md`）以及项目中的现有文件。这样可以把较大的说明集拆分为更小、可复用的文件，并在生成代码时为 Copilot 指出可参考的示例。（其中路径是相对于说明文件本身，而不是存储库根目录。）
-
-> [!NOTE]
-> `copilot-instructions.md` 中的 **Code formatting requirements** 部分记录了项目的编码标准，但目前还没有要求在代码中编写文档。接下来的步骤会添加 TSDoc 文档注释和文件注释头规则。
-
-## 创建分支
-
-接下来会修改代码，因此先创建一个分支来工作。
-
-1. 在 codespace 终端中，创建并切换到新分支：
-
- ```bash
- git checkout -b update-custom-instructions
- ```
-
-2. 确认 Copilot CLI 已安装并完成验证：
-
- ```bash
- copilot --version
- ```
-
- 如果找不到该命令，或者尚未登录，请返回[练习 1 - 安装 GitHub Copilot CLI](../1-install-copilot-cli/)。
-
-## 在更新说明*之前*使用 Copilot CLI
-
-为了看清自定义说明的影响，先在当前说明生效的情况下生成代码。稍后会更新该文件，并再次运行后续提示。
-
-> [!TIP]
-> **启动 Copilot CLI 会话**
->
-> 开始下面的练习前，先返回 codespace 并打开一个终端（如果还没打开，可按 Ctrl+\`）。然后使用 `--yolo` 和 `--enable-all-github-mcp-tools` 启动 Copilot CLI：
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 如果希望接续这个项目最近一次会话，而不是重新开始，请运行 `copilot --yolo --enable-all-github-mcp-tools --continue`。如果 Copilot CLI 仍在运行之前练习中的会话，请发送 `/clear` 开始一段新的对话。
->
-> `--enable-all-github-mcp-tools` 会为当前会话启用 GitHub MCP 读写工具，因此在工作坊流程中 Copilot 可以读取积压工作并打开 pull request。
-
-> [!CAUTION]
-> `--yolo` 会启用完整的自动权限（`--allow-all-tools`、`--allow-all-paths` 和 `--allow-all-urls`）。只能在 Codespace 或 VM 这类隔离环境中使用，绝不要把它设成日常开发的默认别名。详情见[允许和拒绝工具使用][allow-all-warning]。
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. 确保 Copilot CLI 会话从**存储库根目录**启动，这样它才能自动读取 `.github/copilot-instructions.md`。
-2. 在 Copilot CLI 提示符中，请它生成过滤 UI 将要使用的 publishers helper：
-
- ```plaintext
- Create a new data-access helper at src/lib/publishers.ts to return a list of all publishers. It should return the name and id for all publishers. Do not run the tests yet.
- ```
-
-3. Copilot CLI 会探索项目、提出计划，并在这个 `--yolo` 会话中写入文件。观察终端输出中的变更，然后在编辑器中查看结果。
-4. 在编辑器中打开生成的 `src/lib/publishers.ts`。
-5. 注意，这个 helper 是一个带类型的函数，第一参数接收 `db` 客户端，并返回一个带类型的 publishers 数组——这来自 `.github/instructions/drizzle.instructions.md` 中的数据层约定（该文件适用于 `src/lib/*.ts`）。
-6. 注意，生成的代码**缺少** TSDoc 文档注释和文件级注释头。
-
-> [!CAUTION]
-> Copilot 是概率性的——即使没有明确要求，它也有可能会添加文档注释。如果出现这种情况也没关系；更新说明后的*一致性*提升仍然是这里要观察的重点。
-
-## 添加新的全库标准
-
-如前所述，`.github/copilot-instructions.md` 旨在向 Copilot 提供项目级信息。现在为它补充存储库编码标准，以改善代码建议质量。
-
-1. 重新打开 `.github/copilot-instructions.md`。
-2. 找到 **Code formatting requirements** 部分，应该在第 27 行附近。注意它已经记录了项目的编码标准——但尚未加入代码内文档规则，这就是生成的 helper 没有文档注释的原因。
-3. 在现有标准的正下方添加以下 markdown 行，指示 Copilot 添加文件注释头和 TSDoc 文档注释：
-
- ```markdown
- - Every exported function should have a TSDoc comment describing its purpose, parameters, and return value.
- - Before imports or any code, add a comment block to the file that explains its purpose.
- ```
-
-4. 保存 `copilot-instructions.md`。
-
-> [!TIP]
-> 正如上一课所示，说明文件既可以在存储库级别创建（`.github/copilot-instructions.md`）用于全局指导，也可以创建为 `*.instructions.md` 文件，用于特定语言、文件类型或任务。像刚刚添加的文档注释规则这类项目级标准，就应该放在存储库级文件中。
-
-## 重新运行提示并观察变化
-
-既然说明中已经加入文档注释规则，就请 Copilot CLI 更新刚刚生成的 publishers 文件。同一条标准指令会引导这次重写。
-
-1. 在 Copilot CLI 会话中发送 `/clear`，以全新的对话开始。
-2. 发送以下提示：
-
- ```plaintext
- Update src/lib/publishers.ts to follow the latest documentation conventions in .github/copilot-instructions.md.
- ```
-
-3. 等待编辑完成，然后重新打开 `src/lib/publishers.ts`。
-4. 注意，文件现在会以类似下面的注释块开头：
-
- ```typescript
- /**
- * Tailspin Toys Crowd Funding platform 的 publisher 数据访问辅助函数。
- * 提供从数据库检索 publisher 信息的函数。
- */
- ```
-
-5. 注意，生成的函数现在会包含类似下面的 TSDoc 注释：
-
- ```typescript
- /**
- * 返回所有 publisher 的列表，包含其 id 和 name。
- *
- * @param db - Drizzle 数据库客户端。
- * @returns 一个 Promise，解析为 publisher 对象数组。
- */
- ```
-
-6. 保留这个更新后的文件。它是下一节练习将继续扩展的第一块数据切片。
-
-## 提交并推送这第一块过滤功能
-
-1. 在终端中确认已变更的文件：
-
- ```bash
- git status
- ```
-
-2. 暂存说明更新和 helper：
-
- ```bash
- git add .github/copilot-instructions.md src/lib/publishers.ts
- ```
-
-3. 提交变更：
-
- ```bash
- git commit -m "Add doc comment standards and publishers helper foundation"
- ```
-
-4. 推送分支：
-
- ```bash
- git push -u origin update-custom-instructions
- ```
-
-## 总结和后续步骤
-
-已经了解了 Copilot 如何从本项目中的说明文件获取上下文，然后使用 Copilot CLI 完成了以下事项：
-
-- 在*现有*说明的基础上，生成了用于过滤功能的 publishers 数据访问 helper 基础；
-- 向 `.github/copilot-instructions.md` 添加了一项新的全库标准；
-- 运行后续提示，并观察重新生成的代码如何采用这项新标准；
-- 提交并推送说明更新和 helper 基础。
-
-下一步，将在[生成代码练习][next-lesson]中应用这些说明，实现积压工作中的功能。
-
-## 资源
-
-- [GitHub Copilot 自定义的说明文件][instruction-files]
-- [创建自定义说明的最佳实践][instructions-best-practices]
-- [为 Copilot 编写更好自定义说明的 5 个技巧][copilot-instructions-five-tips]
-- [Awesome Copilot——说明文件及其他资源集合][awesome-copilot]
-
-[previous-lesson]: ../1-install-copilot-cli/
-[next-lesson]: ../3-generating-code/
-[instruction-files]: https://docs.github.com/copilot/customizing-copilot/about-customizing-github-copilot-chat-responses
-[instructions-best-practices]: https://docs.github.com/enterprise-cloud@latest/copilot/using-github-copilot/coding-agent/best-practices-for-using-copilot-to-work-on-tasks#adding-custom-instructions-to-your-repository
-[copilot-instructions-five-tips]: https://github.blog/ai-and-ml/github-copilot/5-tips-for-writing-better-custom-instructions-for-copilot/
diff --git a/docs/zh-cn/cli/3-custom-instructions.md b/docs/zh-cn/cli/3-custom-instructions.md
new file mode 100644
index 00000000..b697e9c7
--- /dev/null
+++ b/docs/zh-cn/cli/3-custom-instructions.md
@@ -0,0 +1,109 @@
+---
+title: "练习 3 - 使用自定义指令引导 Copilot"
+description: "添加范围明确的文档约定，在现有代码上展示其效果，并合并第二个拉取请求。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+上下文帮助 Copilot 不仅理解要构建*什么*，也理解团队期望*如何*编写代码。你将添加范围明确的文档约定，观察其对真实代码的影响，并将指令和示例改动通过 PR 2 一并合并。
+
+在本练习中，将：
+
+- 探索存储库范围和路径范围的指令。
+- 添加文档标准，不提前实现筛选功能。
+- 在一个现有的小型辅助函数或组件上展示标准的效果。
+- 验证并合并指令里程碑。
+
+## 探索指令
+
+存储库已包含两类有用的指令：
+
+- `.github/copilot-instructions.md` 提供存储库范围的上下文，例如技术栈、结构和通用实践。
+- `.github/instructions/*.instructions.md` 提供限定范围的指导。frontmatter 中的 `applyTo` glob 指明这些指令适用的文件。
+
+在编辑器中打开这些文件：
+
+1. 阅读 `.github/copilot-instructions.md`，找到当前编码和验证标准。
+2. 探索 `.github/instructions/`，包括 Astro、数据层和测试指导。
+3. 在 `unit-tests.instructions.md` 中检查 `applyTo` 模式和测试约定。
+4. 在 `drizzle.instructions.md` 中检查数据访问模式及示例引用。
+
+保持存储库范围指令简洁，将文件特定的细节放入相关范围指令文件，并避免同一规则的多个副本相互矛盾。[GitHub 指令支持参考][instruction-support]说明了各操作环境支持的指令格式。
+
+> [!NOTE]
+> 指令会影响生成结果，但不保证始终遵循。审查时既要检查指令文本，也要检查其对代码的影响。如果 Copilot 已生成良好注释，本课的目的就是让约定明确且可重复，而不是强行制造前后对比中的失败。
+
+## 从已合并的 PR 1 开始
+
+确认星级评分 PR 已合并。在练习存储库终端中，从更新后的 `main` 开始下一个里程碑：
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c update-custom-instructions
+copilot --enable-all-github-mcp-tools
+```
+
+如果工作树不干净或拉取失败，应先解决再继续。保持 **Interactive** 模式。
+
+在存储库的 **Issues** 选项卡中，找到 **Update our repository coding standards**，复制其实际 URL。该议题提供更广泛的上下文：说明意图、记录导出的数据层函数和组件契约，并持续更新注释。本练习只处理其中范围明确的文档工作，不进行全库重构，也不承诺完成每项议题标准。
+
+## 添加文档约定
+
+将占位符替换为实际议题 URL，然后发送：
+
+```plaintext
+阅读此编码标准议题以了解上下文：。检查现有存储库指令和范围指令。添加范围明确的文档约定：说明意图，而不是复述代码；使用 TSDoc/JSDoc 记录 db/ 和 src/lib/ 中导出函数的用途、参数和返回值；记录可复用 Astro 组件的 Props 契约；并在相关代码变化时同步更新注释。
+
+将每条规则放入适当的现有指令文件，避免重复或矛盾。保留现有格式和 lint 标准；在适当位置从 README 链接到或概述该文档约定。将此次更改限定为文档标准，不要迁移格式工具或重写整个存储库。不要创建技能或智能体、实现筛选功能、提交、推送或打开 PR。停止，让我在进行示例改动前检查指令。
+```
+
+检查差异。约定应鼓励有用的注释，而不是要求每个文件都有样板标头，或添加只重复显而易见代码的注释。继续前先请求修正。
+
+## 在真实代码上展示约定
+
+检查存储库后，选择一个现有的小型导出辅助函数或可复用组件。它不必是发行商辅助函数，也不要求 `src/lib/publishers.ts` 已存在。
+
+发送：
+
+```plaintext
+根据更新后的指令，选择一个文档可以更清晰的现有小型导出辅助函数或可复用 Astro 组件。直接在该文件中应用约定，不改变运行时行为，也不添加筛选功能。说明哪条指令指导了改动，并在提交或打开 PR 前停止。
+```
+
+打开实际更改的文件。对于辅助函数，检查注释是否准确描述参数、返回值和注入的数据库参数；对于组件，检查是否记录了 `Props` 契约。确认说明与代码一致，而不只是寻找注释块。
+
+> [!TIP]
+> 聊天中的示意代码片段不算示例改动，应检查真实的存储库更改。如果所选代码已满足约定，应选择另一个确有改进必要的小型现有目标，而不是添加冗余注释。
+
+## 验证并合并 PR 2
+
+让 Copilot 验证已审查的更改：
+
+```plaintext
+审查指令更改和小型文档示例改动。确认运行时行为未改变。检查 package.json，运行 npm run lint 和 npm run typecheck:all，并在代码改动确有需要时运行受影响的现有测试。报告确切命令和结果。暂时不要安装任何内容、创建技能、提交、推送或打开 PR。
+```
+
+解决失败项，检查最终差异，然后授权此里程碑：
+
+```plaintext
+仅提交已审查的文档指令、直接相关的 README 更新和小型代码示例。推送当前分支，并按照存储库的 PR 模板创建以 main 为目标的 PR。包含验证结果，并将编码标准议题作为部分贡献进行引用；除非确已满足每项议题标准，否则不要使用关闭议题的关键字。不要合并或开始筛选功能。
+```
+
+打开 PR URL，检查 **Files changed** 并审查 CI。全部必需检查和审查通过后，在 GitHub 上合并，并确认 PR 2 为 **Merged**。使用 `/exit` 退出 CLI 会话。此 PR 合并前，不要开始下一个里程碑。
+
+## 总结与后续步骤
+
+文档约定和真实示例改动现已进入 `main`。接下来，在基于该合并状态的新分支中，[使用 Plan 和 Autopilot 构建筛选功能][next-lesson]。
+
+## 资源
+
+- [添加存储库自定义指令][repository-instructions]说明存储库范围和路径范围的指导。
+- [Awesome Copilot][awesome-copilot] 提供可审查并调整的示例，不应盲目采用。
+
+[previous-lesson]: ../2-add-star-rating/
+[next-lesson]: ../4-build-filtering/
+[instruction-support]: https://docs.github.com/copilot/reference/custom-instructions-support
+[repository-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
+[awesome-copilot]: https://github.com/github/awesome-copilot
diff --git a/docs/zh-cn/cli/3-generating-code.md b/docs/zh-cn/cli/3-generating-code.md
deleted file mode 100644
index f6e91d41..00000000
--- a/docs/zh-cn/cli/3-generating-code.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: "练习 3 - 使用 GitHub Copilot CLI 添加项目功能"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-正如预期，使用 GitHub Copilot CLI 执行的核心任务之一，就是向项目添加功能、特性和代码。现在从积压工作中选取一个 issue，请 Copilot 帮助实现它。
-
-## 场景
-
-现在到了完成项目过滤功能的时候。积压工作中已经有这个过滤 issue，上一节练习还提供了一个基础 helper。接下来让 Copilot 获取 issue 详情，考虑现有工作，并补齐剩余功能。
-
-在本练习中，将：
-
-- 使用计划模式生成实现过滤功能的计划。
-- 使用 Copilot 生成向网站添加过滤功能所需的代码。
-
-完成本练习后，项目中将新增这项功能。
-
-## 使用计划模式
-
-AI 最适合做的事情之一就是规划。很多时候，对要构建的内容已经有大致想法，只是需要一个对象来帮助梳理思路。AI 工具可以通过追问和分析潜在问题或遗漏项，帮助把想法变得更清晰。为支持这一过程，Copilot CLI 提供了计划模式。此外，花在规划上的时间也会帮助 Copilot 生成更符合要求的代码。
-
-接下来将通过 Copilot CLI 的计划模式，开始创建这项新功能。
-
-> [!TIP]
-> **启动 Copilot CLI 会话**
->
-> 开始下面的练习前，先返回 codespace 并打开一个终端（如果还没打开，可按 Ctrl+\`）。然后使用 `--yolo` 和 `--enable-all-github-mcp-tools` 启动 Copilot CLI：
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 如果希望接续这个项目最近一次会话，而不是重新开始，请运行 `copilot --yolo --enable-all-github-mcp-tools --continue`。如果 Copilot CLI 仍在运行之前练习中的会话，请发送 `/clear` 开始一段新的对话。
->
-> `--enable-all-github-mcp-tools` 会为当前会话启用 GitHub MCP 读写工具，因此在工作坊流程中 Copilot 可以读取积压工作并打开 pull request。
-
-> [!CAUTION]
-> `--yolo` 会启用完整的自动权限（`--allow-all-tools`、`--allow-all-paths` 和 `--allow-all-urls`）。只能在 Codespace 或 VM 这类隔离环境中使用，绝不要把它设成日常开发的默认别名。详情见[允许和拒绝工具使用][allow-all-warning]。
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. 在 Copilot CLI 中输入以下提示，根据过滤 issue 创建计划：
-
- ```
- /plan Retrieve the issue on the repository related to adding filtering. We already added a publishers helper in src/lib/publishers.ts, so treat that as existing work and plan the remaining updates (games filtering logic, UI, and tests).
- ```
-
-2. Copilot 在生成计划时可能会提出后续问题。出现时，可根据希望实现功能的方式进行回答。
-3. 计划生成后，查看这份蓝图。应能看到它建议在数据层和 UI 中进行剩余变更，并生成测试。
-4. Copilot CLI 会提供继续反馈计划的能力。可将光标移到指定区域，然后输入建议。Copilot 会把这些建议整合进新版本计划。
-5. 满意后，选择 Copilot 提供的选项，开始构建这个新功能。
-
-> [!NOTE]
-> 由于 Copilot 是概率性的，提供的具体文本和选项会有所不同。但会看到一个开始构建的选项，内容大致类似：
->
-> `Yes, and switch to autopilot mode`.
->
-> Copilot 可能会像上面的示例一样，提供启用 [autopilot mode](https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot) 的选项。autopilot mode 允许 Copilot CLI 在每一步后无需等待输入，自主完成整个任务。给出初始指令后，Copilot CLI 会自动执行各个步骤，直到判断任务完成。由于当前运行在受控环境中，可以放心启用 autopilot 并允许所有工具。
-
-6. Copilot 会开始生成文件。
-
-> [!NOTE]
-> 这个操作很可能需要几分钟。会看到 Copilot 编辑和创建文件、更新和生成测试，并运行全部测试以确保成功。此时可以顺便回顾前面学到的内容，或者喝点东西休息一下。
-
-## 查看代码
-
-所有 AI 生成的代码在合并到生产环境前都需要审查。现在就来查看 Copilot 为实现新功能而创建和修改的文件。
-
-1. 在 Copilot CLI 中使用以下命令显示“diff”或代码变更：
-
- ```
- /diff
- ```
-
-2. 注意已更改的文件。使用方向键左右切换查看不同文件。应能看到游戏列表页面（新过滤控件和客户端过滤逻辑所在位置）、`src/lib/games.ts`，以及 `games.test.ts` 等测试文件的更新。如果 Copilot 为了与完整实现保持一致而优化了现有 helper，也可能会看到 `publishers.ts` 的更新。
-
-## 总结和后续步骤
-
-现在已经借助 Copilot CLI 为网站添加了过滤功能。具体来说，完成了以下事项：
-
-- 使用计划模式生成了实现过滤功能的计划。
-- 生成了向网站添加过滤功能所需的代码。
-
-当然，下一步就是确认它确实可用。在打开 pull request 之前，先[使用 Playwright MCP 服务器测试这个功能][next-lesson]。
-
-## 资源
-
-- [使用 Copilot CLI][using-copilot-cli]
-- [关于 Copilot CLI][about-copilot-cli]
-- [Copilot CLI 中的上下文管理][context-management]
-
-[previous-lesson]: ../2-custom-instructions/
-[next-lesson]: ../4-mcp/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
diff --git a/docs/zh-cn/cli/4-build-filtering.md b/docs/zh-cn/cli/4-build-filtering.md
new file mode 100644
index 00000000..5eaa965b
--- /dev/null
+++ b/docs/zh-cn/cli/4-build-filtering.md
@@ -0,0 +1,102 @@
+---
+title: "练习 4 - 使用 Plan 和 Autopilot 构建筛选功能"
+description: "明确筛选需求，批准实现计划，验证代码，并在功能分支上保存检查点。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+现在构建较大的功能：让用户按类别和发行商筛选游戏。你将在编码前规划，明确授权 **Autopilot**，审查并测试实现，再保存检查点。本练习不创建技能、QA 智能体或功能 PR。
+
+## 开始筛选里程碑
+
+确认 PR 1 和 PR 2 已合并。在练习存储库终端中运行：
+
+```bash
+git status
+git switch main
+git pull --ff-only
+git switch -c add-game-filtering
+copilot --enable-all-github-mcp-tools
+```
+
+仅在工作树干净且已从 `main` 成功更新后继续。练习 4–8 使用同一分支和检出目录。后续检查点提交会添加技能和 QA 配置文件；不要为每项练习创建分支。
+
+## 获取实际议题
+
+在存储库的 **Issues** 选项卡中找到 **Allow users to filter games by category and publisher**，复制其 URL。不要假定模板中的文件名或某个议题编号就能标识个人副本中的议题。
+
+当前议题要求：
+
+- 选择一个或多个类别。
+- 按发行商筛选，并与类别组合。
+- 在 `src/lib/` 中提供支持两种筛选的数据访问辅助函数。
+- 提供支持键盘导航、适当 ARIA、可见焦点状态和 `data-testid` 属性的无障碍控件。
+- 使用 Vitest 为辅助函数提供单元测试覆盖，使用 Playwright E2E 覆盖筛选行为。
+
+以实际议题为准。保留其 URL 和批准的澄清内容，以供练习 7 的 QA 提示词使用。
+
+## 编码前先规划
+
+使用 Shift+Tab 选择 **Plan** 模式，或使用 `/plan` 开始。替换议题占位符后发送：
+
+```plaintext
+规划此议题描述的筛选功能：。提出改动前，阅读议题、存储库指令、现有数据访问辅助函数、UI 和测试。以当前检出内容为基线，不要假设已创建发行商辅助函数。
+
+涵盖多类别选择、发行商筛选、两者组合、数据访问支持、无障碍控件和单元/E2E 覆盖。对于未明确的行为，例如多个类别如何组合、清除筛选和空结果，请让我澄清；将决定与批准的计划一并记录。保留静态 Astro 架构，不要引入不必要的服务器 API。
+
+规划在当前分支上的实现，包括所需的单元测试和 E2E 测试，以及通过 npm run lint、npm run test:unit、npm run test:e2e 和 npm run typecheck:all 进行验证。先检查先决条件和服务器归属；报告阻塞项，不要安装软件或停止无关进程。
+
+将以下执行边界纳入计划：在我批准后，仅实现筛选功能和所需测试，运行检查，然后停止，供我审查。不要创建 quality-checks 技能、QA 智能体或后续研讨会产出。不要更改分支、提交、推送、打开或合并 PR。
+
+在我批准计划前，不要编辑应用代码或开始实现。
+```
+
+回答后续问题。不要在之后添加未公开的验收标准：将约定的答案与议题 URL 一并保存，让实现、浏览器检查和 QA 使用相同需求。
+
+审查计划中的数据层和 UI 改动、测试、无障碍控件，以及已合并的文档约定。确认计划明确包含全部四项检查、停止供审查的边界，以及禁止提前创建后续研讨会产出、更改分支、提交、推送和执行 PR 操作的要求。如果缺少任何限制或标准，或提出议题范围之外的工作，应在批准前请求修订。
+
+## 明确批准 Autopilot
+
+只有计划已包含审查后的范围和执行边界，才能使用计划批准选项 **Accept plan and build on autopilot**。如果当前版本措辞不同，明确选择切换到 **Autopilot** 的选项，再检查模式指示器。批准后即开始执行范围明确的计划；不要依赖工作开始后再通过后续提示词添加限制。
+
+> [!CAUTION]
+> Autopilot 控制持续工作，而不只是工具权限。选择前审查权限对话框。完整权限允许访问工具、路径和 URL；有限权限可能阻止需要批准的操作。codespace 并不代表允许泄露机密或更改无关资源。应审慎解决访问阻塞，不要把跳过的检查视为通过。
+
+观察工作过程和命令结果。Autopilot 可能在完成计划前因持续执行限制而暂停，或报告阻塞项。授权继续前先审查该状态，并保持相同范围。
+
+## 返回 Interactive 并审查
+
+实现停止后，在发送任何后续提示词前，使用 Shift+Tab 返回 **Interactive** 模式。任务结束后 Autopilot 可能仍处于活动状态，不要假定它已自动切回。
+
+输入 `/diff` 并检查所有更改的文件。对照议题和批准的澄清内容检查实现：
+
+- 用户能否按约定选择多个类别、按发行商筛选，并组合两者？
+- 数据访问辅助函数是否确实支持筛选，而不只是更改 UI？
+- 控件是否具有有意义的标签、键盘支持、可见焦点和稳定的测试标识符？
+- 测试是否断言了行为，包括约定的清除筛选和空结果情况，且未弱化现有断言？
+- 代码是否遵循文档约定，并保留静态应用架构？
+
+审查全部四项 npm 检查的证据。尚未创建 `quality-checks`，因此直接运行这些检查。Playwright 的 E2E 配置会构建并提供预览服务；运行套件前，仅停止自己启动的开发服务器，避免复用过时内容。端口冲突或缺少浏览器是需要解决的阻塞项，不是终止其他进程或声称通过的理由。
+
+必要时请求针对性修正，重新运行受影响的检查，并确保最终实现经过完整验证。练习 6 会进行直接浏览器观察，其目的与此处的自动化验证不同。
+
+## 保存实现检查点
+
+对差异和结果满意后，授权创建本地检查点：
+
+```plaintext
+审查当前差异和验证结果。创建仅包含已审查的筛选实现及其测试的检查点提交。保持当前筛选分支和检出目录。暂时不要推送、打开 PR 或创建技能、QA 智能体。
+```
+
+记录被测修订版本，保留议题 URL 和批准的澄清内容。保持 **Interactive**，在同一检出目录中继续学习[练习 5 - 创建并使用 quality-checks 技能][next-lesson]。
+
+## 资源
+
+- [Autopilot 模式和权限][autopilot]说明自主持续执行及如何切回 Interactive。
+- [Copilot CLI 命令参考][cli-reference]列出当前模式控件和命令。
+
+[previous-lesson]: ../3-custom-instructions/
+[next-lesson]: ../5-agent-skills/
+[autopilot]: https://docs.github.com/copilot/concepts/agents/copilot-cli/autopilot
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/zh-cn/cli/4-mcp.md b/docs/zh-cn/cli/4-mcp.md
deleted file mode 100644
index d266de46..00000000
--- a/docs/zh-cn/cli/4-mcp.md
+++ /dev/null
@@ -1,160 +0,0 @@
----
-title: "练习 4 - 使用 Playwright MCP 服务器测试功能"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-刚刚已经使用 Copilot CLI 生成了过滤功能。在打开 pull request 之前，应该先确认它在浏览器中能够正常工作。与其手动点选应用，不如连接 **Playwright MCP 服务器**，让 Copilot 驱动真实浏览器代为测试。
-
-在本练习中，将：
-
-- 了解什么是 Model Context Protocol (MCP)，以及 MCP 服务器如何扩展 Copilot CLI。
-- 将 Playwright MCP 服务器添加到 Copilot CLI。
-- 要求 Copilot 使用它在浏览器中手动测试过滤功能。
-
-## 什么是 Model Context Protocol (MCP)？
-
-[Model Context Protocol (MCP)](https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/) 为 AI 智能体提供了一种与外部工具和服务通信的方式。借助 MCP，AI 智能体可以实时连接外部工具和服务，从而获取最新信息（通过资源），并代表执行操作（通过工具）。
-
-这些工具和资源通过 MCP 服务器访问，它充当 AI 智能体与外部工具和服务之间的桥梁。MCP 服务器负责管理 AI 智能体与外部工具之间的通信（例如现有 API 或 NPM package 这类本地工具）。每个 MCP 服务器都代表一组不同的工具和资源，供 AI 智能体访问。
-
-几个常见的 MCP 服务器包括：
-
-- **[GitHub MCP Server](https://github.com/github/github-mcp-server)**：该服务器提供一组 API，用于管理 GitHub 存储库。它允许 AI 智能体执行创建新存储库、更新现有存储库、管理 issue 和 pull request 等操作。
-- **[Playwright MCP Server](https://github.com/microsoft/playwright-mcp)**：该服务器提供基于 Playwright 的浏览器自动化能力。它允许 AI 智能体执行导航到网页、填写表单和选择按钮等操作。
-
-还有许多其他 MCP 服务器可提供对不同工具和资源的访问。GitHub 托管了一个 [MCP registry](https://github.com/mcp)，以提升生态系统中的可发现性和协作贡献。
-
-> [!CAUTION]
-> 从安全角度看，应像对待项目中的其他依赖项一样对待 MCP 服务器。使用前，请仔细审查其源代码、验证发布者，并评估安全影响。只使用可信的 MCP 服务器，并谨慎授予对敏感资源或操作的访问权限。
-
-> [!NOTE]
-> [GitHub MCP 服务器][github-mcp-server] 是 Copilot CLI 的**内置**能力——无需任何设置即可使用，这也是为什么在整个工作坊中 Copilot 能持续读取和写入存储库。本练习将添加*第二个*服务器，即 Playwright，为 Copilot 提供浏览器能力。
-
-## 添加 Playwright MCP 服务器
-
-添加服务器最快的方法是使用交互式 `/mcp add` 命令。这里将注册 [Playwright MCP 服务器][playwright-mcp-server]，让 Copilot 获得一个可控浏览器。
-
-> [!TIP]
-> **启动 Copilot CLI 会话**
->
-> 开始下面的练习前，先返回 codespace 并打开一个终端（如果还没打开，可按 Ctrl+\`）。然后使用 `--yolo` 和 `--enable-all-github-mcp-tools` 启动 Copilot CLI：
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 如果希望接续这个项目最近一次会话，而不是重新开始，请运行 `copilot --yolo --enable-all-github-mcp-tools --continue`。如果 Copilot CLI 仍在运行之前练习中的会话，请发送 `/clear` 开始一段新的对话。
->
-> `--enable-all-github-mcp-tools` 会为当前会话启用 GitHub MCP 读写工具，因此在工作坊流程中 Copilot 可以读取积压工作并打开 pull request。
-
-> [!CAUTION]
-> `--yolo` 会启用完整的自动权限（`--allow-all-tools`、`--allow-all-paths` 和 `--allow-all-urls`）。只能在 Codespace 或 VM 这类隔离环境中使用，绝不要把它设成日常开发的默认别名。详情见[允许和拒绝工具使用][allow-all-warning]。
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. 在 Copilot CLI 会话中输入：
-
- ```text
- /mcp add
- ```
-
-2. 此时会出现一个配置表单。使用 Tab 在字段之间切换，并按如下内容填写：
-
- - **Server Name**：`playwright`
- - **Server Type**：选择 **Local**（也标记为 **STDIO**）
- - **Command**：`npx @playwright/mcp@latest --headless`
- - **Tools**：保持为 `*`，允许使用该服务器的全部工具
-
-3. 按 Ctrl+S 保存。服务器会立即添加并可用——无需重启。
-
-`--headless` 标志表示让 Playwright 在无可见窗口的模式下运行，这对于没有桌面界面的 codespace 是必需的。在后台，这会把服务器写入 `~/.copilot/mcp-config.json` 文件：
-
-```json
-{
- "mcpServers": {
- "playwright": {
- "type": "local",
- "command": "npx",
- "args": ["@playwright/mcp@latest", "--headless"],
- "tools": ["*"]
- }
- }
-}
-```
-
-4. 通过列出 MCP 服务器，确认该服务器已注册并处于活动状态：
-
- ```text
- /mcp show
- ```
-
-5. 应该会看到 `playwright` 与内置的 `github` 服务器一起列出。
-
-> [!NOTE]
-> Tailspin Toys 项目本身已经使用 Playwright 进行端到端测试，因此 Playwright 所需的浏览器通常已经安装好。如果之后 Copilot 提示缺少浏览器，让它运行 `npx playwright install chromium`，然后重试。
-
-## 启动网站
-
-Playwright MCP 服务器需要一个正在运行的应用作为测试目标。请在**单独**的终端中启动 Astro 开发服务器，这样在使用 Copilot CLI 时它才能持续运行。
-
-1. 在 codespace 中选择 Ctrl+\` 打开一个新终端。
-2. 启动网站：
-
- ```bash
- npm run dev
- ```
-
-3. 保持这个终端持续运行。看到 `Astro server: http://localhost:4321` 横幅后，说明应用已就绪。
-
-## 测试过滤功能
-
-返回 Copilot CLI 会话，并请 Copilot 测试这个功能。
-
-[Playwright MCP 服务器][playwright-mcp-server] 会为 Copilot 提供一个可以驱动的真实浏览器。无需手动点选应用来检查结果，智能体可以打开页面、导航、应用过滤条件，并把结果读回给你——然后总结其观察结果。这是在不离开当前对话的情况下，快速确认功能是否符合预期的最佳方式。
-
-在底层，Playwright MCP 服务器依赖页面的[无障碍树][playwright-mcp-server]而不是截图来工作。这意味着智能体会基于结构化、带标签的元素（按钮、链接、列表项）进行推理，方式与辅助技术类似——因此一次快速的功能检查，也兼具轻量级的无障碍合理性检查。
-
-在服务器已连接且应用已运行的情况下，请 Copilot 演练刚刚构建的过滤功能：
-
-```text
-Using the Playwright MCP server, open a browser to the running app at http://localhost:4321 and verify the new game filtering feature:
-
-1. Go to the games page and note how many games are listed.
-2. Apply a category filter and confirm the list updates to only show games in that category.
-3. Clear it, then apply a publisher filter and confirm the list updates to that publisher.
-4. Combine a category and a publisher filter and confirm the results respect both.
-
-Report what you observe at each step, and call out anything that does not behave as expected.
-```
-
-Copilot 会通过 Playwright MCP 服务器启动浏览器，依次执行每一步，并反馈它发现的内容。将它的总结与 issue 中的验收标准对照——如果有任何异常，可以继续追问，或在打开 pull request 之前让它回头修复代码。
-
-> [!NOTE]
-> 本测试要求应用运行在 `http://localhost:4321`。如果已经停止开发服务器，请在发送提示前重新启动。Copilot 第一次使用 Playwright MCP 服务器时，可能需要下载浏览器——如果提示缺少浏览器，让它运行 `npx playwright install chromium` 后再试一次。
-
-[playwright-mcp-server]: https://github.com/microsoft/playwright-mcp
-
-## 总结和后续步骤
-
-恭喜，已经使用 Playwright MCP 服务器配合 Copilot CLI 手动测试了这个功能。回顾一下，完成了以下事项：
-
-- 了解了什么是 Model Context Protocol (MCP)，以及 MCP 服务器如何扩展 Copilot CLI。
-- 使用 `/mcp add` 添加了 Playwright MCP 服务器。
-- 要求 Copilot 驱动浏览器，在发布前验证过滤功能。
-
-现在既然已经确认功能正常，可以继续下一节练习，在那里将[借助智能体技能打开一个 pull request][next-lesson]。
-
-## 资源
-
-- [MCP 到底是什么，为什么大家都在讨论它？][mcp-blog-post]
-- [Microsoft Playwright MCP Server][playwright-mcp-server]
-- [为 Copilot CLI 添加 MCP 服务器][cli-add-mcp]
-- [GitHub MCP Server][github-mcp-server]
-
-[previous-lesson]: ../3-generating-code/
-[next-lesson]: ../5-agent-skills/
-[mcp-blog-post]: https://github.blog/ai-and-ml/llms/what-the-heck-is-mcp-and-why-is-everyone-talking-about-it/
-[github-mcp-server]: https://github.com/github/github-mcp-server
-[cli-add-mcp]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
diff --git a/docs/zh-cn/cli/5-agent-skills.md b/docs/zh-cn/cli/5-agent-skills.md
index fce2b75f..55770fca 100644
--- a/docs/zh-cn/cli/5-agent-skills.md
+++ b/docs/zh-cn/cli/5-agent-skills.md
@@ -1,121 +1,93 @@
---
-title: "练习 5 - 使用智能体技能"
+title: "练习 5 - 创建并使用 quality-checks 技能"
+description: "让 Copilot 创建带有配套 shell 脚本的可复用质量检查技能，检查技能内容，并在筛选功能分支上执行。"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
-应用开发经常包含一些可重复的任务，例如生成构建、运行测试或创建 pull request。**智能体技能 (Agent skills)** 让你可以为 Copilot——以及其他 AI 智能体——提供执行这些任务的指导。一个技能是一个文件夹，其中包含说明、脚本和资源，智能体可以按需加载。[Agent Skills 是一项开放标准][agent-skills-repo]，被多种智能体采用，因此同一个技能可以同时在 agent mode 的 Copilot Chat、Copilot cloud agent、Copilot CLI 和 GitHub Copilot app 中使用。
+筛选功能已经实现，并已使用现有 npm 命令完成检查。现在，将这些检查封装为可复用的**智能体技能**。练习 4–8 始终使用同一个筛选功能会话和分支；本练习不创建 pull request。
-技能存放在项目的 `.github/skills` 文件夹中，也可以全局存放在 `~/.copilot/skills`。每个技能都是一个文件夹，其中包含一个 `SKILL.md` 文件。该文件具有 YAML frontmatter（至少包含 `name` 和 `description`），后面跟着 markdown 说明：
-
-```yaml
----
-name: make-contribution
-description: All changes to code must follow the guidance documented in the repository. Before any issue is filed, branch is made, commits generated, or pull request (or PR) created, a search must be done to ensure the right steps are followed. Whenever asked to create an issue, commit messages, to push code, or create a PR, use this skill so everything is done correctly.
----
-```
-
-技能还可以包含脚本、资源和参考资料等子文件夹。完整结构请参见[智能体技能规范][agent-skills-spec]。
-
-> [!TIP]
-> 技能是动态加载的。智能体会根据 `description` 字段判断应使用哪个技能——清晰、针对场景的描述，是一个技能会被使用还是被忽略的关键区别。
-
-[agent-skills-repo]: https://github.com/agentskills/agentskills
-[agent-skills-spec]: https://agentskills.io/specification
+在本练习中，将：
-接下来看看，一个技能如何确保 pull request 符合团队制定的规范。
+- 在创建自定义配置前返回 **Interactive** 模式。
+- 让 Copilot 创建 `quality-checks`，然后停下来供你检查。
+- 通过配套脚本执行全部四项检查，并证明单文件测试参数只会选中指定文件。
+- 在筛选功能分支上为技能创建检查点。
-## 场景
+## 指令、脚本和资源
-团队对 pull request（PR）有一组要求：
+技能将可复用的任务指令、可执行脚本和辅助资源打包，供智能体按需加载。自定义智能体定义专业角色、指令和可用工具。两者相辅相成：自定义智能体可以执行脚本，包括技能附带的脚本。
-- 提交消息要清晰，文件分组要合理。
-- 创建 PR 之前，所有测试都必须通过。
-- 每个 PR 都必须包含以下部分：
- - 说明为什么要进行这些更改。
- - 概述已更改的文件。
- - 重要代码块的片段。
- - 按组整理的更改详情。
+存储库技能位于 `.github/skills//SKILL.md`，包含带有 `name` 和 `description` 的 frontmatter 以及 Markdown 指令。脚本和其他资源存放在旁边。这里将让 Copilot 生成 `.github/skills/quality-checks/SKILL.md` 及其配套脚本，而不是复制现成答案。[Agent Skills 规范][skill-spec]介绍了这种格式。
-由于团队正在使用 Copilot 生成代码和 PR，因此希望确保 AI 工具也能遵循这些要求。
+Copilot 根据已发现技能的描述，决定何时加载它。不要假定新技能会立即被已打开的会话发现；运行部分提供了明确读取技能的备用方式。格式可移植并不意味着无需满足 shell 或项目的前提条件。
-在本练习中，将：
+## 创建技能
-- 探索一个现有的用于创建 pull request 的技能。
-- 了解 AI 智能体如何使用技能。
-- 在技能的帮助下，创建一个符合准则的 PR。
+发送提示前返回 **Interactive** 模式。保持当前检出目录和分支。如果使用的旧版模板已经包含此技能，应先检查并扩展它，而不是覆盖已有的自定义内容。
-## 执行技能
+```plaintext
+创建 .github/skills/quality-checks/SKILL.md 和四个封装脚本，分别调用 npm run lint、npm run test:unit、npm run test:e2e 和 npm run typecheck:all。先阅读 package.json、README、测试配置和存储库指令。
-当智能体判断某个技能有必要时，会动态加载它。决定使用哪些技能的依据，就是 `SKILL.md` 文件中的描述。因此，使用场景清晰的描述非常重要。
+识别当前环境。macOS/Linux/WSL 只创建 Bash .sh 脚本，原生 Windows 只创建 PowerShell .ps1 脚本；如果无法确定，先询问。不要同时创建两种实现。封装脚本仅负责根据自身位置解析存储库根目录，验证该目录包含本项目的 package.json，然后调用 npm。根目录无效时，应明确报错并失败退出。支持任意工作目录和包含空格的路径。保留输出和失败退出代码，包括 PowerShell 原生命令的失败。npm 的 -- 分隔符只插入一次；调用方直接提供工具参数，不再添加 --。不要管理端口或进程。
-## 探索 PR 技能
+在 SKILL.md 中提供 name 和 description frontmatter、运行全部四个封装脚本的指令、前提条件、故障排查方法，以及包含一个现有单元测试文件的可移植调用示例。所有 Bash 示例都必须显式调用 bash；绝不绕过 PowerShell 执行策略。解释 Playwright 的服务器复用：只停止确实由自己启动的服务器，否则先询问。
-由于 Tailspin Toys 对创建 PR 有一套要求，因此他们创建了一个技能，帮助 AI 工具生成符合这些准则的 PR。现在来看看这个技能，了解它会执行什么。
+只创建技能和必需的脚本。不要运行检查或探测，不要安装任何内容、修改应用代码、提交或创建 PR。然后停止，等待检查。
+```
-1. 打开 `.github/skills/make-contribution/SKILL.md`。
-2. 注意其中的名称和描述。可以看到，描述中强调了它适用的场景，也就是当请求创建 pull request 或提交代码时。
-3. 通读这个技能。注意其中定义了分支应如何创建、提交应如何生成，以及 pull request 的内容应包含什么。
+## 检查技能
-## 使用技能
+1. 在编辑器中打开 `.github/skills/quality-checks/SKILL.md` 及其配套脚本，并检查差异。
+2. 检查 `name` 和 `description` 是否说明了技能及其适用场景。阅读指令，不要只看元数据。
+3. 确认执行顺序确实调用 `.github/skills/quality-checks/` 下的配套脚本，执行 lint、单元测试、E2E 和类型检查。
+4. 检查每个封装脚本是否根据自身位置解析根目录，并明确检查推导出的目录是否包含此检出目录中预期的 `package.json`。命令因 npm 搜索祖先目录而成功，并不能证明根目录正确。检查路径是否加引号、参数是否转发、输出是否可见，以及失败时是否正确退出；PowerShell 必须传递原生 npm 命令的失败状态。
+5. 检查文档中只运行一个单元测试文件的示例。封装脚本负责插入 npm 的 `--` 分隔符，因此调用方应直接传递目标工具的参数，不再添加分隔符。可复用指令中不应包含特定机器的检出目录绝对路径。在运行任何内容之前，让 Copilot 修正遗漏或问题。
+6. 脚本应仅负责根目录和清单文件验证，以及运行现有 npm 检查。端口和进程相关决策应放在 SKILL.md 中，而不是通过 shell 进程管理代码实现。确认只有智能体实际启动的服务器才可以停止；工作目录或进程名称匹配不能证明归属。交付的文件应仅包含技能、必需的封装脚本和必要的共享辅助文件，不含临时探测或调试文件。
-如前所述，技能会由 Copilot CLI 自动调用。因此，只需请求 Copilot 创建一个 PR。
+> [!NOTE]
+> 当前 Tailspin Toys 需要 Node.js 22.13 或更高版本、项目依赖项，以及用于 E2E 检查的 Playwright Chromium。在检出目录的 README 和 `package.json` 中确认前提条件。缺少前提条件或 PowerShell 执行策略阻止运行时，需要经批准的解决方案，而不是自动安装、绕过策略或悄悄改为直接运行 npm。
-> [!TIP]
-> **启动 Copilot CLI 会话**
->
-> 开始下面的练习前，先返回 codespace 并打开一个终端（如果还没打开，可按 Ctrl+\`）。然后使用 `--yolo` 和 `--enable-all-github-mcp-tools` 启动 Copilot CLI：
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 如果希望接续这个项目最近一次会话，而不是重新开始，请运行 `copilot --yolo --enable-all-github-mcp-tools --continue`。如果 Copilot CLI 仍在运行之前练习中的会话，请发送 `/clear` 开始一段新的对话。
->
-> `--enable-all-github-mcp-tools` 会为当前会话启用 GitHub MCP 读写工具，因此在工作坊流程中 Copilot 可以读取积压工作并打开 pull request。
+## 运行技能
-> [!CAUTION]
-> `--yolo` 会启用完整的自动权限（`--allow-all-tools`、`--allow-all-paths` 和 `--allow-all-urls`）。只能在 Codespace 或 VM 这类隔离环境中使用，绝不要把它设成日常开发的默认别名。详情见[允许和拒绝工具使用][allow-all-warning]。
+确认上一练习的开发服务器已停止。Playwright 会为 E2E 构建并提供预览服务，但其本地配置可以复用端口 `4321` 上的服务器。其他检出目录的服务器不能为当前功能提供有效证据。
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
+如果 Copilot CLI 提供 `/quality-checks`，选择它来显式调用已发现的技能，并附上以下请求。如果未发现技能，直接在此会话中发送相同请求；本练习支持通过读取技能的方式运行它。
-1. 使用以下提示，请 Copilot 创建一个 PR：
+```plaintext
+读取 .github/skills/quality-checks/SKILL.md，并按照其中的指令验证此检出目录中的筛选功能。先检查每个封装脚本的代码，确认其推导出的目录包含此检出目录中预期的 package.json，且根目录无效时会明确报错并失败退出，而不是依赖 npm 在祖先目录中查找包。不要为模拟失败而移动、重命名、删除或修改存储库文件。实际运行其配套脚本，执行 lint、单元测试、端到端测试和类型检查。同时运行文档中只运行一个单元测试文件的示例，直接传递目标工具的参数，因为 npm 的 -- 分隔符由封装脚本负责。根据测试运行器的结果，确认仅运行了指定文件，并报告该文件名及实际执行的测试文件数量。仅回显参数或返回退出代码 0，不能证明文件选择正确。
- ```
- Can you please create a pull request for me!
- ```
+报告每次脚本调用及其结果，包括失败、跳过的检查或缺失的前提条件。不要在技能脚本无法使用时悄悄改为直接运行 npm 命令。确认待测试的检出目录和服务器，只停止你启动的服务器，并在安装任何内容或停止其他进程前询问。不要修改应用代码、切换分支、提交、推送或创建 pull request。
+```
-2. Copilot 会确认这个请求。稍等片刻后，会看到 Copilot 显示它正在使用 **make-contribution** 技能。
+检查工具调用和输出。四个脚本都必须实际执行；描述检查内容或跳过检查都不算通过。对于单文件示例，将请求的文件名与运行器实际输出的文件结果及报告的数量进行比较：应只运行该文件。如果还运行了其他文件，回显参数或退出代码 0 都不足以证明正确。失败是有用的证据：修正技能，或在获批后解决环境配置阻碍，再重新运行受影响的检查。不要停止无关进程，也不要强行消除端口冲突。
-3. 然后 Copilot 会遵循该技能中的说明。它会先运行测试，然后创建分支、提交，最后创建 PR。
-4. 创建 PR 后，返回存储库并打开该 PR。注意其中各个部分遵循了技能中设定的准则，与团队提出的要求一致。
-5. 在进入下一节练习前，将本地工作区重置到从 `main` 创建的新分支，以便后续无障碍工作与这个过滤功能 PR 保持分离：
+## 保存检查点
- ```bash
- git checkout main
- git pull
- git checkout -b accessibility-cli
- ```
+检查技能及其运行结果后，授权创建本地检查点：
-## 总结和后续步骤
+```plaintext
+检查当前差异，仅为 quality-checks 技能文件创建检查点提交。保留现有筛选功能分支。不要推送或创建 pull request。
+```
-在智能体技能的帮助下，已经创建了一个符合文档要求的新 PR。完成了以下事项：
+技能文件将与筛选功能、QA 配置和相关测试一起纳入练习 8 的功能 PR。继续在同一检出目录中完成[练习 6 - 使用 Playwright MCP 验证功能][next-lesson]。
-- 探索了一个现有的 pull request 创建技能。
-- 了解了 AI 智能体如何使用技能。
-- 在技能的帮助下，创建了一个符合准则的 PR。
+## 更多技能示例
-技能非常适合处理任务，但如果需要更强大的操作能力，就应该利用[自定义智能体][next-lesson]，下一节就会探索这一点。
+以下社区示例仅供参考，不是额外任务。采用前先检查其前提条件和行为：
-## 资源
+- [贡献工作流：`make-repo-contribution`][contribution-example]。
+- [需求文档：`prd`][prd-example]。
+- [图表及配套导出脚本：`drawio`][drawio-example]。
+- [浏览器测试：`webapp-testing`][browser-example]。
-- [关于 Agent Skills][about-agent-skills]
-- [Agent Skills 规范][agent-skills-spec]
-- [Agent Skills 存储库][agent-skills-repo]
-- [awesome-copilot 上的 Agent Skills][awesome-copilot-skills]
+上游贡献示例名为 `make-repo-contribution`；旧版 Tailspin 模板使用另一个名称 `make-contribution`。本工作坊不依赖其中任何一个贡献技能。
-[previous-lesson]: ../4-mcp/
-[next-lesson]: ../6-custom-agents/
-[about-agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[awesome-copilot-skills]: https://github.com/github/awesome-copilot/tree/main/skills
+[previous-lesson]: ../4-build-filtering/
+[next-lesson]: ../6-mcp-playwright/
+[skill-spec]: https://agentskills.io/specification
+[contribution-example]: https://github.com/github/awesome-copilot/tree/main/skills/make-repo-contribution
+[prd-example]: https://github.com/github/awesome-copilot/tree/main/skills/prd
+[drawio-example]: https://github.com/github/awesome-copilot/tree/main/skills/drawio
+[browser-example]: https://github.com/github/awesome-copilot/tree/main/skills/webapp-testing
diff --git a/docs/zh-cn/cli/6-custom-agents.md b/docs/zh-cn/cli/6-custom-agents.md
deleted file mode 100644
index 366d1f01..00000000
--- a/docs/zh-cn/cli/6-custom-agents.md
+++ /dev/null
@@ -1,115 +0,0 @@
----
-title: "练习 6 - 在 GitHub Copilot CLI 中使用自定义智能体"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-## 什么是自定义智能体？
-
-GitHub Copilot 中的[自定义智能体][custom-agents-concept]允许创建适用于开发工作流中特定任务或领域的专用 AI 助手。通过在存储库的 `.github/agents` 文件夹中使用 markdown 文件定义智能体，可以为 Copilot 提供聚焦的说明、最佳实践、编码模式和领域知识，从而引导它更高效地完成特定类型的工作。团队可以把自身经验固化为可复用智能体——例如强制遵循 [WCAG][wcag] 的无障碍智能体、遵循安全编码实践的安全智能体，或保持一致测试模式的测试智能体。
-
-自定义智能体通过项目 `.github/agents` 文件夹中的 markdown 文件定义，也可以全局定义在 `~/.copilot/agents` 中。每个文件都有 YAML frontmatter，至少包含 `name` 和 `description`，后面跟着一个 markdown prompt，用于定义智能体的行为、专长和说明。
-
-### 自定义智能体与智能体技能的对比
-
-自定义智能体与[智能体技能][agent-skills-concept]在逻辑上有一些重叠。两者主要都通过 markdown 文件定义，也都在告诉 AI 如何执行操作。最清晰的区分方式是：**自定义智能体**是执行工作的角色，而 **skills** 是工具。
-
-自定义智能体拥有自己的上下文窗口，并且设计上就用于在工作过程中编排技能（甚至其他智能体）。在这个实验中，无障碍自定义智能体会根据无障碍准则审查并更新网站；在执行这项工作时，它可以调用诸如 pull request 工作流技能，或用于运行和管理测试的技能。
-
-> [!NOTE]
-> 编写自定义智能体并不存在唯一“正确”的方式。和 AI 中的大多数事情一样，需要测试并迭代，找到最适合环境和场景的做法。
-
-[custom-agents-concept]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-custom-agents
-[agent-skills-concept]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[wcag]: https://www.w3.org/WAI/standards-guidelines/wcag/
-
-## 场景
-
-许多 Web 应用在无障碍方面都做得不够，而正在使用的网站也不例外。接下来将使用一个自定义智能体来识别并解决无障碍缺陷。
-
-Tailspin Toys 致力于确保其众筹平台对所有用户都可访问，无论其视觉能力或偏好如何。最近的用户反馈指出，由于文本与背景颜色之间的对比度不足，一些用户认为当前的深色主题难以阅读。为了解决这一无障碍问题，设计团队要求实现一种可开关的高对比度模式。
-
-由于无障碍非常关键，希望尽快实现这项功能。因此将使用一个自定义智能体来生成功能。
-在本练习中，将：
-
-- 探索自定义智能体。
-- 启用一个自定义智能体，并通过 Copilot CLI 为其分配任务。
-
-## 查看无障碍自定义智能体
-
-项目中已经预先创建了一个用于无障碍的自定义智能体。先查看其内容，了解它将如何引导 Copilot。
-
-1. 打开 `.github/agents/accessibility.md`。
-2. 注意其中带有 `name` 和 `description` 字段的 YAML frontmatter。
-
-> [!CAUTION]
-> 自定义智能体必须包含带 `name` 和 `description` 的 frontmatter。
-
-3. 接着浏览后续部分，查看其中强调的内容：
- - 为无障碍网站生成代码时的核心职责。
- - 无障碍最佳实践。
- - HTML、CSS 和 JavaScript 的代码示例。
- - 常见陷阱和错误列表。
-
-## 在 Copilot CLI 中使用自定义智能体
-
-可以通过 `/agent` 命令在 Copilot CLI 中启动自定义智能体。现在对网站执行一次无障碍检查。
-
-> [!TIP]
-> **启动 Copilot CLI 会话**
->
-> 开始下面的练习前，先返回 codespace 并打开一个终端（如果还没打开，可按 Ctrl+\`）。然后使用 `--yolo` 和 `--enable-all-github-mcp-tools` 启动 Copilot CLI：
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 如果希望接续这个项目最近一次会话，而不是重新开始，请运行 `copilot --yolo --enable-all-github-mcp-tools --continue`。如果 Copilot CLI 仍在运行之前练习中的会话，请发送 `/clear` 开始一段新的对话。
->
-> `--enable-all-github-mcp-tools` 会为当前会话启用 GitHub MCP 读写工具，因此在工作坊流程中 Copilot 可以读取积压工作并打开 pull request。
-
-> [!CAUTION]
-> `--yolo` 会启用完整的自动权限（`--allow-all-tools`、`--allow-all-paths` 和 `--allow-all-urls`）。只能在 Codespace 或 VM 这类隔离环境中使用，绝不要把它设成日常开发的默认别名。详情见[允许和拒绝工具使用][allow-all-warning]。
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. 在 Copilot CLI 的提示窗口中输入 `/agent` 并选择 Enter，调出智能体列表。
-2. 从可用智能体列表中选择 **Accessibility agent**。
-3. 使用以下提示，请无障碍智能体执行审查，并为无障碍积压工作项生成修复：
-
- ```
- Perform an accessibility review of the site. Pull the related issue down from the repository for details. Implement a high-contrast mode toggle that persists the user's preference across page reloads. Ensure there are e2e tests for any updates made to the project. Then create a PR with the updates.
- ```
-
-4. Copilot 会开始处理这项任务。它会先检索 issue，然后执行审查、生成更新，最后创建 PR。创建 PR 时，还会注意到它使用了项目中专门处理 PR 的技能。
-
-> [!NOTE]
-> 这个过程可能需要几分钟。正好可以回顾一下到目前为止学到的所有内容、休息片刻，或者提前看一下下一模块——其中会介绍 Copilot CLI 中更多可用命令。
-
-## 总结和后续步骤
-
-本课探索了 GitHub Copilot 中的[自定义智能体][custom-agents]：它们是面向特定任务和领域定制的专用 AI 助手。通过自定义智能体，可以把团队的经验和标准固化为可复用智能体，引导 Copilot 更高效地完成特定类型的工作。
-
-本课探索了以下概念：
-
-- 自定义智能体是如何定义的。
-- 如何在 Copilot CLI 中使用自定义智能体。
-
-接下来将探索[一些斜杠命令][next-lesson]，学习更多 Copilot CLI 的使用技巧。
-
-## 资源
-
-- [自定义智能体][custom-agents]
-- [为存储库创建自定义智能体][creating-custom-agents]
-- [awesome-copilot 上的自定义智能体][awesome-copilot-agents]
-- [在组织中启用自定义智能体的准备工作][org-custom-agents]
-- [在企业中启用自定义智能体的准备工作][enterprise-custom-agents]
-
-[previous-lesson]: ../5-agent-skills/
-[next-lesson]: ../7-slash-commands/
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[creating-custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/create-custom-agents
-[awesome-copilot-agents]: https://github.com/github/awesome-copilot/tree/main/agents
-[org-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-organization/prepare-for-custom-agents
-[enterprise-custom-agents]: https://docs.github.com/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/prepare-for-custom-agents
diff --git a/docs/zh-cn/cli/6-mcp-playwright.md b/docs/zh-cn/cli/6-mcp-playwright.md
new file mode 100644
index 00000000..20769a8e
--- /dev/null
+++ b/docs/zh-cn/cli/6-mcp-playwright.md
@@ -0,0 +1,83 @@
+---
+title: "练习 6 - 使用 Playwright MCP 验证功能"
+description: "通过 MCP 连接浏览器，将观察到的筛选行为与议题和批准的计划进行比较。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+筛选实现和 quality-checks 技能已经过自动化验证。现在为 Copilot 提供浏览器，让它直接观察功能。本练习展示**模型上下文协议（MCP）**交互，而不是再次运行完整测试套件。
+
+在同一筛选检出目录和分支上保持 **Interactive** 模式。配置 MCP 不会开始新的功能里程碑。
+
+## MCP 带来的能力
+
+[MCP][mcp-overview] 通过服务器将智能体连接到外部工具和上下文。内置 GitHub MCP 服务器让 Copilot 能处理议题和 PR。[Playwright MCP 服务器][playwright-mcp]则提供打开页面、检查无障碍元素、导航及操作控件的浏览器工具。
+
+浏览器的无障碍快照有助于智能体识别控件，但不能证明完全符合无障碍要求。应将实际操作和观察结果与议题要求进行比较，而不是接受笼统的“看起来不错”。
+
+> [!CAUTION]
+> 将 MCP 服务器视为项目依赖项：启用前审查发布者、源代码、权限和所有包下载。组织策略可能限制可运行的服务器。不要将凭据放入已提交的配置，也不要只为完成练习而批准未知工具。
+
+## 配置 Playwright MCP
+
+1. 在现有 CLI 会话中输入 `/mcp`，检查已配置的服务器。复用可用的 Playwright 配置，不要重复添加。
+2. 如有需要，输入 `/mcp add`，使用 Tab 在表单中移动。
+3. 将 **Server Name** 设为 `playwright`，**Server Type** 设为 **STDIO**（或 **Local**），**Command** 设为 `npx @playwright/mcp@latest --headless`。
+4. 为此已审查的浏览器服务器，将 **Tools** 设为 `*`。这会使其工具可用，但不会替代 CLI 的权限控制。
+5. 审查包及启动命令后，按 Ctrl+S 保存。注册会启动服务器，并可能下载包；应明确批准该设置，并回应包提示。
+6. 输入 `/mcp show playwright`，确认服务器已连接且浏览器工具可用。
+
+无头浏览器无需桌面窗口，适合 Codespaces。交互式添加流程将配置保存到 `~/.copilot/mcp-config.json`，无需重启 CLI 即可使用服务器。这是用户配置，不是应包含在功能 PR 中的文件。[MCP 设置指南][mcp-setup]说明了相关字段和配置来源。
+
+> [!NOTE]
+> 项目 E2E 依赖项与 MCP 浏览器有关，但可能需要不同设置。如果缺少浏览器或系统依赖项，应检查实际错误，并获批后解决具体的先决条件。不要自动安装浏览器，也不要假定服务器已连接就证明它能启动浏览器。
+
+## 启动正确的应用
+
+在同一筛选检出目录中打开单独的终端。确认目录和分支，再启动应用：
+
+```bash
+pwd
+git branch --show-current
+npm run dev
+```
+
+从服务器输出中读取实际本地 URL。在 codespace 中，MCP 服务器和应用处于同一环境，因此使用该本地 URL，通常是 `http://localhost:4321`，不要假定必须使用转发后的浏览器 URL。
+
+如果端口已占用或 Astro 选择了其他端口，继续前先确定服务器归属。不要复用或终止未知服务器。使用刚启动进程的 URL，并在测试期间保持该终端打开。
+
+## 观察筛选行为
+
+将占位符替换为真实议题 URL、练习 4 中批准的澄清内容和应用 URL：
+
+```plaintext
+使用已配置的 Playwright MCP 服务器，根据此议题验证筛选功能：。以下是规划时批准的澄清内容：<粘贴约定的澄清内容，或填写 none>。当前检出目录的应用运行于 。在依赖结果前，确认被测检出目录、分支和服务器。
+
+打开游戏页面，记录未筛选状态，先选择一个类别，再选择多个类别，应用发行商筛选，并组合类别和发行商选择。根据批准的标准测试清除筛选和空结果行为。检查控件标签、键盘操作和可见焦点。将显示结果与所选筛选条件及源数据比较，不要仅因为控件发生变化就推断成功。
+
+使用实际浏览器工具操作，逐项报告观察到的结果，并明确标出失败或缺失证据。不要仅为此浏览器练习再次运行完整测试套件，不要更改应用代码、创建测试或自定义配置、更改分支、提交、推送或打开 PR。在安装任何内容或停止其他进程前先询问。
+```
+
+检查浏览器工具调用和报告。Copilot 是否确实选择了多个类别并与发行商组合？返回的游戏是否符合约定行为？报告是否区分了可观察的浏览器行为、数据层覆盖和自动化测试覆盖？
+
+如果失败，记录观察到的行为。单独授权针对性的应用修复，再重复受影响的浏览器检查和自动化检查。不要为了迁就实现而修改验收标准，也不要将旧证据算作更改后代码的验证。
+
+## 停止自己启动的服务器并继续
+
+在启动开发服务器的终端中按 Ctrl+C 停止它。保持 Playwright MCP 配置可用。练习 7 将协调新的浏览器观察和自动化 E2E 检查，这些检查不得复用过时的开发服务器或其他检出目录的应用。
+
+创建 QA 配置文件前保持 **Interactive**。你已观察浏览器行为，没有额外创建 PR 或分支；接下来[创建并使用 QA 智能体][next-lesson]，将需求、覆盖情况、技能和最终证据结合起来。
+
+## 资源
+
+- [向 Copilot CLI 添加 MCP 服务器][mcp-setup]说明设置和管理方式。
+- [Microsoft Playwright MCP][playwright-mcp] 说明浏览器配置和工具。
+- [GitHub MCP 注册表][mcp-registry]列出其他可供评估的服务器。
+
+[previous-lesson]: ../5-agent-skills/
+[next-lesson]: ../7-qa-agent/
+[mcp-overview]: https://docs.github.com/copilot/concepts/context/mcp
+[mcp-setup]: https://docs.github.com/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers
+[playwright-mcp]: https://github.com/microsoft/playwright-mcp
+[mcp-registry]: https://github.com/mcp
diff --git a/docs/zh-cn/cli/7-qa-agent.md b/docs/zh-cn/cli/7-qa-agent.md
new file mode 100644
index 00000000..de3f504c
--- /dev/null
+++ b/docs/zh-cn/cli/7-qa-agent.md
@@ -0,0 +1,77 @@
+---
+title: "练习 7 - 创建并使用 QA 智能体"
+description: "创建以需求为先的 QA 配置，将测试覆盖、quality-checks 技能和直接浏览器验证证据结合起来。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+你已运行可重复的检查，并通过 Playwright MCP 探索了筛选功能。现在创建一个 **QA 自定义智能体**，将需求、覆盖情况和浏览器验证证据结合起来。保留筛选功能会话、检出目录和分支；到练习 8 再创建功能 PR。
+
+## 创建 QA 配置
+
+保持 **Interactive** 模式。配置定义专业角色及其指令；技能封装可复用的任务指令、脚本和资源。QA 智能体将使用你的技能和已配置的 MCP 工具，而不是取代它们。
+
+发送以下提示，然后在运行前检查定义：
+
+```plaintext
+在 .github/agents/qa.agent.md 中创建可复用的 QA 自定义智能体。先检查存储库指令、package.json、测试配置和 .github/skills/quality-checks/SKILL.md。为配置提供有效的 YAML frontmatter，其中 name 为 QA，description 说明适用场景。不要固定模型或添加 tools 列表；继承当前使用环境的可用工具和权限。只创建智能体定义，然后停止，让我在运行前检查。
+
+在智能体指令中，要求每项 QA 任务都从用户提供的 issue 和已批准的验收标准出发。以这些需求而非实现为准。需求缺失或不明确时要询问。检查功能及现有测试，将每项标准映射到适当的自动化覆盖和可观察的行为。
+
+要求通过已配置的 Playwright MCP 服务器直接进行浏览器验证，并通过现有 quality-checks 技能及其配套脚本执行 lint、单元测试、端到端测试和类型检查。如果技能尚未被自动发现，则明确读取技能。缺少技能、MCP 工具、前提条件或访问权限时，报告为受阻；不要悄悄改用其他工作流，也不要把跳过的检查标记为通过。确认待测试的检出目录和服务器，避免复用其他工作树的服务器，只停止智能体自己启动的服务器，并在任何安装或停止其他进程前询问。
+
+允许 QA 智能体遵循存储库指令，为确实存在的覆盖缺口添加最少的必要测试；覆盖已经充分时，不添加测试也是有效结果。不要弱化断言、禁用失败测试、为迎合代码而修改验收标准，或未经我批准修改应用代码。更改后，重新运行受影响的检查，并对更改后的版本完成最终验证。要求提供简明报告，将标准映射到证据和通过/失败/受阻状态，列出新增测试或解释为何不需要，报告全部四项检查结果，并指出尚未解决的缺陷。只有具备所有必需的检查和证据，才能给出 GO；否则报告 NO-GO 并说明原因。QA 期间不要切换分支、提交、推送、创建或合并 PR，也不要创建其他智能体或技能。
+```
+
+## 检查配置
+
+在编辑器中打开 `.github/agents/qa.agent.md` 并检查差异。`description` 是必需字段；本练习还将易读的 `name` 设置为 `QA`。确认没有固定 `model`，也没有虚构工具列表。省略 `tools` 会继承可用工具，但不会绕过使用环境的权限。生产配置可以有意限制工具。
+
+确认指令从需求出发，要求实际使用 MCP 浏览器工具和技能脚本，只允许有充分理由的测试补充，并如实报告阻碍。专业角色配置和技能都不要求独立的上下文窗口，也不要求编排其他智能体。
+
+## 根据 issue 运行 QA
+
+运行提示应发送给选中的 **QA** 自定义智能体，而不是让默认智能体读取配置。在同一检出目录中启动新的 CLI 对话以加载新配置，不要创建其他功能分支。
+
+1. 保存筛选功能 issue 的 URL 和已批准的澄清内容。等待当前智能体完成，然后输入 `/exit` 返回终端。
+2. 使用 `git branch --show-current` 和 `git status --short` 确认仍在筛选功能存储库目录中，并处于同一分支。不要切换分支或创建工作树。
+3. 使用存储库配置启动 CLI：
+
+ ```shell
+ copilot --agent qa
+ ```
+
+4. 运行前，确认 CLI 显示选中的智能体是 **QA**。[CLI 命令参考][cli-reference]记录了 `--agent`；仅写入或读取配置不代表激活。如果选择失败，或智能体无法访问已配置的 Playwright MCP 工具和技能，暂停并与讲师一起解决这一阻碍。
+
+将两个占位符替换为实际筛选功能 issue 的 URL 和练习 4 中批准的澄清内容；如果 issue 已完整说明需求，则填写 `none`。不要依赖前一个智能体的记忆。
+
+```plaintext
+根据此 issue 验证筛选功能：。以下是我在规划期间批准的补充验收标准：<粘贴约定的澄清内容，或填写 none>。
+
+使用 Playwright MCP 服务器验证行为，检查测试覆盖，仅针对覆盖缺口添加测试，并通过 quality-checks 技能运行验证。报告证据、检查结果和阻碍。未经我批准，不要修改应用代码。不要创建提交或 pull request。
+```
+
+## 审查证据
+
+对照 issue 检查报告：每项标准都需要适当的自动化覆盖和可观察的行为。检查实际的 Playwright MCP 工具活动、检出目录和服务器身份，以及全部四项技能脚本结果。浏览器检查和自动化 E2E 不得复用过时的服务器或其他检出目录。
+
+审查新增测试：它们应填补真正的缺口，而不是弱化断言。覆盖充分时，不新增测试是正确做法。因受阻或失败而给出 **NO-GO** 是有效结果，不代表可以跳过证据。
+
+如果 QA 发现应用缺陷，另行批准针对性修复，并在更改后的版本上重新执行受影响的检查和浏览器观察。缺少前提条件或工具时，需要明确的解决方案。不要将旧证据当作更改后代码的证明。
+
+## 保存检查点
+
+QA 完成后，保存其报告，其中应包含 issue URL、已批准的澄清内容、测试过的版本、浏览器观察和检查结果。输入 `/exit`，然后在同一目录和分支中启动不带 `--agent` 的 `copilot`，返回普通对话。再次提供这些上下文；新对话不会继承 QA 对话的证据。
+
+审查配置、测试更改及相应证据后，向普通智能体发送以下请求：
+
+```plaintext
+检查当前差异，为 QA 智能体定义和已批准的测试更改创建检查点提交。保留现有筛选功能分支。不要推送或创建 pull request。
+```
+
+带着筛选功能、技能、QA 配置、测试和当前验证证据，继续完成[练习 8 - 创建并合并功能 PR][next-lesson]。
+
+[previous-lesson]: ../6-mcp-playwright/
+[next-lesson]: ../8-create-pull-request/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/zh-cn/cli/7-slash-commands.md b/docs/zh-cn/cli/7-slash-commands.md
deleted file mode 100644
index 15262f20..00000000
--- a/docs/zh-cn/cli/7-slash-commands.md
+++ /dev/null
@@ -1,177 +0,0 @@
----
-title: "练习 7 - GitHub Copilot CLI 中的斜杠命令"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-像其他优秀的 CLI 工具一样，GitHub Copilot CLI 也提供了许多斜杠命令供交互使用。这些命令会暴露高级功能、“幕后”信息或额外的配置选项。前面已经体验过 `/clear`（清理上下文）和 `/mcp`（查看 MCP 服务器）。接下来再探索几个强大的命令，包括 `/context`、`/model`、`/share` 和 `/delegate`。
-
-## 场景
-
-核心 CLI 流程已经体验完毕。现在再看看一些附加能力——共享会话、切换模型，以及把任务委托给 [Copilot cloud agent][about-cloud-agent]。
-
-在本练习中，将使用：
-
-- `/share` 创建一个 GitHub gist，与团队共享会话。
-- `/context` 查看 Copilot CLI 当前使用的上下文。
-- `/model` 查看可用模型列表，并在需要时选择新的模型。
-- `/delegate` 可选地把任务移交给 cloud agent。这需要 cloud agent，Copilot Student、Pro、Pro+、Business 和 Enterprise 都支持——只有 Copilot Free 不支持。
-
-## 共享会话
-
-无论使用什么工具，包括 AI 工具，本身都是一种技能。与团队一起工作、彼此分享经验，是帮助所有人提升体验并生成更高质量代码的最佳方式。为此，Copilot CLI 提供了 `/share` 命令。`/share` 可以生成 markdown 文件或 GitHub gist，其中包含会话详情、使用过的提示以及 Copilot 采取的逻辑。
-
-现在创建一个可以分享给团队的 GitHub gist。
-
-> [!TIP]
-> **启动 Copilot CLI 会话**
->
-> 开始下面的练习前，先返回 codespace 并打开一个终端（如果还没打开，可按 Ctrl+\`）。然后使用 `--yolo` 和 `--enable-all-github-mcp-tools` 启动 Copilot CLI：
->
-> ```bash
-> copilot --yolo --enable-all-github-mcp-tools
-> ```
->
-> 如果希望接续这个项目最近一次会话，而不是重新开始，请运行 `copilot --yolo --enable-all-github-mcp-tools --continue`。如果 Copilot CLI 仍在运行之前练习中的会话，请发送 `/clear` 开始一段新的对话。
->
-> `--enable-all-github-mcp-tools` 会为当前会话启用 GitHub MCP 读写工具，因此在工作坊流程中 Copilot 可以读取积压工作并打开 pull request。
-
-> [!CAUTION]
-> `--yolo` 会启用完整的自动权限（`--allow-all-tools`、`--allow-all-paths` 和 `--allow-all-urls`）。只能在 Codespace 或 VM 这类隔离环境中使用，绝不要把它设成日常开发的默认别名。详情见[允许和拒绝工具使用][allow-all-warning]。
-
-[allow-all-warning]: https://docs.github.com/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
-
-1. 在 Copilot CLI 的提示窗口中发送以下命令：
-
- ```
- /share gist
- ```
-
-2. 稍等片刻后，Copilot 会创建一个 gist 并显示链接。
-3. 复制该链接文本。
-4. 在新的浏览器标签页中粘贴链接并查看 gist。注意其中如何突出显示已发送的提示、使用过的技能和智能体、Copilot 的思考过程，甚至包括本地运行命令的代码和结果。
-
-`/share` 生成的 gist 和 markdown 文件，既可以作为代码生成过程的文档，也可以用于向团队分享某些操作是如何完成的，以及这些操作如何帮助 Copilot 生成期望结果。
-
-## 探索 Copilot CLI 的上下文
-
-处理较大或较复杂的任务时，可能会触及模型的最大上下文窗口。窗口的具体大小取决于所使用的模型和 Copilot CLI 版本。当上下文窗口达到上限时，Copilot CLI 会自动压缩上下文，总结信息并移除它认为与当前任务无关的内容。可以使用斜杠命令查看当前上下文状态，也可以手动压缩上下文。现在来看看上下文窗口。
-
-1. 在 Copilot CLI 的提示窗口中发送以下命令：
-
- ```
- /context
- ```
-
-2. 稍等片刻后，Copilot CLI 会生成当前上下文的可视化表示：
-
- 
-
-3. 注意显示的模型（可能与图片中不同）以及当前已使用的 token 百分比。其余信息展示了以下内容：
-
- | 标题 | 说明 |
- | ------------ | ------------------------------------------------------ |
- | System/Tools | 说明文件、文件内容和工具定义 |
- | Messages | 与 Copilot 的对话历史 |
- | Buffer | Copilot CLI 为生成响应预留的空间 |
- | Free space | 剩余可用空间 |
-
-4. 向 Copilot CLI 发送以下斜杠命令，压缩对话历史：
-
- ```
- /compact
- ```
-
-5. 完成后，再次发送以下命令，显示当前上下文统计：
-
- ```
- /context
- ```
-
-6. 注意上下文的变化。由于当前上下文窗口可能还比较小，变化未必十分明显。
-
-> [!NOTE]
-> 当上下文变满时，Copilot CLI 会自动压缩。接近 100% 容量时，它会在提示窗口上方显示百分比。通常它会异步压缩，因此在处理过程中仍可继续与 Copilot 交互。不过，它也可能在执行压缩时阻塞当前操作几秒钟。
-
-### 上下文最佳实践
-
-在大多数会话中，Copilot 本身就能高效管理上下文，通常不需要额外指导。不过，在某些情况下，可能会决定手动指示 Copilot 清空或压缩其历史记录：
-
-- 如果要切换到应用的其他部分，或转到无关任务，可以使用 `/clear` 重新开始，避免旧的无关上下文让 Copilot 混淆。
-- 如果即将接近最大上下文窗口，可以手动使用 `/compact`，自行控制压缩发生的时机。
-
-> [!CAUTION]
-> 再次强调，大多数时候 Copilot 都能在无需直接干预的情况下管理上下文。如果发现 Copilot 因较早的信息而有些混乱，或者即将切换到无关任务，再考虑使用这些手动命令即可。
-
-## 选择模型
-
-不同模型有不同的强项，不同开发者也会有不同偏好。Copilot CLI 允许列出并选择要使用的模型。
-
-1. 向 Copilot CLI 发送以下斜杠命令，显示模型列表：
-
- ```
- /model
- ```
-
-2. 查看模型列表。每个模型旁边都会显示其名称及单次请求成本修正值。
-3. 如果需要，可以选择一个新模型；或者选择 Esc 退出模型列表。
-
-> [!CAUTION]
-> 在 Copilot CLI 中，模型选择会持久保留。
-
-## 委托给 cloud agent（可选）
-
-有时希望继续在终端中工作，但把耗时较长的任务交给 Copilot cloud agent。`/delegate` 命令会把当前 Copilot CLI 会话发送到 GitHub.com，由 cloud agent 接手，异步处理，并在完成后打开 pull request。
-
-> [!NOTE]
-> `/delegate` 需要 cloud agent，Copilot Student、Pro、Pro+、Business 和 Enterprise 都支持——只有 Copilot Free 不支持。如果没有访问权限，可以阅读这一部分，然后跳过动手步骤。
-
-1. 先清空当前会话，避免把整个工作坊累积的上下文一并委托出去：
-
- ```
- /clear
- ```
-
-2. 发送一个范围较小、定义清晰的提示。例如，可以委托积压工作中的延伸目标——分页功能：
-
- ```
- Implement pagination on the game list page so it shows a fixed number of games per page with Previous and Next controls, and add tests.
- ```
-
-3. 发送以下斜杠命令，把会话交给 cloud agent，并确认要委托的提示：
-
- ```
- /delegate
- ```
-
-4. 在浏览器中打开 [Copilot agents](https://github.com/copilot/agents) 以监控进度。
-5. 在这个路径中，无需等待 pull request 完成；稍后可以再回来查看。如果想更深入了解如何管理异步 agent 工作，可继续学习 [Cloud agent 路径](../../cloud/)。
-
-## 总结和后续步骤
-
-在 Copilot CLI 中使用斜杠命令，可以对它进行配置、共享会话，并查看 Copilot 工作方式的内部信息。本课中，已经使用或了解了以下内容：
-
-- 使用 `/share` 创建 GitHub gist，与团队共享会话。
-- 使用 `/context` 查看 Copilot CLI 当前使用的上下文。
-- 使用 `/model` 查看可用模型列表，并在需要时选择新的模型。
-- 了解了 `/delegate` 作为连接 cloud agent 的可选桥梁。
-
-当然，还有更多斜杠命令可用，也还有更多 Copilot CLI 功能值得探索。最后通过[回顾已学内容][next-lesson]以及后续学习方向，为这段旅程收尾。
-
-## 资源
-
-- [使用 Copilot CLI][using-copilot-cli]
-- [关于 Copilot CLI][about-copilot-cli]
-- [Copilot CLI 中的上下文管理][context-management]
-- [使用 Copilot CLI 共享会话][share-sessions]
-- [在 Copilot CLI 中选择模型][selecting-models]
-
-[previous-lesson]: ../6-custom-agents/
-[next-lesson]: ../8-review/
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[about-cloud-agent]: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent
-[context-management]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#context-management
-[share-sessions]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#share-sessions
-[selecting-models]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#select-an-llm
diff --git a/docs/zh-cn/cli/8-create-pull-request.md b/docs/zh-cn/cli/8-create-pull-request.md
new file mode 100644
index 00000000..c5a8a8c3
--- /dev/null
+++ b/docs/zh-cn/cli/8-create-pull-request.md
@@ -0,0 +1,99 @@
+---
+title: "练习 8 - 创建并合并功能 PR"
+description: "审查完整的筛选里程碑，复用当前 QA 证据，并在 CI 和审查通过后合并第三个拉取请求。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+现在将筛选里程碑汇集到 PR 3 中。保持练习 4–7 使用的分支和检出目录，其中包含筛选实现、quality-checks 技能及脚本、QA 配置文件和相关测试。
+
+这是一个遵循存储库约定、范围明确的普通 PR 请求，不需要贡献技能。
+
+> [!NOTE]
+> 生产团队可能会将功能与可复用质量基础设施分开。本研讨会有意将两者结合，在一个功能 PR 中展示完整工作流。此前的星级评分和指令 PR 应已合并到 `main`，而不是再次作为无关工作出现在差异中。
+
+## 检查准备状态和证据
+
+1. 审查 QA 结论及需求与证据的对应关系。**NO-GO**、缺少浏览器证据或跳过必需检查，都是合并前需要解决的阻塞项。
+2. 确认全部四项检查确实通过 quality-checks 技能运行：lint、单元测试、E2E 和类型检查。
+3. 审查被测修订版本，以及这些检查完成后的更改。只有被测代码、测试和验证脚本保持不变时，才可复用当前 QA 证据。仅创建检查点提交不会使相同文件内容的证据失效，但代码变化会。
+4. 如果实现或被测输入发生变化，重新运行相关技能检查和浏览器观察，并更新证据。当当前 QA 结果仍适用时，不要仅因为要打开 PR 就重新运行整个套件。
+5. 检查完整的分支差异，而不只是最新检查点或未提交的更改。
+
+在同一检出目录的另一个终端中运行：
+
+```bash
+git status
+git fetch origin
+git log --oneline origin/main..HEAD
+git diff --stat origin/main...HEAD
+git --no-pager diff origin/main...HEAD
+```
+
+三点差异显示当前分支自与 `origin/main` 的共同祖先以来的更改，包括早期检查点。确认其中仅包含预期的筛选里程碑。也要检查新文件；暂存前必须审查意外出现的未跟踪或未提交文件。
+
+## 请求创建 PR 3
+
+练习 7 已在创建检查点前让你返回普通 **Interactive** 会话。如果 QA 配置文件不再处于活动状态，且筛选检出目录和分支未变，就在该会话中继续。保留议题 URL、批准的规划澄清内容及当前 QA 报告，包括被测修订版本和检查结果。
+
+QA 配置文件禁止在 QA 期间提交和执行 PR 操作。如果它仍处于活动状态，应先返回普通会话，再请求创建 PR：
+
+1. 等待 QA 空闲，再在其 CLI 提示符处输入 `/exit`。如果另一个会话仍在活动，导致 CLI 未关闭，应先完成或保留该工作，再返回普通提示符并按 Ctrl+D，关闭此 CLI 实例。
+2. 在 shell 提示符处，保持同一筛选检出目录和分支。确认它们的标识，再启动新的普通会话，不使用 `--agent qa` 或恢复会话标志：
+
+ ```bash
+ pwd
+ git branch --show-current
+ git status
+ copilot
+ ```
+
+3. 确认处于 **Interactive** 模式，且 QA 配置文件不再活动。不要创建其他工作树、更改分支或恢复 QA 会话。
+
+将下方所有占位符替换为真实议题 URL、批准的澄清内容和当前 QA 证据。即使仍在练习 7 的普通会话中，也应明确提供这些信息；新对话不得依赖 QA 会话的记忆。
+
+```plaintext
+为此议题准备筛选功能 PR：。以下是我在规划时批准的附加验收标准：<粘贴约定的澄清内容，或填写 none>。以下是当前 QA 证据：<粘贴 QA 报告，包括被测修订版本、浏览器观察、覆盖评估、全部四项检查结果和任何限制>。
+
+确认检出目录和当前筛选分支。检查相对于 main 的完整差异、所有里程碑检查点提交、git status、存储库 PR 模板及所提供的 QA 证据。仅包含已审查的筛选实现、quality-checks 技能及随附脚本、QA 智能体定义和相关测试。
+
+仅在 QA 结果仍描述最终文件内容时复用。如果代码、测试或验证脚本之后发生变化，先报告，并通过技能运行相关检查及受影响的浏览器验证，再将这些结果作为当前证据。不要将失败、受阻或跳过的检查标记为通过。
+
+如有需要，提交剩余已审查的里程碑更改，推送当前分支，并遵循存储库约定创建一个以 main 为目标的 PR。包含议题及批准的标准、实现摘要、新增测试或无需新增的理由、浏览器观察、全部四项检查结果和剩余限制。不要合并、创建其他分支、调用贡献技能或开始其他功能。
+```
+
+## 审查 PR 和 CI
+
+打开返回的 URL，在 **Files changed** 中检查整个 PR。确认其中包含技能脚本和 QA 配置文件，并且没有混入凭据、本地 MCP 配置、无关文件、生成的报告或依赖安装。
+
+使用 PR 的 **Checks** 选项卡，或在功能分支的终端中运行：
+
+```bash
+gh pr view
+gh pr diff
+gh pr checks --watch
+```
+
+检查存储库的 `.github/workflows/`，不要假设绿色标记涵盖所有验证类型。当前 Tailspin 的 **Run tests** 工作流会运行 lint、类型检查、Vitest 单元测试，以及针对构建后静态站点的 Playwright E2E 测试。它不能替代 QA 报告中的直接 MCP 浏览器观察。研讨会站点的 Astro 构建和链接检查验证的是另一个存储库。
+
+如果检查失败，查看日志并解决原因。针对性修复必须在更新后的修订版本上经过审查和重新验证，再推送。如果 `main` 变化且解决冲突改变了功能，也应更新受影响的证据。等待必需的人工审查；智能体自己的批准不能覆盖分支保护。
+
+## 合并并更新本地 main
+
+PR 满足全部审查和检查要求后，在 GitHub 上明确选择 **Merge pull request** 并确认合并。确认 PR 3 为 **Merged**。
+
+使用 `/exit` 退出 CLI 会话。在工作树干净的情况下，更新本地检出内容：
+
+```bash
+git status
+git switch main
+git pull --ff-only
+```
+
+下一练习无需新分支。现在已合并恰好三个研讨会 PR：星级评分；指令及示例改动；筛选功能及质量技能、QA 配置文件和测试。
+
+继续学习[练习 9 - 探索斜杠命令和 CLI 选项][next-lesson]，在明确范围内了解 CLI 控件，而不是开始其他实现任务。
+
+[previous-lesson]: ../7-qa-agent/
+[next-lesson]: ../9-slash-commands/
diff --git a/docs/zh-cn/cli/8-review.md b/docs/zh-cn/cli/8-review.md
deleted file mode 100644
index 5b1db087..00000000
--- a/docs/zh-cn/cli/8-review.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: "练习 8 - 回顾与后续步骤"
-authors:
- - geektrainer
-lastUpdated: 2026-06-30
----
-
-在前几节练习中，已经探索了 GitHub Copilot CLI 的一些最常见用例，包括：
-
-- 与 GitHub 和其他 MCP 服务器交互。
-- 使用说明文件指导代码生成。
-- 实现技能，为 Copilot CLI 工具箱添加工具。
-- 调用自定义智能体处理更高级、更复杂的任务。
-- 使用斜杠命令管理会话，并可选择通过 `/delegate` 衔接回 cloud agent。
-
-下面再谈谈一些斜杠命令、最佳实践和后续步骤。
-
-## 斜杠命令
-
-Copilot CLI 提供了一系列斜杠命令用于交互，其中包括一些可用于配置它或查看幕后情况的命令。前面已经使用过 `/clear` 来开始新聊天并清除当前上下文，也使用过 `/mcp` 来查看和管理 MCP 服务器。以下是一些可能也很有用的命令：
-
-| 命令 | 说明 |
-| ------------------ | ------------------------------------------------------------- |
-| `/add-dir` | 将目录添加到 Copilot 的受信任列表 |
-| `/clear`, `/new` | 清除对话历史并重新开始 |
-| `/compact` | 总结对话历史，以减少上下文窗口占用 |
-| `/context` | 显示上下文窗口 token 使用情况和可视化信息 |
-| `/diff` | 查看当前目录中的变更 |
-| `/model` | 选择要使用的 AI 模型（Claude Sonnet、GPT-5 等） |
-| `/plan ` | 在编码前创建实现计划 |
-| `/review ` | 运行代码审查代理分析变更 |
-| `/delegate` | 将任务委托给 Copilot cloud agent 进行异步处理 |
-| `/session` | 显示会话信息和工作区摘要 |
-| `/share` | 将会话共享为 markdown 文件或 GitHub gist |
-| `/skills` | 管理技能以增强能力 |
-| `/usage` | 显示会话使用指标和统计信息 |
-
-> [!TIP]
-> 使用 `/help` 查看完整的可用命令列表和键盘快捷键。
-
-## 最佳实践
-
-使用任何 AI 工具时，底层基础设施都会影响最终效果。完善的说明文件、自定义智能体和智能体技能都很重要——本工作坊已经逐一体验过。[awesome-copilot][awesome-copilot] 是一个很好的模板来源，而 Copilot 本身也可以为这些内容生成脚手架，作为起点。
-
-和基础设施同样重要的，仍然是上下文。清楚描述想构建*什么*、*为什么*构建、以及*如何*构建，都会显著影响输出结果。凡是有助于 Copilot 的信息，都应该主动提供。
-
-## 后续步骤
-
-提升任何工具使用能力的最好方式，就是持续使用它。把它用在生产代码上、用在个人项目上，或者用在那个想了很多年却一直没开始实现的小应用上。把经验分享给团队，也从团队中学习。并且，一如既往地，多查阅文档。
-
-如果想继续探索 GitHub Copilot 生态系统，可以查看 [VS Code 路径](../../vscode/) 或 [Cloud agent 路径](../../cloud/)。
-
-## 资源
-
-- [关于 Copilot CLI][about-copilot-cli]
-- [使用 Copilot CLI][using-copilot-cli]
-- [Awesome Copilot 存储库][awesome-copilot]
-- [自定义说明指南][repo-instructions]
-- [Agent Skills 文档][agent-skills]
-- [自定义智能体文档][custom-agents]
-- [MCP 规范][mcp-spec]
-
-[previous-lesson]: ../7-slash-commands/
-[about-copilot-cli]: https://docs.github.com/copilot/concepts/agents/about-copilot-cli
-[using-copilot-cli]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli
-[awesome-copilot]: https://github.com/github/awesome-copilot
-[repo-instructions]: https://docs.github.com/copilot/how-tos/configure-custom-instructions/add-repository-instructions
-[agent-skills]: https://docs.github.com/copilot/concepts/agents/about-agent-skills
-[custom-agents]: https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#use-custom-agents
-[mcp-spec]: https://modelcontextprotocol.io/
diff --git a/docs/zh-cn/cli/9-slash-commands.md b/docs/zh-cn/cli/9-slash-commands.md
new file mode 100644
index 00000000..a5109fd4
--- /dev/null
+++ b/docs/zh-cn/cli/9-slash-commands.md
@@ -0,0 +1,88 @@
+---
+title: "练习 9 - 探索斜杠命令和 CLI 选项"
+description: "检查上下文、模型和会话控件，审查共享目标，并探索 CLI 标志，不启动其他功能。"
+authors:
+ - geektrainer
+lastUpdated: 2026-09-11
+---
+
+三个 PR 里程碑已完成。现在探索帮助理解和管理会话的 CLI 控件。本练习不实现其他功能、不委托工作，也不打开其他 PR。
+
+从更新后的练习检出目录中，以 **Interactive** 模式启动 `copilot`。使用 `/help` 和[命令参考][cli-reference]确认已安装版本支持哪些命令；当前文档描述的控件可能比安装版本更新。
+
+## 检查上下文和会话信息
+
+1. 发送范围明确的只读请求：
+
+ ```plaintext
+ 汇总存储库的指令文件、quality-checks 技能和 QA 配置文件。说明它们如何支持筛选验证。不要修改文件、执行检查、委托工作、提交或打开 PR。
+ ```
+
+2. 输入 `/context`，查看上下文窗口用量。注意消息、指令和工具定义如何占用上下文。
+3. 输入 `/compact`，再输入 `/context`。压缩通过总结历史来减少占用；较短会话的变化可能不明显。
+4. 输入 `/session` 检查当前会话，输入 `/usage` 查看使用量信息。
+
+压缩不能替代需求输入。切换任务或智能体时，应明确保留并传递议题 URL、批准的标准、检出目录标识和相关证据。
+
+`/clear` 开始新对话，但不会撤销文件或切换 Git 分支。`/resume` 打开会话选择器，用于返回之前的工作。查看选择器，再按 Esc 离开，不恢复其他任务。不要清除仅存的一份验收标准，也不要假定恢复对话就意味着旧验证仍然有效。
+
+## 检查模型和模式
+
+输入 `/model`，查看账户可用的模型，包括提供时可选的 **Auto**。阅读选择详情和使用量信息；模型可用性和定价可能变化。按 Esc 离开选择器，不更换模型。如果确实更换，应确认显示的选择及当前 CLI 版本中该选择的作用范围。
+
+使用 Shift+Tab 在 **Interactive**、**Plan** 和 **Autopilot** 间循环切换，观察模式指示器；然后返回 **Interactive**，不发送实现提示词。回顾它们的区别：
+
+- Plan 用于编码前约定工作。
+- Autopilot 持续执行已批准、范围明确的任务。
+- Interactive 提供明确的审查和决策节点。
+- 权限单独控制允许哪些工具操作。
+
+## 检查命令行选项
+
+在单独的终端中运行：
+
+```bash
+copilot --help
+```
+
+将以下文档选项与已安装版本的帮助进行比较：
+
+| 选项 | 用途 |
+| --- | --- |
+| `--model MODEL` | 为一次调用选择模型；先确认可用性 |
+| `--agent AGENT` | 为一次调用选择自定义智能体 |
+| `-p PROMPT` | 以编程方式运行提示词，完成后退出 |
+| `--output-format json` | 输出结构化 JSONL，每行一个 JSON 对象 |
+| `--resume` | 恢复现有会话 |
+| `--enable-all-github-mcp-tools` | 提供完整的内置 GitHub MCP 工具集 |
+
+这些是要了解的控件，不是另一个待启动的任务。编程模式可以执行真实工具操作；JSON 输出格式并不会让请求变为只读。智能体选择应遵循[练习 7][qa-lesson]中经过验证的工作流，而不是改为要求默认智能体阅读配置文件来代替真正激活自定义智能体。权限和访问限制仍然适用。
+
+## 共享前先审查
+
+`/share` 可以将会话内容发送到不同目标。[CLI 命令参考][cli-reference]记录了用于 Markdown 导出的 `/share file [session|research] [PATH]`，以及用于发布 gist 的 `/share gist [session|research]`。当前文档说明，不带子命令时，若已登录且已同步，会创建可共享的 GitHub 链接，否则回退为 Markdown 导出。不要假定不带参数的命令只会预览内容而直接运行。
+
+本研讨会明确选择本地会话导出及文件名，而不是发布：
+
+```text
+/share file session cli-session-review.md
+```
+
+在编辑器中打开导出的文件，检查实际内容。审查提示词、回复、工具输出、文件路径、存储库数据，以及任何凭据或个人信息。不要假定导出包含每个内部步骤，或已自动移除敏感内容。
+
+> [!CAUTION]
+> gist 或共享链接会向外部披露内容。秘密 gist 不提供私密访问控制，任何持有 URL 的人都能查看。共享前确认目标、接收者、权限和组织策略。如果需要脱敏，只能通过批准的渠道共享已审查、已脱敏的文件；之后不要再发布原始会话。
+
+不要将此导出放入功能 PR 或存储库历史。检查后，移除刚生成的文件，或将其移到批准的本地笔记位置。不要移除无关文件。
+
+云端委托可能创建远程工作和额外 PR，因此不要在此运行 `/delegate`。[Cloud agent 研讨会][cloud-workshop]介绍了这一独立工作流。
+
+## 总结与后续步骤
+
+你已检查上下文、使用量、模型和模式控件、命令行选项及共享目标，没有启动其他功能。继续学习[练习 10 - 总结与后续步骤][next-lesson]，回顾已构建的工作流和产出。
+
+[previous-lesson]: ../8-create-pull-request/
+[next-lesson]: ../10-review/
+[qa-lesson]: ../7-qa-agent/
+[cloud-workshop]: ../../cloud/
+[cli-reference]: https://docs.github.com/copilot/reference/copilot-cli-reference/cli-command-reference
diff --git a/docs/zh-cn/cli/README.md b/docs/zh-cn/cli/README.md
index 5d6513c4..0ed3109a 100644
--- a/docs/zh-cn/cli/README.md
+++ b/docs/zh-cn/cli/README.md
@@ -3,12 +3,12 @@ slug: zh-cn/cli
title: "GitHub Copilot CLI"
authors:
- geektrainer
-lastUpdated: 2026-06-30
+lastUpdated: 2026-09-11
---
**[GitHub Copilot CLI](https://docs.github.com/copilot/concepts/agents/about-copilot-cli)** 将 GitHub Copilot 作为代理式编码助手带入终端。它可以探索代码库、生成代码、运行命令，并连接外部工具——全部通过命令行完成，无需切换到图形化编辑器即可保持工作流畅。
-在这些练习中，将先安装并验证 Copilot CLI，然后通过自定义说明为它提供项目上下文，再使用计划模式有目的地生成一个功能。接着连接 Playwright MCP 服务器，在真实浏览器中测试该功能；然后通过可复用的智能体技能和自定义智能体扩展 Copilot。最后，将探索用于管理上下文、模型和共享的斜杠命令，并回顾已完成的内容。
+完成练习 0–1 的设置后，你将学习练习 2–10 中的九个核心模块。从添加星级评分快速上手，建立文档指令，再使用 **Plan** 和 **Autopilot** 模式构建筛选功能。随后创建可复用的 quality-checks 技能，使用 Playwright MCP 验证行为，创建 QA 智能体，并交付功能。最后探索 CLI 控件，回顾已构建的内容。
## 练习
@@ -16,13 +16,21 @@ lastUpdated: 2026-06-30
|----------|-------|-------------|
| [0. 先决条件][ex0] | 设置 | 创建存储库和 codespace |
| [1. 安装 Copilot CLI][ex1] | 安装 | 安装并验证 Copilot CLI |
-| [2. 自定义说明][ex2] | 上下文 | 添加一条说明，并观察 Copilot CLI 如何遵循它 |
-| [3. 生成代码][ex3] | 代码生成 | 使用计划模式生成功能 |
-| [4. 使用 Playwright MCP 测试][ex4] | 外部工具 | 添加 Playwright MCP 服务器，并在浏览器中测试功能 |
-| [5. 智能体技能][ex5] | 技能 | 用专门的技能增强 Copilot |
-| [6. 自定义智能体][ex6] | 智能体 | 查看并使用自定义智能体 |
-| [7. 斜杠命令][ex7] | CLI 功能 | 探索上下文、模型、共享，以及可选的委托给 cloud agent |
-| [8. 回顾][ex8] | 总结 | 回顾关键概念和后续步骤 |
+| [2. 添加星级评分：快速上手][ex2] | 首次更改 | 显示现有评分，完成验证，并合并 PR 1 |
+| [3. 使用自定义指令引导 Copilot][ex3] | 上下文 | 添加文档约定，展示其效果，并合并 PR 2 |
+| [4. 使用 Plan 和 Autopilot 构建筛选功能][ex4] | 实现 | 审查计划，批准 Autopilot，测试并保存检查点 |
+| [5. 创建并使用 quality-checks 技能][ex5] | 技能 | 生成、审查并运行随附的 shell 检查脚本 |
+| [6. 使用 Playwright MCP 验证功能][ex6] | 浏览器工具 | 在真实浏览器中观察筛选行为 |
+| [7. 创建并使用 QA 智能体][ex7] | 智能体 | 审查需求和覆盖情况，收集最终证据 |
+| [8. 创建并合并功能 PR][ex8] | 交付 | 在 PR 3 中一并审查筛选功能和可复用自定义配置 |
+| [9. 探索斜杠命令和 CLI 选项][ex9] | CLI 控件 | 检查上下文、模型、会话和共享目标 |
+| [10. 总结与后续步骤][ex10] | 总结 | 回顾共同产出和三个 PR 里程碑 |
+
+## 分支和拉取请求
+
+你将合并三个拉取请求：星级评分；指令及小型示例改动；最后是筛选功能及 quality-checks 技能、QA 配置文件和相关测试。前两个 PR 都必须先完成合并，再从更新后的 `main` 开始下一个里程碑。
+
+练习 4–8 共用一个功能分支和检出目录。过程中使用检查点提交保存进度；创建技能、设置 MCP 和选择 QA 不会开启新的功能分支。练习 9 只探索控件，不启动其他功能或 PR。
## 先决条件
@@ -46,10 +54,12 @@ lastUpdated: 2026-06-30
[ex0]: 0-prerequisites/
[ex1]: 1-install-copilot-cli/
-[ex2]: 2-custom-instructions/
-[ex3]: 3-generating-code/
-[ex4]: 4-mcp/
+[ex2]: 2-add-star-rating/
+[ex3]: 3-custom-instructions/
+[ex4]: 4-build-filtering/
[ex5]: 5-agent-skills/
-[ex6]: 6-custom-agents/
-[ex7]: 7-slash-commands/
-[ex8]: 8-review/
+[ex6]: 6-mcp-playwright/
+[ex7]: 7-qa-agent/
+[ex8]: 8-create-pull-request/
+[ex9]: 9-slash-commands/
+[ex10]: 10-review/
diff --git a/website/astro.config.mjs b/website/astro.config.mjs
index 2abc22db..e53afc2e 100644
--- a/website/astro.config.mjs
+++ b/website/astro.config.mjs
@@ -71,13 +71,15 @@ export default defineConfig({
{ label: 'Overview', link: '/cli/' },
{ label: '0. Prerequisites', link: '/cli/0-prerequisites/' },
{ label: '1. Install Copilot CLI', link: '/cli/1-install-copilot-cli/' },
- { label: '2. Custom instructions', link: '/cli/2-custom-instructions/' },
- { label: '3. Generating code', link: '/cli/3-generating-code/' },
- { label: '4. Testing with Playwright MCP', link: '/cli/4-mcp/' },
- { label: '5. Agent skills', link: '/cli/5-agent-skills/' },
- { label: '6. Custom agents', link: '/cli/6-custom-agents/' },
- { label: '7. Slash commands', link: '/cli/7-slash-commands/' },
- { label: '8. Review', link: '/cli/8-review/' },
+ { label: '2. Add star ratings', link: '/cli/2-add-star-rating/' },
+ { label: '3. Custom instructions', link: '/cli/3-custom-instructions/' },
+ { label: '4. Build filtering with Plan and Autopilot', link: '/cli/4-build-filtering/' },
+ { label: '5. Create and use a quality-checks skill', link: '/cli/5-agent-skills/' },
+ { label: '6. Validate with Playwright MCP', link: '/cli/6-mcp-playwright/' },
+ { label: '7. Create and use a QA agent', link: '/cli/7-qa-agent/' },
+ { label: '8. Create and merge the feature PR', link: '/cli/8-create-pull-request/' },
+ { label: '9. Slash commands and CLI options', link: '/cli/9-slash-commands/' },
+ { label: '10. Wrap-up and next steps', link: '/cli/10-review/' },
],
},
{
@@ -86,13 +88,15 @@ export default defineConfig({
{ label: 'Overview', link: '/app/' },
{ label: '0. Prerequisites', link: '/app/0-prerequisites/' },
{ label: '1. Install the Copilot app', link: '/app/1-install-copilot-app/' },
- { label: '2. Running your first agent session', link: '/app/2-add-star-rating/' },
+ { label: '2. Add star ratings', link: '/app/2-add-star-rating/' },
{ label: '3. Guiding Copilot with custom instructions', link: '/app/3-custom-instructions/' },
- { label: '4. Building a feature with Autopilot', link: '/app/4-build-filtering/' },
- { label: '5. Testing with Playwright MCP', link: '/app/5-mcp-playwright/' },
- { label: '6. Merging with Agent Merge', link: '/app/6-agent-merge/' },
- { label: '7. Planning with canvases', link: '/app/7-canvases/' },
- { label: '8. Review', link: '/app/8-review/' },
+ { label: '4. Build filtering with Plan and Autopilot', link: '/app/4-build-filtering/' },
+ { label: '5. Create and use a quality-checks skill', link: '/app/5-agent-skills/' },
+ { label: '6. Validate with Playwright MCP', link: '/app/6-mcp-playwright/' },
+ { label: '7. Create and use a QA agent', link: '/app/7-qa-agent/' },
+ { label: '8. Create and merge the feature PR', link: '/app/8-create-pull-request/' },
+ { label: '9. Create a canvas', link: '/app/9-canvases/' },
+ { label: '10. Wrap-up and next steps', link: '/app/10-review/' },
],
},
{