Receber por email
← Voltar para o catálogo

human-review

Produce a plain-English review of the files you just edited and gate the changes behind an explicit Approve/Undo choice. Use when the Stop hook from the human-review-skill plugin asks for a review (you'll see a prompt referencing an edit log), OR when the developer's most recent message is "1", "2", "approve", or "undo" in reply to a previous review.

14estrelas
Atualizado há 6 meses

Ver no GitHub ↗

Como adicionar

/plugin marketplace add IrtezaAsadRizvi/claude-human-review

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/human-review/svg)](https://www.skillteca.com.br/skills/human-review)
#ai

Skills relacionadas

Ver todas de Desenvolvimento →

Alerta por categoria

Receba novas skills de Desenvolvimento toda segunda

1 email curto, só com as skills novas de Desenvolvimento. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Human Review

Translate what you just did into plain English so the developer can Approve or Undo. Be brief. Every extra sentence costs tokens.

When to run

Exactly two situations:

  1. Review trigger. The Stop hook injected a prompt telling you to invoke human-review. The prompt includes a path to edit_log.jsonl and a session_id. You must produce a review before stopping.
  2. Reply handling. On the very next user turn after a review, the developer's message is 1, 2, approve, undo, yes, or no. Run the matching script and nothing else.

Otherwise, don't invoke this skill.

Step 1: Document what you changed

Before writing the review, add brief doc comments to new or materially-changed classes, functions, methods, exported symbols, and non-obvious config blocks in the files listed in edit_log.jsonl. The goal is a glanceable note, not prose.

Comment style by language

| Language | Style | | -------------------------------- | ------------------------------------- | | TypeScript / JavaScript | JSDoc /** ... */ above the symbol | | Python | Triple-quoted docstring inside def/class | | Go | // FuncName ... line above | | Rust | /// ... lines above | | Java / Kotlin / PHP / C# | JavaDoc-style /** ... */ | | Ruby | # lines above | | Shell / YAML / TOML / Dockerfile | # line above the block |

Rules

  • Keep it to 1 line (max 2 if a non-obvious param/return matters). One short sentence on what this is for, not how it works.
  • Only touch symbols you added or meaningfully changed this turn. Don't document the whole file.
  • Skip trivial helpers, one-liners, private utility functions, test cases, getters/setters, and obviously-named things. A 3-line formatDate doesn't need a JSDoc.
  • Don't duplicate the signature. "Adds two numbers" on add(a, b) is noise.
  • Don't overwrite existing comments unless they're now wrong. If a symbol already has a docstring/JSDoc, leave it alone.
  • Config blocks: add a comment only when the purpose of the block isn't obvious from the keys.
  • No emojis, no TODOs, no author tags, no dates.

If a file has nothing worth documenting under these rules, skip it. Don't force comments.

Step 2: Writing the review

Read edit_log.jsonl for the file list. Produce exactly this structure:

## Review: what I just did

**What changed**
- `path/to/file1.py`: <≤12 words on the edit>
- `path/to/file2.ts`: <≤12 words on the edit>

**Why**
<1 sentence. Only add a second if a non-obvious assumption needs flagging.>

**Worth a second look**
- <one line per real risk: new dep, secret/config, deletion, auth/crypto, SQL, shell exec, network, migration, unsnapshotted file>

---
**1. Approve**: accept these changes.
**2. Undo**: revert all files this turn.

Hard rules

  • Target 60–120 words total. Hard cap 200. If you're over, cut.
  • One short line per file. Summarize the goal, not each chunk.
  • Skip "Worth a second look" entirely if nothing is risky. Don't pad. No "N/A", no "nothing to flag".
  • Skip "Why" if the prompt was literal (e.g. "add a print statement", "rename X to Y"). Omit the whole section.
  • No preamble, no recap of the prompt, no closing commentary. The template above is the whole message.
  • Never drop the 1/2 closing block. It must appear verbatim.
  • Flag invisible risks only. Things the diff won't show: dynamic imports, loosened checks, swallowed exceptions, new deps, binary/unsnapshotted files.

Example (terse)

## Review: what I just did

**What changed**
- `src/auth/session.py`: session cookie SameSite=Lax → Strict, added Secure flag.
- `tests/test_auth.py`: two cases for the new flags; fixture expects `secure=True`.

**Why**
Read "tighten cookie handling" as CSRF hardening. Strict will break cross-site embeds; I assumed you have none.

**Worth a second look**
- Strict breaks OAuth redirects landing on your domain.
- Secure drops cookies on plain-HTTP localhost dev.

---
**1. Approve**: accept these changes.
**2. Undo**: revert all files this turn.

Handling the developer's reply

On the turn after a review, match the message (case-insensitive, trimmed):

| Reply | Do | | --------------------- | ------------------------------------------------------------------------------------------------------------------ | | 1, approve, yes | Run bash ${CLAUDE_PLUGIN_ROOT}/scripts/approve.sh <session_id>. Reply once: "Approved." | | 2, undo, no | Run bash ${CLAUDE_PLUGIN_ROOT}/scripts/undo.sh <session_id>. Paste the script output. Surface any warnings. | | Anything else | Treat as a new prompt. Don't run either script. The next edit auto-clears prior review state (implicit approve). |

Use the exact <session_id> from the Stop hook prompt. ${CLAUDE_PLUGIN_ROOT} is set by Claude Code.

After approve or undo

  • No second review this turn. State is cleared.
  • No proactive edits. Wait for the next prompt.
  • If undo.sh warns about unsnapshotted files, surface the warning plainly.
Compartilhar X LinkedIn