用途：在仓库范围内检测并修复反模式与一致性漂移，覆盖 React/TypeScript、命名、文件组织与模式统一。特点为“审计并修复”，不只报告：需修复所报告、已点名的文件中的发现；若要做报告中未列出的全仓重命名或重排，应另开一次会话处理。改动应外科手术式，只改有问题的 hook、key 或 import，而非重写整个文件；途中遇到的既有 bug 记为后续项。仅在任务要求或仓库已有相应测试时才新增或修改测试，一次性 grep 与临时脚本不进入提交。若针对某个 PR 或 diff，应改用 audit-code-review。
主要能力：Part 1 反模式（判断自由度较高）包括 props drilling、派生状态放进 useState、用 useEffect 取数、依赖数组里放对象/数组、动态列表用索引作 key、巨型组件，以及 TypeScript 中 any、enum 应换联合类型、缺少穷尽 switch，状态管理选择与过期闭包，架构上的循环依赖、组件内业务逻辑、god 文件。Part 2 一致性审计（约定性 grep 需严格照做）覆盖命名规范（组件 PascalCase、hooks 用 use 前缀、工具 camelCase、常量 SCREAMING_SNAKE、文件 kebab-case、布尔 props 用 is/has/should），文件组织建议 feature 切分（components/hooks/server/types.ts/schemas.ts），模式一致性（服务端状态是否统一 TanStack Query、表单统一 React Hook Form、错误处理形状、样式 cn()、测试约定）。
使用方式：改动前先运行给定命令确认既有约定，如 cat CONTRIBUTING.md .cursor/rules/*.md 2>/dev/null | head -100 与 git log --oneline -20 | grep -i "convention|pattern|style"，并用 git blame 判断“不一致”是否为有意为之。随后按严重度分级：运行时 bug 或数据请求 useEffect 为 High，仅命名问题为 Low。应用修复前做自检：有 file:line 或 rg 证据、可复现、严重度有理由、归属正确、避免误判。最后按仓库自身脚本验证：package.json 的 typecheck（否则 tsc --noEmit）、仓库自己的 lint 与 test 脚本，并确认无新增失败；将强制标准记入 CONTRIBUTING.md 或 .cursor/rules/。
限制：资料未提供具体支持的平台、收费方式或价格信息；工作范围限于仓库级审计与修复，不承担完整代码审查；grep 只能作为线索，真正判断仍需人工核实。