The workflow at a glance
Name the repositories, time window, observed behavior and investigation-only goal. Require links to issues, pull requests or code for each finding before deciding on implementation. The integration documentation still labels these capabilities public preview, and multi-repository support does not remove account, application or repository permission requirements.
More context does not define the task for you
The October 15 GitHub update describes working across repositories in one Slack or Microsoft Teams conversation, with mention and context improvements. For this scenario, the useful change is the ability to compare frontend and backend clues in one investigation without pretending they belong to one repository.
This is a practical task-design guide, not a report of running an agent in a real organization. Repository names, failures and review examples below are editorial constructions. We have not created issues, sent team messages, changed code or claimed that a model diagnosed this incident.
Check access under the account that will run the task
The Slack integration documentation and Teams integration documentation describe prerequisites including paid Copilot access, app connections, cloud sandboxes and organizational policies, while retaining public-preview labels. Your actual access depends on the account and organization; the announcement does not establish universal eligibility.
App installation, access to a discussion and permission to trigger an agent for a repository are different checks. If access is missing, use the organization’s existing process or narrow the investigation to authorized material. Do not expand access across all repositories just to satisfy one prompt. Check the default repository too: an unspecified target can fall back to configured defaults.
| Boundary | What to record | Why it matters |
|---|---|---|
| Repository | Explicit owner/repository names | Avoid attributing frontend work to the backend |
| Branch and time | Actual branches, time window and time zone | Avoid comparing different stages |
| Thread | Relevant discussion and available material | Keep old decisions out of the current investigation |
| Action | Investigation, planning or modification | Match the result to the requested authority |
Ask for a reviewable investigation table first
@GitHub Investigate only: do not create issues or PRs and do not change code. Scope: example-shop/web and example-shop/api. Compare current main with the last known-good versions we explicitly provide. Symptom: the order page reports a missing deliveryDate; use only the incident times and versions listed in this thread. For each repository, list relevant changes, evidence links, supported and contradicted hypotheses, and missing information. A PR title is not proof of deployment. If a repository is inaccessible, mark it unknown and stop making claims about it.Share only authorized, relevant material. Other participants can also affect context; a separate thread for a new task makes its boundaries easier to inspect.
A merged PR, a deployment and a cause are different facts
Suppose a result finds a frontend field-name change and a backend response-structure change. Their existence supplies candidate clues, not proof that production runs those versions together. Confirm deployed versions, actual responses and reproducible conditions before accepting a causal explanation.
A plausible story is not completed triage. Ask each row to separate observation, evidence, inference and required verification. A link to the repository home page, or code from the wrong branch, is insufficient. If a later decision involves a security fix, our human checks for automated alert fixes similarly separate a proposal from validation.
Keep the conclusion within its evidence
The backend merged a relevant PR yesterday, so it caused today’s production failure.
A relevant backend PR exists; confirm the deployed version and response before testing whether it explains this failure.
Give the investigation an explicit finish condition
A useful investigation does not have to force a root cause. It can rule out two hypotheses and identify the exact version record or log still needed. Clear unknowns often help the next owner more than a complete-looking fix based on an unverified assumption.
If implementation follows, specify the target repository, base branch, allowed changes and acceptance conditions again. Identity and review rules in shared contexts depend on current documentation and organizational settings; starting work in chat does not remove normal repository review. For organization-level considerations, see our Copilot code-review billing and access checks.
Accept the investigation when
- Every finding has evidence from an explicit repository and branch.
- The timeline distinguishes merge, deployment and incident times.
- Inaccessible or missing information remains unknown.
- Hypotheses are separate from observations, without invented test execution.
- Implementation begins only with a renewed target and validation requirements.
Common questions
Does multi-repository support mean every repository is accessible?
No. Account permissions, app installation scope, organization policies and action-specific requirements still apply.
Does the update make the entire integration generally available?
Do not infer that. The integration documentation checked for this article still says public preview; use current official status.
Why investigate before asking for a fix?
The deployed versions and cause may be unknown. An evidence table can prevent changes in the wrong repository or against the wrong hypothesis.
