القائمة
Run a Codex-native structured code review using agmo-critic and agmo-verifier where evidence is needed.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | code-review |
| description | Run a Codex-native structured code review using agmo-critic and agmo-verifier where evidence is needed. |
| argument-hint | [plan path, diff scope, or review request] |
Use this skill when the user asks for code review or when an implementation needs a structured review before handoff. The main session stays in orchestration mode and delegates review evidence to existing native roles.
git diff --name-only and git diff --stat to identify the review scope.Delegate plan/spec comparison to agmo-critic.
Check whether each planned item was implemented, acceptance criteria are met, and "must not" constraints were respected. If no plan exists, skip this stage and state that review is diff-scoped.
Delegate quality review to agmo-critic.
Review for:
For the over-engineering lens, use exactly these tags:
delete: dead or speculative codestdlib: hand-rolled standard library behaviornative: behavior already supplied by the platform/frameworkyagni: abstraction, config, or layer with a single implementationshrink: same behavior with less codeFormat each over-engineering finding as:
<location>: <tag> <what>. <replacement>.
End that lens with net: -N lines possible. or Lean already. Classify these findings as IMPORTANT or MINOR unless they independently create correctness, security, or performance risk.
When review claims depend on commands, logs, or tests, delegate concrete proof to agmo-verifier or run the relevant verification directly. Do not claim tests passed without fresh output.
Report:
APPROVE or REQUEST_CHANGESnot applicablegit diff --name-onlyUse as the canonical first-stage Agmo workflow when the user wants idea exploration, design tradeoffs, or requirement shaping before planning or implementation.
Harvest `debt:` markers across the repo into a read-only ledger without modifying code.
Audit and maintain the vault-backed llm-wiki knowledge base, including stale pages, low-confidence or contested captures, superseded captures, missing frontmatter, and broken wikilinks.
Use when prior notes, durable project knowledge, or vault-backed context should influence the current task.
Use when one execution lane is no longer enough and work should escalate to the durable `agmo team ...` runtime.
Use when the user wants a GitHub issue created from the current conversation or repo context. Triggers on requests like "이슈 만들어", "깃허브 이슈", "create issue", or "new issue". If the source artifact is an existing vault note, use `note-to-issue` instead.