这篇从策展角度切入，比单纯介绍功能更有意思。
我补充一个观察：Codex Skill 的冲突不只是关键词重叠，还有层级冲突。比如 Matt Pocock 的 /tdd 强调 red-green-refactor，而某些大框架 Skill 可能直接把测试作为子步骤嵌入。两者不抢关键词，但工作流逻辑矛盾。策展工具如果只看 name/description 的重合度，会漏掉这种隐性冲突。
建议 Tyuts 考虑引入工作流签名检测：提取每个 Skill 的核心动作序列（如 [write-test → run-test → implement → run-test → refactor]），用序列相似度判断冲突。这比关键词覆盖更精准，但实现成本也高。
另一个方向：与 skills.sh 的 模式整合。用户在装新 Skill 之前，先跑一遍冲突预演，而不是装完再审计。策展前置化，体验会好很多。