@liangjie559567/ultrapower 5.0.4

package/skills/ultrawork/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: ultrawork
+description: 高吞吐量任务完成的并行执行引擎
+---
+
+<Purpose>
+Ultrawork 是一个并行执行引擎，同时运行多个 agent 处理独立任务。它是一个组件，而非独立的持久化模式——它提供并行性和智能模型路由，但不提供持久化、验证循环或状态管理。
+</Purpose>
+
+<Use_When>
+- 多个独立任务可以同时运行
+- 用户说 "ulw"、"ultrawork" 或想要并行执行
+- 需要同时将工作委托给多个 agent
+- 任务受益于并发执行，但用户将自行管理完成
+</Use_When>
+
+<Do_Not_Use_When>
+- 任务需要有验证的保证完成——改用 `ralph`（ralph 包含 ultrawork）
+- 任务需要完整的自主 pipeline——改用 `autopilot`（autopilot 包含 ralph，ralph 包含 ultrawork）
+- 只有一个顺序任务，没有并行机会——直接委托给 executor agent
+- 用户需要 session 持久化以便恢复——使用 `ralph`，它在 ultrawork 之上添加持久化
+</Do_Not_Use_When>
+
+<Why_This_Exists>
+当任务独立时，顺序执行会浪费时间。Ultrawork 能够同时启动多个 agent，并将每个 agent 路由到正确的模型层级，在控制 token 成本的同时减少总执行时间。它被设计为 ralph 和 autopilot 在其上分层的可组合组件。
+</Why_This_Exists>
+
+<Execution_Policy>
+- 同时启动所有独立 agent 调用——绝不序列化独立工作
+- 委托时始终显式传递 `model` 参数
+- 首次委托前阅读 `docs/shared/agent-tiers.md` 获取 agent 选择指导
+- 对超过约 30 秒的操作（安装、构建、测试）使用 `run_in_background: true`
+- 在前台运行快速命令（git status、文件读取、简单检查）
+</Execution_Policy>
+
+<Steps>
+1. **阅读 agent 参考**：加载 `docs/shared/agent-tiers.md` 进行层级选择
+2. **按独立性分类任务**：识别哪些任务可以并行运行，哪些有依赖关系
+3. **路由到正确层级**：
+   - 简单查找/定义：LOW 层级（Haiku）
+   - 标准实现：MEDIUM 层级（Sonnet）
+   - 复杂分析/重构：HIGH 层级（Opus）
+4. **同时启动独立任务**：一次性启动所有并行安全的任务
+5. **顺序运行依赖任务**：在启动依赖工作前等待先决条件
+6. **后台运行长时间操作**：构建、安装和测试套件使用 `run_in_background: true`
+7. **所有任务完成后验证**（轻量级）：
+   - 构建/类型检查通过
+   - 受影响的测试通过
+   - 未引入新错误
+</Steps>
+
+<Tool_Usage>
+- 使用 `Task(subagent_type="ultrapower:executor-low", model="haiku", ...)` 处理简单变更
+- 使用 `Task(subagent_type="ultrapower:executor", model="sonnet", ...)` 处理标准工作
+- 使用 `Task(subagent_type="ultrapower:executor-high", model="opus", ...)` 处理复杂工作
+- 对包安装、构建和测试套件使用 `run_in_background: true`
+- 对快速状态检查和文件操作使用前台执行
+</Tool_Usage>
+
+<Examples>
+<Good>
+三个独立任务同时启动：
+```
+Task(subagent_type="ultrapower:executor-low", model="haiku", prompt="Add missing type export for Config interface")
+Task(subagent_type="ultrapower:executor", model="sonnet", prompt="Implement the /api/users endpoint with validation")
+Task(subagent_type="ultrapower:executor", model="sonnet", prompt="Add integration tests for the auth middleware")
+```
+好在哪里：独立任务在适当层级，全部同时启动。
+</Good>
+
+<Good>
+正确使用后台执行：
+```
+Task(subagent_type="ultrapower:executor", model="sonnet", prompt="npm install && npm run build", run_in_background=true)
+Task(subagent_type="ultrapower:executor-low", model="haiku", prompt="Update the README with new API endpoints")
+```
+好在哪里：长时间构建在后台运行，同时短任务在前台运行。
+</Good>
+
+<Bad>
+独立工作的顺序执行：
+```
+result1 = Task(executor-low, "Add type export")  # wait...
+result2 = Task(executor, "Implement endpoint")     # wait...
+result3 = Task(executor, "Add tests")              # wait...
+```
+差在哪里：这些任务是独立的。顺序运行浪费时间。
+</Bad>
+
+<Bad>
+错误的层级选择：
+```
+Task(subagent_type="ultrapower:executor-high", model="opus", prompt="Add a missing semicolon")
+```
+差在哪里：Opus 对于微小修复来说是昂贵的过度杀伤。改用带 Haiku 的 executor-low。
+</Bad>
+</Examples>
+
+<Escalation_And_Stop_Conditions>
+- 当 ultrawork 直接调用（而非通过 ralph）时，仅应用轻量级验证——构建通过、测试通过、无新错误
+- 对于完整持久化和全面 architect 验证，建议切换到 `ralph` 模式
+- 如果任务在多次重试后持续失败，报告问题而非无限重试
+- 当任务有不明确的依赖关系或冲突需求时，向用户升级
+</Escalation_And_Stop_Conditions>
+
+<Final_Checklist>
+- [ ] 所有并行任务已完成
+- [ ] 构建/类型检查通过
+- [ ] 受影响的测试通过
+- [ ] 未引入新错误
+</Final_Checklist>
+
+<Advanced>
+## 与其他模式的关系
+
+```
+ralph（持久化包装器）
+ \-- 包含：ultrawork（本 skill）
+     \-- 提供：仅并行执行
+
+autopilot（自主执行）
+ \-- 包含：ralph
+     \-- 包含：ultrawork（本 skill）
+```
+
+Ultrawork 是并行性层。Ralph 添加持久化和验证。Autopilot 添加完整的生命周期 pipeline。
+</Advanced>

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

@@ -0,0 +1,225 @@
+---
+name: using-git-worktrees
+description: 开始需要与当前工作区隔离的功能工作时使用，或在执行实施计划之前使用——通过智能目录选择和安全验证创建隔离的 git worktree
+---
+
+# 使用 Git Worktrees
+
+## 概述
+
+Git worktree 创建共享同一仓库的隔离工作区，允许同时在多个分支上工作而无需切换。
+
+**核心原则：** 系统化目录选择 + 安全验证 = 可靠隔离。
+
+**开始时宣布：** "I'm using the using-git-worktrees skill to set up an isolated workspace."
+
+## 目录选择流程
+
+按以下优先顺序执行：
+
+### 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 中没有偏好：
+
+```
+No worktree directory found. Where should I create worktrees?
+
+1. .worktrees/ (project-local, hidden)
+2. ~/.config/superpowers/worktrees/<project-name>/ (global location)
+
+Which would you prefer?
+```
+
+## 安全验证
+
+### 对于项目本地目录（.worktrees 或 worktrees）
+
+**必须在创建 worktree 前验证目录已被忽略：**
+
+```bash
+# 检查目录是否被忽略（遵守本地、全局和系统 gitignore）
+git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
+```
+
+**如果未被忽略：**
+
+按照"立即修复损坏的东西"规则：
+1. 在 .gitignore 中添加适当行
+2. 提交变更
+3. 继续创建 worktree
+
+**为何关键：** 防止意外将 worktree 内容提交到仓库。
+
+### 对于全局目录（~/.config/superpowers/worktrees）
+
+无需 .gitignore 验证——完全在项目外部。
+
+## 创建步骤
+
+### 1. 检测项目名称
+
+```bash
+project=$(basename "$(git rev-parse --show-toplevel)")
+```
+
+### 2. 创建 Worktree
+
+```bash
+# 确定完整路径
+case $LOCATION in
+  .worktrees|worktrees)
+    path="$LOCATION/$BRANCH_NAME"
+    ;;
+  ~/.config/superpowers/worktrees/*)
+    path="~/.config/superpowers/worktrees/$project/$BRANCH_NAME"
+    ;;
+esac
+
+# 创建带新分支的 worktree
+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. 验证干净基线
+
+运行测试确保 worktree 从干净状态开始：
+
+```bash
+# 示例——使用项目适当的命令
+npm test
+cargo test
+pytest
+go test ./...
+```
+
+**如果测试失败：** 报告失败，询问是否继续或调查。
+
+**如果测试通过：** 报告就绪。
+
+### 5. 报告位置
+
+```
+Worktree ready at <full-path>
+Tests passing (<N> tests, 0 failures)
+Ready to implement <feature-name>
+```
+
+## 快速参考
+
+| 情况 | 行动 |
+|------|------|
+| `.worktrees/` 存在 | 使用它（验证已忽略） |
+| `worktrees/` 存在 | 使用它（验证已忽略） |
+| 两者都存在 | 使用 `.worktrees/` |
+| 两者都不存在 | 检查 CLAUDE.md → 询问用户 |
+| 目录未被忽略 | 添加到 .gitignore + 提交 |
+| 基线测试失败 | 报告失败 + 询问 |
+| 无 package.json/Cargo.toml | 跳过依赖安装 |
+
+## 常见错误
+
+### 跳过忽略验证
+
+- **问题：** Worktree 内容被跟踪，污染 git 状态
+- **修复：** 创建项目本地 worktree 前始终使用 `git check-ignore`
+
+### 假设目录位置
+
+- **问题：** 造成不一致，违反项目约定
+- **修复：** 遵循优先级：现有 > CLAUDE.md > 询问
+
+### 在测试失败时继续
+
+- **问题：** 无法区分新 bug 和预先存在的问题
+- **修复：** 报告失败，获得明确许可后继续
+
+### 硬编码设置命令
+
+- **问题：** 在使用不同工具的项目上失败
+- **修复：** 从项目文件自动检测（package.json 等）
+
+## 示例工作流
+
+```
+You: I'm using the using-git-worktrees skill to set up an isolated workspace.
+
+[Check .worktrees/ - exists]
+[Verify ignored - git check-ignore confirms .worktrees/ is ignored]
+[Create worktree: git worktree add .worktrees/auth -b feature/auth]
+[Run npm install]
+[Run npm test - 47 passing]
+
+Worktree ready at /Users/jesse/myproject/.worktrees/auth
+Tests passing (47 tests, 0 failures)
+Ready to implement auth feature
+```
+
+## 红线
+
+**绝不：**
+- 未验证已忽略就创建 worktree（项目本地）
+- 跳过基线测试验证
+- 未询问就在测试失败时继续
+- 在模糊时假设目录位置
+- 跳过 CLAUDE.md 检查
+
+**始终：**
+- 遵循目录优先级：现有 > CLAUDE.md > 询问
+- 验证项目本地目录已被忽略
+- 自动检测并运行项目设置
+- 验证干净的测试基线
+
+## 集成
+
+**被以下调用：**
+- **brainstorming**（阶段 4）- 设计获批且实施跟进时必需
+- **subagent-driven-development** - 执行任何任务前必需
+- **executing-plans** - 执行任何任务前必需
+- 任何需要隔离工作区的 skill
+
+**配合使用：**
+- **finishing-a-development-branch** - 工作完成后清理时必需
+
+## 路由触发
+
+worktree 创建并验证后调用 `next-step-router`：
+- current_skill: "using-git-worktrees"
+- stage: "worktree_ready"
+- output_summary: worktree 路径、基于哪个分支

package/skills/using-superpowers/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: using-superpowers
+description: 开始任何对话时使用——建立如何查找和使用 skill 的规则，要求在任何响应（包括澄清问题）之前调用 Skill 工具
+---
+
+<EXTREMELY-IMPORTANT>
+如果你认为某个 skill 有哪怕 1% 的可能适用于你正在做的事情，你绝对必须调用该 skill。
+
+如果一个 SKILL 适用于你的任务，你没有选择。你必须使用它。
+
+这不可协商。这不是可选的。你无法通过理性化来逃避这一点。
+</EXTREMELY-IMPORTANT>
+
+## 如何访问 Skill
+
+**在 Claude Code 中：** 使用 `Skill` 工具。当你调用一个 skill 时，其内容会被加载并呈现给你——直接遵循它。永远不要在 skill 文件上使用 Read 工具。
+
+**在其他环境中：** 查看你的平台文档了解如何加载 skill。
+
+# 使用 Skill
+
+## 规则
+
+**在任何响应或行动之前调用相关 skill。** 即使只有 1% 的可能性某个 skill 适用，也意味着你应该调用该 skill 进行检查。如果调用的 skill 结果不适合当前情况，你不需要使用它。
+
+```dot
+digraph skill_flow {
+    "User message received" [shape=doublecircle];
+    "About to EnterPlanMode?" [shape=doublecircle];
+    "Already brainstormed?" [shape=diamond];
+    "Invoke brainstorming skill" [shape=box];
+    "Might any skill apply?" [shape=diamond];
+    "Invoke Skill tool" [shape=box];
+    "Announce: 'Using [skill] to [purpose]'" [shape=box];
+    "Has checklist?" [shape=diamond];
+    "Create TodoWrite todo per item" [shape=box];
+    "Follow skill exactly" [shape=box];
+    "Respond (including clarifications)" [shape=doublecircle];
+
+    "About to EnterPlanMode?" -> "Already brainstormed?";
+    "Already brainstormed?" -> "Invoke brainstorming skill" [label="no"];
+    "Already brainstormed?" -> "Might any skill apply?" [label="yes"];
+    "Invoke brainstorming skill" -> "Might any skill apply?";
+
+    "User message received" -> "Might any skill apply?";
+    "Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
+    "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
+    "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
+    "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
+    "Has checklist?" -> "Create TodoWrite todo per item" [label="yes"];
+    "Has checklist?" -> "Follow skill exactly" [label="no"];
+    "Create TodoWrite todo per item" -> "Follow skill exactly";
+}
+```
+
+## 新功能路由规则
+
+当用户请求涉及**新功能开发**时（非 bug 修复），强制执行以下流程：
+
+1. 调用 explore agent（haiku）→ 理解代码库，写入 notepad（codebase_summary）
+2. 调用 brainstorming skill → 设计对话（brainstorming 会读取 notepad，不重复 explore）
+3. 设计批准后 → next-step-router 推荐下一步
+
+**判断是否为新功能：**
+- 包含"添加"、"新增"、"实现"、"构建"、"创建" → 新功能流程
+- 包含"修复"、"bug"、"错误"、"不工作" → 调试流程（systematic-debugging）
+- 包含"重构"、"优化"、"改进" → 先 explore，再判断
+
+**路由触发（每次消息到达后）：**
+- 新功能 → explore agent → brainstorming
+- 已知 bug → systematic-debugging
+- 不确定 → AskUserQuestion 询问用户意图
+
+## 红旗
+
+这些想法意味着停下——你在自我合理化：
+
+| 想法 | 现实 |
+|------|------|
+| "这只是个简单问题" | 问题也是任务。检查 skill。 |
+| "我需要先了解更多上下文" | Skill 检查在澄清问题之前。 |
+| "让我先探索代码库" | Skill 告诉你如何探索。先检查。 |
+| "我可以快速检查 git/文件" | 文件缺乏对话上下文。检查 skill。 |
+| "让我先收集信息" | Skill 告诉你如何收集信息。 |
+| "这不需要正式的 skill" | 如果 skill 存在，就使用它。 |
+| "我记得这个 skill" | Skill 会演进。阅读当前版本。 |
+| "这不算任务" | 行动 = 任务。检查 skill。 |
+| "这个 skill 太重了" | 简单的事情会变复杂。使用它。 |
+| "我先做这一件事" | 在做任何事之前先检查。 |
+| "这感觉很有效率" | 无纪律的行动浪费时间。Skill 防止这种情况。 |
+| "我知道那是什么意思" | 了解概念 ≠ 使用 skill。调用它。 |
+
+## Skill 优先级
+
+当多个 skill 可能适用时，按此顺序使用：
+
+1. **流程 skill 优先**（brainstorming、debugging）- 这些决定如何处理任务
+2. **实施 skill 其次**（frontend-design、mcp-builder）- 这些指导执行
+
+"让我们构建 X" → 先 brainstorming，然后实施 skill。
+"修复这个 bug" → 先 debugging，然后领域特定 skill。
+
+## Skill 类型
+
+**刚性**（TDD、debugging）：严格遵循。不要偏离纪律。
+
+**灵活**（patterns）：将原则适应上下文。
+
+Skill 本身会告诉你是哪种类型。
+
+## 用户指令
+
+指令说明做什么，而非如何做。"添加 X"或"修复 Y"不意味着跳过工作流。

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

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