name: fallback-code-review description: Fallback only for agents with no native code-review capability. Do NOT use this skill if the environment provides a code_review tool, built-in code-review skill, or any first-party review mechanism; use that instead. After confirming no other review mechanism exists, use this skill to get an external review of code changes, commits, PRs, patches, or diffs via CLI tools. user-invocable: true license: LicenseRef-MutuaL-1.2 metadata: author: Amolith amolith@secluded.site

Get an external review of your code/changes using the appropriate CLI without setting a timeout.

Selection

Prefer the following in this order.

command -v amp; command -v coderabbit; command -v kodus

If CodeRabbit is rate-limited, use another. If none are usable, tell the user and stop.

CLI usage

kodus review --prompt-only --staged
kodus review --prompt-only --branch main # Compare changes against branch
kodus review --prompt-only --commit abc123
kodus review --prompt-only src/auth.ts

coderabbit review --prompt-only # all changes
coderabbit review --prompt-only --type committed
coderabbit review --prompt-only --type uncommitted
coderabbit review --prompt-only --base main

amp review  # uncommitted changes
amp review "HEAD~1"
amp review "main...HEAD"
amp review -f src/auth.ts
amp review "068d2222..1800e595" -i "explicit, detailed instructions to focus on something(s) in particular" -f src/auth.ts

NEVER set a timeout when running these commands. A reviewer timing out is a disastrous waste of your time and the reviewer's!

Some of them require running in git repos. Some of them don't understand jujutsu refs and require colocation in a git repo along with "ref..ref" ranges using the commit IDs instead of jujutsu changes. Most, I believe, are able to review unstaged changes in a colocated/git repo.

Output

Display issues as a numbered list:

1. category (severity) - [file-basename](file-path#range): verbatim finding from the code review tool

For example:

1. style (nit) - [auth.ts](src/auth.ts#L3-L5): Imports are unsorted and mix standard library, external, and internal packages in a single block without grouping or deterministic ordering

Then ask:

• If other code review tools are available: "Would you like me to fix any of these issues, rerun that, run it differently, or check with [Kodus, CodeRabbit, or Amp] as well?", only listing the available options
• If only the one is: "Would you like me to fix any of these issues, rerun that, or run it differently?"

If told to fix anything, do so, then go through the same review flow again and stop to present the follow-up review.