把"大到塞不进单个 feature"的需求做成完整事前规划:概设 + 接口契约 + 子 feature 拆解清单,放在 `.codestable/roadmap/{slug}/`。两种模式 new / update。触发:用户说"我想要一个 X 系统"、"帮我把这块需求拆一下"、"开一份 roadmap",或…
cs-roadmap 启动必读 开始任何判断或动作前,先读取 .codestable/attention.md;缺失则视为骨架不完整,提示先补齐或运行 cs-onboard,不要回退到外部 AI 入口文件。 .codestable/roadmap/ 是项目的"规划层"——每个子目录承载一块大需求,主文档由三块构成: 概设:这块大需求要怎么搭、拆成哪几个模块 / 组件、各自职责 架构层详设:模块之间的接口契约、共享数据结构、跨 feature 的协议 子 feature 拆解:把方案分解成一串带依赖关系的子 feature 种子,feature 流程一次消费一条 三块一起作为这块大需求所有子 feature 的共同约束——每条子 feature 进 cs-feat-design 时,roadmap 第 2 块的接口契约就是它的硬约束输入(不能违反,要改先回 roadmap update)。 为什么 roadmap 承载架构方案不放进 architecture/:cs-arch 守"只记现状不记计划"。前瞻性架构方案属于"还没落地、可能还会变"的事前规划,放进 architecture 会污染那份系统地图。等子 feature 真正落地,对应接口由 cs-feat-accept 提炼回 architecture/——roadmap 完成过渡使命后归档。 为什么单独一层:requirements 记"要什么"(愿景)、architecture 记"怎么搭"(结构)、roadmap 记"怎么分步实现"(执行)。把执行规划塞进愿景或结构文档会把"要什么"和"打算怎么实现"混起来——查不到系统真实能力,计划改一下又得改两份文档。 为什么文件夹不是单文件:拆解过程会产生草稿 / 调研 / 方案对比 / 白板转述,塞一份 md 会乱又舍不得删。每个 roadmap 一个子目录,主文档对外口径,旁边 drafts/ 随便堆。
don't have the plugin yet? install it then click "run inline in claude" again.