An imaginary food pantry has a small CSV importer maintained in GitHub. A new volunteer developer wants to know whether donor reference IDs must retain their leading zeros. The repository contains executable validation code, an approved schema and an old issue thread proposing numeric conversion. GitHub Copilot Spaces can collect relevant sources and instructions so a developer can ask a targeted question without repeatedly describing the project. But a confident answer remains a hypothesis until it is checked against the governing files and tests. The scenario and example IDs are fictional. We did not access a real repository or observe the tool’s output.
Identify the authoritative CSV contract
Before configuring a Space, write a small contract for the importer: the identifier column is text, the amount column is decimal, dates follow a declared format, and rejects must record a reason. Use a made-up row such as donor ID 0042 and compare it with 42. Those identifiers may represent distinct records, so dropping zeros can cause a destructive merge. Find the schema, tests and import function that actually enforce the policy. A README is useful background, but executable behavior, approved data definitions and release ownership should settle disagreements. Document the owner and current branch before asking the model to interpret the rule.
Create a Space with narrow, useful sources
GitHub documents creating a Space from github.com/copilot/spaces and selecting personal or organization ownership. Add an instruction such as: explain the importer using the attached schema and tests; distinguish current behavior from proposed changes; link the specific files; do not invent requirements. Add the smallest source set that answers the question: importer module, schema, test file and relevant approved pull request. GitHub’s guide distinguishes whole-repository retrieval from attaching individual files whose full contents are provided in context. Large repositories can help discovery, while a small curated file set helps prevent unrelated examples from dominating a precise answer.
Separate current code from historical discussions
An issue that once suggested converting IDs to integers is still valuable evidence of a rejected option, not authority to change today’s importer. Label sources by role: approved specification, current implementation, current tests and historical discussion. Ask Copilot to return a table of claims with the file or issue supporting each one, plus an ‘unresolved’ entry when sources conflict. Reopen the named files yourself. Copilot Spaces can synchronize GitHub-based sources as they change, but a model response does not substitute for checking which branch, release tag or policy version an answer describes. Where the contract is unsettled, ask the code owner.
Test a concrete question rather than a vague summary
Ask: ‘Should import_row preserve 0042 as a string, and which assertion proves it?’ Then test the response with a second case: ‘What should happen if amount is blank, or if two rows share ID 0042?’ Do not ask Copilot to invent a donor database. A useful reply distinguishes string preservation from duplicate detection and points to evidence for each. If the response cites an obsolete issue while ignoring the approved schema, mark that failure in your review notes and adjust the Space’s sources. The diagram’s incorrect conversion is a teaching example, not a measurement of Copilot behavior.
Verify in tests and branch-specific code
Inspect the exact repository code and run the existing import tests locally or in an approved CI environment. Add a regression fixture with both ‘0042’ and ’42’ as separate text IDs, a rejected malformed date, and a duplicate that should be flagged rather than silently accepted. Verify whether the result matches the organization’s business rule; a green test can still encode a mistaken assumption. Treat Copilot’s explanation as a way to navigate unfamiliar code, not authorization to merge a change. If the implementation and written schema differ, open a tracked issue with both references before changing production behavior.
Use organizational ownership and share conservatively
GitHub’s sharing guide describes viewer, editor and admin roles for organization-owned Spaces, with the option of no access by default. A viewer can ask questions and see available attachments; editors can change the knowledge set. Decide who should update instructions and who should merely consult them. Before sharing, scan all uploaded files and free-text notes for API keys, private data samples, operational URLs and personal information. A Space should not become a casual copy of a production .env file. Github source permission rules still matter, and organizational policy must govern whether examples can be made available to contractors.
Check the difference between a Space and a test run
A Space organizes context; it is not a sandbox that proves a code change safe. Keep asking ‘Where does this claim come from?’ and ‘What automated or manual check would refute it?’ For instance, a generated answer may correctly quote the schema but misunderstand how spreadsheet software formatted a CSV before upload. Verify the original bytes and import parsing separately. Record whether the row was read as text, whether quotes were preserved, and whether the user saw a clear validation error. Review the entire path from user file to stored record, especially when identities or financial figures are involved.
Maintain the Space when specifications change
When a new release changes the column set, revise the Space’s instructions and verify attached file links still target the governing work. A GitHub reference may update automatically while an uploaded spreadsheet or pasted note can remain stale; review both types of context. Remove superseded workarounds from the approved-source list or label them historical, rather than deleting the audit trail. Assign a maintainer and a small recheck schedule for important imports. The goal is a stable handoff: new developers should see how the team decides, not just a polished AI paraphrase of uncertain notes.
Publish a reproducible developer handoff
The final handoff should state the source revision, expected behavior of donor IDs, allowed date formats, reject logging and exact commands for running tests. Include an unresolved-questions line and the responsible reviewer. Do not copy sensitive payloads into a public issue. If the model produces a neat explanation but no verifiable references, send it back for sources or write the explanation manually. This hypothetical tutorial illustrates a governance workflow. It does not demonstrate that a particular Copilot Space was configured, that source search was exhaustive, or that a real importer has been certified correct.
How We Research
We reviewed these named official developer resources: GitHub Docs — Creating GitHub Copilot Spaces; GitHub Docs — About GitHub Copilot Spaces; GitHub Docs — Collaborating with others using Copilot Spaces. We checked the documented feature entry points, eligible platforms, administrator or licensing controls, and known sharing or source limitations against the tutorial steps. Editorial examples were designed as hypothetical failure-mode checks, not reports of hands-on testing. We did not have a live account, source files from a museum or nonprofit, user interviews, access to private records, or measured model outputs. Every illustration is original explanatory artwork rather than a vendor screenshot or measured before/after result. Features and entitlements can change. A responsible editor should confirm current product documentation, applicable organizational policy, and the original evidence before putting the workflow into consequential use.
Frequently Asked Questions
No. It curates context and helps answer questions; executable tests and code review still determine whether importer behavior is correct.
GitHub says anyone with a Copilot license, including Copilot Free, can create and use Spaces, subject to applicable usage limits and policies.
Not as a single loaded document. GitHub describes searching repositories for relevant context while specifically attached files are supplied more directly.
Sharing depends on the configured role. Set viewers, editors, admins or no access explicitly and inspect attachments before inviting people.
Open the approved specification and current tests, mark the issue as historical, and escalate any contradiction to the owner.