Skip to content

Commit debcbd5

Browse files
pashpashpashCline Evaluation
pashpashpash
and
Cline Evaluation
authored
* pr-review workflow * docs * at mentions * titles --------- Co-authored-by: Cline Evaluation <[email protected]>
1 parent 6938809 commit debcbd5

File tree

11 files changed

+996
-29
lines changed

11 files changed

+996
-29
lines changed

‎.clinerules/workflows/pr-review.md‎

Lines changed: 351 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,351 @@
1+
You have access to the `gh` terminal command. I already authenticated it for you. Please review it to use the PR that I asked you to review. You're already in the `cline` repo.
2+
3+
<detailed_sequence_of_steps>
4+
# GitHub PR Review Process - Detailed Sequence of Steps
5+
6+
## 1. Gather PR Information
7+
1. Get the PR title, description, and comments:
8+
```bash
9+
gh pr view <PR-number> --json title,body,comments
10+
```
11+
12+
2. Get the full diff of the PR:
13+
```bash
14+
gh pr diff <PR-number>
15+
```
16+
17+
## 2. Understand the Context
18+
1. Identify which files were modified in the PR:
19+
```bash
20+
gh pr view <PR-number> --json files
21+
```
22+
23+
2. Examine the original files in the main branch to understand the context:
24+
```xml
25+
<read_file>
26+
<path>path/to/file</path>
27+
</read_file>
28+
```
29+
30+
3. For specific sections of a file, you can use search_files:
31+
```xml
32+
<search_files>
33+
<path>path/to/directory</path>
34+
<regex>search term</regex>
35+
<file_pattern>*.ts</file_pattern>
36+
</search_files>
37+
```
38+
39+
## 3. Analyze the Changes
40+
1. For each modified file, understand:
41+
- What was changed
42+
- Why it was changed (based on PR description)
43+
- How it affects the codebase
44+
- Potential side effects
45+
46+
2. Look for:
47+
- Code quality issues
48+
- Potential bugs
49+
- Performance implications
50+
- Security concerns
51+
- Test coverage
52+
53+
## 4. Ask for User Confirmation
54+
1. Before making a decision, ask the user if you should approve the PR, providing your assessment and justification:
55+
```xml
56+
<ask_followup_question>
57+
<question>Based on my review of PR #<PR-number>, I recommend [approving/requesting changes]. Here's my justification:
58+
59+
[Detailed justification with key points about the PR quality, implementation, and any concerns]
60+
61+
Would you like me to proceed with this recommendation?</question>
62+
<options>["Yes, approve the PR", "Yes, request changes", "No, I'd like to discuss further"]</options>
63+
</ask_followup_question>
64+
```
65+
66+
## 5. Ask if User Wants a Comment Drafted
67+
1. After the user decides on approval/rejection, ask if they would like a comment drafted:
68+
```xml
69+
<ask_followup_question>
70+
<question>Would you like me to draft a comment for this PR that you can copy and paste?</question>
71+
<options>["Yes, please draft a comment", "No, I'll handle the comment myself"]</options>
72+
</ask_followup_question>
73+
```
74+
75+
2. If the user wants a comment drafted, provide a well-structured comment they can copy:
76+
```
77+
Thank you for this PR! Here's my assessment:
78+
79+
[Detailed assessment with key points about the PR quality, implementation, and any suggestions]
80+
81+
[Include specific feedback on code quality, functionality, and testing]
82+
```
83+
84+
## 6. Make a Decision
85+
1. Approve the PR if it meets quality standards:
86+
```bash
87+
# For single-line comments:
88+
gh pr review <PR-number> --approve --body "Your approval message"
89+
90+
# For multi-line comments with proper whitespace formatting:
91+
cat << EOF | gh pr review <PR-number> --approve --body-file -
92+
Thanks @username for this PR! The implementation looks good.
93+
94+
I particularly like how you've handled X and Y.
95+
96+
Great work!
97+
EOF
98+
```
99+
100+
2. Request changes if improvements are needed:
101+
```bash
102+
# For single-line comments:
103+
gh pr review <PR-number> --request-changes --body "Your feedback message"
104+
105+
# For multi-line comments with proper whitespace formatting:
106+
cat << EOF | gh pr review <PR-number> --request-changes --body-file -
107+
Thanks @username for this PR!
108+
109+
The implementation looks promising, but there are a few things to address:
110+
111+
1. Issue one
112+
2. Issue two
113+
114+
Please make these changes and we can merge this.
115+
EOF
116+
```
117+
118+
Note: The `cat << EOF | ... --body-file -` approach preserves all whitespace and formatting without requiring temporary files. The `-` parameter tells the command to read from standard input.
119+
</detailed_sequence_of_steps>
120+
121+
<example_review_process>
122+
# Example PR Review Process
123+
124+
Let's walk through a real example of reviewing PR #3627 which fixes the thinking mode calculation for Claude 3.7 models.
125+
126+
## Step 1: Gather PR Information
127+
128+
```bash
129+
# Get PR details
130+
gh pr view 3627 --json title,body,comments
131+
132+
# Get the full diff
133+
gh pr diff 3627
134+
```
135+
136+
## Step 2: Understand the Context
137+
138+
```xml
139+
# Examine the original files to understand what's being changed
140+
<read_file>
141+
<path>src/shared/api.ts</path>
142+
</read_file>
143+
144+
# Look at the ThinkingBudgetSlider component implementation
145+
<read_file>
146+
<path>webview-ui/src/components/settings/ThinkingBudgetSlider.tsx</path>
147+
</read_file>
148+
149+
# Check how thinking mode is currently handled in API providers
150+
<search_files>
151+
<path>src/api/providers</path>
152+
<regex>reasoningOn</regex>
153+
<file_pattern>*.ts</file_pattern>
154+
</search_files>
155+
```
156+
157+
## Step 3: Analyze the Changes
158+
159+
From the PR information and code examination, we can see that:
160+
161+
1. The PR fixes an issue with the thinking mode budget calculation for Claude 3.7 models
162+
2. Currently, the thinking budget is incorrectly calculated as 80% of maxTokens (8192), resulting in 6553 tokens
163+
3. Claude 3.7 actually supports a much larger thinking budget (up to 64000 tokens)
164+
4. The PR adds a `thinkingConfig` property with `maxBudget: 64000` to model definitions
165+
5. It updates API handlers to use this value when reasoning mode is enabled
166+
6. It enhances the slider component to calculate max values based on model-specific percentages
167+
7. Comprehensive tests were added to verify the calculations
168+
169+
## Step 4: Ask for User Confirmation
170+
171+
```xml
172+
<ask_followup_question>
173+
<question>Based on my review of PR #3627, I recommend approving this PR. Here's my justification:
174+
175+
1. The PR correctly fixes the thinking mode budget calculation for Claude 3.7 models
176+
2. It properly implements the thinkingConfig.maxBudget property (64000) for Claude 3.7 models
177+
3. It applies the appropriate percentage (50%) for the slider calculation
178+
4. The changes are well-tested with comprehensive unit tests
179+
5. The implementation is clean and follows the project's coding standards
180+
6. The PR includes helpful screenshots demonstrating the fix
181+
182+
Would you like me to proceed with approving this PR?</question>
183+
<options>["Yes, approve the PR", "No, I'd like to discuss further", "Let me review it myself first"]</options>
184+
</ask_followup_question>
185+
```
186+
187+
## Step 5: Ask if User Wants a Comment Drafted
188+
189+
```xml
190+
<ask_followup_question>
191+
<question>Would you like me to draft a comment for this PR that you can copy and paste?</question>
192+
<options>["Yes, please draft a comment", "No, I'll handle the comment myself"]</options>
193+
</ask_followup_question>
194+
```
195+
196+
## Step 6: Make a Decision
197+
198+
```bash
199+
# Option 1: Simple one-line comment
200+
gh pr review 3627 --approve --body "This PR looks good! It correctly fixes the thinking mode budget calculation for Claude 3.7 models."
201+
202+
# Option 2: Multi-line comment with proper whitespace formatting
203+
cat << EOF | gh pr review 3627 --approve --body-file -
204+
This PR looks good! It correctly fixes the thinking mode budget calculation for Claude 3.7 models.
205+
206+
I particularly like:
207+
1. The proper implementation of thinkingConfig.maxBudget property (64000)
208+
2. The appropriate percentage (50%) for the slider calculation
209+
3. The comprehensive unit tests
210+
4. The clean implementation that follows project coding standards
211+
212+
Great work!
213+
EOF
214+
```
215+
</example_review_process>
216+
217+
<common_gh_commands>
218+
# Common GitHub CLI Commands for PR Review
219+
220+
## Basic PR Commands
221+
```bash
222+
# List open PRs
223+
gh pr list
224+
225+
# View a specific PR
226+
gh pr view <PR-number>
227+
228+
# View PR with specific fields
229+
gh pr view <PR-number> --json title,body,comments,files,commits
230+
231+
# Check PR status
232+
gh pr status
233+
```
234+
235+
## Diff and File Commands
236+
```bash
237+
# Get the full diff of a PR
238+
gh pr diff <PR-number>
239+
240+
# List files changed in a PR
241+
gh pr view <PR-number> --json files
242+
243+
# Check out a PR locally
244+
gh pr checkout <PR-number>
245+
```
246+
247+
## Review Commands
248+
```bash
249+
# Approve a PR (single-line comment)
250+
gh pr review <PR-number> --approve --body "Your approval message"
251+
252+
# Approve a PR (multi-line comment with proper whitespace)
253+
cat << EOF | gh pr review <PR-number> --approve --body-file -
254+
Your multi-line
255+
approval message with
256+
257+
proper whitespace formatting
258+
EOF
259+
260+
# Request changes on a PR (single-line comment)
261+
gh pr review <PR-number> --request-changes --body "Your feedback message"
262+
263+
# Request changes on a PR (multi-line comment with proper whitespace)
264+
cat << EOF | gh pr review <PR-number> --request-changes --body-file -
265+
Your multi-line
266+
change request with
267+
268+
proper whitespace formatting
269+
EOF
270+
271+
# Add a comment review (without approval/rejection)
272+
gh pr review <PR-number> --comment --body "Your comment message"
273+
274+
# Add a comment review with proper whitespace
275+
cat << EOF | gh pr review <PR-number> --comment --body-file -
276+
Your multi-line
277+
comment with
278+
279+
proper whitespace formatting
280+
EOF
281+
```
282+
283+
## Additional Commands
284+
```bash
285+
# View PR checks status
286+
gh pr checks <PR-number>
287+
288+
# View PR commits
289+
gh pr view <PR-number> --json commits
290+
291+
# Merge a PR (if you have permission)
292+
gh pr merge <PR-number> --merge
293+
```
294+
</common_gh_commands>
295+
296+
<general_guidelines_for_commenting>
297+
When reviewing a PR, please talk normally and like a friendly reviwer. You should keep it short, and start out by thanking the author of the pr and @ mentioning them.
298+
299+
Whether or not you approve the PR, you should then give a quick summary of the changes without being too verbose or definitive, staying humble like that this is your understanding of the changes. Kind of how I'm talking to you right now.
300+
301+
If you have any suggestions, or things that need to be changed, request changes instead of approving the PR.
302+
303+
Leaving inline comments in code is good, but only do so if you have something specific to say about the code. And make sure you leave those comments first, and then request changes in the PR with a short comment explaining the overall theme of what you're asking them to change.
304+
</general_guidelines_for_commenting>
305+
306+
<example_comments_that_i_have_written_before>
307+
<brief_approve_comment>
308+
Looks good, though we should make this generic for all providers & models at some point
309+
</brief_approve_comment>
310+
<brief_approve_comment>
311+
Will this work for models that may not match across OR/Gemini? Like the thinking models?
312+
</brief_approve_comment>
313+
<approve_comment>
314+
This looks great! I like how you've handled the global endpoint support - adding it to the ModelInfo interface makes total sense since it's just another capability flag, similar to how we handle other model features.
315+
316+
The filtered model list approach is clean and will be easier to maintain than hardcoding which models work with global endpoints. And bumping the genai library was obviously needed for this to work.
317+
318+
Thanks for adding the docs about the limitations too - good for users to know they can't use context caches with global endpoints but might get fewer 429 errors.
319+
</approve_comment>
320+
<requesst_changes_comment>
321+
This is awesome. Thanks @scottsus.
322+
323+
My main concern though - does this work for all the possible VS Code themes? We struggled with this initially which is why it's not super styled currently. Please test and share screenshots with the different themes to make sure before we can merge
324+
</request_changes_comment>
325+
<request_changes_comment>
326+
Hey, the PR looks good overall but I'm concerned about removing those timeouts. Those were probably there for a reason - VSCode's UI can be finicky with timing.
327+
328+
Could you add back the timeouts after focusing the sidebar? Something like:
329+
330+
```typescript
331+
await vscode.commands.executeCommand("claude-dev.SidebarProvider.focus")
332+
await setTimeoutPromise(100) // Give UI time to update
333+
visibleWebview = WebviewProvider.getSidebarInstance()
334+
```
335+
</request_changes_comment>
336+
<request_changes_comment>
337+
Heya @alejandropta thanks for working on this!
338+
339+
A few notes:
340+
1 - Adding additional info to the environment variables is fairly problematic because env variables get appended to **every single message**. I don't think this is justifiable for a somewhat niche use case.
341+
2 - Adding this option to settings to include that could be an option, but we want our options to be simple and straightforward for new users
342+
3 - We're working on revisualizing the way our settings page is displayed/organized, and this could potentially be reconciled once that is in and our settings page is more clearly delineated.
343+
344+
So until the settings page is update, and this is added to settings in a way that's clean and doesn't confuse new users, I don't think we can merge this. Please bear with us.
345+
</request_changes_comment>
346+
<request_changes_comment>
347+
Also, don't forget to add a changeset since this fixes a user-facing bug.
348+
349+
The architectural change is solid - moving the focus logic to the command handlers makes sense. Just don't want to introduce subtle timing issues by removing those timeouts.
350+
</request_changes_comment>
351+
</example_comments_that_i_have_written_before>

‎docs/docs.json‎

Lines changed: 12 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -74,6 +74,7 @@
7474
{
7575
"group": "Features",
7676
"pages": [
77+
"features/plan-and-act",
7778
"features/cline-rules",
7879
"features/slash-commands/workflows",
7980
{
@@ -84,14 +85,24 @@
8485
"features/slash-commands/smol",
8586
"features/slash-commands/report-bug"
8687
]
88+
},
89+
{
90+
"group": "@ Mentions",
91+
"pages": [
92+
"features/at-mentions/overview",
93+
"features/at-mentions/file-mentions",
94+
"features/at-mentions/terminal-mentions",
95+
"features/at-mentions/problem-mentions",
96+
"features/at-mentions/git-mentions",
97+
"features/at-mentions/url-mentions"
98+
]
8799
}
88100
]
89101
},
90102
{
91103
"group": "Exploring Cline's Tools",
92104
"pages": [
93105
"exploring-clines-tools/cline-tools-guide",
94-
"exploring-clines-tools/plan-and-act-modes-a-guide-to-effective-ai-development",
95106
"exploring-clines-tools/checkpoints",
96107
"exploring-clines-tools/new-task-tool",
97108
"exploring-clines-tools/remote-browser-support",

0 commit comments

Comments
 (0)