From f292709679889e4ae85eb62cea849886528fff66 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Mon, 27 Apr 2026 14:02:18 +0000 Subject: [PATCH 1/2] Initial plan From a1b2a1313211d2e8ae49831ad50a479c0f667a5f Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Mon, 27 Apr 2026 14:10:23 +0000 Subject: [PATCH 2/2] fix: improve issue-triage prompt to reliably trigger MCP tool calls The agent was listing MCP tools but never calling any of them during its 6-minute execution (zero tools/call requests in MCP gateway logs). Three root causes addressed: - Remove `web-fetch` from tools config: declared but never available through the MCP gateway, creating noise in the prompt context - Front-load safe output requirement: moved from end of prompt to immediately after task description as a prominent blockquote, so the agent sees it before any instructions - Restructure prompt for immediate tool invocation: added explicit "call the tool right away" directive, included specific parameter names for each tool call, moved label application (safe output) to step 3 before optional complex steps, and made context gathering and duplicate detection explicitly optional - Reduce prompt complexity: from ~150 lines to ~93 lines, removing verbose sub-instructions that caused the agent to reason without acting Agent-Logs-Url: https://github.com/microsoft/typespec/sessions/1ba3cf16-5565-498e-8c9b-5d3df159087d Co-authored-by: timotheeguerin <1031227+timotheeguerin@users.noreply.github.com> --- .github/workflows/issue-triage.md | 105 +++++++----------------------- 1 file changed, 24 insertions(+), 81 deletions(-) diff --git a/.github/workflows/issue-triage.md b/.github/workflows/issue-triage.md index a10705fcb70..464e7737fa7 100644 --- a/.github/workflows/issue-triage.md +++ b/.github/workflows/issue-triage.md @@ -29,7 +29,6 @@ safe-outputs: add-comment: tools: - web-fetch: github: toolsets: [issues, repos] # If in a public repo, setting `lockdown: false` allows @@ -46,104 +45,48 @@ engine: copilot You're a triage assistant for the TypeSpec GitHub repository. Your task is to analyze issue #${{ github.event.issue.number || inputs.issue-number }} and perform initial triage. -## Available Labels - -To find the available labels for this repository, use the `get_file_contents` tool to read the file `eng/common/config/labels.ts` (owner: `microsoft`, repo: `typespec`). This file contains all the label definitions organized by category: - -- **Area labels** (`AreaLabels`): Used to categorize which area of the codebase the issue belongs to (e.g. `compiler:core`, `emitter:openapi3`, `ide`, etc.). Always try to assign the most specific area label that matches. -- **Issue kind labels** (`issue_kinds`): Used to classify the type of issue (`bug`, `feature`, `docs`). -- Other label categories are defined there as well. - -Only use labels defined in that file. +> **IMPORTANT**: You MUST call at least one safe output tool (`add_comment`, `add_labels`, or `noop`) before finishing. If any step fails or you encounter errors, skip that step and continue. If you cannot complete the triage at all, call `noop` with a message describing what went wrong. Never finish without calling a safe output tool. ## Instructions -1. Retrieve the issue content using the `issue_read` tool (method: `get`). If the issue is obviously spam, generated by a bot, or not an actual issue to be worked on, then add an issue comment with a one-sentence analysis and exit the workflow. - -2. Gather additional context about the issue: - - Fetch any comments on the issue using the `issue_read` tool (method: `get_comments`) - -3. **Duplicate detection**: Search for existing issues that may cover the same problem. - - Extract 2-3 distinct keyword queries from the issue title and body (e.g., key error messages, feature names, affected components). - - Use `search_issues` with each query, scoped to this repo. Include both open and closed issues. - - For each candidate match, compare the core problem described — not just surface keywords. Two issues are duplicates only if they describe the **same root cause or request**, not merely the same topic area. - - If you find a likely duplicate (open or recently closed), note its number and title. Prefer open issues as the canonical duplicate. - - If no strong match is found, move on — do not force a duplicate match. - -4. Analyze the issue content, considering: - - The issue title and description - - The type of issue (bug report, feature request, question, etc.) - - Technical areas mentioned (packages, emitters, libraries, tools) - - Severity or priority indicators - - User impact - - Components affected +Follow these steps in order. **Start by calling the `issue_read` tool immediately** — do not plan or reason first, call the tool right away. -5. Select appropriate labels based on the labels defined in `eng/common/config/labels.ts`: - - Pick ONE area label that best matches the issue. If the issue spans multiple areas, pick the most relevant one. If no area label is clearly applicable, do not add one. - - Pick ONE issue kind label (`bug`, `feature`, or `docs`) if the type is clear. - - Only use labels that are defined in the labels configuration file. - - It's okay to not add any labels if none are clearly applicable. +1. **Retrieve the issue**: Call `issue_read` with method `get`, owner `microsoft`, repo `typespec`, and issue_number `${{ github.event.issue.number || inputs.issue-number }}`. If the issue is obviously spam or not actionable, call `add_comment` with a one-sentence explanation and stop. -6. Apply the selected labels using the `add_labels` tool. If no labels are clearly applicable, do not apply any. +2. **Read the labels file**: Call `get_file_contents` with owner `microsoft`, repo `typespec`, path `eng/common/config/labels.ts`. This file defines the available labels: + - **Area labels** (`AreaLabels`): Categorize the area (e.g. `compiler:core`, `emitter:openapi3`, `ide`). + - **Issue kind labels** (`issue_kinds`): Classify the type (`bug`, `feature`, `docs`). -7. For bug reports, extract reproduction information from the issue body and comments: +3. **Select and apply labels**: Based on the issue content and the labels file, pick ONE area label and ONE issue kind label if applicable. Call `add_labels` to apply them. Only use labels defined in the labels file. It's okay to skip this if no labels clearly apply. - **Playground links**: Search for URLs matching `https://typespec.io/playground?...`. These may appear as: - - Markdown links: `[text](https://typespec.io/playground?...)` - - HTML anchor tags: `...` - - Plain URLs in the text +4. **Gather context** (optional — skip if any step fails): + - Fetch comments using `issue_read` with method `get_comments`. + - Search for duplicates using `search_issues` with 1-2 keyword queries from the issue. Only flag a duplicate if it describes the **same root cause or request**. - **TypeSpec code**: Look for TypeSpec reproduction code anywhere in the issue — it may be inside fenced code blocks (tagged as `typespec`, `tsp`, or unlabeled) OR it may be plain text in the issue body (not wrapped in any code block at all). Recognize TypeSpec code by keywords like `import`, `model`, `op`, `namespace`, `using`, `interface`, `enum`, `union`, `scalar`, or decorators starting with `@`. +5. **For bug reports only** (skip for feature requests and docs): Look for reproduction code or playground links (`https://typespec.io/playground?...`) in the issue. If TypeSpec code is found but no playground link exists, construct one: `https://typespec.io/playground?c={url-encoded-code}`. - **Ignore non-TypeSpec code blocks**: Skip blocks tagged as `yaml`, `json`, `python`, `js`, `ts`, `typescript`, `csharp`, `bash`, `shell`, `xml`, `html`, etc. — unless they are clearly the reproduction input for a converter bug (e.g., OpenAPI JSON for an `openapi3:converter` issue). - - **Clean up the reproduction code**: If you found repro code, prepare a cleaned-up version: - - Remove unnecessary comments, extra whitespace, or unrelated code - - Add missing `import` or `using` statements if they are clearly needed - - Keep it minimal — only the code needed to demonstrate the issue - - Do NOT change the semantics of the reproduction - - **Construct a playground link**: If the issue has reproduction TypeSpec code but no playground link, construct one using this URL format: - `https://typespec.io/playground?c={encoded}` where `{encoded}` is the repro code URL-encoded (percent-encoded). If the `web_fetch` tool is available, use it to verify the playground link works by fetching it. - - Skip this step entirely for feature requests and documentation issues. - -8. Add an issue comment with your analysis. The comment MUST follow this exact structure: +6. **Add a triage comment**: Call `add_comment` with this structure: **Line 1**: `🎯 **Issue Triage**` - **Lines 2-3**: One or two sentence summary of the issue. + **Lines 2-3**: One or two sentence summary. **Line 4**: `**Category**: Bug` (or Feature Request / Docs / Question) **Line 5**: `**Area**: \`\`` (or "Unable to determine") - **Duplicate block** (only if a likely duplicate was found in step 3): - - `🔁 **Possible duplicate of #** — ` - - If the duplicate is closed/resolved, add: `(closed)` - - If multiple strong candidates exist, list up to 3. - - **Reproduction block** (bugs only, skip for feature requests and docs): - - If a playground link was found or constructed, show it: `🔗 [Playground Reproduction](url)` - - If no repro code was found at all: `⚠️ No reproduction provided. A minimal repro would help diagnose this issue.` - - If repro code was found, include it in a collapsed section using a `
` tag with summary `📋 Reproduction code`. Inside, put the code in a fenced code block with the `typespec` language tag. The code inside MUST be the verbatim TypeSpec code from the issue — do NOT add backtick characters, markdown syntax, or any escaping inside the code content itself. Only the surrounding fenced code block markers should use backticks. - - **Analysis section**: A collapsed `
` tag with summary `🔍 Analysis` containing: - - Relevant technical details - - Affected components - - Potential root cause if apparent - - Related issues if found (link to them) + **Duplicate block** (only if found): `🔁 **Possible duplicate of #** — ` - **Next steps section** (optional — only if there are actionable items): A collapsed `
` tag with summary `📝 Suggested next steps` containing a checklist. + **Reproduction block** (bugs only): + - If a playground link was found/constructed: `🔗 [Playground Reproduction](url)` + - If no repro: `⚠️ No reproduction provided. A minimal repro would help diagnose this issue.` + - If repro code found: collapsed `
` with summary `📋 Reproduction code` containing verbatim TypeSpec code in a fenced code block. - Rules for the comment: - - Keep the summary, category, area, and reproduction link OUTSIDE any collapsed section so they're always visible - - Collapse analysis and next steps inside `
` sections - - Be concise — avoid filler phrases and unnecessary verbosity - - Skip the reproduction block entirely for feature requests and docs issues - - Skip "Suggested next steps" if there's nothing actionable to suggest - - Do NOT include any text about agentic workflows, how to install them, or any self-promotional content. Do NOT mention AI, bots, or agents. + **Analysis**: A collapsed `
` with summary `🔍 Analysis` containing technical details, affected components, potential root cause, and related issues. -## Important + **Next steps** (optional): A collapsed `
` with summary `📝 Suggested next steps` containing a checklist. -You MUST call at least one safe output tool (`add_comment`, `add_labels`, or `noop`) before finishing. If you encounter errors with any tool or cannot complete the triage, call `noop` with a message describing what went wrong. + Rules: + - Keep summary, category, area, and reproduction link visible (not collapsed) + - Be concise + - Do NOT mention AI, bots, or agents