Agent Skills › penpot/penpot › review-code

review-code

GitHub

用于执行代码审查流程，接收用户关于Diff、PR或代码变更的审查请求。通过委托给子代理并遵循特定审查标准，输出结构化审查结果及后续操作建议，全程保持只读模式。

.agents/skills/review-code/SKILL.md penpot/penpot

Trigger Scenarios

用户要求审查代码、Diff或PR 在合并前希望评估提交、分支或差异

Install

npx skills add penpot/penpot --skill review-code -g -y

More Options

Non-standard path

npx skills add https://github.com/penpot/penpot/tree/develop/.agents/skills/review-code -g -y

Use without installing

npx skills use penpot/penpot@review-code

指定 Agent (Claude Code)

npx skills add penpot/penpot --skill review-code -a claude-code -g -y

安装 repo 全部 skill

npx skills add penpot/penpot --all -g -y

预览 repo 内 skill

npx skills add penpot/penpot --list

SKILL.md

Frontmatter

{
    "name": "review-code",
    "slash": true,
    "description": "Code review flow — review a diff, PR, or code change, delegating the review to a subagent that follows the code-review-criteria skill. Use it when the user asks to review code or a PR, in any phrasing."
}

Review Code

Act as a senior software engineer and perform a thorough code review.

When to use

The user asks to review code, in any phrasing: "review this diff", "review the PR", "check my changes", "code review" — or runs /review-code.
A commit, branch, PR, or diff is ready and the user wants it assessed before merge.

Instructions

Determine what is being reviewed from the user context: a working-tree diff, a commit range, a branch, a PR (number or URL), or specific files. If the target is ambiguous, ask before reviewing.
Delegate the review to the general subagent (via the task tool), unless the user specifies another agent. Include in the prompt the code-review-criteria skill name and all user context.
When the subagent returns, output the review to the user verbatim. Do not summarize it and do not act on its findings.
Right after the review, suggest how to proceed based on the findings. These are suggestions — the user decides:
- Approve (no required changes): say so — there is nothing to address.
- Minor findings (nits): applying them directly as-is is fine once the review is done — no plan needed.
- Substantive findings: suggest /make-a-plan to make a plan to address them.

Hard rule — read-only while reviewing

This flow is read-only for the duration of the review: from the moment it starts until the user considers the review finished (including any feedback, questions, or clarifications about it). During that period, never fix, implement, edit files or create commits — not even "obvious" fixes derived from the findings. Once the user explicitly states the review is done (or moves on to a different task), this rule no longer applies and you act as a normal build agent again.

Instructions for the subagent

Load the code-review-criteria skill and follow its process and output format.
Read AGENTS.md (if present) and follow its instructions for finding and reading all related testing documentation from memories before reviewing.
Return in your final message the COMPLETE review, verbatim, exactly as the skill instructs it to be produced. Do not summarize it — include the full structured review.

Strong rules for the subagent

Do not invent problems. Every finding must be real and actionable.
Read-only: do not modify any file and do not create a commit — reviewing never writes.
Be specific and constructive. "This could be better" is not helpful — explain why and how.
Prioritize by impact. One structural issue outweighs ten nits.
Missing tests are an issue, not a suggestion. Report as a severity-tagged finding — never as a recommendation.
Skip generated files, lockfile-only changes, and unrelated modifications unless they introduce security risks.