github/penpot
1
0
Fork 0
mirror of https://github.com/penpot/penpot.git synced 2026-09-14 16:09:01 +00:00
Code Issues Packages Projects Releases Wiki Activity
penpot/.opencode/commands/review-code.md
Andrey Antukh 32d313b0c8 🎉 Add planning and review agent commands 
Add the planning/review command suite for opencode and align the
planner skill with it:

- /make-a-plan (build agent): researches the session subject, drafts
  the plan with the planner skill, asks open questions, then saves
  the final plan to .opencode/plans/.
- /review-plan: reviews a plan with the plan-review skill; on
  approval suggests /implement-plan, on request changes /make-a-plan.
- /review-code: reviews a diff, PR, or code change with the
  code-review skill; suggests /make-a-plan for substantive findings.

All commands run as the build agent with explicit read-only rules
that expire when the command's work is done, so follow-up requests
need no agent switching. The planner skill no longer writes the plan
file on its own: it saves only when a command or the user explicitly
instructs it, and it suggests /review-plan and /implement-plan as
next steps.

AI-assisted-by: omen-alpha
2026-09-08 15:40:15 +00:00

2.8 KiB
Raw Blame History

description, agent
description agent
Code review — review a diff, PR, or code change with the code-review skill (read-only while reviewing) build

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

Instructions

  1. Determine what is being reviewed from the user context or arguments: 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.
  2. Delegate the review to the general subagent (via the task tool), unless the user specifies another agent. Include in the prompt the code-review skill name and all user context.
  3. When the subagent returns, output the review to the user verbatim. Do not summarize it and do not act on its findings.
  4. 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 command 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

  1. Load the code-review skill and follow its process and output format.
  2. Read AGENTS.md (if present) and follow its instructions for finding and reading all related testing documentation from memories before reviewing.
  3. 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

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

User input, overrides and additional context

$ARGUMENTS