Files
superpowers-zh/skills/requesting-code-review/code-reviewer.md
AI不止语 d3db168041 fix(skills): 子智能体产出非中文 —— 中文路由规则到不了子智能体(#116)
## 根因

报告人说 SDD 产出的 task-N-report / review 是英文。查下来不是漏译:
4 个分派提示词模板本身全是中文,缺的是「输出用什么语言」这一条。

`using-superpowers` 里有这条规则:

    用户用中文交流 → 所有输出使用中文

但它活在**控制者**的上下文里。而 SDD 的设计前提正是子智能体不继承会话
上下文(SKILL.md:「它们绝不应继承你会话的上下文或历史记录」)。所以这条
规则对子智能体从来没有生效过 —— 它只在控制者自己说话时管用。

## 改法

4 个分派提示词的输出格式段各加一行输出语言要求,全部落在 ``` 围栏**之内**
(围栏外的文字子智能体一个字都收不到):

- subagent-driven-development/implementer-prompt.md
- subagent-driven-development/task-reviewer-prompt.md
- subagent-driven-development/re-review-prompt.md
- requesting-code-review/code-reviewer.md

指令刻意划了边界:代码、标识符、命令、file:line、测试输出、提交信息**不翻译**;
ADDRESSED / NOT ADDRESSED、Critical / Important / Minor、⚠️ 保持原样 ——
控制者按这些词做判定,翻译了会打断流程。

四处都是对上游的偏离,各自在文件顶部就地声明(不写进围栏,免得污染提示词)。

## 固化成检查

新增 audit 4d:4 个分派提示词必须有输出语言指令,且必须在围栏内。
围栏外是**静默失效** —— 文件里搜得到「用中文写」,产出照样是英文。
已双向验证:删掉 → FAIL 并指明缺哪个文件;挪到围栏外 → FAIL 并提示移回围栏内。
audit 166 -> 170 pass。

## 未覆盖:task-N-brief.md

简报是 `scripts/task-brief` 从计划文件里机械抽取的,语言完全跟随计划本身,
提示词管不到。报告人的简报是英文,说明他的**计划文件**就是英文,那是另一个
问题。已在 issue 里请他确认计划文件的语言。

门禁:audit.sh 170 pass / 0 warn / 0 fail、verify-release.sh 90 pass / 0 fail
2026-08-11 21:04:05 +08:00

5.1 KiB
Raw Blame History

代码审查员提示模板

派遣代码审查员子代理时使用此模板。

用途: 在工作成果扩散到更多工作之前,对照需求和代码质量标准做一次审查。

superpowers-zh 增量: 「输出格式」里的输出语言一行是本 fork 追加的,上游没有。 子智能体拿到的是全新上下文,using-superpowers 里"用户用中文交流 → 所有输出使用中文" 那条路由只活在控制者的上下文里,永远到不了它。要中文审查报告,就得写进提示词本身。

Task toolgeneral-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。
    在列出问题之前先认可做得好的地方——准确的肯定能让实现者
    更愿意接受后续的反馈。

    如果发现与计划有重大偏差,明确标出,让实现者确认这个偏差
    是不是有意为之。如果问题出在计划本身而不是实现,也要说清楚。

    ## 输出格式

    **用中文写。** 结论、问题描述和理由都用中文。代码、标识符、命令、
    file:line 引用和测试输出照原样保留不要翻译。Critical / Important /
    Minor 这三个严重度词保持原样。

    ### 优点
    [哪些地方做得好?具体一点。]

    ### 问题

    #### 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 问题(帮助文本、
日期校验)很容易修,且不影响核心功能。