Skip to main content

Getting started with GitHub Copilot Spaces

A lot of developers are using GitHub Copilot as their day-to-day agent harness. But most of them seem to be unaware that with a GitHub Copilot license comes more than a CLI and Visual Studio (Code) plugins. One thing you get access to are GitHub Copilot Spaces.

GitHub Copilot what? Let me first explain what Spaces are and why they are useful.

Why GitHub Copilot Spaces?

If you've used Copilot Chat for a while, you recognize the pattern: you paste in the same background information for the third time this week. The same coding conventions, the same architecture decisions, the same "no, we don't use that library anymore" context. Close the conversation, and Copilot forgets all of it.

Remark: Part of the answer can be found in building up your CONTEXT.md file and using the GitHub Memory feature but it’s not always the right solution.

That's because source code lives in your repositories, requirements live in issues and pull requests, and team conventions often live nowhere except in one person's memory or buried three pages deep in a Teams chat. Plain Copilot Chat can reason about code, but it has no persistent memory of any of that. You end up re-explaining the same background every time you open a new conversation.

A Space gives that background a name and makes it reusable. You build the context once by providing repos, files, issues, PRs, instructions and every conversation inside that Space is grounded in it automatically. No more copy-pasting the same three paragraphs of context before you can ask your actual question.

Concretely, that unlocks a few things:

  • Onboarding: point a new team member at a Space instead of a wiki page nobody kept up to date. They can ask questions and get answers grounded in the real, current codebase.
  • Consistency: document a repetitive pattern once (how we add telemetry, how we wire up a new endpoint) and every developer gets the same answer instead of five slightly different ones.
  • Less repetition, period: stop re-explaining the same architecture decisions in every chat window you open.
  • Reuse beyond chat history: a Space stays put even after your own chat history is long gone, and — for organization-owned Spaces — beyond any single person leaving the team.

Or as stated in the documentation:

GitHub Copilot Spaces enables teams to centralize and democratize organizational knowledge by providing a collaborative environment for storing, searching, and refining process documentation. By connecting your repository as a source, Copilot Spaces can index your documentation and issue templates, making them easily accessible and actionable for all team members. This approach reduces single-person dependency risk, accelerates onboarding, and ensures that project management processes are consistent and repeatable.

Sounds interesting, right?

Creating your first Space

Go to github.com/copilot/spaces and click Create space.

You'll need to decide:

  • A name for the space.
  • Owner: yourself, or an organization you belong to. Organization-owned Spaces can be shared using GitHub's regular permission model, so a team can collaborate on the same Space.

Click Create Space. You can optionally add a description, it doesn't influence Copilot's answers, it's just there to help colleagues understand what the Space is for.


Remark: if you're on a Business or Enterprise plan, Spaces may need to be enabled as a Copilot feature first. If you don't see the option, check with whoever manages your org's Copilot settings.

Once your Space exists, there are two ingredients that shape how Copilot behaves inside it.

Instructions

Free text describing what Copilot should focus on: its area of expertise, what kind of tasks it should help with, and what it should avoid. Think of this as the system prompt for the Space.

An example straight from the Microsoft Learn path:

## Program process documents

- Stored in `docs/`

### Purpose of this Copilot Space

- Centralize scattered project management knowledge in Copilot Spaces
- Convert tacit team insights into searchable, versioned artifacts
- Give all team members equal access to processes, decisions, and rationale
- Connect a repository as a structured knowledge source
- Extract, refine, and standardize workflows collaboratively
- Feed validated improvements back into living documentation
- Accelerate onboarding and reduce single-person dependency risk
- Enable consistent, repeatable project execution

## Issue templates for program process documents

- Stored in `.github/ISSUE_TEMPLATE/`

Feel free to swap this out for something closer to your own use case.

Sources

This is the actual context. You can add:

  • Files and repositories — add whole repos, or better, specific files/folders that are actually relevant. Copilot searches the contents, but a smaller, targeted set of files gives better answers than dumping in an entire monorepo.
  • Links to pull requests and issues — paste the URL, Copilot pulls in the content.
  • Uploaded files — images, text files, rich documents, spreadsheets.
  • Free text content — paste in transcripts, meeting notes, or anything else that doesn't live in GitHub itself.

Tip: when you add a repository as a source, Spaces always refers to the latest version of the main branch. There's no manual "refresh" step, it stays in sync.

Putting it to work

Once you've added sources and instructions, open the Space and start chatting. Your questions are grounded in everything you've added.

A practical example: create a Space per feature you're actively working on. Add the relevant source files, the design doc, and the tracking issue. Ask Copilot to summarize the implementation plan, suggest a reusable function, or check whether your approach lines up with a similar pattern elsewhere in the codebase. Follow-up questions in the same conversation keep using that same context automatically.

You can also switch which model answers your questions inside a Space, via the model dropdown at the top of the chat.

A word on cost

Questions you ask inside a Space count as regular Copilot Chat requests and consume AI credits based on the model and the number of tokens processed. If you're on Copilot Free, that counts toward your monthly chat limit. Nothing exotic, but worth knowing before you build a Space with a dozen large repositories attached.

More information

    Popular posts from this blog

    Podman– Command execution failed with exit code 125

    After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

    Cache stampede: when our cache turned against us

    While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...

    The role of ActivitySource in OpenTelemetry for .NET

    While doing some pair programming to integrate OpenTelemetry tracing to a .NET application, we had a discussion on how to use the ActivitySource . It looks simple. You new one up, give it a name, start an activity, done. The discussion started when we added a second ActivitySource with the exact same name in a different class. This made us wonder: "Are we duplicating traces now? Is this a memory leak? Do we need a singleton?" So we decided to dig deeper. This post is what we learned… What ActivitySource actually is ActivitySource is part of System.Diagnostics , not part of the OpenTelemetry NuGet packages. Microsoft built tracing primitives directly into the BCL, and OpenTelemetry's .NET SDK simply listens to them. This is why you can add distributed tracing to a library without taking a dependency on OpenTelemetry at all. An ActivitySource is a factory for Activity objects, and an Activity is .NET's name for what OpenTelemetry calls a span.(don’t ask m...