aigroup-workflow 1.3.0 → 2.0.1

package/scripts/update-skills.sh

@@ -1,187 +0,0 @@
-#!/bin/bash
-# ================================================================
-# aiGroup - Skills 自动更新脚本
-# 用法: bash scripts/update-skills.sh [target]
-# 示例:
-#   bash scripts/update-skills.sh all          # 更新所有 GitHub 来源
-#   bash scripts/update-skills.sh ccpm         # 只更新 ccpm
-#   bash scripts/update-skills.sh engineering  # 只更新 engineering-team
-#   bash scripts/update-skills.sh manual       # 显示需手动更新的技能
-# ================================================================
-
-SKILLS_DIR="skills"
-TEMP_DIR=$(mktemp -d)
-
-trap "rm -rf '$TEMP_DIR'" EXIT
-
-# GitHub 镜像列表（直连失败时依次尝试）
-MIRRORS=(
-    "https://github.com"
-    "https://ghfast.top/https://github.com"
-    "https://mirror.ghproxy.com/https://github.com"
-)
-
-# 颜色
-GREEN='\033[0;32m'
-YELLOW='\033[1;33m'
-RED='\033[0;31m'
-NC='\033[0m'
-
-info()  { echo -e "${GREEN}[INFO]${NC} $1"; }
-warn()  { echo -e "${YELLOW}[WARN]${NC} $1"; }
-error() { echo -e "${RED}[ERROR]${NC} $1"; }
-
-# 带镜像回退的 git clone
-clone_repo() {
-    local repo=$1
-    local dest=$2
-
-    for mirror in "${MIRRORS[@]}"; do
-        local url="$mirror/$repo.git"
-        info "  尝试: $url"
-        if git clone --depth 1 "$url" "$dest" 2>/dev/null; then
-            return 0
-        fi
-        rm -rf "$dest"
-    done
-    return 1
-}
-
-# 从 GitHub 克隆并同步到本地目录
-update_from_github() {
-    local repo=$1
-    local target=$2
-
-    info "更新 $target ← github.com/$repo"
-
-    local clone_dir="$TEMP_DIR/$(echo "$repo" | tr '/' '_')"
-
-    if [ ! -d "$clone_dir" ]; then
-        if ! clone_repo "$repo" "$clone_dir"; then
-            error "所有镜像均克隆失败: $repo"
-            return 1
-        fi
-    fi
-
-    # 显示最新提交
-    local commit date
-    commit="$(cd "$clone_dir" && git rev-parse --short HEAD)"
-    date="$(cd "$clone_dir" && git log -1 --format='%ci' | cut -d' ' -f1)"
-    info "  最新提交: $commit ($date)"
-
-    # 同步文件
-    rm -rf "$SKILLS_DIR/$target"
-    cp -r "$clone_dir" "$SKILLS_DIR/$target"
-    rm -rf "$SKILLS_DIR/$target/.git"
-
-    local count
-    count="$(find "$SKILLS_DIR/$target" -type f | wc -l | tr -d ' ')"
-    info "  ✓ 已同步 $count 个文件"
-}
-
-# ── 各源更新函数 ──
-
-update_ccpm() {
-    update_from_github "automazeio/ccpm" "max/ccpm"
-}
-
-update_pm() {
-    update_from_github "mohitagw15856/pm-claude-skills" "max/pm-claude-skills"
-}
-
-update_simone() {
-    update_from_github "Helmi/claude-simone" "jarvis/claude-simone"
-}
-
-update_engineering() {
-    update_from_github "alirezarezvani/claude-skills" "jarvis/engineering-team"
-}
-
-show_manual() {
-    warn "以下技能来自 SkillsMP 技能市场，需要手动更新："
-    echo ""
-    echo "  ui-ux-pro-max    → skills/ella/ui-ux-pro-max"
-    echo "  senior-frontend  → skills/ella/senior-frontend"
-    echo "  senior-qa        → skills/kyle/senior-qa"
-    echo "  tdd-guide        → skills/kyle/tdd-guide"
-    echo ""
-    echo "  请前往 SkillsMP 技能市场下载最新版本后替换对应目录。"
-}
-
-# ── 主逻辑 ──
-
-TARGET=${1:-""}
-
-if [ -z "$TARGET" ]; then
-    echo "用法: $0 <target>"
-    echo ""
-    echo "  all              更新所有 GitHub 来源"
-    echo "  ccpm             更新 CCPM 项目管理"
-    echo "  pm               更新 PM Claude Skills"
-    echo "  simone           更新 Claude Simone"
-    echo "  engineering      更新 Engineering Team"
-    echo "  manual           显示需手动更新的技能"
-    exit 0
-fi
-
-echo "======================================"
-echo "  aiGroup Skills 更新工具"
-echo "======================================"
-echo ""
-
-SUCCESS=0
-FAIL=0
-
-run_update() {
-    if "$@"; then
-        SUCCESS=$((SUCCESS + 1))
-    else
-        FAIL=$((FAIL + 1))
-    fi
-}
-
-case $TARGET in
-    all)
-        run_update update_ccpm
-        echo ""
-        run_update update_pm
-        echo ""
-        run_update update_simone
-        echo ""
-        run_update update_engineering
-        echo ""
-        echo "--------------------------------------"
-        echo -e "  结果: ${GREEN}成功 $SUCCESS${NC}  ${RED}失败 $FAIL${NC}"
-        echo "--------------------------------------"
-        echo ""
-        show_manual
-        ;;
-    ccpm)
-        run_update update_ccpm
-        ;;
-    pm|pm-claude-skills)
-        run_update update_pm
-        ;;
-    simone|claude-simone)
-        run_update update_simone
-        ;;
-    engineering|engineering-team|eng)
-        run_update update_engineering
-        ;;
-    manual|skillsmp)
-        show_manual
-        ;;
-    *)
-        error "未知目标: $TARGET"
-        echo ""
-        echo "可用: all | ccpm | pm | simone | engineering | manual"
-        exit 1
-        ;;
-esac
-
-echo ""
-if [ $FAIL -gt 0 ]; then
-    warn "有 $FAIL 个源更新失败"
-    exit 1
-fi
-info "完成！"

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（任务拆解）