Run any Skill in Manus with one click

claude-review

Stars74

Forks343

UpdatedJune 12, 2026 at 15:56

Use when asked to independently review Claude-authored docs or code changes, Claude-generated diffs, or Claude PR work in the Redis docs repo.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

redis

redis/docs

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

File Explorer

3 files

SKILL.md

readonly

name	claude-review
description	Use when asked to independently review Claude-authored docs or code changes, Claude-generated diffs, or Claude PR work in the Redis docs repo.

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 for output format and severity.
references/claude-review-patterns.md for recurring review patterns.

Treat the pattern file as a map of places to inspect, not as evidence. The current diff and current workspace always win.

Workflow

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.
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.
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.
Produce findings first:
- Order by severity.
- Include precise file/line references.
- Explain the user-visible or maintainer-visible impact.
- Keep summaries secondary and brief.
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.

Suggest the update text, but do not apply it unless explicitly asked. New entries should follow the schema in claude-review-patterns.md.

More from this repository

same repository

park

redis/docs

Freeze a release-ready-pending-upstream branch as a parked PR — open (or update) the PR with a machine-diffable pickup manifest, apply the parked / do-not-merge labels, and deliberately defer /finalize so the episodic re-check notes survive. Use when docs are written against an unreleased or still-changing external source (an upstream PR, a preview feature) and must wait for it to ship before merging. Pairs with /pickup.

2026-07-1074

pickup

redis/docs

Thaw a parked PR — re-fetch each pinned source, diff it against the manifest snapshot taken at park time, report what changed vs what was predicted, then reconcile the docs and resume the normal pipeline (/reflect → /finalize) toward merge. Run with a PR number, or with no argument to scan all parked PRs and report which triggers have fired. Pairs with /park.

2026-07-1074

restructure-diagram

redis/docs

Create a before/after restructuring diagram for a docs section. Use when planning how to reorganise a folder under content/ — produces a draw.io-editable .drawio.svg with two identical columns (current structure left, a copy on the right) joined by arrows, so you can drag the right-hand boxes into their proposed new layout. Reads Hugo weight/linkTitle frontmatter.

2026-06-3074

finalize

redis/docs

Distil a PR's accumulated knowledge into the durable squash commit message — reconcile the /reflect experience notes across its commits with the review feedback into one end-state record, and propose promoting cross-cutting lessons to learning skills/memory. Use just before squash-merging a PR. Prepares the message and the gh merge command; does not merge.

2026-06-2674

reflect

redis/docs

Capture an agent experience note into the commit message — the lived reasoning behind a change (what was learned, what was rejected, what future-you must not break), written where the work happens so it travels with the code. Use right after finishing a meaningful chunk of coding/writing, when about to commit, or to amend the last un-pushed commit. Skip for mechanical changes. Feeds the squash-time distiller and the learning skills.

2026-06-2674

command-api-mapping

redis/docs

Map Redis commands to their client-library method signatures for the docs API-mapping tables. Use when adding or updating entries in data/command-api-mapping/ — e.g. a new command family (AR*, BF.*) or refreshing a client's signatures. Produces per-command JSON files in the repo's real schema, then merges them.

2026-06-1774

Claude Review

Required References

Read these before reviewing:

Treat the pattern file as a map of places to inspect, not as evidence. The current diff and current workspace always win.

Workflow

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.

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.

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.

Produce findings first:

Order by severity.
Include precise file/line references.
Explain the user-visible or maintainer-visible impact.
Keep summaries secondary and brief.

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.

Suggest the update text, but do not apply it unless explicitly asked. New entries should follow the schema in claude-review-patterns.md.