When should I use pwp-code-review?

Use it for code reviews, PRs, audits, or feedback on implementation quality; follow the checklist. Also perform the Self-Review Protocol before presenting results.

What are the severity levels and how should I apply them?

Blocker, Warning, Suggestion, Nit. Blocker must be fixed before merge; the others help guide priority and visibility.

What should code-review comments look like?

Use the standardized format like [SEVERITY] file:line — description, e.g., [Blocker] src/auth/login.ts:42 — Password comparison uses == instead of timing-safe comparison.

pwp-code-review

Scanned

npx machina-cli add skill shandar/pwp-plugin/pwp-code-review --openclaw

Files (1)

SKILL.md

4.0 KB

Code Review Skill

This skill defines how to perform a structured code review. Use it when reviewing your own output before presenting to the user, or when asked to review existing code.

Review Mindset

You are a reviewer, not an author. Your job is to find problems, not defend choices.
Every comment must be actionable. "This could be better" is not a review comment. "Extract this into a utility function to reduce duplication with line 45" is.
Prioritize correctness over style. A bug matters more than a naming preference.

Review Checklist

For every code change, check the following in order:

1. Correctness

Does the code do what it claims to do?
Are all edge cases handled? (null, empty, boundary values, error states)
Are async operations properly awaited? Error-handled?
Are types correct and strict? (no any escapes, no type assertions without justification)

2. Security

Is user input sanitized before rendering or database writes?
Are secrets kept out of client code?
Are permissions checked server-side, not just hidden in UI?
Are dependencies from trusted sources?

3. Readability

Can you understand the code without the author explaining it?
Are variable and function names descriptive and consistent?
Is the code structured logically? (related things together, clear flow)
Are comments present where the why isn't obvious? Absent where it is?

4. Performance

Are there unnecessary re-renders, re-fetches, or re-computations?
Are large operations debounced or throttled?
Are heavy modules lazy-loaded?
Is data fetching efficient? (no N+1 queries, no over-fetching)

5. Maintainability

Is the code DRY without being over-abstracted?
Are there magic numbers or hardcoded values that should be constants?
Is the change scoped correctly? (no mixed concerns in one commit)
Will the next developer understand this in 6 months?

6. Testing

Is the change tested? (new behavior has tests, bug fixes have regression tests)
Are tests testing behavior, not implementation?
Are test names descriptive?

Severity Levels

Level	Meaning	Action Required
Blocker	Bug, security flaw, or data loss risk	Must fix before merge
Warning	Logic concern, missing edge case, performance issue	Should fix; merge with caution if deferred
Suggestion	Readability improvement, naming preference, minor optimization	Optional; author decides
Nit	Formatting, whitespace, trivial style	Fix if easy; ignore if not

Comment Format

[SEVERITY] file:line — description

Example:
[Blocker] src/auth/login.ts:42 — Password comparison uses == instead of timing-safe comparison.
[Warning] src/hooks/useCart.ts:18 — Missing cleanup in useEffect return. Will cause memory leak.
[Suggestion] src/utils/format.ts:7 — Consider renaming `fmt` to `formatCurrency` for clarity.

Self-Review Protocol

Before presenting any code to the user:

Re-read every line you changed
Run through the checklist above mentally
Flag anything you're less than 90% confident about
Verify the change compiles and builds
Confirm you haven't modified files outside the declared scope

Anti-Patterns

Rubber-stamp reviews: Approving without actually reading. Never.
Style-only reviews: Catching semicolons but missing null pointer exceptions.
Ego reviews: Rewriting working code to match personal preference.
Drive-by comments: Pointing out issues without suggesting fixes.

Source

git clone https://github.com/shandar/pwp-plugin/blob/main/skills/pwp-code-review/SKILL.mdView on GitHub

Overview

Code Review Skill provides a structured, repeatable process for evaluating code changes. It emphasizes correctness, security, readability, performance, maintainability, and testing, with an explicit checklist and actionable comments. Use it when reviewing PRs, auditing files, or giving feedback on implementation quality.

How This Skill Works

It applies a six-area checklist (Correctness, Security, Readability, Performance, Maintainability, Testing) to every change in order. For each issue, you provide an actionable comment that includes a severity tag and the file:line reference, using the standardized [SEVERITY] format. Before presenting results, perform the Self-Review Protocol to ensure you did not miss edge cases and that nothing outside the scope was changed.

When to Use It

When you need a formal review of code, a PR, or an audit of a file.
When asked questions like 'review this', 'is this code good', 'check my work', or 'what do you think of this implementation'.
When evaluating implementation quality across correctness, security, readability, performance, and maintainability.
When verifying edge cases, error handling, and testing coverage.
Before presenting code to a user, perform a self-review to confirm scope and build success.

Quick Start

Step 1: Re-read every line you changed.
Step 2: Run through the Review Checklist in order: Correctness, Security, Readability, Performance, Maintainability, Testing.
Step 3: Write actionable, severity-tagged comments and verify the change builds.

Best Practices

Start with correctness and edge-case coverage before style.
Make every comment actionable with concrete guidance (e.g., extract to a utility).
Anchor findings to the Review Checklist order for consistency.
Keep changes scoped and DRY; avoid mixed concerns and magic numbers.
Use the Severity Levels to communicate urgency and impact clearly.

Example Use Cases

Review a PR for a login module to catch correctness, security, and timing-safety concerns.
Audit a file to ensure proper input validation and safe handling of user data.
Spot potential N+1 queries in a data fetch path and suggest batching or lazy loading.
Flag secrets or API keys leaking into client code and recommend removing them.
Propose a concrete refactor, such as extracting duplicated logic into a utility function.

Frequently Asked Questions

Add this skill to your agents