superpowers 太慢了，每天的工作蹬不完，有没有功能相似但速度快的 skill

可以在全局的 AGENT.md 里对本地 superpowers 进行覆写，按你的实际情况来微调

建议是 把 superpowers 下面的 skill 装上就行 有选择的使用

superpowers 得价值不是一个任务。是你能自己拆出任务让他 10 个 20 个一起跑

https://github.com/mindfold-ai/trellis
这个轻很多

如果高推理模型是刚需，我会先砍流程复杂度：读代码和改代码拆开，探索阶段用轻一点的模型，真正动手时再上高推理。每天都完整跑 subagent 很容易把时间花在调度上，而不是花在关键判断上。

不用把工作拆得太细，很细的话一点点小需求都搞很久，有相关性的话都搓到一起干了就完了，没相关性的话同时干也不会有太大问题。

https://github.com/tw93/waza 这个

之前用 openspec 的，现在直接用 codex 的 plan 了

openspec, grill-me, brainstorming 分场景使用。

写 plan 的时候叫它合并 task

马克，大家用的工具都很强啊。

我用过 superpowers ，也用过 gsd ，这俩最大的毛病是烧 token ，但是好歹能兜底，我现在的工作模式是，维护一个项目的知识库，让 agent 按需加载，另外一个 feature ，先和模型讨论几轮，没问题就动手干，本地有 e2e 的环境，干的好与不好，直接测试一下

你觉得慢的地方在哪一步呢？ brainstorm ？还是 subagent 执行实现的时候慢呢？

之前用 openspec
现在用 trellis

尝试过感觉太慢 太重 还是用回 plan mode 了

@brucedone 我现在是维护项目知识库+业务知识库，有些需求需要修改多个应用，用纯业务知识库感觉会好一点

小活/grill-me ，大活/brainstorming

@maichael 我遇到的 subagent 执行慢，当然这也可能是表象，五一用的 copilot 时，也是让开 subagent 完成，但是比 inline 模式耗时要长。原因没看到，我进入 task 查看，也正常在思考和操作，当时主会话用的 gpt5.5,subagent 指定的是 sonnet4.6 和 gpt5.4 让主会话自己决定。一般 gpt5.5 倾向于执行代码用 gpt5.4 ，check 验证用 sonnet4.6 ^-^。相比于 inline 的 plan 模式，速度差了不少。现在反思的话，中间可能有些我需要 approve 的我去忙别的卡住了费些时间，但是我预估 plan 模式我盯着半天应该能好的

@brucedone 怎么维护一个项目的本地知识库呢？有思路吗？

@wjj5728 用 skills ，agents.md 只留索引，按需加载，其它的就沉淀下来，扫描出来生成知识库，需要的就写入，不需要的就不用写，注意长度和压缩，知识库是给 agent 用的

Mark ，大家都用的很高级

@chenY520 顺便也推荐下这个开发者的 kaku 用着也挺好

mark ，学一下大家的工具

收藏了，学习了

我是建了个 rule ，workflow-superpowers.md 目前感觉还行。根据任务大小自动启动路径
内容如下
`
# 工作流路由

## 1. 任务分流

### Fast Path

适用于：

- 单文件修改
- 明确 bug
- 小范围配置调整
- 边界清晰的文案或规则修订
- 可直接完成并做定向验证的小改动

要求：

- 直接执行
- 约束（不可跳过）：任何 Bash 调用前，必须依据 Memory 中 `critical_rules` 逐条校验即将执行的命令。
如果命令包含被禁操作（如 `rm`、`rm -rf`、修改 Git 状态的命令），必须：
1. 改用替代方案（删除 → `mv` 至回收站 `~/.aicode.tmp/{yyyy-MM-dd}/{HH:mm}/`）
2. 如无可用替代方案，向用户报告冲突，请求指示
3. 不得在未解决冲突的情况下继续当前路径
- 做定向验证
- 默认采用满足质量要求的最短路径
- 最多只问一个真正关键的问题
- 若现有上下文已足够，就不要重复提问

### Standard Path

适用于：

- 多文件修改
- 边界基本清晰，但需要先梳理现状
- 需要对现有结构做局部调整
- 中等复杂度实现，仍可用短路径收敛

要求：

- 先梳理上下文
- 明确改动边界、风险和验证方式
- 分步执行并持续验证
- 优先使用轻量已安装的 `planning-with-files` skill ，而不是先产出重文档
- 根据任务进行情况，维护`planning-with-files` skill 衍生的规划文件，衍生的规划文件里最新产出倒序新增

### Heavy Path

适用于：

- 新功能
- 跨模块重构
- 公共 API 变更
- 三步以上的复杂任务
- 高不确定性或高破坏性任务
- 涉及共享逻辑、持久化、并发、schema 或根配置的改动

要求：

- 进入更重的规划流程
- 先设计，再实施
- 必要时拆分阶段产物和确认点
- 在实现前明确验证门禁和回退边界
- 启动 superpowers`writing-plans`产出 plan,进度与发现维护在`planning-with-files` skill 衍生的规划文件，衍生的规划文件里最新产出倒序新增

## 2. 使用 superpowers 的原则

- superpowers 是工具，不是默认仪式
- 默认采用“满足质量要求的最短路径”
- 能直接完成并验证的，不升级为更重流程
- 能用轻量 `planning-with-files` 解决的问题，不升级为重文档流程
- 轻量任务默认不产出独立 design / spec / plan ，除非用户明确要求、项目规则要求，或确有长期协作价值
- 若用户要求持续推进且风险可控，可在说明假设后继续，不因无谓确认中断

## 3. 流程升级 / 降级

### 升级到更重流程

出现下列情况时，应从 Fast Path / Standard Path 升级：

- 影响边界超出初始判断
- 涉及公共 API 、shared contract 、shared types 、schema 、持久化、并发或共享逻辑
- 需求仍不清晰，无法靠现有上下文收敛
- 验证覆盖不足，无法支持完成声明
- 任务已演变为中大型实现或重构

### 降级到更轻流程

出现下列情况时，可从 Heavy Path / Standard Path 降级：

- 改动局部且边界清晰
- 不涉及共享核心逻辑
- 验证直接、成本低
- 补长计划或补重流程的成本明显高于收益
- 问题已经收敛为单点修复

## 4. 并行与子代理

- 默认先判断是否适合并行；不适合则串行
- 只有在任务能自然拆分为 2-4 个边界清晰、可独立验证、没有明显写冲突的子任务时，才适合并行
- 若根因未明、改动集中在少数核心文件，或拆分后整合成本更高，则不要为了并行而并行

**禁止多个子代理同时修改：**

- `package.json`
- lockfile
- 公共 contract / shared types
- schema / migration
- 全局依赖
- 根配置
- CI
- 同一路由总入口
- 应用总入口
- 环境模板

## 5. 交付门禁

在声明“完成”之前，必须满足：

1. 没有验证证据时，不声称完成
2. 不伪造命令输出、测试结果或退出码
3. 关键验证无法执行时，明确说明阻塞原因
4. 需要用户承担风险的动作，先确认再做
5. 若验证不足，只能降低完成度表述，不能把“未验证”说成“已完成”
6. 能做局部验证时，先给出最贴近本次改动的验证结果
7. 任何涉及 2 个或以上文件的改动，或在 `constants.ts`、`composables`、`types/` 目录中新增/修改，必须在交付前对照 `persona-linus.md` 的审查顺序自查
8. [品味自评核验] （不可跳过）
如果本次改动触及第 7 条的范围，必须检查对话末尾是否已输出 [品味自评] 结论。
如果没有，在交付前补充输出。这条检查的是"规则是否被执行了"，而不是"规则是否存在"。

`