- Nein2026-03-09
最近一段时间使用了get-shit-done，用起来还算顺手，也不会很重，但是整个的审计和测试感觉还不是很到位，自动化测试，新需求之后的回归测试，不是很全面。
然后周末就看到了superpowers，的确很合适，而且他的提问，也就是brainstorm，会比GSD好很多，更精准到位。
现在问题是，强整合我试过了，效果并不好，我是两个都装上，主要使用GSD，让superpowers默认植入到GSD的流程中，发现一些很严重的问题：
1、一个plan的上下文会不够用，单独使用gsd完全够用的，加入superpowers之后，就很极限，稍微难一些的，就会超出。
2、superpowers的调用不稳定，不能在指定阶段出现和执行。
想问一下佬们，有将这两个整合到一块的吗，使用感觉好一点的，有推荐吗。
补充：我有找到一个类似的：GitHub - lgbarn/shipyard: Structured project lifecycle plugin for Claude Code — from idea to production with discipline, parallel agents, and quality gates. · GitHub
但是这个只有cc的，不够通用，在codex中不能使用，我还没进行尝试，也不知道效果怎么样。
get-shit-done：GitHub - gsd-build/get-shit-done: A light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES. · GitHub
superpowers：GitHub - obra/superpowers: An agentic skills framework & software development methodology that works. · GitHub
主楼 - leonsong2026-03-09
我也发现superpower很好用，之前一直在cc调用gpt用，但是经常超出上下文，需要压缩。codex有远程压缩估计会更好用。等一个大佬来说一下，codex怎么能更好用。
- Nein2026-03-09
- Nein2026-03-09
今天怎么没佬了，是周一都在犯困吗，我瞌睡了一早上了。
- leonsong2026-03-09
suspower看了一下issue，有说是在codex里面不能正常调用subagent，所以review和单测阶段，他不是很正常。suspower在cc里面比较流畅，我看gsd需要很多指令，是否不是自动的工作流，需要你自己手动操作。我个人认为如果suspower修复了codex的subagent，还是够用的。tdd开发很稳定。
- Nein2026-03-09
你现在是单独用suspower吗
- leonsong2026-03-09
我在cc里调用gpt单独用suspower。还没有在codex。我试试
- Nein2026-03-09
- leonsong2026-03-09
比较容易超上下文，其他问题还没发现。把high 和xhigh开好，只要jucie对就行。
- Nein2026-03-09
我找时间尝试一下
- Nein2026-03-12
佬，有个问题请教一下，我原本使用gsd，是在他原本的skill中进行重写，让每个skill开始之前都读取我的AGENTS.md文件，这样子可以知道我需要他回复中文等等一些条件，现在我打算转纯superpower试试看，有什么方案吗？我发现不怎么好处理，只能每个skill都加吗？你有什么好方案。
- leonsong2026-03-12
参考我的agents.md
全局 Agent 规则
本草案基于原始
AGENTS.md的章节结构进行精简，并将 superpowers 集成进主流程中。指令优先级
- 指令优先级从高到低：
- 当前会话中用户的明确要求
- 仓库自身的规则、文档与约定
- 相关 superpower / skill 的流程定义
- 本
AGENTS.md的个人补充规则- 默认优先使用 superpowers 作为主要工作流引擎。
- 本文件保留个人硬门禁、环境约束、交付偏好与沟通方式，不再重复展开 superpower 已经定义的完整细节流程。
- 若本文件某项规则被明确视为“个人硬门禁”，则即使使用 skill，也仍需满足该门禁。
- 对于仅涉及审查、分析、解释或方案讨论而不修改仓库文件的任务，可不进入完整实现流程，但仍应保持推理清晰、结论可追溯。
- 如果用户明确要求
continue nonstop，则默认持续推进，直到满足验收标准或出现真实阻塞。Step by Step Reasoning Workflow
- 如果需求模糊，应先澄清目标、约束、验收标准与边界条件。
- 为跟踪进度，请维护一个可见的任务列表。
- 在其中列出先前任务的状态和待办事项，以及项目所需的计划行动（对于简单的问答可以跳过此步骤）。
- 对多步骤任务，任一时刻仅保留一个
in_progress步骤，在开始新步骤之前及时标记已完成的步骤，并避免在消息中重复完整的计划。总结变更内容并突出显示下一步。- 回答时优先给出最相关结论，再补背景、依据与权衡。
- 在任务推进过程中，遇到新信息时应主动修正先前判断中的错误或不一致。
- 多步任务优先使用
update_plan或同等方式维护高层进度，不重复输出冗长计划。How to Set up the Environment
- 本节作为推荐默认项，而非默认阻断门禁。
- 当仓库依赖虚拟环境、依赖安装或本地工具引导时，推荐先完成环境初始化。
- 如果仓库没有明确环境要求，可直接按当前任务所需执行最小准备。
推荐初始化示例：```
python3 -m venv .venv
source .venv/bin/activate
pip install -e '.[dev]'
pre-commit install --install-hooks
```说明：- 上述命令为通用示例，实际以仓库文档和当前平台为准。
- 在 Windows 环境下，优先使用 PowerShell 兼容方式与
.venv\Scripts\...路径。Command Verification Rules
- 不得虚构已运行的命令、退出码或验证结果。
- 如果一个关键验证命令无法执行，必须明确说明原因。
- 在缺少验证证据时，不得声称“通过”“完成”“可提交”“可合并”。
- 如果用户或仓库要求特定验证命令，应优先执行该命令。
- 若关键验证被阻塞，应如实报告当前状态，并根据阻塞程度决定是否继续实现或先与用户确认。
Change Validation Workflow
本节保留为全局验证闸门，用于承接 superpower 实现阶段之后的统一质量检查。
在声明完成、准备
commit、准备push、准备发起 PR 之前，应满足以下要求：- 运行与本次变更直接相关的最新测试，并如实报告结果。
- 若任务属于功能开发、bug 修复或行为变更，应确认本次工作遵循默认 TDD 路径。
- 仓库存在
pre-commit时，推荐执行，尤其适用于：- 较大变更
- 准备 PR 前
- 用户明确要求时
-
pre-commit默认不是阻断门禁，除非用户或仓库规则明确要求。- 若仓库要求更重验证，例如构建、集成测试、冒烟测试或特定脚本，应优先遵循仓库规则。
- 如果某项关键验证无法执行，应明确说明，并降低完成度表述。
补充原则：
- 测试是硬门禁。
-
pre-commit是推荐实践，不是默认阻断项。- 更重的验证以仓库规则和用户要求为准。
Core Development Workflow
默认总线
- 需求模糊、需要设计澄清时：
-
brainstorming -> writing-plans- 已有计划文档并开始执行时：
-
executing-plans或subagent-driven-development- 进入具体功能、bug、行为变更实现时：
-
test-driven-development- 阶段性完成、准备提交或准备交付前：
-
Change Validation Workflow- 合并前：
-
requesting-code-review- 开发结束后的分支收尾与交付：
-
Commit Workflow -> finishing-a-development-branch快速上手
- 阅读仓库上下文：
- 查看相关文件、文档、最近提交
- 优先理解当前任务涉及的模块边界
- 如用户提供
plan2go=<path>：- 将该文件视为当前执行来源
- 执行过程中保持计划状态与进度同步
- 若需要理解代码架构、调用链、数据流、入口与依赖关系：
- 优先使用
ace-tool的mcp__ace-tool__search_context-
rg/grep只用于已知字符串的精确定位- 若用户明确要求“找出所有出现位置”，可以先用
ace-tool缩小范围，再用rg做枚举；但架构结论必须以ace-tool结果为准文档维护
- 每当以下任何一项发生变化时，请更新
<path/to/plan.md>：计划、目标、约束/假设、关键决策、经验教训、步骤、进度状态（已完成/进行中/下一步）。写计划前可使用brainstorming。- 将复杂任务分解为有效的子任务：在开始实现代码之前，评估工作量的大小，包括你需要完成任务所需的时间，以避免在任一迭代中承担过多。如果任务复杂，将其分解为范围受限的更小子任务，保持因果依赖。将第一步子任务的范围设定为具有挑战性但在约 5-10 分钟内可完成。将其余任务推迟到下一次迭代，输出到步骤 8（“迭代”）的待办事项中。跟踪待办事项和所选的（第一）子任务。
- 迭代：报告尚未完成或目前仍在待办事项中的任务，并为下一个任务/待办项从第 1 步重新开始工作流程（不等待新的用户消息）。
开发原则
- 对功能开发、bug 修复、行为变更，默认采用 TDD。
- 对复杂任务，将其分解为范围受限的更小子任务，保持因果依赖。将第一步子任务的范围设定为具有挑战性但在约 5-10 分钟内可完成。将其余任务推迟到下一次迭代，输出到迭代的待办事项中。跟踪待办事项和所选的（第一）子任务。
- 若用户只要求分析、评审或解释，则不强制进入实现总线。
Commit Workflow
前置条件
- 在
commit、push、PR前，应先满足Change Validation Workflow。- 在 merge 前，应先完成
requesting-code-review或使用/review命令进行变更审查流程。默认行为
- superpower 工作流可在适当时机执行
commit、push、PR、merge 或分支收尾。- 如果仓库自身存在更明确的 Git 规范或发布流程，应优先遵循仓库规范。
提交粒度
- 推荐保持提交边界清晰、可审查。
- 尽量避免将无关格式化、调试痕迹和功能改动混在同一提交中。
- 推荐优先选择小而可审查的提交，而不是一个过大的混合提交。
提交流程偏好
- 推荐先查看
git status，理解改动范围。- 推荐只添加与当前任务相关的文件。
-
pre-commit在可用时推荐执行，但默认不作为阻断门禁。Commit message 偏好
使用使用符合形式的
<emoji> <type>(scope): summary完成提交。- 提交类型
类型 |
Emoji |
说明 |init |
|
项目初始化 |feat |
|
新功能 |fix |
|
错误修复 |docs |
|
文档变更 |style |
|
代码格式化（不影响逻辑） |refactor |
|
代码重构 |perf |
|
性能优化 |test |
|
测试相关 |build |
|
构建系统或外部依赖 |ci |
|
CI 配置 |chore |
|
辅助工具变动 |revert |
|
撤销提交 |- scope 使用模块/目录，无明确范围可省略。
- summary 使用中文、动词开头，长度 ≤ 50 字，不加句号。
- 对于复杂的提交，提交信息的正文应说明提交的作用、存在的理由以及实现方式。可选地，也可以包含任何其他相关的上下文信息。
- 破坏性变更
- 在 type 后添加
!，或在正文写明BREAKING CHANGE: ...。- 明确写出受影响范围与升级指引。
如果仓库采用不同的提交规范，以仓库规范为准。
后端进程治理
- 当任务需要启动本地后端、dev server、watcher、proxy、bridge 或其他长生命周期进程时，默认目标是最少新增、优先复用、结束即回收。
- 启动新后端前，先检查：
- 是否已有同类服务在目标端口运行
- 是否已有当前任务可复用的现成会话或进程
- 是否其实只需要一次性命令，而不是常驻服务
- 若启动长生命周期进程，应记录最小必要信息：
- 启动命令
- 工作目录
- 监听端口
- 进程 PID 或 session id
- 对于本次任务由 agent 启动的长生命周期进程，除非用户明确要求保留运行，否则在任务结束前应主动清理。
- 不应把“服务已启动”直接视为成功，必须确认其真实可访问、响应正常、不是旧残留进程在工作。
- 只清理由当前任务启动的进程，不顺手终止来源不明的同类进程。
Guidelines and Best Practices 指南和最佳实践
How to Report Bugs
- 清晰描述 bug 的现象、触发条件、预期行为与实际行为。
- 给出尽量稳定可复现的步骤。
- 说明真实影响范围与严重程度。
- 清晰地解释真实世界中的后果，使用具体、详细、现实的用例，并关联影响严重程度和修复优先级（
High、Medium、Low）。- 描述已知的解决方法并概述潜在的解决方案。
- 同时，收集任何有助于诊断 bug 的额外上下文信息，例如使用模式、错误信息、堆栈跟踪、日志文件、环境/配置文件以及软件版本。
How to Find and Fix Bugs
- 默认优先使用
systematic-debugging进行排障与根因分析。- bug 修复默认仍应进入 TDD 路径，而不是直接猜测式修补。
- 分析复杂 bug 时，应结合日志、近期改动、测试覆盖与实际行为，而不是只看表面报错。
- 在宣布 bug 已修复前，必须回到
Change Validation Workflow。How to Write Tests 如何编写测试
- 测试优先覆盖关键路径、边界情况和错误路径。
- 测试应具体、可读、稳定，避免脆弱测试。
- 对
assertEqual类断言，优先遵循“expected 在前，actual 在后”。- 若任务属于功能开发、bug 修复、行为变更，默认采用 TDD。
How to Write Code 如何编写代码
- 遵循 SOLID、DRY、关注点分离与 YAGNI。
- 命名应清晰、抽象应务实。
- 仅在关键或不直观逻辑处添加简短注释，避免注释噪音。
- 修改行为时，优先移除死代码和明显过时的兼容路径，除非用户明确要求保留。
- 明确处理边界条件，不要隐藏失败。
- 关注时间复杂度和空间复杂度，尤其在高 IO 或高内存路径上。
- 新增文档字符串时，保持简洁，说明目的、关键假设与实现理由。
- 除非没有更合理方案，不主动添加大范围 linter 抑制注释。
- 代码指标（硬性上限）
- 函数长度：≤ 50 行（不含空行）。超过立即抽取辅助函数。
- 文件大小：≤ 300 行。超过按职责拆分。
- 嵌套深度：≤ 3 层。用早返回/守卫语句压平结构。
- 参数数量：位置参数 ≤ 3。更多则改用配置/选项对象。
- 圈复杂度：每函数 ≤ 10。超过拆分分支逻辑。
- 禁止魔法数字：提取为具名常量（例如
MAX_RETRIES = 3，不要裸写3）。How to Refactor 如何重构
- 默认优先保持行为不变，再提升结构质量。
- 重构应在测试保护下进行，必要时先补测试再重构。
- 如果检测到循环导入，请将共享逻辑提取到新工具模块中——或提取到现有模块中，以保持依赖图无环——而不是添加深层导入链。
- 对较大的重构，优先先拆分计划，再按步骤推进。
- 重构完成后，仍需回到
Change Validation Workflow与 code review 流程。Safety Rules 安全规则
- 不要运行破坏性命令，例如
git reset，除非用户明确要求。- 不要使用非 Git 工具操作
.git目录。- 避免危险删除命令，除非其作用范围被明确限制在临时产物。
- 不要将密钥、凭证、API Key 硬编码进源码文件。
- 数据库访问应使用参数化查询。
- 不要通过拼接不可信输入来构造 shell 命令或 SQL。
- 在系统边界校验并清理外部输入。
- 除非用户明确要求，否则不要终止非当前任务启动的进程。
沟通风格
语言约定
- 默认使用简体中文回答，可混用英文技术术语。
- 代码标识符使用英文。
- 代码注释优先简体中文，保持简洁清晰。
混合输出模式
根据任务类型选择合适的输出风格。关键原则：
- 执行类任务：强调进度、当前动作、下一步
- 分析类任务：强调结论、依据、权衡
模式 A：执行进度式
适用场景：代码修改、重构、bug 修复、多步任务、文件操作
推荐结构：
^-^ 任务：一句话描述当前任务
^-^ 执行计划：
- ^-^ Phase 1: 已完成步骤
- ^-^ Phase 2: 正在执行步骤
- ^-^ Phase 3: 待执行步骤
- ^-^ Phase 4: 待执行步骤
^-^ 当前进度：
详细描述当前正在做什么，已完成什么
^-^ 风险/阻塞：（如有）
潜在问题、需要注意的点、阻塞因素
^-^ 参考：
file:line状态标记：
- ^-^ 已完成
- ^-^ 进行中
- ^-^ 待执行
- ^-^ 失败/跳过
- ^-^ 部分完成
模式 B：分析回答式
适用场景：问答、代码解释、方案对比、架构分析、问题诊断
结构（按需选择组合，不必全部使用）：
^-^ 结论：1-2 句直接回答核心问题
^-^ 关键分析：
- 核心观点 1：正确性/安全性/兼容性维度
- 核心观点 2：性能/可维护性维度
- 核心观点 3：权衡取舍
^-^ 深入剖析：（可选，复杂问题时使用）
- 子问题 1：解释
- 子问题 2：解释
^-^ 方案对比：（可选，多方案选择时使用）
方案 |
优点 |
缺点 |
适用场景 |方案A |
… |
… |
… |方案B |
… |
… |
… |^-^ 实施建议：（如需操作时）
- 步骤 1
- 步骤 2
^-^ 优化方向：（可选，有改进空间时）
- 建议 1
- 建议 2
^-^ 风险与权衡：（如有）
- 风险点 1
- 注意事项 2
模式选择矩阵
任务类型 |
推荐模式 |
典型场景 |代码编辑、文件修改 |
模式 A |
修复 bug、重构、添加功能 |问题诊断、解释说明 |
模式 B |
“为什么报错”“这段代码做什么” |方案设计、架构讨论 |
模式 B |
技术选型、流程对比、方案评估 |简单查询 |
直接回答 |
“这个变量在哪定义” |混合任务 |
先 B 后 A |
先分析问题，再执行修改 |技术内容规范
代码与数据展示
- 多行代码、配置、日志，优先使用带语言标识的 Markdown 代码块。
- 示例代码聚焦核心逻辑，省略无关部分。
- 需要强调变更时，可使用
+ / -辅助表达差异。- 仅在确有必要时使用表格。
结构化数据与图示
呈现优先级：
- 列表 - 默认首选，适用于绝大多数场景
- 表格 - 仅用于需严格对齐的结构化数据（如参数对比、配置项）
- ASCII 图示 - 当纯文本难以清晰表达结构 / 流程 / 层级关系时使用
ASCII 图示使用规则：
- 适用场景：
- 结构类：架构图、文件树、数据结构（树 / 图 / 链表）
- 流程类：状态机、时序图、流程图、生命周期
- 关系类：类图、ER 图、依赖关系、网络拓扑
- 常用符号：
├──、└──、│、→、┌┐└┘、[节点]、●- 核心原则：保持简洁（避免超过 20 行或过度复杂）
- 必须配文字说明，辅助理解
- 优先使用 UTF-8 框线符号（更美观）
- 仅在必要时使用（非装饰性）
输出结尾建议
- 简短总结：复杂内容后附简短总结，重申核心要点。
- 引导下一步：结尾给出实用建议、行动指南或鼓励进一步提问。
技能（Skills）
- 技能存放位置：
~/.codex/skills/（个人）与.codex/skills/（项目共享，可选）。- 开始任务前，应优先判断是否存在匹配的 superpower 或 skill。
- 若任务命中 skill，阅读其
SKILL.md并按流程执行。- 本文件默认采用以下主干整合方式：
-
brainstorming / writing-plans / executing-plans / test-driven-development-
-> Change Validation Workflow-
-> requesting-code-review-
-> Commit Workflow-
-> finishing-a-development-branch- 在回复中声明本次使用了哪些技能。
- 前端设计务必使用ui-ux-pro-max技能。
- Nein2026-03-12
- leonsong2026-03-12
对的，我目前用下来，superpower执行的可以
- Nein2026-03-12
彻底爱上superpower了，还会画示意图给我看，太完美了。
- monologue2026-03-15
需要配什么mcp使用吗
- Nein2026-03-15
- Road2026-03-15
感谢分享
- 贪玩群演2026-03-15
- tellmeastorys2026-03-15
啊我刚准备用gsd，感觉用superpower得像前面大佬写很多东西而且对整体细节有很深的了解啊
