mirror of
https://github.com/dotnet/skills.git
synced 2026-09-20 09:49:54 +08:00
231 lines
9.5 KiB
Markdown
231 lines
9.5 KiB
Markdown
---
|
|
name: "Issue Investigate"
|
|
description: >
|
|
Deep investigation agent triggered when the 'auto-investigate' label is
|
|
added to an issue. Performs thorough analysis of the issue against the
|
|
codebase and related issues, suggests optimal next steps, and creates
|
|
a draft PR with the fix if the solution is clear.
|
|
|
|
on:
|
|
issues:
|
|
types: [labeled]
|
|
|
|
# ###############################################################
|
|
# Override the COPILOT_GITHUB_TOKEN secret usage for the workflow
|
|
# with a randomly-selected token from a pool of secrets.
|
|
#
|
|
# As soon as organization-level billing is offered for Agentic
|
|
# Workflows, this stop-gap approach will be removed.
|
|
#
|
|
# See: /.github/actions/select-copilot-pat/README.md
|
|
# ###############################################################
|
|
steps:
|
|
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
|
name: Checkout the select-copilot-pat action folder
|
|
with:
|
|
persist-credentials: false
|
|
sparse-checkout: .github/actions/select-copilot-pat
|
|
sparse-checkout-cone-mode: true
|
|
fetch-depth: 1
|
|
|
|
- id: select-copilot-pat
|
|
name: Select Copilot token from pool
|
|
uses: ./.github/actions/select-copilot-pat
|
|
env:
|
|
SECRET_0: ${{ secrets.COPILOT_GITHUB_TOKEN }}
|
|
SECRET_1: ${{ secrets.COPILOT_GITHUB_TOKEN_2 }}
|
|
SECRET_2: ${{ secrets.COPILOT_GITHUB_TOKEN_3 }}
|
|
SECRET_3: ${{ secrets.COPILOT_GITHUB_TOKEN_4 }}
|
|
SECRET_4: ${{ secrets.COPILOT_GITHUB_TOKEN_5 }}
|
|
SECRET_5: ${{ secrets.COPILOT_GITHUB_TOKEN_6 }}
|
|
SECRET_6: ${{ secrets.COPILOT_GITHUB_TOKEN_7 }}
|
|
SECRET_7: ${{ secrets.COPILOT_GITHUB_TOKEN_8 }}
|
|
|
|
# Only run when the 'auto-investigate' label is applied
|
|
if: ${{ github.event.label.name == 'auto-investigate' }}
|
|
|
|
concurrency:
|
|
group: gh-aw-${{ github.workflow }}-${{ github.event.issue.number }}
|
|
|
|
# Add the pre-activation output of the randomly selected PAT
|
|
jobs:
|
|
pre-activation:
|
|
outputs:
|
|
copilot_pat_number: ${{ steps.select-copilot-pat.outputs.copilot_pat_number }}
|
|
|
|
# Override the COPILOT_GITHUB_TOKEN expression used in the activation job
|
|
engine:
|
|
id: copilot
|
|
env:
|
|
COPILOT_GITHUB_TOKEN: ${{ case(needs.pre_activation.outputs.copilot_pat_number == '0', secrets.COPILOT_GITHUB_TOKEN, needs.pre_activation.outputs.copilot_pat_number == '1', secrets.COPILOT_GITHUB_TOKEN_2, needs.pre_activation.outputs.copilot_pat_number == '2', secrets.COPILOT_GITHUB_TOKEN_3, needs.pre_activation.outputs.copilot_pat_number == '3', secrets.COPILOT_GITHUB_TOKEN_4, needs.pre_activation.outputs.copilot_pat_number == '4', secrets.COPILOT_GITHUB_TOKEN_5, needs.pre_activation.outputs.copilot_pat_number == '5', secrets.COPILOT_GITHUB_TOKEN_6, needs.pre_activation.outputs.copilot_pat_number == '6', secrets.COPILOT_GITHUB_TOKEN_7, needs.pre_activation.outputs.copilot_pat_number == '7', secrets.COPILOT_GITHUB_TOKEN_8, secrets.COPILOT_GITHUB_TOKEN) }}
|
|
|
|
permissions:
|
|
contents: read
|
|
issues: read
|
|
pull-requests: read
|
|
|
|
tools:
|
|
github:
|
|
toolsets: [repos, issues, pull_requests]
|
|
bash: ["cat", "grep", "head", "tail", "find", "ls", "wc", "jq", "sort", "diff", "sed", "awk"]
|
|
edit:
|
|
|
|
safe-outputs:
|
|
add-comment:
|
|
max: 2
|
|
create-pull-request:
|
|
max: 1
|
|
add-labels:
|
|
max: 3
|
|
|
|
network:
|
|
allowed:
|
|
- defaults
|
|
|
|
timeout-minutes: 30
|
|
---
|
|
|
|
# Issue Investigation
|
|
|
|
You are a senior engineering investigation agent for the dotnet/skills repository. You have been triggered because the `auto-investigate` label was added to issue #${{ github.event.issue.number }}.
|
|
|
|
Your goal is to perform a deep, thorough investigation of the issue, understand the root cause, and either suggest optimal next steps or — if the fix is clear — implement it and open a draft PR.
|
|
|
|
## Step 1: Understand the Issue
|
|
|
|
1. Use the `get_issue` tool to fetch the full issue content (title, body, labels, comments)
|
|
2. Read all comments on the issue using the `get_issue_comments` tool
|
|
3. Identify:
|
|
- What is the reported problem or requested change?
|
|
- Are there reproduction steps?
|
|
- Are there error messages, logs, or stack traces?
|
|
- What area of the codebase is affected?
|
|
|
|
## Step 2: Explore the Codebase
|
|
|
|
Based on the issue content, explore the relevant parts of the codebase:
|
|
|
|
1. Read the CODEOWNERS file to understand ownership: `cat .github/CODEOWNERS`
|
|
2. List the repository structure to orient yourself: `find plugins/ -maxdepth 3 -type f | head -100`
|
|
3. Search for files and code related to the issue using bash tools (`grep -r`, `find`, `cat`)
|
|
4. If the issue mentions specific files, skills, or plugins — read them in full
|
|
5. Look at recent commits and changes in the affected area if relevant
|
|
|
|
## Step 3: Research Related Issues
|
|
|
|
1. Use `search_issues` to find related open and closed issues
|
|
2. Look for:
|
|
- Duplicates that may have already been resolved
|
|
- Related issues that provide additional context
|
|
- Past discussions that inform the solution approach
|
|
3. Note any patterns (e.g., recurring issue in the same area)
|
|
|
|
## Step 4: Multi-Model Plan Generation and Validation
|
|
|
|
Before taking any action, generate independent plans from multiple models and synthesize the best approach.
|
|
|
|
### 4a. Prepare a planning brief
|
|
|
|
Write a concise planning brief that summarizes everything you have learned so far. Include:
|
|
- The issue summary and key details
|
|
- Root cause hypothesis (if any)
|
|
- Relevant files and code paths discovered
|
|
- Related issues found
|
|
- Constraints (e.g., scope, backward compatibility, ownership)
|
|
|
|
### 4b. Dispatch planning tasks to three models
|
|
|
|
Invoke the following **three inline sub-agents** (`task` tool, `agent_type: "general-purpose"`, `model: "<model>`) with `claude-opus-4.6`, `gpt-5.2-codex`, `gemini-3-pro-preview` models. Each sub-agent runs a different model so you get diverse perspectives. Pass each the same planning brief and ask each to produce a structured plan.
|
|
|
|
The sub-agent prompt is:
|
|
|
|
> You are a senior engineering planning assistant. You will receive a planning brief about a GitHub issue in the dotnet/skills repository.
|
|
>
|
|
> Produce a structured plan with the following sections:
|
|
> - **Problem statement**: one-sentence summary of the root cause
|
|
> - **Proposed solution**: what changes to make and why
|
|
> - **Affected files**: list of files that would be modified
|
|
> - **Risk assessment**: what could go wrong, edge cases, scope creep
|
|
> - **Alternative approaches**: at least one alternative considered and why it was rejected
|
|
> - **Confidence**: High / Medium / Low with rationale
|
|
>
|
|
> Be thorough and precise. Focus only on the information provided in the brief.
|
|
|
|
### 4c. Review and synthesize
|
|
|
|
Once all three sub-agent plans are returned, review them critically:
|
|
|
|
1. **Compare** the three plans side-by-side:
|
|
- Do they agree on the root cause? Disagreement is a red flag — investigate further.
|
|
- Do they propose the same solution? If so, confidence is high.
|
|
- Do they identify different risks? Union of all identified risks is the true risk set.
|
|
|
|
2. **Synthesize a final plan** that takes the best elements from each:
|
|
- Prefer the solution approach that the majority of models agree on
|
|
- Include all unique risks identified across the three plans
|
|
- If the models significantly disagree on approach, document all approaches in the investigation report and let a human decide
|
|
|
|
3. **Decide**:
|
|
- If at least 2 of 3 models agree and confidence is Medium or High → proceed to implementation
|
|
- If all 3 disagree or confidence is Low across the board → do NOT implement; document findings only
|
|
- If any model identifies a risk that the others missed and it is serious → pause and document
|
|
|
|
## Step 5: Implement (if plan is validated)
|
|
|
|
Based on your validated plan, determine the best path forward:
|
|
|
|
### If the fix or implementation is clear and contained:
|
|
- Implement the change using the `edit` tool
|
|
- Create a draft pull request linked to the issue using `create_pull_request`
|
|
- The PR title should reference the issue: `Fix #<number>: <brief description>`
|
|
- The PR body should include:
|
|
- `Fixes #<issue_number>` to auto-link
|
|
- A summary of what was changed and why
|
|
- Any testing considerations
|
|
- Add the label `auto-investigation-pr` to the PR
|
|
|
|
### If the fix is NOT clear or requires significant design decisions:
|
|
- Document your findings thoroughly
|
|
- Suggest 2-3 possible approaches with trade-offs
|
|
- Identify who should be consulted (from CODEOWNERS)
|
|
- List specific questions that need answers before proceeding
|
|
|
|
## Step 6: Post Investigation Report
|
|
|
|
Add a comment to the issue with your investigation results:
|
|
|
|
- Start with "**🔍 Issue Investigation**"
|
|
- **Summary**: 2-3 sentences on what you found
|
|
- **Root Cause** (if identified): explain the underlying problem
|
|
|
|
<details><summary>📂 Codebase Analysis</summary>
|
|
|
|
- Files examined and their relevance
|
|
- Code paths involved
|
|
- Related configuration or dependencies
|
|
|
|
</details>
|
|
|
|
<details><summary>🔗 Related Issues</summary>
|
|
|
|
- Links to related issues with brief explanation of relevance
|
|
|
|
</details>
|
|
|
|
<details><summary>📋 Recommended Next Steps</summary>
|
|
|
|
- Ordered list of specific, actionable steps
|
|
- If a PR was created, link to it
|
|
- If not, explain what is needed before a fix can be implemented
|
|
- Tag relevant owners from CODEOWNERS
|
|
|
|
</details>
|
|
|
|
## Important Guidelines
|
|
|
|
- Be thorough but focused — investigate the specific issue, do not go on tangents
|
|
- If you create a PR, keep the change minimal and well-scoped
|
|
- Do NOT make speculative changes — only implement fixes you are confident about
|
|
- Do NOT communicate directly with users outside of the issue comment
|
|
- If the issue is ambiguous, err on the side of documenting findings rather than implementing a potentially wrong fix
|