claude-apprentice 1.0.0

package/templates/settings.json

@@ -0,0 +1,23 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(git show *)",
+      "Bash(git diff *)",
+      "Bash(git log *)",
+      "Bash(git diff-tree *)",
+      "Bash(git status *)",
+      "Bash(git branch *)"
+    ],
+    "deny": [
+      "Bash(git push --force *)",
+      "Bash(git reset --hard *)",
+      "Bash(rm -rf *)"
+    ]
+  },
+  "enabledPlugins": {
+    "superpowers@superpowers-marketplace": true,
+    "document-skills@anthropic-agent-skills": true
+  },
+  "language": "chinese",
+  "theme": "auto"
+}

package/templates/skills/backend-workflow.md

@@ -0,0 +1,87 @@
+---
+name: backend-workflow
+description: 当需要开发或修改后端 API 接口、数据库操作、业务逻辑、服务配置时使用
+context: fork
+---
+
+# 后端开发流程编排器
+
+你处于后端开发模式。本技能是完整的后端开发流程编排器，每个步骤关联 Superpowers Skill，根据项目配置决定是否启用。
+
+## 配置读取（流程开始前执行）
+
+读取 `.claude/memory/superpowers-config.md` 中的配置，确定每个 Skill 的启用状态：
+- **enabled** → 对应步骤始终执行
+- **disabled** → 对应步骤始终跳过
+- **conditional** → 根据复杂度判断
+
+复杂度：简单（单接口/加字段 < 30 分钟）/ 中等（新表+新接口 30 分钟 - 2 小时）/ 复杂（新模块 > 2 小时）
+
+---
+
+## 流程步骤
+
+### 步骤 0：需求入口 [必选]
+
+- 接收用户需求描述
+- 判断复杂度等级
+- **简单任务**（修接口/加字段）→ 跳到步骤 3 直接实现
+- **中等/复杂任务** → 进入步骤 1
+
+> 关联 Superpowers: using-superpowers
+
+### 步骤 1：需求澄清 + Spec 产出 [中等+复杂]
+
+- 确认涉及的业务模块、数据表、接口
+- 检查 `.claude/memory/backend-standards.md` 了解项目规范
+- 确认现有数据库表结构和 DAO/Mapper
+- 设计 API 路径、请求参数、响应格式、错误码
+- 设计数据库变更（如需建表/改表，先输出 DDL）
+- **产出：在 `specs/active/` 下创建 spec 文件**（状态 Proposed）
+- 让用户确认 spec 后，状态改为 Applied
+
+> Spec 格式参见 `.claude/specs/SPEC-GUIDE.md`
+> 关联 Superpowers: brainstorming
+> 配置项: 如 brainstorming 已禁用，直接用用户描述创建 spec
+
+### 步骤 2：任务拆解与计划 [复杂]
+
+- 拆解为 2-5 分钟可完成的小任务
+- 每个任务标注文件路径和变更范围
+- 输出计划让用户确认
+
+> 关联 Superpowers: writing-plans
+> 配置项: 如 writing-plans 已禁用，跳过此步骤
+
+### 步骤 3：自底向上实现 [必选]
+
+- 读取 `specs/active/` 中对应的 spec 文件作为约束
+- 按顺序逐层实现：
+
+1. **DAO/Mapper 层** — 数据访问方法、SQL 映射
+2. **Service 层** — 业务逻辑、事务管理
+3. **Controller 层** — 接口定义、参数校验、响应封装
+
+### 步骤 4：验证 [必选]
+
+- 运行构建命令（如 `mvn compile` / `go build` / `python -m py_compile`）
+- 运行测试命令（如 `mvn test` / `go test` / `pytest`）
+- 贴出运行结果作为完成证据
+- **将 spec 从 `active/` 移入 `archived/`**
+
+> 关联 Superpowers: verification-before-completion
+
+---
+
+## 完成标准
+
+- 编译通过
+- 测试通过（如有测试）
+- 分层正确，无跨层调用
+- 接口格式符合统一响应规范
+- 输入校验到位，无安全隐患
+- 验证结果已贴出
+
+## 参考规范
+
+阅读 `.claude/memory/backend-standards.md` 了解完整后端规范。

package/templates/skills/code-review/SKILL.md

@@ -0,0 +1,253 @@
+---
+name: code-review
+description: Use when reviewing code changes, pull requests, or performing code quality audits. Triggers include mentions of "code review", "review PR", "check code quality", "代码评审", "代码审查", "评审代码", or when examining code for security vulnerabilities, correctness issues, performance problems, or maintainability concerns.
+---
+
+# 代码评审
+
+基于 6 维度 31 项评审标准体系，对代码变更进行系统性评审，输出结构化评审报告。
+
+## 评审流程
+
+```dot
+digraph review_flow {
+    "确定评审范围" [shape=box];
+    "读取变更内容" [shape=box];
+    "按维度逐项检查" [shape=box];
+    "发现高危/严重问题?" [shape=diamond];
+    "记录问题到报告" [shape=box];
+    "汇总评审结论" [shape=box];
+    "输出评审报告" [shape=doublecircle];
+
+    "确定评审范围" -> "读取变更内容";
+    "读取变更内容" -> "按维度逐项检查";
+    "按维度逐项检查" -> "发现高危/严重问题?" ;
+    "发现高危/严重问题?" -> "记录问题到报告" [label="是"];
+    "发现高危/严重问题?" -> "汇总评审结论" [label="否，检查完毕"];
+    "记录问题到报告" -> "按维度逐项检查";
+    "汇总评审结论" -> "输出评审报告";
+}
+```
+
+## 执行步骤
+
+### 1. 确定评审范围
+
+根据用户输入确定评审对象：
+
+**模式 A：基于 git 提交记录（推荐）**
+
+询问用户选择评审方式：
+- **最近一次提交** → 直接使用最新 commit
+- **选择历史提交** → 列出最近 10 次提交，让用户选择（支持多选）
+
+使用 `AskUserQuestion` 工具展示提交列表，设置 `multiSelect: true` 支持多选：
+
+```
+请选择要评审的提交（已过滤 Merge 提交，仅展示实质变更）：
+
+  1. #2 d1b34e90 — 检查项补全修改 (alice, 4小时前)
+  2. #4 6242b2c0 — 检查项补全修改 (alice, 5小时前)
+  3. #6 c134d3a2 — 检查项合并修改 (alice, 5小时前)
+  4. #8 c39c1a8b — 解析列表详情异常处理 (bob, 6小时前)
+```
+
+用户选择后：
+- **单选** → 获取该提交涉及的文件列表
+- **多选** → 合并所有选中提交涉及的文件列表（去重），对多个提交的变更进行统一评审
+
+**模式 B：指定文件或目录**
+
+- 指定文件路径 → 评审该文件
+- 指定目录 → 评审目录下所有代码文件
+
+### 2. 获取文件内容
+
+使用 `Read` 工具逐一读取步骤 1 中确定的文件列表。
+
+**允许的只读 git 命令（用于理解变更上下文）：**
+
+| 命令 | 用途 |
+|------|------|
+| `git show --stat <commit>` | 查看提交涉及的文件列表 |
+| `git diff-tree --name-only -r <commit>` | 获取变更文件路径 |
+| `git diff <commit>^..<commit>` | 查看具体代码变更内容 |
+| `git log --name-only` | 查看提交历史和关联文件 |
+
+> **禁止执行任何写操作的 git 命令**（commit、push、checkout、reset、merge 等）。
+
+### 3. 按维度逐项检查
+
+严格按以下 7 个维度顺序检查，每项给出判定结果：
+
+**维度优先级**：安全性 > 正确性 > 性能 > 设计与架构 > 可维护性 > 规范与一致性 > 文件类型专属
+
+对每个维度，逐项检查并标记：
+- **通过** — 符合标准
+- **不通过** — 不符合标准，记录具体问题和严重等级
+- **不适用** — 当前变更不涉及此项
+
+#### 3.1 单文件逐项检查
+
+按维度一到维度七逐文件检查。维度七根据文件后缀自动激活对应的检查项。
+
+#### 3.2 跨文件关联分析
+
+检查本次变更涉及的文件之间的关联一致性：
+
+- **接口定义变更** → 搜索所有调用方，检查参数/返回值是否同步更新
+- **数据库表结构变更** → 检查对应的 DAO/Mapper/Model 层是否对应修改
+- **公共组件/工具类变更** → 搜索引用方，检查是否受影响
+- **常量/枚举变更** → 搜索所有使用处，检查是否一致
+- **配置变更** → 检查相关功能模块是否适配新配置
+
+#### 3.3 变更影响面评估
+
+在评审报告的问题清单中增加"影响范围"标注：
+- **局部** — 仅影响当前文件
+- **模块级** — 影响同一模块内多个文件
+- **跨模块** — 影响多个模块（需特别关注）
+- **全局** — 影响公共接口、数据库、配置等（高风险）
+
+### 4. 输出评审报告
+
+使用 `AskUserQuestion` 让用户选择输出格式：
+
+**MD 格式** → 生成 `.md` 文件（适合在 GitHub/GitLab PR 评论、文档归档中使用）
+**Excel 格式** → 生成 `.xlsx` 文件（适合分发给团队、汇总统计、跟踪修复进度）
+
+输出文件路径：`.claude/reports/code-review-YYYYMMDD-HHmmss.{md|xlsx}`
+
+#### MD 格式模板
+
+```markdown
+# 代码评审报告
+
+**评审范围**：[文件/目录/变更范围]
+**评审日期**：[日期]
+**评审结果**：[通过 | 有条件通过 | 不通过]
+
+## 评审汇总
+
+| 维度 | 通过 | 不通过 | 不适用 | 最高等级 |
+|------|------|--------|--------|---------|
+| 正确性与功能 | X | X | X | - |
+| 安全性 | X | X | X | - |
+| 可维护性 | X | X | X | - |
+| 性能 | X | X | X | - |
+| 设计与架构 | X | X | X | - |
+| 规范与一致性 | X | X | X | - |
+
+## 问题清单
+
+| # | 维度 | 评审项 | 问题描述 | 严重等级 | 影响范围 | 修复建议 |
+|---|------|--------|---------|---------|---------|---------|
+| 1 | 安全性 | SQL 注入 | ... | 高危 | 模块级 | ... |
+
+## 评审结论
+
+[总结性说明，包括必须修复的问题和建议改进项]
+```
+
+#### Excel 格式
+
+使用 Python 脚本生成，包含 3 个 Sheet：
+
+**Sheet 1：评审汇总**
+| 维度 | 通过 | 不通过 | 不适用 | 最高等级 |
+|------|------|--------|--------|---------|
+
+**Sheet 2：问题清单**
+| # | 文件 | 行号 | 维度 | 评审项 | 问题描述 | 严重等级 | 修复建议 | 状态 |
+|---|------|------|------|--------|---------|---------|---------|------|
+| 1 | UserService.java | 45 | 安全性 | SQL 注入 | 字符串拼接 SQL | 高危 | 改用 #{} 参数化 | 待修复 |
+
+**Sheet 3：评审信息**
+| 项 | 值 |
+|---|---|
+| 评审范围 | ... |
+| 评审日期 | ... |
+| 评审结果 | ... |
+| 评审提交 | ... |
+| 评审结论 | ... |
+
+生成方式：使用 `openpyxl` 库，若未安装则先 `pip install openpyxl`。单元格样式要求：
+- 高危/严重 → 红色背景
+- 中危 → 橙色背景
+- 一般 → 黄色背景
+- 低危/建议 → 绿色背景
+- 表头加粗、冻结首行、自动列宽
+
+## 评审标准速查
+
+### 维度一：正确性与功能（5 项）
+
+| # | 评审项 | 等级 | 检查要点 |
+|---|--------|------|---------|
+| 1.1 | 功能逻辑 | 严重 | 实现与需求一致，路径覆盖完整 |
+| 1.2 | 边界与异常处理 | 严重 | 空值、越界、并发、极端输入处理 |
+| 1.3 | 数据一致性 | 严重 | 事务正确，无竞态条件 |
+| 1.4 | API 契约 | 严重 | 接口约定一致，向后兼容 |
+| 1.5 | 测试覆盖 | 一般 | 核心逻辑有有效测试 |
+
+### 维度二：安全性（18 项）
+
+**业务数据篡改**：必填项/负值/一致性/选择框/置灰项/空值/边界值校验
+
+**未授权访问**：登录校验、权限校验
+
+**越权防护**：水平越权、ID 遍历、垂直越权
+
+**信息泄露**：敏感数据脱敏、组件版本号、异常信息、密钥泄露
+
+**注入攻击**：SQL 注入、CSRF、会话固定、URL 跳转、用户名枚举
+
+**前端安全**：安全配置、静态文件泄露
+
+> 详细标准见 standards.md
+
+### 维度三：可维护性（6 项）
+
+命名规范、方法长度、代码复杂度、重复代码、注释质量、依赖管理
+
+### 维度四：性能（4 项）
+
+数据库查询、资源管理、缓存使用、批量与循环
+
+### 维度五：设计与架构（4 项）
+
+职责划分、接口设计、扩展性、日志规范
+
+### 维度六：规范与一致性（3 项）
+
+编码规范、提交规范、配置管理
+
+### 维度七：文件类型专属检查（按后缀自动激活）
+
+根据变更文件后缀加载对应检查项（Java/Python/Go/Vue/React/XML Mapper/配置文件/SQL）
+
+> 详细标准见 standards.md 维度七
+
+## 问题等级定义
+
+| 等级 | 处理方式 |
+|------|---------|
+| **高危/严重** | 必须修复，阻塞合并 |
+| **中危** | 强烈建议修复，本轮处理 |
+| **一般** | 建议改进，记录跟踪 |
+| **低危/建议** | 供参考，酌情处理 |
+
+## 评审结论判定规则
+
+- **不通过**：存在任何高危/严重级别问题
+- **有条件通过**：存在中危级别问题，已确认修复计划
+- **通过**：仅有一般/建议级别问题或无问题
+
+## 常见误区
+
+| 误区 | 正确做法 |
+|------|---------|
+| 只检查功能不检查安全 | 安全性是最高优先级维度 |
+| 评审意见含糊（"这里不太好"） | 指明具体问题、违反的评审项、修复建议 |
+| 只关注改动的代码行 | 需理解变更上下文和影响范围 |
+| 忽略不通过的评审项 | 每项都必须明确判定，不得跳过 |

package/templates/skills/code-review/standards.md

@@ -0,0 +1,189 @@
+# 代码评审标准详细参考
+
+## 维度一：正确性与功能
+
+| # | 评审项 | 评审标准 | 等级 |
+|---|--------|---------|------|
+| 1.1 | 功能逻辑 | 代码实现与需求/设计文档一致，核心路径和分支路径均覆盖 | 严重 |
+| 1.2 | 边界与异常处理 | 空值、越界、并发、极端输入有合理处理 | 严重 |
+| 1.3 | 数据一致性 | 数据读写一致，事务使用正确，无竞态条件 | 严重 |
+| 1.4 | API 契约 | 接口入参/出参/错误码符合约定，向后兼容 | 严重 |
+| 1.5 | 测试覆盖 | 核心逻辑有对应的单元测试/集成测试，测试有效（非凑覆盖率） | 一般 |
+
+---
+
+## 维度二：安全性
+
+### 2.1 业务数据篡改防护
+
+| # | 评审项 | 等级 | 评审标准 |
+|---|--------|------|---------|
+| 2.1.1 | 必填项校验 | 高危 | 后端需校验是否接收到有效数值 |
+| 2.1.2 | 负值校验 | 高危 | 金额等字段需 >= 0 |
+| 2.1.3 | 一致性校验 | 中危 | 输入框前后端长度限制须保持一致 |
+| 2.1.4 | 选择框校验 | 高危 | 后端需校验入参是否在选择框可选范围内 |
+| 2.1.5 | 置灰项校验 | 中危 | 后端需对置灰项提交的值进行校验；更新类服务不允许修改置灰字段 |
+| 2.1.6 | 空值校验 | 高危 | 查询入参 ID 为空时需返回异常 |
+| 2.1.7 | 边界值校验 | 中危 | 分页等参数需限制最大值 |
+
+### 2.2 未授权访问防护
+
+| # | 评审项 | 等级 | 评审标准 |
+|---|--------|------|---------|
+| 2.2.1 | 登录校验 | 高危 | 所有服务使用登录过滤器拦截，校验 sessionId 是否有效 |
+| 2.2.2 | 权限校验 | 高危 | 未登录或无权限访问时，页面不可展示、接口无数据返回 |
+
+### 2.3 越权防护
+
+| # | 评审项 | 等级 | 评审标准 |
+|---|--------|------|---------|
+| 2.3.1 | 水平越权 | 高危 | ID 等参数修改后，返回数据须在当前账号权限范围内 |
+| 2.3.2 | ID 遍历风险 | 高危 | 禁止使用自增 ID，避免暴力遍历风险 |
+| 2.3.3 | 垂直越权 | 高危 | 接口需有权限校验，低权限账号调用高权限接口需返回异常 |
+
+### 2.4 信息泄露防护
+
+| # | 评审项 | 等级 | 评审标准 |
+|---|--------|------|---------|
+| 2.4.1 | 敏感数据脱敏 | 高危 | 敏感数据原则上不返回，需展示时脱敏返回 |
+| 2.4.2 | 组件版本号泄露 | 低危 | 避免 Nginx 等组件版本号泄露 |
+| 2.4.3 | 异常信息泄露 | 高危 | 禁止将 `e.getMessage()` 等异常信息返回前端 |
+| 2.4.4 | 密钥泄露 | 中危 | 地图 Key、OSS AccessKeyId 等禁止明文出现在 URL 中，必须加密传输 |
+
+### 2.5 注入与攻击防护
+
+| # | 评审项 | 等级 | 评审标准 |
+|---|--------|------|---------|
+| 2.5.1 | SQL 注入 | 高危 | 禁止字符串拼接 SQL；MyBatis 中禁止使用 `${}`，用 `#{}` 代替 |
+| 2.5.2 | CSRF 跨站请求伪造 | 中危 | 所有请求需添加 Referer/Origin 白名单校验 |
+| 2.5.3 | 会话固定攻击 | 中危 | 登录信息不缓存，需实时调用接口，与入口系统同步 |
+| 2.5.4 | URL 跳转 | 高危 | 跳转 URL 需做域名白名单限制 |
+| 2.5.5 | 用户名枚举 | 高危 | 统一登录异常返回，不区分"账号不存在"和"密码错误" |
+
+### 2.6 前端安全
+
+| # | 评审项 | 等级 | 评审标准 |
+|---|--------|------|---------|
+| 2.6.1 | 安全配置错误 | 低危 | 前端跳转统一加监听，登录失效时在解析页面前跳转登录页 |
+| 2.6.2 | 静态文件信息泄露 | 低危 | 调试 IP、注释 IP 及时删除，编译后 JS 中不得存在明文 IP |
+
+---
+
+## 维度三：可维护性
+
+| # | 评审项 | 评审标准 | 等级 |
+|---|--------|---------|------|
+| 3.1 | 命名规范 | 变量、函数、类命名语义清晰，符合团队编码规范 | 一般 |
+| 3.2 | 方法/函数长度 | 单个方法不超过合理阈值（建议 50 行），职责单一 | 一般 |
+| 3.3 | 代码复杂度 | 嵌套层级不超过 3-4 层，圈复杂度合理 | 一般 |
+| 3.4 | 重复代码 | 无明显的复制粘贴代码，可复用逻辑已抽取 | 一般 |
+| 3.5 | 注释质量 | 关键业务逻辑有必要注释，无冗余/过时注释 | 一般 |
+| 3.6 | 依赖管理 | 新增依赖有必要性论证，无冗余/过期依赖 | 一般 |
+
+---
+
+## 维度四：性能
+
+| # | 评审项 | 评审标准 | 等级 |
+|---|--------|---------|------|
+| 4.1 | 数据库查询 | 无 N+1 查询，大表查询有合理索引和分页 | 严重 |
+| 4.2 | 资源管理 | 连接、流、文件句柄等资源正确关闭，无泄露 | 严重 |
+| 4.3 | 缓存使用 | 热点数据有合理缓存策略，缓存击穿/雪崩有防护 | 一般 |
+| 4.4 | 批量与循环 | 循环内无重复计算/重复查询，批量操作使用批量接口 | 一般 |
+
+---
+
+## 维度五：设计与架构
+
+| # | 评审项 | 评审标准 | 等级 |
+|---|--------|---------|------|
+| 5.1 | 职责划分 | 类/模块职责单一，不出现上帝类或功能堆砌 | 一般 |
+| 5.2 | 接口设计 | 接口粒度合理，遵循最小知识原则 | 一般 |
+| 5.3 | 扩展性 | 新功能不破坏现有结构，符合开闭原则 | 一般 |
+| 5.4 | 日志规范 | 关键操作有日志记录，日志级别使用恰当，不记录敏感信息 | 一般 |
+
+---
+
+## 维度六：规范与一致性
+
+| # | 评审项 | 评审标准 | 等级 |
+|---|--------|---------|------|
+| 6.1 | 编码规范 | 缩进、命名、格式等符合团队编码规范 | 一般 |
+| 6.2 | 提交规范 | Commit 信息清晰，单次提交改动范围合理 | 一般 |
+| 6.3 | 配置管理 | 无硬编码配置值，敏感配置使用环境变量/配置中心 | 严重 |
+
+---
+
+## 维度七：文件类型专属检查（按文件后缀自动激活）
+
+评审时根据变更文件的后缀名，自动加载对应的专属检查项。仅评审涉及该类型文件时生效，不涉及则标记"不适用"。
+
+### 7.1 Java（*.java）
+
+| # | 检查项 | 等级 | 检查要点 |
+|---|--------|------|---------|
+| 7.1.1 | NPE 风险 | 高危 | 链式调用、集合取值、自动拆箱、Map.get() 未判空 |
+| 7.1.2 | switch 穿透 | 中危 | 每个 case 是否有 break/return，是否遗漏 default |
+| 7.1.3 | 资源未关闭 | 高危 | 流、连接、文件句柄是否使用 try-with-resources |
+| 7.1.4 | 线程安全 | 高危 | 共享变量是否有竞态条件、ConcurrentHashMap 使用是否正确 |
+| 7.1.5 | 异常吞没 | 中危 | catch 块是否为空或只打印日志未处理 |
+
+### 7.2 MyBatis Mapper（*.xml，含 SQL 语句）
+
+| # | 检查项 | 等级 | 检查要点 |
+|---|--------|------|---------|
+| 7.2.1 | SQL 注入 | 高危 | 禁止使用 `${}`，必须用 `#{}` |
+| 7.2.2 | N+1 查询 | 中危 | 循环内是否嵌套查询，是否可用 JOIN 或批量查询替代 |
+| 7.2.3 | 大结果集 | 中危 | 查询是否加 LIMIT，是否有分页 |
+| 7.2.4 | 缺索引 | 中危 | WHERE 条件字段是否有对应索引 |
+
+### 7.3 Python（*.py）
+
+| # | 检查项 | 等级 | 检查要点 |
+|---|--------|------|---------|
+| 7.3.1 | 类型安全 | 中危 | 函数参数和返回值是否有类型注解，是否有隐式 Any |
+| 7.3.2 | 异步规范 | 中危 | async 函数中是否有阻塞调用，是否正确使用 await |
+| 7.3.3 | 异常吞没 | 中危 | except 块是否使用具体异常类型，是否为空 |
+| 7.3.4 | 可变默认参数 | 中危 | 函数参数是否使用可变对象作为默认值（如 `def f(a=[])`） |
+
+### 7.4 TypeScript / React（*.ts, *.tsx）
+
+| # | 检查项 | 等级 | 检查要点 |
+|---|--------|------|---------|
+| 7.4.1 | any 类型滥用 | 中危 | 是否大量使用 any，是否可以用具体类型替代 |
+| 7.4.2 | XSS 风险 | 高危 | 是否使用 dangerouslySetInnerHTML，用户输入是否转义 |
+| 7.4.3 | Hooks 规范 | 中危 | useEffect 依赖数组是否完整，是否在条件中使用 Hook |
+| 7.4.4 | 内存泄漏 | 中危 | useEffect 是否返回清理函数，定时器/订阅是否清理 |
+
+### 7.5 Vue（*.vue）
+
+| # | 检查项 | 等级 | 检查要点 |
+|---|--------|------|---------|
+| 7.5.1 | 组件职责 | 一般 | 单个组件是否职责单一，是否应该拆分 |
+| 7.5.2 | 状态管理 | 中危 | 全局状态是否使用 Pinia/Vuex，组件内是否有不必要的状态 |
+| 7.5.3 | API 调用规范 | 中危 | 是否走 api/ 模块，是否有 loading/error/empty 处理 |
+
+### 7.6 Go（*.go）
+
+| # | 检查项 | 等级 | 检查要点 |
+|---|--------|------|---------|
+| 7.6.1 | 错误处理 | 高危 | 是否检查所有 error 返回值，是否正确传播错误 |
+| 7.6.2 | goroutine 泄漏 | 高危 | goroutine 是否有退出条件，channel 是否正确关闭 |
+| 7.6.3 | 并发安全 | 高危 | 共享数据是否使用 sync.Mutex 或 channel 保护 |
+
+### 7.7 配置文件（pom.xml, package.json, go.mod, requirements.txt）
+
+| # | 检查项 | 等级 | 检查要点 |
+|---|--------|------|---------|
+| 7.7.1 | 禁止 SNAPSHOT | 中危 | pom.xml 中是否引用 SNAPSHOT 版本依赖 |
+| 7.7.2 | 依赖冲突 | 中危 | 是否有版本冲突或重复依赖 |
+| 7.7.3 | 通配符版本 | 高危 | 是否使用 `*` 或 `latest` 作为版本号 |
+| 7.7.4 | 新增依赖必要性 | 一般 | 新增依赖是否必要，是否有同功能已有依赖 |
+
+### 7.8 SQL 脚本（*.sql）
+
+| # | 检查项 | 等级 | 检查要点 |
+|---|--------|------|---------|
+| 7.8.1 | 慢查询 | 中危 | 全表扫描、大表 JOIN、子查询是否可优化 |
+| 7.8.2 | 缺索引 | 中危 | WHERE/JOIN 字段是否有索引 |
+| 7.8.3 | 大事务 | 中危 | 单事务是否涉及多张大表操作 |

package/templates/skills/frontend-workflow.md

@@ -0,0 +1,75 @@
+---
+name: frontend-workflow
+description: 当需要开发或修改前端 UI 组件、页面、样式、状态管理、前端性能优化时使用
+context: fork
+---
+
+# 前端开发流程编排器
+
+你处于前端开发模式。本技能是完整的前端开发流程编排器，每个步骤关联 Superpowers Skill，根据项目配置决定是否启用。
+
+## 配置读取（流程开始前执行）
+
+读取 `.claude/memory/superpowers-config.md` 中的配置，确定每个 Skill 的启用状态：
+- **enabled** → 对应步骤始终执行
+- **disabled** → 对应步骤始终跳过
+- **conditional** → 根据复杂度判断
+
+复杂度：简单（单文件 < 30 分钟）/ 中等（新组件 30 分钟 - 2 小时）/ 复杂（新模块 > 2 小时）
+
+---
+
+## 流程步骤
+
+### 步骤 0：需求入口 [必选]
+
+- 接收用户需求描述
+- 判断复杂度等级
+- **简单任务**（改样式/改文案）→ 跳到步骤 3 直接实现
+- **中等/复杂任务** → 进入步骤 1
+
+> 关联 Superpowers: using-superpowers
+
+### 步骤 1：需求澄清 + Spec 产出 [中等+复杂]
+
+- 确认涉及的文件、组件、页面
+- 检查 `.claude/memory/frontend-standards.md` 了解项目规范
+- 搜索项目中是否已有可复用的组件
+- 确认组件 props、events、slots 设计
+- 确认需要调用的 API 接口及数据格式
+- **产出：在 `specs/active/` 下创建 spec 文件**（状态 Proposed）
+- 让用户确认 spec 后，状态改为 Applied
+
+> Spec 格式参见 `.claude/specs/SPEC-GUIDE.md`
+> 关联 Superpowers: brainstorming
+> 配置项: 如 brainstorming 已禁用，直接用用户描述创建 spec
+
+### 步骤 2：任务拆解与计划 [复杂]
+
+- 拆解为 2-5 分钟可完成的小任务
+- 每个任务标注文件路径和变更范围
+- 输出计划让用户确认
+
+> 关联 Superpowers: writing-plans
+> 配置项: 如 writing-plans 已禁用，跳过此步骤
+
+### 步骤 3：实现 [必选]
+
+- 读取 `specs/active/` 中对应的 spec 文件作为约束
+- 按规范编写代码
+- API 调用通过 `api/` 目录模块，不直接写 fetch/axios
+- 处理 loading / error / empty 三种状态
+- 组件保持单一职责
+
+### 步骤 4：验证 [必选]
+
+- 运行 `npm run lint`（或项目对应的 lint 命令）
+- 运行 `npm run test:unit`（如存在）
+- 贴出运行结果作为完成证据
+- **将 spec 从 `active/` 移入 `archived/`**
+
+> 关联 Superpowers: verification-before-completion
+
+## 参考规范
+
+阅读 `.claude/memory/frontend-standards.md` 了解完整前端规范。