Add agent definitions for reproducing SDK build-related issues, and analyzing reproduction binlogs#52917
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new Claude skill (investigate-sdk-issue) intended to standardize how build/publish/pack issues in the .NET SDK are triaged using reproductions, binlogs, and MSBuild target tracing.
Changes:
- Introduces a new investigation playbook skill focused on SDK issue triage.
- Documents a step-by-step workflow for reproduction, binlog analysis, target/source tracing, and writing an RCA with links and suggested fixes.
| dotnet restore | ||
| dotnet publish -c Release /bl:1.binlog | ||
| ``` | ||
| Use the `binlog-generation` skill conventions: name binlogs with incrementing numbers (`1.binlog`, `2.binlog`, etc.). |
There was a problem hiding this comment.
This references “binlog-generation skill conventions”, but there doesn’t appear to be a binlog-generation skill in this repo. Either add the referenced skill, or inline the naming convention here without pointing to a non-existent dependency.
| Use the `binlog-generation` skill conventions: name binlogs with incrementing numbers (`1.binlog`, `2.binlog`, etc.). | |
| Name binlogs with incrementing numbers (`1.binlog`, `2.binlog`, etc.) so you can distinguish multiple runs. |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
After talking a bit to @webreidi I'm going to factor this out from a skill into two subagents:
with separate sub-agents, we can re-use them in CCA sessions (assigning things to copilot via github.com), and in copilot CLI/local sessions - skills today are mostly used from the copilot CLI/claude alone. |
|
The agents themselves are able to be used effectively. This is ready for merge, and next steps can orchestrate their use. |
baronfel
changed the title
|
|
||
| You are analyzing a binary log (binlog) to determine the root cause of unexpected .NET SDK behavior. Your goal is to produce a detailed root cause analysis in GitHub-flavored markdown, with links to the specific source code that causes the problem and a suggested fix. | ||
|
|
||
| You should already have a binlog file available. If you do not have one, ask the user to provide a binlog or use the `reproduce-sdk-issue` agent to create one first. |
There was a problem hiding this comment.
Is there a setting or any privacy policy we need to link the user to such that usernames are redacted or does that happen by default now? Are there versions of .NET where that's not true so we should inform the agent they MUST inform the user?
There was a problem hiding this comment.
@copilot invert this ordering a bit: the reproducer agent should first try to create a binlog itself if one is not present. These binlogs will not have any user PII so should be safe to use. If the reproducer agent cannot create a binlog then it should ask the user to create one, but it should surface guidance from the MSBuild repo docs about the privacy implications of submitting binlogs
|
|
||
| ## Step 4: Read the MSBuild targets source code | ||
|
|
||
| Once the binlog analysis points to specific targets, read the actual target definitions in the source repos to understand the logic. The targets may come from several repositories: |
There was a problem hiding this comment.
The binlog should include all of the imported file contents, wouldn't it make more sense to get this from the binlog?
There was a problem hiding this comment.
Good point - I think I expose that via the MCP, I'll have to test if that all works as I expect.
|
/ba-g no checks run for workflow code so this is ready to merge |
This adds agent definitions for triaging build-related issues, based on a session I just did with these tools to diagnose a PublishAOT related issue with satellite assemblies.
The agents assume the following tools:
ghMCP server/CLII think I can express those linkages, but haven't found out how directly yet.