aigroup-workflow 1.2.7 → 2.0.0

package/skills/requirement-engineering/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: requirement-engineering
+description: 需求工程 — 在任何创造性工作之前使用。通过协作对话收集需求、系统性验证、产出可作为设计和开发基准的需求文档。
+---
+
+# 需求工程
+
+把模糊想法转化为完整、无歧义、可验证的需求文档。包含两个阶段：**收集**（brainstorming）和**验证**（validation）。
+
+> 只负责"要做什么"，不负责"怎么做"——技术方案在 `architecture-designer` / `writing-plans` 完成。
+
+## 协调
+
+```bash
+# 建 session（若尚未创建）
+node scripts/orchestration/session.cjs init <任务名>
+# 需求文档写入 .orchestration/<session>/architect/requirements.md
+# 验证结论追加到同文件；通过后进入方案设计 phase
+```
+
+## 阶段 1：收集（brainstorming）
+
+1. **探索项目上下文** — 读 文件、文档、近期提交，了解现状
+2. **逐个提问澄清** — 每条消息**只问一个问题**，优先选择题
+3. **识别用户场景** — 谁用？什么场景？期望什么结果？
+4. **定义功能边界** — 做什么、不做什么、优先级
+5. **撰写需求文档** — 保存到 `.orchestration/<session>/architect/requirements.md`
+
+### 需求文档结构
+
+```markdown
+# [功能名] 需求文档
+
+## 背景与目的
+为什么做？解决什么问题？
+
+## 用户场景
+- 场景 1：作为 [角色]，我希望 [行为]，以便 [价值]
+
+## 功能需求（每条可验证）
+- [ ] FR-1：[具体描述 + 通过/不通过标准]
+
+## 约束条件
+- 性能 / 兼容性 / 安全要求
+
+## 非功能需求
+- ...
+
+## 范围排除（不做什么）
+- ...
+
+## 成功标准
+- ...
+```
+
+## 阶段 2：验证（validation）
+
+对收集到的需求逐条验证，不通过不得进入设计。
+
+| 维度 | 检查项 |
+|------|--------|
+| 完整性 | 每场景有对应 FR？异常/非功能需求齐全？范围排除明确？ |
+| 可行性 | 技术可实现？时间合理？与现有系统兼容？ |
+| 无歧义性 | 每条只有一种理解？数值/行为边界明确（"快速"→"200ms 内"）？ |
+| 一致性 | 条目间有矛盾？约束冲突？优先级清晰？ |
+| 可验证性 | 有明确通过/不通过标准？ |
+
+### 验证结论（追加到需求文档末尾）
+
+```markdown
+---
+
+## 需求验证结论
+
+**验证日期**：YYYY-MM-DD
+**结论**：通过 / 有条件通过 / 不通过
+
+- [x] 完整性 / 可行性 / 无歧义性 / 一致性 / 可验证性：通过
+
+### 发现的问题（如有）
+1. [问题] → [修正方案]
+
+### 修改记录
+- [修改内容]
+```
+
+## 铁律
+
+1. 此阶段不做技术方案设计、不选择技术栈、不讨论架构
+2. 每条消息只问一个问题
+3. 每条需求必须可验证（明确通过/不通过标准）
+4. 必须产出需求文档并获得用户确认才能推进
+5. 验证发现的问题必须**现场修正**，不得留到后续阶段
+
+## Red Flags — 停下来
+
+| 信号 | 行动 |
+|------|------|
+| 开始讨论技术方案 | 技术方案属于设计阶段，打住 |
+| 用户说"直接做吧" | 先完成最小需求文档 |
+| 需求描述了多个独立系统 | 先帮用户拆解为子项目 |
+| 需求中有"待定""之后再说" | 现在确定或标记为**明确的开放问题** |
+| 需求可以被两种方式理解 | 选定一种并明确 |
+| 需求之间有矛盾 | 与用户澄清并修正 |
+| 想跳过用户确认 | 用户确认是必须的门禁 |
+| 想跳过验证直接设计 | 不允许 |
+
+## 与其他 skill 的协作
+
+- 若涉及 UI/UX，可派遣对应 design agent 参与需求收集
+- 通过验证的需求文档是 `architecture-designer` / `writing-plans` 的核心输入

package/skills/{max/workflow/subagent-driven-development → subagent-driven-development}/SKILL.md

@@ -11,26 +11,26 @@ description: 当有实现计划且任务相互独立时使用。使用 Agent 工
 
 ```
 ❌ 错误方式（角色切换）：
-   Max 在当前对话里"假装变成 Jarvis"然后开始写代码
-   → 共享上下文、无隔离、Max 的项目管理视角被污染
+   主会话 在当前对话里"假装变成 Jarvis"然后开始写代码
+   → 共享上下文、无隔离、主会话 的项目管理视角被污染
 
 ✅ 正确方式（Agent 工具派遣）：
-   Max 调用 Agent({subagent_type: "jarvis", ...}) → 创建独立子代理
+   主会话 调用 Agent({subagent_type: "jarvis", ...}) → 创建独立子代理
    → 子代理有自己的上下文、技能和门控
-   → 子代理完成后返回结果给 Max → Max 继续协调
+   → 子代理完成后返回结果给 主会话 → 主会话 继续协调
 ```
 
-**铁律：Max 自己绝不写代码。所有开发/审查工作必须通过 Agent 工具委派给隔离的子代理（`.claude/agents/{ella,jarvis,kyle}.md`）。**
+**铁律：主会话 自己绝不写代码。所有开发/审查工作必须通过 Agent 工具委派给隔离的子代理（`.claude/agents/{ella,jarvis,kyle}.md`）。**
 
 ## 铁律
 
 ```
-1. 使用 Agent 工具派遣，不是角色切换。Max 不写代码。
+1. 使用 Agent 工具派遣，不是角色切换。主会话 不写代码。
 2. 每个任务一个全新子代理，禁止复用上下文
 3. 两阶段审查顺序不可颠倒：先规格符合性，再代码质量
 4. 审查不通过 = 修复 + 重新审查，不得跳过
 5. 禁止并行派遣多个实现子代理（避免冲突）
-6. 不让子代理自己读计划文件，由 Max 提取任务全文注入 prompt
+6. 不让子代理自己读计划文件，由 主会话 提取任务全文注入 prompt
 ```
 
 ## 流程
@@ -59,7 +59,7 @@ description: 当有实现计划且任务相互独立时使用。使用 Agent 工
 
 ## 派遣 Jarvis 实现子代理 — 具体操作
 
-Max 必须使用 **Agent 工具** 派遣 Jarvis。以下是具体的调用方式：
+主会话 必须使用 **Agent 工具** 派遣 Jarvis。以下是具体的调用方式：
 
 ### 步骤 1：准备 prompt
 
@@ -77,8 +77,8 @@ prompt 模板：
 
 ## 上下文
 - 该任务在整体计划中的位置：第 N/M 个任务
-- 设计文档路径：.dev-agents/shared/designs/YYYY-MM-DD-xxx-design.md
-- 实现计划路径：.dev-agents/shared/tasks/YYYY-MM-DD-xxx-plan.md
+- 设计文档路径：.orchestration/<session>/architect/YYYY-MM-DD-xxx-design.md
+- 实现计划路径：.orchestration/<session>/planner/YYYY-MM-DD-xxx-plan.md
 
 ## 工作规范
 - 遵循 TDD：先写失败测试 → 确认失败 → 写最小实现 → 确认通过 → 提交
@@ -97,9 +97,9 @@ Agent({
 
 ### 步骤 3：处理返回结果
 
-子代理完成后会返回结果给 Max。Max 根据状态处理：
+子代理完成后会返回结果给 主会话。主会话 根据状态处理：
 
-| 状态 | Max 的处理方式 |
+| 状态 | 主会话 的处理方式 |
 |------|-------------|
 | **DONE** | 进入审查：Agent 工具派遣 Kyle |
 | **DONE_WITH_CONCERNS** | 先评估疑虑，再决定是否审查 |
@@ -132,7 +132,7 @@ Agent({
 Jarvis 修改的文件：
 [此处列出 Jarvis 报告中的变更文件列表]
 
-设计文档路径：.dev-agents/shared/designs/YYYY-MM-DD-xxx-design.md
+设计文档路径：.orchestration/<session>/architect/YYYY-MM-DD-xxx-design.md
 
 ### 检查要求
 - 代码是否实现了计划的每条要求？
@@ -140,7 +140,7 @@ Jarvis 修改的文件：
 - 少做了什么？（遗漏的需求 = 需要补充）
 
 ## 输出
-审查报告保存到 `.dev-agents/shared/reviews/YYYY-MM-DD-xxx-review.md`
+审查报告保存到 `.orchestration/<session>/code-reviewer/YYYY-MM-DD-xxx-review.md`
 结论：通过 / 不通过（附具体问题清单）
   "
 })
@@ -168,7 +168,7 @@ git diff HEAD~1
 - 命名是否清晰？
 
 ## 输出
-在 `.dev-agents/shared/reviews/` 的审查报告中追加 Stage 2 结论
+在 `.orchestration/<session>/code-reviewer/` 的审查报告中追加 Stage 2 结论
 结论：通过 / 不通过（附问题清单和修复建议）
   "
 })
@@ -178,12 +178,12 @@ git diff HEAD~1
 
 ```
 Kyle Stage 1 不通过
-  → Max 提取问题清单
+  → 主会话 提取问题清单
   → Agent 派遣新的 Jarvis 子代理修复
   → Agent 派遣新的 Kyle 重审 Stage 1
 
 Kyle Stage 2 不通过
-  → Max 提取问题清单
+  → 主会话 提取问题清单
   → Agent 派遣新的 Jarvis 子代理修复
   → Agent 派遣新的 Kyle 重审 Stage 2
 ```
@@ -194,7 +194,7 @@ Kyle Stage 2 不通过
 
 | 信号 | 行动 |
 |------|------|
-| Max 自己开始写代码 | 停，使用 Agent 工具派遣 Jarvis |
+| 主会话 自己开始写代码 | 停，使用 Agent 工具派遣 Jarvis |
 | 在当前对话中"变成 Jarvis" | 停，这是角色切换不是子代理 |
 | 在 Stage 1 通过前开始 Stage 2 | 停，先完成规格审查 |
 | 审查发现问题但跳过了 | 停，Jarvis 修复后重审 |

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. 实现注意事项（如有）
-
-不要在报告中输出设计稿全文，只返回路径引用。
-
-## 禁止事项
-
-- 不写代码（那是贾维斯的职责）
-- 不做测试验收（那是凯尔的职责）
-- 不输出模糊的设计（必须有具体数值）
-- 不跳过设计自检