getting-started-with-github-copilot: a GitHub Skills exercise in an hour

A template repository that prepares itself

getting-started-with-github-copilot is one of the GitHub Skills exercises, and its structure is worth understanding because the format is reusable.

The repository is not the exercise content in the usual sense. It is a template. The exercise starts with a button that takes you to a GitHub URL with a template owner, a template name, a target owner, a target repository name, a description, and a visibility, all pre-filled. Following it creates a copy of the exercise in your own account, and the copy is the thing you work in.

The exercise is scoped tightly. The stated goal is to get started using GitHub Copilot in less than an hour, and the README repeats that the exercise takes less than one hour to complete. The audience is developers at any experience level looking to accelerate their code workflow, the prerequisites are an Introduction to GitHub skills exercise, familiarity with VS Code, and basic coding principles, and the knowledge you are meant to take away is the different ways to interact with Copilot to explain, write, plan, and develop code.

The repository itself carries a small but telling file list. There is a .devcontainer directory, which is the configuration for the Codespace, a .github directory, a .vscode directory, a pytest.ini, a requirements.txt, and a src directory. So what you get after copying is a working development environment with a small web application in it, and the exercise is the interaction with Copilot rather than the setup of the app.

The licence is MIT, there is a code of conduct, and the repository has no releases, which is what you would expect from something distributed as a template rather than as a package.

What you build: a school extracurricular activities site

The project you work on is described in one line: you will guide Copilot to update Mergington High School's extracurricular activities website.

That framing is the pedagogically interesting part of the exercise. The app is small and recognisable, so there is no time spent understanding an unfamiliar domain, and the task is to change it rather than to write it from nothing. That is a deliberate choice for a one hour session, because the time has to go to the interaction with the assistant rather than to the domain.

The sample application is a web app, and the dependency list tells you what it is built with.

fastapi
uvicorn
httpx
watchfiles

FastAPI is the web framework, uvicorn is the server it runs under, httpx is the HTTP client used for the tests and for talking to the app, and watchfiles is the file watcher that makes the development server reload when you edit a file.

That combination is a normal modern Python web stack, and the presence of pytest.ini in the repository means the exercise ships with a test suite. So the app is small, it is served with a hot reloading development server, and it can be checked with tests.

The application being a real, if small, codebase rather than a scratch file is what makes the exercise honest. Copilot suggestions are only useful when there is context to draw on, and a school activities site with routes, models, and a bit of styling gives the assistant something to work with in the same way a real project would.

Three things to do, in a preconfigured Codespace

The exercise lists exactly three things you will do, and the order is the lesson plan.

First, you use a preconfigured Codespace to run VS Code in your browser. That choice removes the largest obstacle for a newcomer, since there is nothing to install locally and nothing to configure. The Codespace comes from the .devcontainer directory in the template, which is the standard mechanism for describing a development container, including the tools, the editor, and the settings that are present when the container starts.

Second, you learn the different interaction options to develop and plan with GitHub Copilot. This is the core of the exercise and the only step that is not a single action. The framing that it covers explaining, writing, planning, and developing is a good summary of the modes: an assistant that can answer a question about the code, write code from a description, propose a plan before writing anything, and then work through that plan.

Third, you use Copilot to summarize and review your pull request. That step is the one most people skip in real life and the one that connects the exercise to a working habit, because a pull request summary and a review are the artefacts your teammates actually read.

The three steps together are a full loop rather than a feature demo. You start from a running environment, you practise the interaction modes on a codebase you can see, and you finish by producing something reviewable. And the whole thing is scoped to fit in an hour, which is a real constraint on how the lesson is paced.

The 20 second preparation, and what to do when it fails

The start procedure is unusual enough to need an explanation, and the README gives one in a single sentence: copy the exercise to your account, give your favorite Octocat, Mona, about 20 seconds to prepare the first lesson, then refresh the page.

The preparation is a GitHub Actions job that runs when the template is copied, and it is what sets up the Codespace with the content of the first lesson. The copy itself is instantaneous, but the environment is not ready until that job has run, which is why the instruction is to wait and refresh rather than to start immediately.

The troubleshooting section is written for the case where that wait does not work, and it is short and specific. If the exercise is not ready in 20 seconds, check the Actions tab, and check whether a job is running, since sometimes it simply takes a bit longer. If the page shows a failed job, submit an issue, and the README notes that you found a bug.

That is a well designed failure path. A template repository that depends on an automated setup step has a failure mode that most training content ignores, and this one tells you where to look, tells you what a slow run looks like as opposed to a broken one, and gives you a place to report it.

The Octocat detail is worth a second look too, because it is a small piece of deliberate design. The preparation is a GitHub Action rather than a script you run, which means the environment is built the same way for everyone, and the mention of a specific character gives the wait a shape, which is a surprisingly effective way to make a countdown feel shorter than an empty progress bar.

Public or private, and the Actions minutes question

The template flow pre-fills the visibility, and the README recommends the setting explicitly, with a reason attached.

For the owner, choose your personal account or an organization to host the repository. And the README recommends creating a public repository, since private repositories will use Actions minutes.

That single sentence is the most consequential line in the exercise for anyone in an organisation that has rules about publishing training content. The preparation step is a GitHub Actions job, and on a private repository those minutes are charged to the organisation's Actions allowance rather than being free. On a public repository they are not.

The recommendation is a practical one about cost, and it also has a side effect that is worth thinking about before you click the button. The copy you create is public, and it contains a small web application and a development container configuration. For a training exercise that is fine. For a team that wants to follow the same format with an internal application, the same template mechanism works, but the minutes question returns, and the visibility decision becomes one your organisation makes rather than one the exercise makes for you.

The rest of the support surface is standard for a GitHub project of this kind. The README links a code of conduct, the MIT licence, and the exercise repository's issue tracker, and it points to the Introduction to GitHub skills exercise as the prerequisite for anyone who is not yet comfortable with the GitHub workflow.

Editorial conclusion

getting-started-with-github-copilot fits a developer who wants a guided hour with Copilot rather than a reference, and who is willing to work in a browser based Codespace with a throwaway account and a public repository. It does not fit a team that cannot use a public repository for its training, since the README points out that private copies consume Actions minutes, and it does not fit anyone looking for guidance they can apply to their own codebase, since the entire exercise is scoped to one sample application. Verify first that the copy has completed before you start, by checking the Actions tab, that the Copilot features the exercise teaches are available on your plan, and that you are comfortable with the sample project being public for the duration of the exercise.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. skills/getting-started-with-github-copilot on GitHub