aigroup-workflow 1.3.0 → 2.0.0

package/skills/max/workflow/brainstorming/SKILL.md

@@ -1,111 +0,0 @@
----
-name: brainstorming
-description: 需求收集 — 在任何创造性工作之前必须使用。通过协作对话收集和分析功能需求，明确用户意图和成功标准。
----
-
-# 需求收集与分析
-
-通过自然的协作对话，收集和分析功能需求，把模糊的想法转化为清晰的需求文档。
-
-```
-此阶段只负责"要做什么"，不负责"怎么做"。
-技术方案设计在 solution-design 阶段完成。
-```
-
-## 状态机
-
-```bash
-# 进入此阶段
-bash scripts/harness/workflow-state.sh init <任务名>
-# 完成后推进到需求验证
-bash scripts/harness/workflow-state.sh advance
-```
-
-## 检查清单
-
-你**必须**按顺序完成以下每一项：
-
-1. **探索项目上下文** — 检查文件、文档、近期提交，了解现状
-2. **逐个提问澄清** — 一次一个问题，理解目的、约束、成功标准
-3. **识别用户场景** — 谁会用？在什么场景下？期望什么结果？
-4. **定义功能边界** — 做什么、不做什么、优先级
-5. **撰写需求文档** — 保存到 `.dev-agents/shared/designs/YYYY-MM-DD-<功能名>-requirements.md`
-6. **用户确认** — 请用户审阅需求文档，确认后推进到 validation
-
-## 需求文档结构
-
-```markdown
-# [功能名] 需求文档
-
-## 背景与目的
-为什么要做这个功能？解决什么问题？
-
-## 用户场景
-- 场景 1：作为 [角色]，我希望 [行为]，以便 [价值]
-- 场景 2：...
-
-## 功能需求
-- [ ] FR-1：[具体功能描述]
-- [ ] FR-2：...
-
-## 约束条件
-- 性能要求：...
-- 兼容性要求：...
-- 安全要求：...
-
-## 非功能需求
-- ...
-
-## 范围排除（不做什么）
-- ...
-
-## 成功标准
-- ...
-```
-
-## 铁律
-
-```
-1. 此阶段不做技术方案设计，不选择技术栈，不讨论架构
-2. 每条消息只问一个问题，优先使用选择题
-3. 必须产出需求文档并获得用户确认才能推进
-4. brainstorming 的唯一出口是 validation（需求验证）
-```
-
-## 流程详解
-
-### 理解想法
-
-- 先检查项目当前状态（文件、文档、近期提交）
-- 如果请求涉及多个独立子系统，立即指出需要先拆解
-- 逐个提问来细化想法，聚焦理解目的、约束、成功标准
-- **每条消息只问一个问题**
-
-### 定义需求
-
-- 将用户的描述转化为结构化的功能需求列表
-- 每条需求必须可验证（有明确的通过/不通过标准）
-- 识别隐含需求和边界条件
-- 明确范围排除（什么不做）
-
-### 在现有代码库中工作
-
-- 在收集需求前先探索现有结构
-- 理解现有功能和约束
-- 需求应考虑与现有系统的兼容性
-
-## Red Flags — 停下来
-
-| 信号 | 行动 |
-|------|------|
-| 开始讨论技术方案 | 停下来，技术方案在 design 阶段 |
-| 用户说"直接做吧" | 先完成最小需求文档 |
-| 需求描述了多个独立系统 | 先帮用户拆解为子项目 |
-| 需求中有"待定""之后再说" | 现在就确定，或标记为明确的开放问题 |
-| 想跳过用户确认 | 不允许，用户确认是必须的门禁 |
-
-## 与团队的协作
-
-- 如果涉及 UI/UX，可派遣艾拉参与需求收集
-- 需求文档是后续所有阶段的核心输入
-- 需求确认后进入 validation（需求验证）

package/skills/max/workflow/documentation/SKILL.md

@@ -1,82 +0,0 @@
----
-name: documentation
-description: 文档更新 — 在测试验证通过后使用。更新相关文档，确保文档与代码一致，包括 API 文档、README、架构文档等。
----
-
-# 文档更新
-
-测试验证通过后，更新所有受影响的文档，确保文档与代码保持一致。
-
-```
-代码变更后文档不同步 = 技术债。
-此阶段是消除文档债的专门时间窗口。
-```
-
-## 状态机
-
-```bash
-# 确认当前阶段
-bash scripts/harness/workflow-state.sh gate documentation
-# 完成后推进到分支收尾
-bash scripts/harness/workflow-state.sh advance
-```
-
-## 检查清单
-
-你**必须**按顺序完成以下每一项：
-
-1. **列出变更文件** — 基于 git diff 和实现计划，识别本次变更涉及的所有文件
-2. **识别受影响文档** — 哪些文档需要更新？
-3. **逐项更新** — 按优先级更新文档
-4. **一致性检查** — 确认文档与代码一致
-5. **运行文档传感器** — `bash scripts/harness/lint-docs.sh`
-
-## 文档更新优先级
-
-### 必须更新
-
-| 文档类型 | 触发条件 | 更新内容 |
-|---------|---------|---------|
-| **API 文档** | 接口变更 | 参数、返回值、示例 |
-| **README** | 使用方式变更 | 安装步骤、使用示例 |
-| **ARCHITECTURE.md** | 架构变更 | 组件图、数据流 |
-| **模块 CLAUDE.md** | 模块行为变更 | 模块说明、约束 |
-
-### 按需更新
-
-| 文档类型 | 触发条件 | 更新内容 |
-|---------|---------|---------|
-| **代码注释** | 复杂逻辑变更 | 关键算法、设计决策 |
-| **配置文档** | 配置项变更 | 配置说明、默认值 |
-| **部署文档** | 部署流程变更 | 部署步骤、环境要求 |
-
-## 更新原则
-
-- **只更新受影响的文档** — 不做无关的文档改进
-- **保持文档与代码同步** — 描述应反映实际行为
-- **删除过时内容** — 不保留已删除功能的描述
-- **遵循现有文档风格** — 与现有文档保持一致的格式和语气
-
-## 执行方式
-
-- **简单更新**：Max 直接修改
-- **技术文档**：可派遣 Jarvis 更新代码相关文档
-- **知识库文档**：Max 更新 docs/ 下的文档
-
-## 铁律
-
-```
-1. 接口变更必须更新 API 文档
-2. 架构变更必须更新 ARCHITECTURE.md
-3. 更新完成后必须运行 lint-docs.sh 验证
-4. documentation 的唯一出口是 finishing（分支收尾）
-```
-
-## Red Flags — 停下来
-
-| 信号 | 行动 |
-|------|------|
-| 测试验证未通过就更新文档 | 停下来，先回到 testing 阶段 |
-| 文档描述与代码不一致 | 以代码为准，修正文档 |
-| lint-docs.sh 报错 | 修复后重新验证 |
-| 想跳过文档更新 | 检查是否真的没有受影响文档 |

package/skills/max/workflow/requirement-validation/SKILL.md

@@ -1,107 +0,0 @@
----
-name: requirement-validation
-description: 需求验证 — 在需求收集完成后使用。验证需求的完整性、可行性和无歧义性，确保需求可作为后续设计和开发的可靠基准。
----
-
-# 需求验证
-
-对 brainstorming 阶段收集的需求进行系统性验证，确保需求完整、可行、无歧义。
-
-```
-此阶段是需求收集到方案设计之间的质量关口。
-未通过验证的需求不得进入 design 阶段。
-```
-
-## 状态机
-
-```bash
-# 确认当前阶段
-bash scripts/harness/workflow-state.sh gate validation
-# 完成后推进到方案设计
-bash scripts/harness/workflow-state.sh advance
-```
-
-## 检查清单
-
-你**必须**按顺序完成以下每一项：
-
-1. **读取需求文档** — 从 `.dev-agents/shared/designs/` 加载需求文档
-2. **完整性检查** — 每条功能需求是否可独立理解？是否有遗漏的场景？
-3. **可行性检查** — 在当前技术栈和时间约束下，每条需求是否可实现？
-4. **歧义检查** — 需求是否可以被两种方式理解？如果有，选定一种并明确
-5. **一致性检查** — 需求之间有没有矛盾？
-6. **可验证性检查** — 每条需求是否有明确的通过/不通过标准？
-7. **产出验证结论** — 在需求文档末尾追加验证结论
-8. **用户确认** — 如有修改请用户确认
-
-## 验证维度
-
-### 完整性
-
-- 每个用户场景是否有对应的功能需求？
-- 异常情况是否被考虑？（网络错误、空数据、权限不足）
-- 非功能需求是否完整？（性能、安全、兼容性）
-- 范围排除是否明确？
-
-### 可行性
-
-- 技术上是否可实现？（不依赖不存在的 API、不违反物理限制）
-- 时间上是否合理？（单次开发周期能否完成）
-- 是否与现有系统兼容？（不会破坏现有功能）
-
-### 无歧义性
-
-- 每条需求是否只有一种理解方式？
-- 数值边界是否明确？（"快速" → "200ms 内响应"）
-- 行为边界是否明确？（"支持多种格式" → "支持 JSON 和 XML"）
-
-### 一致性
-
-- 不同需求之间是否有矛盾？
-- 约束条件之间是否冲突？
-- 优先级排序是否清晰？
-
-## 验证结论格式
-
-在需求文档末尾追加：
-
-```markdown
----
-
-## 需求验证结论
-
-**验证日期**：YYYY-MM-DD
-**验证结论**：通过 / 有条件通过 / 不通过
-
-### 验证结果
-- [x] 完整性：通过
-- [x] 可行性：通过
-- [x] 无歧义性：通过
-- [x] 一致性：通过
-- [x] 可验证性：通过
-
-### 发现的问题（如有）
-1. [问题描述] → [修正方案]
-
-### 修改记录
-- [修改内容]
-```
-
-## 铁律
-
-```
-1. 每条需求必须逐条验证，不可批量跳过
-2. 发现问题必须现场修正，不可留到后续阶段
-3. 验证结论必须写入需求文档，不可口头声明
-4. validation 的唯一出口是 design（方案设计）
-```
-
-## Red Flags — 停下来
-
-| 信号 | 行动 |
-|------|------|
-| 需求文档不存在 | 回到 brainstorming 阶段 |
-| 需求中有"待定"或"TODO" | 现在确定，不可推迟 |
-| 需求可以被两种方式理解 | 选定一种并明确 |
-| 需求之间有矛盾 | 与用户澄清并修正 |
-| 想跳过验证直接设计 | 不允许，验证是必须的关口 |

package/skills/max/workflow/solution-design/SKILL.md

@@ -1,117 +0,0 @@
----
-name: solution-design
-description: 方案设计 — 在需求验证通过后使用。设计技术方案和架构，进行方案对比和技术选型，产出技术设计文档。
----
-
-# 方案设计
-
-基于已验证的需求，设计技术方案和架构。产出可指导实现的技术设计文档。
-
-```
-此阶段负责"怎么做"。输入是验证过的需求文档，输出是技术设计文档。
-```
-
-## 状态机
-
-```bash
-# 确认当前阶段
-bash scripts/harness/workflow-state.sh gate design
-# 完成后推进到任务拆解
-bash scripts/harness/workflow-state.sh advance
-```
-
-## 检查清单
-
-你**必须**按顺序完成以下每一项：
-
-1. **读取需求文档** — 从 `.dev-agents/shared/designs/` 加载已验证的需求文档
-2. **探索现有代码** — 理解现有架构、模式、技术栈
-3. **提出 2-3 种方案** — 包含取舍分析和推荐
-4. **选定方案** — 用户确认后锁定
-5. **详细设计** — 架构、组件、数据流、接口、错误处理
-6. **撰写设计文档** — 保存到 `.dev-agents/shared/designs/YYYY-MM-DD-<功能名>-design.md`
-7. **设计自检** — 检查占位符、矛盾、歧义
-8. **用户确认** — 请用户审阅设计文档
-9. **推进** — advance 到 planning 阶段
-
-## 设计文档结构
-
-```markdown
-# [功能名] 技术设计文档
-
-## 需求引用
-链接到需求文档路径
-
-## 方案对比
-
-### 方案 A：[名称]
-- 描述：...
-- 优点：...
-- 缺点：...
-
-### 方案 B：[名称]
-- 描述：...
-- 优点：...
-- 缺点：...
-
-### 选定方案
-方案 [X]，原因：...
-
-## 架构设计
-- 整体架构图
-- 组件职责
-
-## 数据流
-- 输入 → 处理 → 输出
-
-## 接口设计
-- API/函数签名
-- 参数和返回值
-
-## 技术栈
-- 使用的库/框架及版本
-
-## 错误处理策略
-- 异常类型和处理方式
-
-## 测试策略
-- 测试范围和方法
-```
-
-## 设计原则
-
-- 将系统拆分为更小的单元，每个单元有一个明确目的
-- 通过定义良好的接口通信，可以独立理解和测试
-- 对每个单元能回答：它做什么、怎么用、依赖什么
-- 外部能否不看内部就理解单元功能？能否修改内部而不破坏调用方？
-
-## 在现有代码库中工作
-
-- 在提议变更前先探索现有结构，遵循现有模式
-- 如果现有代码有影响本次工作的问题，在设计中包含针对性改进
-- 不提议无关的重构，保持聚焦
-
-## 铁律
-
-```
-1. 必须提出至少 2 种方案并做对比分析
-2. 设计文档不能有"待定""TODO"等占位符
-3. 必须获得用户确认后才能推进
-4. design 的唯一出口是 planning（任务拆解）
-```
-
-## Red Flags — 停下来
-
-| 信号 | 行动 |
-|------|------|
-| 没有需求文档就开始设计 | 停下来，回到 brainstorming |
-| 需求文档未通过验证 | 停下来，先完成 validation |
-| 只提了一种方案 | 补充至少一种替代方案 |
-| 设计中有"待定""之后再说" | 现在确定或标记为开放问题 |
-| 想跳过用户确认 | 不允许，用户审阅是必须的门禁 |
-
-## 与团队的协作
-
-- 如果涉及 UI/UX 设计，Max 应派遣艾拉参与
-- 设计文档是 writing-plans 的核心输入
-- 设计完成后进入 planning（任务拆解）

package/skills/max/workflow/testing/SKILL.md

@@ -1,118 +0,0 @@
----
-name: testing
-description: 测试验证 — 在开发完成后使用。编写和执行测试用例，进行两阶段审查（规格符合性 + 代码质量），确保代码质量达标。
----
-
-# 测试验证
-
-开发完成后，对代码进行系统性的测试验证和两阶段审查。
-
-```
-此阶段是开发到文档之间的质量关口。
-未通过测试验证的代码不得进入 documentation 阶段。
-```
-
-## 状态机
-
-```bash
-# 确认当前阶段
-bash scripts/harness/workflow-state.sh gate testing
-# 完成后推进到文档更新
-bash scripts/harness/workflow-state.sh advance
-```
-
-## 三个子步骤
-
-### 步骤 1：测试计划编写
-
-Max 基于实现计划（`.dev-agents/shared/tasks/`）编写或确认测试范围：
-
-- **功能测试**：每条功能需求对应的验证用例
-- **边界测试**：输入边界、空值、极端值
-- **异常测试**：错误处理路径、异常恢复
-- **回归测试**：确认未破坏现有功能
-
-### 步骤 2：Stage 1 — 规格符合性审查
-
-使用 **Agent 工具** 派遣 Kyle 子代理，提供：
-- 实现计划中的完整规格
-- Jarvis 修改的文件路径
-- 设计文档路径
-
-Kyle 检查：
-- 代码是否实现了计划的**每条**要求？
-- 多做了什么？（未要求的功能 = 需要移除）
-- 少做了什么？（遗漏的需求 = 需要补充）
-
-**Stage 1 不通过** → Agent 派遣 Jarvis 修复 → Agent 派遣 Kyle 重新审查 Stage 1
-
-### 步骤 3：Stage 2 — 代码质量审查
-
-Stage 1 通过后，使用 **Agent 工具** 派遣 Kyle 子代理，提供：
-- 代码变更的 git diff
-- 相关文件完整内容
-
-Kyle 检查：
-- 代码是否干净、可读、可维护？
-- 有无安全隐患？
-- 有无性能问题？
-- 测试是否充分？覆盖率是否达标？
-- 命名是否清晰？
-
-**Stage 2 不通过** → Agent 派遣 Jarvis 修复 → Agent 派遣 Kyle 重新审查 Stage 2
-
-## 审查报告格式
-
-每次审查产出报告保存到 `.dev-agents/shared/reviews/YYYY-MM-DD-<功能名>-review.md`：
-
-```markdown
-# 审查报告：[功能名]
-
-## 测试概要
-- 测试用例总数：N
-- 通过：N
-- 失败：N
-- 覆盖率：N%
-
-## Stage 1：规格符合性审查
-- 审查基准：[实现计划路径]
-- 结论：通过 / 不通过
-- 实现完整性：逐条核对结果
-- 问题清单：（如有）
-
-## Stage 2：代码质量审查
-- 结论：通过 / 不通过
-- 安全性：通过 / 发现问题
-- 性能：通过 / 发现问题
-- 可维护性：通过 / 发现问题
-- 问题清单：（如有）
-
-## 总体结论
-- 状态：通过 / 不通过
-- 修复建议：（如有）
-```
-
-## 铁律
-
-```
-1. Stage 1 不通过时禁止开始 Stage 2
-2. 审查发现问题必须修复后重审，不得跳过
-3. 审查报告必须包含完整的两阶段结构
-4. testing 的唯一出口是 documentation（文档更新）
-```
-
-## Red Flags — 停下来
-
-| 信号 | 行动 |
-|------|------|
-| 没有实现计划就开始审查 | 停下来，审查需要规格基准 |
-| Stage 1 通过前开始 Stage 2 | 停，先完成规格审查 |
-| 审查发现问题但跳过 | 停，Jarvis 修复后重审 |
-| Jarvis 说"搞定了"没验证证据 | 要求运行测试并展示输出 |
-| 使用"应该没问题""看起来对了" | 要求提供验证命令和输出证据 |
-
-## 关联技能
-
-- **subagent-driven-development** — 测试不通过时 Jarvis 修复
-- **verification-before-completion** — 每次声称修复后必须验证
-- **systematic-debugging** — 测试失败时的调试方法