GitHub Copilot Projects Enters Public Preview: A Workspace for Work Across Repositories

In its October 28 announcement, GitHub describes Projects as a home for context, agents, and results. Users provide a goal, add material such as repositories or design notes, and choose models and tools. GitHub says Copilot coordinates agents in the background and returns results, including pull requests, for review.

The Projects documentation confirms that a project can span multiple repositories or have no repository at all. It also distinguishes an ongoing project from a focused session started directly in one repository. Projects remain in public preview and are subject to change.

Our interpretation is that the main adoption question concerns coordination. A team maintaining an application and a separate component library may want one place to explain the intended change and follow related work. The announcement does not establish that Copilot will correctly identify every dependency or produce compatible changes across those repositories.

GitHub’s documented creation flow lets users select repositories, describe initial tasks and constraints, and add supporting files or folders through the Library tab. The documentation recommends a focused goal and explicitly naming the results you want. That makes the initial brief an important part of any evaluation.

Our proposed pilot is a compatibility assessment for one interface change shared by two repositories. Supply the relevant specification and a short description of expected behavior. Ask Copilot to identify affected code, explain the dependency between repositories, and list unresolved questions before requesting implementation. This is an evaluation scenario, not a workflow we tested.

Keep the input small enough that a reviewer can check whether the agent used the intended sources. A broad instruction such as “finish the release” makes it harder to separate missing context from execution mistakes. For task selection and acceptance criteria, use our guide to choosing an AI coding assistant.

The documentation describes four groups in the project Overview: Needs input, Open, Working, and Done. Needs input collects items requiring attention. Open covers work with an open pull request and shows session status, the associated pull request, and lines added and deleted. Users can open a session to inspect its conversation, changes, pull request, and plan, then provide further direction.

These are documented navigation features, not evidence that a project’s work is complete or correct. In the proposed pilot, check whether each repository’s result addresses the same interface contract. A completed session in one repository does not by itself demonstrate that its counterpart is ready.

Assign a person to make the final acceptance decision. Our AI code review workflow can help structure that review. Ask whether the overview made outstanding decisions easier to find, and record any time spent reconstructing relationships between sessions.

GitHub documents the Library as both a place to supply context and a place to find artifacts created during project sessions. Under All Files, Agent contains generated artifacts and User contains material the user added. GitHub also advises telling Copilot which sources to use for an assignment.

For a small team, that separation offers a useful starting point for review. Our recommendation is to request a report that names the input specification, identifies relevant files, and separates observations from proposed changes. A generated explanation should remain something the reviewer checks against the underlying material.

If implementation follows, require a clear account of checks actually run, their results, and verification still outstanding. Use the approach in our regression-testing guide to define what evidence the change needs. We have not tested whether Projects consistently produces reports with this level of traceability.

Projects also support recurring work. GitHub’s documentation says users can describe a task, schedule, and expected result in the project conversation. The Automations tab shows the schedule and next run time; it also provides controls to edit the schedule, pause a task, or delete it.

Our editorial recommendation is to establish one useful manual result before making that assignment recurring. A weekly summary of newly added project notes is a more contained first experiment than an open-ended instruction to keep several repositories synchronized. Specify which material to use and what the resulting summary must contain.

Check the displayed schedule and next run time before relying on the task. Then inspect the first result for relevance and unsupported conclusions. The presence of scheduling controls does not establish reliable execution or useful output; neither was tested for this article.

Copilot Projects is worth a bounded evaluation when work repeatedly crosses repository boundaries or depends on specifications and design material outside the code. A focused single-repository task may still fit GitHub’s documented direct-session workflow without the extra project organization.

Compare a pilot with a similar recent task. Record clarification requests, missing dependencies, review effort, and corrections needed before acceptance. These are proposed evaluation measures, not measured benefits. Expand use only if reviewers can understand what happened, identify unfinished work, and validate the result without reconstructing every agent conversation.