sdd-full 1.0.0

package/README.md

@@ -0,0 +1,49 @@
+# sdd-full
+
+一键生成标准技能，自动适配 Trae-CN 和 Claude Code。
+
+## 安装使用
+
+在任意项目根目录执行：
+
+```bash
+npx sdd-full
+```
+
+## 包含技能
+
+- brainstorming
+- claudeception
+- competitive-brief
+- finishing-a-development-branch
+- market-research
+- mempalace-auto-saver
+- prd-write
+- quality-gate
+- receiving-code-review
+- release-flow
+- requesting-code-review
+- requirement-completion-officer
+- sdd
+- sdd-add
+- sdd-code
+- sdd-deploy
+- sdd-full
+- sdd-ops
+- sdd-test
+- security-audit
+- systematic-debugging
+- test-driven-development
+- ui-sdd
+- using-superpowers
+- verification-before-completion
+- writing-plans
+
+## 生成目录
+
+- `.trae/skills` - 适配 Trae-CN
+- `.claude/skills` - 适配 Claude Code
+
+## License
+
+MIT

package/index.js

@@ -0,0 +1,38 @@
+#!/usr/bin/env node
+const fs = require('fs');
+const path = require('path');
+const skillsData = require('./skills-data.js');
+
+const cwd = process.cwd();
+
+const targets = [
+  { name: 'Trae-CN', base: '.trae/skills' },
+  { name: 'Claude-Code', base: '.claude/skills' }
+];
+
+console.log('📦 Generating skills...');
+
+targets.forEach(({ name, base }) => {
+  const root = path.join(cwd, base);
+  console.log(`\n📂 Generating ${name} skills: ${base}`);
+
+  if (!fs.existsSync(root)) {
+    fs.mkdirSync(root, { recursive: true });
+  }
+
+  skillsData.forEach(skill => {
+    const skillDir = path.join(root, skill.name);
+    const mdPath = path.join(skillDir, 'SKILL.md');
+
+    if (!fs.existsSync(skillDir)) {
+      fs.mkdirSync(skillDir, { recursive: true });
+    }
+
+    fs.writeFileSync(mdPath, skill.content, 'utf8');
+    console.log(`✅ ${base}/${skill.name}/SKILL.md`);
+  });
+});
+
+console.log(`\n🎉 Successfully generated ${skillsData.length} skills!`);
+console.log('👉 Generated in:');
+targets.forEach(t => console.log(`   - ${t.base}`));

package/package.json

@@ -0,0 +1,20 @@
+{
+  "name": "sdd-full",
+  "version": "1.0.0",
+  "description": "一键生成标准技能，自动适配 Trae-CN 和 Claude Code",
+  "main": "index.js",
+  "bin": {
+    "sdd-full": "./index.js"
+  },
+  "files": [
+    "index.js",
+    "skills-data.js"
+  ],
+  "author": "",
+  "license": "MIT",
+  "keywords": [
+    "skills",
+    "trae",
+    "claude-code"
+  ]
+}

package/skills-data.js

@@ -0,0 +1,107 @@
+// 技能数据，自动生成
+module.exports = [
+  {
+    "name": "brainstorming",
+    "content": "---\nname: brainstorming\ndescription: \"在任何创意工作之前必须使用此技能 - 创建功能、构建组件、添加功能或修改行为。在实现之前探索用户意图、需求和设计。\"\n---\n\n# 头脑风暴：将想法转化为设计\n\n通过自然的协作对话，帮助将想法转化为完整的设计和规范。\n\n首先了解当前项目上下文，然后一次一个问题地完善想法。一旦理解了要构建的内容，就展示设计并获得用户批准。\n\n<HARD-GATE>\n在展示设计并获得用户批准之前，不要调用任何实现技能、编写任何代码、搭建任何项目或采取任何实现行动。这适用于所有项目，无论其看似多么简单。\n</HARD-GATE>\n\n## 反模式：\"这太简单了，不需要设计\"\n\n每个项目都需要经过这个过程。待办事项列表、单个功能实用程序、配置更改 - 所有这些都需要。\"简单\"项目是未经检验的假设导致最多浪费工作的地方。设计可以很短（对于真正简单的项目，几句话就够了），但你必须展示它并获得批准。\n\n## 检查清单\n\n你必须为以下每个项目创建任务并按顺序完成：\n\n1. **探索项目上下文** - 检查文件、文档、最近的提交\n2. **提供视觉 companion**（如果主题涉及视觉问题）- 这是单独的消息，不与澄清问题结合。请参阅下面的视觉 companion 部分。\n3. **提出澄清问题** - 一次一个，了解目的/约束/成功标准\n4. **提出2-3种方法** - 带有权衡和你的建议\n5. **展示设计** - 按复杂度分部分展示，每部分后获得用户批准\n6. **编写设计文档** - 保存到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并提交\n7. **规范审查循环** - 调度 spec-document-reviewer 子代理，使用精心设计的审查上下文（绝不是你的会话历史）；修复问题并重新调度，直到获得批准（最多3次迭代，然后提交给人类）\n8. **用户审查书面规范** - 请用户在继续之前审查规范文件\n9. **过渡到实现** - 调用 writing-plans 技能创建实现计划\n\n## 流程\n\n```dot\ndigraph brainstorming {\n    \"探索项目上下文\" [shape=box];\n    \"前方有视觉问题？\" [shape=diamond];\n    \"提供视觉 Companion\\n(单独消息，无其他内容)\" [shape=box];\n    \"提出澄清问题\" [shape=box];\n    \"提出2-3种方法\" [shape=box];\n    \"展示设计部分\" [shape=box];\n    \"用户批准设计？\" [shape=diamond];\n    \"编写设计文档\" [shape=box];\n    \"规范审查循环\" [shape=box];\n    \"规范审查通过？\" [shape=diamond];\n    \"用户审查规范？\" [shape=diamond];\n    \"调用 writing-plans 技能\" [shape=doublecircle];\n\n    \"探索项目上下文\" -> \"前方有视觉问题？\";\n    \"前方有视觉问题？\" -> \"提供视觉 Companion\\n(单独消息，无其他内容)\" [label=\"是\"];\n    \"前方有视觉问题？\" -> \"提出澄清问题\" [label=\"否\"];\n    \"提供视觉 Companion\\n(单独消息，无其他内容)\" -> \"提出澄清问题\";\n    \"提出澄清问题\" -> \"提出2-3种方法\";\n    \"提出2-3种方法\" -> \"展示设计部分\";\n    \"展示设计部分\" -> \"用户批准设计？\";\n    \"用户批准设计？\" -> \"展示设计部分\" [label=\"否，修改\"];\n    \"用户批准设计？\" -> \"编写设计文档\" [label=\"是\"];\n    \"编写设计文档\" -> \"规范审查循环\";\n    \"规范审查循环\" -> \"规范审查通过？\";\n    \"规范审查通过？\" -> \"规范审查循环\" [label=\"发现问题，\\n修复并重新调度\"];\n    \"规范审查通过？\" -> \"用户审查规范？\" [label=\"已批准\"];\n    \"用户审查规范？\" -> \"编写设计文档\" [label=\"要求更改\"];\n    \"用户审查规范？\" -> \"调用 writing-plans 技能\" [label=\"已批准\"];\n}\n```\n\n**最终状态是调用 writing-plans。** 不要调用 frontend-design、mcp-builder 或任何其他实现技能。头脑风暴后你唯一应该调用的技能是 writing-plans。\n\n## 流程说明\n\n**理解想法：**\n\n- 首先检查当前项目状态（文件、文档、最近的提交）\n- 在提出详细问题之前，评估范围：如果请求描述了多个独立子系统（例如，\"构建一个包含聊天、文件存储、计费和分析的平台\"），立即标记这一点。不要在需要先分解的项目上花费时间完善细节。\n- 如果项目太大，无法用单个规范覆盖，帮助用户分解为子项目：独立部分是什么，它们如何关联，应该按什么顺序构建？然后通过正常的设计流程对第一个子项目进行头脑风暴。每个子项目都有自己的规范 → 计划 → 实现周期。\n- 对于范围适当的项目，一次一个问题地完善想法\n- 尽可能使用多项选择题，但开放式问题也可以\n- 每条消息只提一个问题 - 如果一个主题需要更多探索，将其分解为多个问题\n- 关注理解：目的、约束、成功标准\n\n**探索方法：**\n\n- 提出2-3种不同的方法，包括权衡\n- 以对话方式展示选项，包括你的建议和理由\n- 先提出你推荐的选项并解释原因\n\n**展示设计：**\n\n- 一旦你认为理解了要构建的内容，就展示设计\n- 根据复杂度调整每个部分：如果简单，几句话就够了；如果复杂，最多200-300字\n- 每部分后询问是否看起来正确\n- 涵盖：架构、组件、数据流、错误处理、测试\n- 准备在有不明白的地方回头澄清\n\n**设计隔离和清晰度：**\n\n- 将系统分解为更小的单元，每个单元有一个明确的目的，通过定义良好的接口进行通信，并且可以独立理解和测试\n- 对于每个单元，你应该能够回答：它做什么，如何使用它，它依赖什么？\n- 有人能在不阅读内部代码的情况下理解一个单元的作用吗？你能在不破坏消费者的情况下更改内部代码吗？如果不能，边界需要改进。\n- 更小、边界明确的单元也更容易使用 - 你对能一次保持在上下文中的代码推理得更好，当文件集中时，你的编辑更可靠。当文件变大时，这通常是它做得太多的信号。\n\n**在现有代码库中工作：**\n\n- 在提出更改之前探索当前结构。遵循现有模式。\n- 在现有代码存在影响工作的问题的地方（例如，文件变得太大、边界不明确、职责混乱），将有针对性的改进作为设计的一部分 - 就像优秀的开发人员改进他们正在工作的代码一样。\n- 不要提出无关的重构。保持专注于服务当前目标的内容。\n\n## 设计之后\n\n**文档：**\n\n- 将验证后的设计（规范）写入 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`\n  - （用户对规范位置的偏好覆盖此默认值）\n- 如果可用，使用 elements-of-style:writing-clearly-and-concisely 技能\n- 将设计文档提交到 git\n\n**规范审查循环：**\n编写规范文档后：\n\n1. 调度 spec-document-reviewer 子代理（参见 spec-document-reviewer-prompt.md）\n2. 如果发现问题：修复，重新调度，重复直到批准\n3. 如果循环超过3次迭代，提交给人类指导\n\n**用户审查关卡：**\n规范审查循环通过后，请用户在继续之前审查书面规范：\n\n> \"规范已编写并提交到 `<path>`。请审查它，并让我知道在我们开始编写实现计划之前是否要进行任何更改。\"\n\n等待用户的响应。如果他们要求更改，进行更改并重新运行规范审查循环。只有在用户批准后才能继续。\n\n**实现：**\n\n- 调用 writing-plans 技能创建详细的实现计划\n- 不要调用任何其他技能。writing-plans 是下一步。\n\n## 关键原则\n\n- **一次一个问题** - 不要用多个问题压倒用户\n- **首选多项选择题** - 在可能的情况下比开放式问题更容易回答\n- **严格遵循 YAGNI** - 从所有设计中删除不必要的功能\n- **探索替代方案** - 在确定之前始终提出2-3种方法\n- **增量验证** - 展示设计，在继续之前获得批准\n- **保持灵活** - 当有不明白的地方时回头澄清\n\n## 视觉 Companion\n\n一个基于浏览器的 companion，用于在头脑风暴期间显示模型、图表和视觉选项。作为工具提供 - 不是模式。接受 companion 意味着它可用于受益于视觉处理的问题；这并不意味着每个问题都通过浏览器进行。\n\n**提供 companion：** 当你预计即将提出的问题将涉及视觉内容（模型、布局、图表）时，一次提出请求获得同意：\n> \"我们正在处理的一些内容可能更容易在网页浏览器中向您展示。我可以在我们进行过程中准备模型、图表、比较和其他视觉内容。此功能仍处于新状态，可能会消耗较多 tokens。想尝试一下吗？（需要打开本地 URL）\"\n\n**此提议必须是单独的消息。** 不要将其与澄清问题、上下文摘要或任何其他内容结合。消息应只包含上述提议，别无其他。在继续之前等待用户的响应。如果他们拒绝，继续使用纯文本头脑风暴。\n\n**每个问题的决定：** 即使在用户接受后，也要为每个问题决定是使用浏览器还是终端。测试：**用户通过查看是否比阅读更能理解这一点？**\n\n- **使用浏览器** 处理视觉内容 - 模型、线框图、布局比较、架构图表、并排视觉设计\n- **使用终端** 处理文本内容 - 需求问题、概念选择、权衡列表、A/B/C/D 文本选项、范围决策\n\n关于 UI 主题的问题并不自动成为视觉问题。\"在这种情况下，个性意味着什么？\"是一个概念性问题 - 使用终端。\"哪种向导布局更好？\"是一个视觉问题 - 使用浏览器。\n\n如果他们同意使用 companion，请在继续之前阅读详细指南：\n`skills/brainstorming/visual-companion.md`\n"
+  },
+  {
+    "name": "claudeception",
+    "content": "---\nname: claudeception\ndescription: |\n  持续学习系统，从工作会话中提取可复用知识。\n  触发词：/claudeception、\"把这个保存为技能\"、\"提取技能\"、\"我们学到了什么？\"，\n  或在非显而易见的调试、变通方案、试错发现后。\n  自动创建标准化的 Trae 技能以便未来复用。\ntags:\n  - 学习\n  - 技能提取\n  - 自动化\n  - 调试\n  - 工作流\nversion: 3.0.0\nauthor: Trae Code\nenabled: true\nrun_on:\n  - manual\n  - after_task\nwhen:\n  any:\n    - command: /claudeception\n    - user_contains:\n        - save this as a skill\n        - extract a skill from this\n        - what did we learn\n        - 把这个保存为技能\n        - 提取技能\n        - 我们学到了什么\n    - task_has:\n        - debugging\n        - workaround\n        - trial_and_error\n        - non_obvious_solution\ntool_allowlist:\n  - read\n  - write\n  - edit\n  - grep\n  - glob\n  - web_search\n  - web_fetch\n  - skill\n  - ask_user\n  - todo\n---\n\n# Claudeception（Trae 版）\n\n持续学习系统，从工作会话中提取可复用知识，并将其编码为标准化的 Trae 技能，实现自主改进。\n\n## 何时提取技能\n\n遇到以下情况时提取：\n1. **非显而易见的解决方案** - 调试、变通方案、难以发现的修复\n2. **项目特定模式** - 未在其他地方记录的约定\n3. **工具集成知识** - 超出基本文档的实际使用\n4. **错误解决** - 带有实际根因的误导性错误\n5. **工作流优化** - 简化的多步骤流程\n\n## 技能质量标准\n\n- 可在未来任务中复用\n- 非琐碎（需要发现，而不只是文档）\n- 具体的触发条件和清晰的解决方案\n- 已在实践中验证可行\n\n## 提取流程\n\n### 1. 检查现有技能\n搜索现有技能以避免重复：\n```sh\n# 项目级\n.trae-cn/skills/**/*.md\n\n# 用户级\n~/.trae-cn/skills/**/*.md\n```\n\n---\n\n## 使用说明\n\n由于系统安全限制，请手动复制此文件到：\n\n**项目级技能：**\n```\ncp claudeception-skill-zh.md /Users/xutao/Documents/trae_projects/todo-all-code/.trae/skills/claudeception/SKILL.md\n```\n\n**用户级技能（所有项目通用）：**\n```\ncp claudeception-skill-zh.md /Users/xutao/.trae-cn/skills/claudeception/SKILL.md\n```\n"
+  },
+  {
+    "name": "competitive-brief",
+    "content": "---\nname: competitive-brief\ndescription: Create concise competitive briefs that summarize competitor analysis, market positioning, and strategic insights for quick decision making.\n---\n\n# Competitive Brief\n\n## 描述\n创建简洁的竞争简报，总结竞品分析、市场定位和战略洞察，支持快速决策。\n\n## 使用场景\n使用此技能当：\n- 需要快速了解竞争对手概况\n- 准备产品战略会议材料\n- 评估市场机会和威胁\n- 用户要求\"做竞品简报\"、\"竞争分析\"或\"竞品对比\"\n\n## 指令\n\n### Phase 1: 收集竞品信息\n- 识别主要竞争对手\n- 收集竞品的产品、定价、市场策略信息\n- 了解竞品的优势和劣势\n\n### Phase 2: 分析对比\n- 对比竞品与自身产品的差异\n- 识别市场空白和机会\n- 评估竞争威胁\n\n### Phase 3: 生成简报\n- 整理关键发现\n- 提出战略建议\n- 形成简洁的竞争简报\n\n## 竞争简报架构\n\n### 1. 竞品概览\n- 竞品名称和定位\n- 核心产品/服务\n- 目标市场\n\n### 2. 产品对比\n- 核心功能对比\n- 技术特点\n- 用户体验评价\n\n### 3. 市场策略\n- 定价策略\n- 营销渠道\n- 市场份额\n\n### 4. SWOT分析\n- 优势（Strengths）\n- 劣势（Weaknesses）\n- 机会（Opportunities）\n- 威胁（Threats）\n\n### 5. 战略建议\n- 差异化策略\n- 竞争应对措施\n- 市场机会\n\n## 质量标准\n\n### 信息准确性\n- 确保数据来源可靠\n- 最新的市场信息\n- 客观中立的分析\n\n### 简报简洁性\n- 突出重点，避免冗长\n- 使用图表和对比表\n- 结论清晰明确\n\n### 建议可行性\n- 建议具体可执行\n- 考虑资源和时间约束\n- 有明确的行动步骤\n\n## 示例：导航应用竞争简报\n\n### 1. 竞品概览\n| 竞品 | 定位 | 核心产品 |\n|------|------|----------|\n| 高德地图 | 综合地图服务 | 导航、POI搜索、实时路况 |\n| 百度地图 | 智能地图服务 | AI导航、AR实景 |\n| 美团导航 | 外卖专用导航 | 骑手路线规划 |\n\n### 2. 产品对比\n- 核心功能：实时导航、POI搜索、语音交互\n- 差异化功能：骑手专属路线、实时订单集成\n\n### 3. 市场策略\n- 定价：免费+增值服务\n- 渠道：应用商店、骑手端集成\n- 份额：高德约40%，百度约30%\n\n### 4. SWOT分析\n- **优势**：骑手专属功能、订单联动\n- **劣势**：用户基数小、功能单一\n- **机会**：骑手市场增长、专业化需求\n- **威胁**：巨头竞争、政策变化\n\n### 5. 战略建议\n- 专注骑手细分市场\n- 强化语音导航和实时路况\n- 与外卖平台深度合作\n\n## 实施指南\n\n**DO（始终）**\n- 保持简报简洁，一页纸原则\n- 使用对比表格和图表\n- 提供可操作的建议\n\n**DON'T（避免）**\n- 信息过载，重点不突出\n- 主观评价，缺乏数据支持\n- 建议过于笼统，无法执行\n"
+  },
+  {
+    "name": "finishing-a-development-branch",
+    "content": "---\nname: finishing-a-development-branch\ndescription: 当实现完成、所有测试通过且你需要决定如何集成工作时使用 - 通过呈现合并、PR 或清理的结构化选项来指导开发工作的完成\n---\n\n# 完成开发分支\n\n## 概述\n\n通过呈现清晰的选项并处理选定的工作流来指导开发工作的完成。\n\n**核心原则：** 验证测试 → 呈现选项 → 执行选择 → 清理。\n\n**开始时宣布：** \"我正在使用 finishing-a-development-branch 技能来完成这项工作。\"\n\n## 流程\n\n### 步骤 1：验证测试\n\n**在呈现选项之前，验证测试通过：**\n\n```bash\n# 运行项目的测试套件\nnpm test / cargo test / pytest / go test ./...\n```\n\n**如果测试失败：**\n```\n测试失败（<N> 个失败）。完成前必须修复：\n\n[显示失败]\n\n在测试通过之前无法继续合并/PR。\n```\n\n停止。不要继续到步骤 2。\n\n**如果测试通过：** 继续到步骤 2。\n\n### 步骤 2：确定基础分支\n\n```bash\n# 尝试常见的基础分支\ngit merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null\n```\n\n或询问：\"此分支从 main 分支分离 - 是否正确？\"\n\n### 步骤 3：呈现选项\n\n呈现以下 4 个选项：\n\n```\n实现完成。你想做什么？\n\n1. 本地合并回 <base-branch>\n2. 推送并创建 Pull Request\n3. 保持分支不变（我稍后处理）\n4. 放弃此工作\n\n选择哪个选项？\n```\n\n**不要添加解释** - 保持选项简洁。\n\n### 步骤 4：执行选择\n\n#### 选项 1：本地合并\n\n```bash\n# 切换到基础分支\ngit checkout <base-branch>\n\n# 拉取最新\ngit pull\n\n# 合并功能分支\ngit merge <feature-branch>\n\n# 验证合并结果的测试\n<test command>\n\n# 如果测试通过\ngit branch -d <feature-branch>\n```\n\n然后：清理 worktree（步骤 5）\n\n#### 选项 2：推送并创建 PR\n\n```bash\n# 推送分支\ngit push -u origin <feature-branch>\n\n# 创建 PR\ngh pr create --title \"<title>\" --body \"$(cat <<'EOF'\n## 摘要\n<2-3 个要点说明更改内容>\n\n## 测试计划\n- [ ] <验证步骤>\nEOF\n)\"\n```\n\n然后：清理 worktree（步骤 5）\n\n#### 选项 3：保持不变\n\n报告：\"保持分支 <name>。Worktree 保存在 <path>。\"\n\n**不要清理 worktree。**\n\n#### 选项 4：放弃\n\n**首先确认：**\n```\n这将永久删除：\n- 分支 <name>\n- 所有提交：<commit-list>\n- Worktree 位于 <path>\n\n输入 'discard' 确认。\n```\n\n等待确切的确认。\n\n如果确认：\n```bash\ngit checkout <base-branch>\ngit branch -D <feature-branch>\n```\n\n然后：清理 worktree（步骤 5）\n\n### 步骤 5：清理 Worktree\n\n**对于选项 1、2、4：**\n\n检查是否在 worktree 中：\n```bash\ngit worktree list | grep $(git branch --show-current)\n```\n\n如果是：\n```bash\ngit worktree remove <worktree-path>\n```\n\n**对于选项 3：** 保持 worktree。\n\n## 快速参考\n\n| 选项 | 合并 | 推送 | 保持 Worktree | 清理分支 |\n|------|------|------|---------------|----------|\n| 1. 本地合并 | ✓ | - | - | ✓ |\n| 2. 创建 PR | - | ✓ | ✓ | - |\n| 3. 保持不变 | - | - | ✓ | - |\n| 4. 放弃 | - | - | - | ✓ (强制) |\n\n## 常见错误\n\n**跳过测试验证**\n- **问题：** 合并损坏的代码，创建失败的 PR\n- **修复：** 在提供选项之前始终验证测试\n\n**开放式问题**\n- **问题：** \"我接下来应该做什么？\" → 模棱两可\n- **修复：** 呈现确切的 4 个结构化选项\n\n**自动 worktree 清理**\n- **问题：** 在可能需要时删除 worktree（选项 2、3）\n- **修复：** 仅为选项 1 和 4 清理\n\n**放弃时无确认**\n- **问题：** 意外删除工作\n- **修复：** 要求输入 \"discard\" 确认\n\n## 红旗\n\n**永远不要：**\n- 带着失败的测试继续\n- 不验证结果测试就合并\n- 未经确认删除工作\n- 未经明确请求强制推送\n\n**始终：**\n- 在提供选项之前验证测试\n- 呈现确切的 4 个选项\n- 为选项 4 获取输入确认\n- 仅为选项 1 和 4 清理 worktree\n\n## 集成\n\n**被调用：**\n- **subagent-driven-development**（步骤 7）- 所有任务完成后\n- **executing-plans**（步骤 5）- 所有批次完成后\n\n**配对：**\n- **using-git-worktrees** - 清理该技能创建的 worktree\n"
+  },
+  {
+    "name": "market-research",
+    "content": "---\nname: market-research\ndescription: Conduct comprehensive market research including competitor analysis, target audience analysis, market trends, and industry insights.\n---\n\n# Market Research\n\n## 描述\n进行全面的市场研究，包括竞品分析、目标用户分析、市场趋势和行业洞察。帮助产品团队做出数据驱动的决策。\n\n## 使用场景\n使用此技能当：\n- 启动新产品或进入新市场前需要了解竞争格局\n- 需要分析目标用户群体特征和需求\n- 了解行业趋势和市场机会\n- 用户要求\"做市场调研\"、\"竞品分析\"、\"用户分析\"或\"市场分析\"\n\n## 指令\n\n### Phase 1: 明确研究目标\n首先明确研究的核心目标：\n- 研究范围：产品/服务类型、目标市场、地域范围\n- 研究目的：了解竞争、发现机会、用户洞察等\n- 关键问题：需要回答哪些核心问题\n\n### Phase 2: 竞品分析\n收集并分析主要竞争对手信息：\n- 识别直接和间接竞争对手\n- 分析竞品的产品功能、定价策略、市场定位\n- 评估竞品的优势和劣势\n- 识别市场空白和机会\n\n### Phase 3: 用户分析\n深入了解目标用户：\n- 用户画像：年龄、性别、地域、收入、职业等\n- 用户需求：痛点、期望、使用场景\n- 用户行为：消费习惯、决策因素、渠道偏好\n\n### Phase 4: 市场趋势分析\n分析市场动态和趋势：\n- 市场规模和增长率\n- 技术发展趋势\n- 政策法规变化\n- 消费者行为变化\n\n### Phase 5: 输出研究报告\n综合所有信息，生成结构化的市场研究报告。\n\n## 市场研究报告架构\n\n### 1. 执行摘要\n- 研究背景和目的\n- 核心发现总结\n- 关键建议\n\n### 2. 市场概述\n- 市场定义和范围\n- 市场规模和增长预测\n- 市场驱动因素\n\n### 3. 竞品分析\n- 主要竞品列表\n- 竞品对比矩阵（功能、价格、市场份额）\n- SWOT分析\n\n### 4. 用户分析\n- 用户画像描述\n- 用户需求分析\n- 购买决策因素\n\n### 5. 市场趋势\n- 技术趋势\n- 消费者趋势\n- 行业挑战和机遇\n\n### 6. 战略建议\n- 市场进入策略\n- 差异化定位建议\n- 产品发展方向\n\n## 质量标准\n\n### 数据来源\n- 优先使用权威数据来源\n- 注明数据来源和时间\n- 交叉验证信息准确性\n\n### 分析深度\n- 避免表面描述，提供深入洞察\n- 使用数据支持结论\n- 识别潜在风险和机会\n\n### 报告结构\n- 逻辑清晰，层次分明\n- 使用图表辅助理解\n- 结论明确，建议可行\n\n## 示例：外卖导航应用市场研究\n\n### 1. 执行摘要\n**背景**：为外卖骑手设计的导航应用市场分析\n**核心发现**：骑手导航市场增长迅速，用户对实时路况和语音导航需求强烈\n**建议**：聚焦语音交互和实时路况功能\n\n### 2. 市场概述\n- 市场规模：预计2025年达XX亿元\n- 年增长率：XX%\n- 主要玩家：高德地图、百度地图、美团导航\n\n### 3. 竞品分析\n| 竞品 | 优势 | 劣势 |\n|------|------|------|\n| 高德地图 | 覆盖广、POI全 | 骑手功能不够专业 |\n| 美团导航 | 深度整合外卖业务 | 通用性不足 |\n\n### 4. 用户分析\n- 年龄：20-40岁为主\n- 核心需求：精准路线、实时路况、语音导航\n- 痛点：地图更新不及时、路线规划不合理\n\n### 5. 市场趋势\n- 实时导航需求增长\n- AI语音交互成为标配\n- 轻量化应用更受欢迎\n\n### 6. 战略建议\n- 专注骑手细分市场\n- 强化语音导航功能\n- 优化路线算法\n\n## 实施指南\n\n**DO（始终）**\n- 多渠道收集信息\n- 保持客观中立\n- 提供具体可操作的建议\n\n**DON'T（避免）**\n- 主观臆断，缺乏数据支持\n- 忽略潜在风险\n- 报告过于冗长，重点不突出\n"
+  },
+  {
+    "name": "mempalace-auto-saver",
+    "content": "---\nname: mempalace-auto-saver\ndescription: AI自动识别项目上下文，生成标准化目录名并完成MemPalace分类存储，支持MCP等多项目自动识别。Invoke when user asks for autosave, 自动保存记忆, or 对话结束保存.\n---\n\n# 记忆宫殿自动保存器（MemPalace Auto-Saver）\n\n## 触发词\n\n- autosave\n- 自动保存记忆\n- 对话结束保存\n- 任务完成\n\n## 功能描述\n\nAI驱动的MemPalace全流程管理，自动完成：\n\n1. 项目上下文分析 → 2. 标准化分类生成 → 3. 上下文提取 → 4. 内容预处理 → 5. 配置文件创建 → 6. 内容扫描存储\n   彻底解决手动操作复杂、分类错误、搜索困难等问题。\n\n## 使用场景\n\n- 多项目并行开发时（如MCP+树莓派+前端项目）\n- 频繁创建新模块/子项目，需要统一分类规范\n- 不想记忆复杂命令参数，追求\"零输入\"操作体验\n- 需要快速搜索和访问历史项目资料\n- 需要保存完整的对话上下文和决策过程\n\n## 规则\n\n- 当单次对话结束（用户未输入新内容达30秒或主动结束对话）时触发\n- 保存内容包含：完整对话历史、关键决策、代码片段、任务结果、项目MD文件\n- 扫描操作后台异步执行，不阻塞当前流程\n- 每次对话开始自动搜索知识库，无需额外指令\n- AI自动识别项目类型，生成标准化分类\n- 支持多项目自动识别与分类存储\n- 执行过程完全自动化，无任何交互提示\n- 不使用rm命令，依赖系统自动清理临时文件\n\n## 执行步骤\n\n### 1. AI项目上下文分析\n\n自动分析当前项目的：\n\n- 项目类型（MCP/前端/嵌入式/其他）\n- 技术栈（Node.js/Python/C/C++等）\n- 项目规模和复杂度\n- 相关文件和目录结构\n\n### 2. 记忆宫殿存储机制\n\nMemPalace 使用向量数据库存储内容，支持语义搜索：\n\n```\n~/.mempalace/\n├── config.json            # 配置文件\n└── palace/                # 记忆宫殿存储目录\n    ├── chroma.sqlite3     # 向量数据库（核心存储）\n    └── {uuid}/            # 临时工作目录\n```\n\n**重要说明**：\n- MemPalace 使用 `chroma.sqlite3` 向量数据库存储内容，不创建传统文件系统目录\n- 无法通过文件系统直接查看保存的文件，只能通过 `mempalace search` 命令访问\n- 向量数据库支持语义搜索，能够理解自然语言查询\n\n### 3. 标准化分类生成\n\n基于AI分析结果，生成符合以下规范的分类：\n\n#### 项目分类规范\n\n- **MCP项目** → wing: \"wing_mcp\"\n- **前端项目** → wing: \"wing_frontend\"\n- **嵌入式项目** → wing: \"wing_embedded\"\n- **通用项目** → wing: \"wing_general\"\n\n### 4. 完整上下文保存流程\n\n#### 自动化保存脚本（无rm命令）\n\n```bash\n#!/bin/bash\n# 自动保存完整上下文到记忆库（无rm命令）\n\n# 项目目录\nPROJECT_DIR=$(pwd)\n\n# 创建临时目录（使用系统临时目录，系统会自动清理）\nTMP_DIR=$(mktemp -d \"/private/tmp/context_save_$(date +%s)\")\n\n# 1. 保存对话历史\ncat > \"$TMP_DIR/conversation.md\" << EOF\n# 对话历史\n$(date +\"%Y-%m-%d %H:%M:%S\")\n\n[完整对话历史将由AI助手自动填充]\nEOF\n\n# 2. 保存关键决策\ncat > \"$TMP_DIR/decisions.md\" << EOF\n# 关键决策\n$(date +\"%Y-%m-%d %H:%M:%S\")\n\n[关键决策将由AI助手自动提取]\nEOF\n\n# 3. 保存代码片段\nmkdir -p \"$TMP_DIR/code_snippets\"\ncat > \"$TMP_DIR/code_snippets/summary.md\" << EOF\n# 代码片段汇总\n$(date +\"%Y-%m-%d %H:%M:%S\")\n\n[代码片段将由AI助手自动收集]\nEOF\n\n# 4. 复制MD文件\nfind \"$PROJECT_DIR\" -name \"*.md\" -exec cp {} \"$TMP_DIR\" \\;\n\n# 5. 保存任务结果\ncat > \"$TMP_DIR/task_results.md\" << EOF\n# 任务结果\n$(date +\"%Y-%m-%d %H:%M:%S\")\n\n[任务结果将由AI助手自动记录]\nEOF\n\n# 创建配置文件（使用printf确保YAML格式正确）\nprintf \"wing: wing_general\\nrooms:\\n- name: general\\n  description: Complete context including conversations, decisions, code, and MD files\\n\" > \"$TMP_DIR/mempal.yaml\"\n\n# 扫描并保存\ncd \"$TMP_DIR\" && mempalace mine --wing wing_general --agent 'Trae AI' .\n\n# 验证保存结果\nmempalace status\n\n# 不需要rm命令，系统会自动清理/private/tmp目录\n```\n\n### 5. 精准搜索内容\n\n使用 `mempalace search` 命令进行精准搜索：\n\n#### 搜索特定分类内容\n\n```bash\n# 搜索特定分类的内容（必须使用--wing参数）\nmempalace search --wing wing_general \"关键词\"\n\n# 搜索对话历史\nmempalace search --wing wing_general \"对话历史\"\n\n# 搜索关键决策\nmempalace search --wing wing_general \"关键决策\"\n\n# 搜索代码片段\nmempalace search --wing wing_general \"代码片段\"\n\n# 搜索任务结果\nmempalace search --wing wing_general \"任务结果\"\n\n# 搜索MD文件\nmempalace search --wing wing_general \"文件名\"\n```\n\n#### 搜索所有分类\n\n```bash\n# 搜索所有分类的内容\nmempalace search \"关键词\"\n```\n\n### 6. 查看分类状态\n\n使用 `mempalace status` 命令查看整体分类状态：\n\n```bash\n# 查看记忆库整体状态\nmempalace status\n```\n\n### 7. 异步执行记忆扫描\n\n使用 memory-palace MCP 的 save 工具保存会话记忆，参数配置：\n\n- session_name: AI生成的标准化会话名称\n- agent: \"产品通\"\n- status: \"对话已保存并分类\"\n- outcome: \"succeeded\"\n- built: 本次对话构建的内容\n- decisions: 关键决策点\n- next_steps: 下一步建议\n- files: 相关文件路径\n- blockers: 遇到的阻碍\n- conversation_context: 完整对话上下文 + AI分类信息\n\n### 8. Wing分类映射\n\n根据项目类型自动映射到相应的wing分类：\n\n- MCP项目 → wing: \"wing_mcp\"\n- 前端项目 → wing: \"wing_frontend\"\n- 嵌入式项目 → wing: \"wing_embedded\"\n- 通用项目 → wing: \"wing_general\"\n\n### 9. 知识库自动搜索\n\n每次新对话开始时，自动调用 memory-palace MCP 的 recover 工具搜索相关历史记忆。\n\n## 使用示例\n\n1. 用户说：\"autosave\" → 立即触发记忆保存和AI分类\n2. 用户说：\"自动保存记忆\" → 执行保存流程和智能分类\n3. 对话结束60秒后 → 自动保存上下文并分类存储\n4. MCP项目开发 → 自动识别为MCP类型，执行自动化保存流程\n5. 多项目并行 → 自动区分不同项目类型，独立分类存储\n6. 搜索对话历史 → 执行mempalace search --wing wing_general \"对话历史\"\n7. 搜索关键决策 → 执行mempalace search --wing wing_general \"关键决策\"\n8. 查看状态 → 执行mempalace status\n\n## 快速命令参考\n\n### 完整自动化工作流程（复制即可执行）\n\n```bash\n#!/bin/bash\n# 自动保存完整上下文到记忆库\n\n# 项目目录\nPROJECT_DIR=$(pwd)\n\n# 创建临时目录\nTMP_DIR=$(mktemp -d \"/private/tmp/context_save_$(date +%s)\")\n\n# 1. 保存对话历史\ncat > \"$TMP_DIR/conversation.md\" << EOF\n# 对话历史\n$(date +\"%Y-%m-%d %H:%M:%S\")\n\n[完整对话历史将由AI助手自动填充]\nEOF\n\n# 2. 保存关键决策\ncat > \"$TMP_DIR/decisions.md\" << EOF\n# 关键决策\n$(date +\"%Y-%m-%d %H:%M:%S\")\n\n[关键决策将由AI助手自动提取]\nEOF\n\n# 3. 保存代码片段\nmkdir -p \"$TMP_DIR/code_snippets\"\ncat > \"$TMP_DIR/code_snippets/summary.md\" << EOF\n# 代码片段汇总\n$(date +\"%Y-%m-%d %H:%M:%S\")\n\n[代码片段将由AI助手自动收集]\nEOF\n\n# 4. 复制MD文件\nfind \"$PROJECT_DIR\" -name \"*.md\" -exec cp {} \"$TMP_DIR\" \\;\n\n# 5. 保存任务结果\ncat > \"$TMP_DIR/task_results.md\" << EOF\n# 任务结果\n$(date +\"%Y-%m-%d %H:%M:%S\")\n\n[任务结果将由AI助手自动记录]\nEOF\n\n# 创建配置文件\nprintf \"wing: wing_general\\nrooms:\\n- name: general\\n  description: Complete context including conversations, decisions, code, and MD files\\n\" > \"$TMP_DIR/mempal.yaml\"\n\n# 扫描并保存\ncd \"$TMP_DIR\" && mempalace mine --wing wing_general --agent 'Trae AI' .\n\n# 验证\nmempalace status\n```\n\n## 注意事项\n\n- 确保 `~/.mempalace/` 目录存在且可写\n- mempalace 命令需要先安装并配置好环境变量\n- 首次使用时会自动创建向量数据库 `chroma.sqlite3`\n- 保存的文件会被转换为向量存储，支持语义搜索\n- 无法通过文件系统直接查看保存的文件，只能通过 `mempalace search` 命令访问\n- 搜索特定分类的内容时必须使用 `--wing` 参数\n- 定期备份 `~/.mempalace/palace/chroma.sqlite3` 文件，确保数据安全\n- 保存操作异步执行，不会阻塞当前对话\n- AI分类基于项目文件和上下文进行智能识别\n- 支持自定义分类规则和wing命名规范\n- 使用系统临时目录 `/private/tmp` 避免权限问题\n- 完全自动化执行，无任何交互提示\n- 不使用 `rm` 命令，依赖系统自动清理临时文件\n- 保存完整的对话上下文，包括对话历史、关键决策、代码片段和任务结果\n- 使用 `printf` 命令创建YAML配置文件，确保格式正确\n- 临时目录使用时间戳命名，确保唯一性"
+  },
+  {
+    "name": "prd-write",
+    "content": "---\nname: prd-write\ndescription: Generate comprehensive Product Requirements Documents (PRDs) for software products and features. Includes executive summaries, user stories, technical specifications, and risk analysis.\n---\n\n# PRD Writer\n\n## 描述\n生成高质量的产品需求文档（PRD），帮助将业务愿景转化为技术执行规范。覆盖从问题定义到实施方案的完整流程。\n\n## 使用场景\n使用此技能当：\n- 启动新产品或功能开发周期\n- 将模糊的想法转化为具体的技术规范\n- 为AI驱动的功能定义需求\n- 利益相关者需要项目范围的统一\"事实来源\"\n- 用户要求\"写PRD\"、\"记录需求\"或\"规划功能\"\n\n## 指令\n\n### Phase 1: 发现阶段（访谈）\n在编写PRD之前，必须询问用户以填补知识空白。不要假设上下文。\n询问：\n- 核心问题：我们为什么现在要构建这个？\n- 成功指标：我们如何知道它有效？\n- 约束条件：预算、技术栈或截止日期？\n- 提议的解决方案：1-2句话描述解决方案。\n- 成功标准：3-5个可衡量的KPI。\n\n### Phase 2: 分析与范围界定\n综合用户输入，识别依赖关系和隐藏的复杂性。\n- 绘制用户流程图\n- 定义非目标以保护时间表\n\n### Phase 3: 技术起草\n使用严格的PRD架构生成文档。\n\n## PRD 质量标准\n\n### 需求质量\n使用具体、可衡量的标准。避免\"快速\"、\"容易\"或\"直观\"。\n\n**模糊（错误）**\n- 搜索应该快速并返回相关结果。\n- UI必须看起来现代且易于使用。\n\n**具体（正确）**\n- 搜索必须在200ms内返回10k记录数据集的结果。\n- 搜索算法必须在基准评估中达到>=85%的Precision@10。\n- UI必须遵循设计系统并达到100%的Lighthouse可访问性分数。\n\n### 严格PRD架构\n必须遵循此确切结构输出：\n\n1. **执行摘要**\n   - 问题陈述：1-2句话描述痛点\n   - 提议解决方案：1-2句话描述修复方案\n   - 成功标准：3-5个可衡量的KPI\n\n2. **用户体验与功能**\n   - 用户角色：这是为谁设计的？\n   - 用户故事：作为[用户]，我想[行动]以便[收益]\n   - 验收标准：每个故事的\"完成\"定义的项目符号列表\n   - 非目标：我们不构建什么？\n\n3. **AI系统需求（如适用）**\n   - 工具需求：需要什么工具和API？\n   - 评估策略：如何衡量输出质量和准确性\n\n4. **技术规格**\n   - 架构概述：数据流和组件交互\n   - 集成点：API、数据库和认证\n   - 安全与隐私：数据处理和合规性\n\n5. **风险与路线图**\n   - 分阶段推出：MVP -> v1.1 -> v2.0\n   - 技术风险：延迟、成本或依赖失败\n\n## 实施指南\n\n**DO（始终）**\n- 定义测试：对于AI系统，指定如何测试和验证输出质量\n- 迭代：呈现草稿并就特定部分征求反馈\n\n**DON'T（避免）**\n- 跳过发现：在至少询问2个澄清问题之前，切勿编写PRD\n- 虚构约束：如果用户未指定技术栈，请询问或标记为TBD\n\n## 示例：智能搜索系统\n\n### 1. 执行摘要\n**问题**：用户难以在大型仓库中找到特定的文档片段。\n**解决方案**：一个智能搜索系统，提供带有来源引用的直接答案。\n**成功**：\n- 将搜索时间减少50%\n- 引用准确性>=95%\n\n### 2. 用户故事\n**故事**：作为开发人员，我想提出自然语言问题，这样我不必猜测关键词。\n**验收标准**：\n- 支持多轮澄清\n- 返回带有\"复制\"按钮的代码块\n\n### 3. AI系统架构\n**所需工具**：codesearch, grep, webfetch\n\n### 4. 评估\n**基准**：用50个常见开发人员问题测试\n**通过率**：90%必须匹配预期引用\n"
+  },
+  {
+    "name": "quality-gate",
+    "content": "---\nname: \"quality-gate\"\ndescription: \"质量门禁技能，执行质量检查确保代码质量。Invoke when you need to run quality checks before deployment.\"\n---\n\n# quality-gate - 质量门禁技能\n\n## 概述\n\n本技能专注于执行质量检查，确保代码质量、测试覆盖、性能基准、安全标准等达到要求，作为发布前的最后一道关卡。\n\n---\n\n## 与其他技能的衔接\n\n### 前置技能\n- **sdd-code** - 代码已完成\n- **sdd-test** - 测试已完成\n\n### 后置技能\n- **sdd-deploy** - 部署执行\n\n---\n\n## 核心功能\n\n### 1. 代码质量检查\n- 代码规范检查\n- 静态代码分析\n- 代码复杂度分析\n- 代码重复检查\n\n### 2. 测试覆盖率检查\n- 单元测试覆盖率\n- 集成测试覆盖率\n- E2E测试覆盖率\n- 覆盖率趋势分析\n\n### 3. 性能基准检查\n- 响应时间基准\n- 吞吐量基准\n- 资源使用基准\n- 性能回归检查\n\n### 4. 安全漏洞扫描\n- 依赖安全检查\n- 静态安全扫描\n- 动态安全扫描\n- 安全配置检查\n\n### 5. 代码评审检查\n- 代码评审覆盖率\n- 评审意见处理\n- 评审流程合规性\n- 评审质量评估\n\n### 6. 文档完整性检查\n- 需求文档完整性\n- 设计文档完整性\n- API文档完整性\n- 用户文档完整性\n\n### 7. 发布前预检清单\n- 综合质量评估\n- 风险评估\n- 发布准备检查\n- 最终决策支持\n\n---\n\n## 检查清单模板\n\n### 代码质量检查清单\n```markdown\n# 代码质量检查清单\n\n## 代码规范检查\n- [ ] 代码符合项目编码规范\n- [ ] 命名规范（变量、函数、类）\n- [ ] 代码注释充分\n- [ ] 代码格式统一\n\n## 静态代码分析\n- [ ] 无高危告警\n- [ ] 无严重bug\n- [ ] 代码复杂度合理\n- [ ] 无潜在性能问题\n\n## 代码复杂度\n- [ ] 函数圈复杂度 < 10\n- [ ] 类职责单一\n- [ ] 模块耦合度低\n- [ ] 代码可读性良好\n\n## 代码重复检查\n- [ ] 代码重复率 < 5%\n- [ ] 无大面积重复代码\n- [ ] 公共逻辑已抽取\n```\n\n---\n\n### 测试覆盖率检查清单\n```markdown\n# 测试覆盖率检查清单\n\n## 单元测试覆盖\n- [ ] 语句覆盖率 ≥ 80%\n- [ ] 分支覆盖率 ≥ 75%\n- [ ] 函数覆盖率 ≥ 90%\n- [ ] 核心模块覆盖率 ≥ 95%\n\n## 集成测试覆盖\n- [ ] 主要接口都有测试\n- [ ] 核心业务流程有测试\n- [ ] 异常场景有测试\n\n## E2E测试覆盖\n- [ ] 核心用户旅程有测试\n- [ ] 关键功能路径有测试\n- [ ] 兼容性测试已完成\n\n## 覆盖率趋势\n- [ ] 覆盖率不低于上次发布\n- [ ] 无明显覆盖率下降\n- [ ] 新增代码有测试覆盖\n```\n\n---\n\n### 性能基准检查清单\n```markdown\n# 性能基准检查清单\n\n## 响应时间\n- [ ] API响应时间 ≤ 500ms（P95）\n- [ ] 页面加载时间 ≤ 2s\n- [ ] 数据库查询时间 ≤ 100ms\n- [ ] 关键操作响应时间达标\n\n## 吞吐量\n- [ ] 系统吞吐量 ≥ 100 TPS\n- [ ] 数据库吞吐量达标\n- [ ] 缓存命中率 ≥ 90%\n\n## 资源使用\n- [ ] CPU使用率 ≤ 70%（峰值）\n- [ ] 内存使用率 ≤ 80%（峰值）\n- [ ] 磁盘IO正常\n- [ ] 网络带宽正常\n\n## 性能回归\n- [ ] 性能不低于上一版本\n- [ ] 无明显性能下降\n- [ ] 性能瓶颈已识别\n```\n\n---\n\n### 安全漏洞扫描清单\n```markdown\n# 安全漏洞扫描清单\n\n## 依赖安全\n- [ ] 无已知高危漏洞\n- [ ] 依赖版本较新\n- [ ] 不再使用的依赖已移除\n\n## 静态安全扫描\n- [ ] 无高危安全问题\n- [ ] 输入验证完整\n- [ ] SQL注入防护到位\n- [ ] XSS防护到位\n\n## 动态安全扫描\n- [ ] 常见攻击测试通过\n- [ ] 认证授权机制安全\n- [ ] 数据传输加密\n- [ ] 敏感数据保护到位\n\n## 安全配置\n- [ ] 安全配置符合规范\n- [ ] 日志记录完整\n- [ ] 权限设置合理\n- [ ] 应急响应机制完善\n```\n\n---\n\n### 代码评审检查清单\n```markdown\n# 代码评审检查清单\n\n## 评审覆盖率\n- [ ] 所有代码都已评审\n- [ ] 核心代码多轮评审\n- [ ] 跨团队代码有评审\n\n## 评审意见处理\n- [ ] 所有评审意见已回复\n- [ ] 合理建议已采纳\n- [ ] 有争议的问题已解决\n\n## 评审流程合规性\n- [ ] 评审流程按规范执行\n- [ ] 评审记录完整\n- [ ] 评审时间合理\n\n## 评审质量\n- [ ] 评审发现真实问题\n- [ ] 评审建议有价值\n- [ ] 评审者资质符合要求\n```\n\n---\n\n### 文档完整性检查清单\n```markdown\n# 文档完整性检查清单\n\n## 需求文档\n- [ ] 需求描述清晰完整\n- [ ] 验收标准明确\n- [ ] 边界条件覆盖\n- [ ] 依赖关系说明清晰\n\n## 设计文档\n- [ ] 架构设计文档完整\n- [ ] 接口设计文档完整\n- [ ] 数据库设计文档完整\n- [ ] 关键设计决策有记录\n\n## API文档\n- [ ] API接口文档完整\n- [ ] 请求响应示例齐全\n- [ ] 错误码定义清晰\n- [ ] 版本说明清晰\n\n## 用户文档\n- [ ] 用户使用说明完整\n- [ ] 常见问题解答齐全\n- [ ] 更新日志完整\n- [ ] 文档与代码同步\n```\n\n---\n\n## 质量门判定标准\n\n### 通过标准\n- [ ] 所有检查项通过（P0-P1）\n- [ ] 测试覆盖率达标\n- [ ] 性能指标达标\n- [ ] 无高危安全漏洞\n- [ ] 风险可控\n\n### 条件通过标准\n- [ ] 少数P2项未通过但不影响发布\n- [ ] 有明确的后续修复计划\n- [ ] 风险评估通过\n- [ ] 相关负责人同意\n\n### 不通过标准\n- [ ] 任何P0项未通过\n- [ ] 存在阻断性bug\n- [ ] 测试覆盖率严重不足\n- [ ] 存在高危安全漏洞\n- [ ] 性能严重不达标\n\n---\n\n## 风险评估矩阵\n\n| 风险等级 | 严重程度 | 可能性 | 处理策略 |\n|---------|---------|--------|---------|\n| P0 | 严重 | 高 | 必须修复 |\n| P0 | 严重 | 中 | 必须修复 |\n| P0 | 严重 | 低 | 评估后决策 |\n| P1 | 重要 | 高 | 尽量修复 |\n| P1 | 重要 | 中 | 评估后决策 |\n| P1 | 重要 | 低 | 可后续修复 |\n| P2 | 一般 | 高 | 可后续修复 |\n| P2 | 一般 | 中 | 可后续修复 |\n| P2 | 一般 | 低 | 可后续修复 |\n\n---\n\n## 使用步骤\n\n### 步骤1：执行自动检查\n- 运行代码质量工具\n- 运行测试覆盖率工具\n- 运行安全扫描工具\n- 运行性能基准测试\n\n### 步骤2：执行人工检查\n- 代码评审检查\n- 文档完整性检查\n- 发布准备检查\n\n### 步骤3：生成质量报告\n- 汇总检查结果\n- 识别问题\n- 评估风险\n- 生成报告\n\n### 步骤4：质量门决策\n- 根据检查结果\n- 评估风险\n- 做出决策（通过/条件通过/不通过）\n- 通知相关团队\n\n---\n\n## 与其他技能的集成\n\n### 与sdd-test集成\n```\nsdd-test → 测试结果 → quality-gate → 质量检查\n```\n\n### 与sdd-deploy集成\n```\nquality-gate → 质量通过 → sdd-deploy → 部署执行\n```\n\n---\n\n## 最佳实践\n\n1. 质量门禁要定期更新\n2. 严格但不过于苛刻\n3. 持续改进检查标准\n4. 自动化为主人工为辅\n5. 质量标准要与业务目标对齐\n\n---\n\n## 常见问题\n\n### Q：质量门禁不通过怎么办？\nA：首先分析问题严重性，阻断性问题必须修复，其他问题评估风险后决策\n\n### Q：如何平衡质量和发布速度？\nA：优先级设置合理，P0必须通过，P1尽量通过，P2可后续修复\n\n### Q：质量检查应该什么时候做？\nA：开发过程中持续做，发布前集中做，定期回顾改进检查标准\n"
+  },
+  {
+    "name": "receiving-code-review",
+    "content": "---\nname: receiving-code-review\ndescription: 在收到代码审查反馈时使用，在实施建议之前，特别是如果反馈似乎不清楚或技术上有问题 - 需要技术严谨性和验证，而不是表演性同意或盲目实施\n---\n\n# 代码审查接收\n\n## 概述\n\n代码审查需要技术评估，而不是情感表演。\n\n**核心原则：** 实施前验证。假设前询问。技术正确性优先于社交舒适度。\n\n## 响应模式\n\n```\n收到代码审查反馈时：\n\n1. 阅读：完整阅读反馈，不做出反应\n2. 理解：用自己的话重述要求（或询问）\n3. 验证：对照代码库现实进行检查\n4. 评估：对这个代码库技术上是否合理？\n5. 响应：技术确认或有理由的反驳\n6. 实施：一次一个项目，测试每个项目\n```\n\n## 禁止的响应\n\n**永远不要：**\n- \"你绝对正确！\"（明确违反 CLAUDE.md）\n- \"好观点！\" / \"优秀的反馈！\"（表演性的）\n- \"让我现在实施那个\"（验证前）\n\n**相反：**\n- 重述技术要求\n- 提出澄清问题\n- 如果错误，用技术推理反驳\n- 直接开始工作（行动 > 言语）\n\n## 处理不清楚的反馈\n\n```\n如果任何项目不清楚：\n  停止 - 暂时不要实施任何内容\n  要求澄清不清楚的项目\n\n原因：项目可能相关。部分理解 = 错误实施。\n```\n\n**示例：**\n```\n你的人类伙伴：\"修复 1-6\"\n你理解 1,2,3,6。对 4,5 不清楚。\n\n❌ 错误：现在实施 1,2,3,6，稍后询问 4,5\n✅ 正确：\"我理解项目 1,2,3,6。在继续之前需要澄清 4 和 5。\"\n```\n\n## 特定来源处理\n\n### 来自你的人类伙伴\n- **可信** - 理解后实施\n- **如果范围不清楚，仍要询问**\n- **无表演性同意**\n- **直接行动**或技术确认\n\n### 来自外部审查者\n```\n实施前：\n  1. 检查：对这个代码库技术上是否正确？\n  2. 检查：是否破坏现有功能？\n  3. 检查：当前实现的原因？\n  4. 检查：是否在所有平台/版本上工作？\n  5. 检查：审查者是否理解完整上下文？\n\n如果建议似乎错误：\n  用技术推理反驳\n\n如果无法轻松验证：\n  说明：\"没有 [X] 我无法验证这一点。我应该 [调查/询问/继续]？\"\n\n如果与你的人类伙伴之前的决定冲突：\n  先停止并与你的人类伙伴讨论\n```\n\n**你的人类伙伴的规则：** \"外部反馈 - 保持怀疑，但仔细检查\"\n\n## \"专业\"功能的 YAGNI 检查\n\n```\n如果审查者建议\"正确实施\"：\n  在代码库中搜索实际使用\n\n  如果未使用：\"这个端点没有被调用。移除它（YAGNI）？\"\n  如果使用：则正确实施\n```\n\n**你的人类伙伴的规则：** \"你和审查者都向我报告。如果我们不需要这个功能，就不要添加它。\"\n\n## 实施顺序\n\n```\n对于多项反馈：\n  1. 首先澄清任何不清楚的内容\n  2. 然后按以下顺序实施：\n     - 阻塞问题（中断，安全）\n     - 简单修复（拼写错误，导入）\n     - 复杂修复（重构，逻辑）\n  3. 单独测试每个修复\n  4. 验证无回归\n```\n\n## 何时反驳\n\n当以下情况时反驳：\n- 建议破坏现有功能\n- 审查者缺乏完整上下文\n- 违反 YAGNI（未使用的功能）\n- 对这个技术栈技术上不正确\n- 存在遗留/兼容性原因\n- 与你的人类伙伴的架构决策冲突\n\n**如何反驳：**\n- 使用技术推理，而非防御性\n- 提出具体问题\n- 引用工作测试/代码\n- 如果是架构问题，让你的人类伙伴参与\n\n**如果不愿意大声反驳的信号：** \"Circle K 有奇怪的事情发生\"\n\n## 确认正确的反馈\n\n当反馈正确时：\n```\n✅ \"已修复。[对更改的简要描述]\"\n✅ \"好发现 - [具体问题]。在 [位置] 已修复。\"\n✅ [直接修复并在代码中显示]\n\n❌ \"你绝对正确！\"\n❌ \"好观点！\"\n❌ \"感谢发现那个！\"\n❌ \"感谢 [任何内容]\"\n❌ 任何感谢表达\n```\n\n**为什么不感谢：** 行动说话。直接修复。代码本身表明你听到了反馈。\n\n**如果你发现自己要写\"谢谢\"：** 删除它。改为说明修复。\n\n## 优雅地纠正你的反驳\n\n如果你反驳了但错了：\n```\n✅ \"你是对的 - 我检查了 [X]，它确实 [Y]。现在实施。\"\n✅ \"验证了这一点，你是正确的。我最初的理解是错误的，因为 [原因]。正在修复。\"\n\n❌ 冗长的道歉\n❌ 为你反驳的原因辩护\n❌ 过度解释\n```\n\n事实陈述纠正并继续。\n\n## 常见错误\n\n| 错误 | 修复 |\n|------|------|\n| 表演性同意 | 说明要求或直接行动 |\n| 盲目实施 | 首先对照代码库验证 |\n| 批量实施而不测试 | 一次一个，测试每个 |\n| 假设审查者是对的 | 检查是否破坏事物 |\n| 避免反驳 | 技术正确性 > 舒适度 |\n| 部分实施 | 首先澄清所有项目 |\n| 无法验证，仍继续 | 说明限制，请求方向 |\n\n## 真实示例\n\n**表演性同意（错误）：**\n```\n审查者：\"移除遗留代码\"\n❌ \"你绝对正确！让我移除那个...\"\n```\n\n**技术验证（正确）：**\n```\n审查者：\"移除遗留代码\"\n✅ \"检查中... 构建目标是 10.15+，此 API 需要 13+。需要遗留代码以保持向后兼容。当前实现的 bundle ID 错误 - 修复它还是放弃 13 之前的支持？\"\n```\n\n**YAGNI（正确）：**\n```\n审查者：\"实施带有数据库、日期过滤器、CSV 导出的适当指标跟踪\"\n✅ \"搜索代码库 - 没有调用此端点。移除它（YAGNI）？还是我遗漏了使用情况？\"\n```\n\n**不清楚的项目（正确）：**\n```\n你的人类伙伴：\"修复项目 1-6\"\n你理解 1,2,3,6。对 4,5 不清楚。\n✅ \"理解 1,2,3,6。在实施之前需要澄清 4 和 5。\"\n```\n\n## GitHub 线程回复\n\n在 GitHub 上回复内联审查评论时，在评论线程中回复（`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`），而不是作为顶级 PR 评论。\n\n## 底线\n\n**外部反馈 = 要评估的建议，不是要遵循的命令。**\n\n验证。提问。然后实施。\n\n无表演性同意。始终保持技术严谨。\n"
+  },
+  {
+    "name": "release-flow",
+    "content": "---\nname: \"release-flow\"\ndescription: \"发布流程管理技能，管理整个发布生命周期。Invoke when you need to manage the full release lifecycle.\"\n---\n\n# release-flow - 发布流程管理技能\n\n## 概述\n\n本技能专注于管理整个发布生命周期，从发布计划到发布总结，确保发布过程规范、可控、可追溯。\n\n---\n\n## 与其他技能的衔接\n\n### 前置技能\n- **sdd-deploy** - 部署SDD已创建\n- **quality-gate** - 质量检查已通过\n\n### 后置技能\n- 发布完成\n- 复盘总结\n\n---\n\n## 核心功能\n\n### 1. 发布计划制定\n- 发布版本规划\n- 发布时间安排\n- 发布范围确定\n- 风险评估\n- 资源分配\n\n### 2. 发布风险评估\n- 功能风险分析\n- 技术风险分析\n- 业务风险分析\n- 风险等级判定\n- 风险应对措施\n\n### 3. 发布通知管理\n- 发布前通知\n- 发布中更新\n- 发布后通知\n- 异常通知\n- 通知记录\n\n### 4. 发布清单管理\n- 发布前检查清单\n- 发布中执行清单\n- 发布后验证清单\n- 回滚准备清单\n\n### 5. 发布后验证\n- 冒烟测试\n- 功能验证\n- 性能验证\n- 安全验证\n- 数据验证\n\n### 6. 发布回滚触发\n- 回滚触发条件\n- 回滚决策流程\n- 回滚执行监督\n- 回滚结果确认\n- 回滚记录\n\n### 7. 发布复盘流程\n- 发布情况总结\n- 问题分析\n- 经验教训\n- 改进计划\n- 流程优化建议\n\n---\n\n## 发布计划模板\n\n### 发布计划文档\n```markdown\n# 发布计划 - v1.0.0\n\n## 1. 发布概述\n- 版本号：v1.0.0\n- 发布时间：2024-01-01 14:00\n- 发布负责人：[姓名]\n- 发布类型：[新功能/修复/优化/重大变更]\n\n## 2. 发布内容\n### 新功能\n- 功能A：描述\n- 功能B：描述\n\n### 修复\n- Bug#123：描述\n- Bug#124：描述\n\n### 优化\n- 优化项1：描述\n- 优化项2：描述\n\n## 3. 发布时间安排\n| 时间节点 | 任务 | 负责人 |\n|---------|------|-------|\n| T-3天 | 发布计划确认 | 全员 |\n| T-2天 | 代码冻结 | 开发 |\n| T-1天 | 测试完成 | 测试 |\n| T-0天 | 发布执行 | 运维 |\n| T+1天 | 发布验证 | 全员 |\n\n## 4. 风险评估\n| 风险 | 等级 | 概率 | 影响 | 应对措施 |\n|-----|------|------|------|---------|\n| 数据库迁移失败 | P0 | 低 | 严重 | 准备回滚脚本，提前测试 |\n| 第三方服务异常 | P1 | 中 | 重要 | 提前沟通，准备降级方案 |\n\n## 5. 回滚计划\n- 回滚触发条件：见回滚方案\n- 回滚窗口：发布后24小时内\n- 回滚责任人：[姓名]\n```\n\n---\n\n## 发布检查清单模板\n\n### 发布前检查清单\n```markdown\n# 发布前检查清单 - v1.0.0\n\n## 代码检查\n- [ ] 所有代码已合并到发布分支\n- [ ] 无未提交代码\n- [ ] 代码已通过评审\n- [ ] 无已知阻断性bug\n\n## 测试检查\n- [ ] 所有测试用例通过\n- [ ] 测试覆盖率达标\n- [ ] 性能测试通过\n- [ ] 安全测试通过\n\n## 文档检查\n- [ ] 更新日志已编写\n- [ ] 用户文档已更新\n- [ ] API文档已更新\n- [ ] 运维文档已准备\n\n## 发布准备\n- [ ] 回滚方案已准备\n- [ ] 数据备份已完成\n- [ ] 监控告警已配置\n- [ ] 发布通知已发送\n- [ ] 相关人员已到位\n\n## 审批\n- [ ] 发布计划已审批\n- [ ] 风险评估已完成\n- [ ] 业务方同意发布\n- [ ] 负责人已签字\n```\n\n---\n\n## 发布记录模板\n\n### 发布记录文档\n```markdown\n# 发布记录 - v1.0.0\n\n## 1. 基本信息\n- 版本号：v1.0.0\n- 发布时间：2024-01-01 14:00\n- 发布耗时：30分钟\n- 发布状态：[成功/部分成功/失败/回滚]\n- 发布人：[姓名]\n\n## 2. 发布执行记录\n| 时间 | 操作 | 执行结果 | 备注 |\n|-----|------|---------|------|\n| 14:00 | 开始发布 | - | - |\n| 14:05 | 数据库迁移 | 成功 | - |\n| 14:15 | 部署应用 | 成功 | - |\n| 14:25 | 冒烟测试 | 成功 | - |\n| 14:30 | 发布完成 | 成功 | - |\n\n## 3. 发布后验证\n- [ ] 功能正常\n- [ ] 性能达标\n- [ ] 监控正常\n- [ ] 日志无错误\n- [ ] 用户反馈正常\n\n## 4. 问题记录\n| 问题 | 严重程度 | 处理方式 | 状态 |\n|-----|---------|---------|------|\n| 问题A | 轻微 | 后续修复 | 待处理 |\n\n## 5. 发布总结\n- 发布是否顺利：[是/否]\n- 主要问题：[描述]\n- 下次改进：[建议]\n```\n\n---\n\n## 回滚记录模板\n\n### 回滚记录文档\n```markdown\n# 回滚记录 - v1.0.0\n\n## 1. 回滚概述\n- 原发布版本：v1.0.0\n- 回滚到版本：v0.9.0\n- 回滚时间：2024-01-01 15:00\n- 回滚原因：[描述]\n- 回滚负责人：[姓名]\n\n## 2. 回滚触发条件\n- [ ] 核心功能不可用\n- [ ] 性能严重下降\n- [ ] 数据错误\n- [ ] 用户投诉激增\n\n## 3. 回滚执行记录\n| 时间 | 操作 | 执行结果 | 备注 |\n|-----|------|---------|------|\n| 15:00 | 触发回滚决策 | - | - |\n| 15:05 | 停止服务 | 成功 | - |\n| 15:10 | 恢复数据 | 成功 | - |\n| 15:20 | 部署旧版本 | 成功 | - |\n| 15:25 | 验证功能 | 成功 | - |\n| 15:30 | 回滚完成 | 成功 | - |\n\n## 4. 回滚结果验证\n- [ ] 应用版本正确\n- [ ] 数据恢复正常\n- [ ] 功能正常\n- [ ] 性能正常\n- [ ] 监控正常\n\n## 5. 回滚原因分析\n- 根因：[描述]\n- 预防措施：[建议]\n\n## 6. 后续计划\n- 修复问题：[时间]\n- 重新发布：[时间]\n```\n\n---\n\n## 发布复盘模板\n\n### 发布复盘文档\n```markdown\n# 发布复盘 - v1.0.0\n\n## 1. 复盘基本信息\n- 复盘时间：2024-01-02\n- 参与人员：[名单]\n- 发布版本：v1.0.0\n- 发布时间：2024-01-01\n- 发布结果：[成功/部分成功/失败/回滚]\n\n## 2. 发布情况总结\n### 做得好的\n- [ ] 方面1：描述\n- [ ] 方面2：描述\n\n### 可以改进的\n- [ ] 方面3：描述\n- [ ] 方面4：描述\n\n## 3. 问题分析\n| 问题 | 根因 | 影响 | 建议 |\n|-----|------|------|------|\n| 问题1 | 描述 | 描述 | 建议 |\n| 问题2 | 描述 | 描述 | 建议 |\n\n## 4. 经验教训\n- 教训1：描述\n- 教训2：描述\n- 教训3：描述\n\n## 5. 改进计划\n### 短期改进（1-2周）\n- [ ] 改进项1：负责人 - 截止时间\n- [ ] 改进项2：负责人 - 截止时间\n\n### 中期改进（1-2月）\n- [ ] 改进项3：负责人 - 截止时间\n- [ ] 改进项4：负责人 - 截止时间\n\n## 6. 流程优化建议\n- 建议1：描述\n- 建议2：描述\n- 建议3：描述\n\n## 7. 行动计划\n| 行动项 | 负责人 | 截止日期 | 状态 |\n|-------|-------|---------|------|\n| 行动1 | [姓名] | 2024-01-10 | 待开始 |\n| 行动2 | [姓名] | 2024-01-20 | 待开始 |\n```\n\n---\n\n## 发布生命周期管理\n\n### 发布状态流转\n```\n规划中 → 准备中 → 已就绪 → 发布中 → 已发布 → 验证中 → 已完成\n                        ↓\n                      回滚中 → 已回滚\n```\n\n### 发布阶段说明\n| 阶段 | 描述 | 关键动作 |\n|-----|------|---------|\n| 规划中 | 发布计划制定 | 制定计划、风险评估 |\n| 准备中 | 发布准备 | 代码冻结、测试完成 |\n| 已就绪 | 准备好发布 | 检查清单完成、审批通过 |\n| 发布中 | 执行发布 | 执行部署、监控状态 |\n| 已发布 | 发布完成 | 发布执行完成 |\n| 验证中 | 发布后验证 | 冒烟测试、功能验证 |\n| 已完成 | 发布结束 | 验证通过、复盘总结 |\n| 回滚中 | 执行回滚 | 触发回滚、执行回滚 |\n| 已回滚 | 回滚完成 | 回滚验证、分析总结 |\n\n---\n\n## 使用步骤\n\n### 步骤1：发布规划\n- 制定发布计划\n- 评估发布风险\n- 确定发布内容\n- 安排发布时间\n\n### 步骤2：发布准备\n- 完成代码冻结\n- 确保测试通过\n- 准备发布清单\n- 发送发布通知\n\n### 步骤3：执行发布\n- 执行发布检查清单\n- 执行发布操作\n- 监控发布状态\n- 处理发布问题\n\n### 步骤4：发布验证\n- 执行冒烟测试\n- 验证功能正常\n- 检查监控数据\n- 收集用户反馈\n\n### 步骤5：发布总结\n- 记录发布情况\n- 进行发布复盘\n- 总结经验教训\n- 制定改进计划\n\n---\n\n## 与其他技能的集成\n\n### 与sdd-deploy集成\n```\nsdd-deploy → 部署SDD → release-flow → 发布计划\n```\n\n### 与quality-gate集成\n```\nquality-gate → 质量通过 → release-flow → 发布执行\n```\n\n---\n\n## 最佳实践\n\n1. 每个发布都要有计划\n2. 发布前一定要有回滚方案\n3. 发布后要及时验证和总结\n4. 发布记录要完整可追溯\n5. 定期回顾和优化发布流程\n\n---\n\n## 常见问题\n\n### Q：什么时候可以发布？\nA：质量门禁通过，风险可控，相关方同意，准备工作完成\n\n### Q：发布中遇到问题怎么办？\nA：首先评估问题严重性，小问题继续发布并记录，严重问题考虑暂停或回滚\n\n### Q：发布后多久可以确认没问题？\nA：通常观察24-48小时，重点监控前几小时，有问题及时发现和处理\n"
+  },
+  {
+    "name": "requesting-code-review",
+    "content": "---\nname: requesting-code-review\ndescription: 在完成任务、实现主要功能或合并前使用，以验证工作是否满足要求\n---\n\n# 请求代码审查\n\n调度 superpowers:code-reviewer 子代理，在问题扩散前捕获它们。审查者获得精确设计的评估上下文 - 绝不是你的会话历史。这使审查者专注于工作产品，而不是你的思考过程，并保留你自己的上下文以继续工作。\n\n**核心原则：** 尽早审查，经常审查。\n\n## 何时请求审查\n\n**必须：**\n- 子代理驱动开发中的每个任务后\n- 完成主要功能后\n- 合并到 main 之前\n\n**可选但有价值：**\n- 卡住时（新鲜视角）\n- 重构前（基线检查）\n- 修复复杂错误后\n\n## 如何请求\n\n**1. 获取 git SHAs：**\n```bash\nBASE_SHA=$(git rev-parse HEAD~1)  # 或 origin/main\nHEAD_SHA=$(git rev-parse HEAD)\n```\n\n**2. 调度代码审查子代理：**\n\n使用 Task 工具与 superpowers:code-reviewer 类型，填写 `code-reviewer.md` 中的模板\n\n**占位符：**\n- `{WHAT_WAS_IMPLEMENTED}` - 你刚刚构建的内容\n- `{PLAN_OR_REQUIREMENTS}` - 它应该做什么\n- `{BASE_SHA}` - 起始提交\n- `{HEAD_SHA}` - 结束提交\n- `{DESCRIPTION}` - 简短摘要\n\n**3. 根据反馈行动：**\n- 立即修复关键问题\n- 在继续之前修复重要问题\n- 记录次要问题以便以后处理\n- 如果审查者错误，反驳（带有理由）\n\n## 示例\n\n```\n[刚刚完成任务 2：添加验证函数]\n\n你：让我在继续之前请求代码审查。\n\nBASE_SHA=$(git log --oneline | grep \"Task 1\" | head -1 | awk '{print $1}')\nHEAD_SHA=$(git rev-parse HEAD)\n\n[调度 superpowers:code-reviewer 子代理]\n  WHAT_WAS_IMPLEMENTED: 对话索引的验证和修复函数\n  PLAN_OR_REQUIREMENTS: docs/superpowers/plans/deployment-plan.md 中的任务 2\n  BASE_SHA: a7981ec\n  HEAD_SHA: 3df7661\n  DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，具有 4 种问题类型\n\n[子代理返回]:\n  优势：干净的架构，真实测试\n  问题：\n    重要：缺少进度指示器\n    次要：报告间隔的魔法数字 (100)\n  评估：可以继续\n\n你：[修复进度指示器]\n[继续到任务 3]\n```\n\n## 与工作流集成\n\n**子代理驱动开发：**\n- 每个任务后审查\n- 在问题复合前捕获它们\n- 在移至下一个任务前修复\n\n**执行计划：**\n- 每批（3 个任务）后审查\n- 获取反馈，应用，继续\n\n**临时开发：**\n- 合并前审查\n- 卡住时审查\n\n## 红旗\n\n**永远不要：**\n- 因为\"简单\"而跳过审查\n- 忽略关键问题\n- 带着未修复的重要问题继续\n- 与有效的技术反馈争论\n\n**如果审查者错误：**\n- 用技术推理反驳\n- 展示证明它有效的代码/测试\n- 请求澄清\n\n请参阅模板：requesting-code-review/code-reviewer.md\n"
+  },
+  {
+    "name": "requirement-completion-officer",
+    "content": "---\nname: 需求补全\ndescription: Analyzes user requirements, identifies missing information, and asks core questions to complete the requirements. Invoke when user presents a new project or feature request that needs clarification.\n---\n\n# 需求补全官\n\n## 核心功能\n\n本技能用于分析用户提出的需求，识别其中缺失的关键信息，并按优先级提出最核心的问题，帮助用户补全需求，为后续的方案设计和实现提供清晰的指导。\n\n## 执行规则\n\n1. **禁止立刻给方案**：当用户提出需求时，首先进行分析，不直接提供解决方案\n2. **识别缺失信息**：判断需求中缺失的关键信息\n3. **优先级提问**：按优先级只问最核心的3-7个问题，不冗余\n4. **主动补全维度**：重点覆盖以下维度：\n   - 核心目标\n   - 服务对象\n   - 使用场景与约束\n   - 输入与输出要求\n   - 成功验收标准\n   - 时间/预算限制\n   - 技术/资源限制\n   - 风险边界与必选/可选要求\n5. **结构化梳理**：若需求模糊，先结构化梳理为：\n   - 目标\n   - 已知条件\n   - 缺失信息\n   - 建议补充项\n6. **信息完整后再输出方案**：确保信息完整后，再输出正式方案\n7. **不擅自补设定**：不确定的信息直接询问用户\n8. **输出风格**：短、直接、结构化\n\n## 使用流程\n\n1. **接收需求**：用户提出新的项目或功能需求\n2. **初步分析**：快速浏览需求，判断是否清晰完整\n3. **结构化梳理**：将需求拆解为目标、已知条件、缺失信息和建议补充项\n4. **优先级提问**：针对缺失信息，按重要性提出3-7个核心问题\n5. **收集反馈**：等待用户回答问题\n6. **信息整合**：根据用户反馈，整合完整的需求信息\n7. **方案输出**：信息完整后，输出正式的解决方案\n\n## 应用场景\n\n- 产品经理提出新功能需求\n- 开发人员需要明确项目范围\n- 设计师需要了解设计约束\n- 项目管理者需要确定项目边界\n\n## 输出格式示例\n\n### 需求分析\n\n**目标**：\n- [用户提出的核心目标]\n\n**已知条件**：\n- [已明确的需求信息]\n\n**缺失信息**：\n- [需要补充的关键信息]\n\n**建议补充项**：\n- [建议用户提供的额外信息]\n\n### 核心问题\n\n1. [问题1]\n2. [问题2]\n3. [问题3]\n4. [问题4]\n5. [问题5]\n\n## 注意事项\n\n- 保持客观中立，不偏向任何特定解决方案\n- 聚焦于需求本身，不深入技术实现细节\n- 尊重用户的专业知识，避免提出过于基础的问题\n- 及时调整问题优先级，根据用户反馈动态调整分析方向\n- 确保所有问题都与需求的核心目标相关\n\n## 示例\n\n### 输入\n用户：\"我需要一个电商APP的购物车功能\"\n\n### 输出\n\n**需求分析**\n\n**目标**：\n- 实现电商APP的购物车功能\n\n**已知条件**：\n- 应用类型：电商APP\n- 功能模块：购物车\n\n**缺失信息**：\n- 核心目标：购物车的具体功能需求和业务逻辑\n- 服务对象：目标用户群体\n- 使用场景：用户如何添加、管理和结算商品\n- 输入与输出：商品添加方式和结算流程\n- 成功验收标准：功能验证方法\n- 技术/资源限制：技术栈和开发资源\n- 风险边界：异常处理和边界情况\n\n**建议补充项**：\n- 与其他模块的集成需求\n- 性能要求和响应时间\n- 安全考虑和数据保护\n\n**核心问题**\n\n1. 购物车需要支持哪些核心功能？（如添加商品、修改数量、删除商品、优惠券使用等）\n2. 目标用户群体是什么？（如普通消费者、企业用户等）\n3. 购物车的使用场景有哪些？（如移动端、PC端、不同网络环境等）\n4. 购物车与结算流程的集成方式是什么？\n5. 有哪些技术栈和开发资源限制？\n6. 性能要求是什么？（如响应时间、并发处理能力等）\n7. 有哪些安全和数据保护要求？"
+  },
+  {
+    "name": "sdd",
+    "content": "---\nname: sdd\ndescription: 用于将大型需求拆分为用户故事、UI设计、前后端架构边界、数据库/API契约与子代理可用的SDD功能规格，支持个人开发，适配Superpowers/Trae-CN全流程开发。\n---\n\n# SDD 需求拆分（个人开发版）\n\n## 概述\n\n本技能提供一套**\"垂直切片+水平分层\"双模式**需求拆分流程，兼顾敏捷快速交付与架构规范，专为个人开发者设计：\n\n**大需求 → 第0步：Epic拆分（超大需求适用）→ 第0.5步：拆用户故事 → 第1步：拆UI设计 → 第2步：拆前后端分离架构 → 第3步：拆数据库+接口 → 第4步：拆SDD**\n\n核心目的：\n- 既保证**快速交付用户价值**，又确保**技术架构规范**\n- 明确前后端**权责边界与协作契约**\n- 产出子代理可直接消费的**SDD功能规格**\n- 适配Superpowers/Trae-CN的**子代理驱动开发**与**测试驱动开发**工作流\n\n---\n\n## 何时使用\n\n- 你有一个**大型、模糊、跨模块**的需求/想法，需要结构化拆解\n- 项目采用**前后端分离架构**，需要明确技术边界\n- 在 **Superpowers / Trae-CN** 中进行**完整全流程开发**\n- 需要**敏捷迭代+架构规范**双保障，既快速交付又避免技术债务\n\n---\n\n## 核心流程\n\n```dot\ndigraph requirement_splitting {\n    rankdir=TB;\n    node [shape=box, style=filled, fillcolor=lightblue];\n\n    \"大需求\":::start -> \"第0步:Epic拆分(超大需求)\":::epic;\n    \"第0步:Epic拆分(超大需求)\":::epic -> \"第0.5步:拆用户故事\":::agile;\n    \"第0.5步:拆用户故事\":::agile -> \"第1步:拆UI设计\":::step1;\n    \"第1步:拆UI设计\":::step1 -> \"第2步:拆前后端架构\":::step2;\n    \"第2步:拆前后端架构\":::step2 -> \"第3步:拆数据库+接口\":::step3;\n    \"第3步:拆数据库+接口\":::step3 -> \"第4步:拆SDD\":::step4;\n\n    {rank=same; \"大需求\"}\n    {rank=same; \"第0步:Epic拆分(超大需求)\"}\n    {rank=same; \"第0.5步:拆用户故事\"}\n    {rank=same; \"第1步:拆UI设计\"}\n    {rank=same; \"第2步:拆前后端架构\"}\n    {rank=same; \"第3步:拆数据库+接口\"}\n    {rank=same; \"第4步:拆SDD\"}\n\n    classDef start fillcolor=lightgreen;\n    classDef epic fillcolor=lightcoral;\n    classDef agile fillcolor=lightcoral;\n    classDef step1 fillcolor=lightcyan;\n    classDef step2 fillcolor=lightcyan;\n    classDef step3 fillcolor=lightcyan;\n    classDef step4 fillcolor=lightyellow;\n}\n```\n\n流程本质：**先垂直切片（用户价值维度），再水平分层（技术栈维度）**\n优势：**既保证独立交付价值，又确保技术架构规范**\n\n---\n\n## 个人敏捷工作流\n\n### 1. 双模式工作流\n\n```\n大需求 → Epic拆分（可选）→ 拆用户故事 → 按故事优先级分批 → 每批内执行水平拆分 → 子代理开发 → 测试验收 → 上线 → 下一批故事\n```\n\n### 2. 关键实践\n\n| 实践 | 具体做法 | 优势 |\n|------|----------|------|\n| 分批交付 | 按用户故事优先级分组，每批1–3个故事，分批完成水平拆分与开发 | 避免全量冻结，支持快速迭代，降低风险 |\n| 并行开发 | 前端按Mock数据开发，后端按契约开发，互不依赖 | 缩短迭代周期，提高开发效率 |\n| 契约版本化 | 每批故事对应一个契约版本，变更只影响当前批次 | 控制变更范围，减少返工成本 |\n| 子代理适配 | 每个SDD对应一个子代理任务，完成后自动审查 | 适配Superpowers/Trae-CN工作流，保证质量 |\n\n---\n\n## 第0步：Epic拆分（超大需求适用）\n\n### 目标\n\n将**跨越多个Sprint、涉及多模块**的超大需求（Epic）拆分为可管理的Feature和Story，确保价值渐进交付，降低风险。\n\n### Epic定义与识别标准\n\n什么是Epic？\n- **范围**：预计超过2周完成\n- **价值**：代表宏观用户价值或业务目标\n- **特点**：模糊性高，细节不明确，需要进一步拆解\n\n何时需要先拆Epic？\n✅ 需求描述中包含\"完整\"\"全部\"\"全面\"等词汇\n✅ 估算工作量>10人天\n✅ 涉及≥3个核心模块\n✅ 跨平台需求且各平台工作量不均衡\n\n### Epic三层拆分法（Epic→Feature→Story）\n\n```markdown\n# Epic拆分示例：电商购物流程\n\n## 1. Epic（顶级）\n- 名称：构建完整电商购物流程\n- 价值：用户可浏览商品→加入购物车→结算→支付→查看订单\n- 估算：6周\n\n## 2. Feature（中层，按业务流程拆分）\n- Feature 1：商品浏览与搜索（第1–2周）\n- Feature 2：购物车管理（第2–3周）\n- Feature 3：订单创建与管理（第3–4周）\n\n## 3. Story（底层，按用户价值拆分）\n### Feature 1：商品浏览与搜索\n- US-001：浏览商品列表\n- US-002：搜索商品\n- US-003：查看商品详情\n```\n\n### 6种Epic拆分模式（按场景选择）\n\n| 拆分模式 | 适用场景 | 示例 |\n|----------|----------|------|\n| **按用户旅程拆分** | 有明确用户操作流程的功能 | 购物流程：浏览→详情→加购→结算→订单 |\n| **按功能模块拆分** | 模块化强的系统 | 电商系统：用户→商品→订单→支付 |\n| **按平台适配拆分** | 跨平台开发 | 登录功能：Web→iOS→Android |\n| **按复杂度分层拆分** | 功能复杂度差异大的功能 | 搜索功能：基础搜索→高级筛选→智能推荐 |\n| **按时间阶段拆分** | 有明确时间节点的功能 | 会员系统：MVP版→高级版→尊享版 |\n\n---\n\n## 第0.5步：拆用户故事\n\n### 目标\n\n把大需求拆成**可独立交付、有用户价值**的用户故事，每个故事覆盖\"页面+交互+业务+数据\"完整链路，符合**INVEST原则**（独立、可协商、有价值、可估算、小、可测试）。\n\n### 产出\n\n`docs/stories/user_stories.md`\n\n### 故事模板\n\n```markdown\n# 用户故事清单\n\n## 格式\n\n作为[用户角色]，我想要[功能]，以便[价值]\n\n## Epic（可选，用于超大需求）\n\n### Epic：用户认证与授权\n\n包含用户注册、登录、权限管理等相关功能。\n\n## 核心故事（按优先级排序）\n\n### 故事1：用户登录系统\n- **优先级**：P0（最高）\n- **估算**：3天（或5故事点）\n- **内容**：作为未登录用户，我想要登录系统，以便访问个人中心和下单\n- **验收标准（BDD格式）**：\n  - Given 用户未登录，访问登录页\n  - When 输入正确用户名密码并点击登录\n  - Then 登录成功，跳转到首页\n  - And Token保存到本地存储\n- **验收标准（规则列表）**：\n  - ✅ 用户可以通过用户名/密码登录\n  - ✅ 登录成功后跳转到首页\n  - ✅ 登录失败显示友好提示\n  - ✅ 支持\"记住我\"功能（7天免登录）\n- **关联页面**：登录页\n- **前置依赖**：无\n- **非功能需求**：页面响应时间≤2秒\n\n### 故事2：浏览商品列表\n- **优先级**：P0\n- **估算**：2天\n- **内容**：作为登录用户，我想要浏览商品列表，以便选择商品\n- **验收标准**：\n  - Given 用户已登录，访问首页\n  - When 查看商品列表\n  - Then 显示商品按分类展示，支持分页\n- **关联页面**：首页、商品列表页\n- **前置依赖**：故事1\n\n### 故事3：查看商品详情\n- **优先级**：P1\n- **估算**：2天\n- **内容**：作为登录用户，我想要查看商品详情，以便了解商品信息\n- **验收标准**：显示商品完整信息（图片、描述、价格、库存）\n- **关联页面**：商品详情页\n- **前置依赖**：故事2\n```\n\n### 故事验收标准编写黄金法则\n\n1. **可测试性**：每个标准都能被验证，避免模糊表述（如\"应该很快\"→\"响应时间≤2秒\"）\n2. **无歧义**：使用精确术语，避免主观描述\n3. **完整性**：覆盖主流程、异常流程、边界条件\n4. **价值导向**：始终围绕用户价值，不包含技术实现细节\n\n### 三种验收标准格式\n\n#### 1. BDD场景格式（推荐）\n```markdown\n### 主场景\nGiven [初始状态/前置条件]\nWhen [用户执行的关键动作]\nThen [系统预期结果]\nAnd [附加验证点1]\n```\n\n#### 2. 规则列表格式（适合简单功能）\n```markdown\n- ✅ 必须支持用户名/邮箱/手机号三种登录方式\n- ✅ 密码输入框必须隐藏明文显示\n- ✅ 登录按钮在表单未填写完整时禁用\n```\n\n#### 3. 多平台矩阵格式（适合复杂跨平台功能）\n| 场景 | 操作 | 预期结果（Web） | 预期结果（iOS） |\n|------|------|----------------|----------------|\n| 正常登录 | 输入正确账号密码 | 跳转首页 | 跳转首页 |\n\n### 敏捷故事拆分方法\n\n| 方法 | 适用场景 | 示例 |\n|------|----------|------|\n| 按用户旅程拆分 | 有明确用户操作流程的功能 | 购物流程：浏览→详情→加购→结算→订单 |\n| 按数据边界拆分 | 包含多数据实体的功能 | 简历功能：基本信息→工作经历→教育背景 |\n| 按操作路径拆分 | 有多种执行路径的功能 | 登录功能：正常登录→忘记密码→注册 |\n| 按优先级拆分 | 大型复杂功能 | 支付功能：基础支付→优惠券→积分抵扣 |\n\n### 故事拆分原则\n\n1. 每个故事必须**可独立交付**，能直接给用户带来价值\n2. 每个故事覆盖**UI+前端交互+后端业务+数据库**完整链路\n3. 故事粒度以**1–3天**可完成为宜\n4. 优先拆分**核心价值**故事，再拆分边缘功能\n5. 每个故事必须有明确的**验收标准**和**优先级**\n\n---\n\n## 第1步：拆UI设计\n\n### 目标\n\n把用户故事拆成**页面清单 + 页面范围说明**，只关心\"用户看到什么、怎么操作\"，**不涉及技术实现、接口、数据库**。\n\n### 产出\n\n`docs/ui/pages.md`\n\n### 模板\n\n```markdown\n# UI 页面清单\n\n## 1. 公共页面\n\n- 登录页（/login）：用户登录入口，关联故事1\n- 注册页（/register）：新用户注册入口\n- 404页：页面不存在时显示\n- 500页：服务器错误时显示\n\n## 2. 业务页面（按用户故事旅程拆分）\n\n- 首页（/home）：关联故事2，展示推荐商品和分类导航\n- 商品列表页（/goods/list）：关联故事2，展示商品列表和筛选\n- 商品详情页（/goods/detail/:id）：关联故事3，展示商品完整信息\n- 购物车页（/cart）：关联故事4，展示购物车商品和操作\n- 结算页（/checkout）：关联故事5，确认订单信息和支付\n- 订单列表页（/order/list）：展示用户历史订单\n- 订单详情页（/order/detail/:id）：关联故事5，展示订单详细信息\n- 个人中心（/profile）：用户信息管理\n\n## 3. 设计规范\n\n- 设计工具：Figma / 手绘稿\n- 主色：#165DFF\n- 字体：Inter，基础字号 14px\n- 响应式：桌面优先，兼容平板（1024px以上）\n- 组件库：使用Ant Design（或指定其他）\n```\n\n### 拆分原则\n\n- **一个独立页面 = 一条记录**，不合并\n- 只拆**页面路由、页面名称、核心用途**，关联对应的用户故事\n- **严禁**出现接口字段、表结构、技术选型\n- 覆盖**核心用户旅程**，边缘页面可后续补充\n\n---\n\n## 第2步：拆前后端分离架构\n\n### 目标\n\n明确**前端做什么、后端做什么、依赖关系**，一刀切开前后端边界，**互不越界、各司其职**，同时支持敏捷并行开发。\n\n### 产出\n\n`docs/architecture/frontend-backend.md`\n\n### 模板\n\n```markdown\n# 前后端分离架构\n\n## 1. 前端职责\n\n- 页面渲染（UI 见 docs/ui/pages.md）\n- 路由管理（/login、/goods/list…）\n- 客户端状态管理（用户信息、购物车）\n- 表单校验、交互反馈、异常提示\n- 调用后端 RESTful API（不写核心业务逻辑）\n- Mock数据并行开发，不依赖后端进度\n\n## 2. 后端职责\n\n- 提供 RESTful API（契约见 docs/api/contract.md）\n- 核心业务逻辑（下单、支付、库存扣减、权限校验）\n- 数据库读写（表结构见 docs/database/schema.md）\n- 数据校验、鉴权、限流、日志、事务\n- 无页面渲染、无交互逻辑\n- 按接口契约开发\n\n## 3. 分离边界\n\n- 前端：**无数据库、无核心业务逻辑** → 只发请求、渲染结果\n- 后端：**无页面、无交互** → 只处理数据、返回标准 JSON\n- 协作模式：前端 Mock 并行开发；后端按契约开发；联调前先对齐契约\n- 敏捷迭代：按用户故事优先级分批交付，每批完成后进行回归测试\n\n## 4. 技术选型（可选）\n\n- 前端框架：React / Vue / Angular\n- 状态管理：Redux / Vuex / MobX\n- UI组件库：Ant Design / Element Plus\n- 后端框架：Node.js / Java / Python / Go\n- 数据库：MySQL / PostgreSQL / MongoDB\n- 缓存：Redis\n```\n\n### 拆分原则\n\n- **单一职责**：前端=UI/交互；后端=业务/数据\n- **依赖单向**：前端依赖后端 API；后端不依赖前端\n- **边界刚性**：不允许前端写复杂业务、不允许后端渲染页面\n- **敏捷适配**：支持按用户故事分批交付，不要求全量完成后再上线\n\n---\n\n## 第3步：拆数据库+接口\n\n### 目标\n\n定义**数据库表结构 + RESTful API 契约**，作为前后端协作的**唯一事实来源**，支持敏捷迭代中的契约版本管理。\n\n### 产出\n\n- `docs/database/schema.md`（表结构）\n- `docs/api/contract.md`（接口契约）\n\n### 数据库模板\n\n```markdown\n# 数据库设计\n\n## 用户表（user）- 关联故事1\n\n- id（PK，自增，BIGINT）\n- username（唯一，VARCHAR(50)，用户名）\n- password（VARCHAR(255)，加密存储）\n- email（唯一，VARCHAR(100)）\n- avatar（VARCHAR(255)，头像URL，可选）\n- status（TINYINT，状态：0-禁用，1-正常）\n- create_time（DATETIME，创建时间）\n- update_time（DATETIME，更新时间）\n\n## 商品表（goods）- 关联故事2、3\n\n- id（PK，自增，BIGINT）\n- name（VARCHAR(200)，商品名称）\n- description（TEXT，商品描述）\n- price（DECIMAL(10,2)，价格）\n- original_price（DECIMAL(10,2)，原价）\n- stock（INT，库存）\n- status（TINYINT，状态：0-下架，1-上架）\n- category_id（FK，分类ID）\n- main_image（VARCHAR(255)，主图URL）\n- create_time（DATETIME，创建时间）\n- update_time（DATETIME，更新时间）\n\n## 购物车表（cart）- 关联故事4\n\n- id（PK，自增，BIGINT）\n- user_id（FK → user.id）\n- goods_id（FK → goods.id）\n- quantity（INT，数量）\n- create_time（DATETIME，创建时间）\n- update_time（DATETIME，更新时间）\n\n## 订单表（order）- 关联故事5\n\n- id（PK，自增，BIGINT）\n- order_no（VARCHAR(50)，订单号，唯一）\n- user_id（FK → user.id）\n- total_price（DECIMAL(10,2)，订单总价）\n- status（TINYINT，状态：0-待支付，1-已支付，2-已发货，3-已完成，4-已取消）\n- address（JSON，收货地址）\n- create_time（DATETIME，创建时间）\n- update_time（DATETIME，更新时间）\n\n## 订单项表（order_item）- 关联故事5\n\n- id（PK，自增，BIGINT）\n- order_id（FK → order.id）\n- goods_id（FK → goods.id）\n- goods_name（VARCHAR(200)，商品名称快照）\n- goods_price（DECIMAL(10,2)，商品价格快照）\n- quantity（INT，购买数量）\n- create_time（DATETIME，创建时间）\n\n## 索引设计\n\n- user表：username、email\n- goods表：category_id、status\n- cart表：user_id\n- order表：user_id、order_no\n- order_item表：order_id\n```\n\n### 接口契约模板\n\n```markdown\n# 接口契约（RESTful，JSON，版本 v1）\n\n## 通用规则\n\n- 基础路径：/api/v1\n- 请求/响应格式：JSON\n- 认证：JWT（请求头 Authorization: Bearer {token}）\n- 版本管理：每批用户故事交付后更新契约版本\n- 响应统一格式：\n\n```json\n{\n  \"code\": 0,\n  \"message\": \"success\",\n  \"data\": {}\n}\n```\n\n## 用户模块（关联故事1）\n\n### POST /api/v1/auth/login - 用户登录\n\n请求：\n```json\n{\n  \"username\": \"string\",\n  \"password\": \"string\",\n  \"remember\": false\n}\n```\n\n响应成功（200）：\n```json\n{\n  \"code\": 0,\n  \"message\": \"success\",\n  \"data\": {\n    \"token\": \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...\",\n    \"user\": {\n      \"id\": 1,\n      \"username\": \"user1\",\n      \"email\": \"user1@example.com\",\n      \"avatar\": \"https://example.com/avatar.jpg\"\n    }\n  }\n}\n```\n\n响应失败（401）：\n```json\n{\n  \"code\": 401,\n  \"message\": \"用户名或密码错误\",\n  \"data\": null\n}\n```\n\n### POST /api/v1/auth/register - 用户注册\n\n请求：\n```json\n{\n  \"username\": \"string\",\n  \"password\": \"string\",\n  \"email\": \"string\"\n}\n```\n\n### GET /api/v1/user/info - 获取当前用户信息\n\n需要认证。\n\n响应：\n```json\n{\n  \"code\": 0,\n  \"message\": \"success\",\n  \"data\": {\n    \"id\": 1,\n    \"username\": \"user1\",\n    \"email\": \"user1@example.com\",\n    \"avatar\": \"https://example.com/avatar.jpg\",\n    \"createTime\": \"2024-01-01T00:00:00Z\"\n  }\n}\n```\n\n## 商品模块（关联故事2、3）\n\n### GET /api/v1/goods/list - 商品列表（分页）\n\n请求参数（Query）：\n- page（INT，页码，默认1）\n- pageSize（INT，每页数量，默认20）\n- categoryId（INT，分类ID，可选）\n- keyword（STRING，搜索关键词，可选）\n\n响应：\n```json\n{\n  \"code\": 0,\n  \"message\": \"success\",\n  \"data\": {\n    \"list\": [\n      {\n        \"id\": 1,\n        \"name\": \"商品名称\",\n        \"price\": 99.99,\n        \"originalPrice\": 199.99,\n        \"mainImage\": \"https://example.com/image.jpg\",\n        \"status\": 1,\n        \"stock\": 100\n      }\n    ],\n    \"total\": 100,\n    \"page\": 1,\n    \"pageSize\": 20\n  }\n}\n```\n\n### GET /api/v1/goods/detail/:id - 商品详情\n\n响应：\n```json\n{\n  \"code\": 0,\n  \"message\": \"success\",\n  \"data\": {\n    \"id\": 1,\n    \"name\": \"商品名称\",\n    \"description\": \"商品描述\",\n    \"price\": 99.99,\n    \"originalPrice\": 199.99,\n    \"mainImage\": \"https://example.com/image.jpg\",\n    \"images\": [\"url1\", \"url2\"],\n    \"status\": 1,\n    \"stock\": 100,\n    \"createTime\": \"2024-01-01T00:00:00Z\"\n  }\n}\n```\n\n## 购物车模块（关联故事4）\n\n### POST /api/v1/cart/add - 添加商品到购物车\n\n需要认证。\n\n请求：\n```json\n{\n  \"goodsId\": 1,\n  \"quantity\": 2\n}\n```\n\n### GET /api/v1/cart/list - 获取购物车列表\n\n需要认证。\n\n响应：\n```json\n{\n  \"code\": 0,\n  \"message\": \"success\",\n  \"data\": [\n    {\n      \"id\": 1,\n      \"goodsId\": 1,\n      \"goodsName\": \"商品名称\",\n      \"goodsPrice\": 99.99,\n      \"mainImage\": \"https://example.com/image.jpg\",\n      \"quantity\": 2,\n      \"stock\": 100\n    }\n  ]\n}\n```\n\n## 订单模块（关联故事5）\n\n### POST /api/v1/order/create - 创建订单\n\n需要认证。\n\n请求：\n```json\n{\n  \"addressId\": 1,\n  \"paymentMethod\": \"alipay\"\n}\n```\n\n响应：\n```json\n{\n  \"code\": 0,\n  \"message\": \"success\",\n  \"data\": {\n    \"orderId\": 1,\n    \"orderNo\": \"ORD202401010001\"\n  }\n}\n```\n\n### GET /api/v1/order/list - 订单列表\n\n需要认证。\n\n### GET /api/v1/order/detail/:id - 订单详情\n\n需要认证。\n```\n\n### 拆分原则\n\n- **先数据、后接口**：表结构稳定后再定义接口\n- **资源命名 RESTful**：名词复数、HTTP 方法语义化\n- **契约即法律**：开发前必须固化契约，变更需同步更新\n- **敏捷适配**：按用户故事分批定义契约，支持增量交付，不要求一次性定全量\n\n---\n\n## 第4步：拆SDD\n\n### 前提\n\n**用户故事 → UI → 架构 → 数据库/接口按批次固化后**，再拆对应批次的 SDD。\n\nSDD 是**给子代理的最小可执行单元**：一个 SDD = 一个用户故事/子故事 = 一个子代理任务，符合**垂直切片**原则。\n\n### 目标\n\n把\"页面+接口+数据\"按**用户故事维度垂直切分**，生成子代理可直接执行、测试、交付的规格文档，适配 Superpowers/Trae-CN 的**子代理驱动开发**与**测试驱动开发**工作流。\n\n### SDD 目录结构\n\n```\nspecs/\n  story1-login/\n    login-frontend.md\n    login-backend.md\n  story2-goods/\n    goods-list-frontend.md\n    goods-list-backend.md\n    goods-detail-frontend.md\n    goods-detail-backend.md\n  story3-order/\n    ...\n```\n\n### 单个 SDD 模板\n\n```markdown\n# SDD：用户登录（关联用户故事1）\n\n## 1. 目标\n\n一句话清晰描述本功能要实现的业务价值（与用户故事一致）。\n\n让用户可以通过用户名和密码安全登录系统，获取访问权限。\n\n## 2. 依赖\n\n- 页面：登录页（引用 docs/ui/pages.md）\n- 接口：POST /api/v1/auth/login（引用 docs/api/contract.md）\n- 数据库：user表（引用 docs/database/schema.md）\n- 架构：前后端分离（引用 docs/architecture/frontend-backend.md）\n- 前置故事：无\n\n## 3. 验收标准（BDD风格）\n\n### 正常流程\n\n- Given 用户未登录，访问登录页\n- When 输入正确的用户名和密码，点击登录按钮\n- Then 登录成功，跳转到首页，显示用户信息\n- And Token保存到本地存储，支持自动登录\n\n### 异常流程\n\n- Given 用户未登录，访问登录页\n- When 输入错误的用户名或密码，点击登录按钮\n- Then 显示\"用户名或密码错误\"提示，停留在登录页\n\n- Given 用户未登录，访问登录页\n- When 用户名或密码为空，点击登录按钮\n- Then 显示字段验证提示\n\n- Given 用户已登录，访问登录页\n- When 页面加载\n- Then 自动跳转到首页\n\n## 4. 非功能需求\n\n- **性能**：页面响应时间≤2秒，API响应时间≤500ms\n- **安全**：密码加密传输，使用HTTPS\n- **兼容**：兼容主流浏览器\n\n## 5. 技术风险\n\n- **风险**：密码明文传输\n- **缓解措施**：使用HTTPS，密码加密传输\n- **风险**：暴力破解\n- **缓解措施**：添加登录失败次数限制，超过5次锁定15分钟\n\n## 6. 测试要点\n\n- 单元测试：登录表单验证、Token存储逻辑\n- 接口测试：正常登录、错误密码、空参数\n- E2E测试：完整登录流程\n- 安全测试：SQL注入、XSS防护\n\n## 7. 子代理执行说明\n\n- 角色：全栈 / 前端+后端\n- 产出：代码 + 单元测试 + 接口/页面联调通过\n- 实践：\n  1. 遵循 TDD 流程：先写测试 → 再写代码 → 重构\n  2. 完成后通过两阶段审查：spec合规性审查 → 代码质量审查\n  3. 审查通过后提交，进入下一个子任务\n```\n\n### 拆分原则\n\n- **垂直切片**：每个 SDD 覆盖UI+接口+数据完整链路，可独立交付价值\n- **故事驱动**：SDD 严格对应用户故事，不跨故事拆分\n- **依赖显式化**：所有依赖必须引用已固化的设计文档\n- **验收标准可测试**：采用 BDD 风格，输入输出明确，无模糊描述\n\n---\n\n## 非功能需求处理指南\n\n### 非功能需求分类与处理方式\n\n| 分类 | 示例 | 处理方式 | 优先级 |\n|------|------|----------|--------|\n| **性能** | 响应时间≤2秒，并发用户≥100 | 融入Story验收标准 | 高 |\n| **安全性** | 数据加密，权限控制，防SQL注入 | 融入DoD + 独立测试 | 最高 |\n| **可用性** | 系统可用性≥99.9% | 架构设计 | 高 |\n| **兼容性** | 适配iOS 14+，Android 10+ | 平台适配Story | 中 |\n| **可维护性** | 代码覆盖率≥80% | 融入DoD | 中 |\n\n### 个人DoD（完成的定义）\n\n```markdown\n# 个人DoD（包含非功能需求）\n\n1. 功能通过所有验收测试\n2. 代码通过静态分析，无高危漏洞\n3. 单元测试覆盖率≥80%\n4. 页面响应时间≤2秒\n5. 适配目标平台所有主流版本\n6. 符合安全规范（如OWASP Top 10防护）\n7. 文档更新完成\n```\n\n### 非功能需求融入验收标准示例\n\n```markdown\n## 故事ID: US-001（商品搜索）\n\n**验收标准**：\n1. 功能：支持关键词搜索、分类筛选、价格区间筛选\n2. 性能：搜索结果返回时间≤1秒（1000条数据）\n3. 可用性：无结果时显示友好提示，提供推荐商品\n4. 兼容性：在所有目标平台显示一致\n```\n\n---\n\n## 故事估算方法指南\n\n### 两种核心估算方法对比\n\n| 估算方法 | 定义 | 优点 | 缺点 | 适用场景 |\n|------|------|------|------|------|\n| **理想人天** | 无中断情况下完成任务的时间（人天） | 直观易懂，适合个人开发 | 受个人能力影响大 | 个人开发、小项目 |\n| **故事点** | 相对工作量单位，基于复杂度综合评估 | 不依赖个人能力，长期稳定 | 需要历史数据校准 | 长期项目 |\n\n### 理想人天估算方法（推荐个人开发使用）\n\n```markdown\n# 理想人天定义\n\n1. 理想人天 = 纯开发时间，不含会议、沟通、测试、中断\n2. 1理想人天 = 8小时专注开发时间\n3. 实际时间 ≈ 理想人天 × 1.5（考虑各种中断）\n\n# 任务分解估算示例\n\n## 故事ID: US-001（登录功能）\n\n### 任务分解：\n1. UI设计：0.5理想人天\n2. 前端开发：1理想人天\n3. 后端API开发：1理想人天\n4. 集成测试：0.5理想人天\n\n### 总估算：3理想人天\n### 实际计划：4.5天（考虑缓冲）\n```\n\n### 估算避坑指南\n\n#### ❌ 常见错误\n\n1. **过度乐观**：忽视边界条件和异常处理\n2. **技术镀金**：考虑超出需求的功能\n3. **依赖忽视**：未考虑外部系统依赖\n4. **估算疲劳**：连续估算太多Story，导致准确性下降\n\n#### ✅ 最佳实践\n\n1. **拆分先行**：先拆分为符合INVEST标准的Story，再估算\n2. **历史参考**：参考类似Story的历史估算和实际时间\n3. **缓冲预留**：计划时预留30-50%缓冲时间应对突发情况\n4. **回顾校准**：每个迭代后回顾估算准确性，调整方法\n\n---\n\n## 最终目录结构\n\n```\n项目根/\n├── brainstorm.md              # 原始大需求\n├── docs/\n│   ├── stories/\n│   │   └── user_stories.md    # 用户故事\n│   ├── ui/\n│   │   └── pages.md           # UI页面清单\n│   ├── architecture/\n│   │   └── frontend-backend.md # 前后端架构边界\n│   ├── database/\n│   │   └── schema.md          # 数据库表结构\n│   └── api/\n│       └── contract.md        # 接口契约\n└── specs/                     # SDD功能规格\n    ├── story1-login/\n    ├── story2-goods/\n    └── story3-order/\n```\n\n---\n\n## Superpowers / Trae-CN 操作指南\n\n1. 先完成 `docs/stories/user_stories.md`，确定**故事优先级**与**分批计划**\n2. 按批次完成 `docs/` 下设计文档（UI→架构→数据库→接口）\n3. 用 `/spec` 命令按故事生成 `specs/xxx/xxx.md` SDD 文件，每个 SDD 对应一个子代理任务\n4. 执行子代理驱动开发：`@specs/xxx/xxx.md`，每个子代理完成后自动进行**spec合规性审查**与**代码质量审查**\n5. 批次内所有 SDD 完成后，进行**集成测试**\n6. 验收通过后上线，进入下一批故事开发\n\n---\n\n## 常见错误与修复\n\n### 错误：水平拆分优先于垂直切片\n\n- **问题**：先做全量UI/架构/契约，再拆故事，导致迭代周期长、变更成本高\n- **修复**：**先拆用户故事，再按故事分批做水平拆分**\n\n### 错误：SDD 粒度过大，跨多个故事\n\n- **问题**：子代理无法独立完成，交付周期长，风险集中\n- **修复**：SDD 严格对应**单个用户故事/子故事**，粒度控制在**1–3天**可完成\n\n### 错误：契约未版本化，变更影响全量\n\n- **问题**：需求变更导致全量契约与代码返工\n- **修复**：**按批次版本化管理契约**，变更只影响当前批次\n\n### 错误：忽略非功能需求\n\n- **问题**：功能完成后发现性能、安全等问题\n- **修复**：**将非功能需求融入DoD或Story验收标准**\n\n---\n\n## 合理性、边界与适应场景\n\n### 合理性（适合场景）\n\n- **敏捷+架构规范双需求**的项目（互联网产品、中后台系统）\n- **大型复杂需求**，需要同时保证快速交付与技术可控\n- **Superpowers/Trae-CN 环境**，需要适配子代理驱动开发与测试驱动开发\n- **个人开发**，流程轻量但规范\n\n### 边界（固有约束）\n\n- **批次内强时序依赖**：每批内必须 1→2→3→4，前一步未固化无法进入下一步\n- **批次间并行有限**：批次按优先级顺序执行，无法完全并行\n\n### 不适应场景\n\n- **纯探索型项目**（需求完全不确定，每天都在变）\n- **非Web系统**（移动端原生、IoT、强实时系统）\n- **纯瀑布项目**（要求全量设计完成后再开发）\n\n---\n\n## 快速参考表\n\n| 步骤 | 产出文件 | 核心关注点 |\n|------|----------|------------|\n| 0 | docs/stories/user_stories.md | 用户价值、垂直切片 |\n| 1 | docs/ui/pages.md | 用户看到什么、操作什么 |\n| 2 | docs/architecture/frontend-backend.md | 前后端技术边界、权责划分 |\n| 3 | docs/database/schema.md + docs/api/contract.md | 数据结构、接口契约 |\n| 4 | specs/xxx/xxx.md | 独立功能规格、子代理任务 |\n\n---\n\n## 与 ui-sdd、sdd-add 的配置建议\n\n### 三层架构定位\n\n| 技能 | 核心定位 | 层级 | 产出 |\n|------|---------|------|------|\n| **sdd** | 需求层·业务拆分 | 顶层 | docs/stories/、docs/ui/pages.md、docs/architecture/、docs/database/、docs/api/、specs/ |\n| **ui-sdd** | 架构层·UI交互 | 中层 | spec/ui/ 下完整 SDD（100%覆盖） |\n| **sdd-add** | 迭代层·快速迭代 | 底层 | docs/temp-requirements/ 下临时迭代 |\n\n### 完整流程配置\n\n#### 项目从零启动（需求→UI→实现）\n\n1. **先用 sdd**：拆 Epic→Feature→Story，写验收标准、做估算\n2. **再用 ui-sdd**：对 Story 中的 UI/交互需求，按「App全域盘点清单」勾出所有页面/组件/规则，建完整 SDD\n3. **交付开发**（或用 sdd-add 做快速实现）\n\n#### 正常迭代开发（日常新功能）\n\n1. **先用 sdd**：把新功能拆成 Story，写验收标准\n2. **再用 ui-sdd**：回「盘点清单」补勾，补建/更新 spec/ui/ 下的 SDD\n3. **最后用 sdd-add**：做快速实现，需求文档中必须**引用 sdd 的 Story 和 ui-sdd 的 SDD**\n\n#### 临时需求/紧急修复\n\n1. **直接用 sdd-add**：快速澄清、优先级、实现\n2. **如果涉及 UI/新增页面**：必须同步回 ui-sdd：补勾、补建 SDD\n3. **如果涉及 Story 拆分**：必须同步回 sdd：补 Story\n\n### 文档关联引用规范\n\n#### sdd Story 中引用 ui-sdd\n\n在 sdd 产出的 Story 文档中加入：\n\n```markdown\n## 关联文档\n\n- 对应UI交互SDD：spec/ui/pages/xxx-page.sdd.md\n- 复用组件SDD：spec/ui/common/ui-yyy.sdd.md\n- 相关弹窗SDD：spec/ui/dialog/zzz-dialog.sdd.md\n```\n\n#### ui-sdd SDD 中引用 sdd Story\n\n在 ui-sdd 产出的页面/组件SDD中加入：\n\n```markdown\n## 关联用户故事\n\n- 主故事：US-001（在 docs/stories/user_stories.md）\n- 相关故事：US-002、US-003\n```\n\n#### sdd-add 临时需求中引用前两者\n\n在 sdd-add 产出的临时需求文档中加入：\n\n```markdown\n## 关联文档\n\n- 关联Story：docs/stories/user_stories.md 中的 US-xxx\n- 关联UI-SDD：spec/ui/pages/yyy-page.sdd.md\n```\n\n### 高频场景决策表\n\n| 场景 | 第1步用 | 第2步用 | 第3步用 |\n|------|---------|---------|---------|\n| 新项目从零开始 | sdd（需求拆分） | ui-sdd（UI设计） | 开发 |\n| 新增完整Story | sdd（Story拆分） | ui-sdd（补SDD） | 开发 |\n| 临时小功能 | sdd-add（快速处理） | ui-sdd（可选，需UI） | 开发 |\n| 新增复杂Epic | sdd（Epic拆分） | ui-sdd（批量建SDD） | 分批开发 |\n| 临时小bug修复 | sdd-add | 无需 | 快速修复 |\n| 优化现有交互 | sdd（更新Story） | ui-sdd（更新SDD） | sdd-add（实现） |\n\n### 一句话原则\n\n**「sdd 定方向（做什么），ui-sdd 定样子（怎么做），sdd-add 填细节（快速补）；从上往下拆，从下往上补，互相引用不遗漏」**\n"
+  },
+  {
+    "name": "sdd-add",
+    "content": "---\nname: sdd-add\ndescription: 个人开发临时新增功能全流程落地：需求澄清→优先级决策→成本估算→最小可行实现→自我测试→技术债务记录→文档同步→安全合并发布→监控→优化\n---\n\n# 个人开发临时功能全流程落地\n\n## 概述\n\n本技能提供一套完整的**个人开发临时功能处理流程**，确保临时功能不打乱节奏、不埋技术债务，同时兼顾**快速交付**与**架构规范**。\n\n核心流程：\n- **需求处理阶段**：需求澄清 → 优先级决策 → 成本估算 → 版本控制准备\n- **开发实现阶段**：最小可行实现 → 多平台适配 → 自我测试 → 技术债务记录 → 文档同步\n- **发布维护阶段**：安全合并与发布 → 上线后监控 → 后续迭代优化\n\n---\n\n## 何时使用\n\n- 有**临时、突发、高频小功能**需要快速上线\n- 个人开发项目，需要平衡**快速交付**与**技术债务管控**\n- 临时功能可能演变成正式功能，需要为未来留后路\n- 需要一套**标准化流程**处理临时需求，避免每次都从头思考\n\n---\n\n## 第一部分：需求处理阶段\n\n### 1.1 需求澄清（避免模糊开发）\n\n**必须回答 5W1H**：\n- What：功能内容具体是什么？\n- Why：解决什么痛点？不做会怎么样？\n- Who：目标用户是谁？使用频率如何？\n- When：上线时间要求？紧急程度？\n- How：大致的实现方式是什么？\n- How much：价值收益如何？量化评估？\n\n**制定可验证验收标准**：\n每条标准必须具体、可测试，例如：\n- 批量上传 ≤ 5 张图，单张 ≤ 2MB\n- 响应时间 ≤ 500ms，成功率 ≥ 99%\n- 支持 3 种主流浏览器（Chrome、Safari、Edge）\n\n**价值量化评估**：\n使用简易评分表判断优先级：\n```\n优先级得分 = (紧急度 + 重要性 + 价值) / 成本\n```\n\n评分标准：\n- 紧急度：1（低）- 5（高，立即要）\n- 重要性：1（低）- 5（高，核心功能）\n- 价值：1（低）- 5（高，带来显著收益）\n- 成本：1（低，<1天）- 5（高，>1周）\n\n得分 > 3 优先处理，得分 < 2 考虑放弃或延后。\n\n**产出**：创建 `docs/temp-requirements/[功能名]-requirements.md`\n\n---\n\n### 1.2 优先级决策（拒绝无差别处理）\n\n| 类型 | 需要采取的行动 | 时间要求 |\n|------|----------------|----------|\n| **P0 紧急修复** | 立即暂停非核心任务，启动修复流程 | 30分钟内响应，2小时内出临时方案 |\n| **P1 核心增强** | 评估成本，替换当前低价值任务 | 1天内完成决策，48小时内启动开发 |\n| **P2 体验优化** | 放入个人 Backlog，排到下一轮迭代 | 1周内规划，不影响当前核心任务 |\n| **P3 探索功能** | 仅记录想法，等待项目稳定期 | 无时间压力，按需启动 |\n\n**产出**：更新 `docs/temp-requirements/backlog.md`，记录优先级与计划\n\n---\n\n### 1.3 成本估算（避免过度投入）\n\n**时间盒限制**：\n- P0/P1 级功能：≤ 8 小时\n- P2 级功能：≤ 4 小时\n- 超过时间盒必须重新评估，考虑拆分或延后\n\n**多平台适配成本**：\n- 原生开发：考虑不同机型、系统版本\n- Flutter：优先复用共享代码\n- Web：先适配主流浏览器\n\n**技术债务预估**：\n明确临时方案的后续优化成本，纳入迭代计划。\n\n**产出**：在需求文档中记录 `成本估算` 与 `时间盒`\n\n---\n\n### 1.4 版本控制准备（避免代码混乱）\n\n**必须创建独立分支**：\n- 临时功能：`temp/[功能名]-[日期]`\n- 紧急修复：`hotfix/[问题]-[日期]`\n\n**分支隔离原则**：\n- 开发、测试、合并全流程在分支内完成\n- 不污染主分支\n- 提交规范：每次提交附清晰说明，便于后续追溯和回滚\n\n**产出**：\n- 创建并切换到对应分支\n- 更新 `docs/temp-requirements/[功能名]-requirements.md`，记录分支信息\n\n---\n\n## 第二部分：开发实现阶段\n\n### 2.1 最小可行实现（拒绝过度设计）\n\n**垂直切片开发**：\n先完成核心流程，再逐步添加辅助功能。例如：先实现上传，再做裁剪。\n\n**临时方案优先**：\n- 复杂功能可用第三方库快速实现\n- 标注 `// TODO: 后续优化 [原因] [计划时间]`\n- 避免功能镀金，减少维护成本\n\n**代码简洁原则**：\n- 只写必要代码\n- 保持代码可读性\n- 不追求完美，追求可用\n\n**产出**：功能代码实现，标注临时方案\n\n---\n\n### 2.2 多平台适配（确保一致性）\n\n| 平台 | 需要做的适配工作 | 效率技巧 |\n|------|------------------|----------|\n| **原生（iOS/Android）** | 适配不同屏幕、系统版本，处理权限申请 | 抽取核心逻辑为共享模块，减少重复开发 |\n| **Flutter** | 统一UI/UX，平台特有功能单独实现 | 利用Hot Reload快速调试，使用成熟插件 |\n| **Web** | 兼容主流浏览器，处理响应式布局 | 使用Tailwind CSS等工具减少样式适配时间 |\n\n**产出**：多平台适配代码\n\n---\n\n### 2.3 自我测试（避免上线后翻车）\n\n**单元测试**：\n- 核心函数编写测试用例\n- 例如：Python 用 pytest，JavaScript 用 Jest\n\n**手动测试**：\n- 严格按验收标准执行\n- 记录测试步骤和结果\n\n**边界测试**：\n- 无效输入、网络异常、权限不足等场景\n\n**回归测试**：\n- 验证临时功能不影响原有核心功能\n\n**产出**：\n- 单元测试代码\n- `docs/temp-requirements/[功能名]-test-report.md`\n\n---\n\n### 2.4 技术债务记录（避免隐形坑）\n\n**创建 `tech-debt.md` 文件**（如果不存在），记录：\n\n模板：\n```markdown\n# 技术债务清单\n\n## [日期] - [功能名]\n\n1. **功能**：[简要描述]\n2. **临时方案**：[使用了什么临时方案，为什么]\n3. **优化计划**：[计划在什么时间用什么方式优化]\n4. **原因**：[为什么选择临时方案而不是完美方案]\n5. **风险**：[临时方案可能带来的风险]\n```\n\n**示例**：\n```markdown\n# 技术债务清单\n\n## 2026-05-04 - 头像上传优化\n\n1. **功能**：用户头像上传与裁剪\n2. **临时方案**：使用第三方 image_cropper 库\n3. **优化计划**：2026年5月10日前替换为自研算法\n4. **原因**：快速实现功能，减少开发时间，赶上线节点\n5. **风险**：第三方库可能有兼容性问题，未来需要迁移成本\n```\n\n**产出**：更新 `docs/tech-debt.md`\n\n---\n\n### 2.5 文档同步（方便后续维护）\n\n**更新 `README.md`**：\n- 添加临时功能说明\n- 使用方法和注意事项\n- 标注\"临时功能，后续优化\"\n\n**记录测试用例**：\n- 保存关键测试步骤\n- 便于后续回归测试\n\n**产出**：\n- 更新 `README.md`\n- 更新 `docs/temp-requirements/[功能名]-requirements.md`，补充实现细节\n\n---\n\n## 第三部分：发布与维护阶段\n\n### 3.1 安全合并与发布\n\n**合并前检查清单**：\n1. [ ] 切换到主分支并拉取最新代码\n2. [ ] 合并临时分支，解决冲突\n3. [ ] 测试合并后代码，确保无问题\n4. [ ] 提交并推送\n5. [ ] 删除临时分支\n\n**灰度发布策略**（如果适用）：\n- 先小范围发布（10% 用户）\n- 监控指标正常后再全量发布\n\n**产出**：功能上线，分支清理完成\n\n---\n\n### 3.2 上线后监控（及时发现问题）\n\n**核心指标监控**：\n- 响应时间\n- 错误率\n- 用户反馈\n- 业务数据\n\n**快速回滚准备**：\n- 准备回滚方案\n- 发现严重问题立即恢复到之前版本\n\n**产出**：`docs/temp-requirements/[功能名]-monitoring.md`，记录监控结果\n\n---\n\n### 3.3 后续迭代优化（持续改进）\n\n**技术债务清理**：\n- 按计划重构临时方案\n- 提升代码质量\n\n**功能扩展**：\n- 根据用户反馈，决定是否增加更多功能\n\n**流程优化**：\n- 总结此次处理经验\n- 调整个人开发流程\n\n**产出**：\n- 优化后的代码\n- `docs/temp-requirements/[功能名]-retrospective.md`，总结经验教训\n\n---\n\n## 最终目录结构\n\n```\n项目根/\n├── docs/\n│   ├── temp-requirements/          # 临时功能需求\n│   │   ├── backlog.md              # 临时功能待办\n│   │   ├── [功能名]-requirements.md\n│   │   ├── [功能名]-test-report.md\n│   │   ├── [功能名]-monitoring.md\n│   │   └ [功能名]-retrospective.md\n│   └── tech-debt.md                # 技术债务清单\n└── README.md                       # 更新，添加临时功能说明\n```\n\n---\n\n## 快速检查清单\n\n### 需求阶段\n- [ ] 回答了 5W1H\n- [ ] 制定了可验证验收标准\n- [ ] 完成了价值量化评估\n- [ ] 确定了优先级\n- [ ] 设定了时间盒\n- [ ] 创建了独立分支\n\n### 开发阶段\n- [ ] 完成了最小可行实现\n- [ ] 标注了临时方案和 TODO\n- [ ] 完成了多平台适配\n- [ ] 编写了单元测试\n- [ ] 完成了手动测试和边界测试\n- [ ] 记录了技术债务\n- [ ] 更新了文档\n\n### 发布阶段\n- [ ] 通过了合并前检查\n- [ ] 功能正常上线\n- [ ] 删除了临时分支\n- [ ] 启动了监控\n- [ ] 准备了回滚方案\n\n---\n\n## 常见\"需要避免\"的错误\n\n1. **无计划接收临时需求**：导致任务混乱，效率低下\n   - 解决：建立个人需求看板，严格按优先级处理\n\n2. **直接在主分支开发**：代码混乱，回滚困难\n   - 解决：强制使用 Git 分支，隔离临时功能\n\n3. **过度追求完美**：开发时间过长，延误核心任务\n   - 解决：设定时间盒，只做最小可行实现\n\n4. **忽略测试**：上线后发现问题，频繁修复\n   - 解决：建立个人测试流程，确保覆盖核心场景\n\n5. **不记录技术债务**：代码维护困难，后续开发效率低\n   - 解决：创建技术债务文档，明确优化计划\n\n---\n\n## 核心逻辑总结\n\n临时功能处理的本质是**平衡灵活性与稳定性**，需要做到：\n\n1. **先评估再行动**：用价值-成本模型判断优先级，拒绝盲目开发\n2. **严格版本控制**：用 Git 分支隔离临时功能，确保主分支干净\n3. **最小可行实现**：聚焦核心价值，标注技术债务，后续迭代优化\n4. **全程文档记录**：需求、验收标准、测试用例、技术债务均需文档化\n5. **上线后监控与优化**：快速响应问题，持续改进功能和流程\n\n---\n\n## 使用指南\n\n### 快速开始（30分钟快速处理）\n\n1. **第1-5分钟**：需求澄清，回答 5W1H，制定验收标准\n2. **第5-10分钟**：优先级决策，价值量化评估，设定时间盒\n3. **第10-15分钟**：版本控制准备，创建分支\n4. **第15-结束**：按流程开发、测试、记录、发布\n\n### 命令参考（假设使用 Git）\n\n```bash\n# 1. 创建分支\ngit checkout -b temp/[功能名]-$(date +%Y%m%d)\n\n# 2. 开发提交\ngit add .\ngit commit -m \"temp: [功能名] 最小可行实现\"\n\n# 3. 测试完成后合并\ngit checkout main\ngit pull origin main\ngit merge temp/[功能名]-[日期]\n# 解决冲突...\ngit push origin main\n\n# 4. 删除分支\ngit branch -d temp/[功能名]-[日期]\ngit push origin --delete temp/[功能名]-[日期]\n```\n\n---\n\n## 模板文件（可复制）\n\n### 临时功能需求模板\n\n```markdown\n# [功能名] - 临时功能需求\n\n## 1. 需求澄清\n\n### 5W1H\n- **What**：\n- **Why**：\n- **Who**：\n- **When**：\n- **How**：\n- **How much**：\n\n### 验收标准\n- [ ]\n- [ ]\n- [ ]\n\n### 价值量化评估\n- 紧急度：/5\n- 重要性：/5\n- 价值：/5\n- 成本：/5\n- 得分：\n\n### 优先级\n- P0 / P1 / P2 / P3\n\n### 时间盒\n- 预估时间：小时\n- 截止时间：\n\n## 2. 版本控制\n\n- 分支名：\n- 创建时间：\n\n## 3. 实现记录\n\n- 临时方案：\n- TODO 优化：\n- 第三方依赖：\n\n## 4. 测试结果\n\n- 单元测试：通过/失败\n- 手动测试：通过/失败\n- 边界测试：通过/失败\n- 回归测试：通过/失败\n\n## 5. 上线记录\n\n- 上线时间：\n- 监控状态：\n- 回滚准备：是/否\n```\n\n### 技术债务模板\n\n```markdown\n# 技术债务清单\n\n## [YYYY-MM-DD] - [功能名]\n\n1. **功能**：\n2. **临时方案**：\n3. **优化计划**：\n4. **原因**：\n5. **风险**：\n```\n\n---\n\n## 与 sdd、ui-sdd 的配置建议\n\n### 三层架构定位\n\n| 技能 | 核心定位 | 层级 | 产出 |\n|------|---------|------|------|\n| **sdd** | 需求层·业务拆分 | 顶层 | docs/stories/、docs/ui/pages.md、docs/architecture/、docs/database/、docs/api/、specs/ |\n| **ui-sdd** | 架构层·UI交互 | 中层 | spec/ui/ 下完整 SDD（100%覆盖） |\n| **sdd-add** | 迭代层·快速迭代 | 底层 | docs/temp-requirements/ 下临时迭代 |\n\n### 完整流程配置\n\n#### 项目从零启动（需求→UI→实现）\n\n1. **先用 sdd**：拆 Epic→Feature→Story，写验收标准、做估算\n2. **再用 ui-sdd**：对 Story 中的 UI/交互需求，按「App全域盘点清单」勾出所有页面/组件/规则，建完整 SDD\n3. **交付开发**（或用 sdd-add 做快速实现）\n\n#### 正常迭代开发（日常新功能）\n\n1. **先用 sdd**：把新功能拆成 Story，写验收标准\n2. **再用 ui-sdd**：回「盘点清单」补勾，补建/更新 spec/ui/ 下的 SDD\n3. **最后用 sdd-add**：做快速实现，需求文档中必须**引用 sdd 的 Story 和 ui-sdd 的 SDD**\n\n#### 临时需求/紧急修复\n\n1. **直接用 sdd-add**：快速澄清、优先级、实现\n2. **如果涉及 UI/新增页面**：必须同步回 ui-sdd：补勾、补建 SDD\n3. **如果涉及 Story 拆分**：必须同步回 sdd：补 Story\n\n### 文档关联引用规范\n\n#### sdd Story 中引用 ui-sdd\n\n在 sdd 产出的 Story 文档中加入：\n\n```markdown\n## 关联文档\n\n- 对应UI交互SDD：spec/ui/pages/xxx-page.sdd.md\n- 复用组件SDD：spec/ui/common/ui-yyy.sdd.md\n- 相关弹窗SDD：spec/ui/dialog/zzz-dialog.sdd.md\n```\n\n#### ui-sdd SDD 中引用 sdd Story\n\n在 ui-sdd 产出的页面/组件SDD中加入：\n\n```markdown\n## 关联用户故事\n\n- 主故事：US-001（在 docs/stories/user_stories.md）\n- 相关故事：US-002、US-003\n```\n\n#### sdd-add 临时需求中引用前两者\n\n在 sdd-add 产出的临时需求文档中加入：\n\n```markdown\n## 关联文档\n\n- 关联Story：docs/stories/user_stories.md 中的 US-xxx\n- 关联UI-SDD：spec/ui/pages/yyy-page.sdd.md\n```\n\n### 高频场景决策表\n\n| 场景 | 第1步用 | 第2步用 | 第3步用 |\n|------|---------|---------|---------|\n| 新项目从零开始 | sdd（需求拆分） | ui-sdd（UI设计） | 开发 |\n| 新增完整Story | sdd（Story拆分） | ui-sdd（补SDD） | 开发 |\n| 临时小功能 | sdd-add（快速处理） | ui-sdd（可选，需UI） | 开发 |\n| 新增复杂Epic | sdd（Epic拆分） | ui-sdd（批量建SDD） | 分批开发 |\n| 临时小bug修复 | sdd-add | 无需 | 快速修复 |\n| 优化现有交互 | sdd（更新Story） | ui-sdd（更新SDD） | sdd-add（实现） |\n\n### 一句话原则\n\n**「sdd 定方向（做什么），ui-sdd 定样子（怎么做），sdd-add 填细节（快速补）；从上往下拆，从下往上补，互相引用不遗漏」**\n"
+  },
+  {
+    "name": "sdd-code",
+    "content": "---\nname: \"sdd-code\"\ndescription: \"功能实现逻辑SDD拆分，将用户故事拆分为独立可交付的功能实现SDD，按语言架构特性适配。Invoke when needing to split user stories into implementation-level SDDs after basic SDD split.\"\n---\n\n# 功能实现逻辑SDD拆分技能\n\n本技能定义「功能实现逻辑SDD拆分」为独立技能，核心解决「功能实现逻辑如何拆分、拆分多少个SDD、不同场景下如何适配」的核心问题，可直接嵌入原有开发流程。\n\n## 核心原则\n\n**1个最小可独立实现的功能逻辑单元 = 1个SDD**，拆分数量由「功能复杂度、代码耦合度、语言架构特性、项目用途」四大维度决定。\n\n---\n\n# 一、通用基础拆分规则\n\n## 1.1 核心拆分原则\n\n- **独立可交付**：每个SDD对应1个最小可独立实现的功能逻辑单元，可单独开发、测试、交付。\n- **低耦合高内聚**：SDD内部逻辑闭环，仅聚焦自身核心功能。\n- **粒度适配场景**：拆分粒度需贴合项目语言、架构、用途。\n- **逻辑闭环完整**：每个SDD需覆盖「正常流程+关键异常流程」。\n- **衔接原有流程**：需严格关联基础SDD拆分产出的用户故事、UI设计、接口契约。\n\n## 1.2 拆分数量判定核心公式\n\n```\n拆分数量 = 核心功能逻辑单元数 + 异常处理逻辑单元数（可选） - 可合并逻辑单元数\n```\n\n## 1.3 禁止拆分与必须拆分场景\n\n### 1.3.1 禁止拆分场景\n- 单一简单操作（如按钮点击事件）\n- 高度耦合的逻辑（如「数据查询+数据渲染」）\n- 重复逻辑（如多个SDD共用的工具函数）\n\n### 1.3.2 必须拆分场景\n- 多分支业务逻辑（如订单支付的多种支付方式）\n- 跨模块依赖逻辑（如「用户登录验证」）\n- 复杂异常处理（如数据入库的多类异常）\n- 前后端分离场景中，前端渲染、前端交互、后端接口实现、后端业务逻辑\n\n---\n\n# 二、按项目语言架构拆分细则\n\n## 2.1 纯前端项目（Vue/React/Angular等）\n\n核心拆分维度：页面渲染 → 交互逻辑 → 数据请求/处理 → 公共逻辑\n\n- **简单页面**：拆分2-3个SDD\n  - 页面渲染逻辑SDD\n  - 核心交互逻辑SDD\n  - 数据请求逻辑SDD（可选）\n\n- **复杂页面**：拆分3-5个SDD\n  - 在简单页面基础上，新增表单校验逻辑SDD、异常提示逻辑SDD\n  - 若有独立组件，可新增组件渲染与交互SDD\n\n## 2.2 纯后端项目（Java/Node.js/Go等）\n\n核心拆分维度：接口实现 → 业务逻辑 → 数据访问 → 公共逻辑\n\n- **简单接口**：拆分2个SDD\n  - 接口实现逻辑SDD\n  - 数据访问逻辑SDD\n\n- **复杂接口**：拆分3-4个SDD\n  - 接口实现逻辑SDD\n  - 业务逻辑SDD\n  - 数据访问逻辑SDD\n  - 异常处理逻辑SDD\n\n## 2.3 Flutter项目（MVVM架构为主）\n\n核心拆分维度：UI渲染（Widget）→ 交互逻辑 → 状态管理 → 数据请求/处理 → 公共逻辑\n\n- **简单页面/组件**：拆分2-3个SDD\n  - UI渲染逻辑SDD\n  - 核心交互逻辑SDD\n  - 数据请求逻辑SDD（可选）\n\n- **复杂页面/组件**：拆分3-5个SDD\n  - 在简单页面基础上，新增状态管理逻辑SDD、异常处理逻辑SDD\n  - 涉及元素渲染特殊处理的场景，可新增渲染辅助逻辑SDD\n\n---\n\n# 三、代码规范与技术债务管理\n\n## 3.1 代码规范要求\n\n### 3.1.1 通用编码规范\n- **命名规范**\n  - 类名：大驼峰（PascalCase），如 `UserService`\n  - 函数名：小驼峰（camelCase），如 `getUserInfo`\n  - 变量名：小驼峰（camelCase），如 `userName`\n  - 常量名：全大写下划线分隔（UPPER_SNAKE_CASE），如 `MAX_RETRY_COUNT`\n  - 文件名：语义化命名，如 `user_service.dart`\n\n- **注释规范**\n  - 公共API必须有文档注释\n  - 复杂逻辑必须有注释说明思路\n  - 注释不要重复代码本身的意思\n  - TODO/FIXME必须有注释说明原因和计划\n\n- **代码风格**\n  - 统一使用项目约定的格式化工具\n  - 缩进统一（2空格或4空格，保持一致）\n  - 避免过长的函数（建议不超过50行）\n  - 单一职责原则，一个函数只做一件事\n\n### 3.1.2 语言特定规范\n- **Flutter/Dart**\n  - 遵循官方Dart风格指南\n  - 优先使用const常量\n  - 合理使用async/await\n  - Widget拆分合理，避免过于庞大\n\n- **Web前端**\n  - 组件化设计\n  - 状态管理合理\n  - 组件Props类型定义完整\n\n- **后端**\n  - 分层架构清晰\n  - 接口设计RESTful\n  - 错误处理统一\n\n## 3.2 技术债务管理\n\n### 3.2.1 技术债务识别\n技术债务主要来源：\n- 快速迭代时的临时方案\n- 技术栈演进，旧代码未及时更新\n- 性能瓶颈暂时未优化\n- 安全隐患暂时未修复\n- 代码可读性较差的部分\n\n### 3.2.2 技术债务记录模板\n\n```markdown\n# 技术债务记录\n\n## 基本信息\n- **债务ID**：TD-001\n- **模块**：用户认证模块\n- **优先级**：P1\n- **识别日期**：2024-05-04\n\n## 问题描述\n- **问题类型**：代码质量/性能/安全/可维护性\n- **具体问题**：密码使用MD5加密，不安全\n- **影响范围**：用户账户安全\n- **当前状态**：未修复/修复中/已修复\n\n## 技术细节\n- **问题代码位置**：lib/auth/password.dart:23-28\n- **当前实现**：使用MD5加密密码\n- **建议方案**：升级为bcrypt或Argon2加密\n\n## 修复计划\n- **预计工作量**：1天\n- **计划修复时间**：2024-05-15前\n- **风险评估**：低/中/高\n- **回滚方案**：如有问题，可回滚到MD5（临时方案）\n\n## 关联信息\n- **关联SDD**：skill-sdd-story1-login-backend-api.md\n- **关联测试**：test/password_encryption_test.dart\n- **备注**：安全审计建议修复\n\n## 更新记录\n| 日期 | 更新内容 | 更新人 |\n|------|---------|-------|\n|      |         |       |\n```\n\n### 3.2.3 技术债务管理规范\n- **优先级定义**\n  - P0：严重问题，必须立即修复\n  - P1：重要问题，近期修复\n  - P2：一般问题，计划修复\n  - P3：轻微问题，有空修复\n\n- **管理流程**\n  - 识别技术债务 → 记录到技术债务清单 → 评估优先级 → 计划修复 → 修复验证 → 关闭债务\n  - 每个迭代预留10-20%时间偿还技术债务\n  - 定期回顾技术债务清单，调整优先级\n\n## 3.3 重构计划\n\n### 3.3.1 重构触发条件\n- 代码难以理解和维护\n- 频繁出现bug\n- 性能不满足要求\n- 技术栈更新需要适配\n- 功能扩展困难\n\n### 3.3.2 重构计划模板\n\n```markdown\n# 重构计划\n\n## 基本信息\n- **重构ID**：REF-001\n- **模块**：订单处理模块\n- **发起日期**：2024-05-04\n- **优先级**：P1\n\n## 重构原因\n- **现状问题**：当前代码耦合度高，难以维护和测试\n- **业务影响**：新功能开发效率低，bug修复周期长\n- **重构目标**：提高代码可维护性，降低耦合度\n\n## 重构范围\n- **涉及文件**：lib/order/order_service.dart, lib/order/order_repository.dart\n- **涉及功能**：订单创建、订单状态更新、订单查询\n- **不涉及内容**：支付模块、用户模块\n\n## 重构方案\n- **重构策略**：增量重构/完全重写\n- **技术方案**：\n  1. 拆分OrderService为多个职责单一的类\n  2. 引入Repository模式，分离数据访问逻辑\n  3. 添加单元测试，提高测试覆盖率\n\n- **依赖关系**：\n  - 前置依赖：无\n  - 后置影响：需同步更新相关测试\n\n## 时间计划\n- **准备阶段**：2024-05-06 分析现有代码\n- **重构阶段**：2024-05-07 到 2024-05-10\n- **测试阶段**：2024-05-11 到 2024-05-12\n- **上线阶段**：2024-05-13\n\n## 风险评估\n- **技术风险**：中/高\n- **风险预案**：准备回滚方案，灰度发布\n- **测试重点**：功能完整性、性能不下降\n\n## 验收标准\n- 代码可维护性提升\n- 测试覆盖率达到80%以上\n- 功能保持完整，无新增bug\n- 性能不低于重构前\n\n## 回滚方案\n- **回滚条件**：出现严重bug，性能明显下降\n- **回滚步骤**：\n  1. 停止新功能的开发\n  2. 从Git回滚代码\n  3. 验证回滚后的功能\n  4. 重新发布\n\n## 备注\n- 重构过程中，保持小步提交，便于回滚\n- 每完成一个小重构，立即验证功能\n```\n\n### 3.3.3 重构最佳实践\n- **增量重构**：尽量避免大规模重写，采用小步迭代方式\n- **测试先行**：重构前确保有充分的测试覆盖\n- **保持功能**：重构过程中保持功能不变\n- **频繁验证**：每一步重构后立即验证\n- **记录过程**：记录重构的原因、过程、结果\n\n---\n\n# 四、SDD拆分落地流程\n\n## 4.1 拆分前置条件\n\n1. 已完成基础SDD拆分（Epic→Feature→用户故事）\n2. 已完成UI设计、前后端架构拆分、数据库+接口拆分\n3. 明确项目语言、架构、用途\n\n## 4.2 拆分步骤（6步落地）\n\n1. **梳理逻辑单元**：拆解每个用户故事对应的核心功能逻辑单元\n2. **判定拆分数量**：结合项目语言、架构、用途，判定需拆分的SDD数量\n3. **拆分SDD**：为每个功能逻辑单元分配独立SDD，明确核心范围、验收标准\n4. **补充技术债务**：识别当前实现中的技术债务，记录到债务清单\n5. **规划重构计划**：如需要重构，制定重构计划\n6. **规范命名与存放**：按命名、目录规范，为每个SDD命名并放入对应目录\n7. **自检优化**：按校验标准，自检SDD拆分合理性\n\n---\n\n# 五、输出文件结构\n\n## 5.1 SDD目录结构\n\n```\n项目根/\n├── docs/\n│   └── tech-debt/       # 技术债务记录\n│       ├── td-001.md\n│       └── td-list.md\n└── specs/\n    ├── function-implementation-sdd/\n    │   ├── story1-login/\n    │   │   ├── skill-sdd-story1-login-frontend-render.md\n    │   │   ├── skill-sdd-story1-login-frontend-interact.md\n    │   │   └── skill-sdd-story1-login-backend-api.md\n    │   └── common/\n    └── refactor-plans/  # 重构计划\n        └── ref-001.md\n```\n\n---\n\n# 六、拆分合理性校验标准\n\n## 6.1 核心校验项（必过项）\n\n- 独立可交付：每个SDD可单独开发、测试、交付\n- 逻辑闭环：每个SDD覆盖正常流程+关键异常流程\n- 粒度适配：无过度拆分、无拆分不足\n- 技能衔接：与基础SDD拆分产出的用户故事、接口契约严格衔接\n- 规范适配：SDD命名、目录符合规范要求\n- 代码规范：SDD中明确代码规范要求\n- 债务管理：技术债务已识别并记录\n- 重构计划：如需重构，计划已制定\n\n---\n\n# 七、与其他技能的衔接\n\n## 7.1 前置技能\n- **sdd**：基础SDD拆分，输出用户故事、UI设计、接口契约\n- **ui-sdd**：UI交互SDD，如需要\n\n## 7.2 后置技能\n- **sdd-test**：测试SDD拆分\n- **sdd-add**：快速迭代补充（如需要）\n- **子代理开发**：执行SDD开发\n\n## 7.3 流程关系\n```\nsdd → ui-sdd → sdd-code → sdd-test → 开发\n```\n"
+  },
+  {
+    "name": "sdd-deploy",
+    "content": "---\nname: \"sdd-deploy\"\ndescription: \"部署SDD拆分技能，将发布需求拆分为可执行的部署SDD。Invoke when you need to create deployment SDDs after sdd-test is complete.\"\n---\n\n# sdd-deploy - 部署SDD拆分技能\n\n## 概述\n\n本技能专注于将发布需求拆分为完整的部署SDD，覆盖环境配置、发布流程、回滚方案、灰度发布、A/B测试等部署相关内容。\n\n---\n\n## 与其他技能的衔接\n\n### 前置技能\n- **sdd-test** - 测试已通过\n- **quality-gate** - 质量门禁已通过\n\n### 后置技能\n- 部署执行\n- release-flow\n\n---\n\n## 核心功能\n\n### 1. 部署环境配置\n- 配置多环境（dev/test/staging/prod）\n- 定义环境差异清单\n- 指定环境变量管理策略\n- 生成环境配置模板\n\n### 2. 发布流程设计\n- 定义发布步骤\n- 指定发布时间窗口\n- 制定发布审批流程\n- 生成发布检查清单\n\n### 3. 回滚方案设计\n- 定义回滚触发条件\n- 制定回滚步骤\n- 准备回滚数据备份\n- 生成回滚验证清单\n\n### 4. 灰度发布策略\n- 定义灰度发布步骤\n- 指定流量分配比例\n- 制定灰度监控指标\n- 生成灰度发布决策树\n\n### 5. A/B测试方案\n- 定义A/B测试目标\n- 指定测试分组策略\n- 制定成功指标\n- 生成A/B测试评估方案\n\n### 6. 部署权限管理\n- 定义部署角色权限\n- 指定操作审批流程\n- 制定权限审计策略\n- 生成权限矩阵\n\n### 7. 配置管理（配置中心）\n- 定义配置分类\n- 指定配置变更流程\n- 制定配置版本管理策略\n- 生成配置模板\n\n### 8. 环境变量管理\n- 定义环境变量分类\n- 指定敏感数据加密策略\n- 制定变量变更流程\n- 生成变量管理清单\n\n---\n\n## 产出文件结构\n\n### 部署文档目录\n```\ndocs/\n  deploy/\n    ├── environments.md\n    ├── release-process.md\n    ├── rollback-plan.md\n    ├── canary-strategy.md\n    ├── ab-test-plan.md\n    ├── config-management.md\n    └── variables.md\n```\n\n---\n\n## 部署SDD模板\n\n### 环境配置SDD模板\n```markdown\n# 环境配置SDD\n\n## 1. 环境清单\n| 环境名称 | 环境地址 | 用途 | 数据来源 |\n|---------|---------|------|---------|\n| dev | dev.example.com | 开发测试 | 测试数据 |\n| test | test.example.com | 集成测试 | 测试数据 |\n| staging | staging.example.com | 预发布 | 生产数据快照 |\n| prod | www.example.com | 生产 | 真实数据 |\n\n## 2. 环境差异清单\n\n### 配置差异\n- 数据库连接字符串\n- API密钥\n- 第三方服务地址\n- 日志级别\n\n### 功能差异\n- 是否启用调试模式\n- 是否启用性能监控\n- 是否发送真实通知\n\n## 3. 环境配置模板\n```yaml\n# config.yml\ndatabase:\n  host: ${DB_HOST}\n  port: ${DB_PORT}\n\napi:\n  key: ${API_KEY}\n```\n\n## 4. 环境准备检查清单\n- [ ] 数据库已创建\n- [ ] 配置文件已部署\n- [ ] 环境变量已设置\n- [ ] 第三方服务已配置\n- [ ] 监控告警已设置\n```\n\n---\n\n### 发布流程SDD模板\n```markdown\n# 发布流程SDD\n\n## 1. 发布概述\n- 发布版本号\n- 发布内容清单\n- 发布时间窗口\n- 发布负责人\n\n## 2. 发布步骤\n\n### 步骤1：发布前准备\n- [ ] 合并代码到主分支\n- [ ] 运行完整测试\n- [ ] 准备发布文档\n- [ ] 通知相关团队\n\n### 步骤2：发布到staging\n- [ ] 部署到staging环境\n- [ ] 运行冒烟测试\n- [ ] 业务验证\n- [ ] 准备回滚方案\n\n### 步骤3：发布到prod\n- [ ] 执行发布\n- [ ] 监控系统状态\n- [ ] 验证功能正常\n- [ ] 确认发布成功\n\n## 3. 发布检查清单\n### 发布前检查\n- [ ] 所有测试通过\n- [ ] 代码已评审\n- [ ] 文档已更新\n- [ ] 回滚方案已准备\n\n### 发布中检查\n- [ ] 部署脚本执行正常\n- [ ] 监控指标正常\n- [ ] 日志无错误\n- [ ] 服务健康检查通过\n\n### 发布后检查\n- [ ] 功能验证完成\n- [ ] 用户反馈收集\n- [ ] 发布总结编写\n\n## 4. 发布通知流程\n- 发布前通知：提前24小时\n- 发布中通知：实时更新\n- 发布后通知：成功告知\n```\n\n---\n\n### 回滚方案SDD模板\n```markdown\n# 回滚方案SDD\n\n## 1. 回滚触发条件\n- [ ] 核心功能不可用\n- [ ] 性能严重下降\n- [ ] 数据错误\n- [ ] 安全漏洞\n- [ ] 用户投诉量激增\n\n## 2. 回滚步骤\n\n### 步骤1：决策回滚\n- 评估问题严重程度\n- 确认需要回滚\n- 通知相关团队\n- 记录回滚原因\n\n### 步骤2：执行回滚\n- 停止发布流程\n- 执行回滚脚本\n- 验证回滚结果\n- 确认系统恢复\n\n### 步骤3：回滚后处理\n- 收集问题数据\n- 分析根因\n- 制定修复计划\n- 更新发布流程\n\n## 3. 回滚验证清单\n- [ ] 应用版本正确\n- [ ] 数据库状态正确\n- [ ] 配置已恢复\n- [ ] 功能正常\n- [ ] 性能指标正常\n\n## 4. 数据备份策略\n- 备份时间点：发布前立即备份\n- 备份内容：数据库+配置文件\n- 备份存储位置：安全的备份服务器\n- 保留时间：至少7天\n```\n\n---\n\n### 灰度发布策略SDD模板\n```markdown\n# 灰度发布策略SDD\n\n## 1. 灰度目标\n- 降低发布风险\n- 收集用户反馈\n- 验证新功能表现\n\n## 2. 灰度步骤\n\n### 阶段1：内部测试（10%流量）\n- 用户群：内部员工\n- 流量比例：10%\n- 持续时间：2小时\n- 监控指标：错误率，性能指标\n\n### 阶段2：小范围（30%流量）\n- 用户群：指定测试用户\n- 流量比例：30%\n- 持续时间：4小时\n- 监控指标：同上 + 用户反馈\n\n### 阶段3：中范围（70%流量）\n- 用户群：大部分用户\n- 流量比例：70%\n- 持续时间：8小时\n- 监控指标：同上\n\n### 阶段4：全量（100%流量）\n- 用户群：所有用户\n- 流量比例：100%\n- 持续时间：永久\n\n## 3. 灰度决策树\n\n### 继续发布条件\n- 错误率 < 1%\n- 性能指标正常\n- 用户反馈良好\n- 无严重bug\n\n### 暂停发布条件\n- 错误率 1-5%\n- 性能指标下降但可接受\n- 需要更多数据\n\n### 回滚条件\n- 错误率 > 5%\n- 性能严重下降\n- 发现严重bug\n\n## 4. 灰度监控指标\n- 系统错误率\n- API响应时间\n- 页面加载时间\n- 用户操作成功率\n- 用户投诉量\n```\n\n---\n\n### A/B测试方案SDD模板\n```markdown\n# A/B测试方案SDD\n\n## 1. A/B测试概述\n- 测试名称\n- 测试目标\n- 测试时间\n- 负责人\n\n## 2. 测试分组\n\n### 组A（对照组）\n- 用户数：50%\n- 功能：当前版本\n- 指标：基准数据\n\n### 组B（实验组）\n- 用户数：50%\n- 功能：新版本\n- 指标：对比数据\n\n## 3. 测试指标\n\n### 核心指标\n- 转化率提升\n- 用户留存率\n- 错误率\n- 性能指标\n\n### 次要指标\n- 用户满意度\n- 操作路径变化\n- 功能使用频率\n\n## 4. 数据统计分析\n- 置信度要求：95%\n- 最小样本量：1000用户\n- 统计方法：t检验/卡方检验\n\n## 5. 结论判定\n- 如果B组显著优于A组：全量发布B版本\n- 如果两组无显著差异：根据业务目标决策\n- 如果B组显著差于A组：回滚到A版本\n\n## 6. 测试停止条件\n- 达到预定样本量\n- 测试时间到期\n- 结论已经明确\n- 发现严重问题\n```\n\n---\n\n### 配置管理SDD模板\n```markdown\n# 配置管理SDD\n\n## 1. 配置分类\n\n### 环境配置\n- 数据库连接\n- API地址\n- 第三方服务配置\n\n### 应用配置\n- 功能开关\n- 业务规则参数\n- 性能参数\n\n### 安全配置\n- 密钥\n- 证书\n- 权限设置\n\n## 2. 配置变更流程\n\n### 变更申请\n1. 提交配置变更申请\n2. 说明变更原因和影响\n3. 进行风险评估\n4. 获得审批\n\n### 变更执行\n1. 准备配置变更\n2. 在非生产环境测试\n3. 按计划执行变更\n4. 验证变更结果\n\n### 变更记录\n1. 记录变更内容\n2. 记录变更时间\n3. 记录变更人\n4. 记录变更结果\n\n## 3. 配置版本管理\n- 版本号格式：v1.0.0\n- 变更历史记录\n- 版本回滚支持\n- 配置差异对比\n\n## 4. 配置模板\n```json\n{\n  \"version\": \"v1.0.0\",\n  \"config\": {\n    \"database\": {},\n    \"api\": {}\n  }\n}\n```\n```\n\n---\n\n## 部署执行流程\n\n### 1. 部署准备\n1. 确认部署条件满足\n2. 准备部署脚本\n3. 准备回滚方案\n4. 通知相关人员\n\n### 2. 部署执行顺序\n1. 部署到dev → 2. 部署到test → 3. 部署到staging → 4. 部署到prod\n\n### 3. 部署后验证\n- 冒烟测试\n- 功能验证\n- 性能验证\n- 数据一致性检查\n\n---\n\n## 使用步骤\n\n### 步骤1：分析发布需求\n- 读取sdd-test输出\n- 确定发布范围\n- 评估发布风险\n\n### 步骤2：设计部署方案\n- 选择部署策略\n- 定义环境配置\n- 设计发布流程\n\n### 步骤3：创建部署SDD\n- 使用模板创建部署SDD\n- 填写部署步骤\n- 定义回滚方案\n\n### 步骤4：执行部署\n- 按计划执行部署\n- 监控部署过程\n- 处理部署问题\n\n---\n\n## 与其他技能的集成\n\n### 与sdd-test集成\n```\nsdd-test → 测试通过 → sdd-deploy → 部署SDD\n```\n\n### 与release-flow集成\n```\nsdd-deploy → 部署SDD → release-flow → 发布管理\n```\n\n---\n\n## 最佳实践\n\n1. 总是准备回滚方案\n2. 优先使用灰度发布\n3. 详细记录每次发布\n4. 建立发布审批流程\n5. 定期演练回滚流程\n\n---\n\n## 常见问题\n\n### Q：什么时候需要用灰度发布？\nA：重大功能变更、架构调整、不确定用户反馈的情况\n\n### Q：如何选择A/B测试的样本量？\nA：根据预期效果大小、显著性水平、统计功效来计算\n\n### Q：回滚时需要注意什么？\nA：确保数据一致性、通知相关用户、记录回滚原因、后续根因分析\n"
+  },
+  {
+    "name": "sdd-full",
+    "content": "\n---\nname: sdd-full-flow\ndescription: SDD全流程开发 - 分3个阶段：产品经理阶段→拆分阶段→开发流程，含调试/临时需求分支\n---\n\n&lt;SUBAGENT-STOP&gt;\n如果您被派作为子代理执行特定任务，请跳过此技能。\n&lt;/SUBAGENT-STOP&gt;\n\n# SDD全流程开发 - 分3阶段\n\n---\n\n## 🔄 完整流程图\n\n```\n┌─────────────────────────────────────────────────────────────────────┐\n│  阶段 1：产品经理阶段（Product Manager）                            │\n│  ├─ 市场调研（market-research）                                     │\n│  ├─ 竞品分析（competitive-brief）                                    │\n│  ├─ 用户调研                                                        │\n│  ├─ 头脑风暴（brainstorming）【新增】                                │\n│  ├─ 需求文档编写（PRD）                                              │\n│  └─ 完成后询问：【是否进行SDD拆分？】→ 是则进入阶段2                  │\n└─────────────────────────────────────────────────────────────────────┘\n                              ↓ 是\n┌─────────────────────────────────────────────────────────────────────┐\n│  阶段 2：SDD拆分阶段（Split Phase）                                  │\n│  ├─ 基础SDD拆分（sdd）                                               │\n│  │  ├─ Epic拆分（如需要）                                            │\n│  │  ├─ 用户故事拆分（INVEST原则）                                    │\n│  │  ├─ 前后端架构拆分                                                │\n│  │  ├─ 数据库+接口拆分                                               │\n│  │  └─ SDD垂直切片                                                  │\n│  ├─ UI交互SDD（ui-sdd）【新增】                                      │\n│  │  ├─ UI设计梳理                                                   │\n│  │  ├─ 交互逻辑设计                                                 │\n│  │  └─ UI-SDD规范文档                                              │\n│  ├─ 功能实现SDD（sdd-code）                                          │\n│  │  ├─ 按语言架构拆分（前端/后端/Flutter）                            │\n│  │  ├─ 代码规范定义                                                  │\n│  │  └─ 技术债务管理+重构计划                                         │\n│  ├─ 测试SDD（sdd-test）                                              │\n│  │  ├─ 单元/集成/E2E测试SDD                                         │\n│  │  ├─ 性能/安全测试SDD                                              │\n│  │  └─ 测试数据管理                                                  │\n│  ├─ 部署SDD（sdd-deploy）                                            │\n│  │  ├─ 环境配置                                                      │\n│  │  ├─ 发布流程/回滚方案                                             │\n│  │  └─ 灰度发布/A/B测试                                             │\n│  ├─ 运维SDD（sdd-ops）                                              │\n│  │  ├─ 监控告警/日志管理                                             │\n│  │  ├─ 备份恢复/扩容策略                                             │\n│  │  └─ 灾难恢复/运维手册                                             │\n│  └─ 完成后询问：【是否进行MVP验证？】→ 是则进入阶段2.5                │\n└─────────────────────────────────────────────────────────────────────┘\n                              ↓ 是\n┌─────────────────────────────────────────────────────────────────────┐\n│  阶段 2.5：MVP验证（Minimum Viable Product）【新增】                    │\n│  ├─ 最小MVP开发（基于SDD中最核心的用户故事）                            │\n│  ├─ MVP内部测试                                                    │\n│  ├─ 用户介入测试（邀请真实用户测试）                                    │\n│  ├─ 反馈收集整理                                                    │\n│  ├─ 迭代优化（可调用 systematic-debugging/sdd-add）                  │\n│  └─ 用户确认通过 → 是则进入阶段3                                      │\n└─────────────────────────────────────────────────────────────────────┘\n                              ↓ 通过\n┌─────────────────────────────────────────────────────────────────────┐\n│  阶段 3：开发流程（Development Flow）                                │\n│  ├─ 实现计划（writing-plans）                                        │\n│  ├─ TDD开发（test-driven-development）                              │\n│  │  ├─ 分支A：调试流程（systematic-debugging）← 测试失败时触发      │\n│  │  │  ├─ 错误根因分析                                              │\n│  │  │  ├─ 修复问题                                                  │\n│  │  │  └─ 验证测试                                                  │\n│  │  ├─ 分支B：临时需求流程（sdd-add）← 临时需求插入时触发          │\n│  │  │  ├─ 需求澄清（5W1H）                                          │\n│  │  │  ├─ 优先级决策                                                │\n│  │  │  ├─ 成本估算+时间盒                                           │\n│  │  │  ├─ 最小可行实现                                              │\n│  │  │  └─ 技术债务记录                                              │\n│  │  └─ 正常完成 → 继续                                              │\n│  ├─ 验证完成（verification-before-completion）                       │\n│  ├─ 代码审查（requesting-code-review + receiving-code-review）     │\n│  ├─ 质量门禁（quality-gate + security-audit）                        │\n│  ├─ 交付发布（finishing-a-development-branch + release-flow）       │\n│  └─ 经验沉淀（claudeception + mempalace-auto-saver）                 │\n└─────────────────────────────────────────────────────────────────────┘\n```\n\n---\n\n## 🚀 开始流程\n\n### 第一步：调用 using-superpowers\n\n首先调用 `using-superpowers` 建立技能调用规则，确保所有后续技能正确使用。\n\n---\n\n## 阶段 1：产品经理阶段（Product Manager）\n\n**目标**：从市场到需求，完成产品定义\n\n**工具/技能**：\n- `market-research` - 市场调研\n- `competitive-brief` - 竞品分析\n- `brainstorming` - 头脑风暴【新增】\n- `prd-write` - 产品需求文档编写\n\n**详细步骤**：\n\n### 1.1 市场调研\n- 目标用户分析\n- 市场规模评估\n- 趋势分析\n- 痛点识别\n- 机会点挖掘\n\n**输出**：市场调研报告\n\n---\n\n### 1.2 竞品分析\n- 直接竞品分析\n- 间接竞品分析\n- 竞品功能对比矩阵\n- 竞品优劣势分析\n- 差异化机会点\n\n**输出**：竞品分析简报\n\n---\n\n### 1.3 用户调研\n- 用户画像定义\n- 用户访谈计划\n- 需求收集整理\n- 痛点优先级排序\n\n**输出**：用户调研报告\n\n---\n\n### 1.4 头脑风暴【新增】\n- 需求分析和方案设计\n- 功能探索和创意讨论\n- 技术方案初步评估\n- 用户体验设计探讨\n\n---\n\n### 1.5 PRD编写\n- 产品目标定位\n- 功能需求列表\n- 非功能需求\n- 用户故事初稿\n- 验收标准定义\n\n**输出**：完整PRD文档\n\n---\n\n### 阶段1完成检查\n- [ ] 市场调研报告完成\n- [ ] 竞品分析简报完成\n- [ ] 用户调研报告完成\n- [ ] 头脑风暴完成\n- [ ] PRD文档完成并用户确认\n\n---\n\n### 阶段1结束询问\n```\n产品经理阶段已完成！\n是否进行SDD拆分？（是/否）\n```\n\n---\n\n## 阶段 2：SDD拆分阶段（Split Phase）\n\n**目标**：从需求到可执行规格，完成全链路设计\n\n**工具/技能**：\n- `sdd` - 基础SDD拆分\n- `ui-sdd` - UI交互SDD【新增】\n- `sdd-code` - 功能实现SDD\n- `sdd-test` - 测试SDD\n- `sdd-deploy` - 部署SDD\n- `sdd-ops` - 运维SDD\n\n**详细步骤**：\n\n---\n\n### 2.1 基础SDD拆分（sdd）\n\n**子阶段**：\n1. **Epic拆分（如需要）**\n   - 判断是否为大型需求（预计>2周）\n   - Epic→Feature分层\n   - 按用户旅程/功能模块拆分\n\n2. **用户故事拆分**\n   - 符合INVEST原则\n   - BDD格式验收标准\n   - 优先级排序（P0/P1/P2/P3）\n   - 工作量估算\n\n3. **前后端架构拆分**\n   - 前端职责定义\n   - 后端职责定义\n   - 技术选型说明\n\n4. **数据库+接口拆分**\n   - 数据库表结构\n   - RESTful API契约\n   - 契约版本管理\n\n5. **SDD垂直切片**\n   - 按用户故事垂直切分\n   - 每个SDD = 1个子代理可执行单元\n\n**输出**：\n- `docs/stories/user_stories.md`\n- `docs/architecture/frontend-backend.md`\n- `docs/database/schema.md`\n- `docs/api/contract.md`\n- `specs/[story-name]/` 基础SDD\n\n---\n\n### 2.2 UI交互SDD（ui-sdd）【新增】\n\n**核心内容**：\n- UI设计梳理\n  - 页面组件清单\n  - 页面布局规范\n  - UI/UX设计规范\n- 交互逻辑设计\n  - 用户操作流程\n  - 异常交互处理\n  - 反馈提示设计\n- UI-SDD规范文档\n  - 完整的UI-SDD目录\n  - 页面/组件级SDD\n  - 设计规范文档\n\n**输出**：\n- `spec/ui/` 目录\n  - `pages/` 页面SDD\n  - `common/` 组件SDD\n  - `dialog/` 弹窗SDD\n- `docs/ui/` UI设计规范文档\n\n---\n\n### 2.4 功能实现SDD（sdd-code）\n\n**核心拆分**：\n- 按语言架构特性拆分（前端/后端/Flutter）\n- 每个最小功能逻辑单元 = 1个SDD\n\n**代码规范**：\n- 命名规范（大驼峰/小驼峰/常量）\n- 注释规范\n- 单一职责原则\n\n**技术债务管理**：\n- 识别技术债务\n- 优先级排序\n- 制定重构计划\n\n**输出**：\n- `specs/function-implementation-sdd/[story-name]/`\n- `docs/tech-debt/`\n- `specs/refactor-plans/`\n\n---\n\n### 2.6 测试SDD（sdd-test）\n\n**测试类型覆盖**：\n1. **单元测试SDD** - 覆盖率≥80%\n2. **集成测试SDD** - 服务间交互\n3. **E2E测试SDD** - 用户旅程\n4. **性能测试SDD** - 响应时间/并发指标\n5. **安全测试SDD** - OWASP Top 10，包含 security-audit 【强调】\n\n**输出**：`specs/test/` 下各类型测试SDD，特别关注 `specs/test/security/` 安全测试部分\n\n---\n\n### 2.8 部署SDD（sdd-deploy）\n\n**核心内容**：\n- 环境配置（dev/test/staging/prod）\n- 发布流程+审批流程\n- 回滚方案+数据备份\n- 灰度发布策略\n- A/B测试方案\n- 配置管理\n\n**输出**：`docs/deploy/` 下部署文档\n\n---\n\n### 2.9 运维SDD（sdd-ops）\n\n**核心内容**：\n- 监控告警（应用/系统/数据库）\n- 日志管理（级别/格式/采集）\n- 备份恢复（策略/流程/演练）\n- 扩容策略（水平/垂直）\n- 灾难恢复（RTO/RPO/多活）\n- 运维手册\n\n**输出**：`docs/ops/` 下运维文档\n\n---\n\n### 阶段2完成检查\n- [ ] 基础SDD拆分完成（sdd）\n- [ ] UI交互SDD完成（ui-sdd）【新增】\n- [ ] 功能实现SDD完成（sdd-code）\n- [ ] 测试SDD完成（sdd-test）\n- [ ] 部署SDD完成（sdd-deploy）\n- [ ] 运维SDD完成（sdd-ops）\n- [ ] 所有设计文档用户确认\n\n---\n\n### 阶段2结束询问\n```\nSDD拆分阶段已完成！\n是否进行MVP验证？（是/否）\n```\n\n---\n\n## 阶段 2.5：MVP验证（Minimum Viable Product）【新增】\n\n**目标**：最小可行产品验证，用户介入测试确认方向正确\n\n**工具/技能**：\n- `test-driven-development`（精简版，只做核心功能）\n- `systematic-debugging`（MVP迭代时使用）\n- `sdd-add`（MVP反馈优化时使用）\n\n**详细步骤**：\n\n---\n\n### 2.5.1 MVP功能筛选\n- 从SDD用户故事中挑选最核心的1-3个\n- 确保是最小可行产品（MVP）\n- 用户确认MVP范围\n\n---\n\n### 2.5.2 MVP开发\n- 调用 `test-driven-development` 精简版\n- 只开发MVP核心功能\n- 内部测试通过\n\n---\n\n### 2.5.3 用户介入测试\n- 邀请真实用户进行测试\n- 收集用户使用反馈\n- 记录问题和改进建议\n\n---\n\n### 2.5.4 迭代优化\n- 根据反馈整理问题清单\n- 调用 `systematic-debugging` 修复Bug\n- 调用 `sdd-add` 优化或调整功能（如需要）\n- 再次内部测试\n\n---\n\n### 2.5.5 用户确认\n- 展示优化后的MVP\n- 用户确认是否通过\n- 收集最终意见\n\n---\n\n### 阶段2.5完成检查\n- [ ] MVP范围确认\n- [ ] MVP开发完成\n- [ ] 内部测试通过\n- [ ] 用户介入测试完成\n- [ ] 反馈迭代完成\n- [ ] 用户确认通过\n\n---\n\n### 阶段2.5结束询问\n```\nMVP验证阶段已完成！\n用户确认通过。\n是否进入完整开发流程？（是/否）\n```\n\n---\n\n## 阶段 3：开发流程（Development Flow）\n\n**目标**：从设计到交付，完成开发发布\n\n**工具/技能**：\n- `writing-plans` - 实现计划\n- `test-driven-development` - TDD开发\n- `systematic-debugging` - 调试流程（分支A）\n- `sdd-add` - 临时需求流程（分支B）\n- `verification-before-completion` - 验证完成\n- `requesting-code-review` + `receiving-code-review` - 代码审查\n- `quality-gate` + `security-audit` - 质量门禁\n- `finishing-a-development-branch` + `release-flow` - 交付发布\n- `claudeception` + `mempalace-auto-saver` - 经验沉淀\n\n**详细步骤**：\n\n---\n\n### 3.1 实现计划\n- 调用 `writing-plans`\n- 输出TodoWrite任务清单\n- 用户确认计划\n\n---\n\n### 3.2 TDD开发（核心路径）\n\n**原则**：\n- 测试先行\n- 按Todo列表逐个执行\n- 每个功能完成后验证\n\n**分支A：调试流程**\n```\n触发条件：测试失败 / 发现Bug\n\n├─ 调用 systematic-debugging\n│  ├─ 错误根因分析\n│  ├─ 定位问题代码\n│  └─ 制定修复方案\n├─ 执行修复\n├─ 重新运行测试\n└─ 验证通过 → 返回TDD主流程\n```\n\n**分支B：临时需求流程**\n```\n触发条件：插入临时需求 / 紧急修复\n\n├─ 调用 sdd-add\n│  ├─ 需求澄清（5W1H）\n│  ├─ 优先级决策（P0/P1/P2/P3）\n│  ├─ 成本估算+时间盒限制\n│  ├─ 最小可行实现\n│  ├─ 技术债务记录\n│  └─ 文档同步\n├─ 创建独立分支\n├─ 开发+测试\n├─ 安全合并发布\n└─ 监控优化 → 返回TDD主流程\n```\n\n---\n\n### 3.3 验证完成\n调用 `verification-before-completion`，确保：\n- 所有测试通过\n- 功能符合验收标准\n- 无严重问题\n\n---\n\n### 3.4 代码审查\n- 调用 `requesting-code-review`\n- 调用 `receiving-code-review`\n- 根据反馈修改\n- 审查通过\n\n---\n\n### 3.5 质量门禁\n- 代码规范检查\n- 安全审计（security-audit）\n- 性能检查\n- 测试覆盖率验证\n\n---\n\n### 3.6 交付发布\n- 调用 `finishing-a-development-branch`\n- 调用 `release-flow`\n- 执行部署SDD\n- 发布上线\n\n---\n\n### 3.7 经验沉淀\n- 调用 `claudeception` - 保存经验教训，创建可复用技能\n- 调用 `mempalace-auto-saver` - 记忆宫殿存储\n\n---\n\n### 阶段3完成检查\n- [ ] 实现计划完成（writing-plans）\n- [ ] 所有功能开发完成\n- [ ] 所有测试通过\n- [ ] 代码审查通过\n- [ ] 质量门禁通过\n- [ ] 成功发布上线\n- [ ] 经验沉淀完成\n\n---\n\n## 📂 最终产出目录结构\n\n```\n项目根/\n├── brainstorm.md                                  # 原始需求\n├── docs/\n│   ├── market-research.md                        # 市场调研（阶段1）\n│   ├── competitive-brief.md                      # 竞品分析（阶段1）\n│   ├── prd.md                                    # PRD文档（阶段1）\n│   ├── stories/\n│   │   └── user_stories.md                       # 用户故事（阶段2）\n│   ├── ui/\n│   │   └── design.md                             # UI设计规范（阶段2）\n│   ├── architecture/\n│   │   └── frontend-backend.md                   # 架构设计（阶段2）\n│   ├── database/\n│   │   └── schema.md                             # 数据库设计（阶段2）\n│   ├── api/\n│   │   └── contract.md                           # API契约（阶段2）\n│   ├── temp-requirements/                        # 临时需求（阶段3分支B）\n│   ├── tech-debt/                                # 技术债务（阶段2）\n│   ├── deploy/                                   # 部署文档（阶段2）\n│   │   ├── environments.md\n│   │   ├── release-process.md\n│   │   ├── rollback-plan.md\n│   │   └── ...\n│   └── ops/                                      # 运维文档（阶段2）\n│       ├── monitoring.md\n│       ├── logging.md\n│       ├── backup-restore.md\n│       └── ...\n└── specs/                                        # SDD功能规格\n    ├── [story1]/                                 # 基础SDD（阶段2）\n    ├── ui/                                       # UI交互SDD【新增】\n    │   ├── pages/\n    │   ├── common/\n    │   └── dialog/\n    ├── function-implementation-sdd/              # 实现SDD（阶段2）\n    ├── test/                                     # 测试SDD（阶段2）\n    │   ├── unit/\n    │   ├── integration/\n    │   ├── e2e/\n    │   ├── performance/\n    │   ├── security/\n    │   └── data/\n    └── refactor-plans/                           # 重构计划（阶段2）\n```\n\n---\n\n## 📋 全流程检查清单\n\n| 阶段 | 步骤 | 完成标记 |\n|------|------|---------|\n| **前置** | 调用 using-superpowers | ⬜ |\n| **阶段1** | 市场调研 | ⬜ |\n| | 竞品分析 | ⬜ |\n| | 用户调研 | ⬜ |\n| | 头脑风暴【新增】 | ⬜ |\n| | PRD编写 | ⬜ |\n| | **用户确认是否进行SDD拆分** | ⬜ |\n| **阶段2** | 基础SDD拆分（sdd） | ⬜ |\n| | UI交互SDD（ui-sdd）【新增】 | ⬜ |\n| | 功能实现SDD（sdd-code） | ⬜ |\n| | 测试SDD（sdd-test） | ⬜ |\n| | 部署SDD（sdd-deploy） | ⬜ |\n| | 运维SDD（sdd-ops） | ⬜ |\n| | **用户确认是否进行MVP验证** | ⬜ |\n| **阶段2.5** | MVP功能筛选 | ⬜ |\n| | MVP开发 | ⬜ |\n| | 用户介入测试 | ⬜ |\n| | 迭代优化 | ⬜ |\n| | **用户确认通过** | ⬜ |\n| **阶段3** | 实现计划（writing-plans） | ⬜ |\n| | TDD开发 | ⬜ |\n| | 调试流程（分支A，按需） | ⬜ |\n| | 临时需求流程（分支B，按需） | ⬜ |\n| | 验证完成 | ⬜ |\n| | 代码审查 | ⬜ |\n| | 质量门禁 | ⬜ |\n| | 交付发布 | ⬜ |\n| | 经验沉淀 | ⬜ |\n\n---\n\n## ⚡ 快速开始\n\n现在，让我们开始吧！\n1. **首先调用 `using-superpowers`**\n2. **然后进入阶段1：产品经理阶段**\n\n---\n\n**一句话总结**：阶段1做产品（市场→竞品→用户调研→头脑风暴→PRD）→ 阶段2做设计（SDD全系列拆分，含 ui-sdd，含安全测试）→ 阶段2.5做MVP验证（最小开发→用户介入测试→迭代→确认）→ 阶段3做开发（从 writing-plans 开始 → TDD+分支流程+安全审计）→ 每个阶段结束后询问是否继续！\n\n"
+  },
+  {
+    "name": "sdd-ops",
+    "content": "---\nname: \"sdd-ops\"\ndescription: \"运维SDD拆分技能，设计监控、日志、备份、扩容等运维方案。Invoke when you need to design operation and maintenance strategy after release.\"\n---\n\n# sdd-ops - 运维SDD拆分技能\n\n## 概述\n\n本技能专注于将发布后的运维需求拆分为完整的运维SDD，包含监控告警、日志管理、备份恢复、扩容策略、灾难恢复、运维手册、故障排查等。\n\n---\n\n## 与其他技能的衔接\n\n### 前置技能\n- **sdd-deploy**（部署SDD）\n- **release-flow**（发布完成）\n\n### 后置技能\n- 持续优化运维方案\n\n---\n\n## 核心功能\n\n### 1. 监控告警设计\n- 应用监控指标（QPS、响应时间、错误率）\n- 系统监控指标（CPU、内存、磁盘、网络）\n- 数据库监控指标（连接数、慢查询、复制延迟）\n- 告警规则定义（P0/P1/P2告警级别）\n- 告警通知渠道（电话、短信、邮件、IM）\n\n### 2. 日志管理设计\n- 日志级别定义（DEBUG/INFO/WARN/ERROR）\n- 日志格式规范\n- 日志采集方案（ELK/CloudWatch/Loki等）\n- 日志存储策略（保留时长、归档、清理）\n- 日志查询规范\n\n### 3. 备份恢复设计\n- 数据库备份策略（全量+增量）\n- 文件备份策略（静态资源、配置）\n- 备份存储方案（本地+异地）\n- 备份验证方案\n- 恢复流程文档\n\n### 4. 扩容策略设计\n- 水平扩容方案（加机器）\n- 垂直扩容方案（升配置）\n- 自动扩容触发条件\n- 手动扩容流程\n- 扩容验证清单\n\n### 5. 灾难恢复设计\n- 灾难场景定义（机房故障、数据丢失、大面积故障）\n- RTO/RPO目标定义\n- 多活/灾备架构\n- 灾难切换流程\n- 灾难演练计划\n\n### 6. 运维手册编写\n- 日常运维检查清单\n- 常见问题排查手册\n- 应急响应流程\n- 权限管理规范\n- 变更管理流程\n\n### 7. 故障排查流程\n- 故障分级（P0/P1/P2）\n- 排查步骤指南\n- 问题根因分析方法\n- 故障记录模板\n- 复盘优化流程\n\n---\n\n## 产出文件结构\n\n### 运维SDD目录\n```\ndocs/\n  └── ops/\n      ├── monitoring.md          # 监控告警设计\n      ├── logging.md            # 日志管理设计\n      ├── backup-restore.md      # 备份恢复设计\n      ├── scaling.md            # 扩容策略设计\n      ├── disaster-recovery.md  # 灾难恢复设计\n      ├── manual.md             # 运维手册\n      └── troubleshooting.md    # 故障排查流程\n```\n\n---\n\n## 运维SDD模板\n\n### 监控告警SDD模板\n```markdown\n# 监控告警SDD\n\n## 1. 监控指标清单\n\n### 应用层监控\n| 指标名称 | 说明 | 正常值范围 | 告警阈值 |\n|---------|------|----------|---------|\n| QPS | 每秒请求数 | - | >1000或<100（异常） |\n| 响应时间P99 | 99分位响应时间 | <200ms | >500ms |\n| 错误率 | 请求错误比例 | <1% | >5% |\n| 健康检查 | 应用是否健康 | UP | DOWN |\n\n### 系统层监控\n| 指标名称 | 说明 | 正常值范围 | 告警阈值 |\n|---------|------|----------|---------|\n| CPU使用率 | CPU利用率 | <70% | >90%持续5分钟 |\n| 内存使用率 | 内存利用率 | <80% | >95%持续5分钟 |\n| 磁盘使用率 | 磁盘空间利用率 | <80% | >90% |\n| 网络IO | 网络流量 | - | 异常波动 |\n\n### 数据库监控\n| 指标名称 | 说明 | 正常值范围 | 告警阈值 |\n|---------|------|----------|---------|\n| 连接数 | 活动连接数 | <90%最大连接 | >95%最大连接 |\n| 慢查询 | 慢查询数量 | <10个/分钟 | >50个/分钟 |\n| 复制延迟 | 主从延迟 | <1s | >10s |\n\n## 2. 告警规则\n\n### P0告警（立即响应）\n- 健康检查失败\n- 错误率>10%\n- 数据库主从断开\n\n### P1告警（1小时内响应）\n- CPU>90%持续5分钟\n- 内存>95%持续5分钟\n- 错误率>5%\n\n### P2告警（工作日响应）\n- 磁盘>85%\n- 慢查询异常增加\n\n## 3. 告警通知渠道\n- P0：电话+短信+IM群@所有人\n- P1：IM群@所有人+邮件\n- P2：IM群消息\n\n## 4. 检查清单\n- [ ] 监控指标配置完成\n- [ ] 告警规则已设置\n- [ ] 通知渠道已配置\n- [ ] 告警测试已通过\n```\n\n---\n\n### 备份恢复SDD模板\n```markdown\n# 备份恢复SDD\n\n## 1. 备份策略\n\n### 数据库备份\n- 全量备份：每日凌晨2点，保留30天\n- 增量备份：每小时，保留7天\n- 备份存储：本地+云存储（异地备份）\n\n### 文件备份\n- 配置文件：每小时，保留30天\n- 静态资源：每日，保留7天\n\n## 2. 恢复流程\n\n### 数据库恢复步骤\n1. 停止应用\n2. 从备份恢复数据库\n3. 验证数据完整性\n4. 启动应用\n5. 完整测试\n\n### 文件恢复步骤\n1. 定位备份文件\n2. 恢复到目标位置\n3. 验证文件完整性\n4. 测试应用\n\n## 3. 备份验证\n- 每日自动验证备份完整性\n- 每周执行一次恢复演练\n- 每月执行一次完整灾难恢复演练\n\n## 4. 检查清单\n- [ ] 备份任务已配置\n- [ ] 备份存储位置安全\n- [ ] 恢复流程已文档化\n- [ ] 定期演练计划已制定\n```\n\n---\n\n### 灾难恢复SDD模板\n```markdown\n# 灾难恢复SDD\n\n## 1. 灾难场景定义\n\n### 场景1：单机房故障\n- 影响：一个机房不可用\n- 目标：RTO<1小时，RPO<15分钟\n\n### 场景2：数据库故障\n- 影响：主库不可用\n- 目标：RTO<30分钟，RPO<5分钟\n\n### 场景3：大面积故障\n- 影响：核心服务不可用\n- 目标：RTO<2小时，RPO<30分钟\n\n## 2. 灾难恢复流程\n\n### 启动响应\n1. 监控报警触发\n2. 确认灾难级别\n3. 启动应急响应小组\n4. 通知相关人员\n\n### 执行恢复\n1. 按预定义流程执行\n2. 定期汇报进度\n3. 记录所有操作\n\n### 验证恢复\n1. 核心功能测试\n2. 数据完整性验证\n3. 性能验证\n\n### 恢复业务\n1. 确认业务正常\n2. 通知用户\n3. 关闭响应\n\n## 3. 灾难演练\n- 每季度一次桌面演练\n- 每半年一次小型演练\n- 每年一次完整灾难恢复演练\n\n## 4. 检查清单\n- [ ] RTO/RPO目标明确\n- [ ] 灾难场景覆盖完整\n- [ ] 恢复流程文档化\n- [ ] 演练计划已制定\n```\n\n---\n\n## 使用步骤\n\n### 步骤1：评估运维需求\n- 分析系统重要程度\n- 确定RTO/RPO目标\n- 评估运维复杂度\n\n### 步骤2：设计运维方案\n- 使用模板创建各运维SDD\n- 定义监控告警策略\n- 设计备份恢复方案\n- 制定灾难恢复流程\n\n### 步骤3：落地执行\n- 配置监控系统\n- 实现备份策略\n- 编写运维手册\n- 培训运维人员\n\n---\n\n## 与其他技能的集成\n\n### 与release-flow集成\n```\nrelease-flow → sdd-ops → 运维方案落地\n```\n\n---\n\n## 最佳实践\n\n1. **监控要全面：** 应用、系统、数据库都要覆盖\n2. **备份要验证：** 不仅备份，还要定期演练恢复\n3. **灾难有预案：** 提前准备好灾难恢复流程\n4. **运维文档化：** 所有操作都要有文档\n5. **定期做演练：** 桌面演练+实际演练结合\n\n---\n\n## 常见问题\n\n### Q：如何确定RTO/RPO目标？\nA：根据业务重要程度评估，核心业务RTO<1小时，RPO<15分钟；一般业务可以适当放宽。\n\n### Q：监控指标太多怎么办？\nA：分层级管理，P0指标重点关注，P1/P2按需配置，避免告警疲劳。\n\n### Q：备份存储在哪里安全？\nA：建议3-2-1原则：3份备份，2种介质，1份异地。\n"
+  },
+  {
+    "name": "sdd-test",
+    "content": "---\nname: \"sdd-test\"\ndescription: \"测试SDD拆分技能，将用户故事拆分为可执行的测试SDD。Invoke when you need to create test SDDs after sdd-code is complete.\"\n---\n\n# sdd-test - 测试SDD拆分技能\n\n## 概述\n\n本技能专注于将用户故事拆分为完整的测试SDD，覆盖单元测试、集成测试、E2E测试、性能测试、安全测试等多种测试类型。\n\n---\n\n## 与其他技能的衔接\n\n### 前置技能\n- **sdd-code** - 功能实现SDD已完成\n\n### 后置技能\n- 子代理执行测试\n\n---\n\n## 核心功能\n\n### 1. 单元测试SDD拆分\n- 按功能模块拆分单元测试\n- 定义测试覆盖率要求\n- 指定测试框架（JUnit/Pytest/Mocha等）\n- 生成测试用例模板\n\n### 2. 集成测试SDD拆分\n- 按服务/模块间交互拆分\n- 定义Mock策略\n- 指定集成测试场景\n- 生成测试数据准备方案\n\n### 3. E2E测试SDD拆分\n- 按用户旅程拆分端到端测试\n- 定义浏览器/设备兼容性要求\n- 指定测试工具（Cypress/Puppeteer/Appium等）\n- 生成测试步骤模板\n\n### 4. 性能测试SDD拆分\n- 按关键业务流程拆分性能测试\n- 定义性能指标（响应时间/并发数/吞吐量）\n- 指定性能测试工具（JMeter/Locust/k6等）\n- 生成性能基准测试方案\n\n### 5. 安全测试SDD拆分\n- 按安全漏洞类型拆分安全测试\n- 定义安全检查清单\n- 指定安全测试工具（OWASP ZAP/Burp Suite等）\n- 生成渗透测试方案\n\n### 6. 测试数据管理\n- 按测试类型分类管理测试数据\n- 定义测试数据生成策略\n- 指定测试数据生命周期\n- 生成测试数据清理方案\n\n### 7. 测试用例优先级排序\n- 按业务重要性排序\n- 按风险等级排序\n- 按回归频率排序\n- 生成测试执行优先级矩阵\n\n---\n\n## 产出文件结构\n\n### 测试SDD目录\n```\nspecs/\n  test/\n    ├── unit/\n    │   ├── module1-test-sdd.md\n    │   ├── module2-test-sdd.md\n    │   └── ...\n    ├── integration/\n    │   ├── service1-service2-test-sdd.md\n    │   └── ...\n    ├── e2e/\n    │   ├── user-journey1-test-sdd.md\n    │   ├── user-journey2-test-sdd.md\n    │   └── ...\n    ├── performance/\n    │   ├── critical-flow1-performance-test-sdd.md\n    │   └── ...\n    ├── security/\n    │   ├── authentication-security-test-sdd.md\n    │   ├── data-protection-test-sdd.md\n    │   └── ...\n    └── data/\n        ├── test-data-schema.md\n        ├── test-data-generation-strategy.md\n        └── test-data-cleanup-sdd.md\n```\n\n---\n\n## 测试SDD模板\n\n### 单元测试SDD模板\n```markdown\n# 单元测试SDD：[模块名称]\n\n## 1. 概述\n- 测试目标\n- 测试范围\n- 测试框架\n- 前置依赖\n\n## 2. 测试用例清单\n\n### 正常流程用例\n| 用例ID | 用例名称 | 测试步骤 | 预期结果 |\n|--------|---------|---------|---------|\n| TC-001 | 功能正常输入 | 1. 步骤1 2. 步骤2 | 结果描述 |\n\n### 异常流程用例\n| 用例ID | 用例名称 | 测试步骤 | 预期结果 |\n|--------|---------|---------|---------|\n| TC-002 | 无效输入处理 | 1. 步骤1 2. 步骤2 | 结果描述 |\n\n### 边界情况用例\n| 用例ID | 用例名称 | 测试步骤 | 预期结果 |\n|--------|---------|---------|---------|\n| TC-003 | 边界值测试 | 1. 步骤1 2. 步骤2 | 结果描述 |\n\n## 3. 测试覆盖率要求\n- 语句覆盖率：≥ 80%\n- 分支覆盖率：≥ 75%\n- 函数覆盖率：≥ 90%\n\n## 4. 测试数据准备\n- 输入数据清单\n- Mock对象列表\n- 测试数据生成策略\n\n## 5. 验收标准\n- 所有测试用例通过\n- 测试覆盖率达到要求\n- 无严重bug\n```\n\n---\n\n## 集成测试SDD模板\n```markdown\n# 集成测试SDD：[服务A-服务B]\n\n## 1. 集成概述\n- 集成的服务/模块\n- 集成场景\n- 集成点清单\n- 测试工具\n\n## 2. 集成测试用例\n\n### 场景1：正常集成流程\n- 测试步骤\n- 数据准备\n- 预期结果\n- 验证点\n\n### 场景2：异常集成处理\n- 测试步骤\n- 模拟异常\n- 预期结果\n- 恢复机制验证\n\n## 3. Mock策略\n- 需要Mock的外部依赖\n- Mock数据定义\n- Mock行为验证\n\n## 4. 验收标准\n- 所有集成场景测试通过\n- 数据传输正确\n- 错误处理正确\n```\n\n---\n\n## E2E测试SDD模板\n```markdown\n# E2E测试SDD：[用户旅程名称]\n\n## 1. 用户旅程概述\n- 业务目标\n- 涉及的页面/流程\n- 用户角色\n- 测试设备/浏览器清单\n\n## 2. 测试场景\n\n### 场景1：正常用户操作流程\n| 步骤 | 操作描述 | 输入数据 | 预期结果 | 验证点 |\n|------|---------|---------|---------|-------|\n| 1 | 打开页面 | - | 页面加载 | 页面元素显示 |\n| 2 | 输入数据 | 用户名:xxx | 输入成功 | 数据提交 |\n\n### 场景2：用户错误操作\n| 步骤 | 操作描述 | 输入数据 | 预期结果 | 验证点 |\n|------|---------|---------|---------|-------|\n| 1 | 输入错误数据 | 错误格式 | 显示错误提示 | 提示信息正确 |\n\n## 3. 兼容性要求\n- 浏览器：Chrome, Firefox, Safari, Edge（最新2个版本）\n- 设备：桌面端，平板，手机\n- 分辨率：1920x1080, 1366x768, 375x667\n\n## 4. 验收标准\n- 所有用户旅程测试通过\n- 兼容性测试通过\n- 无阻断性bug\n```\n\n---\n\n## 性能测试SDD模板\n```markdown\n# 性能测试SDD：[关键流程名称]\n\n## 1. 性能目标\n- 响应时间：≤ 2秒\n- 并发用户：≥ 100\n- 吞吐量：≥ 50 TPS\n- 资源使用：CPU ≤ 70%, 内存 ≤ 80%\n\n## 2. 测试场景\n\n### 场景1：基准性能测试\n- 用户数：50\n- 持续时间：10分钟\n- 测试步骤\n- 性能指标\n\n### 场景2：负载测试\n- 用户数：100 → 200 → 500\n- 持续时间：每级15分钟\n- 性能指标\n\n### 场景3：压力测试\n- 用户数：最大并发\n- 持续时间：直到系统瓶颈\n- 性能指标\n\n## 3. 性能监控\n- 监控指标：CPU, 内存, 磁盘IO, 网络IO, 数据库性能\n- 监控工具\n- 告警阈值\n\n## 4. 验收标准\n- 性能目标全部达成\n- 无内存泄漏\n- 系统在负载下稳定运行\n```\n\n---\n\n## 安全测试SDD模板\n```markdown\n# 安全测试SDD：[安全场景名称]\n\n## 1. 安全目标\n- 保护的资产\n- 风险等级\n- 安全标准（OWASP Top 10等）\n\n## 2. 测试清单\n\n### 认证与授权\n- [ ] 弱密码检测\n- [ ] 会话管理测试\n- [ ] 权限越界测试\n- [ ] Token安全测试\n\n### 数据安全\n- [ ] SQL注入测试\n- [ ] XSS攻击测试\n- [ ] CSRF攻击测试\n- [ ] 数据加密验证\n\n### 接口安全\n- [ ] 接口速率限制测试\n- [ ] 输入验证测试\n- [ ] 错误信息泄露测试\n\n## 3. 测试工具\n- 静态代码分析工具\n- 动态扫描工具\n- 渗透测试工具\n\n## 4. 验收标准\n- 无高危安全漏洞\n- 通过安全扫描\n- 符合安全标准\n```\n\n---\n\n## 测试执行流程\n\n### 1. 测试准备\n1. 准备测试环境\n2. 准备测试数据\n3. 配置测试工具\n4. 设置测试监控\n\n### 2. 测试执行顺序\n1. 单元测试 → 2. 集成测试 → 3. E2E测试 → 4. 性能测试 → 5. 安全测试\n\n### 3. 测试报告\n- 测试执行结果汇总\n- Bug清单\n- 测试覆盖率报告\n- 性能测试报告\n- 安全测试报告\n\n---\n\n## 使用步骤\n\n### 步骤1：分析需求\n- 读取sdd-code的输出\n- 识别需要测试的功能模块\n- 确定测试范围\n\n### 步骤2：选择测试类型\n- 根据功能重要性选择测试类型\n- 确定优先级\n- 制定测试计划\n\n### 步骤3：创建测试SDD\n- 使用模板创建各类型测试SDD\n- 填写测试用例\n- 定义测试数据\n\n### 步骤4：执行测试\n- 调用子代理执行测试\n- 收集测试结果\n- 生成测试报告\n\n---\n\n## 与其他技能的集成\n\n### 与sdd-code集成\n```\nsdd-code → 读取功能实现 → sdd-test → 生成测试SDD\n```\n\n### 与quality-gate集成\n```\nsdd-test → 测试执行 → quality-gate → 质量检查\n```\n\n---\n\n## 最佳实践\n\n1. 测试用例覆盖所有验收标准\n2. 优先测试核心业务流程\n3. 自动化测试覆盖率≥80%\n4. 定期更新测试用例\n5. 建立测试数据管理机制\n\n---\n\n## 常见问题\n\n### Q：什么时候需要做性能测试？\nA：核心业务流程、用户数较多的功能、涉及大量数据计算的模块\n\n### Q：安全测试需要覆盖哪些内容？\nA：至少覆盖OWASP Top 10，根据业务特性增加特定安全测试\n\n### Q：如何平衡测试覆盖和开发效率？\nA：优先覆盖核心路径，使用自动化测试提高效率，建立回归测试机制\n"
+  },
+  {
+    "name": "security-audit",
+    "content": "---\nname: \"security-audit\"\ndescription: \"安全审计技能，分析安全需求、设计安全架构、执行安全检查。Invoke when you need to do security audit and hardening.\"\n---\n\n# security-audit - 安全审计技能\n\n## 概述\n\n本技能专注于系统安全审计和加固，包含安全需求分析、安全架构设计、安全检查清单、渗透测试方案、漏洞修复流程、安全培训等。\n\n---\n\n## 与其他技能的衔接\n\n### 前置技能\n- **sdd**（安全需求分析）\n- **quality-gate**（安全检查）\n\n### 后置技能\n- 安全持续改进\n\n---\n\n## 核心功能\n\n### 1. 安全需求分析\n- 数据安全需求（加密、脱敏、备份）\n- 认证授权需求（登录、权限、会话）\n- 接口安全需求（鉴权、限流、防攻击）\n- 合规性需求（等保、GDPR等）\n- 安全分级（按资产重要程度）\n\n### 2. 安全架构设计\n- 安全架构设计（分层防御、纵深防御）\n- 认证方案设计（密码、OAuth、SAML、生物认证）\n- 权限模型设计（RBAC、ABAC等）\n- 数据加密方案（传输加密、存储加密）\n- 安全监控设计（日志、告警、审计）\n\n### 3. 安全检查清单\n- OWASP Top 10检查清单\n- 代码安全检查清单\n- 配置安全检查清单\n- 依赖安全检查清单\n- 运维安全检查清单\n\n### 4. 渗透测试方案\n- 渗透测试计划\n- 测试范围定义\n- 测试方法选择\n- 测试用例设计\n- 风险分级\n\n### 5. 漏洞修复流程\n- 漏洞分级（Critical/High/Medium/Low）\n- 修复时限要求\n- 修复方案设计\n- 修复验证方法\n- 应急响应流程\n\n### 6. 安全培训材料\n- 开发安全培训\n- 运维安全培训\n- 员工安全意识培训\n- 常见攻击识别和防范\n- 应急响应培训\n\n---\n\n## 产出文件结构\n\n### 安全审计目录\n```\ndocs/\n  └── security/\n      ├── requirements.md          # 安全需求\n      ├── architecture.md          # 安全架构\n      ├── checklist.md            # 检查清单\n      ├── pentest-plan.md          # 渗透测试方案\n      ├── vulnerability-fix.md     # 漏洞修复流程\n      └── training.md            # 安全培训\n```\n\n---\n\n## 安全审计模板\n\n### 安全需求分析模板\n```markdown\n# 安全需求分析\n\n## 1. 资产清单\n| 资产名称 | 重要程度 | 风险等级 | 说明 |\n|---------|---------|---------|------|\n| 用户数据 | Critical | 高 | 包含手机号、邮箱、密码等 |\n| 订单数据 | High | 中高 | 包含交易记录 |\n| 系统配置 | Medium | 中 | 包含敏感配置 |\n\n## 2. 安全需求\n\n### 数据安全\n- [ ] 敏感数据加密存储\n- [ ] 敏感数据传输加密（TLS）\n- [ ] 敏感数据脱敏显示\n- [ ] 数据备份加密\n- [ ] 数据访问审计日志\n\n### 认证授权\n- [ ] 强密码策略\n- [ ] 多因素认证（可选）\n- [ ] 会话超时控制\n- [ ] 权限最小化原则\n- [ ] 权限变更审计\n\n### 接口安全\n- [ ] 接口鉴权\n- [ ] 接口限流\n- [ ] 防SQL注入\n- [ ] 防XSS攻击\n- [ ] 防CSRF攻击\n\n### 合规性\n- [ ] 符合等保要求\n- [ ] 符合GDPR（如需要）\n- [ ] 符合其他行业标准\n\n## 3. 风险评估\n| 风险 | 等级 | 可能性 | 影响 | 应对措施 |\n|-----|------|-------|------|---------|\n| 数据泄露 | Critical | 低 | 极高 | 加密、访问控制、监控 |\n| 未授权访问 | High | 中 | 高 | 强认证、权限控制 |\n```\n\n---\n\n### 安全检查清单模板\n```markdown\n# 安全检查清单\n\n## OWASP Top 10检查\n\n### A01:2021 - Broken Access Control\n- [ ] 权限验证正确实现\n- [ ] 垂直权限隔离正确\n- [ ] 水平权限隔离正确\n- [ ] 敏感接口有权限控制\n\n### A02:2021 - Cryptographic Failures\n- [ ] 敏感数据加密存储\n- [ ] 使用强加密算法\n- [ ] 密钥管理安全\n- [ ] TLS正确配置\n\n### A03:2021 - Injection\n- [ ] 所有查询参数化\n- [ ] 防止SQL注入\n- [ ] 防止XSS注入\n- [ ] 防止其他注入\n\n### A04:2021 - Insecure Design\n- [ ] 有安全威胁建模\n- [ ] 安全需求明确\n- [ ] 有安全架构设计\n\n### A05:2021 - Security Misconfiguration\n- [ ] 安全配置正确\n- [ ] 不必要的功能禁用\n- [ ] 默认密码已修改\n- [ ] 错误信息不泄露细节\n\n### A06:2021 - Vulnerable and Outdated Components\n- [ ] 依赖定期扫描\n- [ ] 高危依赖已修复\n- [ ] 不再使用的依赖已移除\n- [ ] 依赖更新策略\n\n### A07:2021 - Identification and Authentication Failures\n- [ ] 认证实现正确\n- [ ] 会话管理安全\n- [ ] 凭据存储安全\n- [ ] 有防止暴力破解措施\n\n### A08:2021 - Software and Data Integrity Failures\n- [ ] 数据完整性校验\n- [ ] 第三方来源可信\n- [ ] 有完整性验证机制\n\n### A09:2021 - Security Logging and Monitoring Failures\n- [ ] 关键操作有日志\n- [ ] 安全事件有告警\n- [ ] 日志内容完整\n- [ ] 日志存储安全\n\n### A10:2021 - Server-Side Request Forgery\n- [ ] 防止SSRF攻击\n- [ ] 外网请求有控制\n- [ ] URL验证正确\n\n## 代码安全检查\n- [ ] 无硬编码密钥\n- [ ] 无SQL注入风险\n- [ ] 无XSS风险\n- [ ] 输入验证完整\n- [ ] 输出编码正确\n\n## 配置安全检查\n- [ ] 生产环境配置安全\n- [ ] 不必要的端口已关闭\n- [ ] 服务以最小权限运行\n- [ ] 防火墙规则正确\n\n## 依赖安全检查\n- [ ] 依赖漏洞已扫描\n- [ ] 高危漏洞已修复\n- [ ] 依赖定期更新\n```\n\n---\n\n### 渗透测试方案模板\n```markdown\n# 渗透测试方案\n\n## 1. 测试概述\n- 测试目标\n- 测试范围\n- 测试时间\n- 测试人员\n\n## 2. 测试方法\n- 黑盒测试/白盒测试\n- 测试工具选择\n- 测试策略\n\n## 3. 测试范围\n\n### 测试范围\n- 测试的系统/应用\n- 测试的接口\n- 测试的功能模块\n\n### 不测试范围\n- 生产环境直接攻击（用测试环境）\n- 可能导致服务不可用的测试（提前沟通）\n\n## 4. 测试用例\n| 用例ID | 测试项 | 测试方法 | 预期结果 |\n|-------|--------|---------|---------|\n| TC-001 | SQL注入 | 尝试注入 | 无注入漏洞 |\n| TC-002 | XSS | 尝试注入脚本 | 无XSS漏洞 |\n| ... | ... | ... | ... |\n\n## 5. 风险分级\n| 等级 | 说明 | 处理时限 |\n|-----|------|---------|\n| Critical | 严重漏洞，可导致数据泄露或系统控制 | 24小时内修复 |\n| High | 高危漏洞 | 3天内修复 |\n| Medium | 中危漏洞 | 1周内修复 |\n| Low | 低危漏洞 | 1个月内修复 |\n\n## 6. 测试计划\n| 阶段 | 时间 | 内容 |\n|-----|------|------|\n| 阶段1 | ... | 信息收集 |\n| 阶段2 | ... | 漏洞扫描 |\n| 阶段3 | ... | 手动测试 |\n| 阶段4 | ... | 报告编写 |\n```\n\n---\n\n### 漏洞修复流程模板\n```markdown\n# 漏洞修复流程\n\n## 1. 漏洞上报\n- 漏洞描述\n- 漏洞等级\n- 影响范围\n- 上报时间\n- 上报人\n\n## 2. 漏洞确认\n- 验证漏洞真实性\n- 确认漏洞影响\n- 评估风险等级\n- 确认修复优先级\n\n## 3. 修复方案设计\n- 修复方案选择\n- 修复方案评估\n- 回滚方案准备\n- 修复时间计划\n\n## 4. 修复实施\n- 代码修复\n- 配置修复\n- 测试验证\n- 代码评审\n\n## 5. 发布上线\n- 修复上线计划\n- 灰度发布\n- 监控观察\n- 完整验证\n\n## 6. 复盘总结\n- 漏洞根因分析\n- 预防措施\n- 流程改进\n- 经验教训\n```\n\n---\n\n## 使用步骤\n\n### 步骤1：安全需求分析\n- 识别系统资产\n- 分析安全需求\n- 评估安全风险\n- 确定安全目标\n\n### 步骤2：安全架构设计\n- 设计安全架构\n- 选择安全方案\n- 制定安全规范\n- 设计安全监控\n\n### 步骤3：安全检查\n- 执行安全检查清单\n- 代码安全扫描\n- 依赖安全扫描\n- 配置安全检查\n\n### 步骤4：渗透测试（可选）\n- 制定渗透测试方案\n- 执行渗透测试\n- 生成测试报告\n- 制定修复计划\n\n### 步骤5：漏洞修复\n- 按优先级修复漏洞\n- 验证修复效果\n- 复盘总结\n- 持续改进\n\n---\n\n## 与其他技能的集成\n\n### 与quality-gate集成\n```\nsecurity-audit → 安全检查清单 → quality-gate → 安全检查\n```\n\n### 与sdd-test集成\n```\nsecurity-audit → 安全测试SDD → sdd-test → 安全测试\n```\n\n---\n\n## 最佳实践\n\n1. **安全左移：** 开发阶段就考虑安全，不要等上线后再补\n2. **纵深防御：** 不要只依赖单一安全措施，多层防护\n3. **最小权限：** 只给必要的权限，权限最小化原则\n4. **定期审计：** 定期执行安全检查，不要一次就完\n5. **全员重视：** 安全不只是安全团队的事，全员要有安全意识\n\n---\n\n## 常见问题\n\n### Q：需要做渗透测试吗？\nA：核心业务、敏感数据系统建议定期做；一般系统可以先用自动化工具扫描。\n\n### Q：发现高危漏洞怎么办？\nA：按应急响应流程，快速评估影响，先做临时防护，再彻底修复，修复后验证，最后复盘。\n\n### Q：如何平衡安全和用户体验？\nA：在保证安全的前提下尽量不影响体验，选择对用户影响小的安全方案，做好用户引导。\n"
+  },
+  {
+    "name": "systematic-debugging",
+    "content": "---\nname: systematic-debugging\ndescription: 在遇到任何错误、测试失败或意外行为时使用，在提出修复方案之前\n---\n\n# 系统性调试\n\n## 概述\n\n随机修复浪费时间并创建新错误。快速补丁掩盖潜在问题。\n\n**核心原则：** 在尝试修复之前始终找到根本原因。症状修复是失败。\n\n**违反此流程的字面意思就是违反调试的精神。**\n\n## 铁律\n\n```\n没有根本原因调查，就没有修复\n```\n\n如果你还没有完成第 1 阶段，你不能提出修复方案。\n\n## 何时使用\n\n用于任何技术问题：\n- 测试失败\n- 生产中的错误\n- 意外行为\n- 性能问题\n- 构建失败\n- 集成问题\n\n**特别使用当：**\n- 在时间压力下（紧急情况使猜测变得诱人）\n- \"只需一个快速修复\"看起来很明显\n- 你已经尝试了多个修复\n- 之前的修复不起作用\n- 你不完全理解问题\n\n**不要跳过当：**\n- 问题看起来简单（简单错误也有根本原因）\n- 你很匆忙（匆忙保证返工）\n- 经理希望立即修复（系统性比混乱更快）\n\n## 四个阶段\n\n你必须完成每个阶段才能进入下一个阶段。\n\n### 阶段 1：根本原因调查\n\n**在尝试任何修复之前：**\n\n1. **仔细阅读错误消息**\n   - 不要跳过错误或警告\n   - 它们通常包含确切的解决方案\n   - 完全阅读堆栈跟踪\n   - 注意行号、文件路径、错误代码\n\n2. **一致地重现**\n   - 你能可靠地触发它吗？\n   - 确切的步骤是什么？\n   - 它每次都会发生吗？\n   - 如果不可重现 → 收集更多数据，不要猜测\n\n3. **检查最近的更改**\n   - 什么更改可能导致此问题？\n   - Git diff，最近的提交\n   - 新依赖项，配置更改\n   - 环境差异\n\n4. **在多组件系统中收集证据**\n\n   **当系统有多个组件时（CI → 构建 → 签名，API → 服务 → 数据库）：**\n\n   **在提出修复之前，添加诊断工具：**\n   ```\n   对于每个组件边界：\n     - 记录什么数据进入组件\n     - 记录什么数据离开组件\n     - 验证环境/配置传播\n     - 检查每层的状态\n\n   运行一次以收集显示它在哪里中断的证据\n   然后分析证据以识别失败的组件\n   然后调查该特定组件\n   ```\n\n   **示例（多层系统）：**\n   ```bash\n   # 第 1 层：工作流\n   echo \"=== 工作流中可用的密钥：===\"\n   echo \"IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}\"\n\n   # 第 2 层：构建脚本\n   echo \"=== 构建脚本中的环境变量：===\"\n   env | grep IDENTITY || echo \"IDENTITY 不在环境中\"\n\n   # 第 3 层：签名脚本\n   echo \"=== 钥匙串状态：===\"\n   security list-keychains\n   security find-identity -v\n\n   # 第 4 层：实际签名\n   codesign --sign \"$IDENTITY\" --verbose=4 \"$APP\"\n   ```\n\n   **这揭示：** 哪一层失败（密钥 → 工作流 ✓，工作流 → 构建 ✗）\n\n5. **跟踪数据流**\n\n   **当错误在调用堆栈深处时：**\n\n   请参阅此目录中的 `root-cause-tracing.md` 了解完整的向后跟踪技术。\n\n   **快速版本：**\n   - 坏值源自哪里？\n   - 什么用坏值调用了这个？\n   - 继续向上跟踪直到找到源\n   - 在源处修复，而不是在症状处\n\n### 阶段 2：模式分析\n\n**在修复前找到模式：**\n\n1. **找到工作示例**\n   - 在同一代码库中定位类似的工作代码\n   - 什么与损坏的代码类似但能工作？\n\n2. **与参考进行比较**\n   - 如果实现模式，完全阅读参考实现\n   - 不要浏览 - 阅读每一行\n   - 在应用前完全理解模式\n\n3. **识别差异**\n   - 工作的和损坏的之间有什么不同？\n   - 列出每个差异，无论多小\n   - 不要假设\"那不重要\"\n\n4. **理解依赖关系**\n   - 这需要其他哪些组件？\n   - 需要什么设置、配置、环境？\n   - 它做了什么假设？\n\n### 阶段 3：假设和测试\n\n**科学方法：**\n\n1. **形成单一假设**\n   - 明确说明：\"我认为 X 是根本原因，因为 Y\"\n   - 写下来\n   - 具体，不要模糊\n\n2. **最小测试**\n   - 做最小可能的更改来测试假设\n   - 一次一个变量\n   - 不要一次修复多个问题\n\n3. **继续前验证**\n   - 它工作了吗？是 → 阶段 4\n   - 没工作？形成新假设\n   - 不要在上面添加更多修复\n\n4. **当你不知道时**\n   - 说\"我不理解 X\"\n   - 不要假装知道\n   - 寻求帮助\n   - 研究更多\n\n### 阶段 4：实施\n\n**修复根本原因，不是症状：**\n\n1. **创建失败测试用例**\n   - 最简单的可能复现\n   - 尽可能自动测试\n   - 如果没有框架，使用一次性测试脚本\n   - 修复前必须有\n   - 使用 `superpowers:test-driven-development` 技能编写适当的失败测试\n\n2. **实施单一修复**\n   - 解决已识别的根本原因\n   - 一次一个更改\n   - 没有\"顺便\"改进\n   - 没有捆绑重构\n\n3. **验证修复**\n   - 测试现在通过了吗？\n   - 没有其他测试损坏？\n   - 问题实际解决了？\n\n4. **如果修复不起作用**\n   - 停止\n   - 计数：你尝试了多少个修复？\n   - 如果 < 3：返回阶段 1，用新信息重新分析\n   - **如果 ≥ 3：停止并质疑架构（见下面的步骤 5）**\n   - 不要在没有架构讨论的情况下尝试修复 #4\n\n5. **如果 3+ 修复失败：质疑架构**\n\n   **表明架构问题的模式：**\n   - 每个修复都揭示不同地方的新共享状态/耦合/问题\n   - 修复需要\"大规模重构\"来实现\n   - 每个修复都在其他地方创建新症状\n\n   **停止并质疑基础：**\n   - 这个模式从根本上是否健全？\n   - 我们是否\"仅仅因为惯性而坚持它\"？\n   - 我们应该重构架构还是继续修复症状？\n\n   **在尝试更多修复之前与你的人类伙伴讨论**\n\n   这不是失败的假设 - 这是错误的架构。\n\n## 红旗 - 停止并遵循流程\n\n如果你发现自己在想：\n- \"现在快速修复，以后调查\"\n- \"只需尝试更改 X 看看是否有效\"\n- \"添加多个更改，运行测试\"\n- \"跳过测试，我会手动验证\"\n- \"可能是 X，让我修复它\"\n- \"我不完全理解，但这可能有效\"\n- \"模式说 X 但我会以不同方式适应它\"\n- \"这里是主要问题：[列出没有调查的修复]\"\n- 在跟踪数据流之前提出解决方案\n- **\"再尝试一次修复\"（已经尝试了 2+）**\n- **每个修复都揭示不同地方的新问题**\n\n**所有这些都意味着：停止。返回阶段 1。**\n\n**如果 3+ 修复失败：** 质疑架构（见阶段 4.5）\n\n## 你的人类伙伴的信号你做错了\n\n**注意这些重定向：**\n- \"那不是发生了吗？\" - 你未经验证就假设\n- \"它会告诉我们...？\" - 你应该添加证据收集\n- \"停止猜测\" - 你在不理解的情况下提出修复\n- \"超级思考这个\" - 质疑基础，而不仅仅是症状\n- \"我们卡住了？\"（沮丧）- 你的方法不起作用\n\n**当你看到这些：** 停止。返回阶段 1。\n\n## 常见的合理化\n\n| 借口 | 现实 |\n|------|------|\n| \"问题简单，不需要流程\" | 简单问题也有根本原因。流程对简单错误很快。 |\n| \"紧急情况，没时间流程\" | 系统性调试比猜测和检查的混乱更快。 |\n| \"先试试这个，然后调查\" | 第一个修复设定模式。从一开始就做对。 |\n| \"我会在确认修复有效后写测试\" | 未经测试的修复不会持久。先测试证明它。 |\n| \"一次多个修复节省时间\" | 无法隔离什么有效。导致新错误。 |\n| \"参考太长，我会适应模式\" | 部分理解保证错误。完全阅读它。 |\n| \"我看到问题了，让我修复它\" | 看到症状 ≠ 理解根本原因。 |\n| \"再尝试一次修复\"（2+ 失败后） | 3+ 失败 = 架构问题。质疑模式，不要再修复。 |\n\n## 快速参考\n\n| 阶段 | 关键活动 | 成功标准 |\n|------|----------|----------|\n| **1. 根本原因** | 阅读错误，重现，检查更改，收集证据 | 理解 WHAT 和 WHY |\n| **2. 模式** | 找到工作示例，比较 | 识别差异 |\n| **3. 假设** | 形成理论，最小测试 | 确认或新假设 |\n| **4. 实施** | 创建测试，修复，验证 | 错误解决，测试通过 |\n\n## 当流程揭示\"无根本原因\"时\n\n如果系统性调查揭示问题确实是环境性、时间依赖性或外部的：\n\n1. 你已经完成了流程\n2. 记录你调查了什么\n3. 实施适当的处理（重试，超时，错误消息）\n4. 添加监控/日志以便将来调查\n\n**但：** 95% 的\"无根本原因\"案例是调查不完整。\n\n## 支持技术\n\n这些技术是系统性调试的一部分，在此目录中可用：\n\n- **`root-cause-tracing.md`** - 通过调用堆栈向后跟踪错误以找到原始触发器\n- **`defense-in-depth.md`** - 在找到根本原因后在多个层添加验证\n- **`condition-based-waiting.md`** - 用条件轮询替换任意超时\n\n**相关技能：**\n- **superpowers:test-driven-development** - 用于创建失败测试用例（阶段 4，步骤 1）\n- **superpowers:verification-before-completion** - 在声称成功之前验证修复有效\n\n## 现实影响\n\n来自调试会话：\n- 系统方法：15-30 分钟修复\n- 随机修复方法：2-3 小时混乱\n- 首次修复率：95% 对 40%\n- 引入的新错误：几乎为零对常见\n"
+  },
+  {
+    "name": "test-driven-development",
+    "content": "---\nname: test-driven-development\ndescription: 在编写实现代码之前，实现任何功能或错误修复时使用\n---\n\n# 测试驱动开发 (TDD)\n\n## 概述\n\n先写测试。看着它失败。编写最小代码使其通过。\n\n**核心原则：** 如果你没有看到测试失败，你就不知道它是否测试了正确的东西。\n\n**违反规则的字面意思就是违反规则的精神。**\n\n## 何时使用\n\n**始终：**\n- 新功能\n- 错误修复\n- 重构\n- 行为变更\n\n**例外（询问你的人类伙伴）：**\n- 一次性原型\n- 生成的代码\n- 配置文件\n\n想“就这一次跳过 TDD”？停止。那是合理化。\n\n## 铁律\n\n```\n没有先失败的测试，就没有生产代码\n```\n\n在测试之前写代码？删除它。重新开始。\n\n**没有例外：**\n- 不要将其作为“参考”保留\n- 不要在编写测试时“适应”它\n- 不要看它\n- 删除意味着删除\n\n从测试中重新实现。就这样。\n\n## 红-绿-重构\n\n```dot\ndigraph tdd_cycle {\n    rankdir=LR;\n    red [label=\"RED\\n编写失败的测试\", shape=box, style=filled, fillcolor=\"#ffcccc\"];\n    verify_red [label=\"验证失败\\n正确\", shape=diamond];\n    green [label=\"GREEN\\n最小代码\", shape=box, style=filled, fillcolor=\"#ccffcc\"];\n    verify_green [label=\"验证通过\\n全部绿色\", shape=diamond];\n    refactor [label=\"REFACTOR\\n清理\", shape=box, style=filled, fillcolor=\"#ccccff\"];\n    next [label=\"下一个\", shape=ellipse];\n\n    red -> verify_red;\n    verify_red -> green [label=\"是\"];\n    verify_red -> red [label=\"错误\\n失败\"];\n    green -> verify_green;\n    verify_green -> refactor [label=\"是\"];\n    verify_green -> green [label=\"否\"];\n    refactor -> verify_green [label=\"保持\\n绿色\"];\n    verify_green -> next;\n    next -> red;\n}\n```\n\n### 红 - 编写失败的测试\n\n编写一个最小测试，显示应该发生什么。\n\n<Good>\n```typescript\ntest('重试失败操作 3 次', async () => {\n  let attempts = 0;\n  const operation = () => {\n    attempts++;\n    if (attempts < 3) throw new Error('fail');\n    return 'success';\n  };\n\n  const result = await retryOperation(operation);\n\n  expect(result).toBe('success');\n  expect(attempts).toBe(3);\n});\n```\n名称清晰，测试真实行为，一个测试一个行为\n</Good>\n\n<Bad>\n```typescript\ntest('重试有效', async () => {\n  const mock = jest.fn()\n    .mockRejectedValueOnce(new Error())\n    .mockRejectedValueOnce(new Error())\n    .mockResolvedValueOnce('success');\n  await retryOperation(mock);\n  expect(mock).toHaveBeenCalledTimes(3);\n});\n```\n名称模糊，测试模拟而非代码\n</Bad>\n\n**要求：**\n- 一个行为\n- 清晰的名称\n- 真实代码（除非不可避免，否则不要使用模拟）\n\n### 验证红 - 看着它失败\n\n**必须执行。永远不要跳过。**\n\n```bash\nnpm test path/to/test.test.ts\n```\n\n确认：\n- 测试失败（不是错误）\n- 失败消息符合预期\n- 失败是因为功能缺失（不是拼写错误）\n\n**测试通过？** 你在测试现有行为。修复测试。\n\n**测试错误？** 修复错误，重新运行直到正确失败。\n\n### 绿 - 最小代码\n\n编写最简单的代码以通过测试。\n\n<Good>\n```typescript\nasync function retryOperation<T>(fn: () => Promise<T>): Promise<T> {\n  for (let i = 0; i < 3; i++) {\n    try {\n      return await fn();\n    } catch (e) {\n      if (i === 2) throw e;\n    }\n  }\n  throw new Error('unreachable');\n}\n```\n刚好足够通过\n</Good>\n\n<Bad>\n```typescript\nasync function retryOperation<T>(\n  fn: () => Promise<T>,\n  options?: {\n    maxRetries?: number;\n    backoff?: 'linear' | 'exponential';\n    onRetry?: (attempt: number) => void;\n  }\n): Promise<T> {\n  // YAGNI\n}\n```\n过度设计\n</Bad>\n\n不要添加功能、重构其他代码或超出测试范围的“改进”。\n\n### 验证绿 - 看着它通过\n\n**必须执行。**\n\n```bash\nnpm test path/to/test.test.ts\n```\n\n确认：\n- 测试通过\n- 其他测试仍然通过\n- 输出纯净（无错误、警告）\n\n**测试失败？** 修复代码，不是测试。\n\n**其他测试失败？** 立即修复。\n\n### 重构 - 清理\n\n仅在绿色之后：\n- 移除重复\n- 改进名称\n- 提取辅助函数\n\n保持测试绿色。不要添加行为。\n\n### 重复\n\n下一个失败的测试用于下一个功能。\n\n## 好的测试\n\n| 质量 | 好 | 坏 |\n|------|----|----|\n| **最小** | 一个行为。名称中有 \"and\"？拆分它。 | `test('validates email and domain and whitespace')` |\n| **清晰** | 名称描述行为 | `test('test1')` |\n| **展示意图** | 演示期望的 API | 掩盖代码应该做什么 |\n\n## 为什么顺序很重要\n\n**\"我会在之后写测试来验证它有效\"**\n\n在代码之后写的测试立即通过。立即通过证明不了什么：\n- 可能测试错误的东西\n- 可能测试实现，而不是行为\n- 可能遗漏你忘记的边缘情况\n- 你从未看到它捕获错误\n\n测试优先迫使你看到测试失败，证明它实际上测试了某些东西。\n\n**\"我已经手动测试了所有边缘情况\"**\n\n手动测试是临时的。你认为你测试了一切，但：\n- 没有记录你测试了什么\n- 代码更改时无法重新运行\n- 在压力下容易忘记情况\n- \"我尝试时它有效\" ≠ 全面\n\n自动化测试是系统的。它们每次都以相同的方式运行。\n\n**\"删除 X 小时的工作是浪费的\"**\n\n沉没成本谬误。时间已经过去了。你现在的选择：\n- 删除并重写 TDD（再 X 小时，高信心）\n- 保留它并在之后添加测试（30 分钟，低信心，可能有错误）\n\n\"浪费\"是保留你不能信任的代码。没有真实测试的工作代码是技术债务。\n\n**\"TDD 是教条的，务实意味着适应\"**\n\nTDD 就是务实：\n- 在提交前发现错误（比之后调试更快）\n- 防止回归（测试立即捕获中断）\n- 记录行为（测试展示如何使用代码）\n- 启用重构（自由更改，测试捕获中断）\n\n\"务实\"的捷径 = 在生产中调试 = 更慢。\n\n**\"测试之后达到相同的目标 - 这是精神不是仪式\"**\n\n不。测试之后回答\"这做什么？\"。测试之前回答\"这应该做什么？\"。\n\n测试之后被你的实现所偏见。你测试你构建的东西，而不是需要的东西。你验证记住的边缘情况，而不是发现的边缘情况。\n\n测试之前迫使在实现之前发现边缘情况。测试之后验证你记住了一切（你没有）。\n\n30 分钟的测试之后 ≠ TDD。你获得覆盖率，失去测试工作的证明。\n\n## 常见的合理化\n\n| 借口 | 现实 |\n|------|------|\n| \"太简单了，不需要测试\" | 简单代码会中断。测试需要 30 秒。 |\n| \"我会之后测试\" | 立即通过的测试证明不了什么。 |\n| \"测试之后达到相同的目标\" | 测试之后 = \"这做什么？\" 测试之前 = \"这应该做什么？\" |\n| \"已经手动测试过了\" | 临时 ≠ 系统。无记录，无法重新运行。 |\n| \"删除 X 小时是浪费的\" | 沉没成本谬误。保留未验证的代码是技术债务。 |\n| \"保留作为参考，先写测试\" | 你会适应它。那是测试之后。删除意味着删除。 |\n| \"需要先探索\" | 很好。扔掉探索，从 TDD 开始。 |\n| \"测试难 = 设计不清\" | 听测试的。难测试 = 难使用。 |\n| \"TDD 会减慢我\" | TDD 比调试快。务实 = 测试优先。 |\n| \"手动测试更快\" | 手动不能证明边缘情况。你会重新测试每个更改。 |\n| \"现有代码没有测试\" | 你正在改进它。为现有代码添加测试。 |\n\n## 红旗 - 停止并重新开始\n\n- 测试之前的代码\n- 实现之后的测试\n- 测试立即通过\n- 无法解释测试为什么失败\n- \"稍后\"添加的测试\n- 合理化\"就这一次\"\n- \"我已经手动测试过了\"\n- \"测试之后达到相同的目的\"\n- \"这是精神不是仪式\"\n- \"保留作为参考\"或\"适应现有代码\"\n- \"已经花了 X 小时，删除是浪费的\"\n- \"TDD 是教条的，我在务实\"\n- \"这不同因为...\"\n\n**所有这些都意味着：删除代码。用 TDD 重新开始。**\n\n## 示例：错误修复\n\n**错误：** 接受空电子邮件\n\n**红**\n```typescript\ntest('拒绝空电子邮件', async () => {\n  const result = await submitForm({ email: '' });\n  expect(result.error).toBe('Email required');\n});\n```\n\n**验证红**\n```bash\n$ npm test\n失败：期望 'Email required'，得到 undefined\n```\n\n**绿**\n```typescript\nfunction submitForm(data: FormData) {\n  if (!data.email?.trim()) {\n    return { error: 'Email required' };\n  }\n  // ...\n}\n```\n\n**验证绿**\n```bash\n$ npm test\n通过\n```\n\n**重构**\n如果需要，提取多个字段的验证。\n\n## 验证清单\n\n在标记工作完成之前：\n\n- [ ] 每个新函数/方法都有测试\n- [ ] 每个测试在实现前都看到失败\n- [ ] 每个测试因预期原因失败（功能缺失，不是拼写错误）\n- [ ] 为每个测试编写最小代码以通过\n- [ ] 所有测试通过\n- [ ] 输出纯净（无错误、警告）\n- [ ] 测试使用真实代码（仅在不可避免时使用模拟）\n- [ ] 覆盖边缘情况和错误\n\n无法检查所有框？你跳过了 TDD。重新开始。\n\n## 卡住时\n\n| 问题 | 解决方案 |\n|------|----------|\n| 不知道如何测试 | 编写期望的 API。先编写断言。询问你的人类伙伴。 |\n| 测试太复杂 | 设计太复杂。简化接口。 |\n| 必须模拟一切 | 代码耦合度太高。使用依赖注入。 |\n| 测试设置庞大 | 提取辅助函数。仍然复杂？简化设计。 |\n\n## 调试集成\n\n发现错误？编写重现错误的失败测试。遵循 TDD 循环。测试证明修复并防止回归。\n\n永远不要没有测试就修复错误。\n\n## 测试反模式\n\n添加模拟或测试实用程序时，阅读 @testing-anti-patterns.md 以避免常见陷阱：\n- 测试模拟行为而不是真实行为\n- 向生产类添加仅测试方法\n- 在不理解依赖关系的情况下模拟\n\n## 最终规则\n\n```\n生产代码 → 测试存在且首先失败\n否则 → 不是 TDD\n```\n\n未经你的人类伙伴许可，无例外。\n"
+  },
+  {
+    "name": "ui-sdd",
+    "content": "\n# UI-SDD 完整整合版：App全域全景骨架 + 标准模板\n\n---\n\n## 第一部分：App全域全景骨架（项目启动第一步）\n\n### 核心定义\n**App全域全景骨架**：在写任何SDD、写任何代码前，先把整个App所有页面、弹窗、公共组件、全局隐性规则，梳理成一棵完整结构树。作用：定结构、定拆分、防遗漏。\n\n---\n\n### 具体5步流程（照着做！）\n\n#### 第1步：模拟用户完整走一遍App全流程\n从头到尾模拟真实用户操作，不思考设计、不写细节，只记录出现了哪些页面、哪些弹窗。\n\n**示例（地图导航App）**：\n```\n打开App → 启动页 → 首页（Tab）→ 搜索页 → 详情页 → 设置 → 退出\n            ↓\n         真实地图页\n            ↓\n         语音测试页\n```\n\n#### 第2步：逐一把看到的「页面、弹窗」全部罗列出来\n边走边记，看到什么写什么，不脑补、不省略。\n\n**示例（地图导航App）**：\n| 类型 | 名称 |\n|------|------|\n| 独立页面 | 启动页、首页、真实地图页、搜索页、语音测试页 |\n| 弹窗 | 确认弹窗、权限申请弹窗、语音识别中浮层 |\n| 反复出现组件 | 顶部导航栏、语音按钮、加载指示器、错误提示 |\n\n#### 第3步：分类归为三大类（固定分类）\n把罗列好的内容，强制分成3类：\n\n| 分类 | 说明 | 示例 |\n|------|------|------|\n| **业务页面（pages）** | 全屏独立页面，一页一个入口 | 启动页、首页、搜索页 |\n| **弹窗/浮层（dialog）** | 非全屏、弹出覆盖式 | 确认弹窗、权限弹窗 |\n| **全局公共组件（common）** | 多个页面复用的UI控件 | 导航栏、按钮、输入框 |\n\n#### 第4步：梳理「全局隐性规则」（最容易漏！）\n单独拉出一类，不属于页面也不属于组件，但是整个App都要遵守：\n\n| 规则分类 | 说明 | 示例 |\n|----------|------|------|\n| 全局配色/圆角/字体规范 | UI样式统一 | 主色调深海蓝、圆角统一8dp |\n| 平台适配 | iOS/Android差异 | iOS刘海安全区、Android物理返回 |\n| 页面路由/栈/返回逻辑 | 导航行为 | 返回保留页面栈、某些页面替换路由 |\n| 未登录拦截/登录态管理 | 用户状态 | 首次使用请求权限 |\n| 全局弱网/报错兜底 | 异常处理 | 网络不可用提示、加载失败重试 |\n| 全局键盘适配/防抖/权限流程 | 交互细节 | 键盘弹出布局调整、点击防抖 |\n\n#### 第5步：整理成「树形全景骨架结构」\n把上面三类，整理成树状层级：\n\n```\nApp全域全景骨架\n├─ 启动流程页面\n│  ├─ 启动页（闪屏）\n│  └─ 隐私协议页（可选）\n├─ 主业务页面\n│  ├─ 首页\n│  ├─ 真实地图页\n│  ├─ 搜索页\n│  └─ 语音测试页\n├─ 全局弹窗/浮层\n│  ├─ 通用确认弹窗\n│  ├─ 权限申请弹窗\n│  └─ 语音识别浮层\n├─ 全局公共组件\n│  ├─ 顶部导航栏\n│  ├─ 语音按钮\n│  ├─ 加载指示器\n│  ├─ 错误提示\n│  └─ 确认弹窗\n└─ 全局隐性规则\n   ├─ 样式规范（颜色/字体/间距）\n   ├─ 平台适配（iOS/Android）\n   ├─ 路由逻辑（栈/返回）\n   ├─ 权限流程（定位/麦克风）\n   └─ 网络/键盘/防抖\n```\n\n---\n\n### 极简口诀（记住就会！）\n1. **模拟用户走全程**\n2. **所见全部罗列**\n3. **分成页面/弹窗/组件三类**\n4. **补上全局隐性规则**\n5. **整理成树形骨架**\n\n---\n\n### 画完骨架后马上能做什么？\n1. 直接按这个树，**建立SDD目录文件夹**\n2. 每个页面/弹窗/组件，对应新建SDD文档\n3. 对照骨架做「UI交互盘点清单」逐项打勾\n4. 保证后面所有SDD **100%全覆盖无遗漏**\n\n---\n\n## 第二部分：UI交互专用SDD标准模板\n\n### 何时使用\n- 需要为新页面、弹窗、复杂组件编写设计文档\n- 需要确保UI布局、交互、状态能1:1还原\n- 适用于Web、原生iOS、原生Android、Flutter项目\n- 需要替代原型设计，直接通过文档驱动开发\n\n---\n\n### 模板结构（完整11部分）\n\n#### 1. 基础信息\n| 字段 | 说明 |\n|------|------|\n| **归属平台** | Web / 原生iOS / 原生Android / Flutter |\n| **页面名称** | 页面的正式名称 |\n| **页面路由** | 路由地址（Web/Flutter）或页面标识 |\n| **关联用户故事** | 对应的用户故事ID或描述 |\n| **依赖接口/本地缓存** | 所需的数据接口或本地存储 |\n| **适配机型/系统版本** | 适配范围 |\n\n#### 2. 整体页面结构布局\n- 整体布局方式：固定布局 / 流式 / 弹性 / 卡片式\n- 页面整体分区（从上到下/从左到右）\n- 全局样式基准（统一约束）\n\n#### 3. 页面所有状态定义（必写！）\n必须逐条定义，不能只写正常状态：\n1. 默认初始态\n2. 加载中态（全局/局部）\n3. 空数据态\n4. 网络异常/接口报错态\n5. 表单禁用/按钮置灰态\n6. 操作成功反馈态\n7. 键盘弹出适配态（移动端必写）\n\n#### 4. 组件清单 & 静态UI描述\n逐个列出页面所有控件，每项写清楚：\n- 位置\n- 文案/占位符\n- 默认样式\n- 显隐条件\n\n#### 5. 逐组件交互逻辑（核心！）\n| 组件类型 | 需定义内容 |\n|----------|------------|\n| 输入类 | 输入规则、实时校验、清空按钮、键盘类型 |\n| 点击类 | 触发动作、防抖间隔、禁用条件、重复点击、点击反馈 |\n| 手势类 | 滑动、下拉刷新、长按、iOS右滑返回、Android物理返回 |\n\n#### 6. 弹窗、浮层、Toast交互规则\n- 触发条件\n- 弹出动画\n- 遮罩是否可点击关闭\n- 按钮确认/取消行为\n- 自动消失时长\n- 弹窗关闭后页面状态保留规则\n\n#### 7. 页面跳转 & 返回逻辑\n| 场景 | 路由 | 返回逻辑 | 保留页面栈 | 替换路由 |\n|------|------|----------|------------|----------|\n| 正向跳转 | | | | |\n| 返回上一页 | | | | |\n\n#### 8. 动画 & 过渡效果\n- 页面进入/退出过渡动画\n- 加载动画样式\n- 按钮点击动效\n- 列表加载骨架屏动效\n\n#### 9. 边界&异常场景处理\n1. 弱网/无网络时表现\n2. 接口报错文案展示\n3. 输入超限、特殊字符拦截\n4. 无权限访问处理\n5. 首次进入/非首次进入差异化\n\n#### 10. 平台差异化专属规则\n分别说明iOS、Android、Flutter、Web的差异。\n\n#### 11. 验收标准（UI视觉 + 交互行为逐条可测！）\n- 视觉验收\n- 状态验收\n- 交互验收\n- 异常验收\n- 平台适配验收\n\n---\n\n## 第三部分：完整工作流程\n\n### 项目从零启动（需求→UI→实现）\n```\n1. 用 sdd 技能：拆 Epic→Feature→Story，写验收标准，做估算\n2. 用 ui-sdd 的「App全域全景骨架」：梳理完整结构，建目录\n3. 用 ui-sdd 的「标准模板」：逐个页面写SDD\n4. 交付开发（或用 sdd-add 做快速实现）\n```\n\n### 正常迭代开发（日常新功能）\n```\n1. 用 sdd：把新功能拆成 Story，写验收标准\n2. 用 ui-sdd：回「全景骨架」补勾，补建/更新SDD\n3. 用 sdd-add：做快速实现，需求文档必须引用 sdd 的 Story 和 ui-sdd 的 SDD\n```\n\n### 临时需求/紧急修复\n```\n1. 直接用 sdd-add：快速澄清、优先级、实现\n2. 如果涉及UI/新增页面：必须同步回 ui-sdd 补勾、补建SDD\n3. 如果涉及Story拆分：必须同步回 sdd 补Story\n```\n\n---\n\n## 第四部分：文档关联引用规范\n\n### sdd Story 中引用 ui-sdd\n在 sdd 产出的 Story 文档中加入：\n```markdown\n## 关联文档\n- 对应UI交互SDD：spec/ui/pages/xxx-page.sdd.md\n- 复用组件SDD：spec/ui/common/ui-yyy.sdd.md\n- 相关弹窗SDD：spec/ui/dialog/zzz-dialog.sdd.md\n```\n\n### ui-sdd SDD 中引用 sdd Story\n在 ui-sdd 产出的页面/组件SDD中加入：\n```markdown\n## 关联用户故事\n- 主故事：US-001（在 docs/stories/user_stories.md）\n- 相关故事：US-002、US-003\n```\n\n### sdd-add 临时需求中引用前两者\n在 sdd-add 产出的临时需求文档中加入：\n```markdown\n## 关联文档\n- 关联Story：docs/stories/user_stories.md 中的 US-xxx\n- 关联UI-SDD：spec/ui/pages/yyy-page.sdd.md\n```\n\n---\n\n## 第五部分：一句话原则\n\n**「sdd 定方向（做什么），ui-sdd 定样子（怎么做），sdd-add 填细节（快速补）；从上往下拆，从下往上补，互相引用不遗漏」**\n\n---\n\n## 附录：快速检查表\n\n### 「App全域全景骨架」完成检查\n- [ ] 第1步：模拟用户走完全程\n- [ ] 第2步：所见全部罗列（页面/弹窗/组件）\n- [ ] 第3步：分成三大类（pages/dialog/common）\n- [ ] 第4步：补上全局隐性规则\n- [ ] 第5步：整理成树形结构\n\n### 单个UI-SDD文档完成检查\n- [ ] 基础信息完整\n- [ ] 页面结构清晰\n- [ ] 所有状态定义（至少7种）\n- [ ] 组件清单及静态UI\n- [ ] 交互逻辑详细（包括防抖、点击反馈）\n- [ ] 平台适配规则\n- [ ] 验收标准明确（逐条可测）\n\n---\n\n## 最佳实践总结\n\n1. **骨架先行**：先画App全域全景骨架，再写单个SDD\n2. **状态优先**：定义所有状态，再写组件和交互\n3. **交互细化**：每个交互都要考虑边缘情况（防抖、反馈等）\n4. **平台适配**：明确列出各平台的差异\n5. **验收标准**：每条标准都要可测试\n6. **互相引用**：sdd、ui-sdd、sdd-add 三者文档互相关联\n\n---\n\n*文档版本：v1.0 | 最后更新：2026-05-04*\n"
+  },
+  {
+    "name": "using-superpowers",
+    "content": "---\nname: using-superpowers\ndescription: 当开始任何对话时使用 - 建立如何查找和使用技能的方法，要求在包括澄清问题在内的任何响应之前调用Skill工具\n---\n\n<SUBAGENT-STOP>\n如果您被派作为子代理执行特定任务，请跳过此技能。\n</SUBAGENT-STOP>\n\n<EXTREMELY-IMPORTANT>\n如果您认为技能可能适用于您正在做的事情的可能性甚至为1%，您绝对必须调用该技能。\n\n如果技能适用于您的任务，您没有选择。您必须使用它。\n\n这是不可协商的。这不是可选的。您不能通过理性思考来逃避这一点。\n</EXTREMELY-IMPORTANT>\n\n## 指令优先级\n\nSuperpowers技能会覆盖默认的系统提示行为，但**用户指令始终优先**：\n\n1. **用户的明确指令**（CLAUDE.md、GEMINI.md、AGENTS.md、直接请求）— 最高优先级\n2. **Superpowers技能** — 在冲突时覆盖默认系统行为\n3. **默认系统提示** — 最低优先级\n\n如果CLAUDE.md、GEMINI.md或AGENTS.md说\"不要使用TDD\"，而技能说\"始终使用TDD\"，请遵循用户的指令。用户是控制者。\n\n## 如何访问技能\n\n**在Claude Code中：** 使用`Skill`工具。当您调用技能时，其内容会加载并呈现给您——直接遵循它。永远不要在技能文件上使用Read工具。\n\n**在Gemini CLI中：** 技能通过`activate_skill`工具激活。Gemini在会话开始时加载技能元数据，并根据需要激活完整内容。\n\n**在其他环境中：** 查看您平台的文档，了解如何加载技能。\n\n## 平台适应\n\n技能使用Claude Code工具名称。非CC平台：请参阅`references/codex-tools.md`（Codex）了解工具等效项。Gemini CLI用户通过GEMINI.md自动加载工具映射。\n\n# 使用技能\n\n## 规则\n\n**在任何响应或操作之前调用相关或请求的技能。** 即使技能可能适用的可能性为1%，也意味着您应该调用技能进行检查。如果调用的技能结果证明不适合该情况，您不需要使用它。\n\n```dot\ndigraph skill_flow {\n    \"收到用户消息\" [shape=doublecircle];\n    \"即将进入计划模式？\" [shape=doublecircle];\n    \"已经进行头脑风暴？\" [shape=diamond];\n    \"调用头脑风暴技能\" [shape=box];\n    \"可能适用任何技能？\" [shape=diamond];\n    \"调用Skill工具\" [shape=box];\n    \"宣布：'使用[技能]进行[目的]'\" [shape=box];\n    \"有清单？\" [shape=diamond];\n    \"为每个项目创建TodoWrite待办事项\" [shape=box];\n    \"严格遵循技能\" [shape=box];\n    \"响应（包括澄清）\" [shape=doublecircle];\n\n    \"即将进入计划模式？\" -> \"已经进行头脑风暴？\";\n    \"已经进行头脑风暴？\" -> \"调用头脑风暴技能\" [label=\"否\"];\n    \"已经进行头脑风暴？\" -> \"可能适用任何技能？\" [label=\"是\"];\n    \"调用头脑风暴技能\" -> \"可能适用任何技能？\";\n\n    \"收到用户消息\" -> \"可能适用任何技能？\";\n    \"可能适用任何技能？\" -> \"调用Skill工具\" [label=\"是，即使1%\"];\n    \"可能适用任何技能？\" -> \"响应（包括澄清）\" [label=\"绝对不\"];\n    \"调用Skill工具\" -> \"宣布：'使用[技能]进行[目的]'\";\n    \"宣布：'使用[技能]进行[目的]'\" -> \"有清单？\";\n    \"有清单？\" -> \"为每个项目创建TodoWrite待办事项\" [label=\"是\"];\n    \"有清单？\" -> \"严格遵循技能\" [label=\"否\"];\n    \"为每个项目创建TodoWrite待办事项\" -> \"严格遵循技能\";\n}\n```\n\n## 红旗\n\n这些想法意味着停止——您在合理化：\n\n| 想法 | 现实 |\n|------|------|\n| \"这只是一个简单的问题\" | 问题是任务。检查技能。 |\n| \"我需要先了解更多上下文\" | 技能检查在澄清问题之前进行。 |\n| \"让我先探索代码库\" | 技能告诉您如何探索。先检查。 |\n| \"我可以快速检查git/文件\" | 文件缺乏对话上下文。检查技能。 |\n| \"让我先收集信息\" | 技能告诉您如何收集信息。 |\n| \"这不需要正式技能\" | 如果技能存在，使用它。 |\n| \"我记得这个技能\" | 技能会演变。阅读当前版本。 |\n| \"这不算任务\" | 行动=任务。检查技能。 |\n| \"技能过度了\" | 简单的事情会变得复杂。使用它。 |\n| \"我先做这件事\" | 在做任何事情之前检查。 |\n| \"这感觉很有成效\" | 无纪律的行动浪费时间。技能可以防止这种情况。 |\n| \"我知道那是什么意思\" | 知道概念≠使用技能。调用它。 |\n\n## 技能优先级\n\n当多个技能可能适用时，使用此顺序：\n\n1. **首先是流程技能**（头脑风暴、调试）- 这些决定如何处理任务\n2. **其次是实现技能**（前端设计、mcp-builder）- 这些指导执行\n\n\"让我们构建X\" → 先头脑风暴，然后是实现技能。\n\"修复这个错误\" → 先调试，然后是领域特定技能。\n\n## 技能类型\n\n**严格**（TDD、调试）：严格遵循。不要放弃纪律。\n\n**灵活**（模式）：根据上下文调整原则。\n\n技能本身会告诉您是哪一种。\n\n## 用户指令\n\n指令说明做什么，而不是怎么做。\"添加X\"或\"修复Y\"并不意味着跳过工作流程。\n"
+  },
+  {
+    "name": "verification-before-completion",
+    "content": "---\nname: verification-before-completion\ndescription: 在声称工作完成、修复或通过之前使用，在提交或创建 PR 之前 - 需要运行验证命令并在做出任何成功声明之前确认输出；始终证据先于断言\n---\n\n# 完成前验证\n\n## 概述\n\n在没有验证的情况下声称工作完成是不诚实，不是效率。\n\n**核心原则：** 始终证据先于声明。\n\n**违反此规则的字面意思就是违反此规则的精神。**\n\n## 铁律\n\n```\n没有新鲜的验证证据，就没有完成声明\n```\n\n如果你没有在这条消息中运行验证命令，你不能声称它通过。\n\n## 门控函数\n\n```\n在声称任何状态或表达满意之前：\n\n1. 识别：什么命令证明这个声明？\n2. 运行：执行完整命令（新鲜，完整）\n3. 阅读：完整输出，检查退出代码，计数失败\n4. 验证：输出是否确认声明？\n   - 如果否：用证据说明实际状态\n   - 如果是：用证据说明声明\n5. 只有这样：做出声明\n\n跳过任何步骤 = 说谎，不是验证\n```\n\n## 常见失败\n\n| 声明 | 需要 | 不足够 |\n|------|------|--------|\n| 测试通过 | 测试命令输出：0 失败 | 之前的运行，\"应该通过\" |\n| 代码检查干净 | 代码检查输出：0 错误 | 部分检查，推断 |\n| 构建成功 | 构建命令：退出 0 | 代码检查通过，日志看起来不错 |\n| 错误已修复 | 测试原始症状：通过 | 代码已更改，假设已修复 |\n| 回归测试有效 | 红-绿循环已验证 | 测试通过一次 |\n| 代理完成 | VCS diff 显示更改 | 代理报告\"成功\" |\n| 满足要求 | 逐行检查清单 | 测试通过 |\n\n## 红旗 - 停止\n\n- 使用\"应该\"、\"可能\"、\"似乎\"\n- 在验证前表达满意（\"太好了！\"、\"完美！\"、\"完成！\"等）\n- 在没有验证的情况下即将提交/推送/PR\n- 信任代理成功报告\n- 依赖部分验证\n- 想\"就这一次\"\n- 疲倦并希望工作结束\n- **任何暗示成功但未运行验证的措辞**\n\n## 防止合理化\n\n| 借口 | 现实 |\n|------|------|\n| \"现在应该工作\" | 运行验证 |\n| \"我有信心\" | 信心 ≠ 证据 |\n| \"就这一次\" | 无例外 |\n| \"代码检查通过\" | 代码检查 ≠ 编译器 |\n| \"代理说成功\" | 独立验证 |\n| \"我累了\" | 疲惫 ≠ 借口 |\n| \"部分检查足够\" | 部分证明不了什么 |\n| \"不同的词，所以规则不适用\" | 精神胜于字面 |\n\n## 关键模式\n\n**测试：**\n```\n✅ [运行测试命令] [见：34/34 通过] \"所有测试通过\"\n❌ \"现在应该通过\" / \"看起来正确\"\n```\n\n**回归测试（TDD 红-绿）：**\n```\n✅ 编写 → 运行（通过）→ 恢复修复 → 运行（必须失败）→ 恢复 → 运行（通过）\n❌ \"我已经编写了回归测试\"（没有红-绿验证）\n```\n\n**构建：**\n```\n✅ [运行构建] [见：退出 0] \"构建通过\"\n❌ \"代码检查通过\"（代码检查不检查编译）\n```\n\n**要求：**\n```\n✅ 重新阅读计划 → 创建检查清单 → 验证每个 → 报告差距或完成\n❌ \"测试通过，阶段完成\"\n```\n\n**代理委托：**\n```\n✅ 代理报告成功 → 检查 VCS diff → 验证更改 → 报告实际状态\n❌ 信任代理报告\n```\n\n## 为什么这很重要\n\n来自 24 个失败记忆：\n- 你的人类伙伴说\"我不相信你\" - 信任破裂\n- 未定义函数被发布 - 会崩溃\n- 缺少要求被发布 - 功能不完整\n- 时间浪费在错误的完成上 → 重定向 → 返工\n- 违反：\"诚实是核心价值观。如果你撒谎，你将被替换。\"\n\n## 何时应用\n\n**始终在之前：**\n- 任何成功/完成声明的变体\n- 任何满意的表达\n- 任何关于工作状态的积极陈述\n- 提交、PR 创建、任务完成\n- 移动到下一个任务\n- 委托给代理\n\n**规则适用于：**\n- 确切短语\n- 释义和同义词\n- 成功的暗示\n- 任何暗示完成/正确性的沟通\n\n## 底线\n\n**验证没有捷径。**\n\n运行命令。阅读输出。然后声明结果。\n\n这是不可协商的。\n"
+  },
+  {
+    "name": "writing-plans",
+    "content": "---\nname: writing-plans\ndescription: 当你有规范或多步骤任务的需求时，在接触代码前使用\n---\n\n# 编写计划\n\n## 概述\n\n编写全面的实现计划，假设工程师对我们的代码库没有任何上下文，并且品味可疑。记录他们需要知道的一切：每个任务需要修改哪些文件、代码、测试、他们可能需要检查的文档、如何测试。将整个计划分解为 bite-sized 任务。DRY（不要重复自己）、YAGNI（你不会需要它）、TDD（测试驱动开发）、频繁提交。\n\n假设他们是熟练的开发人员，但对我们的工具集或问题域几乎一无所知。假设他们不太了解良好的测试设计。\n\n**开始时宣布：** \"我正在使用 writing-plans 技能创建实现计划。\"\n\n**上下文：** 这应该在专用的工作树中运行（由 brainstorming 技能创建）。\n\n**保存计划到：** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`\n- （用户对计划位置的偏好覆盖此默认值）\n\n## 范围检查\n\n如果规范涵盖多个独立子系统，在头脑风暴期间应该已经分解为子项目规范。如果没有，建议将其分解为单独的计划 - 每个子系统一个。每个计划都应该独立产生可工作、可测试的软件。\n\n## 文件结构\n\n在定义任务之前，映射出将创建或修改哪些文件以及每个文件的职责。这是分解决策被锁定的地方。\n\n- 设计具有明确边界和定义良好接口的单元。每个文件应该有一个明确的职责。\n- 你对能一次保持在上下文中的代码推理得最好，当文件集中时，你的编辑更可靠。优先选择较小、集中的文件，而不是做太多事情的大文件。\n- 一起更改的文件应该放在一起。按职责划分，而不是按技术层划分。\n- 在现有代码库中，遵循已建立的模式。如果代码库使用大文件，不要单方面重构 - 但如果你正在修改的文件变得难以管理，在计划中包含拆分是合理的。\n\n这种结构为任务分解提供信息。每个任务应该产生独立有意义的自包含更改。\n\n## Bite-Sized 任务粒度\n\n**每个步骤是一个动作（2-5分钟）：**\n- \"编写失败的测试\" - 步骤\n- \"运行它以确保它失败\" - 步骤\n- \"实现最小代码以使测试通过\" - 步骤\n- \"运行测试并确保它们通过\" - 步骤\n- \"提交\" - 步骤\n\n## 计划文档标题\n\n**每个计划必须以以下标题开始：**\n\n```markdown\n# [功能名称] 实现计划\n\n> **对于代理工作者：** 必需：使用 superpowers:subagent-driven-development（如果子代理可用）或 superpowers:executing-plans 来实现此计划。步骤使用复选框（`- [ ]`）语法进行跟踪。\n\n**目标：** [一句话描述此构建内容]\n\n**架构：** [关于方法的2-3句话]\n\n**技术栈：** [关键技术/库]\n\n---\n```\n\n## 任务结构\n\n````markdown\n### 任务 N：[组件名称]\n\n**文件：**\n- 创建：`exact/path/to/file.py`\n- 修改：`exact/path/to/existing.py:123-145`\n- 测试：`tests/exact/path/to/test.py`\n\n- [ ] **步骤 1：编写失败的测试**\n\n```python\ndef test_specific_behavior():\n    result = function(input)\n    assert result == expected\n```\n\n- [ ] **步骤 2：运行测试以验证它失败**\n\n运行：`pytest tests/path/test.py::test_name -v`\n预期：失败，提示 \"function not defined\"\n\n- [ ] **步骤 3：编写最小实现**\n\n```python\ndef function(input):\n    return expected\n```\n\n- [ ] **步骤 4：运行测试以验证它通过**\n\n运行：`pytest tests/path/test.py::test_name -v`\n预期：通过\n\n- [ ] **步骤 5：提交**\n\n```bash\ngit add tests/path/test.py src/path/file.py\ngit commit -m \"feat: add specific feature\"\n```\n````\n\n## 记住\n- 始终使用精确的文件路径\n- 计划中包含完整的代码（不是 \"添加验证\"）\n- 带有预期输出的精确命令\n- 使用 @ 语法引用相关技能\n- DRY、YAGNI、TDD、频繁提交\n\n## 计划审查循环\n\n编写完整计划后：\n\n1. 调度单个 plan-document-reviewer 子代理（参见 plan-document-reviewer-prompt.md），使用精心设计的审查上下文 - 绝不是你的会话历史。这使审查者专注于计划，而不是你的思考过程。\n   - 提供：计划文档路径，规范文档路径\n2. 如果 ❌ 发现问题：修复问题，重新调度审查者审查整个计划\n3. 如果 ✅ 批准：继续执行交接\n\n**审查循环指导：**\n- 编写计划的同一代理修复它（保留上下文）\n- 如果循环超过3次迭代，提交给人类指导\n- 审查者是顾问 - 如果你认为反馈不正确，解释分歧\n\n## 执行交接\n\n保存计划后：\n\n**\"计划完成并保存到 `docs/superpowers/plans/<filename>.md`。准备执行？\"**\n\n**执行路径取决于 harness 能力：**\n\n**如果 harness 有子代理（Claude Code 等）：**\n- **必需：** 使用 superpowers:subagent-driven-development\n- 不要提供选择 - 子代理驱动是标准方法\n- 每个任务使用新的子代理 + 两阶段审查\n\n**如果 harness 没有子代理：**\n- 在当前会话中使用 superpowers:executing-plans 执行计划\n- 批处理执行，带有审查检查点\n"
+  }
+];