Workshop Section: 1 — Welcome, Objectives & Environment Setup

Steps

Step 1: Fork & Clone

# Fork the repo via GitHub UI, then:
git clone https://github.com/<YOUR-USERNAME>/GitHubCopilot_Customized.git
cd GitHubCopilot_Customized

Step 2: Install & Build

npm install
npm run build

Step 3: Start the Application

npm run dev

Step 4: Verify

• API running at http://localhost:3000 — open in browser, check Swagger docs
• Frontend running at http://localhost:5137 — open in browser, click "Products"
• VS Code: Open Command Palette → type "Copilot" → verify extension is active

Note: If using Codespaces, ensure API port (3000) visibility is set to public to avoid CORS errors.

Success Criteria

• ✅ Repository is forked and cloned locally
• ✅ npm install and npm run build completed without errors
• ✅ API is running on http://localhost:3000
• ✅ Frontend is running on http://localhost:5137
• ✅ Copilot extension is active in VS Code

Workshop Section: 2 — Copilot Chat Modes: Ask, Agent, Plan

Mode Reference

Steps

Exercise 1 — Ask Mode:

1. Open Copilot Chat → select Ask mode from the dropdown
2. Enter the following prompt:

What testing framework does this project use and what's the current test coverage?

3. Note the answer — you'll use this information in Lab 4 when generating tests

Exercise 2 — Plan Mode:

1. Switch to Plan mode from the mode dropdown
2. Enter the following prompt:

How should I add comprehensive error handling to the API routes?

3. Review the plan Copilot proposes — notice it lists which files need to change, what approach to take, and step-by-step instructions
4. Importantly, Plan mode does NOT create or modify any files — it only proposes

Exercise 3 — Agent Mode:

1. Switch to Agent mode
2. If your app isn't already running, enter:

Build and run the project

3. Then enter:

Open the Swagger documentation page for the API

Success Criteria

• ✅ You can switch between Ask, Agent, and Plan modes
• ✅ You've received a codebase-aware answer from Ask mode
• ✅ You've seen Plan mode propose changes without modifying files
• ✅ Agent mode has created or edited files and run terminal commands
• ✅ Your app is running (API on :3000, Frontend on :5137)

Workshop Section: 3 — Custom Instructions

Why This Matters

Custom instructions are the simplest and highest-impact way to personalize Copilot. They're loaded into every Copilot interaction automatically — think of them as "tribal knowledge" that Copilot always has access to. Without them, Copilot uses generic best practices. With them, it follows YOUR team's standards.

Reference: Customization Hierarchy

What Makes Good Instructions?

Note: Keep instructions concise. They're loaded on every interaction and consume context window space. Think bullet points, not paragraphs.

Steps

Step 1: Establish a Baseline (Before Instructions)

1. Open Copilot Chat in Ask mode
2. Ask the following question and note the response:

How should I add a new API endpoint to this project?

3. Pay attention to: Does Copilot mention Swagger? Does it reference existing patterns? Does it know about the project's entity model structure?

Step 2: Generate Project-Wide Instructions

1. Open Copilot Chat → click the Gear icon (⚙️) in the chat window
2. Select "Generate Agent Instructions"
3. Watch Copilot analyze the entire repo — it will scan the architecture, dependencies, build config, and conventions
4. Review the generated content. It should reference:
   • The project name and tech stack (TypeScript, React, Express)
   • Build commands (npm install && npm run build)
   • Testing framework (vitest)
   • Project structure and architecture patterns
5. Save the file to .github/copilot-instructions.md
6. Open the saved file and read through it — this is Copilot's understanding of your project

Step 3: Create Scoped API Instructions

Scoped instructions activate only when you're editing files that match a glob pattern. This lets you give Copilot different guidance for different parts of the codebase.

1. Create the directory: .github/instructions/
2. Create the file .github/instructions/API.instructions.md with the following content:

---
applyTo: "api/**"
---
# API Development Instructions

For REST APIs in this project:
- Use descriptive endpoint naming following REST conventions
- Add Swagger/OpenAPI docs for all API methods
- Implement proper error handling with appropriate HTTP status codes
- Follow the entity pattern established in existing routes
- Include input validation for all POST/PUT endpoints

Note: The applyTo field uses glob patterns. api/** means these instructions load whenever you have any file under the api/ folder open.

Step 3b: Test Scoped Instructions

1. Open a file in api/src/routes/ (e.g., product.ts)
2. In Copilot Chat (Ask mode), enter:

How should I add a new API endpoint to this project?

3. Notice how the response references Swagger docs, REST conventions, error handling patterns, and the entity model structure — these come from the scoped instructions you just created

Step 4: Test the Difference (After Instructions)

1. Open a file in api/src/routes/ (e.g., product.ts)
2. In Copilot Chat (Ask mode), ask the same question from Step 1:

How should I add a new API endpoint to this project?

3. Compare the response to your baseline. You should notice:
   • More specific references to the project's patterns
   • Mentions of Swagger documentation
   • References to error handling conventions
   • Awareness of the entity model structure

Step 5: Create a Frontend Scoped Instruction (Bonus)

1. Create .github/instructions/Frontend.instructions.md:

---
applyTo: "src/**"
---
# Frontend Development Instructions

For React components in this project:
- Use functional components with TypeScript
- Use Tailwind CSS for all styling — no inline styles or CSS modules
- Follow the existing component structure in src/components/
- Use React hooks for state management
- All components should be exported as default exports

2. Open a file in src/ and ask Copilot about building a new component — observe the Tailwind and TypeScript guidance in the response

Success Criteria

• ✅ .github/copilot-instructions.md exists in your repo
• ✅ .github/instructions/API.instructions.md exists with applyTo: "api/**"
• ✅ You've compared Copilot's responses before and after adding instructions and noticed the difference
• ✅ You understand that instructions are always-on background context

Workshop Section: 4 — Custom Prompt Files

Why This Matters

Prompt files are reusable task templates that encode complex workflows into a single file. Instead of explaining the same task to Copilot every time, you write it once and anyone on the team can run it. Think of them as "recipes" — a junior developer can run a senior developer's testing prompt and get senior-quality output.

Reference: Prompt File Structure

---
mode: 'agent'                    # Which mode to use (ask, agent, plan)
description: 'Description here'  # Shows in the prompt picker
tools: ['changes', 'codebase',   # Which tools the agent can use
  'editFiles', 'runCommands',
  'search', 'terminalLastCommand']
---

# Prompt content goes here (Markdown)

How to Run a Prompt

There are three ways to run a prompt file:

1. Run button: Open the .prompt.md file → click the ▶️ Run button at the top
2. Command Palette: Ctrl+Shift+P → type "Prompts: Run Prompt" → select from the list
3. Chat shortcut: Type / in Copilot Chat and select the prompt name

Steps

Exercise 1 — Explore the Existing Prompts

Before creating your own, look at what's already in the repo:

1. Open .github/prompts/ in the file explorer
2. Open Unit-Test-Coverage.prompt.md and read through it:
   • Notice the YAML frontmatter — mode: 'agent' with a comprehensive tool list
   • Notice how it describes the current state ("only 1 test file exists")
   • Notice the detailed requirements — which entities to test, which patterns to follow
   • Notice the success criteria with checkboxes
3. Open plan.prompt.md and compare:
   • This one explicitly says "DO NOT SHOW CODE CHANGES — only the overview"
   • It forces Copilot to think before coding
   • It saves the plan as a Markdown file
4. Key takeaway: Prompts can control not just what Copilot does, but how it thinks

Exercise 2 — Run an Existing Prompt

1. Open .github/prompts/Unit-Test-Coverage.prompt.md
2. Click the ▶️ Run button at the top of the file
3. Watch Agent mode activate and observe Copilot:
   • Reading existing test files to understand patterns
   • Generating new test files for entities without tests
   • Running the tests to verify they pass
   • If tests fail, watch the self-healing: Copilot reads the errors and fixes them
4. Let it run for a couple minutes — you can stop it early if needed

Exercise 3 — Create Your Own Prompt: Security Review

1. Create a new file: .github/prompts/security-review.prompt.md
2. Add the following content:

---
mode: 'agent'
description: 'Analyze the codebase for security vulnerabilities and suggest fixes'
tools: ['codebase', 'search', 'editFiles', 'changes']
---

# Security Review Prompt

## Objective
Analyze the current codebase for common security vulnerabilities.

## Check For
- Cross-site Scripting (XSS) vulnerabilities
- Command Injection risks
- Insecure CORS configuration
- Missing security headers
- Hardcoded credentials or secrets
- SQL/NoSQL injection vectors
- Insecure authentication implementation

## Output Format
For each vulnerability found:
1. **Location**: File and line number
2. **Severity**: Critical / High / Medium / Low
3. **Description**: What the vulnerability is
4. **Fix**: Suggested remediation with code changes

## Constraints
- Follow the project's coding standards from copilot-instructions.md
- Do not modify test files
- Create a summary report at the end

3. Run the prompt using any of the three methods above
4. Review the findings — Copilot will scan the codebase and report vulnerabilities

Exercise 4 — Design Your Own Prompt (Bonus)

Think about a repetitive task in your own work. Create a prompt for it. Ideas:

• code-review.prompt.md — reviews the current changes for best practices
• api-documentation.prompt.md — generates Swagger docs for undocumented endpoints
• refactor-suggestions.prompt.md — identifies code that could be simplified

Key tips for writing good prompts:

• Be specific about what "done" looks like (success criteria)
• Tell Copilot what NOT to do (constraints)
• Reference existing files as patterns to follow
• Choose the right mode — use agent for tasks that need to create/edit files, ask for analysis-only

Success Criteria

• ✅ You've explored the existing prompt files and understand their structure
• ✅ You've run a prompt and watched Copilot execute a multi-step task
• ✅ You've created security-review.prompt.md and run it successfully
• ✅ You understand the three ways to invoke a prompt file

Workshop Section: 5 — Agent Skills

Why This Matters

Agent Skills are the smartest customization layer — Copilot automatically loads them when it determines they're relevant to your prompt. You don't invoke them; Copilot chooses them. This makes skills ideal for detailed, specialized procedures that would be too verbose for always-on instructions.

Skills are also an open standard used by Copilot Coding Agent, GitHub Copilot CLI, and Agent mode in VS Code.

Reference: Skills vs Instructions vs Prompts

Rule of thumb: Instructions = "always true" rules. Skills = "when doing X, follow these detailed steps." Prompts = "do this specific task now."

Skill File Structure

.github/skills/
└── api-route-creation/
    ├── SKILL.md              # Required — instructions + frontmatter
    ├── route-template.ts     # Optional — example files Copilot can reference
    └── test-template.ts      # Optional — additional resources

Steps

Exercise 1 — Create an API Route Creation Skill

1. Create the directory structure:

mkdir -p .github/skills/api-route-creation

2. Create .github/skills/api-route-creation/SKILL.md with the following content:

---
name: api-route-creation
description: Guide for creating new API routes in the Express.js backend.
  Use this when asked to add new endpoints, entities, or REST resources.
---

Follow this process when creating new API routes:

1. **Create the entity model** in `api/src/models/`
   - Follow the TypeScript interface pattern from existing models
   - Include all required and optional fields with proper types

2. **Create the route file** in `api/src/routes/`
   - Follow the pattern from `api/src/routes/product.ts`
   - Implement full CRUD: GET (list), GET (by ID), POST, PUT, DELETE
   - Add proper error handling with try/catch and appropriate HTTP status codes

3. **Register the route** in `api/src/index.ts`
   - Import the new route module
   - Add it to the Express app with the correct base path

4. **Add Swagger documentation**
   - Add JSDoc annotations with @swagger tags on each endpoint
   - Include request/response schemas, parameters, and example values

5. **Create tests** in `api/src/routes/<entity>.test.ts`
   - Follow the pattern from existing test files
   - Test all CRUD operations and error scenarios
   - Use vitest as the test framework

Exercise 2 — Test the Skill Auto-Selection

The key difference between skills and prompts is that you don't invoke skills manually — Copilot selects them based on your prompt matching the skill's description field.

1. Switch to Agent mode in Copilot Chat
2. Enter a prompt that should trigger the skill:

I need to add a new "Warehouse" entity and API endpoints for managing warehouses. Each warehouse has a name, address, city, state, zipCode, and capacity.

3. Watch Copilot work — it should follow the steps from your skill: create the model, create the route, register it, add Swagger docs
4. Check whether the generated code follows the patterns you specified

Exercise 3 — Create a Second Skill (Bonus)

Create a react-component-creation skill:

mkdir -p .github/skills/react-component-creation

Create .github/skills/react-component-creation/SKILL.md:

---
name: react-component-creation
description: Guide for creating new React components in the frontend.
  Use this when asked to add new pages, UI components, or frontend features.
---

Follow this process when creating new React components:

1. **Create the component file** in `src/components/` or `src/pages/`
   - Use functional components with TypeScript (.tsx)
   - Use Tailwind CSS for all styling — no inline styles or CSS modules
   - Export the component as the default export

2. **Add routing** (if it's a page)
   - Add the route to the router configuration
   - Add a navigation link if appropriate

3. **Connect to the API** (if needed)
   - Use fetch or the existing API utility for data fetching
   - Handle loading, error, and empty states
   - Add TypeScript interfaces for API response types

4. **Follow existing patterns**
   - Reference `src/pages/Products.tsx` for page structure
   - Reference `src/components/` for reusable component patterns

Test it by asking Copilot: Create a Warehouses page that shows a list of all warehouses with their addresses

Where to Find More Skills

• anthropics/skills — Anthropic's reference skills
• github/awesome-copilot — community-curated collection

Personal Skills

You can also create personal skills that apply across all your repos:

• Location: ~/.copilot/skills/*/SKILL.md (where ~ is your OS home directory — e.g., C:\Users\<username> on Windows, /Users/<username> on macOS)
• These are private to your machine — not shared via git
• Great for personal coding preferences or tools only you use

Success Criteria

• ✅ You've created .github/skills/api-route-creation/SKILL.md with a complete step-by-step guide
• ✅ You've tested the skill by asking Copilot to create a new entity and observed it following your steps
• ✅ You understand the difference: instructions = always-on, skills = auto-selected, prompts = manually invoked

Workshop Section: 6 — Custom Agents (Chat Modes)

Why This Matters

Custom agents are persistent personas that stay active for an entire chat session. While a prompt file runs once and gives you a result, an agent changes how Copilot behaves for every message you send. Think of agents as hiring a specialist — once selected, every interaction is filtered through that specialist's expertise and toolset.

In this lab you'll work with three agents that show a clear progression:

Reference: Agents vs Prompts

Agent Frontmatter Reference

---
tools: ['codebase', 'search']     # Which tools the agent can use
description: 'What this agent does' # Shows in the mode picker dropdown
model: Claude Sonnet 4              # Optional — specify the AI model
---

Available tools include: codebase, search, editFiles, runCommands, usages, problems, changes, fetch, githubRepo, todos, github/* (all GitHub MCP tools), playwright/* (all Playwright tools)

Steps

Exercise 1 — Create and Use the OctoCATEngineer Agent

The simplest kind of agent — a persona with local tools. No MCP, no custom model, just a specialized pair programmer.

1. Create the agent file:

   • In your repo, create a new file at .github/agents/OctoCATEngineer.agent.md with the following content:

   ---
   tools: ['search/codebase', 'azure-mcp/search', 'edit/editFiles', 'execute/getTerminalOutput', 'execute/runInTerminal', 'read/terminalLastCommand', 'read/terminalSelection', 'read/problems']
   description: Full-stack engineer for the OctoCAT Supply app
   ---
   
   You are a senior full-stack TypeScript engineer working on the OctoCAT Supply application — a supply chain management web app with a React 18+ frontend (Vite, Tailwind CSS) and an Express.js API backend (TypeScript, OpenAPI/Swagger).
   
   ## Your Approach
   
   - Read existing code patterns before making changes — follow the conventions already established in the project
   - Use TypeScript with strict typing for all new code
   - Follow REST conventions for API endpoints
   - Add Swagger/OpenAPI documentation annotations for any new or modified API routes
   - Use Tailwind CSS for all frontend styling — no inline styles or CSS modules
   - Use functional React components with hooks
   
   ## Backend Conventions
   
   - Entity models go in `api/src/models/`
   - Route handlers go in `api/src/routes/`
   - Follow the pattern established in `api/src/routes/product.ts` for new routes
   - Register new routes in `api/src/index.ts`
   - Use proper error handling with try/catch and appropriate HTTP status codes
   - Include input validation for all POST/PUT endpoints
   
   ## Frontend Conventions
   
   - Pages go in `src/pages/`
   - Reusable components go in `src/components/`
   - Follow the component structure in existing pages like `src/pages/Products.tsx`
   - Use React Router for navigation
   - Handle loading, error, and empty states in all data-fetching components
   
   ## Testing
   
   - Use vitest as the test framework
   - Follow patterns from existing test files
   - Run tests after making changes to verify nothing is broken
   
   ## Workflow
   
   1. Understand the task by reading relevant existing code
   2. Plan the changes needed
   3. Implement the changes across all affected files
   4. Build and verify the changes compile successfully
   5. Run tests if applicable
   

2. Read through the file and notice:

   • The tools list: search/codebase, azure-mcp/search, edit/editFiles, execute/getTerminalOutput, execute/runInTerminal, read/terminalLastCommand, read/terminalSelection, read/problems — all local tools
   • No model field — it uses the default model
   • The persona: a full-stack TypeScript engineer for OctoCAT Supply

3. Open the Copilot Chat mode picker (dropdown at the top) and select OctoCATEngineer

4. Give it a task:

Add a GET /api/products/search endpoint that accepts a "name" query parameter and returns matching products

5. Watch the agent work — it reads the codebase, edits files, and runs commands, all while staying in character as a full-stack engineer

Exercise 2 — Build a Code Reviewer Agent

Now create an agent with a different tool set — read-only tools that prevent it from editing files.

1. Create .github/agents/CodeReviewer.agent.md with the following content:

---
tools: ['codebase', 'search', 'usages', 'problems']
description: Review code for security, performance, and best practices
model: Claude Sonnet 4
---

You are an expert code reviewer specializing in TypeScript and React applications.

When reviewing code:

1. **Security**: Check for XSS, injection, insecure data handling
2. **Performance**: Identify N+1 queries, unnecessary re-renders, memory leaks
3. **Best Practices**: Verify error handling, input validation, type safety
4. **Maintainability**: Check naming, code organization, DRY violations

Always provide:
- Severity level (Critical / Warning / Suggestion)
- Specific file and line references
- Concrete fix recommendations with code examples

Be direct and opinionated. Don't say "consider" — say "change this to..."

2. Check the mode picker — "CodeReviewer" should appear immediately (no reload needed)
3. Notice the contrast with OctoCATEngineer:
   • No editFiles or runCommands — this agent can't change your code
   • It has usages — it can trace how functions are called across the codebase
   • Same file format, completely different behavior — the tool list controls what an agent can do

Exercise 3 — Test Your Code Reviewer

1. Select CodeReviewer from the mode picker
2. Ask it to review a specific file:

Review the product route handler for security and performance issues

3. Notice how the agent stays in character — every response follows the review format you defined
4. Ask a follow-up question:

Now review the error handling across all API routes

5. The agent maintains its persona across the entire conversation

Exercise 4 — Run the ImplementationIdeas Agent (Bonus — Agents Calling Agents)

This is the most advanced agent pattern — an agent that researches, plans, and then delegates implementation to the Coding Agent in the cloud.

1. Open .github/agents/ImplementationIdeas.agent.md
2. Read through the file and notice what makes this different from OctoCATEngineer:
   • Tools: search, github/* (wildcard = all GitHub MCP tools), playwright/*, githubRepo, todos
   • Model: Claude Sonnet 4.5 — the agent chooses its own model
   • Key line: call GitHub's create_pull_request_with_copilot — this agent delegates to the Coding Agent (cloud)
3. Select ImplementationIdeas from the Copilot Chat mode picker
4. Give it a task:

Explore adding a wishlist feature where users can save products for later

5. Watch the agent work — it should:
   • Research the codebase using parallel tool calls
   • Create a todo list with feature variations
   • Delegate implementation to Coding Agent (which creates a branch and opens a PR)
6. Think about the progression across all three agents:
   • OctoCATEngineer: local tools, default model → simple worker
   • CodeReviewer: read-only tools, specified model → safe reviewer
   • ImplementationIdeas: MCP tools, custom model, delegation → advanced strategist

Note: When you run this, you may see a tip from Coding Agent: "You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring MCP servers." Coding Agent configuration (environment setup, branch protection, assigning issues) is covered in the workshop's Section 9 demo.

Note: This exercise requires the GitHub MCP server to be configured (Lab 7) and Coding Agent to be enabled in the repository settings. If either is not available, read through the agent file to understand the pattern — you'll see it demonstrated live.

Exercise 5 — Create Your Own Agent (Bonus)

Choose a persona that would be useful for this project and create it:

Option A: APIDesigner.agent.md

---
tools: ['codebase', 'search', 'editFiles', 'runCommands']
description: Design and implement REST API endpoints following project patterns
model: Claude Sonnet 4
---

You are an API architect specializing in Express.js and TypeScript.
[Add behavior instructions: how to design endpoints, which patterns to follow,
how to handle validation, what Swagger docs to generate...]

Option B: TestEngineer.agent.md

---
tools: ['codebase', 'search', 'editFiles', 'runCommands', 'problems', 'findTestFiles']
description: Design and write comprehensive test suites
model: Claude Sonnet 4
---

You are a test engineering expert focused on TypeScript applications using vitest.
[Add behavior instructions: what to test, coverage targets, testing patterns,
how to handle mocking, edge cases to consider...]

Option C: DocWriter.agent.md

---
tools: ['codebase', 'search', 'editFiles']
description: Generate and maintain project documentation from code
model: Claude Sonnet 4
---

You are a technical writer who creates clear, concise documentation.
[Add behavior instructions: documentation style, what to document,
README structure, API doc format, code comment standards...]

Fill in the behavior instructions with your own rules, then test the agent with a real task.

Success Criteria

• ✅ You've used the OctoCATEngineer agent and seen it work with local tools
• ✅ You've created the CodeReviewer agent with read-only tools and tested it
• ✅ You've explored the ImplementationIdeas agent and understand the advanced patterns (MCP tools, custom model, delegation)
• ✅ You understand the progression: simple worker → read-only reviewer → advanced delegator
• ✅ You understand that agents persist for the entire chat session, unlike prompts

Workshop Section: 7 — MCP Servers (Playwright + GitHub)

Why This Matters

MCP (Model Context Protocol) extends Copilot beyond code — connecting it to browsers, APIs, databases, and external tools. Without MCP, Copilot can only read and write files. With MCP, it can browse your running app, interact with GitHub's API, query databases, and more. The two MCP servers in this project are:

• Playwright — drives a real browser so Copilot can see and interact with your app
• GitHub — gives Copilot access to issues, PRs, and repo data via GitHub's API

Prerequisites

• Your app must be running locally (npm run dev)
• Playwright MCP does NOT work in Codespaces (it needs a local browser)

Reference: MCP Configuration

The repo's .vscode/mcp.json configures both servers:

Steps

Exercise 1 — Verify MCP Server Configuration

MCP servers auto-start when Copilot needs them — you don't need to manually launch them.

1. Open .vscode/mcp.json in the editor and confirm both github and playwright servers are defined.

2. Verify the VS Code setting is enabled: Open Settings (Ctrl+,) → search for chat.mcp.discovery.enabled → ensure it's checked (true). This allows Copilot to discover and auto-start MCP servers defined in .vscode/mcp.json.

3. For the GitHub server: The first time Copilot calls a GitHub MCP tool, you'll see an OAuth authentication flow. Follow the prompts to authorize Copilot to access your GitHub account.

4. To check server status at any time: Command Palette (Ctrl+Shift+P) → MCP: List servers — shows status for each server.

Important: When Copilot calls an MCP tool for the first time, VS Code displays a tool approval dialog — an "Allow" button with a dropdown arrow. Clicking "Allow" approves only that single call, which gets tedious during exercises. Click the dropdown arrow (▼) next to "Allow" to see broader approval options:

Option	Scope	Effect
Allow	One-time	Approves this single tool call only
Skip	One-time	Skips this tool call without approving
Allow Without Review in this Session	All tools, current session	Auto-approves all MCP tool calls until VS Code restarts
Allow Without Review in this Workspace	All tools, this workspace	Auto-approves all MCP tool calls in this project permanently
Always Allow Without Review	All tools, global	Auto-approves all MCP tool calls everywhere, permanently
Allow Tools from [Server] Without Review in this Session	Per-server, current session	Auto-approves only tools from that specific MCP server for this session
Allow Tools from [Server] Without Review in this Workspace	Per-server, this workspace	Auto-approves only tools from that specific MCP server in this project permanently
Always Allow Tools from [Server] Without Review	Per-server, global	Always auto-approves tools from that specific MCP server everywhere

For this workshop: Select "Allow Tools from Playwright Without Review in this Session" the first time you see this dialog, so you can focus on the exercises without repeated prompts. Do the same for the GitHub server when you reach Exercise 5.

Exercise 2 — Browse Your App with Playwright

1. Switch to Agent mode in Copilot Chat
2. Ask Copilot to explore your running application:

Browse to http://localhost:5137 and describe what you see on the home page

3. Watch Copilot:
   • Launch a browser window (you'll see it open)
   • Navigate to the URL
   • Take a screenshot and analyze the page
   • Describe the UI elements it finds
4. Now ask it to interact with the app:

Navigate to the Products page and click on the first product. Describe the product details you see.

5. Copilot will click through the UI, read the content, and report back

Exercise 3 — Functional Testing with Natural Language

1. Ask Copilot to verify specific functionality:

Browse to http://localhost:5137, go to Products, and verify that:
1. All products have images displayed
2. All products show a price
3. The "Add to Cart" button is visible on each product
Report any issues you find.

2. Review the results — Copilot will check each condition and report pass/fail
3. Try a more specific test:

Go to the Products page, click "Add to Cart" on any product, and tell me what happens

Exercise 4 — Run BDD-Style Test Scenarios

1. Start a new chat — click the + button in Copilot Chat to start with a clean context
2. Ask Copilot to execute BDD-style test scenarios against the live app:

Run these BDD test scenarios against http://localhost:5137 using Playwright:
1. Given I navigate to the Products page, Then I should see a list of products with names, images, and prices
2. When I click on a product, Then I should see the product details
3. When I click "Add to Cart" on a product, Then I should see a confirmation
Report pass/fail for each scenario.

3. Review Copilot's test execution results — it should:

   • Navigate to the Products page and verify product cards are displayed
   • Click a product and confirm details appear
   • Click "Add to Cart" and confirm the response
   • Report pass/fail for each scenario

4. Save the chat as a reusable prompt file:

   • Click the Gear icon (⚙️) at the top of the Copilot Chat panel
   • Select "Save Prompt"
   • Name it bdd-playwright-tests — VS Code saves it to .github/prompts/bdd-playwright-tests.prompt.md
   • Open the saved file and review the YAML frontmatter — it should include mode: 'agent' and tools: ['playwright/*']
   • Now anyone on the team can run the same BDD scenarios with one click via the prompt picker (/ in chat)

💡 Tip: Starting a new chat before saving ensures the prompt captures only the BDD scenario — no leftover context from previous conversations. This is a best practice for creating clean, reusable prompt files.

Exercise 5 — GitHub MCP: Manage Issues from Chat

1. In Agent mode, ask Copilot:

Check which issues are currently open in this repo

2. Copilot will fetch issues via the GitHub API — no terminal needed
3. Create an issue directly from chat:

Create a GitHub Issue titled "Add product search functionality" with a description that includes acceptance criteria for searching products by name and category

4. Verify the issue was created by checking in your browser or asking: Show me the issue you just created

Exercise 6 — Combine Both MCP Servers (Bonus)

This is where things get powerful — use Playwright to find a bug, then use GitHub to file an issue:

Browse to http://localhost:5137 and test all the navigation links. If any pages are missing or broken, create a GitHub Issue for each problem you find.

Success Criteria

• ✅ Both MCP servers are configured in .vscode/mcp.json and auto-start when needed
• ✅ You've seen Playwright navigate your app and describe what it sees
• ✅ You've run a natural-language functional test against your running app
• ✅ You've used GitHub MCP to create or list issues from Copilot Chat
• ✅ You understand that MCP connects Copilot to the real world beyond just code files

Workshop Section: 8. GitHub Copilot CLI: The Agentic Terminal

Why This Matters

The standalone copilot CLI is a full agentic terminal — an interactive TUI where AI can read your files, build multi-step plans, execute changes with your approval, review code, and even delegate tasks to Coding Agent in the cloud. It's the same agentic experience as VS Code, but entirely in your terminal.

Quick Reference

Steps

Exercise 1 — Launch the CLI & Explore:

1. Open a standalone terminal — not the VS Code integrated terminal — to experience the CLI as an independent tool:
   • Windows: Open Windows Terminal (Win+X → Terminal) or PowerShell
   • macOS: Open Terminal.app (Cmd+Space → "Terminal") or iTerm2
2. Navigate to the project directory:

cd path/to/GitHubCopilot_Customized

3. Launch the GitHub Copilot CLI:

copilot

3. Ask about your project:

What does this project do? Summarize the architecture.

4. Watch the tool calls appear — the agent reads your files and provides a summary
5. Notice the tool approval prompt: (Y)es / (N)o / Yes for this (S)ession / Yes (A)lways

Note: The tool approval system lets you control every action the agent takes. Start with approving one at a time to see what's happening, then use "Yes for session" once you're comfortable.

Exercise 2 — File Context with @:

1. Reference a specific file in your prompt using @:

@src/api/routes.ts What endpoints does this file define? Are there any missing error handlers?

2. The agent reads the file and answers with specific line references
3. Try referencing multiple files:

@package.json @tsconfig.json What version of TypeScript is this project using and what are the compiler options?

Exercise 3 — Plan Mode & Build a Feature:

1. Press Shift+Tab to enable plan mode
2. Type a feature request:

Add a health check endpoint at GET /api/health that returns { status: "ok", timestamp: new Date().toISOString(), uptime: process.uptime() }

3. Review the plan — the agent shows numbered steps it will take
4. Press Enter to execute the plan
5. Approve each tool call as it appears:
   • read_file — the agent reads existing route files
   • edit_file — the agent writes the new endpoint (review the diff!)
   • run_command — the agent may run tests or linting
6. When complete, check what changed:

!git diff

Exercise 4 — Review Your Changes:

1. After building the feature, ask for a code review:

/review

2. Read the AI's feedback — it may suggest improvements, catch edge cases, or confirm the code looks good
3. If the review suggests changes, ask the agent to fix them:

Apply the suggestions from the review

Exercise 5 — Shell Commands & Session Info:

1. Run shell commands without leaving the session:

!git status

!npm test

2. Check your session context and token usage:

/context

/usage

Exercise 6 — Delegate to Coding Agent (Bonus):

1. If Coding Agent is enabled in your repo, try handing off a task:

/delegate Create an issue to add request logging middleware to all API routes, then implement it

2. The CLI confirms the handoff — Coding Agent will create a branch, write the code, and open a PR
3. Check GitHub in your browser to see the Coding Agent session

Note: /delegate requires Coding Agent to be enabled in the repository settings and the gh CLI installed and authenticated (gh auth login). If either is not available, skip this exercise — you'll see it demonstrated in Section 9.

Stretch Goals

If you finish early, try these:

• Resume a session: Exit the CLI (Ctrl+C or type exit), then resume:

  copilot --resume
  

• Allow all tools: Start a session with full autonomy:

  copilot --allow-all-tools
  

• Ask the agent to refactor: Pick a file and ask for improvements:

  @src/api/routes.ts Refactor this file to separate route definitions from handler logic
  

Success Criteria

• ✅ You've launched the copilot CLI and explored the interactive TUI
• ✅ You've used @filename to attach file context to a prompt
• ✅ You've used Shift+Tab to toggle plan mode and reviewed a plan
• ✅ You've built a feature and approved tool calls (read_file, edit_file)
• ✅ You've used /review to get an AI code review in the terminal
• ✅ You've run shell commands inline with ! (e.g., !git diff)
• ✅ You've checked /context and /usage for session info