Review workflow

Get a second review. Verify every finding.

Ask Triss to review a branch, a staged diff, or a GitHub pull request through your selected provider. You receive findings to check one by one — the decision about what to change stays with you or your main agent.

Use it when

You want a second opinion on a change before it merges: possible correctness defects, regressions, or missing coverage in the diff. This is an executable recipe for running the review — it is not a published case study, and this page shows no invented findings.

Prerequisites

Your selected provider is configured (check with triss status).
A local branch comparison needs Git and a base ref that actually exists in your repository (for example origin/main after a fetch).
The GitHub pull request path needs working gh access, per the current CLI.

Run

Review the current branch against a base branch:

triss review --base origin/main

The base must exist as a ref you have locally. This is a branch review: committed changes on the current branch compared against the base — not a review of arbitrary unstaged changes. Without --base, Triss auto-detects origin/HEAD or main/master/develop.

Alternative sources

Review an explicitly piped staged diff:

git diff --cached | triss review --stdin

Review a GitHub pull request by number:

triss review 123

123 is an example PR number — replace it with your own pull request. Do not point a verification run at a random PR.

Pick one source per invocation. Do not mix --base, a PR number, and --stdin in a single command — the CLI rejects these combinations. For linked-ticket context, use the explicit supported flag --issue <key> (for example--issue PROJ-123); pull request prose never triggers tracker access on its own.

Inspect

For each finding, check it before acting on it:

Does the cited path and line exist, and does the code say what the finding claims?
Is the described defect real — is the faulty path reachable in practice?
Do existing guards or tests already cover it?
Reject findings you cannot confirm. An unverified finding is a lead, not a defect.

Use the result

You or your main agent choose which confirmed findings to fix, make the changes, and test them. Running another review afterwards is a separate, explicit decision — Triss does not chain reviews or approve anything for you.

Limits

A review is not a guarantee that no defects remain.
It is not automatic pull request approval — acceptance stays with you.
A partial or sharded result (the --payload-mode shard option) reviews sequential whole-file shards with no global verdict — do not present it as a full review of the change.