Structured machine readable API for Copilot code reviews, that does not change every few days?

[ptr727]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Copilot Code Review

Body

I am using Copilot for code reviews, driven by Claude in VSCode, through a python script I wrote to isolate Claude from Copilot, and I would like a well structure machine readable API for the review interaction.

I don't mean the current gh API GraphQL where the flow is reasonably well know, but what Copilot writes keeps on changing day by day. Words change, structure changes, A/B testing changes the experience session to session, low confidence issues can no longer be replied to as a thread so there is no context to maintain, I find it really frustrating.

I started with just instructions for Claude on how to interact with Copilot reviews, but I found it was burning tokens, making the same mistakes over and over as one API does not work and switches to another, and when the Copilot structure changes it just ignores serious review issues and claims all is good.

That is why I wrote the python adaptor script, Claude talks to the script, the script talks to github and interprets what Copilot is trying to say. This at least results in a hard break if the script encounters a new flavor of a Copilot review, but it still breaks.

Is there a more structured Coplit review API?
If not, please please create one, it is like the wild west trying to interpret what Copilot is trying to say when it speaks in words rather than data.

[narendraanbazhagann]

I think you're running into a real gap between the GitHub API surface and the Copilot review experience.

GitHub does expose APIs for requesting a Copilot review and for retrieving pull-request review comments, but those APIs don't appear to provide a stable, Copilot-specific schema for the semantic output of the review itself. The review is exposed largely through the normal PR/review-comment model.

That makes your Python adapter approach pretty understandable. If the goal is to have Claude consume Copilot's findings reliably, I'd avoid parsing the rendered text/Markdown as much as possible and normalize the REST response into your own schema, for example:

{
"reviewer": "copilot",
"severity": "high",
"file": "src/example.py",
"line": 42,
"body": "...",
"thread_id": "...",
"status": "open",
"suggestion": "...",
"source": "github_review_comment"
}

You could then make your adapter fail loudly whenever GitHub returns something it doesn't recognize, rather than allowing Claude to silently interpret a new format incorrectly.

I agree that a first-class structured Copilot Review API would be much cleaner, especially if it exposed stable fields for severity/confidence, location, category, suggestion, thread/review IDs, and resolution state. That would make integrations with other agents and automation considerably less brittle.

GitHub is also continuing to expand Copilot code review with things like MCP and agent skills, so the review system is clearly still evolving.

I'd definitely +1 a feature request for a versioned, machine-readable Copilot review schema rather than having integrations infer semantics from the human-facing output.