القائمة
Review code changes for correctness and quality before merging. Use after implementing a meaningful chunk or feature, between plan tasks, or before opening a PR — to catch issues while they're cheap.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Query forge's live, always-fresh code map — a dependency graph of the repo with god-nodes, modules, and neighbors/impact (blast-radius) queries. Use before editing to know what depends on a file, to find the most-depended-on hotspots, to map an unfamiliar codebase's architecture, or whenever you need current structural context instead of guessing.
Build an accurate mental map of unfamiliar code before changing it. Use when starting work in a codebase or area you don't know well, before editing code whose ripple effects you can't predict, or when the user asks how something works or where something lives.
Design the shape of a non-trivial module, API, or system before implementing it. Use when a design decision has more than one reasonable answer, when introducing a new abstraction or interface, or when getting the shape wrong would be expensive to undo.
Turn a vague idea into an approved, written spec before any code is written. Use before building a feature, adding functionality, or changing behavior — whenever the work is more than a trivial mechanical edit and the requirements aren't already pinned down.
Find the root cause of a bug, test failure, or performance regression before proposing any fix. Use the moment something is broken, throwing, failing, flaky, or slower than expected — and resist the urge to patch first.
Build or redesign frontend UI that doesn't look templated or AI-generated. Use when creating components, pages, landing pages, or restyling existing UI — before writing CSS/markup, and before shipping any visual work.
| name | review |
| description | Review code changes for correctness and quality before merging. Use after implementing a meaningful chunk or feature, between plan tasks, or before opening a PR — to catch issues while they're cheap. |
██████╗ ███████╗██╗ ██╗██╗███████╗██╗ ██╗
██╔══██╗██╔════╝██║ ██║██║██╔════╝██║ ██║
██████╔╝█████╗ ██║ ██║██║█████╗ ██║ █╗ ██║
██╔══██╗██╔══╝ ╚██╗ ██╔╝██║██╔══╝ ██║███╗██║
██║ ██║███████╗ ╚████╔╝ ██║███████╗╚███╔███╔╝
╚═╝ ╚═╝╚══════╝ ╚═══╝ ╚═╝╚══════╝ ╚══╝╚══╝
The reviewer must not be the author. A self-review shares the exact blind spots that produced the bug. Dispatch a fresh subagent with crafted context — the diff plus the originating spec/issue — not your session history. The reviewer should reach its verdict without your reasoning leaking in. If you can't spawn a subagent, simulate the reset: review strictly from the diff + spec, deliberately setting aside your implementation reasoning.
Run these reviews so they don't pollute each other (ideally as parallel subagents that never see each other's findings), then present them side by side without merging or reranking:
Keep them separate because a change routinely passes one and fails another. A merged review lets one mask the others.
First run the repo's own lint / typecheck / test commands and confirm they're green; then the Standards reviewer can skip what tooling already enforces (formatting, lint) and spend its attention on judgment calls. Never skip a check you didn't actually run.
Assume there are problems and go find them. "I found zero issues" almost always means you weren't looking hard enough. A clean verdict is only valid if you inspected every changed hunk and can name the single riskiest line you considered and why it's actually safe.
forge:principles #2).Fix Critical/Important, then forge:verify with evidence, then forge:ship.