メニュー
Use when requesting code review after implementing features, before merging, when stuck, or after fixing complex bugs. Structures what to provide reviewers and what output to expect.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use before any creative work — features, components, changes, or modifications. Guides structured design through collaborative dialogue before implementation. Triggers: "brainstorm", "design", "think through", "explore approaches", ambiguous requests, or requests with multiple valid interpretations.
Use after a problem has been solved and the solution verified working — captures the lesson as categorized documentation in docs/solutions/ with YAML frontmatter so future sessions can find it. Triggers: "compound", "capture learning", "document solution", "that worked", "it's fixed", "working now", "problem solved", "that did it", "doc-fix".
Use for extended multi-agent review with 14+ agents including conditional and language-specific reviewers. Appropriate for large changes, architectural shifts, migrations, or when standard review is not thorough enough. Triggers: "deep review", "thorough review", "full review", "extended review", "review everything", "maximum coverage".
Use to review brainstorm or plan documents before proceeding to the next workflow step. Applies structured self-review for completeness, clarity, consistency, feasibility, and YAGNI.
Use when implementation is complete and all tests pass — guides branch completion by presenting structured options for merge, PR, or cleanup.
Use when performing multi-agent code review after implementing features, before merging, or when reviewing PRs. Runs 5 core review agents in parallel plus a learnings researcher. Produces prioritized findings (P1/P2/P3) with todo files for tracking and resolution. Triggers: "review", "code review", "check before merge", "review PR", "run reviewers", "catch issues".
| name | requesting-code-review |
| description | Use when requesting code review after implementing features, before merging, when stuck, or after fixing complex bugs. Structures what to provide reviewers and what output to expect. |
Core principle: Give reviewers everything they need to evaluate your changes without follow-up questions.
Mandatory: after completing a feature, before merging to main, after fixing complex bugs.
Optional but valuable: when stuck, before refactoring, after architectural changes.
Every review request includes:
BASE_SHA=$(git merge-base origin/main HEAD)
HEAD_SHA=$(git rev-parse HEAD)
git diff --stat $BASE_SHA..$HEAD_SHA
Reviewers should return findings in this structure:
What is well done, with specific file:line references.
Critical (Must Fix): Bugs, security vulnerabilities, data loss risks, broken functionality.
Important (Should Fix): Architecture problems, missing error handling, test gaps, performance issues.
Minor (Nice to Have): Code style, minor optimizations, documentation improvements.
Each issue includes:
file:line referenceReady to merge? Yes / No / With fixes
Reasoning: One to two sentences of technical justification.
See the receiving-code-review skill for the full feedback-handling protocol.
| Workflow | When to Review |
|---|---|
| Subagent-driven development | After each task |
| Executing plans | After each batch of 3 tasks |
| Ad-hoc development | Before merge, or when stuck |