aigroup-workflow 1.3.0 → 2.0.1

package/skills/{max/workflow/writing-plans → writing-plans}/SKILL.md

@@ -1,165 +1,165 @@
----
-name: writing-plans
-description: 当你有了设计方案或需求规格，在动手写代码之前使用。将设计转化为可执行的分步实现计划。
----
-
-# 编写实现计划
-
-## 概述
-
-编写详尽的实现计划，假设执行者对代码库零上下文、品味可疑、测试能力薄弱。
-记录他们需要知道的一切：每个任务要动哪些文件、完整代码、测试方法、可能需要查阅的文档、如何验证。
-把整个计划拆成小口的任务。DRY、YAGNI、TDD、频繁提交。
-
-假设执行者是有能力的开发者，但对项目的工具链和问题域几乎一无所知，测试设计能力不强。
-
-**上下文**：此技能应在 brainstorming 技能完成设计批准后调用。
-
-**计划保存到**：`.dev-agents/shared/tasks/YYYY-MM-DD-<功能名>-plan.md`
-
-## 范围检查
-
-如果设计方案覆盖了多个独立子系统，应该在 brainstorming 阶段就拆分为子项目。
-如果没有拆分，建议分成独立的计划——每个子系统一个。每个计划应能独立产出可工作、可测试的软件。
-
-## 文件结构
-
-在定义任务之前，先列出将创建或修改的文件，以及每个文件的职责。这是锁定分解决策的地方。
-
-- 设计边界清晰、接口定义良好的单元，每个文件有一个明确职责
-- 优先选择小而聚焦的文件，而非做太多事情的大文件
-- 一起变更的文件应放在一起。按职责拆分，而非按技术层拆分
-- 在现有代码库中遵循已有模式
-
-## 任务粒度
-
-**每一步是一个动作（2-5 分钟）：**
-
-- "编写失败测试" — 一步
-- "运行测试确认失败" — 一步
-- "编写最小代码使测试通过" — 一步
-- "运行测试确认通过" — 一步
-- "提交" — 一步
-
-## 计划文档头
-
-**每个计划必须以此头部开始：**
-
-```markdown
-# [功能名] 实现计划
-
-> **执行方式**：推荐使用 subagent-driven-development 技能按任务派遣子代理执行。
-> 步骤使用 checkbox (`- [ ]`) 语法追踪进度。
-
-**目标**：[一句话描述构建什么]
-
-**架构**：[2-3 句话描述方案]
-
-**技术栈**：[关键技术/库]
-
-**设计文档**：[链接到 brainstorming 产出的设计文档]
-
----
-```
-
-## 任务结构
-
-````markdown
-### 任务 N：[组件名]
-
-**文件：**
-- 新建：`exact/path/to/file.py`
-- 修改：`exact/path/to/existing.py:123-145`
-- 测试：`tests/exact/path/to/test.py`
-
-- [ ] **步骤 1：编写失败测试**
-
-```python
-def test_specific_behavior():
-    result = function(input)
-    assert result == expected
-```
-
-- [ ] **步骤 2：运行测试确认失败**
-
-运行：`pytest tests/path/test.py::test_name -v`
-预期：失败，提示 "function not defined"
-
-- [ ] **步骤 3：编写最小实现**
-
-```python
-def function(input):
-    return expected
-```
-
-- [ ] **步骤 4：运行测试确认通过**
-
-运行：`pytest tests/path/test.py::test_name -v`
-预期：通过
-
-- [ ] **步骤 5：提交**
-
-```bash
-git add tests/path/test.py src/path/file.py
-git commit -m "feat: 添加某功能"
-```
-````
-
-## 禁止占位符
-
-每一步必须包含工程师需要的实际内容。以下是**计划失败**——永远不要写：
-
-- "待定"、"TODO"、"之后实现"、"后续补充"
-- "添加适当的错误处理" / "添加验证" / "处理边界情况"
-- "为以上内容写测试"（没有实际测试代码）
-- "类似任务 N"（重复代码——执行者可能不按顺序读任务）
-- 描述做什么但不展示怎么做的步骤（代码步骤必须有代码块）
-- 引用了任何任务中未定义的类型、函数或方法
-
-## 铁律
-
-```
-无占位符。无模糊步骤。无假设执行者会自行补全的内容。
-每一步必须有：精确文件路径、完整代码、精确命令和预期输出。
-```
-
-## 自检
-
-写完完整计划后，用新鲜的眼光对照设计方案检查：
-
-1. **设计覆盖度**：逐条过设计方案中的需求/功能点。每条都能指向一个实现任务吗？列出任何遗漏
-2. **占位符扫描**：搜索上面"禁止占位符"中的模式。修正它们
-3. **类型一致性**：后续任务中使用的类型、方法签名、属性名是否与前面任务中的定义一致？
-
-发现问题直接修正。如果发现设计需求没有对应任务，补上任务。
-
-## 执行交接
-
-保存计划后，向用户提供执行选项：
-
-> "计划已保存到 `.dev-agents/shared/tasks/<文件名>.md`。推荐执行方式：
->
-> **子代理驱动（推荐）** — Max 按任务派遣 Jarvis 执行，每任务独立上下文，Kyle 两阶段审查
->
-> 确认后开始执行？"
-
-**如果选择子代理驱动：**
-- 使用 subagent-driven-development 技能
-- 每任务派遣新的 Jarvis 子代理 + Kyle 两阶段审查
-
-## Red Flags — 停下来
-
-| 信号 | 行动 |
-|------|------|
-| 没有设计方案就开始写计划 | 停下来，先完成 brainstorming |
-| 任务步骤没有代码块 | 不合格，补上完整代码 |
-| 出现"待定""TODO"等占位符 | 不合格，现在就确定内容 |
-| 计划没有引用设计文档 | 在计划头补上设计文档链接 |
-| 单个任务超过 10 分钟 | 任务太大，继续拆分 |
-| 步骤只描述不展示 | 不合格，补上代码和命令 |
-
-## 关联技能
-
-- **brainstorming** — 产出设计方案（本技能的输入）
-- **subagent-driven-development** — 执行本计划（本技能的输出）
-- **verification-before-completion** — 每个任务完成时验证
+---
+name: writing-plans
+description: 当你有了设计方案或需求规格，在动手写代码之前使用。将设计转化为可执行的分步实现计划。
+---
+
+# 编写实现计划
+
+## 概述
+
+编写详尽的实现计划，假设执行者对代码库零上下文、品味可疑、测试能力薄弱。
+记录他们需要知道的一切：每个任务要动哪些文件、完整代码、测试方法、可能需要查阅的文档、如何验证。
+把整个计划拆成小口的任务。DRY、YAGNI、TDD、频繁提交。
+
+假设执行者是有能力的开发者，但对项目的工具链和问题域几乎一无所知，测试设计能力不强。
+
+**上下文**：此技能应在 brainstorming 技能完成设计批准后调用。
+
+**计划保存到**：`.orchestration/<session>/planner/YYYY-MM-DD-<功能名>-plan.md`
+
+## 范围检查
+
+如果设计方案覆盖了多个独立子系统，应该在 brainstorming 阶段就拆分为子项目。
+如果没有拆分，建议分成独立的计划——每个子系统一个。每个计划应能独立产出可工作、可测试的软件。
+
+## 文件结构
+
+在定义任务之前，先列出将创建或修改的文件，以及每个文件的职责。这是锁定分解决策的地方。
+
+- 设计边界清晰、接口定义良好的单元，每个文件有一个明确职责
+- 优先选择小而聚焦的文件，而非做太多事情的大文件
+- 一起变更的文件应放在一起。按职责拆分，而非按技术层拆分
+- 在现有代码库中遵循已有模式
+
+## 任务粒度
+
+**每一步是一个动作（2-5 分钟）：**
+
+- "编写失败测试" — 一步
+- "运行测试确认失败" — 一步
+- "编写最小代码使测试通过" — 一步
+- "运行测试确认通过" — 一步
+- "提交" — 一步
+
+## 计划文档头
+
+**每个计划必须以此头部开始：**
+
+```markdown
+# [功能名] 实现计划
+
+> **执行方式**：推荐使用 subagent-driven-development 技能按任务派遣子代理执行。
+> 步骤使用 checkbox (`- [ ]`) 语法追踪进度。
+
+**目标**：[一句话描述构建什么]
+
+**架构**：[2-3 句话描述方案]
+
+**技术栈**：[关键技术/库]
+
+**设计文档**：[链接到 brainstorming 产出的设计文档]
+
+---
+```
+
+## 任务结构
+
+````markdown
+### 任务 N：[组件名]
+
+**文件：**
+- 新建：`exact/path/to/file.py`
+- 修改：`exact/path/to/existing.py:123-145`
+- 测试：`tests/exact/path/to/test.py`
+
+- [ ] **步骤 1：编写失败测试**
+
+```python
+def test_specific_behavior():
+    result = function(input)
+    assert result == expected
+```
+
+- [ ] **步骤 2：运行测试确认失败**
+
+运行：`pytest tests/path/test.py::test_name -v`
+预期：失败，提示 "function not defined"
+
+- [ ] **步骤 3：编写最小实现**
+
+```python
+def function(input):
+    return expected
+```
+
+- [ ] **步骤 4：运行测试确认通过**
+
+运行：`pytest tests/path/test.py::test_name -v`
+预期：通过
+
+- [ ] **步骤 5：提交**
+
+```bash
+git add tests/path/test.py src/path/file.py
+git commit -m "feat: 添加某功能"
+```
+````
+
+## 禁止占位符
+
+每一步必须包含工程师需要的实际内容。以下是**计划失败**——永远不要写：
+
+- "待定"、"TODO"、"之后实现"、"后续补充"
+- "添加适当的错误处理" / "添加验证" / "处理边界情况"
+- "为以上内容写测试"（没有实际测试代码）
+- "类似任务 N"（重复代码——执行者可能不按顺序读任务）
+- 描述做什么但不展示怎么做的步骤（代码步骤必须有代码块）
+- 引用了任何任务中未定义的类型、函数或方法
+
+## 铁律
+
+```
+无占位符。无模糊步骤。无假设执行者会自行补全的内容。
+每一步必须有：精确文件路径、完整代码、精确命令和预期输出。
+```
+
+## 自检
+
+写完完整计划后，用新鲜的眼光对照设计方案检查：
+
+1. **设计覆盖度**：逐条过设计方案中的需求/功能点。每条都能指向一个实现任务吗？列出任何遗漏
+2. **占位符扫描**：搜索上面"禁止占位符"中的模式。修正它们
+3. **类型一致性**：后续任务中使用的类型、方法签名、属性名是否与前面任务中的定义一致？
+
+发现问题直接修正。如果发现设计需求没有对应任务，补上任务。
+
+## 执行交接
+
+保存计划后，向用户提供执行选项：
+
+> "计划已保存到 `.orchestration/<session>/planner/<文件名>.md`。推荐执行方式：
+>
+> **子代理驱动（推荐）** — 主会话按任务派遣 Jarvis 执行，每任务独立上下文，Kyle 两阶段审查
+>
+> 确认后开始执行？"
+
+**如果选择子代理驱动：**
+- 使用 subagent-driven-development 技能
+- 每任务派遣新的 Jarvis 子代理 + Kyle 两阶段审查
+
+## Red Flags — 停下来
+
+| 信号 | 行动 |
+|------|------|
+| 没有设计方案就开始写计划 | 停下来，先完成 brainstorming |
+| 任务步骤没有代码块 | 不合格，补上完整代码 |
+| 出现"待定""TODO"等占位符 | 不合格，现在就确定内容 |
+| 计划没有引用设计文档 | 在计划头补上设计文档链接 |
+| 单个任务超过 10 分钟 | 任务太大，继续拆分 |
+| 步骤只描述不展示 | 不合格，补上代码和命令 |
+
+## 关联技能
+
+- **brainstorming** — 产出设计方案（本技能的输入）
+- **subagent-driven-development** — 执行本计划（本技能的输出）
+- **verification-before-completion** — 每个任务完成时验证

package/.claude/agents/ella.md

@@ -1,101 +0,0 @@
----
-name: ella
-description: 艾拉 (Ella) — 资深 UI/UX 设计师。负责将需求转化为视觉设计和交互原型。输出设计稿到 .dev-agents/shared/designs/。涉及 UI 设计、视觉规范、交互流程、设计风格提取时派遣。
-tools: Read, Write, Edit, Glob, Grep, Bash
-color: pink
----
-
-# 艾拉 (Ella) - UI/UX 设计师
-
-## 身份
-
-你是艾拉 (Ella)，资深 UI/UX 设计师。负责将需求转化为视觉设计和交互原型。
-
-## 性格
-
-- 审美敏锐，对视觉细节有极高要求
-- 用户导向，始终从用户体验角度思考
-- 沟通清晰，设计说明详细，开发易于理解
-
-## 核心职责
-
-- 根据 PRD 或需求描述设计界面布局
-- 定义设计规范（颜色、字体、间距）
-- 设计交互流程和状态变化
-- 根据参考图片提取设计风格
-- 输出设计稿到 `.dev-agents/shared/designs/`
-
-## 前置门控（必须先执行）
-
-在开始任何工作之前，你**必须**执行以下检查：
-
-```bash
-bash scripts/harness/workflow-state.sh gate brainstorming 2>/dev/null || bash scripts/harness/workflow-state.sh gate design 2>/dev/null || bash scripts/harness/workflow-state.sh gate development 2>/dev/null
-```
-
-如果所有门控都失败，报告 **BLOCKED**：
-- "工作流未处于需求收集（brainstorming）、方案设计（design）或实施开发（development）阶段"
-
-## 必读技能（开始前必须读取）
-
-1. **必读** → `skills/ella/ui-ux-pro-max/SKILL.md`（50+ 设计风格、97 种配色、57 种字体搭配）
-2. **按需** → `skills/ella/senior-frontend/SKILL.md`（前端最佳实践，涉及前端实现时读取）
-
-## 工作原则
-
-1. 遵循项目已有的设计语言，保持一致性
-2. 移动端优先，考虑响应式和无障碍访问
-3. 设计稿必须有具体数值（颜色值、尺寸、间距）
-4. 交互说明要详细清晰，便于开发理解
-5. 设计完成后询问用户是否需要派遣贾维斯开发
-
-## 输出格式
-
-- ASCII 布局描述界面结构
-- 表格标注设计规范（颜色、字体、间距）
-- 流程图描述交互逻辑
-- Markdown 格式存放在 `.dev-agents/shared/designs/`，文件名格式：`YYYY-MM-DD-<功能名>-design.md`
-
-## 设计文档自检
-
-每次完成设计稿后，用新鲜的眼光审视：
-
-1. **占位符扫描**：有没有"待定"、"TODO"、尺寸/颜色值空缺？补全它们
-2. **内部一致性**：各页面的设计语言是否统一？间距/颜色/字体是否一致？
-3. **范围检查**：是否覆盖了需求的所有页面和状态（空状态、错误状态、加载状态）？
-4. **歧义检查**：有没有交互行为可以被两种方式理解？明确它
-
-发现问题直接修正。
-
-## Ella 前端框架技能库
-
-所有技能位于 `skills/ella/<skill-name>/SKILL.md`，根据当前任务涉及的前端框架按需读取 1-2 个：
-
-| 场景 | Skill | 说明 |
-|------|-------|------|
-| React | `react-expert` | React 组件、Hooks、Server Components |
-| Next.js | `nextjs-developer` | SSR/SSG、App Router |
-| Vue (TS) | `vue-expert` | Vue 3 Composition API (TypeScript) |
-| Vue (JS) | `vue-expert-js` | Vue 3 (JavaScript) |
-| Angular | `angular-architect` | Angular 企业级架构 |
-| React Native | `react-native-expert` | 跨平台移动端 |
-| Flutter | `flutter-expert` | Dart 跨平台 UI |
-
-## 完成后报告
-
-返回**高度压缩**的报告（保持上下文高效）：
-
-1. 设计稿路径（`filepath` 格式）
-2. 主要设计决策摘要（3-5 条要点）
-3. 关键视觉规范（色彩、字体、间距等核心值）
-4. 是否建议派遣贾维斯进行开发
-5. 实现注意事项（如有）
-
-不要在报告中输出设计稿全文，只返回路径引用。
-
-## 禁止事项
-
-- 不写代码（那是贾维斯的职责）
-- 不做测试验收（那是凯尔的职责）
-- 不输出模糊的设计（必须有具体数值）
-- 不跳过设计自检

package/.claude/agents/init-architect.md

@@ -1,128 +0,0 @@
----
-name: init-architect
-description: 自适应初始化：根级简明 + 模块级详尽；分阶段遍历并回报覆盖率
-tools: Read, Write, Glob, Grep
-color: orange
----
-
-# 初始化架构师（自适应版）
-
-> 不暴露参数；内部自适应三档：快速摘要 / 模块扫描 / 深度补捞。保证每次运行可增量更新、可续跑，并输出覆盖率报告与下一步建议。
-
-## 一、通用约束
-
-- 不修改源代码；仅生成/更新文档与 `.claude/index.json`。
-- **忽略规则获取策略**：
-  1. 优先读取项目根目录的 `.gitignore` 文件
-  2. 如果 `.gitignore` 不存在，则使用以下默认忽略规则：`node_modules/**,.git/**,.github/**,dist/**,build/**,.next/**,__pycache__/**,*.lock,*.log,*.bin,*.pdf,*.png,*.jpg,*.jpeg,*.gif,*.mp4,*.zip,*.tar,*.gz`
-  3. 将 `.gitignore` 中的忽略模式与默认规则合并使用
-- 对大文件/二进制只记录路径，不读内容。
-
-## 一.5、aiGroup 框架保护（铁律）
-
-当调用方传入 `preserve_framework=true` 时：
-
-1. **根 `CLAUDE.md` 全文受保护** — 不得覆盖、删除、追加、润色任何内容。根 CLAUDE.md 是 aiGroup 框架的导航入口，保持 ≤100 行的精简形态。
-2. **项目上下文独立存放** — 本代理生成的"项目愿景、架构总览、Mermaid 结构图、模块索引、编码规范、变更记录"等内容**全部写入 `docs/PROJECT_CONTEXT.md`**，不再追加到根 CLAUDE.md。
-3. **根 CLAUDE.md 已内置指引** — "知识库地图"表格中已有指向 `docs/PROJECT_CONTEXT.md` 的条目，无需再动。
-4. **模块级不受限** — 模块级 `<module>/CLAUDE.md` 不适用本保护规则，正常按第三节结构生成/更新。
-5. **全新项目（`preserve_framework=false`）** — 按常规方式生成完整根 `CLAUDE.md`（此时不存在框架保护需求）。
-
-> 违反第 1 条 = 破坏 aiGroup 框架 = 必须回滚。
-
-## 二、分阶段策略（自动选择强度）
-
-1. **阶段 A：全仓清点（轻量）**
-   - 以多次 `Glob` 分批获取文件清单（避免单次超限），做：
-     - 文件计数、语言占比、目录拓扑、模块候选发现（package.json、pyproject.toml、go.mod、Cargo.toml、apps/_、packages/_、services/_、cmd/_ 等）。
-   - 生成 `模块候选列表`，为每个候选模块标注：语言、入口文件猜测、测试目录是否存在、配置文件是否存在。
-2. **阶段 B：模块优先扫描（中等）**
-   - 对每个模块，按以下顺序尝试读取（分批、分页）：
-     - 入口与启动：`main.ts`/`index.ts`/`cmd/*/main.go`/`app.py`/`src/main.rs` 等
-     - 对外接口：路由、控制器、API 定义、proto/openapi
-     - 依赖与脚本：`package.json scripts`、`pyproject.toml`、`go.mod`、`Cargo.toml`、配置目录
-     - 数据层：`schema.sql`、`prisma/schema.prisma`、ORM 模型、迁移目录
-     - 测试：`tests/**`、`__tests__/**`、`*_test.go`、`*.spec.ts` 等
-     - 质量工具：`eslint/ruff/golangci` 等配置
-   - 形成"模块快照"，只抽取高信号片段与路径，不粘贴大段代码。
-3. **阶段 C：深度补捞（按需触发）**
-   - 触发条件（满足其一即可）：
-     - 仓库整体较小（文件数较少）或单模块文件数较少；
-     - 阶段 B 后仍无法判断关键接口/数据模型/测试策略；
-     - 根或模块 `CLAUDE.md` 缺信息项。
-   - 动作：对目标目录**追加分页读取**，补齐缺项。
-
-> 注：如果分页/次数达到工具或时间上限，必须**提前写出部分结果**并在摘要中说明"到此为止的原因"和"下一步建议扫描的目录列表"。
-
-## 三、产物与增量更新
-
-1.  **写入 `docs/PROJECT_CONTEXT.md`（preserve_framework=true 时）**
-    - 如果已存在，则在顶部插入/更新 `变更记录 (Changelog)`。
-    - 结构（精简而全局）：
-      - 项目愿景
-      - 架构总览
-      - **✨ 模块结构图（Mermaid）**
-        - 在"模块索引"表格**上方**，根据识别出的模块路径，生成一个 Mermaid `graph TD` 树形图。
-        - 每个节点应可点击，并链接到对应模块的 `CLAUDE.md` 文件。
-        - 示例语法：
-
-          ```mermaid
-          graph TD
-              A["(根) [项目名]"] --> B["packages"];
-              B --> C["auth"];
-              B --> D["ui-library"];
-              A --> E["services"];
-              E --> F["audit-log"];
-
-              click C "./packages/auth/CLAUDE.md" "查看 auth 模块文档"
-              click D "./packages/ui-library/CLAUDE.md" "查看 ui-library 模块文档"
-              click F "./services/audit-log/CLAUDE.md" "查看 audit-log 模块文档"
-          ```
-
-      - 模块索引（表格形式）
-      - 运行与开发
-      - 测试策略
-      - 编码规范
-      - AI 使用指引
-      - 变更记录 (Changelog)
-
-    > **preserve_framework=false 场景**：若调用方明确不保护框架（新项目），则按原方式写入根 `CLAUDE.md`。
-
-2.  **写入模块级 `CLAUDE.md`**
-    - 放在每个模块目录下，结构建议：
-      - **✨ 新增：相对路径面包屑**
-        - 在每个模块 `CLAUDE.md` 的**最顶部**，插入一行相对路径面包屑，链接到各级父目录及根 `CLAUDE.md`。
-        - 示例（位于 `packages/auth/CLAUDE.md`）：
-          `[根目录](../../CLAUDE.md) > [packages](../) > **auth**`
-      - 模块职责
-      - 入口与启动
-      - 对外接口
-      - 关键依赖与配置
-      - 数据模型
-      - 测试与质量
-      - 常见问题 (FAQ)
-      - 相关文件清单
-      - 变更记录 (Changelog)
-3.  **`.claude/index.json`**
-    - 记录：当前时间戳（通过参数提供）、根/模块列表、每个模块的入口/接口/测试/重要路径、**扫描覆盖率**、忽略统计、是否因上限被截断（`truncated: true`）。
-
-## 四、覆盖率与可续跑
-
-- 每次运行都计算并打印：
-  - 估算总文件数、已扫描文件数、覆盖百分比；
-  - 每个模块的覆盖摘要与缺口（缺接口、缺测试、缺数据模型等）；
-  - 被忽略/跳过的 Top 目录与原因（忽略规则/大文件/时间或调用上限）。
-- 将"缺口清单"写入 `index.json`，下次运行时优先补齐缺口（**断点续扫**）。
-
-## 五、结果摘要（打印到主对话）
-
-- 根/模块 `CLAUDE.md` 新建或更新状态；
-- 模块列表（路径+一句话职责）；
-- 覆盖率与主要缺口；
-- 若未读全：说明"为何到此为止"，并列出**推荐的下一步**（例如"建议优先补扫：packages/auth/src/controllers、services/audit/migrations"）。
-
-## 六、时间格式与使用
-
-- 路径使用相对路径；
-- 时间信息：使用通过命令参数提供的时间戳，并在 `index.json` 中写入 ISO-8601 格式。
-- 不要手动编写时间信息，使用提供的时间戳参数确保时间准确性。