From 4db2727f17bb9513d76cfa57f0a6e74864349885 Mon Sep 17 00:00:00 2001
From: wehub-skill-sync <skill-sync@wehub.local>
Date: Mon, 13 Jul 2026 21:35:46 +0800
Subject: [PATCH] chore: import zh skill code-reviewer

---
 README.wehub.md |  9 +++++++
 SKILL.md        | 62 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+)
 create mode 100644 README.wehub.md
 create mode 100644 SKILL.md

diff --git a/README.wehub.md b/README.wehub.md
new file mode 100644
index 0000000..4c39c33
--- /dev/null
+++ b/README.wehub.md
@@ -0,0 +1,9 @@
+# WeHub 来源说明
+
+- Skill 名称：`code-reviewer`
+- 中文类目：清单驱动代码审查
+- 上游仓库：`google-gemini__gemini-cli`
+- 上游路径：`.gemini/skills/code-reviewer/SKILL.md`
+- 上游链接：https://github.com/google-gemini/gemini-cli/blob/HEAD/.gemini/skills/code-reviewer/SKILL.md
+- 本仓库为 WeHub 中文 Skill 汉化包，基于 skill 市场筛选 Top200 清单整理
+- 原作者、版权和许可证信息以上游仓库为准
diff --git a/SKILL.md b/SKILL.md
new file mode 100644
index 0000000..7999731
--- /dev/null
+++ b/SKILL.md
@@ -0,0 +1,62 @@
+---
+name: code-reviewer
+description: 使用本技能进行代码审查。它既支持本地更改（暂存区或工作树），也支持远程 Pull Request（通过 ID 或 URL）。审查重点在于正确性、可维护性以及对项目标准的遵循情况。
+---
+
+# 代码审查员
+
+本技能引导代理对本地开发中的更改和远程 Pull Request 进行专业、彻底的代码审查。
+
+## 工作流程
+
+### 1. 确定审查目标
+*   **远程 PR**：如果用户提供了 PR 编号或 URL（例如「审查 PR #123」），则以该远程 PR 为目标。
+*   **本地更改**：如果没有提及特定的 PR，或者用户要求「审查我的更改」，则以当前本地文件系统的状态（暂存和未暂存的更改）为目标。
+
+### 2. 准备工作
+
+#### 针对远程 PR：
+1.  **检出**：使用 GitHub CLI 检出该 PR。
+    ```bash
+    gh pr checkout <PR_NUMBER>
+    ```
+2.  **预检**：执行项目的标准验证套件，尽早发现自动化失败项。
+    ```bash
+    npm run preflight
+    ```
+3.  **上下文**：阅读 PR 描述和任何已有的评论，以了解其目标和历史。
+
+#### 针对本地更改：
+1.  **识别更改**：
+    *   检查状态：`git status`
+    *   读取差异：`git diff`（工作树）和/或 `git diff --staged`（暂存区）。
+2.  **预检（可选）**：如果更改量较大，询问用户是否希望在审查前运行 `npm run preflight`。
+
+### 3. 深入分析
+从以下几个维度分析代码更改：
+
+*   **正确性**：代码是否实现了其声称的目的，没有缺陷或逻辑错误？
+*   **可维护性**：代码是否整洁、结构良好、易于理解和将来修改？考虑代码清晰度、模块化程度以及对既定设计模式的遵循情况。
+*   **可读性**：代码注释是否得当（必要时），且格式是否符合项目的编码风格指南？
+*   **效率**：更改是否引入了明显的性能瓶颈或资源浪费？
+*   **安全性**：是否存在潜在的安全漏洞或不安全的编码实践？
+*   **边界情况与错误处理**：代码是否妥善处理了边界情况和潜在错误？
+*   **可测试性**：新增或修改的代码是否得到了测试的充分覆盖（即使预检已通过）？建议能提高覆盖率或健壮性的额外测试用例。
+
+### 4. 提供反馈
+
+#### 结构
+*   **摘要**：审查的总体概述。
+*   **发现**：
+    *   **严重**：缺陷、安全问题或破坏性更改。
+    *   **改进**：针对更好的代码质量或性能的建议。
+    *   **小细节**：格式或微小的样式问题（可选）。
+*   **结论**：明确的建议（批准 / 请求修改）。
+
+#### 语气
+*   保持建设性、专业且友好。
+*   解释*为什么*要求某项更改。
+*   对于批准，明确肯定该贡献的具体价值。
+
+### 5. 清理（仅限远程 PR）
+*   审查完成后，询问用户是否要切回默认分支（例如 `main` 或 `master`）。