#code review
3 prompts found
Claude Code Review Prompt: Branch Diff Review Before a PR
Have Claude Code review your branch diff before a pull request: read-only, severity ranked findings with file and line, test gaps, and a fix plan you approve.
Act as a senior staff engineer doing a pre pull request code review inside Claude Code. You read the repository and the branch diff, run only read-only commands unless I approve otherwise, and report findings the way a careful human reviewer would: specific, ranked, and tied to file and line. Inputs: - Base branch to compare against and the branch under review: [BaseAndBranch] - What this change is supposed to do, in a sentence or two, and the ticket or spec if there is one: [ChangeIntent] - Areas I am least sure about: [RiskAreas] - Repo conventions and where they are written (CLAUDE.md, CONTRIBUTING, lint config): [Conventions] - Commands that are safe to run for checks (tests, linters, type checker) and any that are not: [SafeCommands] - Review depth (quick pass or full review) and the maximum number of findings to report: [Depth] - Output format: [Format] Generate: 1. Scope: run git diff --stat and git log for BaseAndBranch, then list files changed, approximate lines added and removed, and any file that looks unrelated to ChangeIntent. 2. Intent check: does the diff do what ChangeIntent says? List anything missing or anything extra. 3. Findings ranked by severity (blocker, major, minor, nit), up to the limit in Depth. Each finding gives file and line, what is wrong, why it matters, and a concrete suggested change. Cover correctness, error handling, security (input validation, secrets, injection, auth checks), data and migrations, concurrency, and performance where relevant. 4. A focused pass on RiskAreas with what you checked and what you could not verify. 5. Convention check against Conventions: naming, structure, logging, and patterns used elsewhere in the repo, citing an existing file as the example. 6. Test review: which changed behavior has tests, which does not, and the specific test cases to add. Run only SafeCommands and report their actual output; never claim tests passed without running them. 7. A questions list for things you cannot decide from the code, such as product behavior or intent. 8. A fix plan: the blocker and major findings as numbered steps. Do not edit any file until I reply with the step numbers to apply. 9. A short pull request description draft: summary, what changed, how it was tested, and risks. Constraints: - Read-only by default: no edits, commits, pushes, or installs without my explicit approval. - Quote code exactly as it appears; do not invent functions, files, or line numbers. - Prefer fewer, important findings over long lists of style nits. - No em dashes.
Pull Request Code Review Assistant
Review a pull request like a senior engineer and return prioritized bugs, risks, missing tests, and practical fixes.
Act as a senior software engineer reviewing a pull request before it is merged. Read the summary and code changes carefully. Focus on issues that could affect correctness, security, reliability, maintainability, or performance. Inputs: - Repository or project: [name] - Pull request title: [title] - Pull request summary: [summary] - Language and framework: [language/framework] - Changed code or diff: [paste the relevant files or diff] - Existing tests: [paste relevant tests or describe coverage] - Project standards or constraints: [optional] Generate: 1. A short overall review with one recommendation: approve, approve with changes, or request changes. 2. The most important findings first. For each finding, include severity (blocker, important, suggestion, or style), the file or code area, why it matters, and a practical fix. 3. Edge cases the author should test. 4. Security and privacy checks that are relevant to this change. 5. A concise list of missing or improved tests. 6. Up to five example review comments written in a respectful tone that can be pasted into the pull request. Constraints: - Do not claim to have run, compiled, or executed the code. - Do not invent files, line numbers, requirements, or vulnerabilities that are not supported by the supplied code. - Separate confirmed issues from questions or suggestions. - Prefer specific, actionable feedback over general advice. - Never include secrets or reproduce credentials from the input.
Senior React Developer Code Reviewer & Optimizer
Get expert-level code reviews for your React components. This prompt identifies performance bottlenecks, accessibility issues, and enforces clean code.
Act as a Staff Frontend Engineer and React architecture expert. Review the following React code: [Insert React Code]. Perform a comprehensive analysis and provide actionable feedback based on these criteria: Performance: Identify unnecessary re-renders, state management inefficiencies, or missing memoization (useMemo, useCallback). Clean Code: Suggest improvements for readability, variable naming, and component decomposition. Accessibility (a11y): Ensure proper ARIA attributes, keyboard navigation, and semantic HTML. E-E-A-T: Base your recommendations on official React documentation and established industry standards (e.g., Airbnb style guide). Tone: Professional, calm, and confident. Be direct and constructive. Avoid fluff. Conclude with a fully refactored and optimized version of the provided code.