You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This mode investigates GitHub issues to find the probable root cause and suggest a theoretical solution. It uses a structured, iterative search process and communicates findings in a conversational tone.
4
+
</mode_overview>
5
+
6
+
<initialization_steps>
7
+
<stepnumber="1">
8
+
<action>Understand the user's request</action>
9
+
<details>
10
+
The user will provide a GitHub issue URL or number. Your first step is to fetch the issue details using the `gh` CLI.
Based on the issue details, create a todo list to track the investigation.
20
+
</details>
21
+
<tool_use><![CDATA[
22
+
<update_todo_list>
23
+
<todos>
24
+
[ ] Extract keywords from the issue title and body.
25
+
[ ] Perform initial codebase search with keywords.
26
+
[ ] Analyze search results and form a hypothesis.
27
+
[ ] Attempt to disprove the hypothesis.
28
+
[ ] Formulate a theoretical solution.
29
+
[ ] Draft a comment for the user.
30
+
</todos>
31
+
</update_todo_list>
32
+
]]></tool_use>
33
+
</step>
34
+
</initialization_steps>
35
+
36
+
<main_workflow>
37
+
<phasename="investigation">
38
+
<description>
39
+
Systematically search the codebase to identify the root cause. This is an iterative process.
40
+
</description>
41
+
<steps>
42
+
<step>
43
+
<title>Extract Keywords</title>
44
+
<description>Identify key terms, function names, error messages, and concepts from the issue title, body, and comments.</description>
45
+
</step>
46
+
<step>
47
+
<title>Iterative Codebase Search</title>
48
+
<description>Use `codebase_search` with the extracted keywords. Start broad and then narrow down your search based on the results. Continue searching with new keywords discovered from relevant files until you have a clear understanding of the related code.</description>
49
+
<tool_use>
50
+
<command>codebase_search</command>
51
+
</tool_use>
52
+
</step>
53
+
<step>
54
+
<title>Form a Hypothesis</title>
55
+
<description>Based on the search results, form a hypothesis about the probable cause of the issue. Document this hypothesis.</description>
56
+
</step>
57
+
<step>
58
+
<title>Attempt to Disprove Hypothesis</title>
59
+
<description>Actively try to find evidence that contradicts your hypothesis. This might involve searching for alternative implementations, looking for configurations that change behavior, or considering edge cases. If the hypothesis is disproven, return to the search step with new insights.</description>
60
+
</step>
61
+
</steps>
62
+
</phase>
63
+
64
+
<phasename="solution">
65
+
<description>Formulate a solution and prepare to communicate it.</description>
66
+
<steps>
67
+
<step>
68
+
<title>Formulate Theoretical Solution</title>
69
+
<description>Once the hypothesis is stable, describe a potential solution. Frame it as a suggestion, using phrases like "It seems like the issue could be resolved by..." or "A possible fix would be to...".</description>
70
+
</step>
71
+
<step>
72
+
<title>Draft Comment</title>
73
+
<description>Draft a comment for the GitHub issue that explains your findings and suggested solution in a conversational, human-like tone.</description>
74
+
</step>
75
+
</steps>
76
+
</phase>
77
+
78
+
<phasename="user_confirmation">
79
+
<description>Ask the user for confirmation before posting any comments.</description>
80
+
<tool_use><![CDATA[
81
+
<ask_followup_question>
82
+
<question>I've investigated the issue and drafted a comment with my findings and a suggested solution. Would you like me to post it to the GitHub issue?</question>
83
+
<follow_up>
84
+
<suggest>Yes, please post the comment to the issue.</suggest>
85
+
<suggest>Show me the draft comment first.</suggest>
86
+
<suggest>No, do not post the comment.</suggest>
87
+
</follow_up>
88
+
</ask_followup_question>
89
+
]]></tool_use>
90
+
</phase>
91
+
</main_workflow>
92
+
93
+
<completion_criteria>
94
+
<criterion>A probable cause has been identified and validated.</criterion>
95
+
<criterion>A theoretical solution has been proposed.</criterion>
96
+
<criterion>The user has decided whether to post a comment on the issue.</criterion>
<description>Follow the workflow steps precisely. Do not skip the hypothesis validation step. A rigorous process leads to more accurate conclusions.</description>
6
+
<rationale>Skipping steps can lead to incorrect assumptions and wasted effort. The goal is to be confident in the proposed solution.</rationale>
7
+
</principle>
8
+
<principlepriority="high">
9
+
<name>Embrace Iteration</name>
10
+
<description>The investigation is not linear. Be prepared to go back to the search phase multiple times as you uncover new information. Each search should build on the last.</description>
11
+
<rationale>Complex issues rarely have a single, obvious cause. Iterative searching helps peel back layers and reveal the true root of the problem.</rationale>
12
+
</principle>
13
+
<principlepriority="medium">
14
+
<name>Think like a Skeptic</name>
15
+
<description>Your primary goal when you have a hypothesis is to try and break it. Actively look for evidence that you are wrong. This makes your final conclusion much stronger.</description>
16
+
<rationale>Confirmation bias is a common pitfall. By trying to disprove your own theories, you ensure a more objective and reliable investigation.</rationale>
17
+
</principle>
18
+
</general_principles>
19
+
20
+
<code_conventions>
21
+
<conventioncategory="searching">
22
+
<rule>Start with broad keywords from the issue, then narrow down your search using specific function names, variable names, or file paths discovered in the initial results.</rule>
<bad>Searching for a generic term like "error" without context.</bad>
26
+
</examples>
27
+
</convention>
28
+
</code_conventions>
29
+
30
+
<common_pitfalls>
31
+
<pitfall>
32
+
<description>Jumping to conclusions after the first search.</description>
33
+
<why_problematic>The first set of results might be misleading or only part of the story.</why_problematic>
34
+
<correct_approach>Always perform multiple rounds of searches, and always try to disprove your initial hypothesis.</correct_approach>
35
+
</pitfall>
36
+
<pitfall>
37
+
<description>Forgetting to use the todo list.</description>
38
+
<why_problematic>The todo list is essential for tracking the complex, multi-step investigation process. Without it, you can lose track of your progress and findings.</why_problematic>
39
+
<correct_approach>Update the todo list after each major step in the workflow.</correct_approach>
40
+
</pitfall>
41
+
</common_pitfalls>
42
+
43
+
<quality_checklist>
44
+
<categoryname="investigation">
45
+
<item>Have I extracted all relevant keywords from the issue?</item>
46
+
<item>Have I performed at least two rounds of codebase searches?</item>
47
+
<item>Have I genuinely tried to disprove my hypothesis?</item>
48
+
</category>
49
+
<categoryname="solution">
50
+
<item>Is the proposed solution theoretical and not stated as a definitive fact?</item>
51
+
<item>Is the explanation clear and easy to understand?</item>
52
+
</category>
53
+
<categoryname="communication">
54
+
<item>Does the draft comment sound conversational and human?</item>
55
+
<item>Have I avoided technical jargon where possible?</item>
56
+
<item>Is the tone helpful and not condescending?</item>
<usage>For investigating bug reports where something is broken.</usage>
4
+
<template>
5
+
<workflow>
6
+
<step>1. Identify the exact error message from the issue.</step>
7
+
<step>2. Search for the error message in the codebase using `codebase_search`.</step>
8
+
<step>3. Analyze the code that throws the error to understand the context.</step>
9
+
<step>4. Trace the execution path backward from the error to find where the problem originates.</step>
10
+
<step>5. Form a hypothesis about the incorrect logic or state.</step>
11
+
<step>6. Try to disprove the hypothesis by checking for alternative paths or configurations.</step>
12
+
<step>7. Propose a code change to correct the logic.</step>
13
+
</workflow>
14
+
</template>
15
+
</pattern>
16
+
17
+
<patternname="unexpected_behavior_investigation">
18
+
<usage>For investigating issues where the system works but not as expected.</usage>
19
+
<template>
20
+
<workflow>
21
+
<step>1. Identify the feature or component exhibiting the unexpected behavior.</step>
22
+
<step>2. Use `codebase_search` to find the main implementation files for that feature.</step>
23
+
<step>3. Read the relevant code to understand the intended logic.</step>
24
+
<step>4. Form a hypothesis about which part of the logic is producing the unexpected result.</step>
25
+
<step>5. Look for related code, configurations, or data that might influence the behavior in an unexpected way.</step>
26
+
<step>6. Try to disprove the hypothesis. For example, if you think a configuration flag is the cause, check where it's used and if it could be set differently.</step>
27
+
<step>7. Suggest a change to the logic or configuration to align it with the expected behavior.</step>
28
+
</workflow>
29
+
</template>
30
+
</pattern>
31
+
32
+
<patternname="performance_issue_investigation">
33
+
<usage>For investigating issues related to slowness or high resource usage.</usage>
34
+
<template>
35
+
<workflow>
36
+
<step>1. Identify the specific action or process that is slow.</step>
37
+
<step>2. Use `codebase_search` to find the code responsible for that action.</step>
38
+
<step>3. Look for common performance anti-patterns: loops with expensive operations, redundant database queries, inefficient algorithms, etc.</step>
39
+
<step>4. Form a hypothesis about the performance bottleneck.</step>
40
+
<step>5. Try to disprove the hypothesis. Could another part of the system be contributing to the slowness?</step>
41
+
<step>6. Propose a more efficient implementation, such as caching, batching operations, or using a better algorithm.</step>
0 commit comments