What Happened
GitHub has outlined four ways to give Copilot codebase context: repository-wide custom instructions, file-specific instructions, reusable agent skills, and custom agents for broader tasks. MCP servers can connect Copilot to external tools; a Playwright server, for example, can let it test an application in a browser [1].
Separately, GitHub has introduced push attribution in limited public preview for Enterprise customers. It records the authenticated pusher alongside commit author and committer information. An optional repository rule, Committer must match pusher, rejects pushes when the committer email does not match a verified email address of that pusher [2].
Why It Matters to Businesses
These changes address two different weaknesses in AI-assisted development. Instructions and skills can make generated changes more consistent with a team’s conventions and test procedures. Push attribution gives security teams a more dependable identity for investigating a commit than author or committer fields, which a client can set arbitrarily [1][2]. Neither feature establishes that generated code is correct or that a push was authorized for a particular business purpose.
The research notes do not establish comparable new releases from Cursor, Windsurf, Replit, Sourcegraph, JetBrains, VS Code, or Continue.dev. Teams using multiple assistants should therefore treat the GitHub features as a concrete implementation to evaluate, not as evidence of feature parity across tools.
Kimbodo Engineering Perspective
Put durable engineering policy in the repository, not only in individual developers’ prompts. Keep instructions short and testable; use skills for repeatable workflows and specialized agents only when their scope is clear. The trade-off is maintenance: stale guidance can reliably produce the wrong change, while broad tool access can let an agent act beyond what a coding task requires [1].
Push attribution is valuable investigation evidence, but it should complement code review, branch protection, and CI. The committer-matching rule also needs testing against legitimate bot, service-account, and delegated workflows before enforcement [2].
How We Would Implement It
- Document a small set of repository conventions in .github/copilot-instructions.md; add file-specific instructions under .github/instructions where rules genuinely differ [1].
- Package build, lint, and test commands as skills under .github/skills. Define specialized agents in .github/agents for bounded reviews, such as accessibility, rather than general-purpose authority [1].
- Connect only approved MCP servers. For browser testing, run Playwright against an isolated test environment with restricted credentials and review its results in CI [1].
- For eligible GitHub Enterprise repositories, pilot push attribution and audit existing committer-email patterns. Enable the matching rule only after confirming that developer and automation pushes behave as intended [2].
Risks, Costs and Security
Instructions, skills, agents, and MCP connections add configuration and review work; external tools add credential and data-access exposure. Treat repository content and tool output as untrusted input, and limit agent permissions to the task. Push attribution helps identify which account pushed a commit, but a compromised account remains a risk. Its current limited public preview also means availability and rollout must be confirmed with GitHub before making it a required control [1][2].
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Application Development practice, or Estimate My AI Application.
