smart-commit-copilot-cli 0.1.5 → 0.1.7

package/src/code-review-skills/frontend-code-review/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: frontend-code-reviewer
+review-domain: frontend
+description: "前端专项代码审查技能，用于开发者在 commit 前审查页面、组件、样式、浏览器端逻辑与交互改动。当用户请求前端代码审查、React/Vue 审查、组件 review、页面改动检查或类似场景时使用。重点识别真实缺陷、交互状态错误、渲染风险、前端安全、性能回退与可访问性问题，给出可执行的修复建议。默认只输出审查结论，不直接修改代码。"
+---
+
+# 前端代码审查
+
+## 问题门槛
+
+每条问题必须满足以下三点，否则不输出：
+
+1. **可定位**：能指向具体文件和新增行号
+2. **可自证**：仅凭当前 diff 和可见上下文即可成立，不依赖 diff 之外的假设
+3. **可修复**：给出具体修复方案，而非泛泛建议
+
+同一根因的多处表现合并为一条，不重复列举。
+
+## 审查模式
+
+你会收到一段共享的 diff 类型识别结果。
+
+- 当识别结果为 `frontend` 且与当前 skill 匹配时，按本 skill 的前端专项标准审查
+- 当识别结果与当前 skill 不匹配时，不要提示用户选错了 skill，也不要中止审查
+- 不匹配时继续使用同一输出格式，但按现有通用 `code-review` 审查基线做稳妥审查
+- 不匹配时减少 React、Vue、DOM、样式、浏览器运行时等前端特有假设
+
+## 严重级别
+
+| 等级 | 含义 | 处理 |
+|------|------|------|
+| **P0** | 安全漏洞、数据损坏、必现 crash、核心页面不可用 | 必须修复后才能提交 |
+| **P1** | 逻辑错误、功能异常、明显性能或稳定性回退 | 提交前修复 |
+| **P2** | 可维护性问题、测试不足、非阻塞设计问题、局部语义或基础可用性退化 | 当前批次修复或登记后续任务 |
+| **P3** | 次要改进 | 可选 |
+
+## 工作流
+
+### 1) 确认审查范围
+
+先关注共享分类结果、`changedFiles` 与 diff 本身，再决定本次是否使用前端专项视角。
+
+- 当前 diff 主要是页面、组件、浏览器端逻辑、样式或构建配置改动时，使用前端专项视角
+- 当前 diff 若明显偏后端、数据库、基础设施或语言类型不匹配，则直接回到通用稳妥审查
+- 不因为用户选择了前端 skill 就强行输出前端专属问题
+
+### 2) 代码分析
+
+#### a) 交互与状态生命周期
+
+加载 `references/interaction-and-state-lifecycle.md`，检查组件状态、事件处理、异步流程、表单行为、空态与错误态在生命周期各阶段是否一致。
+如 diff 涉及表单、弹层、导航控件或明显的语义结构调整，可结合 `references/accessibility-and-semantic-ux.md` 补充检查基础语义与可用性是否退化，但不单独作为高优先级评审主轴。
+
+#### b) 安全与数据边界
+
+加载 `references/security-and-data-boundary.md`，重点关注 XSS、危险 HTML 注入、token/敏感信息暴露、前端权限绕过与不安全存储。
+
+#### c) 渲染性能与资源加载
+
+加载 `references/rendering-performance-and-resource-loading.md`，检查不必要重渲染、大列表、昂贵计算、资源加载与 hydration/render 风险。
+
+#### d) 通用工程基线补充
+
+完成前端专项检查后，补充对通用 `code-review` 的以下基线检查：架构与设计、测试质量，以及当 diff 包含删除时的冗余与残留引用。前端专项维度只负责浏览器端与交互相关风险，不替代通用工程审查。
+
+### 3) 整理问题列表
+
+确认每条问题满足门槛（可定位、可自证、可修复）。同一根因的多处表现合并为一条。不为凑数量降低标准。
+
+### 4) 评分
+
+加载 `references/scoring-guide.md`，**每次审查必须根据该指南给出具体评分**：先按最严重问题确定基准区间，再按影响广度、问题数量、可逆性在区间内微调，最终输出一个具体分值（如 8.5、7.0），不得只写区间或省略评分；纯文件删除时记为 N/A。
+
+### 5) 输出格式
+
+按以下格式输出：
+
+```markdown
+## 审查摘要
+
+**审查范围**：X 个文件，Y 行新增
+
+**评分**：X / 10（必须为具体分值，如 8.5；仅纯删除时为 N/A）
+
+**提交建议**：✅ 可以提交 / ✅ 可以提交，跟进修复 / 🔧 修复后提交 / 🚫 禁止提交
+
+**问题统计**：P0 × 个 / P1 × 个 / P2 × 个 / P3 × 个
+
+---
+
+## 各维度结果
+
+| # | 维度 | 结论 |
+|---|------|------|
+| 1 | 交互与状态生命周期（含基础语义与可用性） | ✅ 无问题 / ⚠️ 存在问题（简述） |
+| 2 | 安全与数据边界 | ✅ 无问题 / ⚠️ 存在问题（简述） |
+| 3 | 渲染性能与资源加载 | ✅ 无问题 / ⚠️ 存在问题（简述） |
+
+---
+
+## 问题列表
+
+### P0 🔴 严重
+无
+
+### P1 🟠 高
+1. **[文件:行号] 问题标题**
+   - **问题**：一句话说明是什么问题
+   - **影响**：一句话说明会导致什么后果
+   - **修复**：具体方案
+
+### P2 🟡 中
+无
+
+### P3 🟢 低
+无
+
+---
+
+## 总体评价
+
+2–3 句话说明是否建议提交，以及还需要哪些修复或跟进。
+```
+
+**输出规则：**
+
+- 每次审查必须在「审查摘要」中给出根据 `references/scoring-guide.md` 计算的具体评分（X / 10），不得省略。
+- 直接给问题，不写前言铺垫。
+- 每条问题写清楚：位置、问题是什么、影响是什么、如何修复。
+- 只在有明确代码路径支撑时输出问题，不猜项目框架、运行环境或业务规则。
+- 如果共享分类结果提示应回到通用审查，则按通用基线保守审查，但仍然使用本 skill 的统一输出结构。
+- 禁止在模板之外添加"亮点"、"优点"、"表扬"等额外章节。
+- `## 总体评价` 只写 2–3 句连续段落，不用列表或子标题。
+
+## 参考文件
+
+| 文件 | 用途 |
+|------|------|
+| `interaction-and-state-lifecycle.md` | 交互流程、状态切换、边界条件与生命周期一致性检查项 |
+| `security-and-data-boundary.md` | 前端安全、数据暴露与权限边界风险检查项 |
+| `rendering-performance-and-resource-loading.md` | 渲染性能、资源加载与 hydration 风险检查项 |
+| `accessibility-and-semantic-ux.md` | 语义化 DOM、基础键盘可达性与状态表达补充检查项 |
+| `scoring-guide.md` | 评分模型、区间规则和提交建议 |

package/src/code-review-skills/frontend-code-review/references/accessibility-and-semantic-ux.md

@@ -0,0 +1,33 @@
+# 语义与基础可用性检查项
+
+## 语义化与结构
+
+- 可点击元素用 `div`、`span` 模拟，但没有使用语义化的 `button`、`a`、`label` 等标签
+- 结构性区域缺少明确语义，导致导航、主内容、表单分组或标题层级不清晰
+- 图片、图标按钮、仅视觉可见内容缺少可读文本、`alt` 或等价名称
+
+## 基础交互与焦点
+
+- 新增弹窗、抽屉、菜单、下拉层后，没有焦点管理、Esc 关闭或 Tab 顺序控制
+- 关键交互只能靠鼠标触发，键盘无法访问或无法感知当前焦点
+- 状态切换后焦点丢失，用户无法继续操作
+
+## 表单与状态反馈
+
+- 输入框、复选框、单选框缺少关联标签、必填说明或错误提示
+- 加载中、禁用、展开/收起、选中等状态只有视觉变化，没有通过文本或明确状态提示表达
+- 校验错误只改变颜色，没有给出明确的文字反馈
+
+## 视觉与可读性
+
+- 仅依赖颜色区分成功/失败、启用/禁用、选中/未选中等状态
+- 文本与背景对比度不足，或字体尺寸、点击区域明显影响可读性与可操作性
+
+## 排查思路
+
+审查时依次问自己：
+
+- 不使用鼠标时，用户是否仍能完成关键流程？
+- 语义结构、控件名称和状态表达是否仍能支撑主流程理解与操作？
+- 这次改动有没有把原本可正常操作的控件退化成只对视觉用户友好的实现？
+- 如果没有明确代码路径支撑，不作为正式问题输出。

package/src/code-review-skills/frontend-code-review/references/interaction-and-state-lifecycle.md

@@ -0,0 +1,39 @@
+# 交互与状态生命周期检查项
+
+## 交互流程与状态一致性
+
+- 事件处理函数更新了错误的状态分支，导致按钮、弹窗、表单或加载态卡住
+- async 提交流程只处理成功路径，失败后没有恢复 loading、禁用态或错误提示
+- 派生状态可以由 props 或已有 state 计算，却被额外存一份，导致数据源不一致
+- `useEffect`、`watch`、订阅或事件监听缺少清理，导致重复触发或内存泄漏
+- 列表、条件渲染或切换视图时 key 不稳定，导致组件状态错位
+
+## 表单与边界条件
+
+- 空值、空数组、空字符串、`0`、`false` 等合法值被误判为“无数据”
+- 提交前缺少必要的禁用/防重入处理，重复点击会造成多次请求
+- 表单校验只在 happy path 下工作，错误态、回填、重置、回显场景失效
+- 可选字段在渲染或格式化时直接访问属性，存在 `undefined` 崩溃风险
+- 组件卸载后仍更新 state，导致警告、状态污染或用户感知异常
+
+## 组件边界与可维护性
+
+- 一个组件同时承担数据请求、业务编排、展示与样式细节，职责过重
+- props 设计泄露过多内部细节，调用方必须传入一组脆弱参数才能工作
+- 共享逻辑被复制到多个组件，而不是抽成 hook、composable 或 utility
+- 魔法字符串、裸枚举值、硬编码状态常量散落在模板和逻辑中
+
+## 测试
+
+- 交互行为发生变化，但没有新增或更新组件测试、交互测试或回归测试
+- 只测静态渲染，未覆盖点击、输入、异步完成、错误提示与边界场景
+- 断言过于宽泛，无法证明状态切换、按钮禁用、错误提示等关键行为
+
+## 排查思路
+
+审查时依次问自己：
+
+- 用户快速点击、重复提交、接口失败、组件卸载时，页面状态会不会错乱？
+- 这里的状态是单一事实来源，还是复制了一份容易漂移的派生数据？
+- 这段逻辑在列表重排、条件渲染、路由切换后还成立吗？
+- 如果没有明确代码路径支撑，不作为正式问题输出。

package/src/code-review-skills/frontend-code-review/references/rendering-performance-and-resource-loading.md

@@ -0,0 +1,34 @@
+# 渲染性能与资源加载检查项
+
+## 渲染性能
+
+- 每次渲染都新建昂贵对象、函数或计算结果，导致子组件无意义重渲染
+- 大列表缺少虚拟滚动、分页或窗口化处理，滚动和首屏性能明显回退
+- `useMemo`、`useCallback`、`computed`、缓存逻辑依赖错误，导致缓存失效或结果陈旧
+- 在渲染阶段执行高开销计算、深拷贝、正则或序列化
+
+## 资源与网络加载
+
+- 首屏新增大体积资源、同步阻塞资源或重复请求，没有 lazy load、拆包或缓存策略
+- 路由切换、搜索输入、滚动监听等高频场景没有 debounce/throttle 或取消机制
+- 同一页面重复拉取相同数据，缺少去重、缓存或失效策略
+
+## Hydration / SSR / CSR 风险
+
+- 服务端和客户端渲染依赖不同的数据、随机值、时间或环境变量，存在 hydration mismatch 风险
+- 在服务端渲染路径中直接访问 `window`、`document`、`localStorage` 等浏览器对象
+- 仅在客户端可用的副作用被放在首屏关键路径上，导致闪烁、抖动或状态不一致
+
+## 样式与布局稳定性
+
+- 样式改动导致关键内容不可见、覆盖、溢出、布局抖动或响应式断点失效
+- 动画、阴影、滤镜、回流频繁属性被用于大面积元素，可能引发卡顿
+
+## 排查思路
+
+审查时依次问自己：
+
+- 这个改动会不会让组件在每次输入、滚动、切换时都重复做昂贵工作？
+- 首屏、列表、大量节点、SSR hydration 场景是否比之前更脆弱？
+- 用户快速操作或慢网环境下，会不会出现重复请求、闪烁或状态回退？
+- 如果没有明确代码路径支撑，不作为正式问题输出。

package/src/code-review-skills/frontend-code-review/references/scoring-guide.md

@@ -0,0 +1,38 @@
+# 评分指南
+
+评分由**最严重的已确认问题**决定基准区间，再在区间内微调。
+
+## 第一步：确定基准区间
+
+| 最严重问题 | 分值区间 |
+|-----------|---------|
+| 无问题 | 9.0–10.0 |
+| 仅 P2/P3 | 7.5–9.0 |
+| P1 | 4.0–7.0 |
+| P0（crash、数据损坏） | 2.0–3.5 |
+| P0（安全漏洞、认证绕过） | 1.0–2.5 |
+
+## 第二步：在区间内调整
+
+- **影响广度**：影响所有用户取下限，仅边界场景触发取上限，差距约 0.5–1.0 分
+- **问题数量**：每多一个独立同级别问题，向下移约 0.3–0.5 分
+- **可逆性**：出问题后可以快速定位修复，可在区间内上浮 0.3–0.5 分
+
+> 多个问题时取区间下限附近；单个问题且影响有限时取区间上限附近。
+
+## 硬上限
+
+- 有任意 P0 → 评分上限 3.5
+- 核心页面或主交互完全失效 → 评分上限 2.5
+- 硬编码真实 credentials 或 secret 泄露 → 评分上限 2.0
+- 纯文件删除（无逻辑变更）→ 评分记为 N/A
+- 测试文件的问题 → 最高计为 P2，不纳入 P0/P1 计数
+
+## 评分语义
+
+| 分值 | 提交建议 | 含义 |
+|------|---------|------|
+| 9.0–10.0 | ✅ 可以提交 | 无明显问题 |
+| 7.5–9.0 | ✅ 可以提交，跟进修复 | 有轻微问题，不影响提交 |
+| 4.0–7.0 | 🔧 修复后提交 | 存在 P1 问题，影响广取下限，影响窄取上限 |
+| 1.0–3.5 | 🚫 禁止提交 | 存在 P0 问题，必须修复 |

package/src/code-review-skills/frontend-code-review/references/security-and-data-boundary.md

@@ -0,0 +1,34 @@
+# 安全与数据边界检查项
+
+## XSS 与危险内容注入
+
+- 未经转义的用户输入直接渲染到 HTML，或通过 `innerHTML`、`dangerouslySetInnerHTML` 注入页面
+- 富文本、Markdown、外部模板内容缺少白名单过滤或 sanitizer
+- 将不可信字符串拼进样式、URL、脚本片段或事件属性中，存在注入风险
+
+## 凭证与敏感信息
+
+- token、API key、密码、私有地址、测试账号写死在前端代码、配置或示例中
+- 将 access token、完整用户信息、敏感响应体直接打印到控制台或埋点日志
+- 把长期敏感凭证放入 `localStorage`、`sessionStorage` 或可被脚本随意读取的位置，且没有说明风险
+
+## 权限与数据暴露边界
+
+- 只靠前端开关隐藏按钮或页面，却默认信任客户端的权限判断
+- 将仅服务端应知的数据直接下发到前端并持久化缓存
+- 路由守卫、菜单显隐、特性开关逻辑不一致，导致越权入口仍可访问
+
+## 外部资源与跳转
+
+- 直接打开、拼接或渲染来自用户输入的 URL，没有校验协议、域名或目标来源
+- `postMessage`、iframe 通信或第三方脚本接入没有校验来源
+- 新增外链、下载地址或图片资源时，允许任意不可信地址进入关键页面
+
+## 排查思路
+
+审查时依次问自己：
+
+- 用户可控内容最终会不会进入 DOM、样式、URL、日志或本地存储？
+- 这个权限判断只是前端展示逻辑，还是被错误地当成真正的安全边界？
+- 这次改动有没有把本不该暴露给浏览器的信息带到客户端？
+- 如果没有明确代码路径支撑，不作为正式问题输出。

package/src/code-review-skills/golang-code-review/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: golang-code-reviewer
+review-domain: golang
+description: "Golang 专项代码审查技能，用于开发者在 commit 前审查 Go 服务、工具链与库改动。重点识别并发与资源生命周期问题、错误处理缺陷、接口契约风险、安全边界问题、性能回退与可维护性问题，给出可执行修复建议。默认只输出审查结论，不直接修改代码。"
+---
+
+# Golang 代码审查
+
+## 问题门槛
+
+每条问题必须满足以下三点，否则不输出：
+
+1. **可定位**：能指向具体文件和新增行号
+2. **可自证**：仅凭当前 diff 和可见上下文即可成立，不依赖 diff 之外的假设
+3. **可修复**：给出具体修复方案，而非泛泛建议
+
+同一根因的多处表现合并为一条，不重复列举。
+
+## 审查模式
+
+你会收到一段共享的 diff 类型识别结果。
+
+- 当识别结果为 `golang` 且与当前 skill 匹配时，按本 skill 的 Go 专项标准审查
+- 当识别结果与当前 skill 不匹配时，不要提示用户选错了 skill，也不要中止审查
+- 不匹配时继续使用同一输出格式，但按现有通用 `code-review` 审查基线做稳妥审查
+- 不匹配时减少对 Go 框架、部署环境和业务拓扑的特有假设
+
+## 严重级别
+
+| 等级 | 含义 | 处理 |
+|------|------|------|
+| **P0** | 安全漏洞、数据损坏、必现 panic、核心路径不可用 | 必须修复后才能提交 |
+| **P1** | 逻辑错误、功能异常、并发/资源泄漏、明显性能/可靠性回退 | 提交前修复 |
+| **P2** | 可维护性问题、测试不足、非阻塞设计问题 | 当前批次修复或登记后续任务 |
+| **P3** | 次要改进 | 可选 |
+
+## 工作流
+
+### 1) 确认审查范围
+
+先关注共享分类结果、`changedFiles` 与 diff 本身，再决定本次是否使用 Go 专项视角。
+
+- 当前 diff 主要是 `.go`、`go.mod`、`go.sum` 改动时，使用 Go 专项视角
+- 当前 diff 若明显偏前端、Java、Python 或类型不匹配，则直接回到通用稳妥审查
+- 不因为用户选择了 Golang skill 就强行输出 Go 专属问题
+
+### 2) 代码分析
+
+#### a) 并发与资源生命周期
+
+加载 `references/concurrency-and-lifecycle.md`，检查 goroutine 生命周期、context 传递、channel 使用、锁粒度、资源释放与取消链路。
+
+#### b) 错误处理与鲁棒性
+
+加载 `references/error-handling-and-reliability.md`，重点关注错误传播、包装、重试策略、超时边界与失败可观测性。
+
+#### c) 接口契约与可维护性
+
+加载 `references/api-contract-and-maintainability.md`，检查接口兼容性、nil 语义、边界约束、命名一致性、测试可维护性。
+
+#### d) 安全与信任边界
+
+加载 `references/security-and-trust-boundary.md`，检查鉴权边界、注入、SSRF、敏感日志与多租户/跨租户数据访问风险。
+
+#### e) 性能与分配行为
+
+加载 `references/performance-and-allocation.md`，检查算法复杂度、热路径分配、I/O 模式、批处理策略和锁竞争。
+
+#### f) 通用工程基线补充
+
+完成 Go 专项检查后，补充对通用 `code-review` 的以下基线检查：架构与设计，以及当 diff 包含删除时的冗余与残留引用。Go 专项维度只负责语言、运行时与服务边界风险，不替代通用工程审查。
+
+### 3) 整理问题列表
+
+确认每条问题满足门槛（可定位、可自证、可修复）。同一根因的多处表现合并为一条。不为凑数量降低标准。
+
+### 4) 评分
+
+加载 `references/scoring-guide.md`，**每次审查必须根据该指南给出具体评分**：先按最严重问题确定基准区间，再按影响广度、问题数量、可逆性在区间内微调，最终输出一个具体分值（如 8.5、7.0），不得只写区间或省略评分；纯文件删除时记为 N/A。
+
+### 5) 输出格式
+
+按以下格式输出：
+
+```markdown
+## 审查摘要
+
+**审查范围**：X 个文件，Y 行新增
+
+**评分**：X / 10（必须为具体分值，如 8.5；仅纯删除时为 N/A）
+
+**提交建议**：✅ 可以提交 / ✅ 可以提交，跟进修复 / 🔧 修复后提交 / 🚫 禁止提交
+
+**问题统计**：P0 × 个 / P1 × 个 / P2 × 个 / P3 × 个
+
+---
+
+## 各维度结果
+
+| # | 维度 | 结论 |
+|---|------|------|
+| 1 | 并发与资源生命周期 | ✅ 无问题 / ⚠️ 存在问题（简述） |
+| 2 | 错误处理与鲁棒性 | ✅ 无问题 / ⚠️ 存在问题（简述） |
+| 3 | 接口契约与可维护性 | ✅ 无问题 / ⚠️ 存在问题（简述） |
+| 4 | 安全与信任边界 | ✅ 无问题 / ⚠️ 存在问题（简述） |
+| 5 | 性能与分配行为 | ✅ 无问题 / ⚠️ 存在问题（简述） |
+
+---
+
+## 问题列表
+
+### P0 🔴 严重
+无
+
+### P1 🟠 高
+1. **[文件:行号] 问题标题**
+   - **问题**：一句话说明是什么问题
+   - **影响**：一句话说明会导致什么后果
+   - **修复**：具体方案
+
+### P2 🟡 中
+无
+
+### P3 🟢 低
+无
+
+---
+
+## 总体评价
+
+2-3 句话说明是否建议提交，以及还需要哪些修复或跟进。
+```
+
+**输出规则：**
+
+- 每次审查必须在「审查摘要」中给出根据 `references/scoring-guide.md` 计算的具体评分（X / 10），不得省略。
+- 直接给问题，不写前言铺垫。
+- 每条问题写清楚：位置、问题是什么、影响是什么、如何修复。
+- 只在有明确代码路径支撑时输出问题，不猜项目框架、运行环境或业务规则。
+- 如果共享分类结果提示应回到通用审查，则按通用基线保守审查，但仍然使用本 skill 的统一输出结构。
+- 禁止在模板之外添加"亮点"、"优点"、"表扬"等额外章节。
+- `## 总体评价` 只写 2-3 句连续段落，不用列表或子标题。
+
+## 参考文件
+
+| 文件 | 用途 |
+|------|------|
+| `concurrency-and-lifecycle.md` | 并发、context、资源生命周期与泄漏风险检查项 |
+| `error-handling-and-reliability.md` | error 传播、重试超时与鲁棒性检查项 |
+| `api-contract-and-maintainability.md` | 接口契约、nil 语义、可读性与可维护性检查项 |
+| `security-and-trust-boundary.md` | 鉴权、注入、SSRF 与敏感数据边界检查项 |
+| `performance-and-allocation.md` | 热路径分配、I/O 模式、锁竞争与性能检查项 |
+| `scoring-guide.md` | 评分模型、区间规则和提交建议 |

package/src/code-review-skills/golang-code-review/references/api-contract-and-maintainability.md

@@ -0,0 +1,25 @@
+# Go 接口契约与可维护性检查清单
+
+## API 契约与兼容性
+
+- 导出函数、结构体字段或接口变更是否会破坏已有调用方。
+- JSON / protobuf / DB 映射字段变更是否评估向后兼容性与迁移路径。
+- 错误返回、状态码和空值语义是否与历史行为保持一致或有明确升级说明。
+
+## 类型与抽象
+
+- 接口是否最小化，只暴露必要行为，避免为测试而设计过宽接口。
+- 是否过早抽象导致实现复杂化，简单场景是否可直接使用具体类型。
+- 泛型使用是否真正降低重复，约束是否清晰且不损失可读性。
+
+## 可读性与组织
+
+- 包边界是否清晰（`internal` / `pkg` / `cmd`），避免循环依赖与职责混乱。
+- 命名是否遵循 Go 习惯并表达领域语义，避免无意义缩写。
+- 函数是否过长、分支过深，是否可拆为可测试的小单元。
+
+## 测试与变更安全
+
+- 关键业务路径是否补充测试，尤其是边界条件和失败路径。
+- 表驱动测试是否覆盖主要分支，并包含可读的 case 名称。
+- 测试是否依赖不稳定外部环境，是否存在偶发失败风险。

package/src/code-review-skills/golang-code-review/references/concurrency-and-lifecycle.md

@@ -0,0 +1,25 @@
+# Go 并发与生命周期检查清单
+
+## Goroutine 生命周期
+
+- 新增 goroutine 是否有明确退出条件，是否可能因 channel 永久阻塞而泄漏。
+- 是否在请求级逻辑中将 `context.Context` 传递到下游调用，避免失去取消信号。
+- 后台任务是否区分短生命周期请求和长生命周期服务，避免与请求上下文错误绑定。
+
+## Channel 与同步
+
+- channel 的发送和接收是否成对，是否可能出现无人消费的发送阻塞。
+- `close(channel)` 是否只由生产方执行，是否存在多次关闭导致 panic 的路径。
+- `select` 分支是否处理 `ctx.Done()` 或超时，避免无限等待。
+- `sync.Mutex` / `RWMutex` 是否存在锁顺序反转、长临界区或 defer 解锁遗漏。
+
+## 资源生命周期
+
+- 文件、连接、响应体等资源是否在所有返回路径上关闭（包括错误路径）。
+- `defer` 是否位于资源成功创建之后，避免空对象 defer 或遗漏清理。
+- 池化对象（如 `sync.Pool`）是否正确归还，且不在归还后继续使用。
+
+## 可观测性与排障
+
+- 并发失败路径是否保留关键上下文（请求 ID、关键参数摘要）而不泄露敏感信息。
+- 超时、取消、重试终止是否可从日志或指标区分，便于定位问题。

package/src/code-review-skills/golang-code-review/references/error-handling-and-reliability.md

@@ -0,0 +1,24 @@
+# Go 错误处理与鲁棒性检查清单
+
+## 错误传播
+
+- 返回错误时是否保留根因，是否使用 `fmt.Errorf("...: %w", err)` 做包装。
+- 上层是否通过 `errors.Is` / `errors.As` 判断语义错误，避免字符串匹配。
+- 是否存在吞错（记录日志但继续返回 nil）导致失败不可见。
+
+## 失败边界与恢复
+
+- 对外部依赖（DB、RPC、HTTP）的失败是否有超时、重试上限与退避策略。
+- 重试是否满足幂等约束，是否可能放大副作用。
+- panic 风险路径是否可通过边界校验避免，必要 recover 是否在明确边界层处理。
+
+## 输入校验与契约
+
+- 入参是否在边界层完成最小必要校验，避免非法值深入核心逻辑。
+- 零值语义是否明确（如空切片与 nil 切片、0 与未设置）。
+- 错误码或错误类型是否稳定，避免破坏调用方处理逻辑。
+
+## 可运行性
+
+- 关键失败路径是否有可执行测试覆盖（单测或集成测试）。
+- 监控告警依赖的错误日志是否包含足够上下文并保持结构一致。

package/src/code-review-skills/golang-code-review/references/performance-and-allocation.md

@@ -0,0 +1,25 @@
+# Go 性能与分配行为检查清单
+
+## 算法与热路径
+
+- 热路径是否引入不必要的高复杂度操作（排序、全量扫描、重复解析）。
+- 循环内是否存在可外提计算或重复字符串拼接。
+- 批处理场景是否避免逐条远程调用导致放大延迟。
+
+## 内存分配与对象生命周期
+
+- 是否在高频路径产生可避免分配（临时切片、map 扩容、字符串转换）。
+- 切片预分配是否合理（`make(..., 0, n)`），避免频繁扩容复制。
+- 大对象是否长期持有导致 GC 压力上升，是否需要缩短引用链。
+
+## 并发性能
+
+- 锁竞争是否可能成为瓶颈，是否存在读多写少但未使用 `RWMutex` 的场景。
+- goroutine 数量是否受控，是否可能在高负载下无上限增长。
+- channel 缓冲大小是否与吞吐需求匹配，避免抖动或阻塞放大。
+
+## I/O 与外部系统
+
+- 数据库访问是否存在 N+1 查询、缺失索引或重复拉取。
+- 网络调用是否设置超时与连接复用，避免资源耗尽。
+- 序列化/反序列化是否在必要范围内执行，避免冗余编码开销。

package/src/code-review-skills/golang-code-review/references/scoring-guide.md

@@ -0,0 +1,40 @@
+# 评分指南
+
+评分由**最严重的已确认问题**决定基准区间，再在区间内微调。
+
+## 第一步：确定基准区间
+
+| 最严重问题 | 分值区间 |
+|-----------|---------|
+| 无问题 | 9.0-10.0 |
+| 仅 P2/P3 | 7.5-9.0 |
+| P1 | 4.0-7.0 |
+| P0（panic、数据损坏） | 2.0-3.5 |
+| P0（安全漏洞、权限绕过） | 1.0-2.5 |
+
+## 第二步：在区间内调整
+
+- **影响广度**：影响全量请求或核心链路取下限，仅边界场景触发取上限，差距约 0.5-1.0 分
+- **问题数量**：每多一个独立同级别问题，向下移约 0.3-0.5 分
+- **可逆性**：可快速定位、低风险修复的问题可上浮 0.3-0.5 分
+
+> 多个问题时取区间下限附近；单个问题且影响有限时取区间上限附近。
+
+## Go 语境硬上限
+
+- 有任意 P0 -> 评分上限 3.5
+- 核心服务主路径不可用 -> 评分上限 2.5
+- goroutine 明确泄漏且会持续放大 -> 评分上限 3.0
+- HTTP/RPC/数据边界上可证的注入、越权、SSRF 或跨租户访问 -> 评分上限 2.5
+- 硬编码真实 credentials 或 secret 泄露 -> 评分上限 2.0
+- 纯文件删除（无逻辑变更）-> 评分记为 N/A
+- 测试文件的问题 -> 最高计为 P2，不纳入 P0/P1 计数
+
+## 评分语义
+
+| 分值 | 提交建议 | 含义 |
+|------|---------|------|
+| 9.0-10.0 | ✅ 可以提交 | 无明显问题 |
+| 7.5-9.0 | ✅ 可以提交，跟进修复 | 有轻微问题，不影响提交 |
+| 4.0-7.0 | 🔧 修复后提交 | 存在 P1 问题，影响广取下限，影响窄取上限 |
+| 1.0-3.5 | 🚫 禁止提交 | 存在 P0 问题，必须修复 |

package/src/code-review-skills/golang-code-review/references/security-and-trust-boundary.md

@@ -0,0 +1,20 @@
+# Go 安全与信任边界检查清单
+
+## 鉴权与租户边界
+
+- 鉴权、租户隔离与资源归属校验是否在服务端边界强制执行，而不是只依赖上游约定或客户端参数。
+- 查询、缓存键、批量操作与后台任务是否遗漏租户/用户范围约束，导致跨租户或越权读写。
+
+## 输入、注入与外部调用
+
+- SQL、命令、模板、正则或路径拼接是否引入注入风险；动态构造语句时是否仍保留参数化边界。
+- 对外部 URL、Webhook、回调地址或代理目标的访问是否可能引入 SSRF、内网探测或重定向滥用。
+
+## 敏感信息与可观测性
+
+- 日志、指标标签、trace 属性或错误包装是否写入 token、密钥、完整 PII 或受保护业务字段。
+- 配置、环境变量与默认值是否把真实 secret、调试开关或危险能力暴露到不可信环境。
+
+## 边界判断
+
+- 仅在 diff 可明确体现信任边界、数据来源与输出路径时输出正式安全问题，避免脱离上下文猜测部署拓扑。