sdd-full 4.2.0 → 4.3.1

package/skills/using-git-worktrees/SKILL.md

@@ -1,218 +0,0 @@
----
-name: using-git-worktrees
-description: 当需要开始与当前工作区隔离的功能开发或执行实现计划之前使用——创建具有智能目录选择和安全验证的隔离 git 工作树
----
-
-# 使用 Git 工作树
-
-## 概述
-
-Git 工作树创建共享同一仓库的隔离工作区，允许同时在多个分支上工作而无需切换。
-
-**核心原则：** 系统化的目录选择 + 安全验证 = 可靠的隔离。
-
-**开始时宣布：** "我正在使用 using-git-worktrees 技能来建立一个隔离的工作区。"
-
-## 目录选择流程
-
-按以下优先顺序执行：
-
-### 1. 检查现有目录
-
-```bash
-# 按优先顺序检查
-ls -d .worktrees 2>/dev/null     # 首选（隐藏目录）
-ls -d worktrees 2>/dev/null      # 备选
-```
-
-**如果找到：** 使用该目录。如果两者都存在，`.worktrees` 优先。
-
-### 2. 检查 CLAUDE.md
-
-```bash
-grep -i "worktree.*director" CLAUDE.md 2>/dev/null
-```
-
-**如果指定了偏好：** 直接使用，无需询问。
-
-### 3. 询问用户
-
-如果没有现有目录且 CLAUDE.md 中无偏好设置：
-
-```
-未找到工作树目录。我应该在哪里创建工作树？
-
-1. .worktrees/（项目本地，隐藏目录）
-2. ~/.config/superpowers/worktrees/<project-name>/（全局位置）
-
-你倾向哪个？
-```
-
-## 安全验证
-
-### 项目本地目录（.worktrees 或 worktrees）
-
-**创建工作树前必须验证目录已被忽略：**
-
-```bash
-# 检查目录是否被忽略（遵循本地、全局和系统 gitignore）
-git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
-```
-
-**如果未被忽略：**
-
-根据 Jesse 的规则"立即修复坏掉的东西"：
-1. 在 .gitignore 中添加相应条目
-2. 提交更改
-3. 继续创建工作树
-
-**为什么这很关键：** 防止意外将工作树内容提交到仓库。
-
-### 全局目录（~/.config/superpowers/worktrees）
-
-无需 .gitignore 验证——完全在项目之外。
-
-## 创建步骤
-
-### 1. 检测项目名称
-
-```bash
-project=$(basename "$(git rev-parse --show-toplevel)")
-```
-
-### 2. 创建工作树
-
-```bash
-# 确定完整路径
-case $LOCATION in
-  .worktrees|worktrees)
-    path="$LOCATION/$BRANCH_NAME"
-    ;;
-  ~/.config/superpowers/worktrees/*)
-    path="~/.config/superpowers/worktrees/$project/$BRANCH_NAME"
-    ;;
-esac
-
-# 创建带有新分支的工作树
-git worktree add "$path" -b "$BRANCH_NAME"
-cd "$path"
-```
-
-### 3. 运行项目设置
-
-自动检测并运行相应的设置命令：
-
-```bash
-# Node.js
-if [ -f package.json ]; then npm install; fi
-
-# Rust
-if [ -f Cargo.toml ]; then cargo build; fi
-
-# Python
-if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
-if [ -f pyproject.toml ]; then poetry install; fi
-
-# Go
-if [ -f go.mod ]; then go mod download; fi
-```
-
-### 4. 验证基线正常
-
-运行测试确保工作树初始状态干净：
-
-```bash
-# 示例 - 使用项目对应的命令
-npm test
-cargo test
-pytest
-go test ./...
-```
-
-**如果测试失败：** 报告失败情况，询问是否继续或排查。
-
-**如果测试通过：** 报告就绪。
-
-### 5. 报告位置
-
-```
-工作树已就绪：<full-path>
-测试通过（<N> 个测试，0 个失败）
-准备实现 <feature-name>
-```
-
-## 快速参考
-
-| 情况 | 操作 |
-|------|------|
-| `.worktrees/` 存在 | 使用它（验证已忽略） |
-| `worktrees/` 存在 | 使用它（验证已忽略） |
-| 两者都存在 | 使用 `.worktrees/` |
-| 都不存在 | 检查 CLAUDE.md → 询问用户 |
-| 目录未被忽略 | 添加到 .gitignore + 提交 |
-| 基线测试失败 | 报告失败 + 询问 |
-| 无 package.json/Cargo.toml | 跳过依赖安装 |
-
-## 常见错误
-
-### 跳过忽略验证
-
-- **问题：** 工作树内容被跟踪，污染 git status
-- **修复：** 创建项目本地工作树前始终使用 `git check-ignore`
-
-### 假设目录位置
-
-- **问题：** 造成不一致，违反项目约定
-- **修复：** 遵循优先级：现有目录 > CLAUDE.md > 询问
-
-### 带着失败的测试继续
-
-- **问题：** 无法区分新 bug 和已有问题
-- **修复：** 报告失败，获得明确许可后再继续
-
-### 硬编码设置命令
-
-- **问题：** 在使用不同工具的项目上会出错
-- **修复：** 从项目文件自动检测（package.json 等）
-
-## 示例工作流
-
-```
-你：我正在使用 using-git-worktrees 技能来建立一个隔离的工作区。
-
-[检查 .worktrees/ - 存在]
-[验证已忽略 - git check-ignore 确认 .worktrees/ 已被忽略]
-[创建工作树：git worktree add .worktrees/auth -b feature/auth]
-[运行 npm install]
-[运行 npm test - 47 个通过]
-
-工作树已就绪：/Users/jesse/myproject/.worktrees/auth
-测试通过（47 个测试，0 个失败）
-准备实现 auth 功能
-```
-
-## 红线
-
-**绝不：**
-- 创建项目本地工作树时不验证是否已忽略
-- 跳过基线测试验证
-- 不询问就带着失败的测试继续
-- 在有歧义时假设目录位置
-- 跳过 CLAUDE.md 检查
-
-**始终：**
-- 遵循目录优先级：现有目录 > CLAUDE.md > 询问
-- 对项目本地目录验证是否已忽略
-- 自动检测并运行项目设置
-- 验证测试基线干净
-
-## 集成
-
-**被以下技能调用：**
-- **brainstorming**（阶段 4）- 设计通过且需要实现时必需
-- **subagent-driven-development** - 执行任何任务前必需
-- **executing-plans** - 执行任何任务前必需
-- 任何需要隔离工作区的技能
-
-**配合使用：**
-- **finishing-a-development-branch** - 工作完成后清理时必需

package/skills/using-superpowers/SKILL.md

@@ -1,134 +0,0 @@
----
-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];
-    "即将进入 EnterPlanMode？" [shape=doublecircle];
-    "已经头脑风暴过？" [shape=diamond];
-    "调用头脑风暴技能" [shape=box];
-    "可能有技能适用？" [shape=diamond];
-    "调用 Skill 工具" [shape=box];
-    "宣布：'使用 [技能] 来 [目的]'" [shape=box];
-    "有检查清单？" [shape=diamond];
-    "为每个条目创建 TodoWrite 待办" [shape=box];
-    "严格遵循技能" [shape=box];
-    "响应（包括澄清）" [shape=doublecircle];
-
-    "即将进入 EnterPlanMode？" -> "已经头脑风暴过？";
-    "已经头脑风暴过？" -> "调用头脑风暴技能" [label="否"];
-    "已经头脑风暴过？" -> "可能有技能适用？" [label="是"];
-    "调用头脑风暴技能" -> "可能有技能适用？";
-
-    "收到用户消息" -> "可能有技能适用？";
-    "可能有技能适用？" -> "调用 Skill 工具" [label="是，哪怕只有 1%"];
-    "可能有技能适用？" -> "响应（包括澄清）" [label="确定不适用"];
-    "调用 Skill 工具" -> "宣布：'使用 [技能] 来 [目的]'";
-    "宣布：'使用 [技能] 来 [目的]'" -> "有检查清单？";
-    "有检查清单？" -> "为每个条目创建 TodoWrite 待办" [label="是"];
-    "有检查清单？" -> "严格遵循技能" [label="否"];
-    "为每个条目创建 TodoWrite 待办" -> "严格遵循技能";
-}
-```
-
-## 红线
-
-这些想法意味着停下——你在合理化：
-
-| 想法 | 现实 |
-|------|------|
-| "这只是一个简单的问题" | 问题就是任务。检查技能。 |
-| "我需要先了解更多上下文" | 技能检查在澄清性问题之前。 |
-| "让我先探索一下代码库" | 技能告诉你如何探索。先检查。 |
-| "我可以快速查一下 git/文件" | 文件缺少对话上下文。检查技能。 |
-| "让我先收集信息" | 技能告诉你如何收集信息。 |
-| "这不需要正式的技能" | 如果技能存在，就使用它。 |
-| "我记得这个技能" | 技能会迭代更新。阅读当前版本。 |
-| "这不算一个任务" | 行动 = 任务。检查技能。 |
-| "技能太小题大做了" | 简单的事会变复杂。使用它。 |
-| "让我先做这一件事" | 在做任何事之前先检查。 |
-| "这样做感觉很高效" | 无纪律的行动浪费时间。技能防止这一点。 |
-| "我知道那是什么意思" | 知道概念 ≠ 使用技能。调用它。 |
-
-## 技能优先级
-
-当多个技能可能适用时，使用此顺序：
-
-1. **流程技能优先**（头脑风暴、调试）- 这些决定如何处理任务
-2. **实现技能其次**（前端设计、mcp-builder）- 这些指导执行
-
-"让我们构建 X" → 先头脑风暴，再使用实现技能。
-"修复这个 bug" → 先调试，再使用领域特定技能。
-
-## 中国特色技能路由
-
-当检测到以下场景时，**必须**优先调用对应的中国特色技能：
-
-| 场景 | 调用技能 |
-|------|---------|
-| 代码审查且团队使用中文沟通 | **superpowers:chinese-code-review** |
-| 使用 Gitee/Coding/极狐 GitLab | **superpowers:chinese-git-workflow** |
-| 编写中文技术文档或 README | **superpowers:chinese-documentation** |
-| 编写 git commit message（中文项目） | **superpowers:chinese-commit-conventions** |
-| 构建 MCP 服务器/工具 | **superpowers:mcp-builder** |
-
-**判断依据：**
-- 项目中有中文注释、中文 README、或 .gitee 目录 → 启用中文系列技能
-- commit 历史中有中文 → 使用中文提交规范
-- 用户用中文交流 → 所有输出使用中文，优先考虑中国特色技能
-
-中国特色技能与翻译技能**叠加使用**，不互斥。例如：做代码审查时，同时使用 requesting-code-review（流程）+ chinese-code-review（风格）。
-
-## 技能类型
-
-**刚性的**（TDD、调试）：严格遵循。不要偏离纪律。
-
-**灵活的**（模式）：根据上下文调整原则。
-
-技能本身会告诉你它属于哪种。
-
-## 用户指令
-
-指令说明做什么，而非怎么做。"添加 X"或"修复 Y"不意味着跳过工作流。

package/skills/using-superpowers/references/codex-tools.md

@@ -1,25 +0,0 @@
-# Codex 工具映射
-
-Skills 使用 Claude Code 的工具名称。在 Codex 中遇到这些名称时，请使用对应的平台等价工具：
-
-| Skill 中的引用 | Codex 等价工具 |
-|---------------|---------------|
-| `Task` 工具（派遣子 agent） | `spawn_agent` |
-| 多个 `Task` 调用（并行） | 多个 `spawn_agent` 调用 |
-| Task 返回结果 | `wait` |
-| Task 自动完成 | `close_agent` 释放槽位 |
-| `TodoWrite`（任务跟踪） | `update_plan` |
-| `Skill` 工具（调用 skill） | Skills 原生加载——直接按说明操作 |
-| `Read`、`Write`、`Edit`（文件） | 使用原生文件工具 |
-| `Bash`（执行命令） | 使用原生 shell 工具 |
-
-## 子 Agent 派遣需要多 Agent 支持
-
-在 Codex 配置文件（`~/.codex/config.toml`）中添加：
-
-```toml
-[features]
-multi_agent = true
-```
-
-启用后可使用 `spawn_agent`、`wait` 和 `close_agent`，支持 `dispatching-parallel-agents` 和 `subagent-driven-development` 等 skills。

package/skills/using-superpowers/references/gemini-tools.md

@@ -1,33 +0,0 @@
-# Gemini CLI 工具映射
-
-Skills 使用 Claude Code 的工具名称。在 Gemini CLI 中遇到这些名称时，请使用对应的平台等价工具：
-
-| Skill 中的引用 | Gemini CLI 等价工具 |
-|---------------|-------------------|
-| `Read`（读取文件） | `read_file` |
-| `Write`（创建文件） | `write_file` |
-| `Edit`（编辑文件） | `replace` |
-| `Bash`（执行命令） | `run_shell_command` |
-| `Grep`（搜索文件内容） | `grep_search` |
-| `Glob`（按名称搜索文件） | `glob` |
-| `TodoWrite`（任务跟踪） | `write_todos` |
-| `Skill` 工具（调用 skill） | `activate_skill` |
-| `WebSearch` | `google_web_search` |
-| `WebFetch` | `web_fetch` |
-| `Task` 工具（派遣子 agent） | 无等价工具——Gemini CLI 不支持子 agent |
-
-## 不支持子 Agent
-
-Gemini CLI 没有 Claude Code `Task` 工具的等价物。依赖子 agent 派遣的 skills（`subagent-driven-development`、`dispatching-parallel-agents`）将退化为通过 `executing-plans` 进行单会话执行。
-
-## Gemini CLI 额外工具
-
-以下工具在 Gemini CLI 中可用，但 Claude Code 中没有对应工具：
-
-| 工具 | 用途 |
-|------|------|
-| `list_directory` | 列出文件和子目录 |
-| `save_memory` | 将信息持久化到 GEMINI.md，跨会话保留 |
-| `ask_user` | 向用户请求结构化输入 |
-| `tracker_create_task` | 丰富的任务管理（创建、更新、列表、可视化） |
-| `enter_plan_mode` / `exit_plan_mode` | 切换到只读研究模式，在修改前先调研 |

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

@@ -1,139 +0,0 @@
----
-name: verification-before-completion
-description: 在宣称工作完成、已修复或测试通过之前使用，在提交或创建 PR 之前——必须运行验证命令并确认输出后才能声称成功；始终用证据支撑断言
----
-
-# 完成前验证
-
-## 概述
-
-在没有验证的情况下宣称工作完成，这不是高效，而是不诚实。
-
-**核心原则：** 始终用证据支撑结论。
-
-**对这条规则敷衍了事，就等于违背了它的精神。**
-
-## 铁律
-
-```
-没有新鲜的验证证据，不许宣称完成
-```
-
-如果你在这条消息中没有运行验证命令，就不能声称测试通过。
-
-## 门控函数
-
-```
-在宣称任何状态或表达满意之前：
-
-1. 确定：什么命令能证明这个结论？
-2. 运行：执行完整命令（重新运行，完整执行）
-3. 阅读：完整输出，检查退出码，统计失败数
-4. 验证：输出是否支持这个结论？
-   - 如果否：用证据说明实际状态
-   - 如果是：带证据陈述结论
-5. 只有这时：才能做出结论
-
-跳过任何一步 = 说谎，不是验证
-```
-
-## 常见失败模式
-
-| 结论 | 需要 | 不够格 |
-|------|------|--------|
-| 测试通过 | 测试命令输出：0 failures | 之前的运行结果、"应该会通过" |
-| Linter 无报错 | Linter 输出：0 errors | 部分检查、推断 |
-| 构建成功 | 构建命令：exit 0 | linter 通过、日志看起来没问题 |
-| Bug 已修复 | 测试原始症状：通过 | 代码改了，假设已修复 |
-| 回归测试有效 | 红-绿循环已验证 | 测试只通过了一次 |
-| 代理已完成 | VCS diff 显示变更 | 代理报告"成功" |
-| 需求已满足 | 逐项核对清单 | 测试通过 |
-
-## 红线——停下来
-
-- 使用"应该"、"大概"、"似乎"
-- 验证前就表达满意（"太好了！"、"完美！"、"搞定！"等）
-- 即将提交/推送/创建 PR 却没有验证
-- 信任代理的成功报告
-- 依赖部分验证
-- 想着"就这一次"
-- 累了想赶紧收工
-- **任何暗示成功但实际未运行验证的措辞**
-
-## 防止合理化
-
-| 借口 | 现实 |
-|------|------|
-| "应该能行了" | 运行验证命令 |
-| "我有信心" | 信心 ≠ 证据 |
-| "就这一次" | 没有例外 |
-| "Linter 通过了" | Linter ≠ 编译器 |
-| "代理说成功了" | 独立验证 |
-| "我累了" | 疲劳 ≠ 借口 |
-| "部分检查就够了" | 部分检查什么也证明不了 |
-| "换个说法这条规则就不适用了" | 精神大于字面 |
-
-## 关键模式
-
-**测试：**
-```
-✅ [运行测试命令] [看到：34/34 pass] "全部测试通过"
-❌ "应该能通过了" / "看起来对了"
-```
-
-**回归测试（TDD 红-绿）：**
-```
-✅ 编写 → 运行（通过）→ 回退修复 → 运行（必须失败）→ 恢复 → 运行（通过）
-❌ "我写了回归测试"（没有经过红-绿验证）
-```
-
-**构建：**
-```
-✅ [运行构建] [看到：exit 0] "构建通过"
-❌ "Linter 通过了"（linter 不检查编译）
-```
-
-**需求：**
-```
-✅ 重读计划 → 创建核对清单 → 逐项验证 → 报告缺口或完成
-❌ "测试通过了，阶段完成"
-```
-
-**代理委派：**
-```
-✅ 代理报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态
-❌ 信任代理报告
-```
-
-## 为什么这很重要
-
-来自 24 次失败记录：
-- 搭档说"我不信你"——信任被破坏
-- 未定义的函数被交付——会直接崩溃
-- 遗漏需求被交付——功能不完整
-- 虚假完成浪费的时间 → 返工 → 重做
-- 违反原则："诚实是核心价值。如果你说谎，就会被替换。"
-
-## 何时使用
-
-**以下情况之前必须使用：**
-- 任何形式的成功/完成声明
-- 任何满意的表达
-- 任何关于工作状态的正面陈述
-- 提交、创建 PR、标记任务完成
-- 进入下一个任务
-- 委派给代理
-
-**本规则适用于：**
-- 准确措辞
-- 同义词和换一种说法
-- 暗示成功
-- 任何传达完成/正确性的沟通
-
-## 底线
-
-**验证没有捷径。**
-
-运行命令。阅读输出。然后才能宣称结果。
-
-这没有商量余地。