メニュー
Review code changes for correctness, security, performance, and maintainability. Use when reviewing pull requests, implementation output, or auditing code quality.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Implement a bounded code change from a request, spec, or implementation plan. Use when executing implementation work and choosing between quick, bounded, and tracked modes.
Manage tracked feature work with `.ai/current-work.md`, handoffs, and archive rules.
Turn a bounded functional spec into an implementation plan. Use when architecture, code structure, sequencing, migration, and verification must be decided before implementation.
Turn current context into a concise implementation spec. Use when a user wants to define what to build, capture requirements, or create a bounded technical/product spec before implementation.
Map a large or unclear initiative into facts, decisions, open frontier, and next work without writing a spec or implementation plan. Use when scope, architecture, dependencies, or sequencing are still genuinely uncertain before creating a spec.
Collapses deterministic multi-step repository research, aggregation, indexing, validation, and transformation into one small purpose-built local script and one Bash run. Use when a task would otherwise require 6+ related read/search/tool calls, iterates over many files or records, cross-references results, or requests batch analysis; do not use for small exploration or broad mutations.
| name | code-review-excellence |
| description | Review code changes for correctness, security, performance, and maintainability. Use when reviewing pull requests, implementation output, or auditing code quality. |
Review changes systematically. Prioritize impact. Be specific/actionable; no nitpicks while logic is wrong.
If context is missing, note it as a review limitation/finding.
Use exact file:line, issue, impact, suggested fix. Example:
src/api/handler.ts:42 — Query is not parameterized, creating SQL injection risk. Use prepared statement.
## Summary
[1-3 sentences: scope, overall assessment, top risk.]
## Blocking Issues
- `file:line` — [issue]. [impact]. [fix].
## Important Issues
- `file:line` — [issue]. [rationale/fix].
## Minor Issues / Suggestions
- `file:line` — [suggestion].
## Questions
- `file:line` — [unclear point and why it matters].
## Requirements Compliance
[Met/missing/partial requirements when source exists.]
## Test & Eval Results
[command -> pass/fail + short output summary; or not run + why.]
## Verdict
[Approve / Approve with minor fixes / Request changes] — [1-2 next actions].
When a plan exists, check tasks against actual changes, run eval gates when practical, flag skipped/partial tasks, and note intentional deviations.