sdd-full 3.2.0 → 4.0.0

package/skills/special-tools/receiving-code-review/SKILL.md

@@ -1,215 +0,0 @@
-【claude code调用标识：receiving-code-review】【trae调用标识：receiving-code-review+代码审查接收】【流程场景：1.完整3阶段SDD流程、3.小型功能迭代、5.代码发布】
-
----
-name: receiving-code-review
-description: 在收到代码审查反馈时使用，在实施建议之前，特别是如果反馈似乎不清楚或技术上有问题 - 需要技术严谨性和验证，而不是表演性同意或盲目实施
----
-
-# 代码审查接收
-
-## 概述
-
-代码审查需要技术评估，而不是情感表演。
-
-**核心原则：** 实施前验证。假设前询问。技术正确性优先于社交舒适度。
-
-## 响应模式
-
-```
-收到代码审查反馈时：
-
-1. 阅读：完整阅读反馈，不做出反应
-2. 理解：用自己的话重述要求（或询问）
-3. 验证：对照代码库现实进行检查
-4. 评估：对这个代码库技术上是否合理？
-5. 响应：技术确认或有理由的反驳
-6. 实施：一次一个项目，测试每个项目
-```
-
-## 禁止的响应
-
-**永远不要：**
-- "你绝对正确！"（明确违反 CLAUDE.md）
-- "好观点！" / "优秀的反馈！"（表演性的）
-- "让我现在实施那个"（验证前）
-
-**相反：**
-- 重述技术要求
-- 提出澄清问题
-- 如果错误，用技术推理反驳
-- 直接开始工作（行动 > 言语）
-
-## 处理不清楚的反馈
-
-```
-如果任何项目不清楚：
-  停止 - 暂时不要实施任何内容
-  要求澄清不清楚的项目
-
-原因：项目可能相关。部分理解 = 错误实施。
-```
-
-**示例：**
-```
-你的人类伙伴："修复 1-6"
-你理解 1,2,3,6。对 4,5 不清楚。
-
-❌ 错误：现在实施 1,2,3,6，稍后询问 4,5
-✅ 正确："我理解项目 1,2,3,6。在继续之前需要澄清 4 和 5。"
-```
-
-## 特定来源处理
-
-### 来自你的人类伙伴
-- **可信** - 理解后实施
-- **如果范围不清楚，仍要询问**
-- **无表演性同意**
-- **直接行动**或技术确认
-
-### 来自外部审查者
-```
-实施前：
-  1. 检查：对这个代码库技术上是否正确？
-  2. 检查：是否破坏现有功能？
-  3. 检查：当前实现的原因？
-  4. 检查：是否在所有平台/版本上工作？
-  5. 检查：审查者是否理解完整上下文？
-
-如果建议似乎错误：
-  用技术推理反驳
-
-如果无法轻松验证：
-  说明："没有 [X] 我无法验证这一点。我应该 [调查/询问/继续]？"
-
-如果与你的人类伙伴之前的决定冲突：
-  先停止并与你的人类伙伴讨论
-```
-
-**你的人类伙伴的规则：** "外部反馈 - 保持怀疑，但仔细检查"
-
-## "专业"功能的 YAGNI 检查
-
-```
-如果审查者建议"正确实施"：
-  在代码库中搜索实际使用
-
-  如果未使用："这个端点没有被调用。移除它（YAGNI）？"
-  如果使用：则正确实施
-```
-
-**你的人类伙伴的规则：** "你和审查者都向我报告。如果我们不需要这个功能，就不要添加它。"
-
-## 实施顺序
-
-```
-对于多项反馈：
-  1. 首先澄清任何不清楚的内容
-  2. 然后按以下顺序实施：
-     - 阻塞问题（中断，安全）
-     - 简单修复（拼写错误，导入）
-     - 复杂修复（重构，逻辑）
-  3. 单独测试每个修复
-  4. 验证无回归
-```
-
-## 何时反驳
-
-当以下情况时反驳：
-- 建议破坏现有功能
-- 审查者缺乏完整上下文
-- 违反 YAGNI（未使用的功能）
-- 对这个技术栈技术上不正确
-- 存在遗留/兼容性原因
-- 与你的人类伙伴的架构决策冲突
-
-**如何反驳：**
-- 使用技术推理，而非防御性
-- 提出具体问题
-- 引用工作测试/代码
-- 如果是架构问题，让你的人类伙伴参与
-
-**如果不愿意大声反驳的信号：** "Circle K 有奇怪的事情发生"
-
-## 确认正确的反馈
-
-当反馈正确时：
-```
-✅ "已修复。[对更改的简要描述]"
-✅ "好发现 - [具体问题]。在 [位置] 已修复。"
-✅ [直接修复并在代码中显示]
-
-❌ "你绝对正确！"
-❌ "好观点！"
-❌ "感谢发现那个！"
-❌ "感谢 [任何内容]"
-❌ 任何感谢表达
-```
-
-**为什么不感谢：** 行动说话。直接修复。代码本身表明你听到了反馈。
-
-**如果你发现自己要写"谢谢"：** 删除它。改为说明修复。
-
-## 优雅地纠正你的反驳
-
-如果你反驳了但错了：
-```
-✅ "你是对的 - 我检查了 [X]，它确实 [Y]。现在实施。"
-✅ "验证了这一点，你是正确的。我最初的理解是错误的，因为 [原因]。正在修复。"
-
-❌ 冗长的道歉
-❌ 为你反驳的原因辩护
-❌ 过度解释
-```
-
-事实陈述纠正并继续。
-
-## 常见错误
-
-| 错误 | 修复 |
-|------|------|
-| 表演性同意 | 说明要求或直接行动 |
-| 盲目实施 | 首先对照代码库验证 |
-| 批量实施而不测试 | 一次一个，测试每个 |
-| 假设审查者是对的 | 检查是否破坏事物 |
-| 避免反驳 | 技术正确性 > 舒适度 |
-| 部分实施 | 首先澄清所有项目 |
-| 无法验证，仍继续 | 说明限制，请求方向 |
-
-## 真实示例
-
-**表演性同意（错误）：**
-```
-审查者："移除遗留代码"
-❌ "你绝对正确！让我移除那个..."
-```
-
-**技术验证（正确）：**
-```
-审查者："移除遗留代码"
-✅ "检查中... 构建目标是 10.15+，此 API 需要 13+。需要遗留代码以保持向后兼容。当前实现的 bundle ID 错误 - 修复它还是放弃 13 之前的支持？"
-```
-
-**YAGNI（正确）：**
-```
-审查者："实施带有数据库、日期过滤器、CSV 导出的适当指标跟踪"
-✅ "搜索代码库 - 没有调用此端点。移除它（YAGNI）？还是我遗漏了使用情况？"
-```
-
-**不清楚的项目（正确）：**
-```
-你的人类伙伴："修复项目 1-6"
-你理解 1,2,3,6。对 4,5 不清楚。
-✅ "理解 1,2,3,6。在实施之前需要澄清 4 和 5。"
-```
-
-## GitHub 线程回复
-
-在 GitHub 上回复内联审查评论时，在评论线程中回复（`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`），而不是作为顶级 PR 评论。
-
-## 底线
-
-**外部反馈 = 要评估的建议，不是要遵循的命令。**
-
-验证。提问。然后实施。
-
-无表演性同意。始终保持技术严谨。

package/skills/special-tools/requesting-code-review/SKILL.md

@@ -1,107 +0,0 @@
-【claude code调用标识：requesting-code-review】【trae调用标识：requesting-code-review+请求代码审查】【流程场景：1.完整3阶段SDD流程、3.小型功能迭代、5.代码发布】
-
----
-name: requesting-code-review
-description: 在完成任务、实现主要功能或合并前使用，以验证工作是否满足要求
----
-
-# 请求代码审查
-
-调度 superpowers:code-reviewer 子代理，在问题扩散前捕获它们。审查者获得精确设计的评估上下文 - 绝不是你的会话历史。这使审查者专注于工作产品，而不是你的思考过程，并保留你自己的上下文以继续工作。
-
-**核心原则：** 尽早审查，经常审查。
-
-## 何时请求审查
-
-**必须：**
-- 子代理驱动开发中的每个任务后
-- 完成主要功能后
-- 合并到 main 之前
-
-**可选但有价值：**
-- 卡住时（新鲜视角）
-- 重构前（基线检查）
-- 修复复杂错误后
-
-## 如何请求
-
-**1. 获取 git SHAs：**
-```bash
-BASE_SHA=$(git rev-parse HEAD~1)  # 或 origin/main
-HEAD_SHA=$(git rev-parse HEAD)
-```
-
-**2. 调度代码审查子代理：**
-
-使用 Task 工具与 superpowers:code-reviewer 类型，填写 `code-reviewer.md` 中的模板
-
-**占位符：**
-- `{WHAT_WAS_IMPLEMENTED}` - 你刚刚构建的内容
-- `{PLAN_OR_REQUIREMENTS}` - 它应该做什么
-- `{BASE_SHA}` - 起始提交
-- `{HEAD_SHA}` - 结束提交
-- `{DESCRIPTION}` - 简短摘要
-
-**3. 根据反馈行动：**
-- 立即修复关键问题
-- 在继续之前修复重要问题
-- 记录次要问题以便以后处理
-- 如果审查者错误，反驳（带有理由）
-
-## 示例
-
-```
-[刚刚完成任务 2：添加验证函数]
-
-你：让我在继续之前请求代码审查。
-
-BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
-HEAD_SHA=$(git rev-parse HEAD)
-
-[调度 superpowers:code-reviewer 子代理]
-  WHAT_WAS_IMPLEMENTED: 对话索引的验证和修复函数
-  PLAN_OR_REQUIREMENTS: docs/superpowers/plans/deployment-plan.md 中的任务 2
-  BASE_SHA: a7981ec
-  HEAD_SHA: 3df7661
-  DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，具有 4 种问题类型
-
-[子代理返回]:
-  优势：干净的架构，真实测试
-  问题：
-    重要：缺少进度指示器
-    次要：报告间隔的魔法数字 (100)
-  评估：可以继续
-
-你：[修复进度指示器]
-[继续到任务 3]
-```
-
-## 与工作流集成
-
-**子代理驱动开发：**
-- 每个任务后审查
-- 在问题复合前捕获它们
-- 在移至下一个任务前修复
-
-**执行计划：**
-- 每批（3 个任务）后审查
-- 获取反馈，应用，继续
-
-**临时开发：**
-- 合并前审查
-- 卡住时审查
-
-## 红旗
-
-**永远不要：**
-- 因为"简单"而跳过审查
-- 忽略关键问题
-- 带着未修复的重要问题继续
-- 与有效的技术反馈争论
-
-**如果审查者错误：**
-- 用技术推理反驳
-- 展示证明它有效的代码/测试
-- 请求澄清
-
-请参阅模板：requesting-code-review/code-reviewer.md

package/skills/special-tools/using-superpowers/SKILL.md

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

package/skills/templates/API-SDD.md

@@ -1,31 +0,0 @@
-【claude code调用标识：API-SDD】【trae调用标识：API-SDD+sdd】【流程场景：1.完整3阶段SDD流程、2.从零开始新项目、3.小型功能迭代】
-
-# API-SDD：[接口模块名称]（skill选项式设计）
-
-## 一、接口清单（skill可选项，支持多选/自定义补充）
-- 选项1：API路径 → 选项：/api/user/login（用户登录）/api/user/info（获取用户信息） → 自定义路径：__________
-- 选项2：请求方法 → 选项：GET/POST/PUT/DELETE → 自定义方法：__________
-- 选项3：功能描述 → 选项：用户登录/获取用户信息/更新用户信息 → 自定义描述：__________
-
-## 二、接口详细定义（skill可选项，支持多选/自定义补充）
-### [API名称]
-- 选项1：路径 → 选项：/api/xxx（示例） → 自定义路径：__________
-- 选项2：方法 → 选项：GET/POST/PUT/DELETE → 自定义方法：__________
-- 选项3：认证方式 → 选项：JWT Token/API Key/无需认证 → 自定义认证：__________
-- 选项4：请求参数 → 选项：参数1（类型：String，必填）/参数2（类型：Number，可选） → 自定义参数：__________
-- 选项5：返回值 → 选项：code（状态码）/data（数据）/message（提示信息） → 自定义返回：__________
-- 选项6：错误码 → 选项：1001（参数错误）/1002（认证失败） → 自定义错误码：__________
-
-## 三、契约版本管理（skill可选项，支持多选/自定义补充）
-- 选项1：版本号 → 选项：v1.0/v2.0/v3.0 → 自定义版本：__________
-- 选项2：版本说明 → 选项：新增接口/修改接口/删除接口 → 自定义说明：__________
-
-## 四、前后端约定（skill可选项，支持多选/自定义补充）
-- 选项1：数据格式 → 选项：JSON/XML/form-data → 自定义格式：__________
-- 选项2：编码方式 → 选项：UTF-8/GBK → 自定义编码：__________
-- 选项3：超时时间 → 选项：5秒/10秒/30秒 → 自定义超时：__________
-
-## trae调用参数说明（仅trae触发时使用）
-- 调用路径：skills/templates/API-SDD.md
-- 必传参数：接口模块名称、API路径、请求方法
-- 可选参数：认证方式、返回值说明补充内容

package/skills/templates/Andrej Karpathy AI/347/274/226/347/240/201/350/247/204/345/210/231/350/220/275/345/234/260SDD.md"

@@ -1,117 +0,0 @@
-【claude code调用标识：Andrej Karpathy AI编码规则落地SDD】【trae调用标识：Andrej Karpathy AI编码规则落地SDD+编码规范】【流程场景：1.完整3阶段SDD流程、3.小型功能迭代】
-
-# Andrej Karpathy AI编码规则落地SDD：[项目名称]
-
-## 一、编码约束
-
-### 1.1 THINK BEFORE YOU CODE
-| 规则 | 说明 | 执行方式 |
-|------|------|---------|
-| 明确需求 | 先理解需求再编码 | 需求评审 |
-| 无范围蔓延 | 严格按需求实现 | 需求文档确认 |
-| 简洁优先 | 优先简洁方案 | 方案评审 |
-
-### 1.2 MAKE SURGICAL CHANGES
-| 规则 | 说明 | 执行方式 |
-|------|------|---------|
-| 最小变更 | 只修改必要代码 | 代码审查 |
-| 不碰无关代码 | 不修改无关代码 | CI检查 |
-| 不重构 | 除非明确要求 | 变更审批 |
-
-### 1.3 KEEP IT SIMPLE
-| 规则 | 说明 | 执行方式 |
-|------|------|---------|
-| 简单优先 | 选择简单方案 | 方案评审 |
-| 避免复杂 | 不使用复杂模式 | 代码审查 |
-| 易理解 | 代码易于理解 | peer review |
-
-### 1.4 VERIFY YOUR WORK
-| 规则 | 说明 | 执行方式 |
-|------|------|---------|
-| 测试验证 | 测试覆盖 | 单元测试 |
-| 边缘案例 | 考虑边界 | 边界测试 |
-| 确认方案 | 不确定就问 | 沟通确认 |
-
-### 1.5 COMMUNICATE CLEARLY
-| 规则 | 说明 | 执行方式 |
-|------|------|---------|
-| 简洁说明 | 简要说明变更 | PR描述 |
-| 说明原因 | 说明变更原因 | 文档更新 |
-| 聚焦任务 | 专注当前任务 | 任务管理 |
-
----
-
-## 二、开源/商用方案对比范式
-
-### 2.1 对比维度
-| 维度 | 开源方案 | 商用方案 |
-|------|---------|---------|
-| 成本 | 免费 | 付费 |
-| 支持 | 社区支持 | 官方支持 |
-| 定制 | 高度定制 | 有限定制 |
-| 稳定性 | 可能不稳定 | 稳定可靠 |
-
-### 2.2 选择原则
-| 场景 | 推荐方案 |
-|------|---------|
-| 核心功能 | 商用方案 |
-| 非核心功能 | 开源方案 |
-| 快速迭代 | 开源方案 |
-| 企业级稳定 | 商用方案 |
-
-### 2.3 决策流程
-```
-需求评估 → 方案调研 → 成本分析 → 风险评估 → 方案选择 → 验证 → 落地
-```
-
----
-
-## 三、禁止自由发挥落地细则
-
-### 3.1 禁止项清单
-| 禁止行为 | 说明 | 后果 |
-|---------|------|------|
-| 自行添加功能 | 未确认需求 | 返工 |
-| 修改无关代码 | 改动超出范围 | 引入bug |
-| 使用未批准库 | 未评审依赖 | 安全风险 |
-| 跳过测试 | 未测试提交 | 质量问题 |
-
-### 3.2 审批流程
-| 步骤 | 内容 | 负责人 |
-|------|------|--------|
-| 1 | 需求确认 | 产品经理 |
-| 2 | 方案评审 | 技术负责人 |
-| 3 | 代码审查 | 技术评审 |
-| 4 | 测试验证 | QA |
-
-### 3.3 变更控制
-| 变更类型 | 审批级别 |
-|---------|---------|
-| 功能新增 | 技术负责人 |
-| Bug修复 | 技术评审 |
-| 文档更新 | 自行审批 |
-| 基础设施 | 架构师 |
-
----
-
-## 四、验收标准
-
-### 4.1 编码规范验证
-- [ ] 代码符合约束规则
-- [ ] 无自由发挥变更
-- [ ] 方案经过评审
-- [ ] 变更经过审批
-
-### 4.2 代码质量验证
-- [ ] 代码简洁易懂
-- [ ] 测试覆盖达标
-- [ ] 无未授权修改
-- [ ] 文档同步更新
-
----
-
-## 五、trae调用参数说明
-- **调用路径**: skills/templates/Andrej Karpathy AI编码规则落地SDD.md
-- **必传参数**: 项目名称
-- **可选参数**: 团队规模、项目类型
-- **流程场景**: 1.完整3阶段SDD流程、3.小型功能迭代