Busabase × GitHub CopilotKnowledge base for GitHub Copilot
GitHub already records code changes well. Add a reviewed handoff layer for decisions and operational facts that must move between IDE Agent, cloud agent, pull requests, and the systems beyond GitHub.
One product, several execution surfaces
The same task can start locally, continue in the cloud, and end in a review queue.
GitHub distinguishes IDE agent mode from Copilot cloud agent. The cloud agent works in an ephemeral GitHub Actions-powered environment and can create a branch and pull request; IDE Agent edits the developer's local environment. Copilot code review is another consumer of repository context. A durable handoff must say which surface produced each claim.
Local workspace
Edits and tests on a developer machine.
GitHub-hosted task
Research, plan, branch, commits, and a pull request.
Pull request
Checks proposed code against repository context and policy.
Repository context already has owners
Do not duplicate GitHub instructions, commits, and pull requests in a second database.
GitHub supports repository-wide instructions, path-specific instructions, AGENTS.md, and Copilot Memory. Repository-level memories are scoped to the same repository and validated against cited code before use. These are strong mechanisms for code context. Busabase is for the facts whose owner is not the repository alone.
| Artifact | Job | Canonical owner |
|---|---|---|
| .github/copilot-instructions.md | How Copilot should build, test, and validate this repository. | Git |
| AGENTS.md / path instructions | Instructions that change with directory or file scope. | Git |
| Commit and pull request | The exact code change and its review discussion. | GitHub |
| Customer, release, support, or operational decision | A fact reused by people and Agents outside one repository. | Busabase |
The handoff chain
A merged pull request is one event, not the entire delivery record.
A task may begin as an Issue, become an Agent session, produce a pull request, pass CI, deploy, and then change a release or customer-facing state. Each transition has different evidence and a different person responsible for accepting it.
Release evidence contract
Give every cross-system fact enough structure to survive the pull request.
The record should point back to GitHub rather than copy it. A small schema makes it clear when code is merged but rollout, documentation, support readiness, or customer impact still needs review.
| Field | Meaning |
|---|---|
| work_item | Issue or task that authorized the work |
| pull_request | Reviewed code change |
| commit_sha | Exact version evaluated |
| environment | Staging, production, region, or tenant |
| verification | Tests, health checks, or observed result |
| operational_state | Proposed, ready, released, rolled back, or blocked |
| owner | Person accountable for the state |
| effective_at | When downstream users may rely on it |
Review outside the pull request
Code approval and business acceptance can happen at different times.
Copilot can propose a release-state change after reading the merged pull request and deployment evidence. Busabase shows the exact record fields that would change. Product, support, or operations reviews the consequence before the new state is merged.
Events can keep the ledger current
Use automation to propose follow-up work, not to erase the reviewer.
A deployment webhook or scheduled Agent can detect a new event and open a Change Request. Delivery logs show whether the event arrived; the record review still decides whether its interpretation becomes canonical.
deploy.succeededPropose release state and verification URLdeploy.failedPropose blocked state and incident ownerrollback.completedPropose restored version and affected scope
MCP differs by execution surface
A connection that works in VS Code is not automatically valid for Copilot cloud agent.
The Busabase connection page covers Copilot Agent mode in VS Code, where a Streamable HTTP server can complete OAuth. GitHub's cloud-agent documentation currently says its MCP integration supports tools only, not resources or prompts, and does not support remote MCP servers that use OAuth. Treat these as separate deployment choices.
| VS Code Agent mode | Streamable HTTP + OAuth | Use the existing connection guide and confirm auth_verify. |
|---|---|---|
| Copilot cloud agent | Repository MCP configuration | Select only required tools; current remote OAuth limitation applies. |
| Copilot code review | Shares repository MCP settings | Review tool access because calls may run autonomously. |
Questions about Copilot handoffs
GitHub Copilot knowledge base FAQ
Does Busabase replace GitHub Issues or pull requests?
No. GitHub should remain canonical for code tasks, commits, branches, pull requests, and code review. Busabase owns reviewed facts that cross repositories or feed product, support, release, and operations workflows.
Does it replace Copilot Memory?
No. Copilot Memory stores repository facts and personal preferences for supported Copilot features. Busabase is useful when a record needs explicit fields, an external owner, a review decision, and reuse outside the same repository.
Can cloud agent connect the same way as VS Code Agent mode?
Not necessarily. GitHub documents different MCP capabilities and authentication limits for cloud agent. Configure and verify each execution surface independently.
Should deployment events write directly to the record?
A deterministic event may trigger a proposal, but a successful delivery does not always establish business readiness. Keep review when the state affects customers, support, compliance, or coordinated rollout.
What should the first Base track?
Start with one handoff where teams currently disagree: release readiness, migration status, security remediation, incident follow-up, or customer-impacting change state.
Start after the pull request
Turn one merged change into a reviewed fact every team can use.
Connect Copilot in the environment you actually use, define one release-state record, and review the first handoff from GitHub evidence to operational truth.