Your first review

What you will see

1. A check run named crocotaste appears within seconds, reading Reviewing 6 files… ~60s. It is created before the work starts, so you can see a review is happening.

2. One summary comment. Its first line is the verdict and what the review was grounded in:

   On-system · checked against DESIGN.md and your code
   

   Under it, the pass enumerated, the counts of the whole design system the review read, your stylesheets and components as well as DESIGN.md:

   6 files · 42 tokens · 12 components · 9 decisions · 0 violations
   

   Then a table of findings if there are any, and one collapsed prompt for your coding agent that carries every listed finding, so one copy fixes the review. This comment is edited in place on every later push; there is never a second one.

3. Inline findings, when there are any, grouped as one review per push under the summary. Each names the value, the token or component it should be, and the source line it comes from, with a suggestion you can commit in one click and a collapsed prompt for the agent that wrote the code. Findings and verdicts has the anatomy.

4. An approving review when the change is on-system and the AI review has read it, or had nothing new to read since its last read. A real approval, not just a green check; its body is one line, since the numbers are in the summary above it:

   Nothing to snap at.
   

The approval is for that commit. A later push gets its own review, and when a read is due but withheld (the review's included reads are spent, or the model failed to answer twice) the check is green on the checks alone, titled checks only, with no approval. Crocotaste never dismisses a review, its own included: GitHub's "Dismiss stale pull request approvals when new commits are pushed" branch rule retires ours on the next push the way it retires a person's.

If the pull request touches no UI files, none of that happens: the check says Skipped · no UI files changed, no comment is posted, and no review is spent. What counts as UI lists the globs.

What a review is checked against

Your design system, as it exists in that repository: the tokens, the component inventory, the conventions and the decisions in your DESIGN.md, plus what can be read from your stylesheets, Tailwind config and component files. Nothing else, and nothing from anyone else's repository.

Every finding cites the line it is proved against. A finding that cannot cite one is deleted before it reaches the pull request.

On later pushes

Nothing is repeated. A finding is posted once per pull request, and the marker that makes that possible survives force-pushes and line shifts.

A finding you fixed is marked fixed once the review can see the line is gone: its comment opens with ✅ Fixed in and a link to the commit, collapses as resolved, and the summary counts it in its first line (11 fixed). If you edit the line and it still breaks the same rule, the finding gets a new comment and the old one collapses as outdated. If a later push brings a fixed finding back, its comment opens again as it was. GitHub's "Resolve conversation" button stays yours to press.

Pushes are free. The first completed review of a pull request spends one review from your balance and covers two AI reads: the first, and one more after you push new UI lines. Every push gets the deterministic checks for nothing. A third AI read, asked for with @crocotaste review or Re-run, is one review; an ask with nothing new to read is free.

Pushing three times in a minute gets you one review against the newest commit, not three.

If something goes wrong on our side

The check goes neutral, never red, with the next step written on its title:

Couldn't complete · re-run with @crocotaste review

A review that could not finish does not spend a review.

The same holds for an exhausted balance and for a commit that has already been superseded. Each has its own neutral title saying what to do; when a review fails is the complete list.