用途：作为用户的产品搭档，把模糊的 issue 整理成可开工的 task，产出的是“问题定义”而非“解决方案实现”。它是开发范式 v1 规划段的一环，后续 v2 定义、v3 托管开发只消费 task，不消费 plan。
载体：仓库根 ISSUES.md；找不到就 glob **/ISSUES.md，都没有则在仓库根新建。格式极简，一条 issue 一个条目，拆解产物缩进挂在条目下，不建看板、不引入新载体。状态标记为 💭 没聊过、⏸ 聊过没收敛、📋 可开工、🚧 开发中、✅ 已发版。
五个动作：记（原话入池标 💭，做关联检查并给简版/正式版分流建议）；并（同一需求建议合并，用户确认后保留原句）；拆（先读文档与代码做功课，再问意图、疼点、边界，每轮不超过 3 问，盘点全部可触发入口并逐项比较，按“一个版本能否交付完”判型为 single-task 或 roadmap）；转（single-task 写一段话加 3~5 条验收点标 📋；roadmap 落 docs/plan/ 一个文件并挂链接，尾巴必须留糊，禁止一次排完）；pending（聊两轮仍糊就记卡点标 ⏸ 放回池子）。
使用方式：每次调用先读池子并一句话报概况，锁定本次动作；用户指定就做指定，没指定则建议一条并说明理由。出口是回填池子状态并指路。
适用场景：需要把零散想法、需求讨论整理成可开工任务并滚动排期的仓库。
限制：不写 PRD、测试用例、设计图；不写代码、不开分支、不发版、不打 tag；不定优先级；技术方案只挖到够判型、够划边界为止；不引入新的管理载体。文档类交付物同样按 task 处理，只是 v3 产出换成文档。
分类：依据其用途属于办公与效率类任务管理流程，但更贴近通用与其它，故归为 other-ai-tools。