sdd-full 4.2.0 → 4.3.1

package/skills/workflow-runner/SKILL.md

@@ -1,172 +0,0 @@
----
-name: workflow-runner
-description: "在 Claude Code / OpenClaw / Cursor 中直接运行 agency-orchestrator YAML 工作流——无需 API key，使用当前会话的 LLM 作为执行引擎。当用户提供 .yaml 工作流文件或要求多角色协作完成任务时触发。"
----
-
-# 工作流执行器：在 AI 工具内运行多角色编排
-
-直接在当前会话中执行 agency-orchestrator 的 YAML 工作流，无需配置 API key。当前 LLM 就是执行引擎——依次扮演每个角色完成任务。
-
-## 适用场景
-
-- 用户提供了一个 `.yaml` 工作流文件（如 `运行 workflows/story-creation.yaml`）
-- 用户要求多个角色协作完成任务（如"用产品经理和架构师一起评审这个 PRD"）
-- 用户安装了 `agency-agents-zh` 并希望直接在 AI 工具内编排多角色
-
-## 执行流程（5 步）
-
-按以下顺序执行，不要跳步：
-
-### 第 1 步：解析工作流
-
-用 Read 工具读取用户指定的 YAML 文件，提取以下字段：
-
-```yaml
-name: "工作流名称"
-agents_dir: "agency-agents-zh"    # 角色定义目录
-inputs:                            # 输入变量
-  - name: xxx
-    required: true/false
-    default: "默认值"
-steps:                             # 执行步骤
-  - id: step_id
-    role: "category/agent-name"    # 角色路径
-    task: "任务描述 {{变量}}"       # 支持模板变量
-    output: variable_name          # 输出变量名
-    depends_on: [other_step_id]    # 依赖关系
-```
-
-**忽略 `llm`、`concurrency`、`timeout`、`retry` 配置**——Skill 模式使用当前会话的 LLM，这些字段仅用于 CLI 模式。
-
-**定位角色目录**：用 Bash `test -d` 按以下顺序检查，用第一个存在的：
-1. 当前工作目录下的 `{agents_dir}/`（如 `./agency-agents-zh/`）
-2. `../{agents_dir}/`（上级目录）
-3. 相对于 YAML 文件所在目录的 `{agents_dir}/`
-4. `node_modules/agency-agents-zh/`
-
-如果全部找不到，**停止执行**并提示用户：
-```
-找不到角色目录。请先安装：
-  git clone --depth 1 https://github.com/jnMetaCode/agency-agents-zh.git
-  或：npm install agency-agents-zh
-```
-
-### 第 2 步：收集输入
-
-- 对每个 `required: true` 的输入，检查用户消息中是否已提供值
-- 未提供的必填输入：**立即向用户询问**，不要猜测或用空值
-- 有 `default` 的可选输入：使用默认值
-- 无默认值的可选输入：设为空字符串
-
-### 第 3 步：构建执行顺序
-
-根据 `depends_on` 进行拓扑排序，将步骤分成多个层级：
-
-- **无 depends_on 的步骤** → 第 1 层
-- **depends_on 全部在第 N 层或之前的步骤** → 第 N+1 层
-- **同一层内的步骤**互不依赖，可并行
-
-在回复中展示执行计划：
-```
-执行计划（共 N 步）：
-  第 1 层: [step_id] — 角色名
-  第 2 层: [step_a, step_b] — 并行
-  第 3 层: [step_id] — 角色名
-```
-
-### 第 4 步：逐层执行
-
-对每一层：
-
-#### 4a. 预读角色文件
-
-用 Read 工具读取该层所有步骤的角色 `.md` 文件：`{角色目录}/{role}.md`
-
-从文件中提取：
-- **角色名**：frontmatter 中的 `name` 字段
-- **角色 system prompt**：第二个 `---` 之后的全部 markdown 内容
-
-#### 4b. 渲染 task 模板
-
-将 task 中的 `{{变量名}}` 替换为：
-- 来自 inputs 的用户输入值
-- 来自前序步骤 output 的结果文本
-
-#### 4c. 执行
-
-**单步骤层**：直接在主会话中扮演该角色执行。格式：
-
-```
-### Step N/Total: step_id（角色名）
-
-[以该角色身份完成 task，使用角色的专业知识和沟通风格]
-```
-
-**多步骤层（并行）**：使用 Agent 工具为每个步骤启动子代理。每个子代理的 prompt 必须包含：
-- 角色文件的**完整文本内容**（不是路径——子代理可能无法读文件）
-- 渲染后的 task 文本
-- 指令："以上是你的角色定义，请以该角色身份完成以下任务，直接输出结果"
-
-#### 4d. 保存输出到上下文
-
-如果 step 有 `output` 字段，将该步骤的输出文本存入变量上下文，供后续步骤的 `{{变量}}` 使用。
-
-### 第 5 步：保存结果并展示
-
-用 Write 工具将结果保存到文件：
-
-```
-.ao-output/{工作流名称}-{YYYY-MM-DD}/
-├── steps/
-│   ├── 1-{step_id}.md       # 每步的输出
-│   ├── 2-{step_id}.md
-│   └── ...
-├── summary.md                # 最后一步的完整输出（最终成果）
-└── metadata.json             # 基本元数据
-```
-
-metadata.json 格式：
-```json
-{
-  "name": "工作流名称",
-  "date": "2026-03-22",
-  "success": true,
-  "steps": [
-    {"id": "step_id", "role": "category/agent", "status": "completed"},
-    ...
-  ]
-}
-```
-
-执行完毕后，向用户展示：
-1. 最终成果（summary.md 的内容）
-2. 文件保存位置
-3. 执行了几个步骤
-
-## 重要规则
-
-<HARD-GATE>
-- 每个步骤都必须真正扮演对应角色，使用该角色的专业知识和沟通风格，不能泛泛回答
-- 角色切换必须明确——每步开始时标注角色名
-- 不要跳过步骤或合并步骤，严格按 DAG 层级顺序执行
-- 如果角色文件找不到，告知用户并建议安装 agency-agents-zh
-- 不要在没有读取角色 .md 文件的情况下执行步骤——必须先 Read 再执行
-</HARD-GATE>
-
-## 没有 YAML 文件时的快捷模式
-
-如果用户没有指定 YAML 文件，但描述了需要多角色协作的任务：
-
-1. 根据用户描述，**自动生成** YAML 工作流定义
-2. 展示给用户确认
-3. 确认后按上述流程执行
-
-示例：
-- 用户说"帮我用叙事学家和心理学家写个故事" → 生成 story-creation 类似的工作流
-- 用户说"让产品经理和架构师评审这个 PRD" → 生成 product-review 类似的工作流
-
-## 故障处理
-
-- **角色文件不存在**：提示用户运行 `ao init` 或 `npm install agency-agents-zh`
-- **模板变量未定义**：检查上下文，如果是必填输入则向用户询问
-- **步骤执行失败**：标记该步骤为失败，跳过所有依赖它的下游步骤，继续执行其他独立步骤

package/skills/writing-plans/SKILL.md

@@ -1,152 +0,0 @@
----
-name: writing-plans
-description: 当你有规格说明或需求用于多步骤任务时使用，在动手写代码之前
----
-
-# 编写计划
-
-## 概述
-
-编写全面的实现计划，假设工程师对我们的代码库零上下文，且品味存疑。记录他们需要知道的一切：每个任务要修改哪些文件、代码、测试、可能需要查阅的文档、如何测试。将整个计划拆成小步骤任务。DRY。YAGNI。TDD。频繁 commit。
-
-假设他们是有经验的开发者，但对我们的工具链和问题领域几乎一无所知。假设他们不太擅长测试设计。
-
-**开始时宣布：** "我正在使用 writing-plans 技能创建实现计划。"
-
-**上下文：** 此技能应在专用 worktree 中运行（由 brainstorming 技能创建）。
-
-**计划保存位置：** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`
-- （用户对计划位置的偏好优先于此默认值）
-
-## 范围检查
-
-如果规格涵盖了多个独立子系统，它应该在头脑风暴阶段就被拆分为子项目规格。如果没有，建议将其拆分为独立的计划——每个子系统一个。每个计划应该能独立产出可工作、可测试的软件。
-
-## 文件结构
-
-在定义任务之前，先列出将要创建或修改的文件以及每个文件的职责。这是锁定分解决策的地方。
-
-- 设计边界清晰、接口定义良好的单元。每个文件应有一个明确的职责。
-- 你对能一次放入上下文的代码推理得最好，文件越专注你的编辑越可靠。优先选择小而专注的文件，而非承担过多功能的大文件。
-- 一起变更的文件应放在一起。按职责拆分，而非按技术层级拆分。
-- 在现有代码库中，遵循已有模式。如果代码库使用大文件，不要单方面重构——但如果你正在修改的文件已经变得难以管理，在计划中包含拆分是合理的。
-
-此结构决定了任务分解。每个任务应产出独立的、有意义的变更。
-
-## 小步骤任务粒度
-
-**每步是一个操作（2-5 分钟）：**
-- "编写失败的测试" - 一步
-- "运行它确认失败" - 一步
-- "实现最少代码让测试通过" - 一步
-- "运行测试确认通过" - 一步
-- "Commit" - 一步
-
-## 计划文档头部
-
-**每个计划必须以此头部开始：**
-
-```markdown
-# [功能名称] 实现计划
-
-> **面向 AI 代理的工作者：** 必需子技能：使用 superpowers:subagent-driven-development（推荐）或 superpowers:executing-plans 逐任务实现此计划。步骤使用复选框（`- [ ]`）语法来跟踪进度。
-
-**目标：** [一句话描述要构建什么]
-
-**架构：** [2-3 句话描述方案]
-
-**技术栈：** [关键技术/库]
-
----
-```
-
-## 任务结构
-
-````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`
-预期：FAIL，报错 "function not defined"
-
-- [ ] **步骤 3：编写最少实现代码**
-
-```python
-def function(input):
-    return expected
-```
-
-- [ ] **步骤 4：运行测试验证通过**
-
-运行：`pytest tests/path/test.py::test_name -v`
-预期：PASS
-
-- [ ] **步骤 5：Commit**
-
-```bash
-git add tests/path/test.py src/path/file.py
-git commit -m "feat: add specific feature"
-```
-````
-
-## 禁止占位符
-
-每个步骤都必须包含工程师需要的实际内容。以下是**计划缺陷**——绝不要写出来：
-- "待定"、"TODO"、"后续实现"、"补充细节"
-- "添加适当的错误处理" / "添加验证" / "处理边界情况"
-- "为上述代码编写测试"（没有实际测试代码）
-- "类似任务 N"（重复代码——工程师可能不按顺序阅读任务）
-- 只描述做什么而不展示怎么做的步骤（代码步骤必须有代码块）
-- 引用了未在任何任务中定义的类型、函数或方法
-
-## 注意事项
-- 始终使用精确的文件路径
-- 每个步骤都包含完整代码——如果步骤涉及代码变更，就展示代码
-- 精确的命令和预期输出
-- DRY、YAGNI、TDD、频繁 commit
-
-## 自检
-
-编写完整计划后，以全新视角审视规格并对照检查计划。这是你自己执行的检查清单——不是子代理调度。
-
-**1. 规格覆盖度：** 浏览规格中的每个章节/需求。你能指出实现它的任务吗？列出所有遗漏。
-
-**2. 占位符扫描：** 搜索计划中的红旗——上方"禁止占位符"章节中的任何模式。修复它们。
-
-**3. 类型一致性：** 后续任务中使用的类型、方法签名和属性名是否与前面任务中定义的一致？任务 3 中叫 `clearLayers()` 但任务 7 中叫 `clearFullLayers()` 就是 bug。
-
-如果发现问题，直接内联修复。无需重新审查——修好继续推进。如果发现规格中的需求没有对应任务，就添加任务。
-
-## 执行交接
-
-保存计划后，提供执行选项：
-
-**"计划已完成并保存到 `docs/superpowers/plans/<filename>.md`。两种执行方式：**
-
-**1. 子代理驱动（推荐）** - 每个任务调度一个新的子代理，任务间进行审查，快速迭代
-
-**2. 内联执行** - 在当前会话中使用 executing-plans 执行任务，批量执行并设有检查点
-
-**选哪种方式？"**
-
-**如果选择子代理驱动：**
-- **必需子技能：** 使用 superpowers:subagent-driven-development
-- 每个任务一个新子代理 + 两阶段审查
-
-**如果选择内联执行：**
-- **必需子技能：** 使用 superpowers:executing-plans
-- 批量执行并设有检查点供审查

package/skills/writing-plans/plan-document-reviewer-prompt.md

@@ -1,49 +0,0 @@
-# 计划文档审查员提示模板
-
-调度计划文档审查员子代理时使用此模板。
-
-**用途：** 验证计划是否完整、与规格匹配，并且任务分解合理。
-
-**调度时机：** 完整计划编写完成后。
-
-```
-Task tool（通用）:
-  description: "审查计划文档"
-  prompt: |
-    你是一名计划文档审查员。验证此计划是否完整并准备好进行实现。
-
-    **待审查计划：** [PLAN_FILE_PATH]
-    **参考规格：** [SPEC_FILE_PATH]
-
-    ## 检查内容
-
-    | 类别 | 检查要点 |
-    |------|----------|
-    | 完整性 | TODO、占位符、不完整的任务、缺失的步骤 |
-    | 规格对齐 | 计划覆盖了规格需求，没有重大范围蔓延 |
-    | 任务分解 | 任务有清晰的边界，步骤可执行 |
-    | 可构建性 | 工程师能否按此计划执行而不会卡住？ |
-
-    ## 校准标准
-
-    **只标记会在实现阶段造成实际问题的事项。**
-    实现者构建了错误的东西或卡住了——这是问题。
-    措辞上的小改进、风格偏好和"锦上添花"的建议则不是。
-
-    除非存在严重缺陷——规格中的需求遗漏、
-    矛盾的步骤、占位内容、或者模糊到无法执行的任务——否则应予以通过。
-
-    ## 输出格式
-
-    ## 计划审查
-
-    **状态：** 通过 | 发现问题
-
-    **问题（如有）：**
-    - [任务 X，步骤 Y]：[具体问题] - [为什么这对实现很重要]
-
-    **建议（仅供参考，不阻止通过）：**
-    - [改进建议]
-```
-
-**审查员返回：** 状态、问题（如有）、建议