# Reviewing a change

> Ask what a change introduced before it lands, instead of scoring the whole repository again.

Web page: https://supercov.com/docs/quality-changes
All Supercov pages for agents: https://supercov.com/llms.txt · Full text: https://supercov.com/llms-full.txt

Scoring a repository tells you where the old problems are. A change asks a
different question: did this edit introduce something that was not there
before? Supercov asks that directly.

```sh
npx supercov quality patch
```

```text
Reviewing unstaged changes.

src/session.js
  0.93  deep_nesting
  0.82  complex_conditional
  0.80  long_parameter_list
  0.79  magic_values
```

Nothing here is a score. Each line says a property appeared in this edit,
and how confident that answer is.

## Both versions go in together

For every changed file, the version before the edit and the version after it
go into one request, and the question is what `after` shows that `before` did
not. That is why it can be pointed at code that was already messy: a file that
scores `weak` has nothing to lose, but an edit that adds a fourth level of
nesting to it still shows up.

## Choosing what to compare

With no options it picks the range from the state of your tree.

| Your tree | What it reviews |
| --- | --- |
| Uncommitted edits present | The working tree against the index |
| Only the index is ahead | What a commit would contain |
| Clean | Everything since this branch left its default branch |

You can say so explicitly instead:

```sh
npx supercov quality patch --staged
npx supercov quality patch --base origin/main
npx supercov quality patch src/session.js
```

## Risks a change can carry

A change is also asked six questions that only make sense about an edit: does
it add a hardcoded secret, build a query or command from untrusted input,
touch authentication or permissions, weaken or delete a test, migrate data
irreversibly, or leave debugging behind.

These stay quiet on ordinary work. On a routine change, expect around one to
fire, and read it rather than trusting it: each one is a judgment about the
diff, and the diff is in front of you.

## In continuous integration

```sh
npx supercov quality patch --base origin/main --annotate github
```

`--annotate github` prints workflow annotations to stdout, so findings appear
on the changed lines. It posts nothing and calls no API of its own.

Crossing the findings with a coverage run shows which of them landed in code
no test exercises:

```sh
npx supercov quality patch --base origin/main --run latest
```

## What it will not find

This is a structural check, not a code review. Measured against a published
set of review comments from real pull requests, the twelve properties had a
word for about one comment in twelve, and most of what reviewers actually
wrote about were bugs — wrong conditions, missed cases, bad assumptions.
Those are what your tests and your reviewers are for.

Read it as one more signal beside [coverage](https://supercov.com/docs/coverage-model.md) and
[assertion coverage](https://supercov.com/docs/assertions.md), and keep the reviewer.

## Read more in the terminal

```sh
npx supercov docs quality
npx supercov quality --help
```

`patch` reads your working tree and writes nothing to it.