“Comet 把 **eval 证据作为 publish 的强制门禁**——没有当前 draft hash 的 eval 证据、eval 失败、或证据对应旧 hash，都不能 publish”， 这句话来自于comet-any那部分的创建和分发的介绍，这个组合Skill的功能还没有达到生产级，大概GPT 5.4-5.5时代做的，初版写完之后就没打磨了，在这个功能上要做的东西很困难，代码随时可能发生

佬我没有深度使用过Trellis的skill，所以在Skill上其实我不太了解Trellis，从文档的观感上我觉得Trellis强调的是团队化的规范，有一些共同的观点比如跨设备跨会话的恢复要在Skill侧做，其他的有些类似的技术，比如自动推进等等。其实通过对比文档和具体实现过程我觉得还是能感受到两者的设计仅仅是一些使用技术的类似，想要解决的问题是各不相同的，Comet从诞生开始到后续围绕打造的东西

欢迎体验comet佬，感受下批量澄清的特点~ ^-^

我其实觉得如果太小的调整不需要记录的话直接改就行了，git提交记录就是最好的答案，如果确实是需要记录的，直接告诉native并说跳过澄清，他能够把你的内容记录澄清文档里面，由于验收的内容比较少我理解跑完流程也不需要多少时间，native就是根据前期记录的文档多少当成依据的

如果是一个父目录下来有多个git仓库，其实在父目录去初始化comet就可以用了，不过如果需要change跟着某个仓库跑，那么需要在这个仓库中去初始化，尤其是在各自仓库里面有独立演进式的需求的时候，我在开发comet的时候里面有挂载一个gitsubmoudle的git仓库，用于同步一些文档，那个仓库就是没有初始化过comet的，但是comet主目录有初始化过，一般在主目录里面描述要去子目录做的事情也