Commands

Everything Crocotaste does can be driven from the pull request, because that is where the conversation already is. There is no CLI and no settings page.

@crocotaste review

Re-runs the review against the pull request's current head commit. Post it as an ordinary comment on the pull request, or inside any inline review thread.

Use it after a neutral check, after topping up a balance, or whenever you want a fresh pass. Nothing already posted is repeated. A pull request's review covers two AI reads; a command that has the AI read it a third time spends one review, and a command with nothing new to read (the same UI lines against the same design system) is free and says so. It is also how a member reviews an outside contributor's pull request, which waits until one asks, and the only way a review starts on a repository set to on demand. It runs up to 20 times an hour per installation.

The dashboard's Re-run button does the same thing without touching a webhook, which is the one recovery path that works even when a delivery was lost.

@crocotaste ignore <reason>

Reply to one of Crocotaste's inline findings with this. It has to be a reply to the finding itself; a top-level comment has no finding attached.

Three things then happen:

1. The finding is dismissed for this pull request: its comment is marked resolved, and the summary keeps it listed as dismissed. It will not come back here on any later push.
2. For an AI finding, Crocotaste replies in the thread with a ready-to-paste block for your DESIGN.md's ## Decisions section: a title, your reason and the source line already filled in.
3. That reply carries a prompt for your coding agent to open the pull request that records the decision.

The review then runs again on the same commit without spending anything, so dismissing the last open finding turns the check green; the approval follows when the model's last read covers these lines, and never on an outside contributor's pull request.

A deterministic finding (a raw value measured against your tokens) gets a shorter reply: those checks read your tokens, not your Decisions section, so a recorded decision can't change what they flag. If the value belongs in your system, name it as a token; the checks follow your tokens from the next review on.

If the same finding was dismissed on other pull requests before, the reply says how many. A rule that keeps needing dismissal is one worth recording.

Every dismissal reply ends with an address for telling us the finding itself was wrong, so we can fix the check rather than your DESIGN.md.

No DESIGN.md yet? The reply drafts the file's first ## Decisions section instead, and links the instructions for your coding agent. Reviews run either way (without the file they are grounded in the tokens and components parsed from your code), but a decision needs somewhere to live.

Merge the decision and it holds everywhere: on every future review, and in every agent that reads the file before writing UI. Leave it unrecorded and the same finding can resurface on a different pull request. That is on purpose: a dismissal that only lived in our database would be an invisible exception list nobody on your team could read, review or revert.

The reason is optional, but a decision without a reason is a rule nobody can argue with later.

Who may issue a command

Anyone who can push to the repository: its owners, and the members and collaborators with write, maintain or admin access, as GitHub reports it at the moment of the comment. A comment from anyone else (an outside contributor on a public repository, a bot) is read and ignored, so a drive-by cannot spend your reviews or dismiss a finding. Their pull requests wait for a member's @crocotaste review and are never reviewed on their own.

Where a command is read

The command must start a line of the comment:

@crocotaste review

Lines inside fenced code blocks and quoted lines (> …) are ignored, so you can quote or explain the commands in a thread without issuing them. Case does not matter, and the first command line in a comment is the one that runs.

Commands are rate limited per installation. If you hit the limit the comment is dropped without a reply, and the next hour clears it.

What a command cannot do

• It cannot un-dismiss a finding. The way to bring a rule back is to remove the decision from DESIGN.md.
• It cannot change what is reviewed. The only per-repository setting is the review mode in the dashboard, which says when a review starts and never what it checks; what counts as UI is the same everywhere.
• It cannot resolve the conversation. GitHub lets only someone with write access to your code do that, and Crocotaste never asks for it: the conversation's Resolve button stays yours.