القائمة
Use independent review at meaningful semantic or risk boundaries and before substantive whole-change closeout.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Consult after receiving review feedback and before implementation when the feedback needs evidence-based evaluation.
Consult before delegating implementation when an approved plan benefits from worker context isolation and durable coordination.
Consult before attempting a fix when root cause or behavior is unclear, failures repeat, components interact, or guessing would be unsafe.
Consult before implementing an observable behavior change when a meaningful automated test seam exists; use proportional red-green evidence.
Consult directly matching task playbooks before substantial design, debugging, implementation, review, or completion work without forcing full workflow execution.
Consult before making a substantive completion claim; require current trustworthy evidence and semantic acceptance.
| name | requesting-code-review |
| description | Use independent review at meaningful semantic or risk boundaries and before substantive whole-change closeout. |
Independent review supplies a perspective that implementation reports cannot. Place it where it changes confidence in semantic behavior, integration, or risk; do not manufacture a review merely to find a style issue or demonstrate process.
Low-risk mechanical work does not always need an independent reviewer by default.
Request independent review at meaningful semantic or risk boundaries, including user-visible behavior changes, API or compatibility boundaries, cross-module integration, and substantive implementation milestones. Request a final whole-change review for substantive work so the reviewer can assess the joined behavior rather than isolated diffs alone.
Short changes still merit independent review when they involve security, data-integrity, permission, concurrency, or cross-module behavior. Repeated low-risk mechanical changes that follow an already-reviewed pattern may be reviewed as a group, with the chosen semantic acceptance evidence preserved.
Give the reviewer the smallest durable package that permits real judgment:
Ask the reviewer to judge semantic behavior and integration: whether the change solves the intended user or operational problem, preserves its contracts, and works with neighboring modules. Style and maintainability findings matter when they threaten that behavior or future safe change; they are not a quota.
Fix Critical and Important findings before relying on the reviewed behavior. Record Minor findings when they have a clear owner or future decision. If a reviewer is wrong, respond with concrete code or semantic evidence rather than silencing the review.
After a fix, request another independent review only when the finding or fix changes semantic behavior, risk, or integration confidence. For a contained mechanical correction, preserve focused validation and the reason a further review would not add evidence.
Use the active harness's supported worker mechanism; do not assume a particular subagent API. Select reviewer capability proportional to the diff's risk and the judgment required. Reviewers are read-only and should return evidence-backed findings with file references and severity tied to impact.
See code-reviewer.md for the whole-change review template.
