specops 0.2.2 → 0.2.4

package/.opencode/skills/finishing-a-development-branch/SKILL.md

@@ -0,0 +1,222 @@
+---
+name: finishing-a-development-branch
+description: 实现完成、所有测试通过后使用，指导如何集成工作，提供合并、PR 或清理的结构化选项
+---
+
+# 完成开发分支
+
+## 概述
+
+指导开发工作的收尾，提供清晰的选项并处理所选的工作流。
+
+**核心原则：** 验证测试 → 运行验收 → 展示选项 → 执行选择 → 清理。
+
+**开始时宣布：** "我正在使用 finishing-a-development-branch skill 来完成这项工作。"
+
+## 流程
+
+### 步骤 1：验证测试
+
+**展示选项之前，先验证测试通过：**
+
+```bash
+# 运行项目的测试套件
+npm test / cargo test / pytest / go test ./...
+```
+
+**如果测试失败：**
+```
+测试失败（<N> 个失败）。完成前必须修复：
+
+[展示失败信息]
+
+测试通过前无法进行合并/PR。
+```
+
+停下。不要进入步骤 2。
+
+**如果测试通过：** 继续步骤 2。
+
+### 步骤 1.5：运行 specops 验收
+
+**测试通过后，运行 specops 验收运行器确认全部通过：**
+
+```bash
+# 运行 specops 验收检查
+specops verify
+```
+
+**如果验收失败：**
+```
+验收检查未通过（<N> 项失败）。完成前必须修复：
+
+[展示失败项]
+
+验收全部通过前无法进行合并/PR。
+```
+
+停下。不要进入步骤 2。
+
+**如果验收通过：** 继续步骤 2。
+
+### 步骤 2：确定基准分支
+
+```bash
+# 尝试常见的基准分支
+git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
+```
+
+或者询问："这个分支是从 main 分出来的，对吗？"
+
+### 步骤 3：展示选项
+
+展示恰好这 4 个选项：
+
+```
+实现完成。你想怎么做？
+
+1. 本地合并回 <基准分支>
+2. 推送并创建 Pull Request
+3. 保持分支现状（我稍后处理）
+4. 丢弃这项工作
+
+选哪个？
+```
+
+**不要添加解释** - 保持选项简洁。
+
+### 步骤 4：执行选择
+
+#### 选项 1：本地合并
+
+```bash
+# 切换到基准分支
+git checkout <基准分支>
+
+# 拉取最新
+git pull
+
+# 合并功能分支
+git merge <功能分支>
+
+# 在合并结果上验证测试
+<测试命令>
+
+# 如果测试通过
+git branch -d <功能分支>
+```
+
+然后：清理工作树（步骤 5）
+
+#### 选项 2：推送并创建 PR
+
+```bash
+# 推送分支
+git push -u origin <功能分支>
+
+# 创建 PR
+gh pr create --title "<标题>" --body "$(cat <<'EOF'
+## 摘要
+<2-3 条变更要点>
+
+## 测试计划
+- [ ] <验证步骤>
+EOF
+)"
+```
+
+然后：清理工作树（步骤 5）
+
+#### 选项 3：保持现状
+
+报告："保持分支 <名称>。工作树保留在 <路径>。"
+
+**不要清理工作树。**
+
+#### 选项 4：丢弃
+
+**先确认：**
+```
+这将永久删除：
+- 分支 <名称>
+- 所有提交：<提交列表>
+- 工作树 <路径>
+
+输入 'discard' 确认。
+```
+
+等待精确确认。
+
+确认后：
+```bash
+git checkout <基准分支>
+git branch -D <功能分支>
+```
+
+然后：清理工作树（步骤 5）
+
+### 步骤 5：清理工作树
+
+**选项 1、2、4：**
+
+检查是否在工作树中：
+```bash
+git worktree list | grep $(git branch --show-current)
+```
+
+如果是：
+```bash
+git worktree remove <工作树路径>
+```
+
+**选项 3：** 保留工作树。
+
+## 快速参考
+
+| 选项 | 合并 | 推送 | 保留工作树 | 清理分支 |
+|------|------|------|------------|----------|
+| 1. 本地合并 | ✓ | - | - | ✓ |
+| 2. 创建 PR | - | ✓ | ✓ | - |
+| 3. 保持现状 | - | - | ✓ | - |
+| 4. 丢弃 | - | - | - | ✓（强制） |
+
+## 常见错误
+
+**跳过测试验证**
+- **问题：** 合并了坏代码，创建了失败的 PR
+- **修正：** 展示选项前始终验证测试
+
+**开放式提问**
+- **问题：** "接下来该做什么？" → 模糊
+- **修正：** 展示恰好 4 个结构化选项
+
+**自动清理工作树**
+- **问题：** 可能还需要时移除了工作树（选项 2、3）
+- **修正：** 只在选项 1 和 4 时清理
+
+**丢弃不确认**
+- **问题：** 意外删除工作
+- **修正：** 要求输入 "discard" 确认
+
+## 红线
+
+**绝对不要：**
+- 测试失败时继续
+- 不验证合并结果的测试就合并
+- 不确认就删除工作
+- 未经明确要求就 force-push
+
+**始终：**
+- 展示选项前验证测试
+- 展示恰好 4 个选项
+- 选项 4 要求输入确认
+- 只在选项 1 和 4 时清理工作树
+
+## 集成
+
+**被调用方：**
+- **specops:subagent-driven-development**（步骤 7）- 所有任务完成后
+- **specops:executing-plans**（步骤 5）- 所有批次完成后
+
+**配合使用：**
+- **specops:using-git-worktrees** - 清理该 skill 创建的工作树

package/.opencode/skills/receiving-code-review/SKILL.md

@@ -0,0 +1,213 @@
+---
+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（未使用的功能）
+- 对这个技术栈来说技术上不正确
+- 存在遗留/兼容性原因
+- 与你的人类搭档的架构决策冲突
+
+**如何反驳：**
+- 用技术理由，不要防御性
+- 提出具体问题
+- 引用可用的测试/代码
+- 如果涉及架构，让你的人类搭档参与
+
+**如果不方便大声反驳的信号：** "Strange things are afoot at the Circle K"
+
+## 确认正确的反馈
+
+当反馈确实正确时：
+```
+✅ "已修复。[简要描述改了什么]"
+✅ "好发现 - [具体问题]。已在 [位置] 修复。"
+✅ [直接修复并在代码中展示]
+
+❌ "你说得太对了！"
+❌ "好观点！"
+❌ "感谢指出！"
+❌ "感谢 [任何东西]"
+❌ 任何感谢表达
+```
+
+**为什么不感谢：** 行动说明一切。直接修复就好。代码本身就表明你听到了反馈。
+
+**如果你发现自己要写"感谢"：** 删掉它。改为描述修复内容。
+
+## 优雅地纠正你的反驳
+
+如果你反驳了但发现自己错了：
+```
+✅ "你是对的 - 我检查了 [X]，它确实 [Y]。现在实现。"
+✅ "验证了这一点，你是正确的。我最初的理解有误，因为 [原因]。修复中。"
+
+❌ 长篇道歉
+❌ 为什么反驳做辩护
+❌ 过度解释
+```
+
+陈述事实，继续前进。
+
+## 常见错误
+
+| 错误 | 修正 |
+|------|------|
+| 表演性认同 | 复述需求或直接行动 |
+| 盲目实现 | 先对照代码库验证 |
+| 批量处理不测试 | 一次一项，每项测试 |
+| 假设审查者正确 | 检查是否会破坏东西 |
+| 回避反驳 | 技术正确性 > 舒适 |
+| 部分实现 | 先澄清所有项目 |
+| 无法验证就继续 | 说明限制，请求指导 |
+
+## 真实案例
+
+**表演性认同（错误）：**
+```
+审查者："移除遗留代码"
+❌ "你说得太对了！让我移除..."
+```
+
+**技术验证（正确）：**
+```
+审查者："移除遗留代码"
+✅ "检查中... 构建目标是 10.15+，这个 API 需要 13+。需要遗留代码来向后兼容。当前实现的 bundle ID 有误 - 修复它还是放弃 pre-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 评论。
+
+## 底线
+
+**外部反馈 = 需要评估的建议，不是必须执行的命令。**
+
+验证。质疑。然后实现。
+
+不要表演性认同。始终保持技术严谨。