个人codex使用Trellis的简单流程
- 内容介绍
- 文章标签
- 相关推荐
和omo不同，Trellis是典型的花小钱办大事，侵入性低，扩展性强，很适合研究学习并总结出一套属于自己的工作流。
但codex不支持hook，在使用Trellis时会有诸多不便，官方又主要针对claude开发维护，其他平台多少有点疏漏。
但我也没用过claude code，不清楚自己的流程到底符不符合最佳实践，在此分享下以抛砖引玉。希望能有更多的人在codex上使用Trellis，并总结出一套符合codex的最优解。
同时开了三个项目进行测试git位置
第一种
├─.agents
├─.trellis
│ └─.git
└─src
├─backend
│ └─.git
└─frontend
└─.git
第二种，也可以用submodule
├─.agents
├─.git
├─.trellis
└─src
├─backend
│ └─.git
└─frontend
└─.git
第三种 Monorepo
├─.agents
├─.git
├─.trellis
│ └─.git
└─src
├─backend
└─frontend
首先第一种方案很快就被放弃了，因为trellis在$record-session时会自动提交workspace的内容，如果项目根目录没有.git，会导致无法找到git仓库而自动提交失败。
第二种和第三种都行，
工作流程如下：
$start- 输入提示词：“开启一个新task，需要xxxxx. 讨论后执行”
- 讨论几个来回敲定细节，确定实施，并输入提示词：“实施前记得$before-backend-dev/$before-frontend-dev”
- 实施完成，测试功能，review代码
$check-backend/$check-frontend, 看记录一般实施完成后都会自动触发，基本不用手动执行- 手动commit后端，手动commit前端，
$finish-work，当需要更新spec时这里会提示让你先$update-spec- 手动提交的
.trellis文件夹下未commit的内容(比如spec文件夹)
次数多了会发现重复操作太多了，所以可以考虑将重复性的步骤写成skill(本质slash command)
比如第2步，用个简单的$new-task代替：
开启一个新task，要求讨论后执行。功能如下...
比如第6步，前后端git会堆在一起，就可以：
读取更改的文件(除.trellis文件夹外)，并根据更改内容分阶段进行add与commit，并给出commit message和理由，让用户确认后执行
比如第8步：
按要求提交.trellis文件夹内容...
当然这里的skill只是简单描述，按自己需求写就行。
我还在考虑是否要将这些skill融入到trellis
一开始我还在想，如果有些项目只有单个前端单个后端，或者多端怎么办，看了下0.4的changelog，开发者似乎也考虑到了这点，将check-frontend和check-backend都合并为check了。
codex现在的subagent貌似支持的也不错，不知道trellis什么时候能跟进。
其他也没啥了，想到再补充。
--【壹】--：
我个人感觉，openspec 本身没啥强约束的东西，很容易跑偏；
另外 ai 想写出好代码，关键的是项目特化的 coding spec（比如在你的项目里面前端 hook 该放在哪里，后端 db 的 batch 操作具体该怎么用这种），有了这种 coding spec ，ai 写的代码才能符合项目，
而 openspec 的 spec 是纯 prd，只是告诉 ai，你需要实现一个 xx功能，xx 功能的边界是什么，具体有什么小细节，但是没有对 coding spec 的约束
--【贰】--：
codex hook 我们会尽快支持的，正确在这个 beta 版本搞出来（目前团队在忙别的事，最近这两天确实没来得及跟进开发）
--【叁】--：
感谢分享，从零开始的项目流程有吗
--【肆】--：
我一开始是开的
但后面会发现在实施的时候不太方便打：“实施前记得$before-backend-dev/$before-frontend-dev”
完整步骤是plan → $before-backend-dev/$before-frontend-dev → 实施
理论上before-backend-dev/before-frontend-dev应该自动注入，plan偶尔会漏掉这个，而且不太方便补充细节，所以我现在都不用了。
--【伍】--：
感谢大佬
--【陆】--：
辛苦辛苦，现在没有hook正好可以更好的手动把控全局，后续我还打算转到pi-mono，那个才是真的什么都没有。
想顺便问问我这个流程是否符合trellis的最佳实践？
官方文档中，claude code似乎只需要最后record-session，这差别那么大的吗
--【柒】--：
我在 start 的时候，before-backend-dev/before-frontend-dev会自动注入，这个时候实施计划还需要再次before-backend-dev/before-frontend-dev吗
--【捌】--：
感谢分享
--【玖】--：
基本没啥问题；
另外我们自己实测 codex 指令遵循效果其实很好，大部分时候光 $start 一下，在 讨论完再进入 coding 之后，大概率（我自己体感是十次有八次会自动唤起）会调用 $before-dev 的 skill，然后完成之后有概率调用 $check 的 skill（这个概率稍微小一点）；
我们内部简单任务在用 codex 的时候基本也只是 start 一下，coding 结束后 check 一下，最后直接 record 的
--【拾】--：
我自己不爱用 codex 的主要原因是它说话一股味 …
5da39ff0f764bd4bde55f1398c29ad451260×1375 260 KB
--【拾壹】--：
佬，codex 的 plan 在 “开启新task”的时候需要开启吗，还是完全不实用 plan 模式；我在日常用codex plan模式和的时候感觉和Trellis头脑风暴有些冲突
--【拾贰】--：
感谢分享
--【拾叁】--：
感谢分享！强烈点赞！给每一个安利trellis的人点赞！
--【拾肆】--：
感谢佬分享
--【拾伍】--：
mark 一下
--【拾陆】--：
佬，我现在是Codex+OpenSpec的，我看之前的帖子说你们也有用过OpenSpec的，这两个有什么区别嘞，现在使用Codex+OpenSpec发现并不会很遵循文档的内容，导致开发时间拉长之后就容易跑偏了
--【拾柒】--：
感谢佬的思路分享，我现在在使用OpenSpec也是觉得一些重复性流程节点太繁琐，直接封成一个Skill来使用了
--【拾捌】--：
学习一下
--【拾玖】--：
感谢分享
和omo不同，Trellis是典型的花小钱办大事，侵入性低，扩展性强，很适合研究学习并总结出一套属于自己的工作流。
但codex不支持hook，在使用Trellis时会有诸多不便，官方又主要针对claude开发维护，其他平台多少有点疏漏。
但我也没用过claude code，不清楚自己的流程到底符不符合最佳实践，在此分享下以抛砖引玉。希望能有更多的人在codex上使用Trellis，并总结出一套符合codex的最优解。
同时开了三个项目进行测试git位置
第一种
├─.agents
├─.trellis
│ └─.git
└─src
├─backend
│ └─.git
└─frontend
└─.git
第二种，也可以用submodule
├─.agents
├─.git
├─.trellis
└─src
├─backend
│ └─.git
└─frontend
└─.git
第三种 Monorepo
├─.agents
├─.git
├─.trellis
│ └─.git
└─src
├─backend
└─frontend
首先第一种方案很快就被放弃了，因为trellis在$record-session时会自动提交workspace的内容，如果项目根目录没有.git，会导致无法找到git仓库而自动提交失败。
第二种和第三种都行，
工作流程如下：
$start- 输入提示词：“开启一个新task，需要xxxxx. 讨论后执行”
- 讨论几个来回敲定细节，确定实施，并输入提示词：“实施前记得$before-backend-dev/$before-frontend-dev”
- 实施完成，测试功能，review代码
$check-backend/$check-frontend, 看记录一般实施完成后都会自动触发，基本不用手动执行- 手动commit后端，手动commit前端，
$finish-work，当需要更新spec时这里会提示让你先$update-spec- 手动提交的
.trellis文件夹下未commit的内容(比如spec文件夹)
次数多了会发现重复操作太多了，所以可以考虑将重复性的步骤写成skill(本质slash command)
比如第2步，用个简单的$new-task代替：
开启一个新task，要求讨论后执行。功能如下...
比如第6步，前后端git会堆在一起，就可以：
读取更改的文件(除.trellis文件夹外)，并根据更改内容分阶段进行add与commit，并给出commit message和理由，让用户确认后执行
比如第8步：
按要求提交.trellis文件夹内容...
当然这里的skill只是简单描述，按自己需求写就行。
我还在考虑是否要将这些skill融入到trellis
一开始我还在想，如果有些项目只有单个前端单个后端，或者多端怎么办，看了下0.4的changelog，开发者似乎也考虑到了这点，将check-frontend和check-backend都合并为check了。
codex现在的subagent貌似支持的也不错，不知道trellis什么时候能跟进。
其他也没啥了，想到再补充。
--【壹】--：
我个人感觉，openspec 本身没啥强约束的东西，很容易跑偏；
另外 ai 想写出好代码，关键的是项目特化的 coding spec（比如在你的项目里面前端 hook 该放在哪里，后端 db 的 batch 操作具体该怎么用这种），有了这种 coding spec ，ai 写的代码才能符合项目，
而 openspec 的 spec 是纯 prd，只是告诉 ai，你需要实现一个 xx功能，xx 功能的边界是什么，具体有什么小细节，但是没有对 coding spec 的约束
--【贰】--：
codex hook 我们会尽快支持的，正确在这个 beta 版本搞出来（目前团队在忙别的事，最近这两天确实没来得及跟进开发）
--【叁】--：
感谢分享，从零开始的项目流程有吗
--【肆】--：
我一开始是开的
但后面会发现在实施的时候不太方便打：“实施前记得$before-backend-dev/$before-frontend-dev”
完整步骤是plan → $before-backend-dev/$before-frontend-dev → 实施
理论上before-backend-dev/before-frontend-dev应该自动注入，plan偶尔会漏掉这个，而且不太方便补充细节，所以我现在都不用了。
--【伍】--：
感谢大佬
--【陆】--：
辛苦辛苦，现在没有hook正好可以更好的手动把控全局，后续我还打算转到pi-mono，那个才是真的什么都没有。
想顺便问问我这个流程是否符合trellis的最佳实践？
官方文档中，claude code似乎只需要最后record-session，这差别那么大的吗
--【柒】--：
我在 start 的时候，before-backend-dev/before-frontend-dev会自动注入，这个时候实施计划还需要再次before-backend-dev/before-frontend-dev吗
--【捌】--：
感谢分享
--【玖】--：
基本没啥问题；
另外我们自己实测 codex 指令遵循效果其实很好，大部分时候光 $start 一下，在 讨论完再进入 coding 之后，大概率（我自己体感是十次有八次会自动唤起）会调用 $before-dev 的 skill，然后完成之后有概率调用 $check 的 skill（这个概率稍微小一点）；
我们内部简单任务在用 codex 的时候基本也只是 start 一下，coding 结束后 check 一下，最后直接 record 的
--【拾】--：
我自己不爱用 codex 的主要原因是它说话一股味 …
5da39ff0f764bd4bde55f1398c29ad451260×1375 260 KB
--【拾壹】--：
佬，codex 的 plan 在 “开启新task”的时候需要开启吗，还是完全不实用 plan 模式；我在日常用codex plan模式和的时候感觉和Trellis头脑风暴有些冲突
--【拾贰】--：
感谢分享
--【拾叁】--：
感谢分享！强烈点赞！给每一个安利trellis的人点赞！
--【拾肆】--：
感谢佬分享
--【拾伍】--：
mark 一下
--【拾陆】--：
佬，我现在是Codex+OpenSpec的，我看之前的帖子说你们也有用过OpenSpec的，这两个有什么区别嘞，现在使用Codex+OpenSpec发现并不会很遵循文档的内容，导致开发时间拉长之后就容易跑偏了
--【拾柒】--：
感谢佬的思路分享，我现在在使用OpenSpec也是觉得一些重复性流程节点太繁琐，直接封成一个Skill来使用了
--【拾捌】--：
学习一下
--【拾玖】--：
感谢分享