菜单
Use when reviewing implemented code changes after the fact, especially to assess correctness, architecture, subsystem ownership, performance, naming, test quality, and remaining design debt with help from the review team in .agents/team.md.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Workflow guidance for codifying, reviewing, and iterating on AGENTS.md subsystem guides as codebase knowledge evolves, including subsystem purpose, design notes, known limitations, ownership boundaries, and routing maps.
Use when planning a non-trivial codebase change by researching current behavior, drafting a precise implementation proposal, and iterating on that proposal with the review team in .agents/team.md before implementation.
| name | review |
| description | Use when reviewing implemented code changes after the fact, especially to assess correctness, architecture, subsystem ownership, performance, naming, test quality, and remaining design debt with help from the review team in .agents/team.md. |
Inspect the working tree, changed files, and relevant diffs to understand the implementation. Read the owning subsystem AGENTS.md files, nearby source, public exports, tests, and representative call sites needed to judge the change in context.
Build a concise mental model of the intended behavior and the actual implementation. Identify the affected subsystems, data/control flow, public APIs, hot paths, tests, and any assumptions the implementation appears to make.
Read ../../team.md, choose the applicable reviewers, and spin up subagents for independent critique. Ask them to focus on blockers, follow-up debt, what landed well, and concrete suggestions. Use additional rounds when feedback reveals unresolved design questions.
Run or recommend validation appropriate to the risk: focused tests, typecheck, lint, benchmark suites, playground/browser checks, or golden tests. Do not treat validation as a substitute for code review.
Report findings first, ordered by severity and grounded in file/function references. Separate blockers from follow-up debt, call out test or benchmark gaps, and summarize what landed well only after the issues. Do not edit files unless the user explicitly asks you to address the findings.
