anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-23 02:36:57 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[PR #5918] prompts: improve built-in /review prompt #11645

New Issue
Closed
opened 2026-02-16 18:16:32 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:16:32 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/5918

State: closed
Merged: Yes

This PR pulls in elements of the review.yml prompt into the /review command shipped to all OpenCode users.

why:

  • I've found the built-in /review command to be good, but seems to miss things that this repo's own /review workflow (https://github.com/sst/opencode/blob/dev/.github/workflows/review.yml#L64-L71) catches when @rekram1-node tells me my code sucks.
  • As with all prompts + no evals, this is somewhat anecdotal, but I've seen good results from just copying in the review.yml prompt myself.
  • I used OpenCode to combine them with the below prompt + response + and a manual review to pull back some of its brevity.

This is not intended to be a huge change.

my prompt

the sst/opencode repo has two "review" type prompts:

- the built in `/review` command - this prompt: https://github.com/sst/opencode/blob/3456f4ed8053f7718865d2d03dc261e983fed9aa/packages/opencode/src/command/template/review.txt - feeds the command: https://github.com/sst/opencode/blob/3456f4ed8053f7718865d2d03dc261e983fed9aa/packages/opencode/src/command/index.ts#L51-L56
- the `review.yml` workflow that invokes opencode via a GitHub Action: https://github.com/sst/opencode/blob/dev/.github/workflows/review.yml#L64-L71

the latter seems to be shorter but more robust, catching more issues in a code review flow based on observed experience (anecdotal over several PRs). specifically, it does a better job of catching:

- if-else guards around branching control flow
- empty/null/undefined arguments leading to exceptions or unintended behavior
- following existing instructions and style guide conventions.

can you analyze both prompts and provide an updated, single review prompt that we can use for the review.txt template. the workflow one should be inspiration to improve this template.

rationale / response

## Summary of Changes

I've updated `review.txt` incorporating insights from the `review.yml` workflow. Here's what changed and why:

### Added: "Gathering Context" section
The workflow prompt explicitly states: *"Diffs are important but make sure you read the entire file to get proper context."* This is critical for catching bugs that only manifest when you understand surrounding code. The original template only looked at diffs.

### Added: If-else guards and branching to the Bugs checklist
Your feedback noted the workflow catches *"if-else guards around branching control flow"* better. I made this explicit under the Bugs section.

### Added: "Don't be a zealot about style" guidance
The workflow has pragmatic advice like:
- *"don't complain about else statements if they already use early returns"*
- *"we don't like let statements but sometimes they are the simplest option"*

This prevents false positives on style issues. The original template had no such nuance.

### Added: Excessive nesting as a legitimate concern
The workflow says *"You may complain about excessive nesting though, regardless of else statement usage"*—this is a real code quality issue worth flagging even when other style rules are bent.

### Added: "Frame suggestions as suggestions"
The workflow states *"Make it clear the suggestions are merely suggestions and the human can decide what to do."* This sets the right tone for reviewer/author collaboration.

### Restructured: Tone section → Output section
Renamed and tightened the guidance. Kept the key points (be direct, accurate severity, matter-of-fact tone, no flattery) but integrated the "suggestions are suggestions" framing.

### Not incorporated:
- The workflow's specific GitHub API comment syntax—that's workflow-specific, not relevant to the general review template
- IIFE pattern mention—too specific to one codebase's conventions
**Original Pull Request:** https://github.com/anomalyco/opencode/pull/5918 **State:** closed **Merged:** Yes --- This PR pulls in elements of the `review.yml` prompt into the `/review` command shipped to all OpenCode users. why: * I've found the built-in `/review` command to be good, but seems to miss things that this repo's own `/review` workflow (https://github.com/sst/opencode/blob/dev/.github/workflows/review.yml#L64-L71) catches when @rekram1-node tells me my code sucks. * As with all prompts + no evals, this is somewhat anecdotal, but I've seen good results from just copying in the `review.yml` prompt myself. * I used OpenCode to combine them with the below prompt + response + and a manual review to pull back some of its brevity. This is not intended to be a huge change. ### my prompt ``` the sst/opencode repo has two "review" type prompts: - the built in `/review` command - this prompt: https://github.com/sst/opencode/blob/3456f4ed8053f7718865d2d03dc261e983fed9aa/packages/opencode/src/command/template/review.txt - feeds the command: https://github.com/sst/opencode/blob/3456f4ed8053f7718865d2d03dc261e983fed9aa/packages/opencode/src/command/index.ts#L51-L56 - the `review.yml` workflow that invokes opencode via a GitHub Action: https://github.com/sst/opencode/blob/dev/.github/workflows/review.yml#L64-L71 the latter seems to be shorter but more robust, catching more issues in a code review flow based on observed experience (anecdotal over several PRs). specifically, it does a better job of catching: - if-else guards around branching control flow - empty/null/undefined arguments leading to exceptions or unintended behavior - following existing instructions and style guide conventions. can you analyze both prompts and provide an updated, single review prompt that we can use for the review.txt template. the workflow one should be inspiration to improve this template. ``` ### rationale / response ``` ## Summary of Changes I've updated `review.txt` incorporating insights from the `review.yml` workflow. Here's what changed and why: ### Added: "Gathering Context" section The workflow prompt explicitly states: *"Diffs are important but make sure you read the entire file to get proper context."* This is critical for catching bugs that only manifest when you understand surrounding code. The original template only looked at diffs. ### Added: If-else guards and branching to the Bugs checklist Your feedback noted the workflow catches *"if-else guards around branching control flow"* better. I made this explicit under the Bugs section. ### Added: "Don't be a zealot about style" guidance The workflow has pragmatic advice like: - *"don't complain about else statements if they already use early returns"* - *"we don't like let statements but sometimes they are the simplest option"* This prevents false positives on style issues. The original template had no such nuance. ### Added: Excessive nesting as a legitimate concern The workflow says *"You may complain about excessive nesting though, regardless of else statement usage"*—this is a real code quality issue worth flagging even when other style rules are bent. ### Added: "Frame suggestions as suggestions" The workflow states *"Make it clear the suggestions are merely suggestions and the human can decide what to do."* This sets the right tone for reviewer/author collaboration. ### Restructured: Tone section → Output section Renamed and tightened the guidance. Kept the key points (be direct, accurate severity, matter-of-fact tone, no flattery) but integrated the "suggestions are suggestions" framing. ### Not incorporated: - The workflow's specific GitHub API comment syntax—that's workflow-specific, not relevant to the general review template - IIFE pattern mention—too specific to one codebase's conventions ```
yindo added the pull-request label 2026-02-16 18:16:32 -05:00
yindo closed this issue 2026-02-16 18:16:32 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#11645
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?