Skip to content

README.md

Latest commit

 

History

History
167 lines (129 loc) · 8.18 KB

README.md

File metadata and controls

167 lines (129 loc) · 8.18 KB
Raw

GitHub Copilot SDK Workshops

Start today: http://github.github.com/copilot-sdk-workshop/

Choose one of two hands-on GitHub Copilot SDK workshops in .NET, Node.js/TypeScript, Python, Go, Rust, or Java:

  • Accessibility Reviewer: build an SDLC developer tool that inspects a web page, consults application-owned WCAG guidance, and produces an evidence-based report.
  • Museum Exhibit Studio: build a non-SDLC curator that transforms educator-approved facts into visitor-ready exhibit copy, optionally enriched by cited Wikipedia research through a local lookup, behind deterministic capability boundaries.

Across the workshops, you'll:

  1. Create a Copilot client and conversation session.
  2. Separate durable agent policy from task-specific data.
  3. Choose between local tools and MCP tools with tightly scoped tool allowlists.
  4. Enforce capability, input, timeout, validation, and lifecycle boundaries in application code.
  5. Explain what the model can infer and what the application must prove.

Plan on about 115 minutes for Accessibility Reviewer or 90 minutes for Museum Exhibit Studio. Machine setup happens separately in an untimed preflight for each workshop. Each workshop includes its interactive HTML lesson and ends with a celebration and resources.

Start the workshop

Open the GitHub Pages URL produced by the repository's Deploy to GitHub Pages workflow. Choose a workshop outcome, choose a language, then start the selected workshop. The site derives its Pages base URL at runtime, so there is no hardcoded organization or user Pages hostname.

To preview the site from a clone:

git clone https://github.com/github/copilot-sdk-workshop.git
cd copilot-sdk-workshop
python3 -m http.server 8000

Open http://localhost:8000/docs/. Do not open step.html with a file:// URL; browsers block the Markdown requests used by the lesson viewer.

Prerequisites

Preflight walks through installation checks, authentication, OS-specific commands, expected output, and troubleshooting.

Repository layout

copilot-sdk-workshop/
|-- docs/                         GitHub Pages site and controlled target page
|-- workshop/                     Two complete workshop tracks and completion resources
|-- start-accessibility/          Accessibility Reviewer starters in all six languages
|-- start-museum/                 Museum Exhibit Studio starters in all six languages
|-- finished/dotnet/
|   |-- hello-copilot-sdk/        Completed local-tool example in every language
|   |-- accessibility-report/     Completed .NET local + MCP reporter
|   `-- museum-exhibit-studio/    Museum curator with application-owned fact and research lookups
|-- finished/nodejs/              Completed TypeScript projects
|-- finished/python/              Completed Python projects
|-- finished/go/                  Completed Go projects
|-- finished/rust/                Completed Rust projects
|-- finished/java/                Completed Maven Java projects
|-- src/BlazorApp/                Source counterpart of the deployed target
|-- scripts/                      Deterministic content and build validation
`-- .github/workflows/            Validation and Pages deployment

Validate a change

bash scripts/validate-workshop.sh

The command checks lesson structure, internal links, site behavior hooks, and project coverage. It then runs browser-independent language-selection and completion tests and restores, builds, or syntax-checks every accessibility and museum starter, every finished project, and the Blazor target without authenticating Copilot, launching a browser, or sending a prompt. The museum projects ship no tests, mocks, or fixtures, so their targets only restore and build.

Pass a language ID to run one smoke-build target:

bash scripts/validate-workshop.sh nodejs

Pull requests run content validation and all six language smoke builds as separate GitHub Actions jobs, so a failure identifies the affected SDK track.

Museum Exhibit Studio workshop

Museum Exhibit Studio starters live under start-museum/<language>, with completed references under finished/<language>/museum-exhibit-studio. Each starter ships one pre-built curator helper module that learners never edit: approved fact sets and their bounds, a streaming printer, deterministic exhibit validation, the scoped Wikipedia MCP server with its deny-by-default permission handler, the single-file exhibit.html write permission, and small terminal prompts.

Learners work directly in start-museum/<language> and grow that one project across the lessons, running it at every step. They write only the session setup, the curator and research system messages, the prompt builders, one session runner that owns the lifecycle and timeout, and main. The finished sample is what a learner ends up with, not a separate reference architecture.

The learner-facing track begins at workshop/museum-00-preflight.md, then runs through seven steps — first session, streaming, curator voice, approved facts, structural checks, and Wikipedia MCP research, followed by an interactive exhibit.html capstone — and finishes with celebration and resources.

When usable cited research exists, the curator calls approved_fact_lookup and the read-only approved_wikipedia_fact_lookup before writing the narrative and visitor questions. The second tool returns captured research, not live Wikipedia access or human-verified facts. Approved facts take precedence, and declined, failed, or uncited research keeps the single-tool generation path. Structural validation does not prove factual grounding; review researched claims before publishing.

Rust checks share one Cargo target directory across all workshop projects, avoiding repeated SDK dependency compilation.

Deployment

After validation passes, push to main. The Pages workflow publishes docs/ plus the Markdown lessons in workshop/. Build and content validation run separately in the validation workflow.

Enable GitHub Pages in repository settings and choose GitHub Actions as the source. The deployment job reports the canonical workshop URL in its environment.

The deployment workflow verifies every published HTML page, site asset, and Markdown lesson. It checks the URL returned by GitHub Pages by default. To validate a future public or custom domain instead, set the repository Actions variable WORKSHOP_SITE_URL to that site's base URL. You can run the same check manually:

WORKSHOP_SITE_URL=https://workshop.example.com/ python3 scripts/validate_deployment.py

References

License

This project is licensed under the MIT License.

This workshop is provided as-is for educational purposes. It is intended to demonstrate concepts and patterns rather than serve as a complete production service.