Claude Skill

code-review

Conducts and responds to code review — reviewing a change for correctness, design, and risk, and evaluating review feedback received on your own work. Use this before merging, when asked to review a diff or pull request, when review feedback has arrived and needs acting on, or wh

LLM Mart · 0 points · 16 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download cbrock84-headcount-plugins_technology_skills_code-review-1f3f550.zip · 1 KB

cbrock84/headcount 1633 245 forks MIT Updated 7d ago

Part of cbrock84/headcount — 160 skills

Install

skills CLI npx skills add https://github.com/cbrock84/headcount/tree/main/plugins/technology/skills/code-review

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install cbrock84-headcount@llmmart

Git git clone https://github.com/cbrock84/headcount.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole cbrock84/headcount collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Code review

Two directions, one skill: reviewing, and being reviewed.

Reviewing

Read the diff against what the change is for, not against your preferences. Order matters — spend attention where damage is expensive:

Correctness — does it do what it claims, including at the boundaries and on the error path?
Blast radius — what else consumes this? Signature and schema changes are the ones that break things far away.
Security and data — untrusted input, authorization, anything logged or persisted.
Tests — do they pin the new behavior, or do they pass regardless?
Design — will this shape hold under the next change?
Style — last, and only where a linter cannot.

Say which category each comment is, and whether it blocks. A review that mixes a data-loss bug with a naming preference in one undifferentiated list wastes the author's judgment.

Receiving

Feedback is a report of a reader's experience, and that part is always valid — if the reviewer misread it, the code is misleading. The proposed remedy is a separate thing and may be wrong.

Verify before implementing. A suggestion that would break behavior gets a reply, not a commit.
Disagreeing is fine; ignoring is not. Answer every comment: changed, or why not.
Do not batch-accept. Applying every suggestion without judgment is how good code becomes incoherent.
Where a reviewer is factually wrong, show the evidence — the test, the spec, the failing case — rather than asserting.

Never

Approve your own work, or a change you authored under another name.
Leave a blocking comment without saying what would unblock it.
Rewrite the author's approach in a review comment. Propose it, and let them decide.

Files (headcount)

SKILL.md 2.1 KB

---
name: code-review
description: Conducts and responds to code review — reviewing a change for correctness, design, and risk, and evaluating review feedback received on your own work. Use this before merging, when asked to review a diff or pull request, when review feedback has arrived and needs acting on, or when feedback seems wrong and needs a reasoned response rather than compliance.
---

# Code review

Two directions, one skill: reviewing, and being reviewed.

## Reviewing

Read the diff against what the change is *for*, not against your preferences. Order matters — spend
attention where damage is expensive:

1. **Correctness** — does it do what it claims, including at the boundaries and on the error path?
2. **Blast radius** — what else consumes this? Signature and schema changes are the ones that break
   things far away.
3. **Security and data** — untrusted input, authorization, anything logged or persisted.
4. **Tests** — do they pin the new behavior, or do they pass regardless?
5. **Design** — will this shape hold under the next change?
6. **Style** — last, and only where a linter cannot.

Say which category each comment is, and whether it blocks. A review that mixes a data-loss bug with
a naming preference in one undifferentiated list wastes the author's judgment.

## Receiving

Feedback is a report of a reader's experience, and that part is always valid — if the reviewer
misread it, the code is misleading. The proposed remedy is a separate thing and may be wrong.

- **Verify before implementing.** A suggestion that would break behavior gets a reply, not a commit.
- **Disagreeing is fine; ignoring is not.** Answer every comment: changed, or why not.
- **Do not batch-accept.** Applying every suggestion without judgment is how good code becomes
  incoherent.
- Where a reviewer is factually wrong, show the evidence — the test, the spec, the failing case —
  rather than asserting.

## Never

- Approve your own work, or a change you authored under another name.
- Leave a blocking comment without saying what would unblock it.
- Rewrite the author's approach in a review comment. Propose it, and let them decide.