Menu
Review uncommitted changes for issues, missed items, and improvements. Use after finishing a substantial change, before committing, or when the user asks to check the work.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Build, serve, and watch a morph page, a single .jsx file previewed locally with hot reload whose state lives in the file itself (useMorph) and which can run approved shell commands (useShell). Serving always includes watching the output, since the reader's clicks and comments come back through the file for you to act on. Use whenever you author, serve, or respond to a morph document.
Format, lint, test, and commit changes. Detects repo tooling automatically.
Read and control tmux panes from inside a tmux session - see what other panes show, send commands to them, create splits, run long-lived processes. ALWAYS use when asked about another pane, before running any tmux command, or when a command needs a real TTY or would outlive the shell tool timeout.
Basé sur la classification professionnelle SOC
| name | git-review |
| description | Review uncommitted changes for issues, missed items, and improvements. Use after finishing a substantial change, before committing, or when the user asks to check the work. |
| argument-hint | ["range"] |
| allowed-tools | Bash(git *), Read, Glob, Grep |
| context | fork |
Review the git diff and identify:
!git status --short
!git diff --no-ext-diff $ARGUMENTS
!git diff --cached --no-ext-diff
Provide a concise, actionable summary. If everything looks good, say so briefly.
Before flagging an issue, read the relevant surrounding code to verify it's actually a problem. Specifically:
?? in the status above) are in neither diff; read them in full and review them like any other change. A whole new file escaping review is the most likely gap.Do not flag something as an issue if the existing codebase already handles it. Only report confirmed or highly likely problems.
Split the findings: a fix is mechanical and unambiguous (leftover debug code, a confirmed bug with an obvious correction, a missed rename, dead code) - include the exact change to make; a decision involves intent or a tradeoff (behavior changes, design questions, scope concerns).
End the report by telling the assistant that invoked you to apply the fixes immediately, without waiting for confirmation, and to surface the decisions to the user as questions. If there are no findings, say everything looks good and that nothing needs to happen.