> ## Documentation Index > Fetch the complete documentation index at: https://docs.plannotator.ai/llms.txt > Use this file to discover all available pages before exploring further. # Review local code changes > Open a browser review for local Git, GitButler, Jujutsu, or Perforce changes and send line-specific feedback to your coding agent. Run a local review from your coding agent: ```text theme={null} /plannotator-review ``` Or start the same review from a terminal: ```bash theme={null} plannotator review ``` Plannotator detects the repository and opens the diff in your browser. When an agent starts the command, it captures your submitted annotations. When you start the command directly, Plannotator prints the result in the terminal. The available comparison modes depend on the source-control system. ## Git reviews start with everything since the base branch In a Git repository, the default **All changes** view uses Plannotator's `since-base` comparison. It shows the change a pull request would contain if you committed and pushed now by comparing the merge base of your branch and its base branch with the current working tree. It includes: * Commits on your branch * Staged and unstaged changes * Untracked files Plannotator tries the repository's default branch first, then common `main` and `master` references. If it cannot resolve a base branch, it opens the uncommitted changes instead. This fallback avoids hiding committed work behind an invalid comparison. Use the comparison picker to review only uncommitted, staged, or unstaged changes, the last commit, a specific commit, all files at `HEAD`, or committed branch changes. The base picker can compare against another local or remote reference. The **Git status** panel groups committed changes, working-tree changes, and untracked files in the default All changes view. Staging controls and the commit-history rail are available only for ordinary local Git reviews. ## Choose the source-control provider Plannotator uses the nearest supported repository root. When a folder contains nested Git, GitButler, or Jujutsu repositories, it can show their workspace changes together with repository-prefixed paths. | Provider | Default view | Important boundaries | | --------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Git | All changes (`since-base`) | Supports staging controls, Git status groups, commit history, base selection, and stale-diff checks. | | GitButler | Workspace | Requires `but` 0.21.0 or newer. Stack and Branch views are committed-only. Git staging, commit history, and base-fetch controls are unavailable. | | Jujutsu | Current | Uses Jujutsu revisions rather than the Git index. No stage or unstage controls. | | Perforce | Default changelist | Shows opened text files from the default or a numbered pending changelist. Binary opened files are skipped. No staging controls or nested-repository aggregation. | ### Force Git or GitButler Automatic detection recognizes an active GitButler workspace only when the repository is on the GitButler workspace reference and has a configured GitButler target reference. A leftover GitButler database or reserved branch is not enough. Use a flag when you need to choose explicitly: ```bash theme={null} plannotator review --gitbutler plannotator review --git ``` `--gitbutler` fails with a clear error if a compatible `but` command is not on `PATH`. It does not silently fall back to Git. On Windows, make the `but.exe` installed by GitButler Desktop available on `PATH`. The standalone GitButler CLI supports macOS and Linux. GitButler's default **Workspace** view includes applied committed work, assigned and unassigned working-tree changes, and untracked files. **Stack** shows committed changes through a stack tip. **Branch** shows one committed branch layer. Assigned working-tree hunks stay in Workspace because GitButler does not provide one authoritative combined diff for a stack plus those hunks. In Stack and Branch views, treat the rendered patch and expanded file content as authoritative. Plannotator disables editor opening, code navigation, semantic diff, and VS Code annotations because the live workspace can contain later branch layers or other applied stacks. ### Review Jujutsu changes Plannotator detects a Jujutsu workspace through the installed `jj` command. The comparison picker offers: * **Current** for `@` compared with its parent * **Last** for the previous change * **Line** for the current line of work back to the selected target * **Evolution** for the current change compared with an older evolution entry * **All** for the repository root through `@` Line mode can target local or remote bookmarks. Plannotator does not expose a separate `--jj` flag. ### Review Perforce changelists Plannotator detects Perforce after Git by running `p4 info` and reading the current client root. The default view contains files opened in the default changelist. Use the comparison picker to open another pending numbered changelist owned by the current user and client. Perforce support is available in Plannotator's main CLI-backed agent setups. The Pi extension's review server does not provide a Perforce provider. ## Annotate and return the review Select changed lines to add comments, quick labels, deletion requests, or an approval mark. **Send Feedback** produces structured file and line references. **Approve** produces the configured code-review approval prompt. The agent that opened Plannotator captures that output; a direct terminal launch prints it. See [Customize Feedback](/open-source/reference/custom-feedback#code-review-feedback) to change the approval message or the instructions appended after submitted findings. For a GitHub pull request or GitLab merge request, use a URL instead. See [Review pull requests and merge requests](/open-source/workflows/pull-requests). Last verified against Plannotator OSS v0.23.1 on July 18, 2026. Maintained by the Plannotator project.