用途：审查 adk-python 工作树中未提交的改动，只报告问题，不主动修改文件。
主要能力：先通过 git status 与 git diff（暂存改动加 --staged）确定新增、修改和删除的文件；再逐文件按七个维度审查并输出报告。七个维度为：正确性（类型、导入、异常、类型判别、边界、前置条件）、设计（复杂度、耦合、性能、安全）、风格（对照 adk-style 技能检查可见性、类型、Pydantic v2、懒日志、导入、异步、文件组织）、架构与意外结果（公共 API 稳定性、Session/Artifact/Memory 服务字段新增所导致的破坏性变更、执行与恢复兼容性、并发与生命周期、数据库运行时 DDL 安全、改动范围）、文档影响、示例、测试。
使用方式：用户要求审查时，获取 diff 并逐文件检查，按优先级分组输出报告并给出文件路径和行号：Critical（错误、类型错误、竞态、资源泄漏、安全问题）、Design（复杂度、可读性、性能、架构偏差）、Style（lint、格式、非懒日志、类型不匹配）、Docs/tests/samples（缺失或过时）。报告后停止，等待用户要求修复；若用户要求修复，则应用修复并重跑受影响测试 pytest tests/unittests/{path} 和 pre-commit run --files {paths}。
适用场景：需要在提交前检查 adk-python 改动质量、评估是否会破坏公共 API 或下游存储后端、检查测试与文档覆盖时使用。
限制：只审查未提交的工作区改动；审查阶段不修改任何文件；公共 API 破坏性变更需要先有弃用周期；向 Session、ArtifactVersion、MemoryEntry 或各基础服务新增字段即视为破坏性变更；运行时启动路径不得执行 DROP INDEX 等破坏性 DDL，且需用 SAVEPOINT 处理多容器启动竞态；用户可见变更需在 adk-docs 仓库同步提交 PR。报告每条发现前需通过基类解析符号，正确性问题须指出会失败的输入，其他问题须引用所违反的规则或约定，无法做到的不应报告。分类：办公与效率。