菜单
Request or perform a git-backed code review for a defined diff or SHA range using implementation context and requirements. Use when finishing a task, completing a major feature, preparing to merge, or when you need a fresh review before proceeding.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Create and maintain repository-aware technical plans, implementation plans, refactor proposals, design drafts, and migration plans. Use when Codex is asked to investigate a codebase and propose a solution before implementation; write or update a durable plan file; produce a 方案、实施计划或重构计划; split engineering work into phases or pull requests; document scope, non-goals, API and behavior decisions, breaking changes, migrations, risks, testing, or validation; or transition a plan through draft, planned, in-progress, blocked, and completed states.
Create GitHub pull requests from a local branch using a reviewable workflow for branch checks, diff analysis, PR title/body writing, and gh CLI creation. Use when opening a PR, drafting or improving a PR description, preparing a branch for review, or adding reviewers on GitHub.
Create GitLab merge requests from a local branch using a reviewable workflow for branch checks, GitLab host detection, diff analysis, title and description writing, and `glab mr create`. Use when opening a GitLab merge request, drafting or improving merge request copy, preparing a branch for review, or working across GitLab.com and self-managed GitLab instances.
Inspect, triage, approve, and merge GitHub Renovate pull requests with gh. When no repository is provided, use the default preset repository set, build a candidate execution plan, and execute only after explicit user confirmation. Use when the user asks to check, batch-handle, approve, or merge Renovate PRs.
Scaffold a project-local memory directory and AGENTS.md guidance for reusable agent knowledge. Use when a user wants to initialize `.agents/memories/` or another project memory path so future agents can read and maintain durable project context.
High-bar review for changes in open-telemetry/opentelemetry-go with strict standards for correctness, compatibility, and performance.
| name | code-review |
| description | Request or perform a git-backed code review for a defined diff or SHA range using implementation context and requirements. Use when finishing a task, completing a major feature, preparing to merge, or when you need a fresh review before proceeding. |
| metadata | {"name":"Code Review","description":"Review a defined git-backed change set for bugs, regressions, missing requirements, and test gaps before merge.","author":"Flc゛","created":"2026-03-14T14:54:38.000Z"} |
Request or perform code review before issues compound.
Act as a pragmatic review coordinator first, and a reviewer second.
Prioritize:
Review early and review often.
Follow this sequence unless the user asks for only one part of the review flow.
Choose the smallest meaningful diff to review.
Prefer:
git merge-base origin/main HEAD to HEADHEADHEAD~1 to HEADUse commands such as:
git merge-base origin/main HEAD
git rev-parse HEAD
git log --oneline --decorate -n 10
If the change set is too large or mixes unrelated work, call that out and split the review scope before continuing.
Capture the minimum context a reviewer needs:
BASE_SHA and HEAD_SHADo not rely on session history. Summarize the relevant context explicitly.
If a dedicated review subagent or local review skill is available, dispatch it with the prepared scope and context.
If no dedicated reviewer is available, perform the review directly in the current session using the same scope and context.
When delegating, pass only the material needed for review:
BASE_SHAHEAD_SHAInspect the diff against the stated requirements.
Focus on:
Prefer review commands such as:
git diff <base>..<head>
git log <base>..<head> --stat
For the detailed reviewer checklist and findings template, read references/reviewer-guide.md.
Report findings first.
Use this structure:
# Review Findings
## Critical
- <issue with file/line and impact>
## Important
- <issue with file/line and impact>
## Minor
- <issue with file/line and impact>
## Open Questions
- <missing context or assumption>
## Assessment
- Ready to proceed / Fix important issues first / Blocked
Keep findings concrete. Include file and line references when available. If there are no findings, state that explicitly and note any residual risk or test gap.
Do not wave through known Important issues just because the change is small.
Use this when preparing a review request:
# Review Request
## What Was Implemented
<what changed>
## Requirements
<plan, ticket, acceptance criteria, or intended behavior>
## Scope
- BASE_SHA: <sha>
- HEAD_SHA: <sha>
## Notes for Reviewer
- risks, edge cases, or areas needing extra scrutiny
HEAD~1 only for truly single-commit reviews.Stop and reassess if:
BASE_SHA or HEAD_SHA