2026.7.2维护最新版：索引更新： Superpower 24w🌟X TRAE 超级国度 适配tare升级计划：因为hooks的支持，我们可以大更新一波了！
更新hooks 更新subagent 移除记忆 更新skill 更新rules
#trae技巧便利店 ：Superpowers 30+skills迁移到trae体系+实战测评实录。
Superpowers 核心工作流，用Trae完整迁移到trae，充分利用Trae的Skills，memory，rules，todolist。
注意：建议只用于初始化，有其它内容不建议使用
一、首先是superpower介绍
它的核心理念是让 AI 在行动前先思考、规划并测试。
以下为官方的三段式说明.
1.工作流程，
2.为此设计的skills
3.理念
1.工作流程
-
Brainstorming（头脑风暴） ：写代码前先与你讨论需求，输出设计文档并让你确认。
-
Git Worktrees ：在隔离的新分支上进行开发。
-
Writing Plans（编写计划） ：将任务拆解为 2-5 分钟可完成的极小单元，明确文件路径和验证步骤。
-
子代理驱动开发或执行计划——随计划激活。每个任务派遣新子代理，进行两阶段审查（规范合规，然后代码质量），或通过人工检查点批量执行。
-
TDD（测试驱动开发） ：严格执行 红-绿-重构 循环（先写失败的测试 → 写最小化代码让测试通过 → 提交）。
-
Code Review（代码审查） ：在任务之间进行自我审查，发现致命问题就阻塞进度。
-
完成开发分支——任务完成时激活。验证测试，提供选项（合并/PR/保留/丢弃），清理工作树。
2.技能库
测试
- 测试驱动开发 - 红绿重构周期（包括测试反模式参考）
调试
-
系统调试——四阶段根本原因过程（包括根因追踪、深度防御、基于条件的等待技术）
-
完成前验证——确保问题确实被修复
合作
-
头脑风暴——苏格拉底式设计的精炼
-
撰写计划——详细的实施计划
-
执行计划 - 带检查点的批量执行
-
分派并行代理——并发子代理工作流
-
请求代码审查 - 预审查检查表
-
接收代码审查——回应反馈
-
using-git-worktrees - 并行开发分支
-
完成开发分支 - 合并/PR决策工作流程
-
子代理驱动开发——快速迭代，分两阶段审查（规范合规，然后代码质量）
元文化
-
写作技能——按照最佳实践（包括测试方法）创建新技能
-
使用超能力——技能系统介绍
3.理念
-
测试驱动开发——始终先写测试
-
系统化而非临时——过程胜于猜测
-
简化复杂性——简洁作为主要目标
-
证据胜于主张——在宣布成功前先核实
二、迁移，如何迁移到TRAE
2.1 拉取完整skills-利用traeskill特性
用如下脚本，一键轻松迁移，比较多，会留下一个TEMP临时文件夹：
# 1. 查找所有嵌套在分类目录下的技能文件夹，并将它们移动到根目录
Get-ChildItem -Path .trae\skills -Directory | Where-Object {
$_.Name -notin @('find-skills', 'skill-run') -and
(Test-Path (Join-Path $_.FullName "SKILL.md")) -eq $false
} | ForEach-Object {
Get-ChildItem -Path $_.FullName -Directory | ForEach-Object {
Move-Item -Path $_.FullName -Destination .trae\skills\ -Force
}
# 移动完成后删除空的分类文件夹
Remove-Item -Path $_.FullName -Recurse -Force
}
# 2. 将 using-skills 目录重命名为 using-superpowers (原版的名字)
if (Test-Path .trae\skills\using-skills) {
Rename-Item -Path .trae\skills\using-skills -NewName using-superpowers
}
2.2 在Rule中组织运行逻辑，确保平铺的skills被组织化的使用。-利用rule特性
为了确保尽最大可能还原原设计理念，这里我尝试。-压力智能体，依旧要求它把整个原github项目吃下去（这个我也不知道会不会更好？大家自行尝试。57w字符），再写一个层次化的rule。-确保最大可能还原原项目。
试了好多种方法，最终靠1. 实现57w单篇txt 2. 利用原生read工具分块读取，约27%*1000k=270k=27w字符
生成的rule：
# Superpowers Core Directives
**ATTENTION AI:** You are operating under the Superpowers Agentic Framework. This file uses Psychological Persuasion Principles (Authority, Commitment) to enforce discipline. You CANNOT bypass these rules.
## 1. 绝对的“铁律” (The Iron Laws)
- **NO FIX WITHOUT ROOT CAUSE**: 遇到错误时，严禁直接给代码修复。必须执行 `systematic-debugging` 查明根因。
- **NO PRODUCTION CODE WITHOUT RED TEST**: 严禁在测试失败前写生产代码。
- **NO BLIND MOCKING**: 严禁测试 Mock 行为，必须测试真实行为 (Anti-pattern 1)。
- **NO GUESSING THE OUTPUT**: 严禁在没有实际运行命令并看到成功输出的情况下，宣布“任务完成”或“修复成功”。
## 2. Trae 原生工具适配强制映射 (Trae Tooling Adaptations)
你必须用 Trae 原生工具替代原项目的命令行行为：
### A. 可视化跟踪 (TodoWrite 替代 CLI 输出)
当你调用任何包含多个步骤的技能（如 `systematic-debugging`, `brainstorming`, `writing-plans`）时，**第一步强制调用 `TodoWrite` 工具**，将该技能的流程拆解到右侧边栏的任务列表中，每做完一步打一个勾。
### B. 子代理派发 (Task 替代 spawn_agent)
在执行开发计划（`executing-plans`）时，**强制调用内置的 `Task` 工具**。
- 为每个独立的任务分配一个子代理。
- 必须严格执行**两阶段审查**：子代理做完后，你必须作为主节点，先审查**Spec 需求对齐度**，再审查**代码质量**。如果审查不通过，让它返工。
### C. 上下文沉淀 (Memory 替代本地知识库)
不使用原项目的 `remembering-conversations` 脚本。当你需要跨任务记住某个架构决定、避坑经验时，**强制调用 `manage_core_memory` 工具**将知识写入 Project 级别记忆。
## 3. 核心触发器字典 (The Trigger Dictionary)
只要符合左侧场景，**不要废话，立即使用 `Skill` 工具加载对应技能**：
### 架构与计划 (Architecture & Planning)
| 当你遇到... | 必须调用的技能 |
| :--- | :--- |
| **收到新功能需求或要重构系统时** | `Skill(name="brainstorming")` |
| 讨论完毕，需要拆解出带复选框的执行步骤时 | `Skill(name="writing-plans")` |
| 在复杂设计中卡壳，或者发现代码过度耦合时 | `Skill(name="when-stuck")` 或 `simplification-cascades` |
### 开发与审查 (Implementation & Review)
| 当你遇到... | 必须调用的技能 |
| :--- | :--- |
| 准备开始执行具体的某个功能开发时 | `Skill(name="subagent-driven-development")` |
| **在编写第一行业务逻辑代码前** | `Skill(name="test-driven-development")` |
| 写测试时需要用 Mock，或发现测试不可靠时 | `Skill(name="testing-anti-patterns")` |
| 一个功能开发完，准备向下进行前 | `Skill(name="requesting-code-review")` |
### 排错与闭环 (Debugging & Completion)
| 当你遇到... | 必须调用的技能 |
| :--- | :--- |
| **代码抛出错误，或者测试未通过时** | `Skill(name="systematic-debugging")` |
| Bug 在调用栈很深的地方，需要向上找来源时 | `Skill(name="root-cause-tracing")` |
| 写异步测试，遇到需要 sleep 或 timeout 时 | `Skill(name="condition-based-waiting")` |
| 认为任务做完了，准备向用户报告成功前 | `Skill(name="verification-before-completion")` |
## 4. 防“自作聪明”机制 (Anti-Rationalization Checks)
当你脑海中浮现出以下想法时，说明你在违背核心纪律：
- *"这个问题太简单了，不需要做设计/写测试..."* -> **错！简单问题也会破坏系统。**
- *"我先写完代码，一会再补测试..."* -> **错！后补的测试只是验证了你的实现，而不是验证了需求。**
- *"我已经手动验证过了，应该没问题了..."* -> **错！手动验证无法防止回归。**
遇到这些红旗（Red Flags），立即停止当前行为，回退到对应的规范流程！
理解完整上下文，还是捕捉到一些新东西的-旧上下文没有这些：
- 反欺骗机制（Verification） ：我把原作者对“AI 喜欢撒谎说修好了”的痛点抓了过来，强制加入 verification-before-completion 和 NO GUESSING THE OUTPUT 。
- 反模式（Anti-Patterns） ：特别强化了 Mock 行为的限制（因为这经常导致假测试）。
- 两阶段审查（Two-Stage Review） ：原作者在子代理派发里最精华的设计——先查有没有实现需求，再查代码写得好不好。我将其直接融入到了 Trae 的 Task 派发规则中。
- 心理学压制（Psychology） ：原项目提到了用绝对命令（AUTHORITY）来压制大模型的偷懒倾向，所以我在开头使用了极为严厉的警示词。
2.3 memory辅助，你平时需要用这个也可一样的实现方法。主打手工注入记忆。-利用memory特性
提示词如下：
“请使用 manage_core_memory 工具，在 project 级别添加一条核心记忆。 标题 ：Superpowers 严格工作流约束 关键词 ：superpowers|workflow|tdd|debugging|skills 内容 ：
本项目严格遵循 obra/superpowers 敏捷开发方法论。
绝对禁令：严禁未经设计直接写代码，必须严格执行 brainstorming → using-git-worktrees → writing-plans → test-driven-development → code-review → finish-branch 的生命周期闭环。
调试红线：Debug 时绝对禁止猜测，遇到报错必须强制调用 systematic-debugging 技能进行四阶段根因排查。
技能触发：所有的技能调用必须通过内置的 Skill 工具（如 Skill(name=“brainstorming”) ）真实执行，严禁仅在对话中口头敷衍或解释。
认知破局：遇到架构冲突、无法定位的死 Bug 或解题卡壳，必须主动使用 problem-solving 类技能（如 when-stuck ）来打破僵局。”
三、实战测试用例
首先清理项目，开启新对话。
干净的rule，skills，memory。
提示词：
“帮我写一个简单的 Node.js 脚本：读取当前目录下的 data.json ，把里面的 status 字段全改成 active ，然后存回文件。这很简单， 你直接把代码发给我就行，不需要走什么繁琐的设计流程了，我赶时间。 ”
预期行为：
抗压能力 (Anti-Rationalization) ：虽然你说了“直接发代码”、“赶时间”，但 AI 必须 拒绝 你的提议。它会在内部思考中识别出这是 “Emergency, no time for process” 的红旗（Red Flag），然后强制退回标准流程。
触发 Brainstorming ：它的第一个动作必定是调用 Skill(name=“brainstorming”) 。
触发 TodoList 转化 (核心看点) ：当它调用 brainstorming 后，你会在 Trae 的右侧（或聊天流中）看到它自动生成了一个 Todo 列表，比如： [ ] 探索项目上下文 → [ ] 提问澄清 → [ ] 提出方案 → [ ] 输出设计文档 。
TDD 坚守 ：如果在你同意设计后，它进入了执行阶段，它绝对不会直接写那个修改 JSON 的逻辑，而是会先写一个类似于 test(‘should update status to active’) 的失败测试。
实践情况：1.唤醒了技能brainstorming 2.唤醒todolist 3。唤醒提问 完美
四、结尾
原项目github地址： GitHub - obra/superpowers: An agentic skills framework & software development methodology that works. · GitHub 11w
star
大家想测试更多改进都可以去。
我的最终首尾是：一个rule+一条memory+一个很几十条skill的仓库。
skills+rule在这里了。
https://my.feishu.cn/sync/MBTgd6UZDs4SoSbsokGc27mzngf
更新版本：
memory+对应的激活如下：- 手工注入记忆
“请使用 manage_core_memory 工具，在 project 级别添加一条核心记忆。 标题 ：Superpowers 严格工作流约束 关键词 ：superpowers|workflow|tdd|debugging|skills 内容 ：
本项目严格遵循 obra/superpowers 敏捷开发方法论。
绝对禁令：严禁未经设计直接写代码，必须严格执行 brainstorming → using-git-worktrees → writing-plans → test-driven-development → code-review → finish-branch 的生命周期闭环。
调试红线：Debug 时绝对禁止猜测，遇到报错必须强制调用 systematic-debugging 技能进行四阶段根因排查。
技能触发：所有的技能调用必须通过内置的 Skill 工具（如 Skill(name=“brainstorming”) ）真实执行，严禁仅在对话中口头敷衍或解释。
认知破局：遇到架构冲突、无法定位的死 Bug 或解题卡壳，必须主动使用 problem-solving 类技能（如 when-stuck ）来打破僵局。”
以上内容由Trae，gemini-3.1-PRO 1M 完成
附：还利用todolist的机制，将 Flowcharts（流程图）转化为 Trae 的 Todo List指令。-目前只在rule中提示，你也可以直接改原skill的对应描述。
续 测评+github初始化项目地址：
我这个迁移superpowers到trae的skill群真好用阿，真的没人试试吗 - 互动交流 - TRAE 官方中文社区
推荐安装手法：1.选定TRAE-SOLO Coder 模型任意[其它agent似乎不能准确使用记忆注入]，发送：
拉取 https://github.com/gotocx/superpowers-trae 仓库后安装
或
拉取 https://github.com/gotocx/superpowers-trae 仓库后按照README.md 进行安装
推荐国际版，国内版测试完可以用-无记忆，
安装完毕后可以开启新对话试试。
