Code Quality Review 是一个代码质量审查技能，用于对 Dune 应用进行代码质量、可维护性与整洁代码方面的检查。按资料说明，它应在 PR 评审之前、功能完成之后，或需要检查代码质量时使用。使用时审查 $ARGUMENTS（若无参数则审查整个应用），并按顺序执行全部步骤，报告所有发现，并附带文件路径与行号。
一、用途与执行方式 该技能的核心用途是对 Dune 应用做系统性代码质量审查，输出结构化报告。执行时按步骤进行，不要静默跳过任何步骤；若某步未发现问题，应写明“No issues found”。
二、审查步骤 第 1 步——先运行 linter 在人工阅读代码之前，先用自动化工具获取基线：
- pnpm run lint：列出每个错误与警告。所有错误必须先修复再继续——lint 错误不可协商；警告应审查并解决，除非有记录的例外。
- pnpm exec tsc --noEmit：以严格模式运行 TypeScript 编译器，暴露隐藏的类型问题，列出每个类型错误并必须修复。
第 2 步——TypeScript 类型安全 2a 消除 any 类型：搜索 any 用法（: any、as any、<any>），逐个替换为正确类型。常见替换：未知外部数据用 unknown + 类型守卫或 Zod 解析；事件处理器用 React.ChangeEvent / React.MouseEvent 等；CDF 响应用 SDK 自带响应类型（从 @cognite/sdk 导入）；数组用带正确泛型的 T[]；as any 用类型收窄或显式重载签名。目标是 src/ 中零 any；若第三方库强制要求，应包一层带类型的适配函数，避免 any 泄漏进应用。 2b 让不可能状态不可表示：用类型系统让非法状态在编译期失败。包括 branded types（示例为 PhoneNumber 品牌类型，在边界处校验一次，下游信任该类型；若项目使用原生支持品牌类型的库如 Effect，则使用其原语）；用可辨别联合替代标志位组合（把 loading/user/error 这类可能非法组合改为带 status 的联合类型），并搜索 loading?、isLoading.*isError、isSuccess.*isError 等标志位模式，将组合布尔标志的类型标记为应改为可辨别联合。 2c 让类型端到端流动：DB schema → server → client 应共享类型而非手工重复；在写新接口前优先使用 Pick、Omit、Parameters、ReturnType、Awaited、typeof 派生类型。标记手工重复 SDK 或 DB 类型字段的 interface，应改用 Pick/Omit。 2d 传对象而非位置参数：两个及以上同类型基本参数的函数应改为命名属性对象，避免调用方静默交换参数。
第 3 步——检查组件体积与单一职责 列出所有 .tsx 文件及其行数，标记超过 150 行的组件文件并逐一阅读，检查是否做了不止一件事（如同时取数据、渲染 UI、处理表单状态），取数逻辑能否移到自定义 hook（如 useAssetData），子区块能否抽为具名子组件。仅在能真正带来更清晰分离时才拆分，不只为行数拆分；一个命名良好的 200 行组件优于三个命名糟糕的 60 行组件。
第 4 步——查找并移除重复逻辑（DRY） 搜索 hooks、工具与组件间复制粘贴的模式，例如重复的 sdk.assets/timeseries/events/files 的 list/retrieve、重复的格式化函数（toLocaleDateString、toLocaleString、new Date()）、重复且超过 40 字符的 className 字符串。对每组重复：纯函数抽到 src/utils/，含 React 状态或副作用的抽到 src/hooks/，JSX 抽为共享组件。
第 5 步——对外部调用强制依赖注入 组件与 hooks 不得直接导入 CDF 客户端，SDK 客户端必须通过 context（useCogniteClient() 或 prop）获得，以便组件可独立测试。应标记在应用 bootstrap/认证设置文件之外直接构造客户端（new CogniteClient / createCogniteClient）的代码。Atlas 工具同样应通过 execute 闭包引用 hook 提供的 ref 来接收依赖，而非导入全局单例。
第 6 步——验证编码模式与可测试性 检查代码库是否遵循 Dune 应用评审要求的三个核心模式。 6a 通过 React context 的依赖注入：hooks 应通过 context 类型声明依赖并用 useContext 消费，而非直接导入；对非 React 代码（工具、服务）使用带部分依赖覆盖的工厂函数。应标记直接导入依赖而非经 context 接收的 hook，即便当前已有测试，这也是可测试性隐患。 6b 基于接口的服务：服务类必须实现显式 TypeScript 接口，以保持生产代码可替换、测试替身类型安全。应标记未实现显式接口的服务类，以及生产或测试代码中的 as unknown as T 强制转换（表明接口设计不佳）。 6c ViewModel 模式：页面级 hook（useSomethingViewModel）必须将业务逻辑与展示分离；UI 组件只接收数据与回调，不含取数、副作用逻辑或直接 SDK 调用。应标记含 useQuery、useMutation 或直接 SDK 调用的页面组件，以及数据逻辑不平凡却缺少 ViewModel hook 的页面。 6d 测试 mock 质量：应标记无注释说明（为何不能用 context 注入）的 vi.mock 用法，以及测试文件中的 as unknown as T 转换。
第 7 步——检查命名规范 资料给出的命名约定包括：文件与目录用 kebab-case（asset-panel.tsx、use-asset-data.ts）；React 组件用 PascalCase（AssetPanel、NavigationBar）；变量、函数、hooks 用 camelCase（isLoading、fetchAssets、useAssetData）；模块级常量用 SCREAMING_SNAKE_CASE（MAX_ITEMS、AGENT_EXTERNAL_ID）；TypeScript 类型与接口用 PascalCase（AssetNode、ChartConfig）；布尔变量用助动词前缀（isLoading、hasError、canEdit）。并搜索常见违规：文件名以小写字母开头的 .tsx 组件，以及 src/hooks 下未以 use 开头的文件。
第 8 步——移除死代码 搜索连续 3 行及以上的注释代码块、console.log/debug/warn/error/info 语句、TODO/FIXME/HACK/XXX 注释、未被任何地方导入的未使用文件，以及路由定义但其组件从未被导入或渲染的页面。规则：console.log 与 console.debug 必须在发布前移除（错误日志用 console.error）；注释掉的代码块必须移除（版本控制保留历史）；早于当前迭代的 TODO/FIXME 应解决或转为跟踪问题；未使用导入由 linter（第 1 步）捕获，需确认已清理。硬性门槛：不可达页面、完全未使用的文件与显著死代码块必须在批准前移除，这些是阻断性发现。
第 9 步——验证文件与导出结构 每个功能区域应遵循一致结构，资料给出的布局：src/ 下含 components/（共享展示组件，子目录含 <name>.tsx 与 re-export 公共 API 的 index.ts）、hooks/（每个文件一个 hook）、utils/（无 React 的纯工具函数）、contexts/（React context providers）、pages/ 或 views/（路由级组件）、types/（共享 TypeScript 类型）。应标记：业务逻辑直接放在页面组件中（应放入 hooks）、工具函数放在组件文件内（应放入 utils/）、跨多文件使用的类型内联定义在组件文件中（应放入 types/）、组件目录缺少 index.ts barrel 文件导致导入冗长。
第 10 步——报告发现 产出按类别分组的结构化报告，列包括 Category、File、Line、Issue、Recommendation（示例：TypeScript 中的 as any 强制转换应导入并使用 NodeItem 类型；Size 中 340 行混合取数与渲染应抽出 useDashboardData hook；DRY 中重复的日期格式化应抽到 src/utils/formatDate.ts；Naming 中文件名未以 use 开头应改名；Dead code 中的 console.log 应移除）。最后按类别汇总发现总数，列出应优先处理的最高影响项；任何 any 类型与 lint 错误必须视为阻断性，需单独列出。
三、适用场景与限制 适用场景：Dune 应用在 PR 评审前、功能完成后，或需要检查代码质量、可维护性、整洁代码问题时进行系统性审查。 限制：资料未提供该技能的收费方式、价格、平台信息或安装命令；也未说明除上述步骤外的其他功能。该技能面向 Dune 应用（使用 pnpm、TypeScript、@cognite/sdk、@cognite/sdk 与 Dune 认证 context 等），部分命令同时给出了跨平台与 PowerShell 形式。输出为审查报告，不自动改写代码。