@alanwang-merit/meritdata-platform-skill-package 1.0.10 → 1.0.11

package/skills/requirement-review/SKILL.md

@@ -1,212 +0,0 @@
----
-name: requirement-review
-description: |
-  需求评审skill。根据需求评审检查单对需求文档进行系统性审查，检查逻辑：检查通过填"是"，不通过填"否"并说明原因，不适用填"不适用"。
-  使用场景：用户提到"需求评审"、"需求检查"、"评审需求文档"、"检查需求是否完整"，或提供需求文档路径时触发。
-  输出：填写完整检查结果的评审报告。
-author: maohan
-source: project
-date_added: "2026-07-08"
-risk: low
----
-
-# 需求评审Skill
-
-## 概述
-
-本skill用于对需求文档进行系统性评审，基于预设的检查单逐项验证需求完整性、一致性、清晰性等维度。
-
-## 输入
-
-- **需求文档路径**：待评审的需求文档（Markdown或文本文件）
-
-## 检查逻辑
-
-对每个检查项应用以下规则：
-
-| 条件 | 检查结果 | 说明 |
-|------|----------|------|
-| 检查通过 | 是 | - |
-| 检查不通过 | 否 | 需在说明列填写未通过原因 |
-| 不适用 | 不适用 | 不适用项不进行通过率计算 |
-
-## 评审流程
-
-### 第一步：读取文件
-
-读取以下两个文件：
-1. 需求文档（用户提供的路径）
-2. 检查单模板（`references/需求评审检查单.md`）
-
-### 第二步：逐项检查
-
-按照检查单从以下10个维度进行评审：
-
-#### 1. 需求完整性（23项）
-- 版本更新记录是否完整
-- 业务背景描述
-- 需求概述完整性
-- 功能点描述对应关系
-- 非功能需求定义
-- 兼容性要求
-- 原型及交互说明
-- 技术研究验证
-- 前置条件合理性
-- 业务流程合理性
-- 异常状况处理
-- UI设计规范
-- 原型与需求一致性
-- 交互细节完整性
-- 历史功能影响说明
-- 功能模块关系
-- 集群模式支持
-- 可测试性说明
-- JDK需求说明
-- 数据库字符集需求
-- 数据库配置确认
-
-#### 2. 需求一致性（3项）
-- 多需求相互冲突检查
-- 单需求内功能逻辑冲突检查
-- 术语定义矛盾检查
-
-#### 3. 描述清晰性（4项）
-- 术语与用户一致性
-- 需求无歧义
-- 功能总体描述
-- 操作模式/状态/概念描述
-
-#### 4. 功能需求（3项）
-- 功能必要性
-- 前置条件充分性
-- 输入输出转换说明
-
-#### 5. 接口需求（3项）
-- 接口用途和参数说明
-- 接口设计约束
-- 接口安全性需求
-
-#### 6. 描述详细性（3项）
-- 功能需求详细程度
-- 接口需求详细程度
-- 非功能需求详细程度
-
-#### 7. 可维护性（2项）
-- 可维护性需求分配
-- 可移植性需求分配
-
-#### 8. 性能（1项）
-- 性能需求分配
-
-#### 9. 可靠性（3项）
-- 可靠性需求分配
-- 可用性需求分配
-- 安全性需求分配
-
-#### 10. 非功能性需求（5项）
-- 商业性需求分配
-- 性能需求分配
-- 安全性需求分配
-- 可靠性需求分配
-- 扩展性需求分配
-
-### 第三步：生成评审报告
-
-按照以下Markdown格式生成报告：
-
-```markdown
-# 需求评审报告
-
-## 基本信息
-- **评审日期**：[填写当前日期]
-- **需求文档**：[文档名称]
-- **评审人员**：AI小助手
-
----
-
-## 一、需求完整性
-
-| 序号 | 检查内容 | 检查结果 | 说明 |
-| ---- | -------- | -------- | ---- |
-| 1 | [检查项] | 是/否/不适用 | [说明] |
-| ... | ... | ... | ... |
-
-**[维度通过率]**：X/X 通过 (XX%)
-
----
-
-## 二、需求一致性
-
-| 序号 | 检查内容 | 检查结果 | 说明 |
-| ---- | -------- | -------- | ---- |
-| ... | ... | ... | ... |
-
-**[维度通过率]**：X/X 通过 (XX%)
-
----
-
-[以此类推，生成其他8个维度的报告]
-
----
-
-## 总体评估
-
-| 维度 | 检查项数 | 通过数 | 通过率 |
-|------|----------|--------|--------|
-| 需求完整性 | 23 | X | XX% |
-| 需求一致性 | 3 | X | XX% |
-| 描述清晰性 | 4 | X | XX% |
-| 功能需求 | 3 | X | XX% |
-| 接口需求 | 3 | X | XX% |
-| 描述详细性 | 3 | X | XX% |
-| 可维护性 | 2 | X | XX% |
-| 性能 | 1 | X | XX% |
-| 可靠性 | 3 | X | XX% |
-| 非功能性需求 | 5 | X | XX% |
-| **总计** | **50** | **X** | **XX%** |
-
----
-
-## 问题汇总
-
-### 高优先级问题
-[列出所有"否"的检查项，说明原因]
-
-### 中优先级问题
-[根据具体情况填写]
-
-### 低优先级问题
-[根据具体情况填写]
-
----
-
-## 评审结论
-
-[根据通过率给出评审结论：优秀/良好/合格/不合格，并说明原因]
-
----
-
-评审人：AI小助手
-评审日期：[当前日期]
-```
-
-### 第四步：保存报告
-
-将评审报告保存到 `docs/需求评审报告-YYYYMMDD.md`
-
-## 输出
-
-生成的需求评审报告，包含：
-1. 10个维度的详细检查结果表格
-2. 每个维度的通过率统计
-3. 总体通过率（不适用项不进行通过率计算）
-4. 问题汇总（按优先级分类）
-5. 评审结论
-
-## 注意事项
-
-- 评审时需结合需求文档的实际内容进行判断，不能仅依赖模板
-- 对于不适用于当前项目的检查项（如浏览器兼容性对后端服务），标记为"不适用"并说明
-- 问题说明需具体、明确，指出具体是缺少什么内容或存在什么问题
-- 生成报告后告知用户报告保存路径
-- 统计通过率时，仅计算适用项数作为分母，不适用项不进行通过率计算

package/skills/requirement-review/references//351/234/200/346/261/202/350/257/204/345/256/241/346/243/200/346/237/245/345/215/225.md

@@ -1,99 +0,0 @@
-# 1.需求完整性
-
-| 序号 | 检查内容                                                     | 检查结果     | 说明 |
-| ---- | ------------------------------------------------------------ | ------------ | ---- |
-| 1    | 版本更新记录是否完整（包括： 版本、类型、提交版本、更新内容、更新人、日期）？ | 是/否/不适用 |      |
-| 2    | 是否描述了该需求的业务背景？                                 | 是/否/不适用 |      |
-| 3    | 需求概述是否完整（包括：影响范围、业务角色、业务主流程、业务约束、技术约束、平台约束、接口需求）？ | 是/否/不适用 |      |
-| 4    | 定义的功能是否有对应的功能点描述？                           | 是/否/不适用 |      |
-| 5    | 是否定义了产品的非功能需求（包括：商业、性能、安全、可靠性、扩展性等）？ | 是/否/不适用 |      |
-| 6    | 是否有兼容性要求（包括：浏览器、兼容性、历史功能兼容性）？   | 是/否/不适用 |      |
-| 7    | 是否有原型及交互说明？                                       | 是/否/不适用 |      |
-| 8    | 是否通过了技术研究、验证？                                   | 是/否/不适用 |      |
-| 9    | 需求前置条件、约束条件设定是否具体、合理？                   | 是/否/不适用 |      |
-| 10   | 正常业务处理流程是否合理，且需求上下文是否不存在矛盾的情况？ | 是/否/不适用 |      |
-| 11   | 异常状况是否列举充分，响应的容错处理是否合理？               | 是/否/不适用 |      |
-| 12   | 原型设计是否遵循UI设计规范？                                 | 是/否/不适用 |      |
-| 13   | 原型设计是否与需求文档描述完全一致？                         | 是/否/不适用 |      |
-| 14   | 是否对鼠标样式、事件等有完全、清晰的体现与描述？             | 是/否/不适用 |      |
-| 15   | 是否对页面、操作交互逻辑有完整、清晰的体现与描述？           | 是/否/不适用 |      |
-| 16   | 是否有新功能对历史功能的影响说明？                           | 是/否/不适用 |      |
-| 17   | 是否已经维护功能模块关系图，并做关系检查？                   | 是/否/不适用 |      |
-| 18   | 新功能是否能够正常工作在集群模式下？                         | 是/否/不适用 |      |
-| 19   | 所有需求和非功能需求都要有可测试性说明章节，是否对如何测试进行了详细说明？ | 是/否/不适用 |      |
-| 20   | 是否有对历史功能影响的需求说明？                             | 是/否/不适用 |      |
-| 21   | 是否由对JDK相关具体需求说明？                                | 是/否/不适用 |      |
-| 22   | 是否涉及数据库相关字符集相关需求说明？                       | 是/否/不适用 |      |
-| 23   | 是否已经与工单提出方确认数据库字符集配置?                    | 是/否/不适用 |      |
-
-# 2.需求一致性
-
-| 序号 | 检查内容                                 | 检查结果     | 说明 |
-| ---- | ---------------------------------------- | ------------ | ---- |
-| 1    | 是否多个需求相互冲突？                   | 是/否/不适用 |      |
-| 2    | 单个需求的多个功能上的逻辑是否相互冲突？ | 是/否/不适用 |      |
-| 3    | 对同一对象的术语定义存在矛盾吗？         | 是/否/不适用 |      |
-
-# 3.描述清晰性
-
-| 序号 | 检查内容                                             | 检查结果     | 说明 |
-| ---- | ---------------------------------------------------- | ------------ | ---- |
-| 1    | 需求中使用的术语是否与用户的术语一致？               | 是/否/不适用 |      |
-| 2    | 需求是否清晰、没有歧义？                             | 是/否/不适用 |      |
-| 3    | 是否对每个功能进行了功能总体描述？                   | 是/否/不适用 |      |
-| 4    | 是否对每个功能的操作模式、状态、概念进行了详细描述？ | 是/否/不适用 |      |
-
-# 4.功能需求
-
-| 序号 | 检查内容                                                     | 检查结果     | 说明 |
-| ---- | ------------------------------------------------------------ | ------------ | ---- |
-| 1    | 是否所有的功能都是必要的？这些功能是否可以解决用户的需求？   | 是/否/不适用 |      |
-| 2    | 每个需求的前置条件是否是必要的？这些前置条件是否足够满足功能的需求？ | 是/否/不适用 |      |
-| 3    | 每个功能如何把输入转换为输出是否清楚的进行了说明？           | 是/否/不适用 |      |
-
-# 5.接口需求
-
-| 序号 | 检查内容                                             | 检查结果     | 说明 |
-| ---- | ---------------------------------------------------- | ------------ | ---- |
-| 1    | 是否对接口的主要用途、关键输入参数、接口类型等说明？ | 是/否/不适用 |      |
-| 2    | 是否对接口的设计约束进行了说明？                     | 是/否/不适用 |      |
-| 3    | 是否对接口的安全性需求进行了说明？                   | 是/否/不适用 |      |
-
-# 6.描述详细性
-
-| 序号 | 检查内容                                                 | 检查结果     | 说明 |
-| ---- | -------------------------------------------------------- | ------------ | ---- |
-| 1    | 系统的功能需求是否描述地足够详细，可以开始设计工作？     | 是/否/不适用 |      |
-| 2    | 系统对外提供的接口是否描述的足够详细，可以开始设计工作？ | 是/否/不适用 |      |
-| 3    | 系统的非功能性需求是否描述地足够详细，可以开始设计工作？ | 是/否/不适用 |      |
-
-# 7.可维护性
-
-| 序号 | 检查内容                               | 检查结果     | 说明 |
-| ---- | -------------------------------------- | ------------ | ---- |
-| 1    | 系统可维护性的需求是否都分配给了功能？ | 是/否/不适用 |      |
-| 2    | 系统可移植性的需求是否都分配给了功能？ | 是/否/不适用 |      |
-
-# 8.性能
-
-| 序号 | 检查内容                           | 检查结果     | 说明 |
-| ---- | ---------------------------------- | ------------ | ---- |
-| 1    | 是否所有的性能需求都分配给了功能？ | 是/否/不适用 |      |
-
-# 9.可靠性
-
-| 序号 | 检查内容                               | 检查结果     | 说明 |
-| ---- | -------------------------------------- | ------------ | ---- |
-| 1    | 系统可靠性的需求是否都分配给功能需求？ | 是/否/不适用 |      |
-| 2    | 系统可用性的需求是否都分配给了功能？   | 是/否/不适用 |      |
-| 3    | 系统安全性的需求是否都分配给了功能？   | 是/否/不适用 |      |
-
-# 10.非功能性需求
-
-| 序号 | 检查内容                                                   | 检查结果     | 说明 |
-| ---- | ---------------------------------------------------------- | ------------ | ---- |
-| 1    | 商业性的需求（付费功能，需要特殊授权）是否都分配给了功能？ | 是/否/不适用 |      |
-| 2    | 性能的需求是否都分配给了功能？                             | 是/否/不适用 |      |
-| 3    | 安全性的需求是否都分配给了功能？                           | 是/否/不适用 |      |
-| 4    | 可靠性的需求是否都分配给了功能？                           | 是/否/不适用 |      |
-| 5    | 扩展性的需求是否都分配给了功能？                           | 是/否/不适用 |      |

package/skills/requirement-review-report/SKILL.md

@@ -1,152 +0,0 @@
----
-name: requirement-review-report
-description: 需求评审报告生成 | 触发条件：生成需求评审报告、需求评审总结、输出评审报告 | 基于需求文档生成标准化的评审报告，包含总体判定、逐项评估、问题清单、亮点和修复建议
-metadata:
-  author: maohan
-  source: project
-  date_added: "2026-07-08"
-  risk: low
----
-
-# 需求评审报告生成
-
-本技能用于生成标准化的需求评审报告，从多个维度评估需求文档质量，输出包含总体判定、问题清单和改进建议的评审报告。
-
----
-
-## 使用方法
-
-1. 加载模板文件 `references/需求评审报告模板.md`
-2. 加载需求文档（用户提供路径或内容）
-3. 收集历次评审记录（支持多轮迭代评审）
-4. 按模板结构生成评审报告（包含完整迭代历史）
-
----
-
-## 评审维度
-
-需求文档应从以下6个维度进行评分：
-
-| 维度 | 评估要点 |
-|------|----------|
-| 必含内容覆盖度 | 必须要包含模板中的所有章节内容 |
-| 业务背景量化 | 痛点必须含数据/事实，且不能定性描述 |
-| 功能点完整可测 | 功能脑图 + 用户故事 + 用户操作途径三件齐全 |
-| 业务约束清晰 | 至少包含 3 条具体业务约束 |
-| API契约可评审 | 接口需求含端点表 + 错误码 |
-| 工程化一致性 | 版本记录规范 + 命名规范 + 文档结构规范 |
-
----
-
-## 评审要点
-
-### 必含内容覆盖度
-- 模板 6 大节必须全覆盖（版本更新记录、业务背景、需求概述、功能点描述、非功能性需求、兼容性要求）
-- 各章节是否有实质内容，不是空白占位
-
-### 业务背景量化
-- 痛点必须含数据/事实（如：处理时间、错误率、成本等具体数字）
-- 不能定性描述（如"较慢"、"很差"、"比较高"等模糊描述）
-- 解决方向是否明确，预期收益是否可衡量
-
-### 功能点完整可测
-- 功能脑图是否清晰展示模块关系
-- 用户故事是否完整（角色、操作、目标、验收标准）
-- 用户操作途径是否明确（菜单入口、URL、API调用、消息触发等）
-
-### 业务约束清晰
-- 业务层面的限制条件是否明确
-- 是否至少包含 3 条具体业务约束
-- 技术约束是否完整（开发语言、数据库、中间件等）
-
-### API契约可评审
-- 接口需求是否含端点表（API路径、请求方法、参数说明）
-- 接口需求是否含错误码（业务错误码、系统错误码）
-- 接口参数、输出是否完整
-- 超时时间、异常处理是否说明
-
-### 工程化一致性
-- 版本记录规范（版本号、变更类型、提交人、日期、更新内容完整）
-- 命名规范（术语、模块、接口命名遵循团队约定，前后一致）
-- 文档结构规范（章节层级清晰，编号连续，无错位）
-
-### 需修改项分级
-- 🟠必须：阻塞项，必须修复后才能通过（如：核心功能缺失、数据错误、严重歧义）
-- 🟡建议：改进项，建议修复但不阻塞（如：表述优化、补充示例）
-- 分级使用必须正确，不能将"建议"标为"必须"，也不能将"必须"标为"建议"
-
-### 亮点提炼
-- 至少 2 条具体亮点
-- 亮点应具体可感（如：数据量化精准、约束清晰、接口设计完整等）
-- 避免空泛赞美（如"写得很详细"、"做得很好"）
-
----
-
-## 多轮迭代评审支持
-
-**场景**：需求文档评审后，作者根据反馈修改；评审员再次评审，如此往复。
-
-**核心要求**：
-- 评审报告必须**完整记录每次评审的详细问题**
-- 每次评审的问题必须**追踪修复状态**
-- **不能只记录最后一次评审结果**，必须展示**完整迭代历史**
-- 最终结论必须基于**当前最新状态**
-
-### 迭代评审记录模板
-
-每次评审记录必须包含：
-
-| 字段 | 说明 |
-|------|------|
-| 评审轮次 | V1/V2/V3... |
-| 评审日期 | 评审发生日期 |
-| 评审版本 | 被评审的需求文档版本 |
-| 发现问题数 | 本轮发现的问题总数（必须/建议） |
-| 已解决问题数 | 本轮前已解决的问题数（累计） |
-| 新增问题数 | 本轮新发现的问题数 |
-| 待解决问题数 | 本轮结束时的待解决总数 |
-
-### 修复状态追踪规则
-
-- **待修复**：本轮评审发现，尚未修复
-- **修复中**：作者正在修复
-- **已解决**：作者已修复完成（本轮或后续轮次需验证）
-- **未解决/遗留**：多轮评审后仍未解决，需升级处理
-
-### 历史问题追溯
-
-- **新增**：本轮第一次发现的问题
-- **回归**：之前已解决的问题再次出现
-- **持续未决**：跨多轮评审仍未解决的问题
-
----
-
-## 输出格式
-
-根据模板 `references/需求评审报告模板.md` 生成评审报告，输出后保存到 `docs/需求评审报告-项目名-日期.md`
-
----
-
-## 触发场景
-
-- "生成需求评审报告"
-- "需求评审总结"
-- "输出评审报告"
-- "对需求文档进行评审"
-- "帮我评审需求文档"
-
----
-
-## 输出格式
-
-根据模板 `references/需求评审报告模板.md` 生成评审报告，输出后保存到 `docs/需求评审报告-项目名-日期.md`
-
----
-
-## 触发场景
-
-- "生成需求评审报告"
-- "需求评审总结"
-- "输出评审报告"
-- "对需求文档进行评审"
-- "帮我评审需求文档"

package/skills/requirement-review-report/references//351/234/200/346/261/202/350/257/204/345/256/241/346/212/245/345/221/212/346/250/241/346/235/277.md

@@ -1,187 +0,0 @@
-# 需求评审报告 — [项目名] V1.0
-
-**评审对象**：[需求文档名称]
-**评审日期**：YYYY-MM-DD
-**评审依据**：业务背景资料
-**当前评审轮次**：V[N]
-
----
-
-## 1. 总体判定
-
-**[通过 / 有保留通过 / 不通过]**
-
-**结论依据**：
-- 当前轮次评审结论
-- 整体迭代历史总结
-
----
-
-## 2. 逐项评估（基于当前轮次）
-
-| # | 维度 | 判定 | 证据 |
-|---|------|------|------|
-| 1 | 模板覆盖度 | 优秀/良好/合格/不合格 | xxx |
-| 2 | 业务完整性 | 优秀/良好/合格/不合格 | xxx |
-| 3 | 业务约束 | 优秀/良好/合格/不合格 | xxx |
-| 4 | API契约 | 优秀/良好/合格/不合格 | xxx |
-| 5 | 验收可测试性 | 优秀/良好/合格/不合格 | xxx |
-| 6 | 兼容性 | 优秀/良好/合格/不合格 | xxx |
-| 7 | 工程化一致性 | 优秀/良好/合格/不合格 | xxx |
-
----
-
-## 3. 评审迭代历史
-
-### 3.1 迭代概览
-
-| 轮次 | 评审日期 | 评审版本 | 发现问题数 | 新增问题 | 已解决 | 待解决 | 评审结论 |
-|------|----------|----------|------------|----------|--------|--------|----------|
-| V1 | YYYY-MM-DD | V0.1 | __ | __ | 0 | __ | 通过/有保留通过/不通过 |
-| V2 | YYYY-MM-DD | V0.2 | __ | __ | __ | __ | 通过/有保留通过/不通过 |
-| V3 | YYYY-MM-DD | V0.3 | __ | __ | __ | __ | 通过/有保留通过/不通过 |
-| ... | ... | ... | ... | ... | ... | ... | ... |
-
-### 3.2 V1 评审详情（YYYY-MM-DD）
-
-#### 评审范围
-- 评审对象：[需求文档 V0.1]
-- 评审人员：xxx
-- 评审耗时：xx 分钟
-
-#### 逐项评估
-
-| # | 维度 | 判定 | 证据 |
-|---|------|------|------|
-| 1 | 模板覆盖度 | xxx | xxx |
-| 2 | 业务完整性 | xxx | xxx |
-| ... | ... | ... | ... |
-
-#### 发现问题清单
-
-| # | 级别 | 位置 | 问题 | 建议修改 |
-|---|------|------|------|----------|
-| 1 | 必须 | xxx | xxx | xxx |
-| 2 | 必须 | xxx | xxx | xxx |
-| 3 | 建议 | xxx | xxx | xxx |
-| ... | ... | ... | ... | ... |
-
-#### V1 结论
-- 总体判定：xxx
-- 必须修复项：__ 个
-- 建议修复项：__ 个
-
-### 3.3 V2 评审详情（YYYY-MM-DD）
-
-#### 评审范围
-- 评审对象：[需求文档 V0.2]
-- 评审人员：xxx
-- 评审耗时：xx 分钟
-- 修订说明：作者根据 V1 反馈进行修改，提交 V0.2
-
-#### V1 问题修复追踪
-
-| V1 # | 级别 | 问题 | 修复状态 | 修复说明 |
-|------|------|------|----------|----------|
-| 1 | 必须 | xxx | 已解决/未解决/遗留 | xxx |
-| 2 | 必须 | xxx | 已解决/未解决/遗留 | xxx |
-| 3 | 建议 | xxx | 已解决/未解决/遗留 | xxx |
-| ... | ... | ... | ... | ... |
-
-**V1 修复统计**：
-- 已解决：__ / __ 个
-- 未解决：__ / __ 个
-- 回归问题：__ 个
-
-#### V2 新发现问题
-
-| # | 级别 | 位置 | 问题 | 建议修改 | 修复状态 |
-|---|------|------|------|----------|----------|
-| 1 | 必须 | xxx | xxx | xxx | 待修复 |
-| 2 | 建议 | xxx | xxx | xxx | 待修复 |
-| ... | ... | ... | ... | ... | ... |
-
-#### 逐项评估（V2）
-
-| # | 维度 | V1 判定 | V2 判定 | 变化说明 |
-|---|------|---------|---------|----------|
-| 1 | 模板覆盖度 | xxx | xxx | 改善/不变/退步 |
-| 2 | 业务完整性 | xxx | xxx | 改善/不变/退步 |
-| ... | ... | ... | ... | ... |
-
-#### V2 结论
-- 总体判定：xxx
-- 必须修复项：__ 个
-- 建议修复项：__ 个
-
-### 3.4 V3 评审详情（YYYY-MM-DD）
-
-> 按相同格式记录
-
-### 3.5 跨轮次问题汇总
-
-#### 持续未决问题（跨多轮未解决）
-
-| 原始轮次 | # | 级别 | 位置 | 问题 | 已迭代轮次 | 处理建议 |
-|----------|---|------|------|------|-----------|----------|
-| V1 | 1 | 必须 | xxx | xxx | V1, V2, V3 | 升级处理/放弃修复 |
-| ... | ... | ... | ... | ... | ... | ... |
-
-#### 回归问题（已解决后再次出现）
-
-| 原始 # | 问题 | 解决轮次 | 回归轮次 | 说明 |
-|--------|------|----------|----------|------|
-| V1-3 | xxx | V2 | V3 | 作者重新修改时引入了之前的问题 |
-| ... | ... | ... | ... | ... |
-
----
-
-## 4. 当前待修复项（基于当前轮次）
-
-| 序号 | 级别 | 位置 | 问题 | 建议修改 | 修复状态 | 原始轮次 |
-|------|------|------|------|----------|----------|----------|
-| 1 | 必须 | xxx | xxx | xxx | 待修复 | V3 |
-| 2 | 必须 | xxx | xxx | xxx | 待修复 | V1（持续未决） |
-| 3 | 建议 | xxx | xxx | xxx | 待修复 | V3 |
-| ... | ... | ... | ... | ... | ... | ... |
-
-**级别说明**：
-- **必须**：阻塞项，必须修复后才能通过
-- **建议**：改进项，建议修复但不阻塞
-
----
-
-## 5. 当前建议项（非阻塞）
-
-| 序号 | 位置 | 建议 | 原始轮次 |
-|------|------|------|----------|
-| 1 | xxx | xxx | V3 |
-| 2 | xxx | xxx | V2（持续未决） |
-| ... | ... | ... | ... |
-
----
-
-## 6. 亮点
-
-需求文档做得好的地方（基于当前轮次）：
-- xxx
-- xxx
-
----
-
-## 7. 修复后定稿
-
-**修复后版本号**：Vx.x
-**最终结论**：[通过 / 不通过]
-**是否可进入下一阶段**：[是 / 否]
-
-**迭代历史总结**：
-- 共经历 N 轮评审
-- 累计发现问题 __ 个
-- 已解决问题 __ 个
-- 遗留问题 __ 个
-
----
-
-**评审人**：xxx
-**评审日期**：YYYY-MM-DD

package/skills/research/SKILL.md

@@ -1,12 +0,0 @@
----
-name: research
-description: Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.
----
-
-Spin up a **background agent** to do the research, so you keep working while it reads.
-
-Its job:
-
-1. Investigate the question against **primary sources** — official docs, source code, specs, first-party APIs — not a secondary write-up of them. Follow every claim back to the source that owns it.
-2. Write the findings to a single Markdown file, citing each claim's source.
-3. Save it where the repo already keeps such notes; match the existing convention, and if there is none, put it somewhere sensible and say where.

package/skills/research/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "Research"
-  short_description: "Research from high-trust sources"

package/skills/resolving-merge-conflicts/SKILL.md

@@ -1,14 +0,0 @@
----
-name: resolving-merge-conflicts
-description: "Use when you need to resolve an in-progress git merge/rebase conflict."
----
-
-1. **See the current state** of the merge/rebase. Check git history, and the conflicting files.
-
-2. **Find the primary sources** for each conflict. Understand deeply why each change was made, and what the original intent was. Read the commit messages, check the PRs, check original issues/tickets.
-
-3. **Resolve each hunk.** Preserve both intents where possible. Where incompatible, pick the one matching the merge's stated goal and note the trade-off. Do **not** invent new behaviour. Always resolve; never `--abort`.
-
-4. Discover the project's **automated checks** and run them — typically typecheck, then tests, then format. Fix anything the merge broke.
-
-5. **Finish the merge/rebase.** Stage everything and commit. If rebasing, continue the rebase process until all commits are rebased.

package/skills/resolving-merge-conflicts/agents/openai.yaml

@@ -1,3 +0,0 @@
-interface:
-  display_name: "Resolving Merge Conflicts"
-  short_description: "Resolve merge and rebase conflicts"