lywsvip/superpowers-zh
1
0
Fork 0
mirror of https://github.com/jnMetaCode/superpowers-zh.git synced 2026-09-03 07:23:56 +08:00
Code Issues Packages Projects Releases Wiki Activity
190 Commits 34 Branches 46 Tags
b01a91c2674fcfaaded85cfa67ff5b84803a6259
Commit Graph

22 Commits

Author SHA1 Message Date
AI不止语
b01a91c267 fix(installer): Qwen Code 缺 bootstrap（skill 是死重）+ 文档把产品搞混了 
核查第五款。路径本身是对的 —— 这是查过的几款里第一个没装错地方的。但另有
两个问题。

## ① 我们把产品搞混了

docs 标题写「Qwen Code (通义灵码)」，链接指向 tongyi.aliyun.com；README 里
把它标成「IDE 插件」。

实际：Qwen Code 是 QwenLM/qwen-code 这个**命令行工具**（Gemini CLI 的 fork），
跑在终端里。通义灵码是阿里的 IDE 插件，**是另一个产品**，配置路径完全不同。
照着我们的文档去配通义灵码是配不通的。

这跟 #119 的 Qoder 表「没标产品面」是同一类错误：把两个不同产品面的东西
混成一份说明。docs 与简繁 README 一并更正（类型也从「IDE 插件」改回 CLI）。

## ② 只装 skills、不写 bootstrap —— skill 是死重

实测装完项目里只有 .qwen/skills/，一个引导文件都没写。而 Claude 写 CLAUDE.md、
Gemini 写 GEMINI.md，Qwen Code 的对应物 QWEN.md 我们完全没用。

按上游的原则：没有 bootstrap，skill 就是死重 —— 文件在磁盘上但很少被调用。

两套机制都查了官方文档：
- skills：qwenlm.github.io/.../features/skills/ 确认 .qwen/skills/ 与
  ~/.qwen/skills/ 自动发现，无需配置
- QWEN.md：分层记忆的默认上下文文件就是 QWEN.md，从 cwd 逐层向上到项目根、
  以及全局 ~/.qwen/ 都会被扫描并拼接（可用 contextFileName 改名）

已补 generateQwenBootstrap，复用 Gemini 那套结构：项目级写 ./QWEN.md，全局写
~/.qwen/QWEN.md；已有文件则用哨兵注释追加而不覆盖。

顺带补上全局卸载的缺口：qwen 在 GLOBAL_OK 里，--global 会写 ~/.qwen/QWEN.md，
原来 GLOBAL_BOOTSTRAP_CLEAN_SECTION 只有 .claude/CLAUDE.md，装卸一轮会在用户
主目录留残留。

## 验证

- 项目级：已有 QWEN.md 时追加，卸载后逐字节恢复用户内容
- 全局：写 ~/.qwen/QWEN.md，卸载后 HOME 下残留 0 个文件
- verify-release 新增 Qwen 段（bootstrap 写入 / 不覆盖用户内容 / 指向
  .qwen/skills/ / 卸载切除干净 / 不误删用户内容 / 全局零残留），101 -> 108 pass
- audit.sh 166 pass / 0 warn / 0 fail

## 范围

installer、docs、简繁 README、verify-release 均为 fork 自有，零上游偏离。
 2026-08-12 19:17:26 +08:00
AI不止语
ad32b2546b fix(installer): Kiro 把 335 KB 塞进每一轮对话 —— 改为索引式（Aider 的反面） 
继 Aider 之后核查 Kiro。这次的错跟 Aider 正好相反：不是不加载，是**全部加载、
每一轮都加载**。

## 问题

Kiro 官方文档（kiro.dev/docs/steering）明确：`.kiro/steering/` 下的文件默认
`inclusion: always`，"loaded into every Kiro interaction automatically"。

而我们把 20 个 skill 的正文整个装进了 `.kiro/steering/`。实测：

    47 个 md 文件 / 342914 字节 ≈ 335 KB —— 每轮对话全量进上下文

这跟我们当初给 Cline / Kilo Code 修的是同一个问题（那次是 182 KB），解法当时
就设计好了，只是没意识到 Kiro 的 steering 也是常驻性质。

## 改法：照搬 Cline / Kilo 的索引式

- skills 正文改装 `.kiro/skills/`（不被自动加载）
- `.kiro/steering/superpowers-zh.md` 只放索引：核心规则 + 20 个 skill 的触发
  条件表，带 `inclusion: always`

335 KB -> 4.4 KB，76 倍。

## 升级路径（这条最要紧）

老用户通常直接重装而不会先卸载。不清旧布局的话新旧两份并存，335 KB 一点没减 ——
那这次修了等于没修。所以安装时先清 `.kiro/steering/` 下与我们 skill 同名的目录，
并打印清理了几个；卸载同样处理（LEGACY_SKILL_DIRS）。

只删同名目录，**用户自己写的 steering 文件不动** —— 已实测。

## 文档里两个编造的 frontmatter 键

docs/README.kiro.md 写着加载模式是 `alwaysApply: true` 和 `globs: "*.ts"` ——
这两个键 Kiro 文档里**根本不存在**，是 Cursor / Trae 的约定被误写成了 Kiro 的。
Kiro 实际用 inclusion / fileMatchPattern。已按官方文档重写整篇，并补上默认值
就是 always 这一条（这正是 335 KB 的成因）。

## 回归守卫

verify-release.sh 新增 Kiro 段：索引存在、带 inclusion: always、20 行表、指向
.kiro/skills/，以及两条硬守卫 ——
  - steering 下只能有 1 个 md
  - steering 常驻总字节 < 20 KB
外加升级路径断言：旧布局必须被清、用户自己的文件必须保留。
双向验证过：模拟退回旧布局后两条断言都会失败。

verify-release 93 -> 101 pass。

## 验证

- 全新装：steering 1 个文件 4437 字节，.kiro/skills/ 下 20 个 skill
- 从旧布局升级：342971 -> 4494 字节，清理 20 个旧目录，用户文件保留
- 卸载：零残留，用户 steering 文件逐字节保留
- audit.sh 166 pass / 0 warn / 0 fail、verify-release.sh 101 pass / 0 fail

## 范围

installer、docs、README 简繁、verify-release 均为 fork 自有，零上游偏离。
 2026-08-12 18:58:54 +08:00
AI不止语
be6dc8c252 fix(installer): Aider 支持有两个都会导致「装了不生效」的错（#45 同类） 
顺着 #45（Hermes 装错目录）和 #119（Qoder 映射表是编的）这条线，系统查了
我们自己那层工具支持。Aider 查出两处，都实测坐实，都是「装完看着成功、
实际不生效」。

## ① 真实 Aider 项目从来没被自动检测到过

detect 写的是 '.aider'，即要求存在一个 `.aider/` 目录 —— 而 **Aider 不创建
这个目录**。它在项目根留下的是 `.aider.` 前缀的产物：

  .aider.conf.yml / .aider.chat.history.md / .aider.tags.cache.v3/

实测：造一个含这三样的目录跑 `npx superpowers-zh`，输出「未检测到任何已知
AI 编程工具」。而 docs/README.aider.md 一直写着「会自动检测 .aider.conf.yml
文件」—— 文档描述的是意图，代码做的是另一回事。

改为认这四个标记（保留 '.aider' 兼容）。

## ② CONVENTIONS.md 不会被 Aider 自动加载

代码注释和文档都写着「Aider 原生支持自动加载此文件」。官方文档
（aider.chat/docs/usage/conventions.html）说的是反的：必须
`aider --read CONVENTIONS.md`，或在 .aider.conf.yml 里写 `read: CONVENTIONS.md`。

最糟的是 docs 的「Skills 未生效」排障第 3 条写着「Aider 会自动读取
CONVENTIONS.md，无需额外配置」—— 用户卡住时来查文档，看到的正好是让他
继续卡住的那句。

改法照搬 #45 的做法：装完打印可直接用的两种激活方式，**不替用户改
.aider.conf.yml**（那是他们的文件）。docs 开头重写，把「还需一步」放最前面，
并注明 v1.7.9 及更早的说法是错的。

## 测试的盲区

verify-release.sh 的检测测试是 `mkdir .aider` 然后断言认出 Aider —— 拿代码
测代码，真实标记一个都没测。已补三个真实标记；顺带修了 case 分支：.yml 也
要按文件建，用目录冒充文件等于测了个假场景。

verify-release 90 -> 93 pass。

## 验证

- 只有 .aider.conf.yml 的目录：正确识别为 Aider，并打印激活提示
- 已有自写 CONVENTIONS.md：追加而不覆盖；卸载后逐字节恢复原内容
- 卸载：.aider 下残留 0 项
- audit.sh 166 pass / 0 warn / 0 fail、verify-release.sh 93 pass / 0 fail

## 范围

bin/superpowers-zh.js、docs/README.aider.md、scripts/verify-release.sh 均为
fork 自有（上游没有 installer 与 docs），零上游偏离。
 2026-08-12 18:03:28 +08:00
AI不止语
0ffaf5bced Revert "fix(skills): 子智能体产出非中文 —— 中文路由规则到不了子智能体（#116）" 
回滚 d3db168。理由不是实现有错，是**证据不成立、且违反本 fork 定位**。

## eval 8 次跑下来，零区分度

搭了真实 fixture（含 3 个植入缺陷的 diff、用本仓 scripts/task-brief 与
review-package 生成的简报和审查包），对 task-reviewer 提示词做 before/after：

| 条件            | 提示词     | 简报/报告 | 产出语言 |
|-----------------|-----------|----------|---------|
| 中文内容 OLD ×2 | 无语言指令 | 中文     | 中文    |
| 中文内容 NEW ×2 | 有语言指令 | 中文     | 中文    |
| 英文内容 OLD ×2 | 无语言指令 | 英文     | 中文    |
| 英文内容 NEW ×2 | 有语言指令 | 英文     | 中文    |

第三行是关键：特意做了英文简报 + 英文报告去复现报告人的场景，OLD 照样输出
中文。也就是说在这套运行环境下，光是提示词模板是中文就足以让子智能体说中文，
加的那一行没有改变任何东西。

## 推理链断在哪

「using-superpowers 的中文路由到不了子智能体」这个机制成立（构造上就成立）。
但从「机制成立」直接跳到「所以这就是 #116 的原因」，没验证就当成根因写进了
commit message 和 issue 回复。这正是 CLAUDE.md 里写明会被关闭的**推测性修复**。

## 而且它违反 fork 定位

被改的 4 个文件全是上游文件：

  skills/subagent-driven-development/{implementer,task-reviewer,re-review}-prompt.md
  skills/requesting-code-review/code-reviewer.md

本 fork 的定位是「完整翻译上游 + 增加工具支持 + 单独增加国内特色内容」。
在 4 个上游的行为塑造文件里加零证据的偏离，跟 v1.7.8 那一整版清理偏离的
工作直接相反 —— 那版刚把 5 处偏离修掉，这次又添了 4 处。

audit 4d 一并回滚：守卫本身是好的，但它守的是一条不该存在的偏离。

## 下一步

#116 缺最关键的信息：整条 issue 没写工具和模型，而本次 eval 8 次全在同一套
运行环境、同一个旗舰模型上跑。已去 issue 追问环境。若在报告人那边确认可复现，
正确落点是 using-superpowers 的「中国特色技能路由」节（已声明的 fork 增量、
fork 自有内容），让**控制者**在分派时补语言要求 —— 零上游偏离。
 2026-08-11 22:40:05 +08:00
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
AI不止语
4a53c1e6ab chore(release): v1.7.9 —— 修复 Hermes 支持一直不生效（#45） 
版本号：7 份声明文件 1.7.8 -> 1.7.9。包内文件 109（无增减）。

内容见 RELEASE-NOTES.zh.md v1.7.9 条目。要点：我们从支持 Hermes 起就只装
项目级 .hermes/skills/，而 Hermes 只自动加载 ~/.hermes/skills/ —— 装了完全
不生效，比不支持更糟。改为全局推荐 + 项目级打印可粘贴的 external_dirs 配置。
修复代码本体见 441d024，本次为发版收尾。

顺带修掉发版工具的一个真问题：bump-version.sh 缺 jq 时不退出，逐文件打
"command not found" 后继续跑到 unbound variable —— 版本号一个没写，输出里
却有 "Done."。加前置检查挡住（本次发版即踩到）。

发版前门禁
- audit.sh 166 pass / 0 warn / 0 fail
- verify-release.sh 90 pass / 0 fail
- dry-run：1.7.9 / 109 文件
 2026-08-11 20:53:41 +08:00
AI不止语
441d024cd6 fix(installer): Hermes 支持一直是坏的 —— 改为全局安装并给出可粘贴配置（#45） 
## 我们装错了目录，一直没生效

#45 报告人说「项目级 .hermes/skills/ 里的 20 个 skill 全部返回 404，必须手动
复制到 ~/.hermes/skills/ 才被识别」。查官方文档核实，他是对的：

hermes-agent.nousresearch.com/docs/user-guide/features/skills 明确
Hermes 只自动加载 ~/.hermes/skills/（原文 "the primary directory and source
of truth"），项目级目录不被自动发现；外部目录必须写进 ~/.hermes/config.yaml
的 skills.external_dirs。

而我们从支持 Hermes 起就只装项目级 .hermes/skills/ —— 那个目录 Hermes 根本
不读。这不是「不好用」，是「装了完全不生效」，比不支持更糟。

## 改法

- TARGETS 给 Hermes 加 global（~/.hermes/skills），全局成为推荐装法
- 项目级仍保留（skills 可随仓库分发），但装完打印**可直接粘贴**的配置片段：
      skills:
        external_dirs:
          - <项目绝对路径>/.hermes/skills
  不替用户改 config.yaml —— 那是他们的文件。文档里也写明「配置里不存在的
  路径会被静默跳过」，所以写错不会报错、只会没生效。
- 全局模式**不写 bootstrap**：Hermes 的用户级指令文件约定没有公开文档，
  往 $HOME 根目录写 HERMES.md 是猜路径 + 污染主目录。实测确认全局装完
  $HOME 根目录 0 个文件、卸载 0 残留。

## 文档与清单

- docs/README.hermes.md 开头重写，把「必须全局」放在最前面，并注明
  v1.7.8 及更早只支持项目级 = 装了不生效，是我们的实现错误
- 简繁 README：全局支持清单加 Hermes Agent，工具表的安装命令改为 --global
- verify-release.sh 的 GLOBAL_OK 加 hermes、GLOBAL_NO 移除

## 验证

- 全局：装 20 skills 到 ~/.hermes/skills、$HOME 根目录 0 文件、卸载 0 残留
- 项目级：正确打印 A/B 两种方案与绝对路径的 config.yaml 片段
- audit.sh 166 pass / 0 warn / 0 fail、verify-release.sh 90 pass / 0 fail

注：#45 的后半部分（7 个 skill 文件里 24 处硬编码 Claude 工具名）本次未动。
那属于行为塑造内容，且 references/hermes-tools.md 已有完整映射表，
应走「强化映射表引用」而非把正文改成某个 harness 专属工具名。
 2026-08-08 14:55:21 +08:00
AI不止语
43a46f7912 refactor(skills): fork 增量改为外挂式并强制声明，保证上游各节不被改动 
按维护者决定：保留翻译 skill 内的 fork 增量，但必须做到「不影响上游部分」。
原来的做法做不到这一点 —— 增量是**插在上游步骤序列中间**的。

## 问题

executing-plans 把「处理常见异常」插成了步骤 3，于是上游的
Step 3: Complete Development 被挤成了我们的「步骤 4」。这就不是「不影响上游」，
而是改了上游的结构编号；Remember 也被多加了一条，从上游的 6 条变成 7 条。

## 改法：外挂式

- 「处理常见异常」移出步骤序列，改为独立小节，挂在「何时停下来求助」之后
  （它本就是那一节里「缺少依赖、测试失败、指令不清」三种情形的展开）
- 步骤编号恢复为 1/2/3，与上游逐条对应
- Remember 恢复为上游的 6 条；被多加的「每个任务单独提交」并入外挂节
- 节内首行显式标注：本节是 superpowers-zh 的增量内容，上游没有

using-superpowers 的「中国特色技能路由」同样加上该标注。

现在 14 个翻译 skill 里，上游各节全部逐节对应；多出的 2 节都带标注。

## 让纪律可执行：audit 新增 3c-bis

光靠 README 声明会漂移。新增检查：翻译 skill 的标题数必须等于
「上游标题数 + 本文件里带标注的增量节数」。标注与内容同处一文件，不会各自漂移。
未标注就多出章节 = 隐性分叉，下次同步会被误当成漏译 —— 直接 FAIL。

已双向验证：给 brainstorming 偷偷加一节会被拦下并给出可操作提示，
加上标注后放行。

## 修掉一个让守卫从未生效的 bug（我自己写的）

3c-bis 第一次测试没拦住。查出原因：`grep -c` 匹配到 0 个时输出 "0" 但
**退出码为 1**，写成 `$(grep -c ... || echo 0)` 会拼出 "0\n0"，后续整数比较
直接报错、检查静默失效。改用 `; true` 只吞退出码。

全仓扫同一模式，发现测试辅助里也有 3 处（上游同样有这个 bug）：
- tests/claude-code/test-helpers.sh:77 assert_count 的实际值
- test-subagent-driven-development-integration.sh 的 task_count / todo_count

这个 bug 的后果是断言**永远无法正常失败** —— 模式没匹配到时比较报错而非判定失败。
三处一并修掉并加注释说明原因。（tests/ 不进 npm 包，仅开发使用。）

修复后 audit 由 154 升到 166 pass —— 因为 3c-bis 现在真的对 14 个 skill 都跑了。

## README

简繁对比表新增一行「翻译 skill 内的增量」，写明仅 2 处、都带标注、
上游各节不被改动、audit 会强制未标注的增量报错。

验证：audit.sh 166 pass / 0 warn / 0 fail、verify-release.sh 90 pass / 0 fail
 2026-08-08 14:26:16 +08:00
AI不止语
8a2f37071a feat(installer): 新增 Crush 适配（23 款工具，#40）；补齐 verify-release 覆盖盲区 
## Crush（#40）

查权威源（charmbracelet/crush repo 文档）确认：Crush 遵循 Agent Skills 开放标准，
项目级**自动发现** .crush/skills、.agents/skills、.claude/skills、.cursor/skills
四个目录，无需任何配置；用户级为 ~/.config/crush/skills。

重要副作用写进了 docs：已经为 CC / Cursor / Codex / Antigravity 装过的用户，
Crush 现在就已经能读到那些 skills，此时不要再装 --tool crush，否则同一批
skills 会有两份、被重复加载。docs 里给了确认命令。

- TARGETS 加 Crush（detect: .crush / crush.json / .crush.json），支持 --global
- CLI_PROBES 加 crush（它是 CLI，PATH 探得到）
- skills-only 适配，不需要 bootstrap；不动用户的 crush.json
- 新增 docs/README.crush.md
- 计数 22 -> 23（installer TARGETS 22 条 + Copilot CLI 单独计）

实测：装 20 skills / 二次装幂等 / 卸载零残留且正确保留用户的 crush.json；
--global 装到 ~/.config/crush/skills 并可干净卸载。

## audit Category 5 当场抓到我漏改的 5 处

加计数时忘了 site/build.mjs 的 5 个位置（三语言标语 + FAQ 枚举）。上个版本
新加的计数一致性检查直接 FAIL 拦下 —— 这是它第一次在真实改动中生效。已补
site 18 处并重建，三语言首页 23 计数、0 残留、Crush 均已出现。

## verify-release.sh 有同样的漂移问题，已修

它有自己独立的覆盖清单，加新工具时不进去就静默不测（本次 Crush 就是：
分数仍是 82，因为压根没测它）。

- SPEC / DETECT / GLOBAL_OK 三处补 Crush
- 顺带发现 B 段还漏了 3 个工具的检测标记：DeerFlow（deer_flow）、
  VS Code（.github/copilot-instructions.md）、Gemini CLI（GEMINI.md）——
  后两个是文件而非目录，DETECT 循环原先一律 mkdir，现按扩展名区分创建方式
- 新增 G 段自检：SPEC 覆盖数必须等于 installer 宣称的工具数；
  DETECT 覆盖的工具名集合必须包含全部 TARGETS 名字（用集合比对而非数条数 ——
  一个工具可以有多个检测标记，数数会误判）

覆盖从 82 项升到 90 项。

回归：audit.sh 152 pass / 0 warn / 0 fail、verify-release.sh 90 pass / 0 fail
 2026-08-08 06:14:48 +08:00
AI不止语
a662295898 fix: 同步上游 D 块 —— worktree 清理静默空转 + Gemini 子智能体支持勘误（#19） 
## 1) finishing-a-development-branch：worktree 清理静默空转（上游 0b47219）

真 bug，我们这边与上游同样存在。步骤 6 在步骤 5 已经 cd 到主仓库根之后才用
`git rev-parse --show-toplevel` 重算 WORKTREE_PATH，于是拿到主根路径 ——
`.worktrees/` 溯源判断永远匹配不上，清理静默空转，随后分支删除还会因为
worktree 仍挂着而失败。上游记录说测试对象不得不偏离 skill 原文才能跑通。

修法（4 处）：
- 步骤 2 趁还在工作区内就捕获 WORKTREE_PATH
- 步骤 6 改为消费步骤 2 的值，并加显式警告说明为什么不能在此重算
- 步骤 6 去掉冗余的 MAIN_ROOT 推导与 cd（两个调用方都已切好目录）
- 选项 2 补上菜单已声称的分离 HEAD 推送变体

已实际复现验证（临时仓库 + .worktrees/feature）：
- 旧逻辑：WORKTREE_PATH 算得 "main" -> 溯源未命中 -> 清理空转
- 新逻辑：捕获到 "main/.worktrees/feature" -> 命中 -> worktree remove 成功、
  branch -D 成功（旧逻辑下会因 worktree 仍挂着而失败）

上游第 4 处改动（rationalization 表里"测试早先通过"那行的措辞）本次不适用 ——
我们还是「红线」清单，那张表属 C 块。

## 2) gemini-tools.md：我们错写成「不支持子 Agent」

我们的版本称 Gemini CLI 没有 Task 等价物、依赖子智能体的 skill「退化为
executing-plans 单会话执行」。实际上 Gemini CLI 通过 `invoke_agent`
（`agent_name: "generalist"`，也可用 `@generalist` 聊天语法）支持子智能体，
并且支持在同一响应里发多个调用做并行分派。

这个错误会让 Gemini CLI 用户的 subagent-driven-development /
dispatching-parallel-agents / requesting-code-review 全部瘸腿。

按上游新版重写（33 行 -> 62 行），补齐：动作导向的映射表、指令文件
（GEMINI.md 层级加载）、个人 skills 目录（~/.gemini/skills 与 ~/.agents/skills
的优先级）、子智能体支持与模板填写、并行分派，以及 tracker_* / complete_task /
update_topic / read_mcp_resource 等此前缺失的 20 个工具名。

已全仓扫描，确认没有别处重复这个错误说法。

## 3) audit.sh 结构漂移度量修正（顺带发现的假阳性来源）

3c/3d 用 `grep -cE '^#{1,4} '` 数标题，但这会把 ``` 围栏内的 shell 注释
（`# 运行测试`）当成 markdown 标题 —— 一个 skill 里多几行 bash 注释就能
凭空造出「结构漂移」。

用正确口径（排除围栏）重算 14 个 skill，3 条告警里 2 条是假阳性：
- executing-plans            9/16 WARN -> 9/11  pass
- finishing-a-development-branch 21/31 WARN -> 14/17 pass
- using-git-worktrees        21/28 WARN -> 14/21 WARN（真漂移，保留）

这点很要紧：#19 里引用的上游欠账数字此前是被虚高的。

改为 awk 逐行跟踪围栏状态。双向验证：给 brainstorming 加 5 个真标题会触发
告警（7 vs 13），加 5 行围栏内 shell 注释不触发。

回归：audit.sh 152 pass / 1 warn / 0 fail（原 150 pass / 3 warn）
      verify-release.sh 82 pass / 0 fail
 2026-08-07 23:10:24 +08:00
AI不止语
1321cc65fb test(audit): 新增工具计数一致性检查；修 bash 3.2 下 CJK 报错信息乱码 
审核 v1.7.2 时发现三个问题，一并修掉。

1) 工具计数散落十几处，没有任何检查兜着（audit 新增 Category 5，+24 项）

加一款工具要同步简繁 README（各 6 处）、package.json、CLAUDE.md、
site/build.mjs（三语言 15 处）、3 份 plugin manifest —— 这次全靠人工 grep 才
没漏。现在改为从 installer 的 TARGETS 推导期望值并逐处断言。

口径写进注释：TARGETS 是「安装目标」共 21 个；Copilot CLI 与 CC 共用
.claude/skills（别名 copilot 映射过去）不占独立条目，但文案里作为独立产品
单独计数，所以「文案数 = TARGETS 数 + 1 = 22」。

除逐处计数外还加了两条结构性断言：
- README 工具表的实际表格行数必须等于宣称数（防漏加/多加行）
- Category 2 实际回归测试的工具数必须等于宣称数（宣称了就必须测）

已验证这个检查真的会拦：把标题改成 23 款、删掉一行工具表，两种漂移都被抓到。

2) bash 3.2 下 CJK 报错信息乱码（真 bug，只在检查失败时才暴露）

macOS 自带 bash 3.2.57 解析标识符时不识别多字节字符，`$file「` 会把「的首字节
(0xE3) 吞进变量名，导致变量展开为空且字符被截断 —— 报错信息变成
「计数不一致: ����= ��应为 22」。写检查的人看不到，因为只有失败时才打印。

复现：bash -c 'f=README.md; echo "文件: $f「标签」结束"' -> 文件: ��标签」结束

修法是给紧跟 CJK 标点的变量加花括号。全仓扫描 `$var` 紧跟非 ASCII 字节的模式，
命中 3 处：audit.sh 2 处（本次新增）、verify-release.sh 1 处（上个提交带进来的，
因为检测项一直全通过所以从没暴露）。修后报错信息可读：
  计数不一致: README.md「工具表标题」= 23，应为 22
  检测 .clinerules/ -> 得到「Cline」，期望「错误期望值」

3) .gitignore 漏了新工具的安装产物

.trae/、.qoder/ 等都在忽略列表里，但 .cline/、.clinerules/、.kilocode/ 没加 ——
在本仓库内跑安装器自测会留一堆未跟踪文件。已补上并验证 git status 干净。

验证：audit.sh 154 pass / 0 fail（原 130，+24 为 Category 5）
      verify-release.sh 82 pass / 0 fail
 2026-08-07 21:54:48 +08:00
AI不止语
da6c6b082d chore(release): v1.7.2 —— Cline / Kilo Code 适配 + 检测落空建议 + marketplace 文档 
版本号：7 份声明文件全部 1.7.1 -> 1.7.2（按 .version-bump.json 逐一核对一致）。
注：本机没装 jq，scripts/bump-version.sh 跑不了，改用等价的逐字面量替换，
只动 "version" 那一行，未重排任何 JSON（已 diff 确认）。

新增 scripts/verify-release.sh —— 发版前深度验证，82 项断言。
补 audit.sh 的盲区：audit 只看 installer 退出码，装完有没有东西落盘、卸载有没有
留垃圾它都不查。本脚本断言实际结果：
  A. 22 款工具：装 -> 断言 20 个 skill 落盘 -> 二次装幂等 -> 卸载零残留 + 无嵌套
  B. 19 个检测标记逐一验证只触发预期工具（防新增工具误触发既有工具）
  C. --global 7 款成功 / 14 款明确拒绝且退出码 1
  D. --global 拒绝信息引用的 8 份 docs 真实存在（防死链）
  E. rules 型工具索引断言：表 20 行、无空 description、Cline 无 frontmatter
  F. PATH 探测在 PATH 为空 / 畸形 / 未定义三种退化情形下的健壮性

文档
- RELEASE-NOTES.zh.md 加 v1.7.2 条目，含设计取舍与完整验证清单
- 简繁 README 更新亮点：v1.7.0 -> v1.7.2（1.7.1 时漏更新，一并修正）
- marketplace 示例里的 "Version: 1.7.1" 改为「<当前版本>」—— 写死版本号每次
  发版都会过期

发版前验证结果
- scripts/audit.sh: 130 pass / 0 fail（2 warn 为既有上游漂移，见 #19）
- scripts/verify-release.sh: 82 pass / 0 fail
- npm 包端到端：npm pack -> 包内 version 1.7.2 -> 从 tarball 安装 ->
  用打包后的二进制真实跑 Kilo Code 自动检测 -> 20 skills + 索引生成 ->
  卸载零残留
- engines >=20 与实际语法一致（仅用到 padEnd/ES2017，无 ?? 与 ?.）
- 包体 444K / 106 文件，docs/README.cline.md 与 README.kilocode.md 均已入包
 2026-08-07 20:00:51 +08:00
AI不止语
6cb1cd89bc feat(installer): 新增 Cline 与 Kilo Code 适配（22 款工具，#112、#88） 
两款都是 VS Code 扩展，加载的是「rules」而非懒加载的 skills —— rules 会
并入每一轮 system prompt。所以照搬「把 20 个 SKILL.md 复制进规则目录」会
让每轮对话背着几万字常驻开销（Cline 官方也提示规则超约 300 行后遵守度下降）。

改用仓库既有的 Trae 模式：规则目录里只放一份小索引（核心规则 + 20 个 skill
的名称/触发条件表），skills 本体放各自的 skills/ 目录由 agent 按需读取。

Cline（#112）
- skills -> .cline/skills/，索引 -> .clinerules/superpowers-zh.md
- 不写 YAML frontmatter：Cline 目前只支持 paths 一个条件字段，
  无 frontmatter 即始终生效，正是所需
- 索引保持在 .clinerules/ 根层单文件 —— 子目录是否递归扫描官方未说明

Kilo Code（#88）
- skills -> .kilocode/skills/，索引 -> .kilocode/rules/superpowers-zh.md
- 走 .kilocode/rules/ 而非 v7 推荐的 .kilo/rules/ + kilo.jsonc：后者需要把
  路径登记进用户的 kilo.jsonc，那是带注释的 JSONC，安装器安全合并容易改坏
  用户配置。官方明确 .kilocode/rules/ 向后兼容且零配置生效，故选它。
  docs 里写了想迁到 v7 方式该改哪一行，以及万一没生效怎么反馈。

接入点（全部为新增，未改动任何既有工具的条目）
- TARGETS 加 2 条，检测标记 .clinerules / [.kilocode,.kilo,kilo.jsonc] 均唯一
- installForTarget 分发、TOOL_ALIASES（cline/kilocode/kilo/kilo-code）
- BOOTSTRAP_DELETE 加两份索引路径，--uninstall 能清干净
- --global 明确拒绝并指向 docs：Cline 全局 rules 路径随 OS 变
  （~/Documents/Cline/Rules，Linux/WSL 还有 ~/Cline/Rules 回退），
  Kilo 全局需改 kilo.jsonc，都不是通用 --global 能可靠命中的
- audit.sh TOOLS 数组加 cline kilocode，纳入 install/幂等/卸载回归
- 新增 docs/README.cline.md、docs/README.kilocode.md
- 计数 20 -> 22：简繁 README、package.json、CLAUDE.md、3 份 plugin manifest
  （RELEASE-NOTES 里的历史计数是过往版本记录，不动）

实测
- 两款均通过 装 / 二次装幂等 / 卸载无残留
- 检测隔离：.clinerules 只触发 Cline、.kilocode|.kilo|kilo.jsonc 只触发
  Kilo Code；.claude/.cursor/.trae/.qoder/.codebuddy 检测结果与改动前一致；
  .claude + .clinerules 共存时两款并行安装正常
- audit.sh: 130 pass / 0 fail（2 项 warn 为既有上游漂移，见 #19）

路径依据：docs.cline.bot/customization/cline-rules、kilo.ai/docs/customize/custom-rules

两款合并为一个提交：共用同一套「rules 型工具」机制与同一批计数改动，
拆开会产生 21 款的中间状态，audit 无法在中间提交上自洽通过。
 2026-08-07 17:38:37 +08:00
AI不止语
01319b5b02 feat: 新增华为云码道 CodeArts 支持（skills-only，关 #20） (#99) 
华为云 CodeArts Doer 的 skills 目录为 .codeartsdoer/skills/（用户在 #20 确认）。
本次做 skills-only 适配：检测 .codeartsdoer/ 或 --tool codearts 安装，
靠 CodeArts 自身 skill 发现加载。其 bootstrap/指令文件约定未证实，
故不生成 bootstrap（docs 已说明，若不自动触发可手动点名 skill）。

- bin: TARGET（.codeartsdoer/skills，检测 .codeartsdoer）+ 别名
  （codearts/codeartsdoer/huawei）
- 工具数 19 → 20：README/站点/package/FAQ/stats 同步
- docs/README.codearts.md（含自动触发的诚实说明 + 求证请求）
- audit TOOLS 加 codearts

测试：audit 124 PASS/0 FAIL（含 codearts 装/幂等/卸载）、全局套件 50/50
回归、站点重建工具数 20。
 2026-07-13 21:56:11 +08:00
AI不止语
cd651cd1c6 feat: 新增 CodeBuddy（腾讯 AI IDE）工具支持（关 #18 #75） (#98) 
CodeBuddy 加载机制类似同类 IDE：项目根 CODEBUDDY.md 作 bootstrap，
skills 放 .codebuddy/skills/。仅项目级（用户级加载路径未证实，暂不做全局）。

- bin: 加 TARGET（检测 .codebuddy / CODEBUDDY.md）+ 别名（codebuddy/-cn/-code）
  + CODEBUDDY.md bootstrap 生成 + 卸载哨兵清理
- 工具数 18 → 19：README/站点/package.json/FAQ/stats 全量同步
- docs/README.codebuddy.md 中文使用文档；audit TOOLS 加 codebuddy
- 站点 FAQ 与工具列表补 CodeBuddy

测试：audit 122 PASS/0 FAIL（含 codebuddy 装/幂等/卸载）、全局套件 50/50
回归无破、站点重建 42 页工具数 19。
 2026-07-13 21:43:56 +08:00
AI不止语
af4c03c1e0 feat(kimi): 新增 Kimi Code harness 支持（对齐上游 v6.0.0 集成模型） 
issue #37：Kimi Code 已支持 Skills 能力，希望原生支持。上游 obra/superpowers
在 v6.0.0 已用插件清单模型原生集成 Kimi，本提交把同样的集成方式落到本 fork。

Kimi 走插件清单模型（与 CC plugin 同类），直接指向仓库现有 skills/，
不复制 skill、不建 symlink、不装 hook、无运行时依赖，因此无需改 npx
安装器（安装器面向需要复制 skills 的工具）。

- .kimi-plugin/plugin.json：fork 品牌清单，skills 指向 ./skills/，
  sessionStart.skill = using-superpowers（会话开始自动加载 bootstrap），
  skillInstructions 提供 Kimi 工具映射（AskUserQuestion/TodoList/Agent/
  Skill/Read/Write/Edit/Bash/Grep/Glob/FetchURL/WebSearch，保留上游权威
  英文映射以免破坏真实工具名）
- 版本同步：.version-bump.json 与 scripts/sync-plugin-version.js 双向接入
- docs/README.kimi.md：中文安装/工具映射/排错指南；README.md 工具列表加链接
- tests/kimi/：清单结构测试（适配 fork：name=superpowers-zh、校验版本同步条目）

验证：bash tests/kimi/run-tests.sh 通过；manifest 合法 JSON；版本同步双机制
均含 kimi 条目；scripts/audit.sh 静态校验 0 FAIL；README→docs/README.kimi.md
链接可解析。

注：Kimi 实际 skill 自动触发需在 Kimi Code 内验证（与本 fork 其它 harness
同样限制），清单结构已对齐上游 v6.0.0 经过验证的集成方式。
 2026-06-20 02:37:31 +08:00
AI不止语
725977b422 feat: 加 Qoder 适配（第 18 款工具）— skills + always_on bootstrap rule 
closes #26, closes #34

## 改动

- bin/superpowers-zh.js: TARGETS 加 Qoder (`.qoder/skills`, detect `.qoder`)，
  TOOL_ALIASES 加 `qoder`，新增 `generateQoderBootstrap()` 生成
  `.qoder/rules/superpowers-zh.md`（`trigger: always_on` + `alwaysApply: true`）
- scripts/audit.sh: TOOLS 加 qoder，17→18
- 3 个 plugin manifest（.claude-plugin/{plugin,marketplace}.json、.cursor-plugin/plugin.json）
  description 同步到 18 款
- README、CLAUDE.md、package.json 文案对齐 18
- docs/README.qoder.md: 新增完整安装/使用/卸载指南，附 schema 说明

## 设计要点

Qoder Rules 的 frontmatter schema（`trigger: always_on` / `model_decision` /
`manual`）官方 docs.qoder.com/zh/user-guide/rules 未公开，来自 GitHub 上
4 份真实社区样本（python-office、termiClaude、QoderTest、TelegramFileServer）
的交叉验证。

按 Trae 模式生成 always_on bootstrap 而非 Cursor/Windsurf 的"裸 skill"模式，
是为了确保核心规则（先 brainstorming / 先 TDD / 先验证）在每个会话都自动加载，
不依赖模型对 description 文本的隐式匹配。

## 验证

- 端到端：--tool qoder 装、自动检测、二次幂等、卸载（20 skills + 1 bootstrap
  全部清掉，0 残留）
- bootstrap 文件 skill 列表（20）与实际 skills/ 目录数（20）一致
- 全量 audit: 96 PASS / 0 FAIL（18 款工具完整 install + 幂等 + uninstall 跑通）
 2026-05-21 00:56:18 +08:00
AI不止语
c5b4fa446b chore: release v1.4.0 — 上游漂移 P0 全量修复 + 防回归基建 (#32) 
跟 PR #28 + #30 + #31 一起构成 v1.4.0 的完整内容。本 PR 仅做发布层
（版本号 bump + plugin manifest 同步 + release notes），不动 skill 内容。

版本号 1.3.0 → 1.4.0：
- package.json
- .claude-plugin/plugin.json + marketplace.json
- .cursor-plugin/plugin.json
- .codex-plugin/plugin.json
- gemini-extension.json（之前卡在 1.1.6，本次顺带追上）

工具链小修：
- scripts/sync-plugin-version.js TARGETS 加入 gemini-extension.json
  （之前漏掉，是 gemini-extension.json 长期卡在老版本的根因）
- package.json 的 version 钩子 git add 列表加上 gemini-extension.json

RELEASE-NOTES.zh.md 新增 v1.4.0 段，按"上游同步"性质分组列出 9 项
修复内容，明确标注每项的上游 ref + 本 fork PR 号。

注意：本 PR 应在 #28 + #30 + #31 merge 之后才 merge —— 顺序错了
会导致 release notes 描述的 PR 在 git log 里还没有。

不影响：
- 上游 marketplace 安装路径（仍按主站路径正常工作）
- 现有 npm 用户向后兼容（npx superpowers-zh 仍可用）
 2026-05-12 18:14:02 +08:00
AI不止语
98ce004193 chore(ci): 加 audit 脚本 + workflow 自动检测上游漂移 (#31) 
防回归基建：把本轮全量质量审计的 4 类检查打包成可重复运行的脚本，
每次 PR 自动跑，发现漂移立刻拦下。

scripts/audit.sh：
1. 静态校验：JSON parse、SKILL.md frontmatter、symlink、hook 可执行性
2. Installer 功能：17 款工具装 / 重装（幂等）/ 卸载全跑一遍
3. 上游对齐：hooks 4 文件 + brainstorm scripts 3 文件 + 14 翻译 skill
   结构层级（H1-H4 标题数）+ code-reviewer.md self-contained 版结构
4. 交叉引用：README → docs/ 链接、skill 间 superpowers:xxx 引用、
   装完后 .claude/skills/using-superpowers/SKILL.md 路径解析

支持 --quick（跳过 installer）和 --no-upstream（跳过对齐）两个开关。

.github/workflows/audit.yml：
- 触发：PR + push to main + 手动 dispatch
- 步骤：checkout（fetch-depth 0）+ setup node 20 + 加 upstream remote
  + fetch upstream main 浅克隆 + 跑 audit.sh
- FAIL > 0 → 整个 workflow 失败，PR 被卡

设计原则：
- 这次"4 个 P0 缺陷漂"事件（hooks-cursor + brainstorm + code-reviewer 引用 +
  code-reviewer.md 整合）如果当时有这个 audit 在 CI 跑，PR 阶段就会被拦下
- 用 H 数对齐而不是行数 diff 来判断结构漂移（避免翻译造成的假阳性）
- WARN（不阻塞）vs FAIL（阻塞）分级：主动扩写算 WARN，
  结构性落后上游算 FAIL

本地烟测：
- main 分支跑：92 PASS / 2 WARN / 8 FAIL（捕获到所有已知漂移）
- chore/sync-upstream-p0-drift（PR #30）跑：97 PASS / 2 WARN / 0 FAIL（PR 修复后全绿）

后续：PR #28 + #30 merge 后，main 上 FAIL 应归零（WARN 只剩 executing-plans
主动扩写一项）。
 2026-05-12 18:13:12 +08:00
AI不止语
48c4d0d417 fix(scripts): sync-plugin-version 支持嵌套字段路径 (#23) 
补上之前简化版未实现的 plugins.0.version 路径，把
.claude-plugin/marketplace.json 纳入版本同步目标。

修复 marketplace.json 卡在 1.1.8 的老漂移（自 v1.1.8 起没动过）：
plugins[0].version 1.1.8 -> 1.2.1（追上其他 4 个 manifest）。

实现：
- TARGETS 改为对象数组 { path, field }，对齐上游 .version-bump.json 格式
- field='version' 走顶层 regex（保留原行为）
- field='plugins.0.version' 走嵌套 regex（锚定到 plugins 数组首项）
- 都用 regex 替换而非 JSON.stringify，保持原文件格式（缩进/数组写法等）

测试：
- 升级场景 1.2.1 → 1.3.0：4 个 manifest 全部同步
- 幂等性：版本相同时输出 "already at"
- 边界：marketplace.json 其他字段完全未动（diff 仅 version 一行）
- npm pack：90 文件 228KB 不变
 2026-05-10 22:48:09 +08:00
AI不止语
a9e02b501e chore: 跟上游 v5.1.0 对齐 (#22) 
补齐上游漏的根级文件：CLAUDE.md（翻译 + 中文 fork 备注）、
AGENTS.md（symlink → CLAUDE.md，跟上游 mode 120000 一致）、
RELEASE-NOTES.md（上游英文原样 1180 行）、RELEASE-NOTES.zh.md
（新建中文 fork 自身 release log）、.codex-plugin/plugin.json
（中文化）、.version-bump.json、scripts/bump-version.sh、
assets/{app-icon.png,superpowers-small.svg}、4 个上游新增测试。

跟上游意图对齐，删上游已废弃流程：
- commands/ 全 3 个 deprecated stub（上游 #1188）
- agents/code-reviewer.md（已上升进 requesting-code-review skill，
  上游 PR #1299）
- bin/superpowers-zh.js 删 install agents 逻辑，保留 uninstall 用
  hardcoded LEGACY_AGENT_FILENAMES 列表清理已装用户残留
- .github/workflows/ci.yml 删 "Validate agents" 段
- package.json files 字段移除 agents/ commands/

主动修上游 v5.1.0 疏忽：
- .cursor-plugin/plugin.json 删 dangling 的 "agents": "./agents/"
  和 "commands": "./commands/"。上游删目录但忘同步 manifest
  （git blame 显示自 2026-02-13 起从未更新）。

配套：
- scripts/sync-plugin-version.js 扩到 .codex-plugin/plugin.json
- npm pack 校验 90 文件 228KB，agents/commands 残留 0 条

中文版"手动新增"叠加层全部保留：bin/ + npx 流程、docs/、
chinese-* skill、mcp-builder、workflow-runner、README 主推 npx、
各 INSTALL.md、.gemini/、sync-plugin-version.js。

详见 RELEASE-NOTES.zh.md v1.3.0 段。
 2026-05-10 22:27:52 +08:00
AI不止语
bb9dc4950e chore: plugin manifest 版本号自动跟 package.json 同步 
之前 .claude-plugin/plugin.json 和 .cursor-plugin/plugin.json 的 version
字段一直停在 1.1.8，落后于 npm 1.1.9 / 1.2.0 / 1.2.1——每次发版都要手改。

- 新增 scripts/sync-plugin-version.js：用正则替换 version 字段一行，
  保留两个 manifest 的原排版（数组单行/多行、缩进等），无 diff 噪音
- 在 package.json 挂 npm version 钩子：bump 后自动同步并 git add 到
  version commit 里，从此不会再漏
- 把当前两个 manifest 从 1.1.8 一次性修到 1.2.1
 2026-05-05 19:32:20 +08:00