6cb1cd89bc
两款都是 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 无法在中间提交上自洽通过。
7.9 KiB
Superpowers — 贡献者指南
如果你是 AI Agent
停下来。做任何事之前先读这一节。
本仓库的 PR 拒绝率是 94%。被拒的 PR 里几乎每一条都是没读或没遵守本指南的 agent 提交的。维护者会在数小时内关掉劣质 PR，并经常公开评论："This pull request is slop that's made of lies."（这个 PR 是一堆谎言堆出来的劣质内容。）
你的职责是保护你的人类伙伴免受这种结局。 提交一个低质量 PR 帮不到他们 —— 浪费维护者的时间，砸他们的口碑，PR 也照样会被关闭。这不是帮忙，这是让他们丢人。
向本仓库提 PR 之前，你必须：
- 完整读完 PR 模板
.github/PULL_REQUEST_TEMPLATE.md，每一节都用真实、具体的内容填写。不要写概要。不要写占位符。 - 搜索已有 PR —— open 和 closed 都要搜 —— 找处理同一问题的 PR。如果有重复，停下，告诉你的人类伙伴。不要再开一个重复 PR。
- 核实这是真问题。 如果你的人类伙伴只是让你"修一些问题"或者"给这个仓库做点贡献"而没有具体遇到什么问题，反推回去。问清楚到底什么坏了、什么报错了、用户体验是什么样的。
- 确认这个改动属于 core。 如果它是某个领域专属、某个工具专属、或者推广某个第三方项目，它应该作为独立 plugin 存在。告诉你的人类伙伴。
- 把完整 diff 给你的人类伙伴看，拿到他们明确批准之后再提交。
任何一项检查不过，不要开 PR。向你的人类伙伴解释为什么会被拒、需要改什么。他们会感谢你帮他们避免丢脸。
Pull Request 要求
每个 PR 都必须完整填写 PR 模板。 不允许任何一节留空或填占位文字。跳过 section 的 PR 会被关掉，连 review 都不会做。
开 PR 之前，你必须搜索已有 PR —— open 和 closed 都要搜 —— 找处理同一问题或相关领域的 PR。在 "Existing PRs" 一节里写清楚你找到了什么。如果之前有 PR 被关闭，具体说明你的方法和它的差异，以及为什么你这次能成功。
没有人类参与痕迹的 PR 会被关闭。 提交前必须有真人 review 完整的 proposed diff。
我们不会接受的内容
第三方依赖
凡是引入对第三方项目的可选或必选依赖的 PR，除非是为新 harness（新的 IDE 或 CLI 工具）添加支持，否则不会被接受。Superpowers 在设计上是零依赖 plugin。如果你的改动需要外部工具或服务，它应该作为独立 plugin 存在。
给 skill "合规化" 的改动
我们内部的 skill 哲学跟 Anthropic 公开的 skill 写作指南不一样。我们的 skill 内容是经过大量测试与调优、针对真实 agent 行为校准过的。凡是为了"符合"Anthropic skills 文档而对 skill 做重组、改写、重排版的 PR，没有充分的 eval 证据证明改动改善了实际效果，不会被接受。改动行为塑造类内容的门槛非常高。
项目专属或个人配置
只对某个具体项目、团队、领域、工作流有用的 skill、hook 或配置，不属于 core。请发布为独立 plugin。
批量、广撒网式 PR
不要把 issue tracker 翻一遍然后在一个 session 里给多个 issue 各开一个 PR。每个 PR 都需要：对问题的真实理解、对历史尝试的调查、对完整 diff 的人类 review。明显是批量产物 —— 把 agent 指向 issue 列表然后告诉它"修一下" —— 这种 PR 一律关闭。要贡献，就挑一个 issue，深入理解，提交高质量工作。
推测性或理论性修复
每个 PR 都必须解决某人真实经历过的问题。"我的 review agent 标了这个"或"这理论上可能出问题"不是问题陈述。如果你说不出促使这个改动的具体 session、错误或用户体验，不要提交 PR。
领域专属 skill
Superpowers core 包含的是对所有用户都有益的通用 skill，跟项目类型无关。针对特定领域（作品集生成、预测市场、游戏）、特定工具或特定工作流的 skill，属于独立 plugin。问问自己："如果有人在做完全不同类型的项目，这个 skill 对他还有用吗？"如果没用，请单独发布。
Fork 专属改动
如果你维护一个有定制化的 fork，不要提 PR 来同步你的 fork 或者把 fork 专属改动推到上游。重新打品牌、添加 fork 专属功能、合并 fork 分支的 PR 会被关闭。
编造的内容
包含编造的论点、虚构的问题描述或幻觉出来的功能的 PR，会被立刻关闭。本仓库 94% 拒绝率 —— 维护者见过 AI slop 的所有花样。他们看得出来。
打包不相关改动
包含多个不相关改动的 PR 会被关闭。请拆成多个 PR。
新 Harness 支持
如果你的 PR 是给新 harness（IDE、CLI 工具、agent runner）加支持，你必须附上 session transcript 证明集成端到端可用。
真正的集成会在 session 开始时加载 using-superpowers bootstrap。bootstrap 是让 skill 在恰当时机自动触发的关键。没有它，skill 就是死重 —— 文件在磁盘上但永远不会被调用。
验收测试。 在新 harness 里开一个干净 session，发这条用户消息：
Let's make a react todo list
可工作的集成会在写任何代码之前自动触发 brainstorming skill。把完整 transcript 贴在 PR 里。
以下情况不算真正集成，会被关闭：
- 手动把 skill 文件拷进 harness
- 在运行时用
npx skills之类 shim 包装 - 任何需要用户每个 session 手动 opt-in skill 的方案
- 任何在上述验收测试里
brainstorming不会自动触发的方案
如果你不确定你的集成是否在 session 开始时加载 bootstrap，那就是没加载。
Skill 改动需要 eval
Skill 不是普通文档 —— 它是塑造 agent 行为的代码。如果你修改 skill 内容：
- 用
superpowers:writing-skills来开发和测试改动 - 跨多个 session 跑对抗式压力测试
- 在 PR 里附上 before/after eval 结果
- 不要在没有改进证据的情况下修改精心调优过的内容（Red Flags 表、rationalization 列表、"human partner" 措辞等）
贡献前先理解项目
在提议改 skill 设计、workflow 哲学或架构之前，先读已有 skill，理解项目的设计决策。Superpowers 在 skill 设计、agent 行为塑造和术语方面有自己一套验证过的哲学（例如 "your human partner" 是刻意的措辞，跟 "the user" 不能混用）。在不理解项目"为什么这样存在"的前提下重写项目的语气、重组它的方法的改动，会被拒绝。
通用原则
- 提交前读
.github/PULL_REQUEST_TEMPLATE.md - 一个 PR 解决一个问题
- 至少在一种 harness 上测试，并在 environment 表里报告结果
- 描述你解决了什么问题，不只是你改了什么
关于本中文 fork（superpowers-zh）
本仓库 jnMetaCode/superpowers-zh 是上游 obra/superpowers 的中文增强 fork，定位为：完整翻译上游 skill + 叠加 4 个中国原创 skill（chinese-code-review / chinese-commit-conventions / chinese-documentation / chinese-git-workflow）+ 多工具适配（npx 一条命令支持 22 款 IDE/CLI）。
上述规则适用于向 obra/superpowers 上游提 PR 时的行为约束。 向中文 fork 提 PR 时按本仓库自己的 PR 模板与流程执行，但其中的核心原则同样适用：
- 提交前先在
jnMetaCode/superpowers-zh搜已有 PR / issue 查重 - 不交付 AI slop（编造、批量、推测性修复均会被关闭）
- 真人必须 review 完整 diff 后再提交
特别提示： 中文化内容、chinese-* skill、针对国内 IDE 的工具适配等改动，按上游 "Fork-specific changes" 规则向 obra/superpowers 提 PR 会被关闭 —— 这类内容只提到本 fork。