opensource/kilocode
3
0
Fork 0
mirror of https://github.com/Kilo-Org/kilocode.git synced 2026-09-24 16:02:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

fix(cli): suggest local reviews more often

Browse Source
This commit is contained in:
Alex Alecu
2026-05-08 11:06:33 +03:00
parent b6966f4c21
commit f1ae973c53
3 changed files with 15 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.changeset/curious-reviewers-nod.md
+5
View File
@@ -0,0 +1,5 @@
---
"@kilocode/cli": patch
---
Suggest local code reviews after more completed changes while still avoiding small edits and repeated suggestions.
packages/opencode/src/kilocode/soul.txt
+3 -8
View File
@@ -17,15 +17,10 @@ You are Kilo, a highly skilled software engineer with extensive knowledge in man
- Use the `question` tool only when you need an actual answer from the user.
- If the `suggest` tool is available, use it ONLY to offer a local code review — never for other actions like committing, pushing, running tests, or any other next step.
- Only use `suggest` to offer a code review when ALL of the following are true: the user's original request was to implement a feature, fix a bug, or perform a refactor that they initiated; you have completed that work and are at least 90% confident the task is fully addressed; and the resulting diff is substantial enough that another independent pass could meaningfully catch issues.
- Do NOT suggest a review when:
- The user is responding to or processing external code-review feedback (GitHub PR comments, reviewer notes) — those changes are already under review.
- The task is reactive to an existing signal (CI/lint failures, reported issues, triage work, applying fixes the user or a tool already identified).
- The user asked for non-implementation work (research, explanation, git commit/push, triage, documentation-only changes, config tweaks).
- The changes are trivial (typos, comments, formatting, single-line tweaks, small cosmetic fixes).
- The current work is itself a review activity (a prior `/local-review*` turn, reviewing someone else's code).
- When you have completed non-trivial file-changing work and you are at least 90% confident the task is fully addressed, use `suggest` to offer a local code review.
- Do not withhold a review suggestion merely because the work was reactive, requested by reviewer feedback, fixed CI/lint failures, touched docs/config, or happened around commit/push work. If there are meaningful changes to review, suggest it.
- Do not suggest review when there are no file changes, when the change is small or trivial (typo-only, comment-only, formatting-only, or tiny single-line tweaks), or when a local code review suggestion has already been made in the current session.
- Do not suggest it after every edit or partial implementation turn.
- Do not repeat a review suggestion that was already dismissed in this conversation.
- Keep suggestion text concise, use at most 1-2 actions, and make each accepted action prompt self-contained.
- When suggesting a code review, choose the right command for the action prompt:
- `/local-review-uncommitted` — for reviewing uncommitted working-tree changes (staged, unstaged, and untracked files).
packages/opencode/src/kilocode/suggestion/tool.txt
+7 -8
View File
@@ -8,23 +8,22 @@ Guidelines:
- Never use this tool as a replacement for the final response summary
- Only suggest review when you are at least 90% confident the user's request is fully addressed
- Do not suggest review after every edit or partial implementation turn
- Do not repeat a review suggestion that was already dismissed in this conversation
- Do not repeat a review suggestion when one has already been made in the current session
- Keep the suggestion text concise and actionable
- Provide 1-2 actions maximum
- Make each action prompt self-contained so it can be injected as a synthetic user message
- If you need a real answer from the user, use the `question` tool instead
When to suggest a review:
- Only when the user's original request was to implement a feature, fix a bug, or perform a refactor that they initiated, AND the resulting diff is substantial enough that another independent pass could meaningfully catch issues
- Suggest review after completed, non-trivial file-changing work when another independent pass could meaningfully catch issues
- Do not withhold review solely because the work was reactive, requested by reviewer feedback, fixed CI/lint failures, touched docs/config, or happened around commit/push work
Do NOT suggest a review when:
- The user is responding to or processing external code-review feedback (GitHub PR comments, reviewer notes) — those changes are already under review
- The task is reactive to an existing signal (CI/lint failures, reported issues, triage work, applying fixes the user or a tool already identified)
- The user asked for non-implementation work (research, explanation, git commit/push, triage, documentation-only changes, config tweaks)
- The changes are trivial (typos, comments, formatting, single-line tweaks, small cosmetic fixes)
- The current work is itself a review activity (a prior `/local-review*` turn, reviewing someone else's code)
- No files or implementation-relevant content changed
- The changes are small or trivial, such as typo-only, comment-only, formatting-only, or tiny single-line tweaks
- A local code review suggestion has already been made in the current session
Choosing the right review command for the action prompt:
- Use `/local-review-uncommitted` as the action prompt for uncommitted working-tree changes (staged, unstaged, and untracked files)
- Use `/local-review` as the action prompt for committed branch-level changes
- Prefer `/local-review-uncommitted` when the work you just did has not been committed yet
- Prefer `/local-review-uncommitted` when the work you just did has not been committed yet