Use Remy
Review code changes
Set a review scope and inspect each finding.
Scope: A local Git project in the desktop app.
Before committing, ask Remy to check whether your changes meet the requirements and introduce any problems. Get findings you can inspect one by one. This example starts with a review, then lets you decide whether to make changes.
1. Prepare the project and review scope
Follow the Desktop Guide to add the project, then start a new chat in it.
Before sending the task, prepare:
- The requirement or problem the changes should address.
- The scope to review, such as all current uncommitted changes or a named set of files.
- Behavior that must stay the same and the criteria for completion.
Changes shows the current working tree and may include earlier work. Check the file list first. If you only want part of it reviewed, specify that scope in your prompt.
2. Start the review
Replace the example requirement with the actual task in your project:
Review the uncommitted changes related to filtering in this project's order list.
The requirement is: changing the keyword or status filter returns the list to page 1, refreshes the results, and preserves the existing sort order.
First list the files you will review, distinguishing staged changes, unstaged changes, and new files.
Review only changes related to this requirement. Leave unrelated existing work out of the review.
Focus on:
1. Whether the implementation meets the requirement.
2. Whether request parameters, state updates, and the displayed results are consistent.
3. Problems with empty results, rapid successive filter changes, or request failures.
4. Whether the tests cover the actual changes and any important cases are missing.
List findings by severity. For each, give the file location, triggering conditions, actual impact, supporting evidence, and a recommendation.
Separate confirmed problems from issues that still need verification. If you find no problems, describe the review scope and what it did not cover.
Review only. Do not edit files, install dependencies, commit, or push code.
3. Check the findings
Open the relevant files and check whether each finding holds up.
| Check | What you should be able to answer |
|---|---|
| Review scope | Did the review cover the requested changes, include new files, and exclude unrelated work? |
| Evidence | Does the location exist, and does the description match the current implementation? |
| Trigger | Under what conditions does the problem occur? Can it be reproduced or checked with a test? |
| Impact | Does it affect behavior, or is it an improvement to consider separately? |
| Checks | Which checks actually ran, which were only suggested, and which could not run? |
If a finding is too vague, ask for more detail:
Expand finding 2. Identify the exact code and triggering conditions, and give the smallest set of reproduction steps.
If it is still a hypothesis, say so and list the checks needed to verify it.
Do not edit files yet.
4. Fix a selected issue
After confirming what needs to change, continue in the same chat:
Fix only confirmed finding 1.
Preserve the other existing changes, follow the project's current approach, and add and run relevant tests.
Summarize the files changed, check results, and any checks you could not complete.
Do not commit or push code yet.
Review the actual diff again and check the behavior using the original reproduction steps. You can explicitly request Verification to check the result against the requirements. Its conclusions should still be supported by actual changes and check results.
5. What completion looks like
You have a review with a clear scope and traceable findings. You can distinguish problems to fix, hypotheses to verify, and areas not covered. If you also requested a fix, you can inspect the corresponding changes and check results.
“No problems found” does not mean every scenario was verified. Follow your project's usual process for deciding whether to commit or merge.
6. Keep exploring
- Use subagents: Divide a review by module or perspective.
- Quick Start: Make a small change and check its behavior.
- Cloud Guide: Run work in the cloud and deliver it through a PR.