claude-review

# Claude Review Use this skill for independent reviews of Claude-authored work in this repo. The goal is to find real correctness, docs, consistency, test, and maintainability issues without becoming biased by past Claude behavior. ## Required References Read these before reviewing: - [`references/review-style.md`](references/review-style.md) for output format and severity. - [`references/claude-review-patterns.md`](references/claude-review-patterns.md) for recurring review patterns. If the change touches tabbed code examples — `local_examples/`, a client repo's doctests, `data/examples.json`, the client config in `config.toml`, or `.claude/skills/tce-examples/` — also read [`references/tce-review-patterns.md`](references/tce-review-patterns.md). Those defects mostly survive a green test run, so the test result is not the review. Treat the pattern file as a map of places to inspect, not as evidence. The current diff and current workspace always win. ## Workflow 1. Identify the review target: - Prefer the user-supplied diff, PR, branch, or file list. - If the target is local, inspect `git diff`, `git status --short`, and the touched files before judging. - If the target is a PR, inspect the PR diff and any relevant review comments. 2. Read the nearby source of truth: - Adjacent docs pages, examples, tests, config, data files, shortcodes, generated mappings, or skill instructions touched by the change. - Existing repo conventions before claiming a convention was violated. 3. Use `claude-review-patterns.md` as a targeted checklist: - Pick only patterns relevant to the touched files and change type. - For each suspected issue, verify the exact current file and line before reporting it. - Do not report a pattern match unless it causes an actionable problem in this change. 4. Produce findings first: - Order by severity. - Include precise file/line references. - Explain the user-visible or maintainer-visible impact. - Keep summaries secondary and brief. 5. If no issues are found: - Say that clearly. - Mention residual risk, unrun tests, or review limits. ## Independence Rules - Historical patterns suggest what to inspect; they never prove a current bug. - Never assume Claude made a mistake because Claude made a similar mistake before. - Verify against the current workspace to avoid stale-snapshot findings. - Prefer fewer, stronger findings over broad speculative concerns. - Do not modify this skill or its references during a review unless the user explicitly asks. ## Skill Memory Updates At the end of a review, add a short `Suggested skill-memory updates` section only if the review revealed a reusable pattern that is: - concrete enough to scan for in future reviews; - backed by a current finding or a clearly described false positive; - not already covered by [`references/claude-review-patterns.md`](references/claude-review-patterns.md). Suggest the update text, but do not apply it unless explicitly asked. New entries should follow the schema in `claude-review-patterns.md`.