human-review

name	human-review
description	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.

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.