---
name: review-work
description: Findings-first review workflow for LazyClaude changes, adapted for LazyClaude review discipline with Claude Code evidence, manual QA, and cleanup receipts.
---

# Review Work

Use this skill after implementation, before commit, or whenever the user asks
for a review. The stance is adversarial but practical: prove bugs, risks,
regressions, and missing tests before discussing style.

## Review Order

Findings first. Summaries are secondary.

1. High severity correctness, data loss, security, or publish/install failures.
2. Medium severity regressions, brittle assumptions, stale docs, or missing
   verification for changed behavior.
3. Low severity maintainability risks that can reasonably cause future mistakes.
4. Open questions and assumptions.
5. Short change summary only after findings.

If there are no findings, say that clearly and name residual risk or test gaps.

## Required Evidence

Every finding needs:

- File path and line when available.
- Reproduction command or concrete scenario.
- Expected behavior and actual behavior.
- Suggested fix that preserves the user's intent.

Do not report vague discomfort. Turn it into an observable claim or omit it.

## Review Surfaces

Check these surfaces for LazyClaude work:

- `package.json` version, `bin` aliases, and `files` allowlist.
- `plugins/lazyclaude/.claude-plugin/plugin.json` version and exported skills.
- `plugins/lazyclaude/commands/*.md` frontmatter and command body.
- `plugins/lazyclaude/skills/*/SKILL.md` Claude-compatible wording.
- `plugins/lazyclaude/bin/lazyclaude-hook.js` hook JSON parsing and prompt
  safety.
- `bin/lazyclaude-ai.js` install/update/uninstall registry behavior.
- `README.md`, `README_ko-KR.md`, and docs parity.
- `test/*.test.mjs` coverage for every behavior change.

## Manual QA Gate

Green tests support review but do not replace real-surface evidence. For CLI and
plugin packaging, a tmux or shell transcript is acceptable when it drives the
real binary. For browser or desktop behavior, use the real browser or desktop
surface.

Required artifact fields:

- command or exact tool invocation
- observable PASS/FAIL condition
- captured output path
- cleanup receipt for tmux/session/process/temp state

## Prompt and Skill Review

Prompt files should be reviewed like executable policy:

- Is the trigger condition clear?
- Are model-facing tools distinguished from slash commands and user actions?
- Are Codex-only instructions translated into Claude Code surfaces?
- Does the text avoid promising behavior the plugin cannot implement?
- Does it require evidence rather than vibes?
- Does it preserve user agency around publishing, destructive commands, and
  secrets?

## Common Findings

- A command says LazyClaude can auto-type `/goal`; it cannot do that safely.
- A hook returns noisy fallback text on every prompt instead of compact context.
- A test pins exact prose rather than the behavior-bearing contract.
- Install docs ask users to type long `claude --plugin-dir` commands even after
  global plugin registration.
- A package version was bumped but plugin manifest or docs were left stale.
- A release checklist mentions a version different from `package.json`.

## Review Result Format

Use this compact shape:

- `P0/P1/P2` severity.
- `[file:line]` reference when available.
- One paragraph explaining why it matters.
- One concrete fix or test.

Then add:

- `Open questions`
- `Verification reviewed`
- `Residual risk`
