issue-triage

The user has received a GitHub Issue (bug report, question, feature request) and needs AI assistance to analyze the problem, determine whether to do it, and draft a reply. The AI leads the whole process, and the user only makes judgments at key points.

Core principles

Diagnose before speaking — do not draw conclusions without reading the code, and do not classify without finding the root cause
Be honest with users — if it is a bug, admit it; if it is an architectural limitation, say so clearly; neither shift blame nor make empty promises
Quantify the cost — "high cost" is not a conclusion; explain clearly where the cost is high: how many files to change, which modules are involved, and whether there are testing conditions
Provide alternatives — not doing it does not mean ignoring it; tell the user how to work around it for now

Workflow

Step 1: Obtain the Issue content

Goal: Get the complete information of the issue.

Method:

The user provides the issue link or repository address
Via gh issue view or WebFetch to obtain the issue details
Extract key information: user environment, reproduction steps, expected behavior, actual behavior, and the user's guesses

Output: Briefly relay the issue content to the user to confirm the understanding is correct.

Prohibited: Starting analysis after only looking at the title. You must read the full issue text.

Step 2: Code diagnosis

Goal: Find the root cause in the code.

Method:

Extract keywords from the issue description (feature name, error message, page name, etc.)
Locate the relevant chain in the code: from frontend entry → IPC call → backend processing → underlying implementation
Draw the complete call chain and annotate the file and line number of each step
Confirm the root cause: where the code went wrong, or why the code does not support the user's scenario

Output: Show the user:

The complete call chain (file + line number)
A one-sentence summary of the root cause
Attach key code snippets when necessary

Prohibited:

Guessing the cause without reading the code
Drawing conclusions after reading only one file (you must trace the entire chain)

Step 3: Classification

Goal: Determine which type this issue belongs to.

Type	Judgment criteria	Response strategy
Bug	Within the product design scope, behavior does not match expectations	Schedule a fix
Architectural limitation	The user's scenario exceeds the product's design premises	Explain the current situation and assess whether it is worth extending
Feature Request	The product itself is fine, but the user wants a new capability	Assess cost and priority
Usage issue	The user's way of operating is incorrect, but the product could be made more user-friendly	Reply with guidance and consider optimizing the experience

Key judgment: Distinguish between "should have been done but was done wrong" (bug) and "not intended to be done" (architectural limitation/feature).

Output: Explain the qualitative conclusion and reasoning to the user, and wait for the user to confirm before moving on.

Step 4: Decision (do it or not)

Goal: Based on the root cause and qualitative assessment, give a recommendation for whether to do it or not.

Assess four dimensions

Scope of change — change a few lines / change one module / add a new module
Blast radius — touch only one file / need to change the call chain across multiple files / need refactoring
Testing conditions — is there an environment to reproduce and verify (no environment = high risk)
User workaround cost — can the user solve it themselves in another way

Decision matrix

Scope of change	Has testing conditions	User can work around	Recommendation
Small (a few lines)	Yes	—	Fix directly
Medium (one module)	Yes	—	Schedule it
Large (new module/refactor)	Yes	No	Schedule after assessment
Large (new module/refactor)	No	Yes	Record the requirement, do not do it for now
Any	No	Yes	Inform of the workaround, record the requirement

Output: Explain the recommendation and reasoning to the user. If the recommendation is not to do it, quantify the cost (how many files to change, which modules are involved, why it cannot be tested).

After the user confirms the decision, proceed to the reply step.

Step 5: Draft the reply

Goal: Write a professional, appropriate, and informative issue reply.

Reply structure (three layers)

Explain the scenario positioning — what scenario this feature was designed for, so the user understands "why it is not currently supported"
Give the actual impact — for the user, how big the impact of not having this feature is, and whether there is an alternative
Explain the follow-up plan — if doing it, give a direction; if not, honestly explain the cost and reason

Tone principles

Thank them for the feedback — a user spending time filing an issue deserves respect
Do not shift blame — do not say "you used it wrong", say "we have not covered this scenario yet"
Give concrete suggestions — do not just say "no", tell the user what to do now
Quantify the cost — let the user understand it is not that we do not want to do it, but that the cost is objectively high

Reply template

Hi @{用户名}，感谢反馈！

**1. 功能定位**
{这个功能是为什么场景设计的，为什么当前不支持用户的场景}

**2. 对你的实际影响**
{用户现在能不能绕过，怎么绕过，核心功能是否受影响}

**3. 关于{用户期望的能力}**
{成本说明 + 后续计划}

Output: Reply draft, to be published after the user confirms.