mirror of
https://github.com/jnMetaCode/superpowers-zh.git
synced 2026-09-02 22:54:06 +08:00
* chore(skills): 同步上游 P0 漂移修复(hooks-cursor + brainstorm + code-reviewer 引用)
来自质量审计的 3 个 P0 缺陷,全部是上游漂移类("主站有的我们没跟"),逐项 cherry-pick / 翻译同步:
1. hooks/hooks-cursor.json:command 从直接调 unix shell 脚本改回上游的
polyglot wrapper "./hooks/run-hook.cmd session-start"。修复 Windows
Cursor 用户 hook 完全不触发的回归。
2. skills/brainstorming/scripts/{server.cjs,start-server.sh,stop-server.sh}:
完整 cherry-pick 上游 v5.0.6(commit 9e3ed21)的 CONTENT_DIR/STATE_DIR
peer-dir 拆分。修复 visual brainstorming 用户因 SKILL.md 指向新路径但
server.cjs 还用旧 SCREEN_DIR 结构导致卡死。
3. skills/requesting-code-review/SKILL.md:
- 3 处 "superpowers:code-reviewer" 命名子代理引用 → 上游 v5.1.0 改用
"general-purpose" Task + 模板路径的形式
- 占位符从 5 个(含 WHAT_WAS_IMPLEMENTED + DESCRIPTION 冗余)精简到 4 个
(只保留 DESCRIPTION 作为 "Brief summary of what you built"),与上游对齐
- 示例段落里的占位符顺序和命名同步上游
- "执行计划" 集成段:从 "每批(3 个任务)后审查" 改为 "每个任务完成后或
在自然 checkpoint 审查",对齐上游 v5.1.0 的 subagent 节奏调整
验证:3 文件 diff vs upstream 全部 0 行漂移;残留
"superpowers:code-reviewer" 字符串 0 处。
不在本 PR 范围(issue #19 其他批次留独立 PR):
- using-git-worktrees + finishing-a-development-branch v5.1.0 安全修复 → PR #28
- brainstorming + writing-plans 的 review loop 简化 → 后续 PR
- subagent-driven-development 的节奏调整其他部分 → 后续 PR
Refs: 本次全量质量审计(102/106 测试 96.2% 通过率)
* chore(skills): 同步 code-reviewer.md 到上游 v5.1.0 self-contained 版
补漏:本次质量审计第二轮(支持文件结构对比)发现 code-reviewer.md
有真结构漂移——上游 6 个 header,我们 16 个,原因是上游 v5.1.0
(PR #1299)把 reviewer persona + checklist + dispatch 模板整合到
单一 code-reviewer.md 里,self-contained。我们仍是拆分式老版。
这是 issue #19 列出的 "v5.1.0 Code Review 整合" 待办项。同性质上游
同步(主站有的我们没跟),合并到本 PR 的 P0 漂移清单里。
改动:重写 skills/requesting-code-review/code-reviewer.md:
- 上游结构:H1 标题 + 散文 intro + 单一 Task tool 代码块(含完整
prompt 模板)+ Placeholders 说明 + Reviewer returns 说明 + Example
Output 段
- 翻译策略:散文逐句翻译;占位符 {DESCRIPTION}/{PLAN_OR_REQUIREMENTS}/
{BASE_SHA}/{HEAD_SHA} 保留英文;Critical/Important/Minor 等术语保留
- 验证:上游 6 header == 我方 6 header(结构 1:1 对齐)
不在范围:reviewer-prompt.md 其他文件(spec/plan-document-reviewer-prompt.md、
subagent-driven-development/*-prompt.md)的翻译漂移——已确认全是
translation drift(H 数对齐 1:1),无结构漂移,本 PR 不动。
4.5 KiB
4.5 KiB
代码审查员提示模板
派遣代码审查员子代理时使用此模板。
用途: 在工作成果扩散到更多工作之前,对照需求和代码质量标准做一次审查。
Task tool(general-purpose):
description: "审查代码改动"
prompt: |
你是一名资深代码审查员,精通软件架构、设计模式与最佳实践。
你的工作是对照计划或需求审查已完成的工作,在问题扩散之前发现它们。
## 实现内容
{DESCRIPTION}
## 需求 / 计划
{PLAN_OR_REQUIREMENTS}
## 待审查的 Git 范围
**Base:** {BASE_SHA}
**Head:** {HEAD_SHA}
```bash
git diff --stat {BASE_SHA}..{HEAD_SHA}
git diff {BASE_SHA}..{HEAD_SHA}
```
## 检查内容
**计划对齐:**
- 实现是否匹配计划 / 需求?
- 偏差是有道理的改进,还是有问题的偏离?
- 计划中的所有功能都到位了吗?
**代码质量:**
- 关注点分离清晰吗?
- 错误处理到位吗?
- 该有类型安全的地方有吗?
- DRY 但没有过早抽象?
- 边界情况处理了吗?
**架构:**
- 设计决策合理吗?
- 可扩展性和性能合理吗?
- 有没有安全隐患?
- 与周围代码集成是否干净?
**测试:**
- 测试验证的是真实行为,不是 mock?
- 边界情况覆盖了吗?
- 该有集成测试的地方有吗?
- 所有测试都通过吗?
**生产就绪:**
- 如果改了 schema,有迁移策略吗?
- 考虑了向后兼容吗?
- 文档完整吗?
- 没有明显 bug?
## 校准标准
按实际严重程度分类。不是所有问题都是 Critical。
在列出问题之前先认可做得好的地方——准确的肯定能让实现者
更愿意接受后续的反馈。
如果发现与计划有重大偏差,明确标出,让实现者确认这个偏差
是不是有意为之。如果问题出在计划本身而不是实现,也要说清楚。
## 输出格式
### 优点
[哪些地方做得好?具体一点。]
### 问题
#### Critical(必须修复)
[bug、安全问题、数据丢失风险、功能损坏]
#### Important(应该修复)
[架构问题、缺失功能、错误处理不到位、测试漏洞]
#### Minor(锦上添花)
[代码风格、优化机会、文档润色]
每个问题包含:
- File:line 引用
- 哪里有问题
- 为什么重要
- 怎么修(如果不明显)
### 建议
[关于代码质量、架构或流程的改进建议]
### 评估
**可以合并吗?** [是 | 否 | 修完再合]
**理由:** [1-2 句技术评估]
## 关键规则
**要做:**
- 按实际严重程度分类
- 具体(file:line,别含糊)
- 解释为什么这个问题重要
- 认可优点
- 给出明确判断
**不要:**
- 没检查就说"看起来 OK"
- 把小事标成 Critical
- 对没真看过的代码给反馈
- 含糊其辞("改进错误处理")
- 回避给出明确判断
占位符说明:
{DESCRIPTION}—— 已构建内容的简要说明{PLAN_OR_REQUIREMENTS}—— 预期功能(计划文件路径、任务文本或需求){BASE_SHA}—— 起始 commit{HEAD_SHA}—— 结束 commit
审查员返回: 优点、问题(Critical / Important / Minor)、建议、评估
输出示例
### 优点
- 数据库 schema 干净,迁移规范(db.ts:15-42)
- 测试覆盖全面(18 个测试,所有边界情况都覆盖)
- 错误处理有 fallback,做得很好(summarizer.ts:85-92)
### 问题
#### Important
1. **CLI wrapper 缺少帮助文本**
- File: index-conversations:1-31
- 问题:没有 --help flag,用户不会发现 --concurrency
- 修复:加 --help case 含使用示例
2. **缺少日期校验**
- File: search.ts:25-27
- 问题:无效日期会静默返回空结果
- 修复:校验 ISO 格式,抛错并附示例
#### Minor
1. **进度指示**
- File: indexer.ts:130
- 问题:长操作没有 "X of Y" 计数
- 影响:用户不知道要等多久
### 建议
- 加进度上报改善用户体验
- 考虑用配置文件管理排除项目(提升可移植性)
### 评估
**可以合并吗:修完再合**
**理由:** 核心实现扎实,架构和测试都很好。Important 问题(帮助文本、
日期校验)很容易修,且不影响核心功能。