| name | to-ctx |
| description | 把当前对话的结论写成一份规范的 context 文档,放进项目 context 体系的正确位置。触发语:/to-ctx、「写进 contexts」「落个 context」「把这个结论归档」。先查放置规则(如 CONTEXT_MAP.md),按项目的既有风格写,最后汇报路径。 |
| metadata | {"short-description":"把结论归档进 context 体系"} |
to-ctx
把这个 session 敲定的东西——一个决策、一份调研结果、一个设计、一次排查记录——变成放对位置的持久 context 文件,让未来的 session 不必重新发现一遍。
语言:context 文件用项目文档本身的语言写(看邻近文件),不一定是对话的语言。聊天回复跟随用户。
步骤
- 定位 context 体系:找到项目的持久层和它的放置规则——地图文件(如
contexts/CONTEXT_MAP.md)、docs/ADR 约定或目录 README。项目自己有 context 管理 skill 的,以它的规则为准,本 skill 只当入口。项目没有 context 体系的,先向用户提议一个位置,再动手创建。
- 挑出持久的部分:保留决策及其理由、带来源的已验证事实、发现的约束、开放问题。丢掉过程噪音:探索的死胡同、工具日志、中途的误解。内容已有落盘处的(issue、PR、别的 context 文档),引用它,不复制。
- 对齐既有风格:先读一两份邻近的 context 文件,照它们的结构、标题、命名和日期惯例写。
- 先查位置再写入:按地图文件的放置检查先行,不要写完再挪。
- 汇报:聊天里给一行摘要、文件路径、它在地图里的位置。新文档需要登记进地图文件的,同一次改动里一并更新。
规则
- 一个事实一个家:已有文档记载的事,永不另建第二份事实源——改它或引用它。
- 仓库自己的放置规则永远优先于本 skill 的默认值。
- 不 commit 不 push;归档文档就是交付物,版本控制留给用户自己的流程。