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
206 Commits 34 Branches 46 Tags
main
Commit Graph

13 Commits

Author SHA1 Message Date
AI不止语
1f66b091b7 fix(site): 官网工具墙停在 20 款 —— Cline / Kilo Code / Crush 的用户在下拉里找不到自己的工具 
起因是核对首页：统计块写着「20 支持工具」，同一屏下面的标题写着「一套 skill，
23 款工具通用」，FAQ 里又老老实实枚举了 23 款。三处自己打自己。

根因：文案计数早就跟着 installer 改到了 23，但 `site/build.mjs` 的 `TOOLS`
数组从来没人补 —— audit 只校验文案里的数字，不校验列表本身。

## 1. 工具列表补 3 款 + 修 4 处错的

`TOOLS` 20 条 -> 23 条（= TARGETS 22 条 + Copilot CLI 单独计数）。
统计块的 `20` 是硬编码的，改成 `TOOLS.length`。

漏的三款（installer 一直支持，官网从没有过）：Cline、Kilo Code、Crush。

已有条目里查出的错（逐条实测过命令）：

| 条目 | 原来 | 现在 | 依据 |
|---|---|---|---|
| Claw Code | `--tool claw` | 直接 `npx superpowers-zh` | detect 是 `.claw` / `CLAW.md`，实测能自动检出 |
| Hermes Agent | `--tool hermes` | `--global --tool hermes` | 官方只自动加载 `~/.hermes/skills/`，项目级要手写 config.yaml，给项目级命令等于给「装了不生效」 |
| Qwen Code | 类型 IDE | CLI | 它是 QwenLM/qwen-code 命令行工具，不是通义灵码 |
| Antigravity | 类型 CLI | IDE | Google 的 AI IDE，docs/README.antigravity.md 里本来就这么写 |

`auto: true/false` 两态不够用了（Hermes 是「能检出但项目级不生效」），换成
`mode: auto / manual / global`，三语各补一条对应说明文案。

## 2. FAQ 的「支持全局」清单少了 4 款

写着 7 款，installer 实际 11 款 —— CodeArts / Crush / Hermes / CodeBuddy
陆续拿到 `--global` 之后这句话没跟。三语同步补齐。
两版 README 的同一句也少了 CodeArts（v1.7.11 补 --global 时漏改），一并修。

## 3. skill 详情页有 6 条死链

`SKILL.md` 里指向兄弟文件的相对链接（`implementer-prompt.md`、
`../requesting-code-review/code-reviewer.md` 等）站点上根本没有这些 .md：
`../` 开头的直接 404，不带 `./` 的被 md.mjs 的 scheme 白名单打成 `href="#"`
—— 点了没反应，比 404 还难查。

`renderMarkdown(src, base)` 加基址参数，相对链接解析到 GitHub 源文件。
5 个目标地址逐个 curl 过，都是 200。全站扫描：死链 0、`href="#"` 0。

## 4. 加两条门禁，堵住这次的漏法

audit 原来只数文案里的数字，这次两个问题它一个都发现不了。补：

- 官网 `TOOLS` 条目数必须 = TARGETS + 1
- 官网 FAQ 全局清单必须包含 installer 里每个带 `global:` 的工具

反向验证过：删掉 Crush、去掉 CodeArts，两条各自报错。

audit 170 pass / 0 fail（新增 2 条）；verify-release 114 pass / 1 fail，
唯一那条是 windsurf.com 返回 429 限流，改动前的干净树上同样失败，与本次无关。
 2026-08-28 21:48:01 +08:00
AI不止语
43edf34b2c fix(installer): Windsurf 全局装错目录（装了不生效）+ 两个静默失效的检查 
## Windsurf --global 一直装在 Windsurf 不读的地方

官方文档（docs.windsurf.com/windsurf/cascade/skills）写明两个路径**不同构**：

    项目级：.windsurf/skills/<skill-name>/
    用户级：~/.codeium/windsurf/skills/<skill-name>/   ← 在 .codeium 下

我们的 --global 装到 ~/.windsurf/skills —— Windsurf 不读那里。又一个 Hermes 同款
「装了完全不生效」。项目级路径是对的，只有全局错。

Cursor 一并核实：cursor.com/docs/skills 确认 .cursor/skills/<name>/SKILL.md
启动时自动发现，无需配置 —— 我们装的是对的。

## 测试为什么没抓到：只验退出码，不验落盘位置

verify-release 的 C 段对全局白名单只断言「退出码为 0」。装到错目录退出码照样是 0。
**「跑通了」不等于「装对了」。** 新增 GLOBAL_DIR 断言：10 款全局工具逐个断言
skill 真的落在官方读的那个目录，外加一条自检（GLOBAL_DIR 必须覆盖 GLOBAL_OK 全部，
以后加全局工具不能漏断言）。

双向验证：把 Windsurf 全局路径改回旧值，立刻报
「--global windsurf: .codeium/windsurf/skills 里是 0 个 skill，期望 20」。

## 两个我自己写出来的静默失效

**① `grep -P` 不可移植。** 新加的「变量后紧跟多字节字符」检查第一版用了 grep -P，
在交互 shell 里（ugrep）看着能用，进了脚本跑的是 /usr/bin/grep（BSD grep，不支持
-P），配上 2>/dev/null 就成了永远匹配不到的死检查 —— 正是我这两天一直在修的那类
bug，自己又造了一个。改用 LC_ALL=C + ERE：C locale 下多字节按单字节处理，>0x7F
的字节落在 [^ -~] 之外，BSD/GNU 都支持。

**② 同一个全角括号坑又踩一次。** `期望 $EXPECT_SKILLS（…）` 里全角括号被吞进变量
名，set -u 下脚本半途崩掉。这已经是本仓第二次（第一次是死链检查的 $code）。所以
把它固化成 audit 1e，注释行排除，双向验证过。

## 一次操作事故（记下来）

用 /tmp 备份做变异测试时，把 verify-release.sh 的未提交改动整段覆盖没了，
git diff 才发现。变异测试应该用 git 保护现场，不该用 /tmp 拷贝。

## 其它

- 外链验活跳过分支补 ok，否则 PASS 总数随网络漂移、发版记录对不上（实测连跑两次
  稳定 111）
- docs/README.windsurf.md 重写：两个路径不同构、渐进式披露（默认只给模型 name +
  description，不造成常驻开销）、跨工具发现（也扫 .agents/skills 与 .claude/skills，
  装过 Antigravity 或 CC 的不必重复装）

audit 168 pass / 0 warn / 0 fail；verify-release 111 pass / 0 fail。
 2026-08-12 20:42:21 +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不止语
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不止语
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不止语
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不止语
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