Skip to main content
Before a change reaches a teammate or a pull request, Review My Changes reads every supported staged, unstaged and untracked file and reports what a reviewer would flag. Blockers first, then warnings, each one click from its source line. It is free, and it is the workflow most people use daily.

​
Running it

When git reports local changes, a Git-changed files detected strip appears above the sidebar tabs. The count only includes files Iris Code will actually read: JavaScript, TypeScript, Vue, Svelte, Go, Python, Ruby, C#, Java and Rust. Click the strip, or run Iris Code: Review My Changes from the command palette. It opens in its own editor tab with:
  • a verdict at the top, “ready for review” or “needs attention”, blockers first
  • filters by severity, and a search box
  • a health score for each changed file
  • click-to-open on every finding
  • an expandable list of files that import each changed file
The Workspace tab switches to a change review view of the same result, and Issues and TODOs fill in from it. All on Free.

​
Import impact

A changed file can affect code outside the diff. Change Review uses the Code Map import graph to show how many mapped files import each changed file. Expand the count to open an importer. Files in the change set still appear in each other’s lists. On Free, the focused file’s direct importers are available. Iris Code Pro adds a transitive dependent count, capped at 500+, and a one-line summary of the distinct files outside the change set that directly import changed files. Impact is information for review. It does not change a health score, gate decision or exit code. In Go, and for a C# using, a Java wildcard import or a Python namespace package, an import names the package rather than a file. Those importers count for every file in the package’s folder, and Change Review labels them through its package. If the graph has not been built, Change Review builds it when the review opens and shows Mapping imports… until it finishes. In a very large workspace it asks first, and if you decline it offers Build import graph instead. An unread, ignored or unsupported file is marked Not mapped, rather than given a zero count. The graph lists unresolved imports separately with their reasons; its counts cover resolved edges only. See Code Map for the graph’s scope and limits.

​
Scoped honestly

A review of eleven files is not a review of the project, and the two are kept distinct:
  • No trend snapshot is created. A partial scan would distort your history.
  • No unused-dependency conclusions. That requires scanning everything that might import a package.
  • Untracked files are included, unless .gitignore excludes them.
  • A workspace inside a larger repository reviews only its own changes. Opening one package of a monorepo never surfaces findings from a sibling package you did not touch.
Whole-project analysis, folder scans, iris check --staged in CI, and hook enforcement are Pro.

​
Real repositories

The awkward cases are handled deliberately rather than left to fail:
  • No git repository: the strip stays hidden and the command explains why rather than erroring.
  • Git not installed: reported as exactly that, rather than as a missing repository.
  • A new repository with no commits: staged and untracked files are still reviewed.
  • Large untracked folders, paths with spaces or unicode, a merge in progress: all handled.