@zhanlucode/zl-darwin-arm64 1.5.87028

package/bin/zhanlu-plugins/lingji-beta-assistant/skills/beta-requirement-decomposer/references/epic-to-story-to-task-template.md

@@ -0,0 +1,221 @@
+# Epic → Story → Task 三层拆解输出模板
+
+## 文档头部
+
+```markdown
+# [项目名称] - 需求拆解文档
+
+## 项目信息
+- 空间名称: [填写空间名称]
+- 项目编码: [填写项目目编码]
+- 项目名称: [填写项目名称]
+- 产品名称: [填写产品名称]
+```
+
+---
+
+## 一级：Epic 区块
+
+```markdown
+---
+
+## Epic-{Epic序号}: {key}-{Epic标题}
+```
+
+---
+
+## 二级：Story 区块
+
+```markdown
+### Story {Epic序号}.{Story序号}: {Story名称}
+
+| 字段 | 值 |
+| ----------- | ---------------- |
+| 需求Key | [自动生成，格式：{父EpicKey}-S{序号}] |
+| 标题 | [Story标题] |
+| 类型 | 用户故事 |
+| 负责人 | [继承自父需求] |
+| 提出人 | [继承自父需求] |
+| 优先级 | [继承自父需求] |
+| 业务背景 | [继承自父需求，若无则填写"无"] |
+| 需求描述 | [拆解后的需求描述] |
+| 验收标准 | [拆解后的验收标准] |
+| 计划开始时间 | [继承自父需求] |
+| 计划结束时间 | [继承自父需求] |
+| 期望完成时间 | [继承自父需求，若无则填写"无"] |
+| 关联产品/业务平台类型 | [继承自父需求] |
+| 选择对应产品/业务平台 | [继承自父需求] |
+| 关联项目 | [继承自父需求] |
+| 关联版本 | [继承自父需求，若无则填写"无"] |
+| 迭代 | [继承自父需求，若无则填写"无"] |
+| 父需求 | [父EpicKey] |
+```
+
+---
+
+## 三级：Task 区块
+
+```markdown
+#### Task {Epic序号}.{Story序号}.{Task序号}: {Task名称}
+
+| 字段 | 值 |
+| ----------- | ---------------- |
+| 需求Key | [自动生成，格式：{父StoryKey}-T{序号}] |
+| 标题 | [Task标题] |
+| 类型 | 任务 |
+| 任务类型 | [需求分析/设计/开发/测试/文档 四选一] |
+| 负责人 | [继承自父需求] |
+| 提出人 | [继承自父需求] |
+| 优先级 | [继承自父需求] |
+| 任务描述 | [拆解后的任务描述] |
+| 计划开始时间 | [继承自父需求] |
+| 计划结束时间 | [继承自父需求] |
+| 计划工时（小时） | [按照情况合理填写] |
+| 关联产品/业务平台类型 | [继承自父需求] |
+| 选择对应产品/业务平台 | [继承自父需求] |
+| 关联项目 | [继承自父需求] |
+| 关联版本 | [继承自父需求，若无则填写"无"] |
+| 父需求 | [父StoryKey] |
+```
+
+---
+
+## 分隔符
+
+- 每个 Epic 之间用 `---` 分隔
+- 每个 Story 之间用 `---` 分隔
+
+---
+
+## 完整示例
+
+```markdown
+# 研发大模型关键技术研发（2025） - 需求拆解文档
+
+## 项目信息
+- 空间名称: 研发大模型关键技术研发
+- 项目编码: R2511D2DC03
+- 项目名称: 研发大模型关键技术研发（2025）
+- 产品名称: 研发大模型
+
+---
+
+## Epic-1: CMSSR2511D2DC03-873 需求代码一致性检查
+
+### Story 1.1: Git提交信息需求代码一致性校验
+
+| 字段 | 值 |
+| ----------- | ---------------- |
+| 需求Key | CMSSR2511D2DC03-873-S1 |
+| 标题 | Git提交信息需求代码一致性校验 |
+| 类型 | 用户故事 |
+| 负责人 | 张三 |
+| 提出人 | 李四 |
+| 优先级 | P0 |
+| 业务背景 | 无 |
+| 需求描述 | 作为 一名开发人员，我想要 在推送（Push）代码到仓库时，系统能自动分析我的 Git 提交信息中的需求描述（如 Jira ID 或任务标题）与实际提交的代码变更是否匹配，以便于 我能及时发现并修正描述错误，确保代码库中每个提交都准确对应业务需求，避免后续维护混乱和代码审查（Code Review）的低效。 |
+| 验收标准 | 1、用户在push代码时，系统自动解析git提交信息中的需求标识；2、若检测到需求与提交代码不一致，系统向用户发出提醒提示；3、提醒信息清晰说明不一致的具体内容。 |
+| 计划开始时间 | 2026-04-27 16:00:00 |
+| 计划结束时间 | 2026-05-21 16:00:00 |
+| 期望完成时间 | 无 |
+| 关联产品/业务平台类型 | 产品 |
+| 选择对应产品/业务平台 | 研发大模型 |
+| 关联项目 | 研发大模型关键技术研发（2025）(R2511D2DC03) |
+| 关联版本 | 无 |
+| 迭代 | 无 |
+| 父需求 | CMSSR2511D2DC03-873 |
+
+#### Task 1.1.1: 开发并集成本地 pre-push Git Hook 脚本以实现提交信息校验逻辑
+
+| 字段 | 值 |
+| ----------- | ---------------- |
+| 需求Key | CMSSR2511D2DC03-873-S1-T1 |
+| 标题 | 开发并集成本地 pre-push Git Hook 脚本以实现提交信息校验逻辑 |
+| 类型 | 任务 |
+| 任务类型 | 开发 |
+| 负责人 | 张三 |
+| 提出人 | 李四 |
+| 优先级 | P0 |
+| 任务描述 | 本任务旨在开发并部署一套本地 Git pre-push 钩子机制，通过编写名为 scripts/git-check-commit.sh 的脚本，在代码推送前自动读取环境变量与远程分支信息，利用 git diff 获取文件变更列表并结合 git log 遍历提交记录，提取 Jira ID 或任务标题后建立"提交 ID - 修改文件"的映射关系，智能推断代码变更是否精准对应业务需求。一旦检测到不匹配，脚本将立即向标准错误流输出包含缺失 ID、文件路径及错误摘要的清晰提示，并强制返回非零退出码以拦截 Push 操作。任务还包括创建 .git/hooks/pre-push 模板及提供 make install-hooks 等便捷命令指导新成员初始化环境。 |
+| 计划开始时间 | 2026-04-27 16:00:00 |
+| 计划结束时间 | 2026-05-21 16:00:00 |
+| 计划工时（小时） | 5 |
+| 关联产品/业务平台类型 | 产品 |
+| 选择对应产品/业务平台 | 研发大模型 |
+| 关联项目 | 研发大模型关键技术研发（2025）(R2511D2DC03) |
+| 关联版本 | 无 |
+| 父需求 | CMSSR2511D2DC03-873-S1 |
+
+---
+
+### Story 1.2: 后台管理页面展示不一致告警记录
+
+| 字段 | 值 |
+| ----------- | ---------------- |
+| 需求Key | CMSSR2511D2DC03-873-S2 |
+| 标题 | 后台管理页面展示不一致告警记录 |
+| 类型 | 用户故事 |
+| 负责人 | 张三 |
+| 提出人 | 李四 |
+| 优先级 | P1 |
+| 业务背景 | 无 |
+| 需求描述 | 作为 一名运维人员，我想要 在后台管理页面查看 Git 提交时检测到的一致性告警记录，以便于 我能快速定位并处理不匹配的提交，降低代码审查成本。 |
+| 验收标准 | 1、后台页面展示告警记录列表，包含提交ID、需求标识、文件变更摘要、检测时间等字段；2、支持按时间、需求标识、状态进行筛选；3、点击单条告警可查看详细信息。 |
+| 计划开始时间 | 2026-04-27 16:00:00 |
+| 计划结束时间 | 2026-05-21 16:00:00 |
+| 期望完成时间 | 无 |
+| 关联产品/业务平台类型 | 产品 |
+| 选择对应产品/业务平台 | 研发大模型 |
+| 关联项目 | 研发大模型关键技术研发（2025）(R2511D2DC03) |
+| 关联版本 | 无 |
+| 迭代 | 无 |
+| 父需求 | CMSSR2511D2DC03-873 |
+
+#### Task 1.2.1: 设计告警记录数据库表结构与API接口
+
+| 字段 | 值 |
+| ----------- | ---------------- |
+| 需求Key | CMSSR2511D2DC03-873-S2-T1 |
+| 标题 | 设计告警记录数据库表结构与API接口 |
+| 类型 | 任务 |
+| 任务类型 | 设计 |
+| 负责人 | 张三 |
+| 提出人 | 李四 |
+| 优先级 | P1 |
+| 任务描述 | 设计告警记录的数据存储方案，包括数据库表结构（字段：告警ID、提交ID、需求标识、变更文件列表、检测时间、状态等）以及后端REST API接口定义（查询列表、查看详情、标记已处理）。输出设计文档并评审。 |
+| 计划开始时间 | 2026-04-27 16:00:00 |
+| 计划结束时间 | 2026-05-21 16:00:00 |
+| 计划工时（小时） | 4 |
+| 关联产品/业务平台类型 | 产品 |
+| 选择对应产品/业务平台 | 研发大模型 |
+| 关联项目 | 研发大模型关键技术研发（2025）(R2511D2DC03) |
+| 关联版本 | 无 |
+| 父需求 | CMSSR2511D2DC03-873-S2 |
+
+#### Task 1.2.2: 开发告警记录后台管理页面前端组件
+
+| 字段 | 值 |
+| ----------- | ---------------- |
+| 需求Key | CMSSR2511D2DC03-873-S2-T2 |
+| 标题 | 开发告警记录后台管理页面前端组件 |
+| 类型 | 任务 |
+| 任务类型 | 开发 |
+| 负责人 | 张三 |
+| 提出人 | 李四 |
+| 优先级 | P1 |
+| 任务描述 | 基于已设计的API，开发后台管理页面的前端组件，包括告警记录列表页（支持筛选、分页）和详情页。使用项目现有前端框架，确保与既有风格一致。 |
+| 计划开始时间 | 2026-04-27 16:00:00 |
+| 计划结束时间 | 2026-05-21 16:00:00 |
+| 计划工时（小时） | 8 |
+| 关联产品/业务平台类型 | 产品 |
+| 选择对应产品/业务平台 | 研发大模型 |
+| 关联项目 | 研发大模型关键技术研发（2025）(R2511D2DC03) |
+| 关联版本 | 无 |
+| 父需求 | CMSSR2511D2DC03-873-S2 |
+
+---
+
+## Epic-2: CMSSR2511D2DC03-874 代码审查自动化辅助
+...
+
+```

package/bin/zhanlu-plugins/lingji-beta-assistant/skills/beta-requirement-decomposer/references/story-to-task-methodology.md

@@ -0,0 +1,139 @@
+# Story → Task 拆解方法论
+
+## 目标
+
+将每个 Story 拆解为具体的、可执行的开发任务（Task）。每个 Task 应该是 Agent 可以独立完成的最小开发单元。
+
+
+## 核心原则
+
+### 1. 一个 Task = 一个独立开发动作，不是"阶段"
+
+**反面示例（按阶段拆——过度拆分）：**
+
+- ~~Task 1: 设计 API 对接方案（4h）~~
+- ~~Task 2: 开发服务模块（8h）~~
+- ~~Task 3: 开发展示组件（6h）~~
+- 这里"设计"不是一个独立的开发产出，设计工作应融入开发中
+
+**正面示例（按开发动作拆）：**
+
+- Task 1: 实现需求查询服务（包含 API 设计+开发）
+- Task 2: 实现前端展示组件
+
+### 2. Task 粒度：一个 Task 的描述应包含足够的技术细节
+
+每个 Task 描述应该让一个开发者看到后就知道要做什么、怎么做，不需要再补充上下文。
+
+**好：**
+
+- "实现 `GET /api/requirements` 查询接口，支持 `assignee`、`status`、`project_id` 三个可选查询参数，支持 `page` 和 `page_size` 分页，返回结构化需求列表"
+
+**不好：**
+
+- "开发需求查询功能"（缺少技术细节）
+
+### 3. 不要为"设计"单独设 Task
+
+设计工作是实现的一部分，不是独立的产出物。把设计融入实现任务中：
+
+**反面示例：**
+
+- ~~Task 1: 设计 Prompt 模板（4h）~~
+- ~~Task 2: 开发 AI 评审服务（8h）~~
+
+**正面示例：**
+
+- Task 1: 开发 AI 评审服务——设计评审 Prompt 模板并实现调用逻辑
+
+### 4. Task 数量限制
+
+一个 Story 拆 **2-4 个 Task**。超过 4 个时考虑合并。
+
+## 拆解步骤
+
+### 步骤 1：理解 Story 的技术实现路径
+
+阅读 Story 的验收标准，判断需要哪些开发工作。按以下维度识别：
+
+| 维度        | 说明                      |
+| ----------- | ------------------------- |
+| 后端/服务层 | API、业务逻辑、数据处理   |
+| 前端/UI 层  | 组件、页面、交互          |
+| 集成层      | 第三方 API 对接、消息队列 |
+| 配置/部署   | 环境配置、部署脚本        |
+
+### 步骤 2：按开发动作拆分 Task
+
+每个 Task 应该是一个完整的开发动作，不是开发阶段。拆分方法：
+
+1. **识别独立开发模块**：哪些代码文件可以独立创建/修改
+2. **合并相关操作**：同一模块下的设计+实现合并为一个 Task
+3. **确保每个 Task 有明确产出**：完成后有一个可运行的代码产出
+
+### 步骤 3：编写 Task
+
+对每个 Task，使用以下格式：
+
+```
+**任务描述：**
+
+{具体开发任务，包含输入、处理、输出}
+```
+
+任务描述必须包含：
+
+- **做什么**：具体的功能名称和行为
+- **怎么做**：关键技术点（接口路径、参数、返回值、组件名等）
+- **边界处理**：异常情况和边界条件
+
+**好示例：**
+
+```
+开发需求查询与分页展示服务：实现 `GET /api/requirements` 接口，支持 `assignee`（我提交的/分配给我的）、`status`、`project_id` 等多条件组合查询。返回格式为 `{items: Requirement[], total: number, page: number, pageSize: number}`。前端组件使用分页表格，每页 5 条，超过 5 条时显示分页导航。空间筛选通过弹窗询问用户，默认展示全部空间。
+```
+
+**不好示例：**
+
+```
+~~开发需求查询功能~~（缺少具体细节）
+~~设计并实现后端服务~~（"设计"不是独立产出）
+~~优化用户体验~~（不是开发动作）
+```
+
+### 步骤 4：验证
+
+完成拆分后，逐一检查：
+
+- [ ] 每个 Task 是否有明确的技术细节？
+- [ ] 每个 Task 是否可以被单个开发者独立完成？
+- [ ] Task 数量是否在 2-4 个？（超过 4 个考虑合并）
+- [ ] 所有验收标准是否都有对应的 Task 覆盖？
+- [ ] 是否没有单独的"设计"Task？
+
+## Task 粒度指导
+
+| 场景                         | 处理方式                                |
+| ---------------------------- | --------------------------------------- |
+| Task 包含多个不相关的功能    | 拆分为多个 Task                         |
+| Task 只涉及一行代码的改动    | 考虑合并到相邻 Task                     |
+| 单个 Story 的 Task 超过 4 个 | 合并相关 Task                           |
+| 单个 Story 的 Task 少于 2 个 | 正常，简单 Story 可能只需要 1-2 个 Task |
+
+## 常见陷阱
+
+| 陷阱                            | 应对方式                                     |
+| ------------------------------- | -------------------------------------------- |
+| 把"设计"单独拆成 Task           | 将设计工作融入实现 Task                      |
+| Task 描述过于笼统，缺少技术细节 | 补充接口路径、参数、返回值、组件名等信息     |
+| 一个 Task 描述像 Epic           | 拆分为更小的 Task                            |
+| Task 顺序不合理                 | 按依赖关系排序：数据层 → 服务层 → 前端层   |
+| 遗漏异常处理                    | 在每个涉及外部调用的 Task 中说明错误处理逻辑 |
+
+## 拆解数量指导
+
+一个 Story 建议包含 **2-4 个 Task**。
+
+- 少于 2 个：正常，简单功能可能只需要 1 个 Task
+- 2-4 个：理想范围
+- 超过 4 个：Story 可能过大或拆得过细，考虑合并

package/bin/zhanlu-plugins/lingji-beta-assistant/skills/beta-requirement-decomposer/references/story-to-task-template.md

@@ -0,0 +1,89 @@
+# Task 输出模板
+
+## 文档头部
+
+```markdown
+# [项目名称] - 需求拆解文档
+
+## 项目信息
+- 空间名称: [填写空间名称]
+- 项目编码: [填写项目编码]
+- 项目名称: [填写项目名称]
+- 产品名称: [填写产品名称]
+```
+
+## 每个 Story 区块
+
+```markdown
+---
+
+## Story-{Story序号}: {key}-{Story标题}
+```
+
+## 每个 Task 区块
+
+```markdown
+### Task {Story序号}.{Task序号}: {Task名称}
+
+| 字段 | 值 |
+| ----------- | ---------------- |
+| 需求Key | [自动生成，格式：{父需求Key}-T{序号}] |
+| 标题 | [Task标题] |
+| 类型 | 任务 |
+| 任务类型 | [需求分析/设计/开发/测试/文档 四选一] |
+| 负责人 | [继承自父需求] |
+| 提出人 | [继承自父需求] |
+| 优先级 | [继承自父需求] |
+| 任务描述 | [拆解后的任务描述] |
+| 计划开始时间 | [继承自父需求] |
+| 计划结束时间 | [继承自父需求] |
+| 计划工时（小时） | [按照情况合理填写] |
+| 关联产品/业务平台类型 | [继承自父需求] |
+| 选择对应产品/业务平台 | [继承自父需求] |
+| 关联项目 | [继承自父需求] |
+| 关联版本 | [继承自父需求，若无则填写"无"] |
+| 父需求 | [父需求Key] |
+```
+
+## 分隔符
+
+每个 Story 之间用 `---` 分隔。
+
+## 完整示例
+
+```markdown
+# 研发大模型关键技术研发（2025） - 需求拆解文档
+
+## 项目信息
+- 空间名称: 研发大模型关键技术研发
+- 项目编码: R2511D2DC03
+- 项目名称: 研发大模型关键技术研发（2025）
+- 产品名称: 研发大模型
+
+---
+
+## Story-1: Git提交信息需求代码一致性校验
+
+### Task 1.1: CMSSR2511D2DC03-876-开发并集成本地 pre-push Git Hook 脚本以实现提交信息校验逻辑
+
+| 字段 | 值 |
+| ----------- | ---------------- |
+| 需求Key | CMSSR2511D2DC03-876-T1 |
+| 标题 | 开发并集成本地 pre-push Git Hook 脚本以实现提交信息校验逻辑 |
+| 类型 | 任务 |
+| 任务类型 | 开发 |
+| 负责人 | 张三 |
+| 提出人 | 李四 |
+| 优先级 | P0 |
+| 任务描述 | 本任务旨在开发并部署一套本地 Git pre-push 钩子机制，通过编写名为 scripts/git-check-commit.sh 的脚本（1），在代码推送前自动读取环境变量与远程分支信息，利用 git diff 获取文件变更列表并结合 git log 遍历提交记录，提取 Jira ID 或任务标题后建立“提交 ID - 修改文件”的映射关系，智能推断代码变更是否精准对应业务需求。一旦检测到不匹配（2），脚本将立即向标准错误流输出包含缺失 ID、文件路径及错误摘要的清晰提示，并强制返回非零退出码以拦截 Push 操作，防止不规范提交进入代码库。同时，团队需创建 .git/hooks/pre-push 模板并在文档中提供 make install-hooks 等便捷命令（3）指导新成员快速初始化环境，确保脚本具备执行权限并实现流程落地。最后，任务将通过单元测试模拟多种场景以及集成测试验证真实分支下的 Push 行为（4），确保带正确 ID 的提交能顺利执行，而缺失或错误 ID 的提交被有效拦截并提示，最终交付可运行的脚本、Hook 模板及测试报告。 |
+| 计划开始时间 | 2026-04-27 16:00:00 |
+| 计划结束时间 | 2026-05-21 16:00:00 |
+| 计划工时（小时） | 5 |
+| 关联产品/业务平台类型 | 产品 |
+| 选择对应产品/业务平台 | 研发大模型 |
+| 关联项目 | 研发大模型关键技术研发（2025）(R2511D2DC03) |
+| 关联版本 | 无 |
+| 父需求 | CMSSR2511D2DC03-876 |
+
+---
+```