lywsvip/superpowers-zh
1
0
Fork 0
mirror of https://github.com/jnMetaCode/superpowers-zh.git synced 2026-09-02 22:54:06 +08:00
Code Issues Packages Projects Releases Wiki Activity
206 Commits 34 Branches 46 Tags
main
Commit Graph

206 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
AI不止语
932ffdcd01 feat(site): 官网补上「本版谁该重装」和 22 份工具文档入口——此前这两件事站上一个字都没有 
上一轮我把官网审计做成了纯技术体检（robots / CSP / 图片字节 / og 标签），扫的是
「哪里不对」，没扫「访客需要什么、站上却没有」。按内容维度重查，查出两个比那些
重得多的空洞。

## ① v1.7.11 的核心信息，官网完全没有

这个版本的全部意义是一句话：Codex CLI / VS Code / Windsurf / Qwen Code / DeerFlow /
Claw Code 六款此前装了不生效，请重装。而官网上关于这件事的表述实测为零：

    重新安装 / 变更 / 更新日志 / Release / RELEASE-NOTES   首页出现 0 次
    重装                                                   1 次，但在全局安装 FAQ 里，与本事无关
    v1.7.11                                                1 次，就是统计块里那个数字

**上周装过的用户今天来站上，没有任何途径知道自己装的那份是坏的。** README 顶部有
整块更新亮点，官网一个字都没有。

hero 下方加一条可点的版本提示条（三语），点进 RELEASE-NOTES。版本号不手写：从
RELEASE-NOTES.zh.md 的最新条目解析，再与 package.json 交叉校验 —— 两边漂了直接
构建失败。需要重装的工具列表抽成 REINSTALL_TOOLS 常量，三语共用一份。

## ② docs/ 里 22 份工具安装指南，官网零暴露

全站链接到它们的次数：0。而官网「安装」区全文只有 378 字，内容就是「选工具 →
复制命令」。那 22 份文档里装的恰恰是这里缺的：

    docs/README.codex.md    ## ⚠️ v1.7.10 及更早的项目级安装装错了地方
    docs/README.kiro.md     ## ⚠️ v1.7.9 及更早版本请重新安装
    docs/README.windsurf.md > 📌 --global 装到了 Windsurf 不读的目录，等于装了不生效

Kiro 用户想知道「为什么要重装、旧布局怎么清」，站上没有出口。

工具墙的 pill 改成：有专属文档的 20 款直接链过去（带 ↗ 与 title 提示），没有文档的
3 款（Claude Code / Cursor / Copilot CLI）保持纯文本，不造不存在的链接。

## 新增三条构建期门禁（都反向验证过）

| 门禁 | 造错 | 实际拦下 |
|---|---|---|
| release notes 与 package.json 版本一致 | 把条目改成 v1.7.12 | `版本漂移：package.json 是 1.7.11，RELEASE-NOTES 最新条目是 v1.7.12` |
| 工具文档必须存在 | doc 改成 windsurfff | `工具 Windsurf 的文档不存在：docs/README.windsurfff.md` |
| release notes 结构可解析 | 抹掉版本标题 | 退回上一条目并报版本漂移，而不是静默渲染空版本 |

第二条尤其必要：官网链到 GitHub 上一个不存在的 docs 文件，就是又一条「编造出处」,
而本仓已经因为编造链接栽过一次（033adc3）。

## 验证

- 三语版本条渲染正确，链接指向 RELEASE-NOTES.zh.md
- 工具墙：可点 20 款 / 纯文本 3 款，与 docs/ 实际拥有的文档一一对应
- **20 条文档链接逐条 curl，全部 200**（不抽样）；RELEASE-NOTES 链接 200
- 官网 66 页构建，站内死链 0、无效 href="#" 0、缺 height 的 img 0
- audit 170 pass 0 fail；verify-release 115 pass 0 fail
- tests/kimi · pi · opencode · brainstorm-server 全 PASS
 2026-09-02 22:45:22 +08:00
AI不止语
1081cefc42 fix(docs,site): README 把 2 个上游 skill 算成「中国特色」；二维码缺 height；官网外链没人验活 
按主站逐项核对时查出的三处，都不是新引入的，是一直没人发现。

## ① README 的「中国特色 Skills（6 个）」与官网自相矛盾

三处口径本来就不一致：

| 位置 | 原来的说法 |
|---|---|
| 官网统计块 | 4 中国原创 |
| `.claude-plugin/plugin.json` | 20 个 skills（14 翻译 + 4 中国原创 + 2 上游历史保留）|
| 两版 README | **6 个中国特色 Skills** ← 只有它是 6 |

README 把 `mcp-builder` 和 `workflow-runner` 也算进了「中国特色」。用 GitHub API 核过：
**上游 obra/superpowers 现有 14 个 skill，本仓 20 个，多出的正是 4 个 `chinese-*` 加这两个。**
它们来自上游、上游后来移除、本 fork 保留继续维护 —— 跟中国特色没有任何关系，把它们
算成中国原创等于虚报了 50% 的原创量。

改：规模表列名改「中国原创 Skills」值改 4（附注另有 2 个上游历史保留）；小节标题拆成
「中国原创（4 个）· 上游历史保留（2 个）」；表格里这两行的「上游有吗？」由「无」改为
「曾有，上游已移除」——原来写「无」会被读成「我们原创的」，正是错误的来源。简繁同步。

（`using-superpowers` 正文里的「中国特色技能路由」是真实存在的小节名，不动。）

## ② 页脚三个二维码缺 height，加载时把页脚顶下去

`<img width="158">` 没有 height，浏览器算不出宽高比，图一到位就发生布局偏移（CLS）。
赞助商 banner 和 logo 都是齐的，只有二维码漏了。

没有写死数字，而是新增零依赖的 `imageSize()`（PNG 读 IHDR、JPEG 逐段找 SOFn），
构建时从文件读真实尺寸：258×258 / 1125×1680 / 316×316，与 `sips` 实测逐一吻合。
换二维码时属性自动跟随，不会悄悄退回错的比例。

顺带用同一个函数补了一条门禁：**赞助商声明的 `w`/`h` 必须与素材真实尺寸一致** ——
换了 banner 忘了改数字，页面就会按错的宽高比预留位置。

## ③ 外链验活门禁扫不到官网，三条付费展位链接一直无人看守

`verify-release` H 段只扫 `docs/*.md` 与两版 README，`site/build.mjs` 不在列。也就是
旗舰赞助商与两个常规位的推广链接挂掉了不会有任何人知道 —— 而这是要赔的。

扫描范围加上 `site/build.mjs`，并把 `compshare|cubence` 移出排除名单（原来被当噪音跳过），
正则补 `?=&` 让带 aff/referral 参数的推广链接被完整验证而不是截断到路径。
覆盖链接 45 → 52 条。

排除名单新增 `googletagmanager|google-analytics`：它们在 build.mjs 里是 **CSP 白名单条目
不是链接**，裸域 `googletagmanager.com` 实测返回 404，纳入等于凭空造一条误报 ——
这条门禁最忌讳的就是误报。

## 反向验证（三条逐一造错，必须拦下）

- 把官网的 book.aibuzhiyu.com 改成不存在的路径 -> `死链（404）`，FAIL 1
- 把 infistar banner 的 w/h 改成 800×368 -> 构建退出码 1，
  `banner 尺寸对不上：声明 800×368，实际 1269×337`
- 二维码尺寸不再有写死数字（`width="158"` 已从源码消失）

## 全量测试

官网 66 页构建 / 站内死链 0 / 无效 href="#" 0 / **缺 height 的 img 0**（原为 3）；
audit 170 pass 0 fail；verify-release 115 pass 0 fail；CI 等价 20 skills 0 错误 v1.7.11；
tests/kimi · pi · opencode · brainstorm-server 全 PASS。
 2026-09-02 21:19:58 +08:00
AI不止语
293b300365 refactor(sponsors): 旗舰赞助商文案改回分段展示，压成一整段把结构揉没了 
赞助商给的原文本来是三条并列要点（⚡ 稳定承载 / 🧠 一个 Key 接入 / 🛠️ 赋能工作流），
上一版为了塞进卡片压成了一整段 —— 信息没丢，但骨架没了：卡片里是一堵 140 字的墙，
README 里也是。付费展位应当按赞助方的文案结构呈现，读者也更容易扫。

## 改法

- 官网旗舰卡：`desc` 整段 -> `points` 三条要点（图标 + 加粗小标题 + 说明），三语各一份；
  新增 `.flag-points` 样式，图标定宽一列、标题与说明纵向对齐，颜色走 --text /
  --text-dim，深浅主题都已定义
- 两版 README：改成「标题行 + 致谢行 + 三条 bullet + 🎁 福利行」，与赞助商原文一一对应，
  福利行补上原文的「superpowers-zh 用户专属福利」前缀
- 常规位不受影响，仍用整段 `desc`（卡片窄，四行截断的排版是为整段设计的）

## 门禁跟着分流

`assertSponsors()` 原来无差别要求每家都有 `desc`。现在按 tier 分：旗舰要
`img/w/h/points`，常规要 `logo/desc`；并新增一条 —— 三语要点**条数必须一致**，
每条的 `icon/t/d` 不能空。漏翻一条要点是最容易发生的漂移，页面上不会报错，
只会某个语言少一条。

反向验证：删掉繁體第三条 -> `points 三语条数不一致：zh/en/zht = 3/3/2`；
把简体第一条标题清空 -> `zh 要点缺 icon/t/d`。两条都按预期拦下。

## 验证

- 三语赞助页各渲染 3 条要点，图标 / 标题 / 说明逐条核对无误
- 官网 66 页构建通过，站内死链 0、无效 href="#" 0
- styles.css 改动后内容 hash 已变（?v=786ad3f27f），边缘缓存不会喂旧 CSS
- audit 170 pass / 0 fail；verify-release 115 pass / 0 fail
 2026-09-02 18:03:43 +08:00
AI不止语
e77aaf6601 feat(sponsors): 新增旗舰赞助商 Infistar.cc 无限星河 
旗舰位此前一直是「虚位以待」招商卡。Infistar.cc 上旗舰位，展示形式对齐
jnMetaCode/agency-agents-zh 的旗舰版式：整块大图 banner + 独立文案段 + 福利行，
排在两个常规位之前。

## 落位

| 位置 | 呈现 |
|---|---|
| 官网赞助商页（三语） | 顶部整块 banner（1269×337）+ 定位一句话 + 简介 + 福利 + 行动按钮；「虚位以待」卡自动消失，下面两家转入「更多赞助商」 |
| 福利汇总表 | 排第一行，优惠码列为 —（推广链接自带 aff，无需手填码） |
| 两版 README | 赞助商区块顶部 `<p align="center">` 整幅 banner + 文案段 + 🎁 福利行 + `<hr>`，与参考仓库同版式 |

## 文案口径

素材原文里福利写的是占位符 `[5美元等值测试额度 / 首充专属优惠]`，二选一未定 ——
这句会直接印在 README 和官网上，跟你确认后定为**「注册并完成首次调用领 5 美元
等值测试额度」**，不写没定下来的首充折扣。其余数字均照素材原文：一个 API Key 接入
Claude / ChatGPT / Gemini / Kimi / GLM / DeepSeek，价格低至官方渠道 1 折。

推广链接发版前实测 200（含 www 与裸域）。

## 顺带加一条构建期门禁

旗舰卡读 `img`，常规卡读 `logo` —— 两条渲染路径要的字段不一样。把 tier 从
flagship 改成 standard 而忘了配 logo，页面上就是个静默碎图，而赞助位是付费展示位，
图挂了就是事故。

`assertSponsors()` 在构建期校验三件事：字段按 tier 齐全、素材文件真的存在、
三语文案不缺。反向验证过 —— 把 img 改成不存在的文件、把 tier 改成 standard，
构建各自直接失败并指名道姓报出缺什么。

赞助素材规格说明（官网赞助 FAQ 三语 + site/README.md）同步更新为旗舰 1269×337 /
常规 800×368，并写明常规位还需方形小图标。

## 验证

- 官网 66 页构建通过，三语赞助页均渲染旗舰卡、「虚位以待」卡消失、福利表首行正确
- 全站链接扫描：站内死链 0、无效 `href="#"` 0；banner 落盘 dist 并本地预览 200
- README 引用的 3 个本地素材全部存在
- audit 170 pass / 0 fail；verify-release 115 pass / 0 fail（外链验活覆盖了新增的
  infistar.cc 推广链接）
- CI 等价检查 + tests/kimi · pi · opencode · brainstorm-server 全 PASS
 2026-09-02 17:46:29 +08:00
AI不止语
d937312202 chore(release): v1.7.11 —— 剩下没查过的工具全查完了，又是四款「装了完全不生效」 
v1.7.10 查出三款装错，当时的结论是「既然错过一次，就该问一句还有几个」。这一版
把剩下的逐款对官方文档核完（拿不到文档的对源码）。

答案：又是四款装了完全不生效，全部是我们自己写的路径、全部没查过官方文档。

## 必须重装的六款

| 工具 | 问题 |
|---|---|
| Codex CLI | 项目级装到 `.codex/skills`，官方扫描清单里从来没有这个目录 |
| VS Code (Copilot) | 20 个文件 Copilot 一个都不读，且不写任何引导 |
| Windsurf | `--global` 装到 `~/.windsurf/skills`，官方是 `~/.codeium/windsurf/skills/` |
| DeerFlow | 检测标记 `deer_flow` 在真实仓库里不存在，从没被自动检测到过 |
| Qwen Code | 无 bootstrap（skill 是死重）；文档还把它跟通义灵码搞混了 |
| Claw Code | 无 bootstrap、且是 23 款里唯一没有安装文档的一款 |

## 其余

- CodeBuddy / CodeArts 拿到官方用户级路径出处，补 `--global`（全局支持 9 → 11 款）
- 4 条死链，其中 2 条是编造出来的仓库地址（`anthropics/openclaw`、
  `anthropics/antigravity` 都不存在）
- 官网工具墙停在 20 款：Cline / Kilo Code / Crush 的用户在下拉里找不到自己的工具；
  skill 详情页 6 条死链；新增赞助商页
- 5 条新门禁，全部做过反向验证：全局落盘位置、外链验活、官网工具列表条目数、
  官网全局清单覆盖、两条 shell 静默失效坑

## 版本号

`v1.7.11 起…` 这句话此前散在 8 处文档里，而 package.json 还停在 1.7.10 ——
用户装到的版本里根本没有那些修复。7 个声明文件经 scripts/sync-plugin-version.js
同步到 1.7.11，两版 README 的更新亮点块换成本版内容。

## 发版前全量验证（全绿）

| 项 | 结果 |
|---|---|
| `scripts/audit.sh` | 170 pass / 0 warn / 0 fail |
| `scripts/verify-release.sh` | 115 pass / 0 fail |
| CI 等价检查（frontmatter / package.json / --help） | 20 skills 0 error，v1.7.11 |
| tests/kimi · pi · opencode · brainstorm-server | 全 PASS（6 / 1 / 32 用例） |
| 官网 66 页构建 + 全站链接扫描 | 站内死链 0，无效 `href="#"` 0 |
| 官网给出的 23 条安装命令逐条实跑 | 19 款自动检测 + 4 款显式命令，各装 20 skills ✓ |
 2026-08-28 22:37:53 +08:00
AI不止语
c7713cac65 fix(verify-release): 429 被判成死链 —— 外链门禁开始误报自己人 
发版前跑 verify-release，H 段报 `死链（429）: https://windsurf.com`。手工用浏览器
UA 复核了几次，稳定 429 —— 站点活着，只是对反复验活限流。

判活口径写的是 `2*|3*|403`，把「服务器答复了但不是 200/403」一律当死。而 429 恰恰
证明 URL 存在：能限流就是能路由到资源。

这条门禁自己的立项理由是「一个会误报的门禁比没有门禁更糟：人会学会忽略它」。
它现在正在做那件事：唯一的 FAIL 每次都是同一条误报，跑几次就会开始忽略整段输出。

判活口径改为 `2*|3*|401|403|405|429` —— 都属于「答复了，只是不欢迎自动化访问」：

| 码 | 含义 | 为什么不是死 |
|---|---|---|
| 401 | 要登录 | 资源存在，只是要凭证 |
| 403 | 拒爬虫 | 原本就在白名单里 |
| 405 | 不认这个请求方式 | 服务器识别了这个路径 |
| 429 | 限流 | 能限流就是能路由到资源 |

真正的死仍然只有两种：404/410，以及连不上（curl 返回空）。

双向验证：
- 往 docs/README.aider.md 塞一条 github.com/anthropics/this-repo-does-not-exist-xyz，
  门禁照报 `死链（404）`，FAIL 1 —— 没被这次放宽削弱
- 还原后 115 pass / 0 fail
 2026-08-28 22:37:33 +08:00
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不止语
c68725b4f6 feat(site): 导航栏补当前页高亮，赞助商入口不额外加粗 
导航此前没有任何当前页标识。参考站看着「赞助商」更重，是因为停在
该页时的 active 态（其导航项统一 font-medium，active 只把颜色从
muted 提到 foreground，字重不变），并非给赞助位单独加粗。

照此实现：停在 /sponsors 时该项颜色提亮 + aria-current="page"，
其余情况与其他导航项完全一致。不给商业位额外字重——导航里单独加粗
一项会被读成「当前页」，点进去发现不是反而困惑。

三语页面同步生效。
 2026-08-18 19:30:31 +08:00
AI不止语
ae316d87f3 feat(site): 新增赞助商独立页；顺带修掉三处一直坏着的链接 / 布局 
官网此前一条赞助商内容都没有。这一版把赞助内容全部收敛到独立页
/sponsors（中 / EN / 繁三语各一份），首页不放任何赞助位，入口进导航栏。

赞助商页结构：Hero → 旗舰位 → 当前赞助商 → 专属福利汇总 → FAQ →
赞助权益 → CTA。

- 分档由数据驱动：SPONSORS 里 tier: 'flagship' 的用大 banner 单独成块
  （读 img），其余是紧凑卡（读 logo，简介 CSS 截 4 行）；当前无 flagship，
  该区块渲染成「虚位以待」招商卡
- 紧凑卡的简介可展开：JS 比对 scrollHeight/clientHeight，只有真被截断
  时才显示「展开全部」，避免出现点了没反应的死按钮
- 福利汇总表里的优惠码点一下即复制，复用站内已有的 copy 委托，未新增
  第三方依赖
- Hero 原文案写「不做付费墙也不接广告」，但赞助位本身就是付费展示位，
  自相矛盾。改为如实说明；外链一律 rel="sponsored nofollow noopener"

顺带修掉三处做入口时发现的老问题（都是线上正在坏的）：

- 每个 skill 详情页的「← 返回全部 Skill」是 404：链接写的 index.html，
  从 /skills/xxx 解析成 /skills/index.html —— 该文件不存在。实测线上
  同样 404。60 个详情页全中，已改 ../index.html
- EN / 繁體页面的导航与品牌链接全部跳回中文首页：base 原本按「相对站点
  根」算，/en/index.html 的导航是 ../index.html。已改为相对当前语言根
- 导航栏在 900px 以下挤成两三行（「支持工具」被竖排拆开）：原来跟着
  720px 断点走，721–900px 这段一直是坏的。现改为导航项永不折行 + 独立
  900px 断点 + 窄屏横向滚动

赞助商图标取自 ao.aiolaola.com（同一维护者的站、同一批赞助商）。
 2026-08-18 18:56:03 +08:00
AI不止语
747cfa4a0d docs(readme): 更新亮点从 17 条砍到 4 条，其余回归 Release Notes 
README 顶部的「更新亮点」是历次发版累积出来的，已经混进 Cline/Kilo
Code（v1.7.6）、Windows bootstrap（v1.7.3）等好几个老版本的条目，共 17
行，把「这是什么 / 怎么装」整段推到首屏之外。

现在只留需要用户动手的 4 条（Aider / Kiro / Hermes 请重装 + 新增
Crush），末尾一行指向 RELEASE-NOTES.zh.md。删掉的 13 条逐条核对过，在
RELEASE-NOTES.zh.md 里全都有，没有信息丢失。

简繁两版同步。
 2026-08-18 18:55:42 +08:00
AI不止语
fb63548c9d fix(installer): Codex 项目级装到 Codex 从不扫描的目录；CodeArts 补 --global 
## Codex：项目级又是「装了完全不生效」

官方 skills 文档（developers.openai.com/codex/skills，现 308 跳到官方新文档站）
给出的扫描目录**完整清单**：

    $CWD/.agents/skills、$CWD/../.agents/skills、$REPO_ROOT/.agents/skills
    $HOME/.agents/skills、/etc/codex/skills、内置 skill

**没有 .codex/skills。** 两次分别追问确认「.codex/skills 是否曾被扫描」，答案都是
从未出现。而我们项目级正是装到 .codex/skills。

全局（~/.agents/skills）一直是对的 —— 原注释也写明了「不是 ~/.codex/skills」，
说明当初查过全局却没顺手核项目级。改为 .agents/skills，并在安装时清理旧位置
（只清我们装的那些，用户自己放在 .codex/skills 下的不动，已实测）。

与 Antigravity 共用 .agents/skills 是 Agent Skills 开放约定，不是冲突。

## 这个改动暴露出一个既有 bug：检测有顺序依赖

改完后测试立刻报「检测 .codex/ -> 得到「Antigravity,Codex CLI」，期望「Codex CLI」」。

根因：自动检测是**边装边判**的。Codex 装到 .agents/skills 会创建 .agents/，
循环走到 Antigravity（detect: '.agents'）时它就被误判为「项目里有这个工具」，
于是多装一份。这个坑在任何「装了 A 会创建 B 的检测标记」的组合上都会犯。

改为先把所有工具的检测结果一次性算完再开始装 —— 检测必须基于**安装前**的项目
状态。实测：只有 .codex 时只装 Codex；同时有 .codex 与 .agents 时两款都装且
.agents/skills 下仍是 20 个（不重复）。

## CodeArts：官方已证实用户级路径，补上 --global

原注释只写「用户在 #20 确认」，没有官方出处。已补华为云官方用户指南出处：

    项目级：项目根目录的 ./.codeartsdoer/skills/
    个人级：%USERPROFILE%/.codeartsdoer/skills   即 ~/.codeartsdoer/skills

既然已证实，--global 从拒绝名单移出并加落盘断言。实测装 20 个到
~/.codeartsdoer/skills、卸载后 HOME 零残留。仍是 skills-only —— 其 bootstrap
约定未证实，不猜。

## 顺带核实

- Cursor：官方 skills 文档确认 .cursor/skills/<name>/SKILL.md ✅
- OpenCode：官方 skills 文档确认项目级与全局都对 ✅（唯二全对的之一）
- Kimi / Pi：不在 TARGETS 里，走 plugin manifest 与扩展分发；已确认 docs 没有
  承诺 --tool kimi/pi，installer 也正确拒绝这两个名字，无虚假承诺

audit 168 pass / 0 warn / 0 fail；verify-release 115 pass / 0 fail。
 2026-08-13 05:54:52 +08:00
AI不止语
0e3fbc4830 fix(installer): VS Code 装的 20 个文件 Copilot 一个都不读（又一个纯死重） 
## 问题

官方文档（code.visualstudio.com/docs/copilot/customization/custom-instructions）
明确 Copilot 只自动读这几处：

    .github/copilot-instructions.md / AGENTS.md / CLAUDE.md   （始终生效）
    .github/instructions/*.instructions.md                    （按 applyTo 匹配）

而我们把 20 个 skill 拷进 `.github/superpowers/` —— **不在其中**，而且装完
**什么引导都不写**。也就是说 VS Code 用户装完，Copilot 一个字都不会读。

旧文档更说明问题：它写着「由于 Copilot 主要通过单个指令文件工作，建议创建
.github/copilot-instructions.md 引用 skills」并给了示例 —— 我们知道需要引导，
却让用户自己动手，而绝大多数人不会照做。

## 改法

自动生成 `.github/instructions/superpowers-zh.instructions.md`：

    ---
    applyTo: "**"          # 关键：省略则只能手动挂载 = 白写
    name: Superpowers-ZH
    description: …
    ---

约 4.5 KB 的索引（核心规则 + 20 个 skill 触发条件表），正文仍留在
`.github/superpowers/` 按需读取 —— 与 Cline / Kilo / Kiro 同一套思路：applyTo "**"
的文件对每个请求都生效，正文塞进去就是每轮常驻开销。

**刻意不动用户的 .github/copilot-instructions.md** —— 那是他们的文件。用我们自己
的 .instructions.md，互不干扰，卸载也能精确删除。

检测标记补上 `.github/instructions`（用了 instructions 机制的项目都有），原来只认
`.github/copilot-instructions.md`。

## 顺带核实的两款

- **Cursor**：cursor.com/docs/skills 确认 .cursor/skills/<name>/SKILL.md 启动时
  自动发现 —— 我们是对的。
- **OpenCode**：opencode.ai/docs/skills 确认 .opencode/skills/ 与
  ~/.config/opencode/skills/ —— 项目级和全局都对。它同时扫 .claude/skills 与
  .agents/skills，已在注释里写明「装过 CC 或 Antigravity 的别重复装」。

## 验证

- 装：正确识别 -> 生成 instructions（applyTo "**"，4503 字节）+ skills 到
  .github/superpowers/
- 卸载：只删我们的，用户的 my-own.instructions.md 与 copilot-instructions.md
  原样保留
- verify-release 新增 VS Code 段（文件存在 / applyTo 断言 / 20 行索引 / 指向
  .github/superpowers/），111 -> 115 pass
- audit 168 pass / 0 warn / 0 fail
 2026-08-12 21:03:40 +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不止语
226638b969 feat(installer): Claw Code 补 bootstrap + 文档；CodeBuddy 补 --global（官方已证实） 
核查最后两款。这两款的**路径都是对的**，问题在缺失的能力和文档。

## Claw Code

路径拿到了源码级证据（ultraworkers/claw-code）：
- rust/crates/plugins/src/lib.rs 明写 "discovers skills from local roots such as
  `.claw/skills`, `.omc/skills`, `.agents/skills`, `~/.omc/skills` …"
- USAGE.md 列出根指令文件优先级 CLAUDE.md > CLAW.md > AGENTS.md

三处缺口：

**① 没写 bootstrap。** 只装 skills，CLAW.md 一个字都没写 —— 与 Qwen Code 同款
问题，skill 能被发现但不会自动触发。已补 generateClawBootstrap。

**② 一个真实的遮蔽陷阱。** 因为优先级是 CLAUDE.md > CLAW.md，项目里若已有
CLAUDE.md（不少工具都会生成它），就可能压过我们刚写的 CLAW.md，表现为「装了
不触发」。安装器现在检测到这种情况会主动提示，并给出解法（让 CLAUDE.md 也带
引导）。这种坑不说清楚，用户只会以为我们的东西不好使。

**③ 23 款工具里唯一没有安装文档的一款。** 已补 docs/README.claw.md，含上面两条
源码出处、遮蔽陷阱说明，以及一条实用提醒：claw 也扫 .agents/skills，装过
Antigravity 的项目其实已经能读到，再装会加载两份。

## CodeBuddy

路径和 bootstrap 都对（官方 codebuddy.cn/docs/cli/skills 与 /codebuddy-dir 确认
.codebuddy/skills/ + CODEBUDDY.md）。但我们的文档写着：

> 目前仅支持项目级安装。CodeBuddy 的用户级（全局）skills 加载路径尚未验证。

现已核实 —— 官方目录结构文档确认全局与项目级同构：

    skills   ~/.codebuddy/skills/       .codebuddy/skills/
    记忆文件  ~/.codebuddy/CODEBUDDY.md   项目根 CODEBUDDY.md（两处等价）
    优先级   项目级 > 用户级 > 插件级

已补 --global 支持：TARGETS 加 global、bootstrap 支持 isGlobal（全局写
~/.codebuddy/CODEBUDDY.md）、全局卸载清单加上它。文档链接一并从
copilot.tencent.com 换成官方文档域名 codebuddy.cn。

## 验证

- Claw 项目级：装 -> CLAW.md 生成 -> 卸载零残留；已有 CLAUDE.md 时正确给出提示
- CodeBuddy 全局：装到 ~/.codebuddy/skills + ~/.codebuddy/CODEBUDDY.md，
  bootstrap 内容指向 ~/.codebuddy/skills/，卸载后 HOME 零残留
- CodeBuddy 项目级不受影响，仍指向 .codebuddy/skills/
- verify-release 白名单 codebuddy 由「应拒绝」移到「应成功」，110 pass / 0 fail
- audit 167 pass / 0 warn / 0 fail（新增 docs/README.claw.md 进交叉引用检查）
 2026-08-12 19:48:14 +08:00
AI不止语
49c2e3a205 fix(installer): DeerFlow 检测标记不存在（Aider 同款）+ 文档里一个查无实据的环境变量 
## 安装路径是对的

官方文档（bytedance-deer-flow.mintlify.app/concepts/skills）确认 DeerFlow 自动
扫描两个**写死**的目录找 SKILL.md：

    for base_dir in ["skills/public", "skills/custom"]:

public 是自带的、进 git；custom 是用户装的、默认被 gitignore。无任何配置项。
我们装到 skills/custom/ 是对的。

## 但检测标记从来没匹配过

detect 写的是 deer_flow —— 用 GitHub API 列了 deer-flow main 分支的顶层目录：

    .agent .github backend contracts deploy docker docs frontend plans
    pr-build scripts skills tests

**没有 deer_flow。** 跟 Aider 的 .aider 是同一个毛病：真实检出从来没被自动检测
到过，用户必须手动 --tool deerflow。

改认 skills/public —— 它是 skills 机制本身、随仓库版本控制，任何 DeerFlow 检出
都有；deer_flow 保留作 1.x 兼容。实测模拟真实检出（skills/public + backend +
frontend）能正确识别为 DeerFlow 并装进 skills/custom/。

## 文档里一个查无实据的环境变量

旧文档给了 `export DEERFLOW_SKILLS_DIR=...` 的写法，容易被读成「DeerFlow 认这个
环境变量」。官方文档里没有它，目录是写死的。已删除，改为直接用绝对路径。

顺带补上原文档没说的两件事：容器挂载（skill 在沙箱里跑，两个目录挂到
/mnt/skills/，附属脚本要写容器内路径），以及由此带来的限制 —— brainstorming
的可视化伴侣是宿主机 harness 用的，在 DeerFlow 容器沙箱里不可用。

## 验证

- 模拟真实 DeerFlow 检出：自动识别 -> skills/custom/
- 卸载精确：只删我们装的 20 个，skills/public/ 与用户自建的 custom skill 不动
- verify-release B 段补 skills/public 标记，109 -> 110 pass
- audit 166 pass / 0 warn / 0 fail
 2026-08-12 19:42:04 +08:00
AI不止语
033adc3768 fix(docs): 4 条死链，其中 2 条是编造的仓库地址；新增外链验活门禁 
核查 OpenClaw 时发现 docs/README.openclaw.md 链的是
github.com/anthropics/openclaw —— **那个仓库不存在（404）**，真正的是
openclaw/openclaw。顺手全仓扫了一遍外链，45 条里 4 条是死的。

## 修掉的 4 条

| 原链接 | 状态 | 改为 |
|---|---|---|
| github.com/anthropics/openclaw | 404，仓库不存在 | github.com/openclaw/openclaw |
| github.com/anthropics/antigravity | 404，且 Antigravity 是**谷歌**的产品不是 Anthropic 的 | antigravity.google |
| huaweicloud.com/product/codeartsdoer.html | 404，产品页改版 | codearts.huaweicloud.com |
| docs.codeium.com/windsurf | Windsurf 已从 codeium.com 迁走 | docs.windsurf.com/... |

前两条是**编造出来的出处**。这比没有出处更坏：它让人以为核实过了。

## OpenClaw 本身：路径是对的

顺带核实完了。docs.openclaw.ai/tools/skills 确认 `<workspace>/skills` 为最高
优先级、`~/.openclaw/skills` 为全局，自动发现无需配置，与我们装的一致。

## 固化成检查（verify-release H 段）

编造链接不该靠人肉发现。新增外链验活，两遍制：

- 第一遍 xargs -P 10 并行快扫，只产出「嫌疑名单」，**不下结论**
- 第二遍对嫌疑名单串行复核，放宽到 25s 并让 curl 自己重试；两遍都判死才算死

两遍制不是过度设计 —— 第一版单遍串行把整个脚本拖到超时跑挂了；改并行后又实测
到 docs.codeium.com 在 8s 上限下偶发超时、误报成死链。**一个会误报的门禁比没有
门禁更糟：人会学会忽略它。** 连跑 3 次确认稳定，全绿。

无网络时整段跳过，不阻塞离线发版。

顺带修了个 bash 坑：`bad "死链（$code）: $u"` 里全角括号会被当成变量名的一部分，
报 `code�: unbound variable`。改用 ${code} 花括号界定。

双向验证：塞一条 github.com/anthropics/this-repo-does-not-exist 会被抓出并 FAIL，
移除后恢复全绿。

verify-release 108 -> 109 pass；audit 166 pass / 0 warn / 0 fail。
 2026-08-12 19:34:16 +08:00
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不止语
d83d3f9dc2 chore(release): v1.7.10 —— 工具支持层系统核查：Aider / Kiro / Qoder 三处修正 
版本号：7 份声明文件 1.7.9 -> 1.7.10。包内文件 109（无增减）。

内容见 RELEASE-NOTES.zh.md v1.7.10 条目。起因是 v1.7.9 修 Hermes 时发现我们
从支持它起就装错了目录 —— 既然错过一次，就该问「还有几个」。答案是又查出三个，
全部是我们自己那层写的、全部没查过官方文档：

- Aider：检测标记 .aider 目录根本不存在（真实项目从没被检测到过），且
  CONVENTIONS.md 不会被自动加载（官方要求 --read）。两错叠加 = 完全不可用。
- Kiro：steering 每轮常驻，我们把 20 个 skill 正文全塞进去 —— 实测 335 KB/轮。
  改索引式后 4.4 KB，76 倍；升级时自动清旧布局（不清等于没修）。
- Qoder：subagent 映射表 4 行错 2 行，且没标适用范围（只覆盖 CLI，IDE 不同）。

同时堵上测试盲区：Aider 那个 bug 能在 90 项全绿下活着，是因为测试写的是
mkdir .aider 再断言认出 Aider —— 拿代码测代码。已补真实标记与 Kiro 两条硬
回归守卫，verify-release 90 -> 101 pass。

发版前门禁
- audit.sh 166 pass / 0 warn / 0 fail
- verify-release.sh 101 pass / 0 fail
- dry-run：1.7.10 / 109 文件
v1.7.10 		2026-08-12 19:07:14 +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不止语
d544eb5505 fix(refs): qoder-tools.md 的 subagent 表有错且未标适用范围（#119） 
## 起因

#119 报告：Qoder IDE 里跑 subagent-driven-development，Qoder 说它只有
CodeReview subagent、没有 general-purpose。查我们自己的 qoder-tools.md，
第 21 行白纸黑字写着 general-purpose 存在。

查 3202b18（该文件的引入 commit）—— **没有引用任何来源**，那张 agent 类型表
是我们自己写的。这跟 #45 的 Hermes 是同一类问题：断言了一个没核实过的能力。

## 逐条核对官方文档后的结果

对照 docs.qoder.com/zh/cli/subagent，表里 4 行错了 2 行：

| 原写法                      | 文档实际           |
|-----------------------------|--------------------|
| Explore -> explore-agent    | Explore（同名）    |
| Plan -> plan-agent          | Plan（同名）       |
| general-purpose             | ✅ 确实存在        |
| claude-code-guide -> qoder-guide | ✅ 确实存在   |

另外「Qoder 额外有 browser-agent、code-reviewer、design-agent」这句：文档里
**没有内置的 code-reviewer**（出现的 api-reviewer 是用户自建 subagent 的示例），
另两个也查无实据。已删掉，改为指向 requesting-code-review 的模板。

## 最关键的一处：表根本没标适用范围

官方 subagent 文档只覆盖 **Qoder CLI**，没有说这套内置集合同样适用于
**Qoder IDE**。而我们的表不带任何产品面标注，IDE 用户读它就当成了权威。
#119 报的正是 IDE 上的情况。

已加：适用范围标注（Qoder CLI）、来源链接、核对日期，以及一节说明 IDE 与
CLI 的差异 —— 并明确告诉用户 IDE 上「找不到 general-purpose」是预期内差异、
不是装错了，Qoder 的自动降级本身是合理适配。

## 范围

qoder-tools.md 是 fork 自有文件（上游没有），零上游偏离。
文件上半部分的工具名对照表（Read/Write/Bash/EnterSpecMode 等）同样没有出处，
本次未动 —— 没有证据就不改，已在 issue 里说明这是已知的遗留风险。

audit.sh 166 pass / 0 warn / 0 fail
 2026-08-12 17:08:54 +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 文件
v1.7.9 		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不止语
f290def463 chore(release): v1.7.8 —— 定位核查：修掉 5 处对上游的偏离并加检查固化 
版本号：7 份声明文件 1.7.7 -> 1.7.8。包内文件 108 -> 109（antigravity-tools.md）。

内容见 RELEASE-NOTES.zh.md v1.7.8 条目。要点：按「只是翻译上游 + 增加更多
工具支持」这个定位逐层核查，查出 5 处偏离（缺文件、漏同步 3 个 commit、
漏译 2 节、编号缺陷、增量插在上游步骤中间），全部修掉；并新增 audit 3c-bis
把「fork 增量必须显式声明」变成可执行检查。

发版前门禁
- audit.sh 166 pass / 0 warn / 0 fail
- verify-release.sh 90 pass / 0 fail
- dry-run：1.7.8 / 109 文件
v1.7.8 		2026-08-08 14:30:03 +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不止语
3f6ffd5d4d fix(skills): 定位核查 —— 补回 4 处「不是增量」的对上游偏离 
按「我们只是翻译上游 + 增加更多工具支持」这个定位做逐层核查，结果发现
4 处偏离**不属于增量，而是缺失或漏同步**。核查方法与结论都记在下面。

## 核查方法

1. 文件级：上游 skills/ 与我们逐文件比对，分出「仅上游有」「仅我们有」
2. 内容级：14 个翻译 skill 各自比对标题数（排除代码围栏）、表格行数、列表项数
3. 逐个追查每处差异的来源：是声明过的 fork 增量，还是漏译/漏同步

## 修掉的 4 处

① antigravity-tools.md 上游有、我们没有
   而 installer 里明明支持 Antigravity —— 该工具用户拿不到任何工具映射。
   影响是实质的：Antigravity 没有 todo 工具（manage_task 管的是后台进程），
   没这份映射，所有说「创建待办」的 skill 在它上面都会走偏。
   已翻译补入，并在 using-superpowers 的平台适配清单里按上游同序列出。

② finishing-a-development-branch 漏同步 3 个 commit
   C 块时我的 commit 清单不全，漏了 fbb6dba / bcfe798 / 9dff1a9。其中
   9dff1a9 是**行为变更**：上游把菜单从 4 个选项减为 3 个，删掉了「丢弃这份
   工作」这一项，丢弃改为只在人类伙伴明确提出时才走的独立小节；基础分支
   判定也从盲跑 merge-base 改为「先确认，合并到错分支代价很高」。
   我们的文件已把 D 块修复织进旧结构，故照上游当前状态整体重译 ——
   上游 main 已含全部 4 个 commit，一次到位。已断言 D 块修复完整保留
   （WORKTREE_PATH 仅在步骤 2 计算一次 + 那条显式警告）。

③ writing-plans 漏译整节
   上游有 Task Right-Sizing 与 Bite-Sized Task Granularity 两节，我们只有后者。
   缺的那节讲的是任务边界怎么划（能独立承载一轮测试循环、值得一个全新
   审查者把关的最小单元），已补译为「任务粒度定界」。

④ writing-skills 三个问题
   - 漏译 H2 整节 Match the Form to the Failure（让形式匹配失败类型）——
     内容是「哪类基线失败该用哪种形式」，含禁令在塑形类问题上会反噬的实测结论
   - 漏译 H3 Micro-Test Wording Before Full Scenarios（先做措辞微型测试）
   - 编号缺陷：两个连续小节都编号为 4（应为 4、5）
   - 节名仍是过时的「Claude 搜索优化（CSO）」，上游早已改名
     Skill Discovery Optimization (SDO)，正文两处引用一并同步

## 核查后的定位现状

纯增量部分（符合定位）：
- 6 个 fork 专属 skill：chinese-* ×4 + mcp-builder + workflow-runner
- 3 个 fork 专属 references：copilot / hermes / qoder（我们支持的 harness，上游不支持或已删）
- using-superpowers 的「中国特色技能路由」一节

14 个翻译 skill 的标题数现在 13 个与上游精确一致，唯一例外是
using-superpowers（+1，即上面那节声明过的增量）。

## 仍存在、需维护者决定的一处（本提交未动）

executing-plans 有一个 fork 自加的「步骤 3：处理常见异常」（上游只有 3 步，
我们是 4 步），内容是测试失败三分诊断、依赖缺失、指令不清的处理；
另外 Remember 多一条「每个任务单独提交，commit message 引用任务编号」。

这两处是内容层面的自主增补，不在「翻译 + 工具支持」的定位之内。它们本身
有用，但会让每次上游改动该节都要人工调和。留给维护者判断是保留（并在
README 里声明）还是回归上游。

验证：audit.sh 152 pass / 0 warn / 0 fail、verify-release.sh 90 pass / 0 fail
 2026-08-08 07:03:52 +08:00
AI不止语
5b54fc4b53 chore(release): v1.7.7 —— 新增 Crush（23 款工具）+ 测试覆盖盲区修补 
版本号：7 份声明文件 1.7.6 -> 1.7.7。包内文件 107 -> 108（docs/README.crush.md）。

内容见 RELEASE-NOTES.zh.md v1.7.7 条目。

发版前门禁
- audit.sh 152 pass / 0 warn / 0 fail
- verify-release.sh 90 pass / 0 fail（覆盖从 82 项提升）
- dry-run：1.7.7 / 108 文件
v1.7.7 		2026-08-08 06:15:40 +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不止语
d1ac51e450 chore(release): v1.7.6 —— 上游 v6.2.0 对齐完成，漂移告警清零 
版本号：7 份声明文件 1.7.5 -> 1.7.6（只动 "version" 行）。

C 块（说服性段落 -> rationalization 表）收尾，#19 的 A/B/C/D 四块全部完成。
scripts/audit.sh 的上游结构漂移告警从 3 条降到 0 条。

内容见 RELEASE-NOTES.zh.md v1.7.6 条目。要点：盘点先行发现 14 个
refactor commit 里有 3 项是实质改动而非风格瘦身（新增 rationalization 表、
executing-plans 加隔离工作区步骤、using-git-worktrees 规则等价压缩），
其余各项逐条核实规则在别处仍在之后才删。

发版前门禁
- audit.sh 150 pass / 0 warn / 0 fail
- verify-release.sh 82 pass / 0 fail
- 行为 eval 两轮共 11 题全对（专门考被删段落里的规则是否仍生效）
- dry-run：1.7.6 / 107 文件 / 468.6 kB
v1.7.6 		2026-08-08 00:22:39 +08:00
AI不止语
02d255102c refactor(skills): 同步上游 C 块 —— 说服性段落改为 rationalization 表（#19 收尾） 
对齐上游 14 个 refactor commit 中尚未同步的 11 个（另 3 个已随 A/B 块完成）。
audit 上游结构漂移告警由此清零：150 pass / 0 warn / 0 fail。

## 盘点先行：不是所有改动都是风格性的

C 块开工前做了逐 commit 盘点，判定标准定为「删掉的文字里有没有别处没写的
规则」。结论纠正了我之前的假设 —— 其中 3 项是实质改动，不是纯瘦身：

- cfb6281 新增了一张 rationalization 表（2 行全新规则），替换掉
  「与工作流的集成」那份工作流清单
- 03147d2 给 executing-plans 加了「先确保隔离工作区」作为步骤 1
  （SDD 那一半已随 A 块完成）
- bc86802 把「常见错误」5 个小节 + 「红线」Never/Always 双清单压成 5 行表，
  规则一条不少 —— 这也是此前唯一有客观漂移证据的 skill

## 逐项核实后才删

每处删除都先确认规则在别处仍在：
- receiving-code-review「底线」：概述已有「核心原则：先验证再实施。先提问再假设」
- writing-skills「总结」：铁律节 + TDD 循环表已完整承载
- writing-plans「注意事项」：精确路径 / Run: / 预期输出 三条都内建在任务结构
  模板里 —— 上游是把「告知」改成「示范」
- brainstorming「核心原则」6 条：5 条已在流程详述里逐条体现（每次一个问题、
  优先选择题、2-3 种方案、增量验证、回头澄清），YAGNI 按上游移到「探索方案」
  的使用现场
- systematic-debugging / dispatching-parallel-agents / verification-before-completion
  删的是「实际效果」「核心优势」「为什么这很重要」这类社会证明与说服段，
  核心原则行全部保留
- systematic-debugging 的「相关技能」块折入第四阶段「验证修复」
- executing-plans 删掉的质量宣称按上游改写为平铺的平台清单

## 验证

结构
- 10 个 skill 的 H2 数与上游逐一对齐（8 个完全相同、2 个差 1）
- executing-plans / using-git-worktrees / requesting-code-review 的
  superpowers: 引用集与上游完全一致

行为 eval —— 两轮共 11 题全对
专门考被删段落里的规则是否仍生效：
- 原生 worktree 工具 vs git worktree add（答出「第一大错误」与「幽灵状态」）
- 跳过 check-ignore 的后果、目录名优先级顺序
- 基线测试失败能否继续、能否无证据宣称完成
- 审查建议技术上有疑问时该照做还是反驳
- 能否先打补丁再查根因
- 能否自己读 diff 代替派审查者（命中 cfb6281 新增的表行）
- 方案里的「以后可能用得上」功能怎么处理（命中 YAGNI 的新落点）

回归：audit.sh 150 pass / 0 warn / 0 fail、verify-release.sh 82 pass / 0 fail

注：audit PASS 由 152 降至 150 —— 上游有意删除的两个「集成」节里各有
superpowers: 引用，Category 4b 因此少 2 项检查；引用集已核对与上游一致。
 2026-08-08 00:21:39 +08:00
AI不止语
9022c6fcc0 chore(release): v1.7.5 —— 上游 B + D 块（worktree bug、Gemini 勘误、测试参考重构） 
版本号：7 份声明文件 1.7.4 -> 1.7.5（只动 "version" 行）。

内容见 RELEASE-NOTES.zh.md v1.7.5 条目。三项面向用户的实质改动：

1) worktree 清理静默空转（真 bug，已复现验证）
2) 更正「Gemini 不支持子智能体」的错误说法 —— 原说法会让 3 个 skill
   在 Gemini CLI 上瘸腿
3) testing-anti-patterns.md -> writing-good-tests.md：5 个反模式清单
   重构为两条原则 + 变异检查

外加 audit 结构漂移度量修正（此前把围栏内 shell 注释当标题，虚报了 2 条
假阳性漂移；#19 里引用的欠账数字此前是虚高的）。

发版前门禁
- audit.sh 152 pass / 1 warn / 0 fail（唯一 warn 是 using-git-worktrees 真漂移）
- verify-release.sh 82 pass / 0 fail
- 行为 eval 8/8（B 块）
- 包内容核对：writing-good-tests.md 已入包、testing-anti-patterns.md 已移除、
  re-review-prompt.md 在包内
- dry-run：1.7.5 / 107 文件 / 468.1 kB
v1.7.5 		2026-08-07 23:35:09 +08:00
AI不止语
2b1ced6365 feat(tdd): 同步上游 B 块 —— testing-anti-patterns 重构为 writing-good-tests（#19） 
对齐上游 5 个 commit（e74961c / 9d8630d / e8a9748 / 50025d1 / caa1826 / 517a9c6）。
我们的 testing-anti-patterns.md 是上游 v6.1.1 的纯翻译（「铁律」= The Iron Laws，
非 fork 自加），因此整体重译为新文件。

## 从「5 个反模式清单」重构为「2 条原则」

上游把 299 行的反模式枚举（测 mock 行为 / 生产类加测试方法 / 不懂依赖就 mock /
不完整 mock / 集成测试事后补）重写为 198 行的两条原则：

- 原则 1「点名它要抓的破坏」：写测试体之前先答"什么生产改动会让它失败，那是
  bug 还是决定"。含镜像断言、变更探测器、测行为不测文本、测你的代码不测框架
- 原则 2「跑真东西」：mock 不配拥有断言、在正确层级 mock、替身要具体、
  完整镜像真实数据、生产类只承载生产方法、宁可真实组件也不要复杂 mock
- 新增「变异检查」：收尾前在脑中变异生产代码，每种现实变异都应至少让一个测试失败
- 触发条件放宽：从"添加 mock 或测试工具时"扩到"编写或修改任何测试时"

## TDD SKILL.md 三处同步

- 删掉「为什么顺序很重要」整节长散文，替换为指向 writing-good-tests.md 的
  四条短指引（上游 b9e75dd 把这些论点折进了合理化借口表）
- 合理化借口表 5 行按上游扩写，把被删散文的论点吸收进「现实」列
- 删掉末尾「测试反模式」一节（引用的文件已不存在）
- git rm testing-anti-patterns.md，全仓确认无残留引用

## 验证

结构与完整性
- 两个文件章节均与上游一一对应
- writing-good-tests.md 指标与上游精确一致：12 个 bold 要点 / 11 行快速参考
  表格 / 11 条危险信号；14 项代码标识记号（buildSearchQuery、MAX_RETRIES、
  ToolCatalog、vi.mock、destroy() 等）全部存在

行为 eval —— 8 个判断场景
先跑了一次意外有价值的对照：agent 因权限拿不到 writing-good-tests.md、
只能退回 SKILL.md 的四条摘要时，得分 6/8 —— 错的恰好是只存在于参考文件里的
两条规则（部分 mock 会静默失败、琐碎转发 getter 不配有测试）。
放开读取权限后重测：8/8 全对，且两题的理由直接引用了新文件的原文依据。

这说明参考文件承载着摘要覆盖不到的承重规则 —— 符合上游设计（那四条是指针
而非摘要），但值得记录：agent 读不到参考文件时，这两类判断会出错。

回归：audit.sh 152 pass / 1 warn / 0 fail、verify-release.sh 82 pass / 0 fail
 2026-08-07 23:33:39 +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不止语
eadc83b64b chore(release): v1.7.4 —— SDD 同步上游 v6.2.0（附行为 eval 证据） 
版本号：7 份声明文件 1.7.3 -> 1.7.4（只动 "version" 行，已 diff 确认）。
包内文件 106 -> 107（新增 re-review-prompt.md）。

内容见 RELEASE-NOTES.zh.md v1.7.4 条目。

按 CLAUDE.md「改 skill 需要 eval 证据」的要求，本次补了两层行为验证 ——
结构性核对不足以证明译文真的传达了新规则：

1) 新机制 7 个场景 eval：7/7 正确
   考察第 2 轮该唤回还是换新、第 4 轮模型档位、第 5 轮能否再开一轮、
   承重发现该搁置还是停下、Minor 走哪条路、遇到别的计划的账本怎么办、
   控制者能否自己修。连「运行环境无法唤回时才改派全新实现者」都答出。

2) 集成 eval：用 tests/subagent-driven-dev/go-fractals 脚手架跑真实
   执行的准备阶段，验证 agent 是否按新签名调脚本（旧习惯可能省掉 PLAN_FILE）
   - 实际调用 sdd-workspace plan.md，带上了 PLAN_FILE
   - 同时检查了 plan 作用域账本和旧扁平路径的游离账本
   - 账本第一行为正确的身份行；工作区落在 .superpowers/sdd/plan/
   - 起飞前冲突扫描产出 5 条打包成一次的提问，而非逐条打断
   - 建 10 条待办并按指令在分派实现者前停下

回归：audit.sh 150 pass / 0 fail、verify-release.sh 82 pass / 0 fail
dry-run：1.7.4 / 107 文件 / 464.0 kB
v1.7.4 		2026-08-07 22:36:38 +08:00
AI不止语
0ab24dee8e feat(sdd): 同步上游 v6.2.0 —— plan 作用域工作区 + 基于唤回的修复循环（#19 A 块） 
对齐上游 v6.1.1 -> v6.2.0 中 subagent-driven-development 的 6 个 commit
（6df8ba1 / b8a2d84 / 2dbbaed / 87e4050 / ebdd4ec / 28882fc）。

这是 #19 拆分后的 A 块。注意 v1.7.1 刚对齐过 SDD，本次是那之后的新增量。

## 为什么必须整块一起改

我们的 SKILL.md 里写的是旧脚本签名（review-package BASE HEAD）。脚本换成
plan 作用域签名后若不同步改文档，agent 会照旧签名调用直接吃 usage 错误 ——
比不同步更糟。所以脚本 + 文档 + 模板同批落地。

## plan 作用域工作区（结构性修复）

原先所有计划共用 .superpowers/sdd/ 一个目录，一份过期账本被误读成当前进度，
会让控制者跳过整段任务序列 —— 上游称这是观察到的最昂贵失败。现在每个计划
一个 .superpowers/sdd/<计划文件名>/，从结构上消除这种误读。

- scripts/sdd-workspace 改为接收 PLAN_FILE，自忽略 .gitignore 上移到
  .superpowers/sdd/；scripts/review-package 前置 PLAN_FILE 参数
- 两个脚本在我们这边与上游 v6.1.1 字节一致（从未汉化），直接取上游版
- scripts/task-brief 只手工应用上游那两处改动，保留我们的 fork 适配
  （awk 同时匹配 "Task N" 与 "任务 N"，因为本仓库 writing-plans 产出中文标题）
- 账本新增身份行 `# SDD ledger — plan: <路径>`，并明确「第一行点名别的计划、
  或旧扁平路径下的游离账本」都不是你的进度

实测（临时 git 仓库）：两个计划各得独立目录；往 A 计划写 ledger 后 B 计划
目录仍为空（关键回归）；.gitignore 落在 .superpowers/sdd/ 且 git status 干净；
中文「任务 2」经新路径抽取成功；review-package 旧签名正确报 usage 错误。

## SKILL.md 全面重写（14 章 -> 生命周期结构）

上游把平铺的 14 节重组为「任务循环」五步 + 熔断机制，Red Flags / Advantages /
Integration / File Handoffs / Durable Progress 等并入使用现场。逐节重译：

- 修复循环：一轮 = 一次修复分派 + 一次定向复审，每任务上限五轮
  第 1-3 轮唤回原实现者（context 完整），第 4-5 轮换全新实现者 + 高一档模型
- 熔断：第 5 轮仍有未解决发现则停止分派，逐条裁定 —— 搁置（附裁定）或在
  承重项上 BLOCKED。只在上限处裁定，提早裁定等于换名字的预先定性
- Minor 发现与「计划要求的」发现两条路在循环外
- 新增「常见的合理化借口」表取代原「红线」清单

新增 re-review-prompt.md（106 行全文翻译）：定向复审只核实发现是否解决 +
只看修复 diff 的新破坏，范围外观察进账本不延长循环。

implementer-prompt.md「审查发现之后」改写为基于唤回的修复轮次；
task-reviewer-prompt.md 更新脚本签名并删除被 re-review-prompt.md 取代的结尾两句。

## 顺手修掉一个既有缺陷

三个 SDD 文件末尾都残留着 `</content>` —— v1.7.1 那次重写（PR #108, d7885ca）
留下的生成产物，上游没有。这些文件会整体进 agent 的 prompt，属于污染。已全部清除，
并全仓扫描确认无同类残留。

## 验证

- 章节结构与上游 14 节一一对应；superpowers: 引用集与上游完全一致
- 26 项关键技术记号（脚本签名、账本行格式、四种状态、ADDRESSED/NOT ADDRESSED、
  数值门槛）逐一确认存在，无漏译
- 两个 dot 图节点/边数与上游精确一致（6/6 与 23/28），且无幽灵节点、无孤立节点
  （手工翻译 dot 标签最易在边里写错，会静默产生幽灵节点）
- audit.sh 150 pass / 0 fail；verify-release.sh 82 pass / 0 fail
- SDD 已从 audit 的上游漂移警告里消失（结构层级现已对齐）

注：audit PASS 由 153 降至 150，是上游有意删除 Integration 一节
（原列 executing-plans / test-driven-development / writing-plans 三个引用）
导致 Category 4b 少 3 项引用检查，非静默跳过 —— 已核对我们的引用集与上游一致。
 2026-08-07 22:29:04 +08:00
AI不止语
78457e5bc3 chore(release): v1.7.3 —— 上游纯代码修复同步 + 工具计数一致性检查 
版本号：7 份声明文件 1.7.2 -> 1.7.3（只动 "version" 行，未重排 JSON，已 diff 确认）。

内容见 RELEASE-NOTES.zh.md v1.7.3 条目：
- 同步上游 Windows SessionStart hook 分发修复与 find-polluter.sh 三处路径 bug
- audit 新增 Category 5 工具计数一致性检查（+24 项，已验证会拦漂移）
- 修 bash 3.2 下 CJK 报错信息乱码（3 处）
- .gitignore 补新工具安装产物；官网计数 20 -> 22
- 简繁 README 亮点更新至 v1.7.3，补上 Windows 修复一条

发版前门禁
- scripts/audit.sh: 153 pass / 0 fail（3 warn 为上游漂移，见 #19）
- scripts/verify-release.sh: 82 pass / 0 fail
- npm publish --dry-run: 1.7.3 / 106 文件 / 457.6 kB
v1.7.3 		2026-08-07 21:59:56 +08:00
AI不止语
073a743ce7 fix: 同步上游两处纯代码修复（Windows hook 分发 + find-polluter 路径匹配） 
对齐上游 v6.1.1 -> v6.2.0 时挑出的两处「无需翻译、无需 eval」的修复。
两个文件在我们这边都与上游 v6.1.1 字节一致（从未汉化改动），所以可直接取上游版。

1) hooks/hooks.json 加 "shell": "bash"（上游 5151e7a）

SessionStart hook 在 Windows 上原先不经 Git Bash 分发。我们的 hooks.json 与上游
除这一行外完全相同。这条直接改善 Windows 用户的 bootstrap 可靠性 —— 而 bootstrap
不加载 skill 就是死重。

冒烟测试：CLAUDE_PLUGIN_ROOT 指向仓库跑 run-hook.cmd session-start，
退出码 0，输出正确的 SessionStart JSON（含中文 using-superpowers 正文）。

2) skills/systematic-debugging/find-polluter.sh 取上游修复版（上游 6015d37、c8921b5）

修三个真 bug，已逐个实测新旧版对比：
- pattern 带 ./ 前缀时匹配不到（find . 输出 ./ 前缀路径）：旧 1 个 -> 新 2 个
- -path 的 **/ 无法匹配零层目录，src/**/*.test.ts 漏掉 src/top.test.ts：
  旧 1 个 -> 新 2 个
- 完全无匹配时计数为 1 而非 0（echo 空串仍算一行）：旧 1 -> 新 0

验证：audit.sh 153 pass / 0 fail、verify-release.sh 82 pass / 0 fail。

注：audit 的上游漂移 warn 从 2 条变 3 条（新增 using-git-worktrees），
且 executing-plans / finishing-a-development-branch 的上游 H 值有变化 ——
这是本次 git fetch upstream 把对比基准从旧快照更新到 v6.2.0 导致的，
不是本提交的改动引起。三个 SKILL.md 本提交都没碰。漂移详情见 #19。
 2026-08-07 21:58:12 +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不止语
c6b741447b docs(site): 官网工具计数 20 -> 22，FAQ 补上 Cline 与 Kilo Code 
v1.7.2 加了两款工具，但官网文案还在说 20 款 —— 已发版而站点没跟，
访客看到的数字和 README / npm 不一致。

site/build.mjs 三个语言块（zh / en / zh-Hant）各 5 处，共 15 处：
- meta description、toolsTitle、能力卡标题与描述
- FAQ「支持哪些 AI 编程工具」的枚举列表补入 Cline、Kilo Code
- FAQ「独特价值」里的适配数量

构建校验：63 页正常生成，三语言首页各 7 处新计数、0 处旧计数残留，
Cline / Kilo Code 均出现在枚举里；404.html 未受影响。

site/dist/ 是 gitignore 的构建产物，本提交只改源文件，
上线需另跑 npm run site:deploy。
 2026-08-07 21:43:14 +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 均已入包
v1.7.2 		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不止语
23fc645402 fix(installer): 修正复制失败提示里的失效锚点 
上一个提交给 README 插入「方式二：Plugin Marketplace」后，手动安装一节
顺延为方式三，installer 报错文案里硬编码的 #方式二手动安装 锚点失效。

改为指向父级 #快速开始 —— 章节编号以后还会变，锚点不该依赖它。
 2026-08-07 17:34:21 +08:00
AI不止语
c2e8f6a67e docs(readme): 补充 plugin marketplace 安装方式 (#39) 
.claude-plugin/marketplace.json 从 v1.7.x 起就存在且可用，但 README 从未
写过怎么用，用户无从得知 —— issue #39 请求的能力其实已经实现，只是没告知。

简/繁 README 新增「方式二：Plugin Marketplace」，原手动安装与配置文件
引用顺延为方式三 / 方式四。

已实测验证（用隔离的 CLAUDE_CONFIG_DIR，未污染本机配置）：
- plugin validate                              → Validation passed
- marketplace add jnMetaCode/superpowers-zh    → 成功（GitHub 直连克隆）
- plugin install superpowers-zh@superpowers-zh → 成功，list 显示 v1.7.1 enabled
- 安装缓存内含全部 20 个 SKILL.md

文档同时说明取舍：marketplace 只服务一款 harness，其余 19 款工具仍需
npx 方式；两者可共存但同一项目内别重复装，否则 skills 会有两份。
 2026-08-07 17:25:27 +08:00
AI不止语
08c5290ce6 feat(installer): 检测落空时扫 PATH，给出针对性的 --tool 命令 (#48) 
用户装了 opencode/codex 但项目里没留下标记目录（没在该项目跑过、或配置
在别处），只报「未检测到任何已知 AI 编程工具」很让人懵 —— issue #48 报告
人 opencode 1.17.3 就是这种情况。

改为：检测落空时扫 PATH 找已安装的 CLI，直接打印可复制的 --tool 命令。

- 新增 CLI_PROBES（仅 CLI；IDE 装在应用目录里，PATH 上探不到）
- isOnPath() 只查文件是否存在，不 spawn 进程 —— 不在用户机器上执行
  探测命令；Windows 下遍历 PATHEXT
- --global 模式只建议 GLOBAL_TARGETS 内的工具，避免推荐装不了的
- 探到具体工具就不再列通用示例，别让用户在无关工具名里自己挑

仍然只提示、不自动安装 —— 自动装错工具正是 issue #33 修掉的问题：
PATH 上装了不代表这个项目要用它。

audit.sh: 126 pass / 0 fail（2 项 warn 为既有的上游漂移，见 #19）
 2026-08-07 17:25:15 +08:00
AI不止语
402f7a3446 docs(copilot): 补 Windows powershell 工具面，修正 bash 唯一假设 (#93) 
copilot-tools.md 原先只记了 bash + async:true + read_bash/stop_bash/
write_bash/list_bash 一套，并把上游的 Bash 工具名直接映射到 bash。
但 Windows 上实测（Copilot CLI 1.0.69-1 / Node v24.17.0）注册的是
powershell + detach 一套，完全没有 bash/async 家族 —— agent 照着不存在
的工具名调用会找不到工具然后即兴发挥。

- 异步 Shell 会话拆成 Unix/macOS（bash）与 Windows（powershell）两张表，
  并明确「两套不会同时出现，动手前先确认本 build 注册的是哪套」
- 标注 powershell 一套没有 write_* 等价物（无法向会话发送输入）
- 新增「Windows 上的两个坑」：.sh 需显式走 Git Bash；stop_powershell
  停不掉 detach:true 的进程，需按真实 Windows PID（非 MSYS PID）Stop-Process
- Bash 映射行补平台提示，指向该节

证据与环境均来自 issue #93 报告人的实测。
 2026-08-07 17:25:04 +08:00
AI不止语
687a330dc7 docs(readme): Cubence 福利行补上注册链接，与其他赞助位保持一致 
原文案只给了优惠码 AGENCY，没有可点击的注册入口。
现改为「通过此链接注册的用户，首次购买即可享受 9 折优惠」，
与优云智算的 🎁 福利行结构一致。
 2026-08-07 16:00:05 +08:00
AI不止语
66fe0c5f31 docs(readme): 新增赞助商 Cubence，赞助位统一为 25%/75% 标准版式 
- 新增 assets/sponsors/cubence.jpg（800px 宽，与 compshare.jpg 规格一致）
- 简/繁 README 赞助位从固定 400px 单元格改为 25%/75% 百分比表格，
  logo 用 width="100%" 自适应，文案统一为 Markdown 链接 + 🎁 福利加粗行
- Cubence 邀请链接：https://cubence.com/signup?code=SCW29JP9
 2026-08-07 15:54:40 +08:00
AI不止语
c383440329 feat(site): 新增 404 页，返回真正的 HTTP 404 并 noindex 
Cloudflare Pages 在根目录存在 404.html 时会对未匹配路径返回真正的
HTTP 404，避免默认把首页当 SPA 兜底返回 200 导致 Google 把大量不存在
的 URL 判为首页重复页/软 404。页面加 noindex 防止自身被收录，导航用
绝对路径以适配任意深度的未命中路径。
 2026-07-31 16:12:07 +08:00