大家日常开发需求 Debug 都是用 Superpowers 或者其他工作流吗？

https://github.com/mattpocock/skills 这套用着挺顺手

同推荐 mattpocock 这套 skill ，我也认同这套 skills 的理念。

@YanSeven 谢谢，看了下就是安装以后日常对话就能自动触发对应的 skills 吗？没有写 spec 那么重，但是不清楚效果怎么样，不知道会不会漂移😂

@NakanoAzure 自己主动用 slash command 触发，cc 里面是/, codex 里面是$，可以自己实践看看。主要是比较轻量。

matt 这套是基本全部需要手动/skill 名称进行触发的，而且面向的更多是维护开源项目的 github 流程，如果不是这套流程的话用这一整套会非常难受，建议是试一试之后如果不合适就摘出来其中一些 skill 拿来自己单独用而不是用他那一整套
superpowers 的问题其实是约束力不强，从脑爆到子 agent 开发都是强触发引入流程，但是到后面就放飞了，没有哪个模型在子 agent 开发后还能继续按照他那套流程继续走的，最后结果就是留一堆过时的无维护的 spec 文档

@KorenKrita #5 所以目前还没有比较完美的解嘛

或许试试 claude 官方的 featuredev
轻量的多也挺好用

@ovtfkw 我自己是使用 Trellis+自己大杂烩从各个框架和个体 skill 里摘抄的 skill 做成自己的 market 订阅分组 plugin 做的比较适合我的工作流，通过规则改成自己喜欢的样子以及改名，github action 同步上游自动提 pr 我来审核是否跟随上游修改
https://github.com/KorenKrita/skills
对于轻量项目就用大杂烩 skill 梭了，自己维护的独立项目或者其他需要完整流程的在项目内初始化 Trellis
Trellis 的好处是只有 continue 和 finish 这两个 command ，实际真正用到的只有 finfish ，就是这个 session 结束时候的收尾打扫。感觉对于需要完整流程的项目是比较友好的，跨 session 也如一。并且和我其他的 skill 也可以完美融合，以任何 skill 找到问题或者提出想法，通过 Trellis 转为 task 并写相关文档，然后进入他的流程开发，出流程后还可以继续接我其他的 cr 相关 skill 去做后续收尾动作

@SeduceQAQ Claude 公司给了账号但是额度太少了几乎用不了，我现在只把 Claude 当做 Review Codex 代码的对抗式的 Agent 了。。。

如果日常用 Codex 有啥推荐吗😂感觉 Openai 这方面真的是没什么创新全是 Anthropic 来引领这种趋势

@KorenKrita 嗯，感觉现在没有什么完美的方案 resolve ，不过我们组最近倒是自己在搞什么 workflow ，贴合自己业务的那种工作流想把流程全自动化，但是效果感觉也一般，感觉未来如果模型变得更强了现在做的全是一些过渡工作，但是感觉现在就是没有一个最佳实践，或者说有些东西太重太费 token 了。。

@KorenKrita 他这一套也容易爆上下文特别是 grill-me 相关的， 一个问题一个问题的澄清，在需求阶段很容易爆上下文， 需要你强制让 ai 隔一段时间提醒 ai 把共识写进文档里

https://github.com/linziyanleo/spec-anchor

自己平时工作流总结的，同事尝试了之后感觉还不错 ⬆️ 推荐试一试，欢迎反馈

今年是哪年了还 skill ，写通用代码就什么都不要装，装了反而影响 codex 自己的流程
只写编码规范和约定即可

如果是 debug, $superpowers:systematic-debugging 大部分情况下不会给你写一个 spec 。

如果是开发，$superpowers:brainstorming spec 我是不提交的，除非一些大的 feature 。不提交的 spec 实际上不需要维护，提交的 spec 封存掉就行，写上日期，后续改动也不需要再去更新 spec ，即使部分功能和 spec 不太一样。

BTW ，个人理解是在不用 superpowers 的情况下，推荐 AGENTS.md 用 https://github.com/multica-ai/andrej-karpathy-skills 也会舒服很多。

模型能力够，plan 一下基本没啥问题了，还整这些干啥

@kera0a +1 plan 完全够用

@kera0a 主要是考虑一个项目长期维护的话。。。。

@NakanoAzure 我是自己开发了一个工作流模板 https://v2ex.com/t/1220512?p=1#reply11

superpowers 太飘了。我每次都 i 是让 superpowers 帮我做一个计划，然后在它要开 subagent 之前叫停。然后让 claude code 根据它定的 plan ，慢慢的一个一个的做，一个 step 一个 PR 。所以我基本只用 superpowers 的做计划这部分

plan 够了，当然大部分还是我在引导 ai 。如果你让 ai 自治，还是要用 skill…

需求用 superpowers 小的改动、bug 直接对话改了

以前用这些 skill, 现在除了具体工具/任务的 skill 之外别的都靠对话推进了. plan 模式用的都很少, 都是直接普通对话聊想法, 期间还会反复启动大量子代理收集信息补充道对话中. 最后才会用 plan 总结对话形成计划, 或者最近我都不开 plan, 直接让他把我们的对话内容沉到文档里, 然后直接开干. 一个阶段完成后我们会再对一下思路, 然后设计测试和评估方案, 来回反复修修补补, 满意之后再推进下一个阶段. 可能因为我这边研究性质比较重, 所以没什么能固定下来的东西, 也就很少用那些 skill

@Lawskiy 所以感觉现在好像又回归模型本身了，模型越强的话感觉其他的反而是负担。。。。

grill me is all you need

OpenSpec
https://github.com/Fission-AI/OpenSpec

@Younow Superpowers 也能写 spec 啊，openspec 有什么优势吗

以前用 Superpowers ，现在不用了。关于开发相关的 skills 一个都没留，现在模型的智能程度，我觉得这些 skills 意义不大，甚至是负优化，浪费 token 增加多余动作。
向前面几位说的日常复杂的 plan 一下，不复杂的我就直接对话了。
我甚至不迷信 skills 这种玩意了，以前用是因为模型本身有不少注意力问题，自从 goal 模式出了以后，我就开始把这类 skills 、包括那些身份 agent.md 都删了。

@KorenKrita 目前也是用 trellis ，体验还不错。

目前是这样干的，至少效率我很满意
装了上百个 skills 和很多 mcp ，

全局 AGENTS.md 加了两句话
不要太多文字了，我理解不了
看看哪些技能和 mcp 可以调用来做这件事

我把 Superpowers 改了下，就是把所有 spec 部分都删了，brainstorm 后直接动手。

我反正觉得大道至简, skills 里面只留最基础的编码规范就够了, 用 superpowers 我觉得又浪费 token 还容易偏

oh-my-openagent ，感觉挺好用的，会用流程规范化防止 AI 犯错，
不过消耗 token 比较多，

@Hansee goal 模式对 token 消耗怎么样，codex 支持吗

目前用 trellis + https://github.com/mattpocock/skills, 前者用来长期维护 doc, 后者 grill-me 等 skill 启动 prd

openspec 自定义工作流 https://github.com/Fission-AI/OpenSpec/blob/main/docs/customization.md

superpowers 就是个垃圾，简单的需求可以拆成很复杂，子 agent 一跑起来不知道飘到哪里去。业余的用了可以生成一个满足你需求的 UI 。看起来确实是那么回事。但是真正的程序员去看代码就会看到一堆屎山代码

@NakanoAzure 我没太在意一直是 ChatGPT pro 订阅，所以 token 没怎么关注过。codex 支持，我是只用 codex 的。

@ximaoyang 现在就是感觉没有什么最佳实践。。。。

@NakanoAzure 我自己倒是发明了一套，一直在犹豫要不要开源。我的核心是让 ai 写完代码别提交，然后生成一份交 commit request 的东西，格式是这样的：

然后它做完改动就会问你的意见，只有你说 approve 它才会提交代码

-----------把这些写到 CLAUDE.md 里面--------------------

## 单次改动规范(CR 规范)

### 颗粒度

每一次改动保持小颗粒度。颗粒度判断标准：

- **同层改动**：单次改动尽量只改同一层。改 service 就不改 router/view ；改业务逻辑 py 就不改 REST API 层。
- **一句话概括检验**：本次改动的 CR 中，Design （ feature ）或 Solution （ defect ）必须能用一句简短的话概括完。如果需要列多件事才能描述清楚，说明颗粒度太大，应拆分。
- **颗粒度不应过小**：如果本次改动本身就只涉及配置（例如某个 defect 就是配置错误，或本次只改 `CODER.md` / `.gitignore`），则配置单独成一个 CR 是合理的。但如果配置改动是为了支撑业务逻辑改动（例如为新功能新增依赖），则依赖变更与源码改动应合并在同一个 CR 里，不应拆开。
- **改动必须闭合**：每次改动都必须有验证手段，保证不会提交错误代码后再修改。验证方式按优先级：
1. 项目已有对应层的**单元测试** → 随改动一起更新，CR 的 Test Details 写测试摘要。
2. 项目已有**端到端测试** → 随改动一起更新，CR 的 Test Details 写测试摘要。
3. 无自动化测试 → 在 CR 的 Test Details 里写清楚**手动验证步骤**，告诉用户执行哪条命令或操作来验证本次改动正确。
4. 连手动验证都难以做到（例如改动依赖外部环境尚未就绪）→ 在本次改动中附上**临时测试脚手架代码**，CR 注明"下次改动删除脚手架"，下一个 CR 中去除。

### CR （ commit request ）

每次模型修改完代码**必须**不直接 commit ，并且生成一份 CR 。
CR 的作用是改动摘要，方便用户及其他 agent 了解改动。
CR 生成后回显给用户，并写入 `.cr.md` 文件。
只包含**项目规则 md 文件**的改动不用生成 CR

**项目规则 md 文件**: 定义项目规则的.md 文件，比如 `PROJECT.md`, `CR.md`, `TASKS.md`。

**CR 回显规则**：回显给用户的 Chat 版本必须与 `.cr.md` 完全一致，包含所有字段，不得省略任何一项。缺少任何字段的 CR 视为不合规。

#### CR 的 reply

CR 创建后等待用户 reply 。reply 分为以下几种：
- **approve**：回复"approve, <理由>"。进行**reply 后的 CR 文件操作**。最后执行 commit & push 。
- **reject**：回复"reject, <理由>"。回滚所有改动。并进行**reply 后的 CR 文件操作**。
- **remake**：回复"remake"。当 CR 混乱或内容有误时使用。模型基于 `git diff HEAD` 全量 diff 从头生成一份新 CR ，覆盖当前 `.cr.md`，回显给用户后继续等待 reply 。
- **ask**：用户通过多轮提问了解本次改动的细节，不造成任何代码改动。模型只回答问题，不执行任何操作，不重新生成 CR 。用户问完后再做出 approve 或 reject 的决定。
- **modify**：修改。用户可以：1. 自己手动更改并要求模型更新 CR ； 2. 让模型修改代码，模型自动更新 CR 。**更新 CR 时只在现有 `.cr.md` 基础上补充或修正变更内容，不得整体重做**——在受影响的字段（ Source Details 、Source Tree 、Test Result 等）追加或修改对应内容即可。更新后回显给用户并继续等待 reply 。只有收到 `remake` 指令时才从头重写 CR 。

#### reply 后的 CR 文件操作

approve 或 reject 执行完对应操作后：
- `.cr.md` 中增加 **Reply** 段落，写上 reply 的结果和理由。可选的结果有 approve, reject
- `.cr.md` 重命名为 `cr.<timestamp>.md`，`timestamp` 格式 `yyyyMMddHHmmss`
- 移入 `cr` 文件夹（不存在则新建）
- `cr` 文件夹会提交到 git ；`.cr.md` 已加入 `.gitignore`

#### CR 的格式

CR 分为 feature 和 defect 两种。

**Source Tree** 和 **Test Tree** 必须使用 ASCII 文件树格式，不可以用一句话代替，例如：
```
project/
├── src/
│ └── service.py ← updated
└── tests/
└── test_service.py ← new
```

**feature**
- **Design**：本次改动的设计摘要
- **Source Details**：源码核心细节，1~2 行代码，简短，不含测试改动
- **Source Tree**：本次改动的源码文件树（ ASCII 树）
- **Test Details**：测试改动摘要。细节见 **CR 的测试方式**
- **Test Tree**：本次改动的测试文件树（ ASCII 树）；细节见 **CR 的测试方式**
- **Test Result**：测试的结果。细节见 **CR 的测试方式**

**defect**
- **Root Cause**：defect 的根本原因
- **Solution**：修改方案摘要
- **Source Details**：源码核心细节，1~2 行代码，简短，不含测试改动
- **Source Tree**：本次改动的源码文件树（ ASCII 树）
- **Test Details**：测试改动摘要。细节见 **CR 的测试方式**
- **Test Tree**：本次改动的测试文件树（ ASCII 树）；细节见 **CR 的测试方式**
- **Test Result**：测试的结果。细节见 **CR 的测试方式**

#### CR 的测试方式
CR 中可选的测试方式有端到端测试，单元测试，无测试。他们有不同的处理方式。
**无测试**
本次改动不需要测试，比如更新 `PROJECT.md` 的文本内容，修改 `.gitignore` 等
- **Test Details**： `无变更`
- **Test Tree**： `无变更`
- **Test Result**： `无变更`

**单元测试**
模型自己在 `tests/unit`下新增，更改单元测试，执行单元测试，将执行结果摘要写入 Test Result （通过/失败条数、失败原因）
- **Test Details**：写出本次单元测试的测试目的，方式的摘要
- **Test Tree**：本次改动的测试文件树（ ASCII 树）
- **Test Result**：单元测试的结果

**端到端测试**
模型自己在 `tests/e2e`下新增，更改端到端测试，执行端到端测试，将执行结果摘要写入 Test Result
- **Test Details**：写出本次单元测试的测试目的，方式的摘要
- **Test Tree**：本次改动的测试文件树（ ASCII 树）
- **Test Result**：端到端测试的结果

@ximaoyang 谢谢，学习一下