sdd-full 1.0.0 → 1.2.0

package/skills/unified-flow/SKILL.md

@@ -0,0 +1,146 @@
+
+---
+name: unified-flow
+description: "综合开发流程 - 提供4个流程选项：从零开始新项目、小型功能迭代、Bug处理、代码发布"
+---
+
+# 综合开发流程
+
+<TRIGGER-WORDS>
+- 从零开始新项目
+- 我现在要做新项目
+- 新项目启动
+- 从零开始
+- 创建新项目
+- 我现在要做小型功能迭代
+- 功能迭代
+- 小型迭代
+- 快速迭代
+- 新增小功能
+- 我现在要处理Bug
+- 处理Bug
+- 修复Bug
+- Bug修复
+- 调试Bug
+- 我现在要发布代码
+- 发布代码
+- 代码发布
+- 部署上线
+- 发布上线
+- 启动开发流程
+- 开始开发
+</TRIGGER-WORDS>
+
+## 🎯 流程选项
+
+请选择您要使用的流程：
+
+```
+1. 从零开始新项目
+2. 小型功能迭代
+3. Bug处理
+4. 代码发布
+```
+
+---
+
+## 1. 从零开始新项目
+
+```
+1. 市场调研/头脑风暴（可选，如需要创意/调研）
+   ↓
+2. PRD编写（可选，写PRD）
+   ↓
+3. 需求补全（可选，requirement-completion-officer）
+   ↓
+4. SDD拆分（sdd/sdd-full）
+   ↓
+5. UI设计（可选，ui-sdd）
+   ↓
+6. 实现拆分（sdd-code，含代码规范、技术债务、重构计划）
+   ↓
+7. 测试设计（sdd-test）
+   ↓
+8. 部署设计（可选，sdd-deploy）
+   ↓
+9. 制定计划（可选，writing-plans）
+   ↓
+10. 开始开发（可选，test-driven-development）
+```
+
+---
+
+## 2. 小型功能迭代
+
+```
+1. 需求补全（可选，requirement-completion-officer）
+   ↓
+2. 制定计划（可选，writing-plans）
+   ↓
+3. sdd-add快速处理
+   ↓
+4. 如果涉及UI/复杂逻辑，补充调用 ui-sdd/sdd-code
+   ↓
+5. verification-before-completion验证
+   ↓
+6. quality-gate质量检查
+   ↓
+7. finishing-a-development-branch完成分支（可选）
+   ↓
+8. 简单发布
+```
+
+---
+
+## 3. Bug处理
+
+```
+1. systematic-debugging调试
+   ↓
+2. sdd-add修复
+   ↓
+3. verification-before-completion验证
+   ↓
+4. quality-gate质量检查
+   ↓
+5. claudeception经验沉淀
+```
+
+---
+
+## 4. 代码发布
+
+```
+1. verification-before-completion验证
+   ↓
+2. quality-gate质量检查
+   ↓
+3. finishing-a-development-branch完成分支（可选）
+   ↓
+4. sdd-deploy部署设计（可选）
+   ↓
+5. release-flow发布管理
+```
+
+---
+
+## ✅ 开始流程
+
+### 第一步：询问用户选择
+
+首先询问用户：
+```
+综合开发流程已启动！
+请选择您要使用的流程：
+1. 从零开始新项目
+2. 小型功能迭代
+3. Bug处理
+4. 代码发布
+
+请输入选项编号（1-4）：
+```
+
+### 第二步：按选择的流程执行
+
+根据用户选择，执行对应的流程步骤。
+

package/skills/using-superpowers/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: using-superpowers
+description: 当开始任何对话时使用 - 建立如何查找和使用技能的方法，要求在包括澄清问题在内的任何响应之前调用Skill工具
+---
+
+<SUBAGENT-STOP>
+如果您被派作为子代理执行特定任务，请跳过此技能。
+</SUBAGENT-STOP>
+
+<EXTREMELY-IMPORTANT>
+如果您认为技能可能适用于您正在做的事情的可能性甚至为1%，您绝对必须调用该技能。
+
+如果技能适用于您的任务，您没有选择。您必须使用它。
+
+这是不可协商的。这不是可选的。您不能通过理性思考来逃避这一点。
+</EXTREMELY-IMPORTANT>
+
+## 指令优先级
+
+Superpowers技能会覆盖默认的系统提示行为，但**用户指令始终优先**：
+
+1. **用户的明确指令**（CLAUDE.md、GEMINI.md、AGENTS.md、直接请求）— 最高优先级
+2. **Superpowers技能** — 在冲突时覆盖默认系统行为
+3. **默认系统提示** — 最低优先级
+
+如果CLAUDE.md、GEMINI.md或AGENTS.md说"不要使用TDD"，而技能说"始终使用TDD"，请遵循用户的指令。用户是控制者。
+
+## 如何访问技能
+
+**在Claude Code中：** 使用`Skill`工具。当您调用技能时，其内容会加载并呈现给您——直接遵循它。永远不要在技能文件上使用Read工具。
+
+**在Gemini CLI中：** 技能通过`activate_skill`工具激活。Gemini在会话开始时加载技能元数据，并根据需要激活完整内容。
+
+**在其他环境中：** 查看您平台的文档，了解如何加载技能。
+
+## 平台适应
+
+技能使用Claude Code工具名称。非CC平台：请参阅`references/codex-tools.md`（Codex）了解工具等效项。Gemini CLI用户通过GEMINI.md自动加载工具映射。
+
+# 使用技能
+
+## 规则
+
+**在任何响应或操作之前调用相关或请求的技能。** 即使技能可能适用的可能性为1%，也意味着您应该调用技能进行检查。如果调用的技能结果证明不适合该情况，您不需要使用它。
+
+```dot
+digraph skill_flow {
+    "收到用户消息" [shape=doublecircle];
+    "即将进入计划模式？" [shape=doublecircle];
+    "已经进行头脑风暴？" [shape=diamond];
+    "调用头脑风暴技能" [shape=box];
+    "可能适用任何技能？" [shape=diamond];
+    "调用Skill工具" [shape=box];
+    "宣布：'使用[技能]进行[目的]'" [shape=box];
+    "有清单？" [shape=diamond];
+    "为每个项目创建TodoWrite待办事项" [shape=box];
+    "严格遵循技能" [shape=box];
+    "响应（包括澄清）" [shape=doublecircle];
+
+    "即将进入计划模式？" -> "已经进行头脑风暴？";
+    "已经进行头脑风暴？" -> "调用头脑风暴技能" [label="否"];
+    "已经进行头脑风暴？" -> "可能适用任何技能？" [label="是"];
+    "调用头脑风暴技能" -> "可能适用任何技能？";
+
+    "收到用户消息" -> "可能适用任何技能？";
+    "可能适用任何技能？" -> "调用Skill工具" [label="是，即使1%"];
+    "可能适用任何技能？" -> "响应（包括澄清）" [label="绝对不"];
+    "调用Skill工具" -> "宣布：'使用[技能]进行[目的]'";
+    "宣布：'使用[技能]进行[目的]'" -> "有清单？";
+    "有清单？" -> "为每个项目创建TodoWrite待办事项" [label="是"];
+    "有清单？" -> "严格遵循技能" [label="否"];
+    "为每个项目创建TodoWrite待办事项" -> "严格遵循技能";
+}
+```
+
+## 红旗
+
+这些想法意味着停止——您在合理化：
+
+| 想法 | 现实 |
+|------|------|
+| "这只是一个简单的问题" | 问题是任务。检查技能。 |
+| "我需要先了解更多上下文" | 技能检查在澄清问题之前进行。 |
+| "让我先探索代码库" | 技能告诉您如何探索。先检查。 |
+| "我可以快速检查git/文件" | 文件缺乏对话上下文。检查技能。 |
+| "让我先收集信息" | 技能告诉您如何收集信息。 |
+| "这不需要正式技能" | 如果技能存在，使用它。 |
+| "我记得这个技能" | 技能会演变。阅读当前版本。 |
+| "这不算任务" | 行动=任务。检查技能。 |
+| "技能过度了" | 简单的事情会变得复杂。使用它。 |
+| "我先做这件事" | 在做任何事情之前检查。 |
+| "这感觉很有成效" | 无纪律的行动浪费时间。技能可以防止这种情况。 |
+| "我知道那是什么意思" | 知道概念≠使用技能。调用它。 |
+
+## 技能优先级
+
+当多个技能可能适用时，使用此顺序：
+
+1. **首先是流程技能**（头脑风暴、调试）- 这些决定如何处理任务
+2. **其次是实现技能**（前端设计、mcp-builder）- 这些指导执行
+
+"让我们构建X" → 先头脑风暴，然后是实现技能。
+"修复这个错误" → 先调试，然后是领域特定技能。
+
+## 技能类型
+
+**严格**（TDD、调试）：严格遵循。不要放弃纪律。
+
+**灵活**（模式）：根据上下文调整原则。
+
+技能本身会告诉您是哪一种。
+
+## 用户指令
+
+指令说明做什么，而不是怎么做。"添加X"或"修复Y"并不意味着跳过工作流程。

package/skills/verification-before-completion/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: verification-before-completion
+description: 在声称工作完成、修复或通过之前使用，在提交或创建 PR 之前 - 需要运行验证命令并在做出任何成功声明之前确认输出；始终证据先于断言
+---
+
+# 完成前验证
+
+## 概述
+
+在没有验证的情况下声称工作完成是不诚实，不是效率。
+
+**核心原则：** 始终证据先于声明。
+
+**违反此规则的字面意思就是违反此规则的精神。**
+
+## 铁律
+
+```
+没有新鲜的验证证据，就没有完成声明
+```
+
+如果你没有在这条消息中运行验证命令，你不能声称它通过。
+
+## 门控函数
+
+```
+在声称任何状态或表达满意之前：
+
+1. 识别：什么命令证明这个声明？
+2. 运行：执行完整命令（新鲜，完整）
+3. 阅读：完整输出，检查退出代码，计数失败
+4. 验证：输出是否确认声明？
+   - 如果否：用证据说明实际状态
+   - 如果是：用证据说明声明
+5. 只有这样：做出声明
+
+跳过任何步骤 = 说谎，不是验证
+```
+
+## 常见失败
+
+| 声明 | 需要 | 不足够 |
+|------|------|--------|
+| 测试通过 | 测试命令输出：0 失败 | 之前的运行，"应该通过" |
+| 代码检查干净 | 代码检查输出：0 错误 | 部分检查，推断 |
+| 构建成功 | 构建命令：退出 0 | 代码检查通过，日志看起来不错 |
+| 错误已修复 | 测试原始症状：通过 | 代码已更改，假设已修复 |
+| 回归测试有效 | 红-绿循环已验证 | 测试通过一次 |
+| 代理完成 | VCS diff 显示更改 | 代理报告"成功" |
+| 满足要求 | 逐行检查清单 | 测试通过 |
+
+## 红旗 - 停止
+
+- 使用"应该"、"可能"、"似乎"
+- 在验证前表达满意（"太好了！"、"完美！"、"完成！"等）
+- 在没有验证的情况下即将提交/推送/PR
+- 信任代理成功报告
+- 依赖部分验证
+- 想"就这一次"
+- 疲倦并希望工作结束
+- **任何暗示成功但未运行验证的措辞**
+
+## 防止合理化
+
+| 借口 | 现实 |
+|------|------|
+| "现在应该工作" | 运行验证 |
+| "我有信心" | 信心 ≠ 证据 |
+| "就这一次" | 无例外 |
+| "代码检查通过" | 代码检查 ≠ 编译器 |
+| "代理说成功" | 独立验证 |
+| "我累了" | 疲惫 ≠ 借口 |
+| "部分检查足够" | 部分证明不了什么 |
+| "不同的词，所以规则不适用" | 精神胜于字面 |
+
+## 关键模式
+
+**测试：**
+```
+✅ [运行测试命令] [见：34/34 通过] "所有测试通过"
+❌ "现在应该通过" / "看起来正确"
+```
+
+**回归测试（TDD 红-绿）：**
+```
+✅ 编写 → 运行（通过）→ 恢复修复 → 运行（必须失败）→ 恢复 → 运行（通过）
+❌ "我已经编写了回归测试"（没有红-绿验证）
+```
+
+**构建：**
+```
+✅ [运行构建] [见：退出 0] "构建通过"
+❌ "代码检查通过"（代码检查不检查编译）
+```
+
+**要求：**
+```
+✅ 重新阅读计划 → 创建检查清单 → 验证每个 → 报告差距或完成
+❌ "测试通过，阶段完成"
+```
+
+**代理委托：**
+```
+✅ 代理报告成功 → 检查 VCS diff → 验证更改 → 报告实际状态
+❌ 信任代理报告
+```
+
+## 为什么这很重要
+
+来自 24 个失败记忆：
+- 你的人类伙伴说"我不相信你" - 信任破裂
+- 未定义函数被发布 - 会崩溃
+- 缺少要求被发布 - 功能不完整
+- 时间浪费在错误的完成上 → 重定向 → 返工
+- 违反："诚实是核心价值观。如果你撒谎，你将被替换。"
+
+## 何时应用
+
+**始终在之前：**
+- 任何成功/完成声明的变体
+- 任何满意的表达
+- 任何关于工作状态的积极陈述
+- 提交、PR 创建、任务完成
+- 移动到下一个任务
+- 委托给代理
+
+**规则适用于：**
+- 确切短语
+- 释义和同义词
+- 成功的暗示
+- 任何暗示完成/正确性的沟通
+
+## 底线
+
+**验证没有捷径。**
+
+运行命令。阅读输出。然后声明结果。
+
+这是不可协商的。

package/skills/writing-plans/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: writing-plans
+description: 当你有规范或多步骤任务的需求时，在接触代码前使用
+---
+
+# 编写计划
+
+## 概述
+
+编写全面的实现计划，假设工程师对我们的代码库没有任何上下文，并且品味可疑。记录他们需要知道的一切：每个任务需要修改哪些文件、代码、测试、他们可能需要检查的文档、如何测试。将整个计划分解为 bite-sized 任务。DRY（不要重复自己）、YAGNI（你不会需要它）、TDD（测试驱动开发）、频繁提交。
+
+假设他们是熟练的开发人员，但对我们的工具集或问题域几乎一无所知。假设他们不太了解良好的测试设计。
+
+**开始时宣布：** "我正在使用 writing-plans 技能创建实现计划。"
+
+**上下文：** 这应该在专用的工作树中运行（由 brainstorming 技能创建）。
+
+**保存计划到：** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`
+- （用户对计划位置的偏好覆盖此默认值）
+
+## 范围检查
+
+如果规范涵盖多个独立子系统，在头脑风暴期间应该已经分解为子项目规范。如果没有，建议将其分解为单独的计划 - 每个子系统一个。每个计划都应该独立产生可工作、可测试的软件。
+
+## 文件结构
+
+在定义任务之前，映射出将创建或修改哪些文件以及每个文件的职责。这是分解决策被锁定的地方。
+
+- 设计具有明确边界和定义良好接口的单元。每个文件应该有一个明确的职责。
+- 你对能一次保持在上下文中的代码推理得最好，当文件集中时，你的编辑更可靠。优先选择较小、集中的文件，而不是做太多事情的大文件。
+- 一起更改的文件应该放在一起。按职责划分，而不是按技术层划分。
+- 在现有代码库中，遵循已建立的模式。如果代码库使用大文件，不要单方面重构 - 但如果你正在修改的文件变得难以管理，在计划中包含拆分是合理的。
+
+这种结构为任务分解提供信息。每个任务应该产生独立有意义的自包含更改。
+
+## Bite-Sized 任务粒度
+
+**每个步骤是一个动作（2-5分钟）：**
+- "编写失败的测试" - 步骤
+- "运行它以确保它失败" - 步骤
+- "实现最小代码以使测试通过" - 步骤
+- "运行测试并确保它们通过" - 步骤
+- "提交" - 步骤
+
+## 计划文档标题
+
+**每个计划必须以以下标题开始：**
+
+```markdown
+# [功能名称] 实现计划
+
+> **对于代理工作者：** 必需：使用 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`
+预期：失败，提示 "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: add specific feature"
+```
+````
+
+## 记住
+- 始终使用精确的文件路径
+- 计划中包含完整的代码（不是 "添加验证"）
+- 带有预期输出的精确命令
+- 使用 @ 语法引用相关技能
+- DRY、YAGNI、TDD、频繁提交
+
+## 计划审查循环
+
+编写完整计划后：
+
+1. 调度单个 plan-document-reviewer 子代理（参见 plan-document-reviewer-prompt.md），使用精心设计的审查上下文 - 绝不是你的会话历史。这使审查者专注于计划，而不是你的思考过程。
+   - 提供：计划文档路径，规范文档路径
+2. 如果 ❌ 发现问题：修复问题，重新调度审查者审查整个计划
+3. 如果 ✅ 批准：继续执行交接
+
+**审查循环指导：**
+- 编写计划的同一代理修复它（保留上下文）
+- 如果循环超过3次迭代，提交给人类指导
+- 审查者是顾问 - 如果你认为反馈不正确，解释分歧
+
+## 执行交接
+
+保存计划后：
+
+**"计划完成并保存到 `docs/superpowers/plans/<filename>.md`。准备执行？"**
+
+**执行路径取决于 harness 能力：**
+
+**如果 harness 有子代理（Claude Code 等）：**
+- **必需：** 使用 superpowers:subagent-driven-development
+- 不要提供选择 - 子代理驱动是标准方法
+- 每个任务使用新的子代理 + 两阶段审查
+
+**如果 harness 没有子代理：**
+- 在当前会话中使用 superpowers:executing-plans 执行计划
+- 批处理执行，带有审查检查点