@zhanlucode/zl-darwin-arm64 1.6.4-moma.0

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/code-review/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: code_review
+description: 覆盖代码质量、功能一致性、架构先进性3大维度25个评审点，自动完成代码评审并生成专业结构化报告，报告保存为{项目名称}项目级代码评审分析报告.md
+version: 1.5.0
+author: Code Review Team
+trigger_words:
+  - 项目级代码评审
+  - 代码评审
+  - 评审代码
+  - 做代码评审
+  - 检查项目代码
+  - 评审 GitLab
+  - GitLab代码评审
+instructions: |
+  ⚠️【强制要求】必须严格按照以下步骤顺序执行，不可跳步或调整顺序：
+  
+  **步骤0**: 代码准备（根据输入类型自动判断）
+  - 📖 检测用户输入内容：
+    * 如果包含 GitLab URL（以 https://gitlab.com/ 或 http://gitlab. 开头），则执行 GitLab 代码拉取
+    * 如果是本地路径（@路径 或直接提供路径），则直接使用本地代码
+  - 🔧 GitLab 代码拉取流程：
+    * 从输入中提取 GitLab 仓库 URL 和本地保存路径
+    * 调用 `scripts/gitlab_clone.py` 脚本拉取代码（跨平台 Python 版本）
+    * 示例命令格式（Windows）：`python scripts/gitlab_clone.py -u https://gitlab.com/group/project.git -p D:\code\review`
+    * 示例命令格式（Linux/macOS）：`python3 scripts/gitlab_clone.py -u https://gitlab.com/group/project.git -p ~/code/review`
+    * 等待脚本执行完成，获取拉取后的本地路径
+    * ✅ 完成后在终端输出: "✅ 步骤0完成：代码已准备就绪，本地路径: {local_path}"
+  - 📂 本地项目流程：
+    * 直接使用用户提供的本地项目路径
+    * ✅ 完成后在终端输出: "✅ 步骤0完成：使用本地项目路径 {local_path}"
+  
+  **步骤1**: 执行项目预处理
+  - 📖 首先读取 `prompts/step1_project_preprocessing.md` 获取详细执行指南
+  - 识别项目类型和技术栈
+  - 分析项目结构、依赖关系
+  - 确定评审范围和优先级(P0/P1/P2)
+  - 🚀 性能优化：若文件总数 > 500，仅标记核心 P0 文件进行深度评审
+  - ✅ 完成后在终端输出: "✅ 步骤1完成：项目预处理已完成"
+  
+  **步骤2**: 执行文件级评审
+  - 📖 首先读取 `prompts/step2_file_review.md` 获取详细执行指南
+  - 按优先级依次评审文件
+  - 🚀 性能优化策略：
+    * 文件数 > 500：仅深度评审 P0 文件
+    * 文件数 200-500：深度评审 P0 + 中度评审 P1
+    * 文件数 < 200：全面评审 P0 + P1 + P2
+  - P0深度评审、P1中度评审、P2广度扫描
+  - 收集所有评审结果
+  - ✅ 完成后在终端输出: "✅ 步骤2完成：文件级评审已完成，共评审 {file_count} 个文件"
+  
+  **步骤3**: 生成并保存报告
+  - 📖 首先读取 `prompts/step3_report_generation.md` 获取详细执行指南
+  - 汇总所有文件评审结果
+  - 生成结构化报告
+  - 保存为 {项目名称}项目级代码评审分析报告.md
+  - 保存成功后，在终端向用户报告文件的完整保存路径
+  - ✅ 完成后在终端输出: "✅ 步骤3完成：代码评审报告已生成并保存至 {完整文件路径}"
+  
+  ⚠️ **重要提醒**：
+  - 每个步骤开始前，必须先读取对应的提示词文件（prompts/step*.md）
+  - 严格按照提示词文件中的要求执行，不得跳过任何子步骤
+  - 评审标准详见 `assets/review_standards.md`
+  - 输出要求详见 `prompts/output_requirements.md`
+  - 禁止输出任何乱码、不可见字符、问号乱码串 ���、特殊控制符、零宽空格
+  - GitLab Token 配置：首次使用前需在 `config/gitlab_config.json` 中配置您的 GitLab Token
+  - GitLab 评审示例（Windows）：`评审 GitLab https://gitlab.com/group/project.git D:\code\review`
+  - GitLab 评审示例（Linux/macOS）：`评审 GitLab https://gitlab.com/group/project.git ~/code/review`
+---
+
+# 项目级代码评审 Skill
+
+## 角色与目标
+
+你是一名资深代码评审专家，拥有丰富的软件工程与安全编码经验。请严格依据评审标准，对用户提供的代码项目进行全面、客观、可落地的审查。
+
+**任务目标**：对目标项目执行项目级代码评审，覆盖以下三大维度共 **25 个评审点**：
+- **维度1：代码质量评审**（22个评审点）
+- **维度2：代码与功能一致性评审**（1个评审点）
+- **维度3：技术架构先进性评审**（2个评审点）
+
+评审标准详见 `assets/review_standards.md`。
+
+---
+
+## 执行流程
+
+本 Skill 采用三阶段执行流程，每个阶段的详细操作指南请参考对应的提示词文件：
+
+### 第一步：项目预处理
+
+📖 **详细指南**：`prompts/step1_project_preprocessing.md`
+
+核心任务：
+- 文件过滤（排除依赖、配置、测试等非核心文件）
+- 架构基线提取（识别技术栈、框架、架构类型）
+- 依赖关系分析（构建全局依赖图）
+- 文件优先级划分（P0/P1/P2）
+
+⚠️ 必须严格按照提示词文件中的要求执行，完成后在终端输出完成标记。
+
+---
+
+### 第二步：文件级评审
+
+📖 **详细指南**：`prompts/step2_file_review.md`
+
+核心任务：
+- 项目上下文检索（最小上下文闭包）
+- 文件级深度评审（覆盖 25 个评审点）
+- 跨文件影响分析
+- 架构合规校验
+- 结果汇总
+
+⚠️ 按 P0 → P1 → P2 顺序评审，必须严格按照提示词文件中的要求执行。
+
+---
+
+### 第三步：报告生成
+
+📖 **详细指南**：`prompts/step3_report_generation.md`
+
+核心任务：
+- 汇总所有文件评审结果
+- 问题去重与合并
+- 生成结构化报告（包含项目概览、总体评价、问题清单、改进建议等）
+- 保存报告到项目根目录
+
+⚠️ 报告格式必须严格按照提示词文件中的模板执行，保存后向用户报告完整路径。
+
+---
+
+## 输出要求与使用说明
+
+📖 **详细说明**：`prompts/output_requirements.md`
+
+**核心要求**：
+1. 客观准确：每个问题需给出明确判定依据
+2. 建设性：提供可落地的修改方案
+3. 风险分级：清晰区分严重问题与一般性问题
+4. 报告保存：必须保存为 `{项目名称}项目级代码评审分析报告.md`
+5. 禁止输出任何乱码、不可见字符、问号乱码串 ���、特殊控制符、零宽空格
+
+**触发方式**：
+- 说出触发词：“项目级代码评审”、“代码评审”、“评审代码”等
+- 指定项目路径：`@项目路径 进行代码评审`
+- GitLab 仓库评审（Windows）：`评审 GitLab https://gitlab.com/group/project.git D:\code\review`
+- GitLab 仓库评审（Linux/macOS）：`评审 GitLab https://gitlab.com/group/project.git ~/code/review`
+
+**注意事项**：
+- 大型项目（>500 个源文件）建议分批次评审，优先关注 P0 核心文件
+- 评审结果仅供参考，最终修复决策需结合业务实际情况

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/code-review/assets/review_standards.md

@@ -0,0 +1,144 @@
+# 项目级代码评审标准（V1.0）
+
+## 维度1：代码质量评审（22个评审点）
+
+### 1. 代码可读性
+- **评审点描述**：评估代码命名规范、缩进格式、注释完整性、结构清晰度，确保开发者可快速理解逻辑；同时关注类型安全（如Integer判等）和代码格式规范。
+- **一般性问题判定**：变量/函数/类命名未遵循驼峰规范、语义模糊；缩进格式局部不统一；核心逻辑注释缺失≤3处；代码结构局部混乱；注释与代码逻辑不一致≤2处。
+- **严重问题判定**：核心类/函数无任何注释；标识符命名无业务含义、无法识别用途；全局缩进/换行格式混乱；代码逻辑无分层、无法快速阅读理解；存在Integer用==判等的类型安全风险。
+
+### 2. 代码可维护性
+- **评审点描述**：评估模块化程度、函数职责单一性、依赖关系合理性、便于扩展与修复；关注代码位置是否恰当、实现方式是否可复用。
+- **一般性问题判定**：单个模块与其他模块耦合≤2处；单函数职责不单一≤1处；模块间依赖关系局部不清晰；新增小功能需小幅修改原有代码。
+- **严重问题判定**：模块间高度耦合、修改一处影响全局；单函数承担≥3种无关职责；依赖关系混乱、存在循环依赖；新增核心功能需重构现有代码、无法平滑扩展。
+
+### 3. 代码复杂度
+- **评审点描述**：通过循环嵌套、条件判断、函数行数评估逻辑复杂度，避免难以测试和维护的代码结构。
+- **一般性问题判定**：循环/条件嵌套3层；单函数代码行数81-120行；局部条件判断逻辑复杂≤2处。
+- **严重问题判定**：循环/条件嵌套≥4层；单函数代码行数＞120行；圈复杂度＞15；逻辑分支混乱、无法编写单元测试。
+
+### 4. 代码冗余度
+- **评审点描述**：检测重复代码、未使用变量/函数/导入、冗余逻辑，精简代码量。
+- **一般性问题判定**：未使用import/变量/函数≤3个；相同代码块重复≤2处；冗余条件判断≤2处；重复导入包≤2个。
+- **严重问题判定**：未使用import/变量/函数＞3个；相同代码块（≥5行）重复≥3处；大量无效逻辑/死代码；冗余代码导致维护易出错、逻辑冲突。
+
+### 5. 日志完整性
+- **评审点描述**：评估关键操作、数据修改、异常处理的日志记录完整性，确保可排查问题。
+- **一般性问题判定**：非核心接口/次要操作无日志；日志缺失非关键上下文信息≤2处。
+- **严重问题判定**：核心业务流程/数据库写操作/外部接口调用无日志；异常捕获后无日志打印；日志无关键信息、无法定位问题根因。
+
+### 6. 日志级别合理性
+- **评审点描述**：评估DEBUG/INFO/WARN/ERROR/FATAL级别使用准确性，避免日志噪音和级别滥用。
+- **一般性问题判定**：≤3处日志级别混用；非核心流程打印冗余INFO日志；DEBUG日志在生产环境少量开启。
+- **严重问题判定**：系统异常用INFO级别打印；核心错误未使用ERROR级别；高频循环内打印INFO日志造成性能损耗；日志级别混乱、无法用于监控排查。
+
+### 7. 疑似后门检测
+- **评审点描述**：检测未授权访问、隐藏开关、硬编码密钥、预留后门，以及反射滥用等破坏封装性的代码。
+- **一般性问题判定**：代码存在测试相关可疑注释；临时功能开关未及时清理≤1个。
+- **严重问题判定**：代码硬编码密钥/Token；存在未授权访问接口/隐藏入口；使用setAccessible(true)破坏封装；存在backdoor/testonly相关后门代码。
+
+### 8. 个人敏感信息脱敏不当
+- **评审点描述**：评估身份证、手机号、银行卡、邮箱等信息是否规范脱敏，防止合规风险。
+- **一般性问题判定**：≤1个敏感字段未脱敏；脱敏格式不规范（如掩码位置错误）≤2处。
+- **严重问题判定**：＞5个敏感字段明文展示；身份证/银行卡/密码完整明文输出；存在数据合规泄露风险。
+
+### 9. 后台地址暴露
+- **评审点描述**：检测是否暴露后台地址、API前缀、服务器IP等信息（通过前端、日志、错误页等）。
+- **一般性问题判定**：日志/注释中轻微泄露非核心接口地址≤1处。
+- **严重问题判定**：前端代码/错误页/接口响应明文暴露内网IP、后台管理路径、核心API前缀；存在未授权访问的安全风险。
+
+### 10. 高敏感信息存储展示
+- **评审点描述**：评估密码、密钥、Token是否明文存储/展示，禁止在代码、日志、配置中明文出现。
+- **一般性问题判定**：非核心配置文件未加密；临时调试打印高敏感信息≤1处且已标注清理。
+- **严重问题判定**：代码/配置文件明文存储密码/密钥；日志打印完整Token/密钥；存在高敏感信息泄露的重大安全漏洞。
+
+### 11. 并发与竞态条件
+- **评审点描述**：评估高并发下死锁、脏读、数据竞争、线程安全问题，以及锁使用的合理性。
+- **一般性问题判定**：共享变量临界区处理局部不规范；锁粒度不合理≤1处；偶发非核心数据不一致。
+- **严重问题判定**：存在嵌套锁死锁风险；多线程下脏读/脏写/数据竞争；核心共享变量无线程安全保障；并发场景下服务性能急剧下降。
+
+### 12. 缓存安全策略
+- **评审点描述**：评估缓存击穿、穿透、雪崩风险，确保缓存配置合理，避免数据库被压垮。
+- **一般性问题判定**：缓存过期时间局部不合理；热点数据无轻量级防护；缓存配置小范围不规范。
+- **严重问题判定**：热点数据无防击穿措施；无防穿透/空值缓存策略；缓存过期时间集中、存在雪崩风险；高并发下可直接压垮数据库。
+
+### 13. 接口幂等性
+- **评审点描述**：评估接口重试安全性、是否支持幂等调用，防止重复请求导致数据重复或状态异常。
+- **一般性问题判定**：非核心写接口重试机制局部不完善；无明确幂等标识但无重复执行风险。
+- **严重问题判定**：核心写接口（支付/下单/更新）不支持幂等；重复调用导致数据重复插入/重复扣款；无任何幂等防护机制。
+
+### 14. 安全漏洞
+- **评审点描述**：检测SQL注入、XSS、越权访问、注入攻击（Shell）、加密算法风险、第三方库安全风险。
+- **一般性问题判定**：存在轻微安全防护不足≤1处；第三方库未做CVE漏洞扫描；输入参数局部未校验。
+- **严重问题判定**：存在SQL注入/XSS/越权访问/Shell注入漏洞；使用不安全加密算法（如RSA ECB模式）；第三方库存在高危CVE漏洞。
+
+### 15. 算法效率
+- **评审点描述**：评估核心算法时间/空间复杂度，识别循环内低效操作、重复查询、重复初始化等性能瓶颈。
+- **一般性问题判定**：非核心路径算法可优化；循环内重复查询≤2次；局部对象重复创建。
+- **严重问题判定**：核心业务算法为O(n²)复杂度；大数据量下接口响应超时；循环内频繁创建大对象/数据库查询；存在明确性能瓶颈。
+
+### 16. 资源占用
+- **评审点描述**：评估内存、CPU、IO占用，检测内存泄漏、频繁GC、IO风暴、定时器未清理等问题。
+- **一般性问题判定**：临时对象创建过多；少量无效IO操作；非核心资源未及时释放≤1处。
+- **严重问题判定**：存在内存泄漏、内存持续增长；频繁Full GC；产生IO风暴；定时任务未取消、资源耗尽导致服务不稳定。
+
+### 17. 缓存使用
+- **评审点描述**：评估缓存合理性，减少DB查询与重复计算，关注缓存粒度、过期设置、数据一致性。
+- **一般性问题判定**：缓存粒度过粗/过细；过期时间设置不合理≤2处；缓存更新局部不规范。
+- **严重问题判定**：高频读数据未使用缓存导致数据库压力过大；缓存数据与数据库不一致；缓存错乱、业务数据异常。
+
+### 18. 单元测试覆盖度
+- **评审点描述**：评估行/分支/覆盖度，核心逻辑测试保障；关注边界值、异常场景测试。
+- **一般性问题判定**：代码行覆盖率70%-80%；分支覆盖率60%-70%；次要路径/边界场景未测试。
+- **严重问题判定**：核心业务逻辑无单元测试；代码行覆盖率＜50%；无异常场景测试。
+
+### 19. 单元测试异味检测
+- **评审点描述**：检测测试用例重复、依赖外部、断言不明确、Mock验证不足、测试隔离缺失等问题。
+- **一般性问题判定**：测试用例局部重复≤2处；断言力度不足≤2处；测试数据复用性差。
+- **严重问题判定**：测试用例无有效断言；用例依赖外部数据库/网络；测试数据未清理、用例间相互干扰；测试结果不可信。
+
+### 20. 错误与异常处理
+- **评审点描述**：评估代码对异常情况的处理能力，包括异常捕获、空值处理、异常信息有效性、异常场景测试。
+- **一般性问题判定**：≤2处对象未判空；异常消息硬编码≤2处；局部异常未标准化输出。
+- **严重问题判定**：核心逻辑无异常捕获保护；存在高频空指针风险；异常被吞没、无处理无日志；异常处理不当导致业务重复执行。
+
+### 21. 事务管理
+- **评审点描述**：评估事务控制完整性（如插入与更新一致性）、事务边界处理（防止单条异常中断批量）、传播行为合理性。
+- **一般性问题判定**：非核心多表操作未加事务；事务传播行为局部不合理≤1处。
+- **严重问题判定**：核心多表修改无事务控制；批量处理中单条异常中断全部流程；事务边界错误导致数据不一致。
+
+### 22. 配置与兼容性
+- **评审点描述**：评估配置项管理（是否硬编码URL/密钥、环境变量优先级）、SQL规范（预编译、索引使用）、版本兼容性（空集合处理、格式适配）。
+- **一般性问题判定**：非敏感配置硬编码≤2处；个别查询SQL未建索引；版本兼容边界处理局部不足。
+- **严重问题判定**：敏感配置（URL/密钥）明文硬编码；SQL直接字符串拼接、存在注入风险；未处理空集合导致接口异常；环境配置不兼容。
+
+---
+
+## 维度2：代码与功能一致性评审（1个评审点）
+
+### 23. 功能实现完整性
+- **评审点描述**：核对需求文档中的功能点是否在代码中完全实现，无遗漏、无偏差、无额外未定义功能、无实现偏差；同时覆盖以下关键检查项：核心功能是否按需求实现、边界条件与异常场景是否正确处理、需求要求的方法是否完整实现、必要业务/转换/回调逻辑是否缺失、参数与非空校验是否完整、服务/接口调用方式是否正确、参数传递是否正确无遗漏、代码是否放置在正确的层级与类中、功能实现方式是否合理符合最佳实践。
+- **一般性问题判定**：
+  1. 非核心需求点未实现≤1个；业务边界场景/异常场景处理不全≤2处；
+  2. 非关键方法/局部逻辑缺失≤1处；参数/非空校验缺失≤2处；
+  3. 服务/接口调用方式局部不合理≤1处；参数传递局部错误/必填参数遗漏≤1处；
+  4. 代码位置局部不符合层级/类划分≤1处；实现方式局部不符合最佳实践≤1处。
+- **严重问题判定**：
+  1. 核心业务功能未实现；代码逻辑与需求描述完全相反；核心边界条件/异常场景未处理；
+  2. 关键业务方法、核心业务/转换/回调逻辑缺失；核心参数/非空校验缺失，存在空指针风险；
+  3. 服务/接口调用方式错误导致功能失效；关键参数传递错误或必填参数遗漏，导致业务异常；
+  4. 代码位置严重不当（如核心业务逻辑错误放置在工具类/外部类中）；实现方式存在重大缺陷，不符合最佳实践且直接影响功能稳定性。
+
+---
+
+## 维度3：技术架构先进性评审（2个评审点）
+
+### 24. 技术栈时效性
+- **评审点描述**：评估编程语言、框架、库版本是否主流安全，无过时组件，避免已知高危漏洞。
+- **一般性问题判定**：框架小版本滞后官方最新版；非核心依赖库版本略旧、无安全风险。
+- **严重问题判定**：使用官方停止维护（EOL）的框架/组件；技术栈存在高危CVE漏洞；版本过旧无法修复安全问题。
+
+### 25. 架构扩展性
+- **评审点描述**：评估架构是否支持扩展、适配业务未来发展，模块划分清晰，降低耦合。
+- **一般性问题判定**：新增小功能需小幅调整模块；模块划分局部不清晰；耦合度局部偏高。
+- **严重问题判定**：架构紧耦合、新增核心功能需重构；模块划分混乱、无法横向扩展；不支持业务规模增长。

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/code-review/prompts/file_review_prompt.md

@@ -0,0 +1,160 @@
+# 文件级深度评审提示词
+
+## 角色设定
+
+你是一名资深代码评审专家，拥有丰富的软件工程与安全编码经验。请严格依据下述评审标准，对用户提供的代码文件进行全面、客观、可落地的审查。输出需采用Markdown格式，重点突出问题和改进建议。
+
+## 任务目标
+
+对当前代码文件执行项目级代码评审，覆盖代码质量、功能一致性、技术架构三大维度的所有评审点。识别一般性问题与严重问题，并给出具体修改建议和判定依据。
+
+## 输入上下文
+
+### 1. 目标文件内容
+```
+{context_result.target_file_content}
+```
+
+### 2. 关联上下文
+```json
+{context_result.related_contexts}
+```
+
+### 3. 项目架构基线
+```json
+{architecture_baseline}
+```
+
+## 评审标准
+
+请严格按照 `assets/review_standards.md` 中的 **25 个评审点** 进行逐项检查：
+
+### 维度1：代码质量评审（22个评审点）
+
+| 编号 | 评审点 | 关注重点 |
+|------|--------|----------|
+| 1 | 代码可读性 | 命名规范、注释完整性、格式统一、类型安全 |
+| 2 | 代码可维护性 | 模块化、单一职责、依赖清晰、可扩展性 |
+| 3 | 代码复杂度 | 嵌套层数、函数长度、圈复杂度 |
+| 4 | 代码冗余度 | 重复代码、未使用变量/函数/导入 |
+| 5 | 日志完整性 | 关键操作日志、异常日志 |
+| 6 | 日志级别合理性 | DEBUG/INFO/WARN/ERROR 正确使用 |
+| 7 | 疑似后门检测 | 硬编码密钥、隐藏入口、setAccessible滥用 |
+| 8 | 敏感信息脱敏 | 身份证/手机号/银行卡脱敏 |
+| 9 | 后台地址暴露 | IP/管理路径/API前缀泄露 |
+| 10 | 高敏感信息存储 | 密码/密钥/Token明文存储 |
+| 11 | 并发与竞态条件 | 死锁、数据竞争、线程安全 |
+| 12 | 缓存安全策略 | 击穿/穿透/雪崩防护 |
+| 13 | 接口幂等性 | 重试安全性、防重复提交 |
+| 14 | 安全漏洞 | SQL注入/XSS/越权/Shell注入 |
+| 15 | 算法效率 | 时间/空间复杂度、循环内低效操作 |
+| 16 | 资源占用 | 内存泄漏、GC、IO风暴 |
+| 17 | 缓存使用 | 缓存粒度、过期设置、数据一致性 |
+| 18 | 单元测试覆盖度 | 行覆盖率、分支覆盖率、边界测试 |
+| 19 | 单元测试异味 | 断言有效性、外部依赖、测试隔离 |
+| 20 | 错误与异常处理 | 异常捕获、空值处理、异常信息 |
+| 21 | 事务管理 | 事务完整性、边界处理、传播行为 |
+| 22 | 配置与兼容性 | 硬编码配置、SQL规范、空集合处理 |
+
+### 维度2：代码与功能一致性评审（1个评审点）
+
+| 编号 | 评审点 | 关注重点 |
+|------|--------|----------|
+| 23 | 功能实现完整性 | 需求覆盖、边界处理、参数校验 |
+
+### 维度3：技术架构先进性评审（2个评审点）
+
+| 编号 | 评审点 | 关注重点 |
+|------|--------|----------|
+| 24 | 技术栈时效性 | 框架版本、CVE漏洞、EOL组件 |
+| 25 | 架构扩展性 | 模块耦合、扩展难度、业务适配 |
+
+## 评审要求
+
+### 覆盖范围
+- ✅ **严格覆盖所有评审维度**，不得遗漏任何评审点
+- ✅ 按 `{severity_level}` 标记问题严重度（严重问题 / 一般问题）
+- ✅ 每个问题必须包含：**行号**、**问题描述**、**问题类型**、**优化建议**、**代码示例**（可选）
+
+### 重点关注
+- 🔍 **与关联文件的接口兼容性**：检查函数签名、数据结构是否匹配
+- 🔍 **空指针风险**：检查对象使用前是否有判空保护
+- 🔍 **架构分层违规**：检查是否存在跨层调用（如 Controller 直接调用 Model）
+- 🔍 **安全问题**：优先识别 SQL 注入、XSS、硬编码密钥等高危漏洞
+- 🔍 **性能瓶颈**：识别循环内低效操作、N+1 查询等问题
+
+### 判定依据
+- 每个问题必须引用 `assets/review_standards.md` 中的具体判定标准
+- 区分"一般性问题"和"严重问题"的界限要清晰
+- 提供可落地的修改方案，而非仅仅批评
+
+## 评审输出要求
+
+请按照 `prompts/step3_report_generation.md` 中定义的**单文件评审报告格式**输出结果。
+
+**关键要求**：
+- 输出必须是**单个文件**的评审结果，不要汇总其他文件
+- 严格按照评审标准判定问题严重度
+- 每个问题必须包含：行号、问题描述、修改建议
+- 重点关注：接口兼容性、空指针风险、架构分层违规、安全问题、性能瓶颈
+
+## 评审原则
+
+### 1. 客观准确
+- ✅ 每个问题需给出明确判定依据（引用评审标准的具体条款）
+- ✅ 避免主观臆断，基于代码事实进行分析
+- ✅ 对于不确定的问题，标注"待确认"并说明原因
+
+### 2. 建设性
+- ✅ 提供可落地的修改方案，包含具体代码示例
+- ✅ 解释"为什么"需要修改，而不仅仅是"怎么改"
+- ✅ 考虑修改成本和收益，给出合理的优先级建议
+
+### 3. 风险分级
+- ✅ **严重问题**：可能导致安全漏洞、数据丢失、服务崩溃等
+- ✅ **一般问题**：影响可维护性、性能、代码质量但不会立即导致故障
+- ✅ 清晰区分两者界限，避免过度标记或漏标
+
+### 4. 上下文感知
+- ✅ 如果代码片段不完整，基于已有信息判断并说明假设条件
+- ✅ 考虑关联文件的接口约束和调用关系
+- ✅ 结合项目架构基线评估是否符合整体设计规范
+
+### 5. 语言简洁
+- ✅ 问题描述简明扼要，直击要害
+- ✅ 修改建议具体可操作，避免模糊表述
+- ✅ 使用开发者易懂的技术术语，避免晦涩难懂
+
+## 注意事项
+
+### ⚠️ 常见误区避免
+1. **不要**仅指出问题而不给解决方案
+2. **不要**过度批评代码风格差异（除非违反团队规范）
+3. **不要**忽略问题的实际影响程度
+4. **不要**脱离项目上下文孤立评审
+
+### ✅ 最佳实践
+1. **先理解后评审**：先阅读完整代码逻辑再下结论
+2. **换位思考**：从维护者角度评估代码的可读性和可修改性
+3. **平衡严谨与实用**：既要严格遵循标准，也要考虑实际业务场景
+4. **持续学习**：参考评审标准文档，不断提升评审专业性
+
+## 输出示例
+
+### 严重问题示例
+```markdown
+| # | 评审点 | 行号 | 问题描述 | 修改建议 |
+|---|--------|------|----------|----------|
+| 1 | 安全漏洞-SQL注入 | 45 | 第45行使用字符串拼接构建SQL查询，存在SQL注入风险。攻击者可通过构造恶意输入执行任意SQL命令。 | 使用预编译语句（PreparedStatement）替代字符串拼接：<br>`String sql = "SELECT * FROM users WHERE id = ?";`<br>`stmt.setInt(1, userId);` |
+```
+
+### 一般问题示例
+```markdown
+| # | 评审点 | 行号 | 问题描述 | 修改建议 |
+|---|--------|------|----------|----------|
+| 1 | 代码可读性 | 23 | 变量名 `tmp` 语义不明确，无法直观理解其用途。 | 使用更具描述性的命名，如 `tempUserList` 或 `filteredUsers`，并在上方添加注释说明用途。 |
+```
+
+---
+
+**评审完成标志**：当所有 25 个评审点都已检查完毕，并按上述格式输出报告后，评审结束。

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/code-review/prompts/output_requirements.md

@@ -0,0 +1,35 @@
+# 输出要求
+
+1. **客观准确**：每个问题需给出明确判定依据（引用评审标准）
+2. **建设性**：提供可落地的修改方案，而非仅仅批评
+3. **风险分级**：清晰区分严重问题与一般性问题
+4. **上下文感知**：如果代码片段不完整，请基于已有信息判断，并在报告中说明假设条件
+5. **语言简洁**：问题描述简明扼要，修改建议具体可操作
+6. **报告保存**：评审完成后,必须将报告保存为 `{项目名称}项目级代码评审分析报告.md` 文件,存放在被评审项目的根目录下
+
+# 使用说明
+
+## 触发方式
+
+用户可以通过以下方式触发本 Skill：
+- 说出触发词："项目级代码评审"、"代码评审"、"评审代码"等
+- 指定项目路径：`@项目路径 进行代码评审`
+
+## 输入要求
+
+用户需要提供：
+1. 项目根目录路径（或在 IDE 中已打开的项目）
+2. 可选：指定评审范围（如"只评审 P0 文件"、"重点关注安全问题"）
+
+## 注意事项
+
+- 大型项目（>500 个源文件）建议分批次评审，优先关注 P0 核心文件
+- 评审结果仅供参考，最终修复决策需结合业务实际情况
+- 对于动态语言（Python/JavaScript），部分类型相关问题可能无法完全检测
+
+## 输出说明
+
+- 评审报告将自动生成并保存为: `{项目名称}项目级代码评审分析报告.md`
+- 保存位置: 被评审项目的根目录
+- 文件格式: Markdown (.md)
+- 编码格式: UTF-8

package/bin/zhanlu-plugins/lingji-alpha-assistant/skills/code-review/prompts/step1_project_preprocessing.md

@@ -0,0 +1,106 @@
+# 第一步：项目预处理（轻量解析）
+
+此步骤处理的是已经准备好的本地代码路径，无论代码来源是 GitLab 远程仓库还是本地项目，处理方式完全相同。
+
+在开始详细评审前，先对项目进行轻量级分析，划定评审边界：
+
+## 1.1 文件过滤
+
+自动过滤以下非核心文件和目录，仅保留源码进行分析：
+- **依赖目录**：`node_modules`、`vendor`、`.gradle`、`target`、`build`、`dist`、`out`
+- **版本控制**：`.git`、`.svn`、`.hg`
+- **IDE配置**：`.idea`、`.vscode`、`.eclipse`、`*.iml`
+- **静态资源**：`*.png`、`*.jpg`、`*.gif`、`*.svg`、`*.ico`、`*.css`、`*.scss`、`fonts/`、`images/`
+- **文档文件**：`*.md`、`*.txt`、`LICENSE`、`CHANGELOG`、`docs/`
+- **测试相关**（P2优先级，可简化评审）：`test/`、`tests/`、`*_test.go`、`*Test.java`、`*.spec.ts`、`*.test.js`
+- **其他**：`.env`、`*.log`、`tmp/`、`temp/`
+
+## 1.2 架构基线提取
+
+读取项目核心配置文件，识别技术栈和架构信息：
+- **Java**: `pom.xml`、`build.gradle` → 识别 Spring Boot/Spring Cloud 版本、依赖库
+- **Go**: `go.mod`、`go.sum` → 识别 Go 版本、框架（Gin/Echo等）、依赖库
+- **Python**: `requirements.txt`、`pyproject.toml`、`setup.py` → 识别框架（Django/Flask/FastAPI等）
+- **Node.js**: `package.json` → 识别框架（Express/NestJS/React/Vue等）、依赖库
+- **通用**: 识别项目目录结构，判断架构类型（MVC/微服务/前后端分离/单体应用）
+
+输出项目架构基线信息：
+```
+项目名称: {name}
+主语言: {language}
+技术栈: [framework1, framework2, ...]
+架构类型: {MVC/微服务/前后端分离/单体}
+模块分层: {controller层路径, service层路径, model层路径, utils层路径}
+入口文件: [main.go, app.py, index.js, Application.java, ...]
+```
+注意：上述输出内容须在终端打印提示用户！
+
+## 1.3 依赖关系分析
+
+扫描核心源文件间的导入/引用关系，构建**全局依赖关系图（DAG）**：
+- Java: 分析 `import` 语句
+- Go: 分析 `import` 语句
+- Python: 分析 `import` / `from ... import` 语句
+- JavaScript/TypeScript: 分析 `import` / `require()` 语句
+
+识别高频被依赖的核心模块和可能存在循环依赖的风险点。
+
+**输出格式示例**（终端打印显示，用于后续评审参考）：
+
+```json
+{
+  "file_dependencies": {
+    "src/service/user.go": ["src/model/user.go", "src/utils/redis.go"],
+    "src/controller/user.go": ["src/service/user.go"]
+  },
+  "function_calls": {
+    "src/service/user.go:CreateUser": ["src/model/user.go:Insert", "src/utils/redis.go:SetCache"]
+  }
+}
+```
+
+> 注意：依赖图仅保留结构化链路，不包含完整代码内容，以控制 token 消耗。
+
+## 1.4 文件优先级划分
+
+🚀 **性能优化策略**：
+- 若项目文件总数 > 500：仅标记核心 P0 文件进行深度评审，P1/P2 文件跳过或快速扫描
+- 若项目文件总数 200-500：深度评审 P0 + 中度评审 P1，P2 文件快速扫描
+- 若项目文件总数 < 200：全面评审 P0 + P1 + P2
+
+根据文件重要性和风险等级，将文件划分为三个优先级，生成**文件优先级标记清单**：
+
+**P0 - 最高优先级（深度评审）**
+- 项目入口文件（main.go、Application.java、app.py、index.js 等）
+- 核心业务逻辑文件（service 层、biz 层）
+- 数据访问层文件（model/dao/repository 层）
+- 控制器文件（controller/handler 层）
+- 高频被依赖的核心模块
+
+**P1 - 中优先级（中度评审）**
+- 工具类文件（utils/helpers 层）
+- 中间件/拦截器（middleware/interceptor）
+- 配置文件（config 层，不含敏感信息）
+- DTO/VO 数据传输对象
+
+**P2 - 低优先级（轻度评审或跳过）**
+- 测试文件（test/tests 目录）
+- 示例代码（examples/demo 目录）
+- 第三方 SDK 封装
+- 生成的代码（generated/proto）
+
+**输出格式示例**（终端打印提示用户，用于指导评审顺序）：
+
+```json
+{
+  "P0": ["src/service/user.go", "src/service/order.go", "src/main.go"],
+  "P1": ["src/utils/redis.go", "src/middleware/auth.go", "config.yaml"],
+  "P2": ["tests/user_test.go", "examples/demo.go", "third_party/sdk.go"]
+}
+```
+
+> **Token 控制策略**：优先评审 P0 文件，时间/Token 允许时再评审 P1 文件，P2 文件可选择性跳过或仅做快速扫描。若项目文件数量过多（>500），可只针对核心的 P0 文件进行深度评审。
+
+注意：严格按照上述要求流程执行，禁止跳过或进行其他未设定的操作！执行完每个步骤必须按执行格式在终端输出显示，否则不清楚实际情况！
+
+✅ 执行完成后请输出: "✅ 步骤1完成：项目预处理已完成"