Download a lab. Keep your work separate.

One exercise, one learner kit, one disposable workspace. Start with the material you need instead of cloning every language, installing every dependency or copying an instructor’s finished solution.

[!TIP] First visit? Choose 01 — Context and interface below. You need Node 24 for its local tests; Copilot access is separate. No GitHub repository or cloud subscription is required for the local exercise.

What a kit contains

Kits exclude the instructor reference directory, Git history, dependencies, caches and local environment files. They do not include accounts, runtimes or credentials. The canonical lesson and code remain in English inside the package; the learning site also offers Spanish and Brazilian Portuguese reading views. External official references still need an internet connection.

[!IMPORTANT] A starter is not a completed application. Some first checks deliberately fail. Follow the expected state in KIT-START.md; a missing runtime, an import error or an empty test run is not a successful reproduction of an intentional failure.

1. Select and download

On the learning site, a ZIP link downloads the archive directly. On GitHub, if the link opens a file preview, select Download raw file. Download the matching checksum inventory from the same reviewed revision.

Hands-on kits

The five preparation guides reuse the associated exercise kit; they do not need five duplicate archives. Choose either the C# or Python variant for language-paired labs, not both at once.

Adventure kits

Each kit contains the lab, its verifier and the adventure instructions. A verifier rejects an unfinished exercise unless the table says otherwise. Host discovery and live integrations require separate evidence.

2. Verify and extract on your system

Choose an existing project/work drive with enough space. The paths below are examples: replace them with your approved work location. Never extract over an existing repository. On the shared workshop Mac, use the T9 work drive.

Compare the full hash with the entry in SHA256SUMS.txt. A hash from inside an untrusted archive does not authenticate that archive. Review the repository and download origin before executing any code.

Open the extracted folder and read KIT-START.md. It specifies whether VS Code should open the kit root or starter/. Use File → Open Folder in a new window. Do not leave another repository in a multi-root workspace.

Checkpoint: you can find the source, lesson and manifest on disk outside the ZIP viewer. If Node 24 is installed, node KIT-VERIFY.cjs from the kit root checks that extraction preserved the packaged files.

3. Run only the selected baseline

1. Read the runtime requirement in KIT-START.md.
2. Select the matching interpreter/SDK. Do not install all language stacks.
3. Use the working directory printed beside the baseline command.
4. Record the command, discovered tests, exit code and actual output.
5. Compare the result with expected pass or intentional starter failure.
6. Continue with KIT-LESSON.md: concepts, Ask, Plan, Agent, negative checks and review.

Local contract tests do not need Copilot authentication. A live agent, CLI, SDK or cloud exercise may require account access and can consume usage. Keep it separate.

Use VS Code or Insiders from the extracted kit

1. Read the workspace value in KIT-START.md. Hands-on kits open at the kit root; adventure customizations open under starter/.

2. Use File > Open Folder in your chosen edition, or open a terminal in that workspace and run one editor command:

   code .
   

   For Insiders instead:

   code-insiders .
   

3. Check the active GitHub account and profile in that edition. Review Workspace Trust and the supplied customizations before authorizing tools.

4. Follow the lesson’s Ask, Plan, Agent and review stages. From an adventure’s starter/ terminal, the verifier is one directory above:

   node ../verify.js
   

   From the adventure kit root instead:

   node verify.js
   

These two commands are alternatives based on the working directory, not two different tests. Hands-on kits use the baseline printed in their own first-run guide. Do not substitute an adventure verifier for a language-specific test.

Use Copilot CLI from the extracted kit

1. Complete CLI installation and authentication for your operating system. No VS Code installation is necessary for terminal-only code work.

2. Open a terminal in the extracted kit root. For an adventure, enter its starter/ directory first; for a hands-on kit, stay at the kit root:

   cd starter
   

   Run the directory-change command only for an adventure. Then start the standalone agent:

   copilot
   

3. Use the lesson’s investigation prompt without edits first. Then request a plan with file scope, positive and negative checks, and reset. These are responsibilities, not a promise of identical VS Code controls in the CLI.

4. Approve only the reviewed change. Do not grant access to the whole parent repository or disable permission prompts to make a test convenient.

5. Keep a separate ordinary terminal for tests. Run the commands in KIT-START.md from its stated directory; do not paste test commands into the agent as if that were an executed terminal result.

6. Review the real diff and outputs. If you initialized Git at the kit root, these read-only commands show the changes:

   git status --short
   git diff
   

7. Record the actual surface, version, permissions and limitations in your evidence. Exit the learning session when finished; do not leave an unattended agent with broad authority.

The same starter can support different environments without making their capabilities interchangeable. Azure credit is not required for these local checks or for GitHub Copilot CLI authentication.

4. Create a local repository, if needed

Run these commands inside the extracted kit root, after inspecting its files:

git init -b training
git status --short

Review the file list. Exclude dependencies, environment files and runtime data in the local .gitignore before staging. If Git needs an identity, configure it for this repository only, with your own approved name and email.

git config user.name "YOUR NAME"
git config user.email "YOUR APPROVED EMAIL"
git add .
git commit -m "Record untouched learning baseline"

The two identity values are placeholders, not commands to copy unchanged. Creating this local baseline does not create a repository on GitHub.

5. Optionally publish to your own GitHub repository

[!CAUTION] Publishing transfers files to GitHub. Review licenses and every staged file. Never upload credentials, real personal data or instructor-private material. A private repository is a sensible default, not permission to upload secrets.

1. Sign in to GitHub using your authorized account.
2. Select New repository and choose an owner you are allowed to use.
3. Enter a unique training name and choose the appropriate visibility.
4. Leave initialization with README, license and .gitignore unchecked: the local kit already has files and a commit.
5. Create the empty repository and copy its HTTPS URL.
6. In the kit root, inspect git remote -v. If there is already an origin, stop and confirm which repository it identifies; do not replace it automatically.
7. Add the copied URL and push the training branch:

git remote add origin https://github.com/YOUR-OWNER/YOUR-TRAINING-REPOSITORY.git
git push -u origin training

Replace the URL placeholders. Use GitHub’s approved authentication flow; do not place an access token in the URL or a document. Check the branch and files on GitHub. A cloud-agent assignment or pull request is a later, separately reviewed action.

Finish, troubleshoot and reset

• Keep the original archive as a clean baseline.
• Save the diff, executed checks and limitations.
• Stop only processes and sessions created for the exercise.
• Extract into a new unused directory for another attempt.
• Close only exercise-owned remote resources after reviewing what must be preserved.

Maintainer reproducibility

From the curriculum checkout, run npm run build:kits after changing a packaged lesson, fixture or image. npm run check:kits rejects missing/stale artifacts. The generator uses Node’s standard library, sorted entries, fixed ZIP timestamps, bundled licenses, file manifests and SHA-256 inventory. It never runs learner code. This is reproducibility for the declared package format, not a security certification.

ZIP entries use the uncompressed STORE method, so checksums do not depend on the runtime’s compression library. Archives are larger than compressed ZIPs, but keep the same extracted files and deterministic bytes across supported environments.

Official references

• Download source archives
• Add locally hosted code to GitHub
• Set up Git
• Open a VS Code workspace