dotnet__skills/.github/workflows/issue-investigate.md

name, description, on, if, concurrency, jobs, engine, permissions, tools, safe-outputs, network, timeout-minutes

name	description	on	if	concurrency	jobs	engine	permissions	tools	safe-outputs	network	timeout-minutes
Issue Investigate	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.	issues steps types labeled uses name with actions/checkout@de0fac2e45 Checkout the select-copilot-pat action folder persist-credentials sparse-checkout sparse-checkout-cone-mode fetch-depth false .github/actions/select-copilot-pat true 1 id name uses env select-copilot-pat Select Copilot token from pool ./.github/actions/select-copilot-pat SECRET_0 SECRET_1 SECRET_2 SECRET_3 SECRET_4 SECRET_5 SECRET_6 SECRET_7 ${{ secrets.COPILOT_GITHUB_TOKEN }} ${{ secrets.COPILOT_GITHUB_TOKEN_2 }} ${{ secrets.COPILOT_GITHUB_TOKEN_3 }} ${{ secrets.COPILOT_GITHUB_TOKEN_4 }} ${{ secrets.COPILOT_GITHUB_TOKEN_5 }} ${{ secrets.COPILOT_GITHUB_TOKEN_6 }} ${{ secrets.COPILOT_GITHUB_TOKEN_7 }} ${{ secrets.COPILOT_GITHUB_TOKEN_8 }}	${{ github.event.label.name == 'auto-investigate' }}	group gh-aw-${{ github.workflow }}-${{ github.event.issue.number }}	pre-activation outputs copilot_pat_number ${{ steps.select-copilot-pat.outputs.copilot_pat_number }}	id env copilot 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) }}	contents issues pull-requests read read read	github bash edit toolsets repos issues pull_requests cat grep head tail find ls wc jq sort diff sed awk	add-comment create-pull-request add-labels max 2 max 1 max 3	allowed defaults	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

📂 Codebase Analysis

• Files examined and their relevance
• Code paths involved
• Related configuration or dependencies

🔗 Related Issues

• Links to related issues with brief explanation of relevance

📋 Recommended Next Steps

• 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

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