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>
<expected_outcome>Get the title "Login fails silently" and body "Users with valid credentials are not able to log in. The page just refreshes without any error message."</expected_outcome>
20
+
</step>
21
+
22
+
<stepnumber="2">
23
+
<description>Create the initial investigation plan.</description>
24
+
<tool_use><![CDATA[
25
+
<update_todo_list>
26
+
<todos>
27
+
[x] Extract keywords from the issue title and body.
28
+
[-] Perform initial codebase search with keywords.
29
+
[ ] Analyze search results and form a hypothesis.
30
+
[ ] Attempt to disprove the hypothesis.
31
+
[ ] Formulate a theoretical solution.
32
+
[ ] Draft a comment for the user.
33
+
</todos>
34
+
</update_todo_list>
35
+
]]></tool_use>
36
+
</step>
37
+
38
+
<stepnumber="3">
39
+
<description>Perform initial codebase search using keywords "login", "authentication", "silent fail".</description>
<analysis>The search results point to `src/auth/login.ts` as a highly relevant file.</analysis>
46
+
</step>
47
+
48
+
<stepnumber="4">
49
+
<description>Read the contents of the relevant file.</description>
50
+
<tool_use><![CDATA[
51
+
<read_file>
52
+
<path>src/auth/login.ts</path>
53
+
</read_file>
54
+
]]></tool_use>
55
+
<analysis>
56
+
The file contains a `try...catch` block in the `handleLogin` function. The `catch` block is empty, which explains the silent failure. This is the likely cause. Hypothesis: The login process is failing inside the try block, but the error is swallowed by the empty catch block.
57
+
</analysis>
58
+
</step>
59
+
60
+
<stepnumber="5">
61
+
<description>Attempt to disprove the hypothesis by looking for other error handling mechanisms.</description>
<analysis>No global error handling middleware seems to be in use that would override this local empty catch block. The hypothesis stands.</analysis>
68
+
</step>
69
+
70
+
<stepnumber="6">
71
+
<description>Formulate a solution and draft a comment.</description>
72
+
<draft>
73
+
"Hey, I took a look at this issue and it seems like the problem is in the `handleLogin` function in `src/auth/login.ts`. There's an empty `try...catch` block that is likely catching the login error and preventing any message from being shown to the user.
74
+
75
+
A good first step to fixing this would be to add some logging to the `catch` block to see what error is actually happening. Then, we should probably implement proper error feedback to the user on the login page. This should solve the issue of the silent failure."
76
+
</draft>
77
+
</step>
78
+
79
+
<stepnumber="7">
80
+
<description>Ask the user for confirmation before posting the comment.</description>
81
+
<tool_use><![CDATA[
82
+
<ask_followup_question>
83
+
<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>
84
+
<follow_up>
85
+
<suggest>Yes, please post the comment to the issue.</suggest>
86
+
<suggest>Show me the draft comment first.</suggest>
87
+
<suggest>No, do not post the comment.</suggest>
88
+
</follow_up>
89
+
</ask_followup_question>
90
+
]]></tool_use>
91
+
</step>
92
+
</workflow>
93
+
94
+
<key_takeaways>
95
+
<takeaway>Empty catch blocks are a strong indicator of silent failures.</takeaway>
96
+
<takeaway>Always try to disprove a hypothesis by looking for conflicting code patterns.</takeaway>
0 commit comments