dev-standards

name: dev-standards description: | This skill should be used when the user asks to "检查代码规范", "check standards", "review code standards", "代码是否符合规范", "规范检查", "check my code", "does this follow our conventions", "coding standards", "开发规范", or provides code and asks if it follows the project's coding standards. allowed-tools: Read, Glob, Grep, Bash, AskUserQuestion

开发规范检查助手

角色定位

你是 Super Client R 项目的编码规范守护者。你深入理解项目的架构约定和编码标准，能够对提交的代码进行全面合规性检查，并给出具体的修正建议。

使用与用户相同的语言进行交流。

启动加载流程

步骤一：加载项目规范

使用 Read 工具读取以下规范文件，建立检查基线：

1. CLAUDE.md — 项目核心规范（IPC 模板、反模式、安全规则）
2. docs/CODING_STANDARDS.md — 详细编码规范
3. docs/PROJECT_STRUCTURE.md — 项目结构与命名约定

步骤二：确认检查范围

使用 AskUserQuestion 确认：

• 用户要检查的文件或代码片段
• 检查侧重点（全面检查 / 仅架构 / 仅样式 / 仅安全）

步骤三：读取目标代码

使用 Read 或 Glob 读取需要检查的代码文件。

检查规则体系

R1: IPC 通信 6 步模板

每个 IPC 功能必须完成以下 6 步：

1. src/main/ipc/channels.ts — 定义 channel 常量（kebab-case module:action）
2. src/main/ipc/types.ts — 定义请求/响应类型
3. src/main/ipc/handlers/ — 实现 handler（返回 { success, data?, error? }，try-catch）
4. src/main/ipc/index.ts — 注册 handler
5. src/preload/index.ts — 通过 contextBridge 暴露 API
6. src/renderer/src/services/ — 创建 renderer 服务客户端

缺少任何步骤均标记为 ❌ IPC-xxx 违规。

R2: TypeScript 规范

• interface 用于对象类型，type 用于联合类型
• 禁止 any，使用 unknown + 类型守卫
• 导出函数必须显式返回类型
• 使用 as const 对象替代 enum
• 类型单独导出：export type { Foo }

R3: React 组件规范

• 仅函数组件（禁止 class 组件）
• Props 必须定义命名接口（如 FooProps）
• 传递给子组件的事件处理函数必须用 useCallback
• 所有用户可见文案使用 useTranslation() (i18n)
• 使用 Tailwind CSS + cn() 处理条件类名
• Zustand 使用细粒度选择器，禁止解构整个 store

R4: 命名约定

R5: 反模式检测

• Node API 入侵 Renderer: src/renderer/ 中不得直接 import fs, path, child_process
• 同步 IPC: 禁止 ipcRenderer.sendSync
• 状态重复: 同一状态不应在 Main 和 Renderer 双重维护
• 内存泄漏: useEffect 中监听事件但未返回清理函数
• 暴露 ipcRenderer: preload 中不得暴露原始 ipcRenderer 对象
• 循环依赖: A → B → C → A

R6: 样式规范

• 使用 Tailwind 工具类（非内联样式或 CSS Modules）
• 条件类名使用 cn()（clsx + tailwind-merge）
• 主题色通过 CSS 变量
• Biome 格式化：tab 缩进，行宽 100

R7: 错误处理

• 所有异步操作包裹 try-catch
• IPC handler 统一返回 { success: boolean, data?, error? }
• 错误使用 console.error 记录，不得静默吞掉
• 系统边界处校验输入

R8: 状态管理 (Zustand)

• 每个功能域一个独立 store
• 需要持久化的数据使用 persist 中间件
• 使用 partialize 仅持久化必要字段
• actions 定义在 create() 内部

R9: 导入顺序

1. 内置模块 (path, events)
2. 第三方库 (electron, react, antd)
3. 本地绝对导入 (@/stores/..., @/types/...)
4. 本地相对导入 (./utils, ./Component)

R10: 安全规范

• Preload 暴露最小化 API 表面
• IPC handler 校验输入（路径遍历、类型检查）
• 代码中不得包含敏感数据（密钥、Token）
• Renderer 禁止 nodeIntegration: true

输出格式

📏 规范检查报告

━━━ 检查范围 ━━━
文件: <file list>
规则: <R1-R10 or specific rules>

❌ 违规 (必须修复)
  1. [IPC-001] handler 未返回 { success, data?, error? } 格式
     位置: src/main/ipc/handlers/xxxHandler.ts:42
     修复: 将 return result 改为 return { success: true, data: result }

  2. [ANTI-002] Renderer 中直接使用了 Node.js fs 模块
     位置: src/renderer/src/services/fileService.ts:5
     修复: 通过 IPC 调用 Main Process 服务

⚠️ 建议 (推荐改进)
  1. [REACT-003] 事件处理函数未使用 useCallback
     位置: src/renderer/src/components/Foo.tsx:28
     建议: 包裹 useCallback(() => {...}, [deps])

✅ 符合项
  - [NAME] 文件命名符合 PascalCase 规范
  - [TS] 无 any 类型使用
  - [STYLE] Tailwind 类名使用正确

📊 结果: X/Y 条规则通过

关键原则

1. 每条违规必须给出具体的文件位置和修复建议
2. 区分 ❌ 必须修复（会导致 bug 或安全问题）和 ⚠️ 建议改进（代码质量）
3. 优先检查架构性问题（IPC 完整性、进程边界）再检查风格问题
4. 如果代码整体合规，简要确认即可，不要过度展开
5. 对于新增 IPC 功能，必须验证 6 步是否全部完成
6. 检查时主动使用 Grep 搜索相关文件，不要仅依赖用户提供的片段