القائمة
想法还模糊时的讨论入口，做分诊后路由到 feature-design / feature-brainstorm / roadmap。采用逐支澄清方法：沿决策树按依赖顺序推进、单题串行并给建议答案，可由代码验证的问题先查代码。AI 是思考伙伴不是记录员。触发：用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"、"grill me"。不处理 bug 和重构。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
维护 `.kflow/architecture/` 这份只记现状的系统地图，三种模式 update / check / backfill。触发：用户说"刷新 architecture"、"做架构检查"、"补这个模块的架构文档"、"方案和代码对得上吗"，或 feature 阶段需要先做架构动作。不写未来规划（走 k-roadmap）。
feature 流程阶段 3——验收闭环：对照 design 核实现 + 回写 architecture / requirement / roadmap，最后产出 {slug}-acceptance.md。触发：用户说"功能写完了验收一下"、"做最后检查"、"准备 merge"、"出验收报告"。前置依赖 k-feat-impl 完成。
feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入，拍板后抽出 checklist。触发：用户说"开始设计方案"、"写 design doc"、"准备实现 XX"，前提是已知道做什么、为谁、怎么算成功。
feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进，每步具体改哪个文件由 implement 自决，写完用统一格式汇报。触发：用户说"方案确认了开始实现"、"按方案写代码"、"开工"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。
issue 流程阶段 2——读 report + 读代码定位根因、评估风险，给用户 2-3 个修复方案让 TA 拍板。这一步不改代码。触发：用户说"分析这个 bug"、"找根因"、"定位问题"，且已有 {slug}-report.md。
issue 流程阶段 3——按已确认根因和方案定点修复、验证、写 {slug}-fix-note.md 落档。两个入口：标准路径从 analyze 来，快速通道从 report 直接来。触发：用户说"开始修 bug"、"按分析修"、"动手改代码"。只动方案声明的文件，不顺手优化。
| name | k-brainstorm |
| description | 想法还模糊时的讨论入口，做分诊后路由到 feature-design / feature-brainstorm / roadmap。采用逐支澄清方法：沿决策树按依赖顺序推进、单题串行并给建议答案，可由代码验证的问题先查代码。AI 是思考伙伴不是记录员。触发：用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"、"grill me"。不处理 bug 和重构。 |
brainstorm 是"讨论层"统一入口。
三件最重要的事：
共享路径和命名约定看
.kflow/reference/shared-paths.md。
| case | 规模 | 用户状态 | 产物 |
|---|---|---|---|
| case 1：已经够清楚 | 不限 | 一句话能说清做什么 / 为谁 / 怎么算成功 / 不做什么 | 不落盘，直接 k-feat-design |
| case 2：小需求 | 单 feature | 知道要解决什么问题，对解法 / 边界还摇摆 | .kflow/features/{feature}/{slug}-brainstorm.md → k-feat-design |
| case 3：大需求，拆解 ready | 多 feature | 心里已有大致模块划分，想直接做拆解和接口契约 | 不落盘，移交 k-roadmap |
| case 4：大需求，先发散存档 | 多 feature | 还不想拆——想先深挖、发散、产生想法存着 | .kflow/brainstorms/{slug}/brainstorm.md → 之后 k-roadmap 读到 |
判错 case 不是灾难——允许升降级。case 2 聊着发现范围越聊越大切 case 3/4，case 3 聊着发现需要先深挖切 case 4，case 4 深挖完可以直接拆切 case 3，当场切换出口。
每次都做，但按需加载正文：
.kflow/attention.md 是否存在；Glob .kflow/ 顶层和 architecture/、features/、roadmap/、brainstorms/、requirements/、compound/ 的目录名 / 文件名。缺 attention.md 视为骨架不完整，不回退读外部 AI 入口。默认不读 attention 全文；要做 spike / 落盘 / 触碰代码前再读短清单rg 文件名和 frontmatter / 标题 / slug。只读取命中的正文；没有命中就不要为了"熟悉项目"打开架构总入口或历史 featurefeatures/ 下有名字相近的 brainstorm？roadmap/ 下有相近子目录？brainstorms/ 下有相关创意记录？brainstorms/ 下有相关创意记录 → 读完汇报"之前 {日期} 存过一份脑暴记录，方向是 {…}，接着聊还是直接拆 roadmap？"k-issue，重构走 k-refactor不是填表——分类题问太多用户觉得在走流程。
用户只说一个模糊词 / 短句（"我想要一个权限系统"、"想聊聊通知"）：
一句话先对齐：你想解决的是 {AI 复述的问题} 对吧？这块你脑子里多大范围——是"加一个小能力"那种一个 feature 能装下的，还是"一整块新子系统得分几轮做"的规模？
用户带着方案来（"我想做 X，里面有 a/b/c"）：
复述一下看对不对——你想解决的问题是 {P}，打算做 X 包含 a/b/c。这里 a/b/c 合起来更像一个 feature 能搞定，还是三件互相有依赖的事要分几轮？
用户自己拆成多件 → 多 feature 规模，追问"想直接拆 roadmap 还是先深挖后存着？"→ case 3 或 case 4；a/b/c 是同一件事的不同面 → case 2；用户听完复述说"对就是这个想清楚了"→ case 1。
判 case 信号（用户说不清就 AI 自判）：
以下对话方法对 case 2 和 case 4 通用。case 2 最终要收敛到一个选定方向，case 4 可以更开放、不强制收敛。
1. 区分"用户说的"和"用户要的"——开口第一句往往是 TA 想到的方案不是真要解决的问题。听到"我想做 X"先别顺着聊方案，先问"X 是为了解决什么场景下的什么问题"。常见发现：真问题不是 X 能解决的，或有更小、更轻、完全不同方向的解法。一旦进 design 方向就焊死——在用户自己还没意识到之前完成这件事是 brainstorm 阶段最大价值。
2. 用户带着方案来时先评估再接受——不要直接进入"那我们聊聊 a 怎么做"。先做：
评估完发现方案确实合理 → "我觉得这个方向 OK 建议直接进 design"，别为凑流程硬发散——当场升级 case 1。
没有固定步骤。三个动作随时可回到上一步：
逐支澄清方法（case 2 / case 4 默认工作方式）：
confirmed / rejected / open question 之一，避免原地打转挖问题——按姿态 1 把"真正要解决的问题"问清楚，能用一句话复述、用户说"对就是这个"为止。这一步价值最高不要急着跳过
深挖模式（按需启动，默认不开）
默认走轻问——一次复述对上就推进。下面任一信号出现切到深挖模式加深：
深挖模式硬约束（防止没完没了）：
confirmed / rejected / open question；连续两轮都只产生 open question 就退到发散或提议 spike发散——确认问题后再谈方案。提 2-3 个具体候选方向（用户带的方案算其中一个），每个 1-2 句描述 / 价值 / 代价。至少有一个反直觉候选（反转 / 去掉常见约束 / 跨领域类比）。所有候选呈现完再给推荐——先锚定再补别的会污染用户判断
收敛——选定方向后轻轻勾勒：核心行为？明显不做？最大未知？给 design 热身不是替 design 决定
讨论中冒出"这个方向能不能走得通要看 X 实际是不是 Y"——不要靠脑补辩论，停下来花 5-30 分钟搭个最小 demo 验一下比再聊三轮更省时。
默认不做——大多数 brainstorm 是在比较权衡，demo 帮不上忙。同时满足下面三条才主动提议：
k-feat-ff 直接做或拆成正式 feature提议格式："这块靠想不准，我做个最小 demo 验一下 {要验的事}，5-10 分钟，OK 吗？" 用户秒过 / 拒绝即可。
spike 落地约定：
.kflow/features/{feature}/ 下（和 brainstorm note 同目录），文件随便起名（spike.py / try-{topic}.ts）.kflow/brainstorms/{slug}/，跟 brainstorm.md 挨着{路径}）"，避免 design / roadmap 阶段再起疑重做case 1 / case 3 也能借这个动作（不强求落 brainstorm note），逻辑一样：事实存疑 + 改变方向 + 成本可控。
信号：一句话能说出做什么 / 为谁 / 怎么算成功 / 不做什么；聊两句核心行为 / 成功标准都对上。
处理：
k-feat-design——brainstorm 对你没增量"退出："直接触发 k-feat-design 从零写 design"（不落盘）；轻量落盘则"下一步 k-feat-design 会读到 {路径} 不必重述"
信号：知道要解决什么问题、大致做哪块，一个 feature 能装下，但对解法 / 边界还摇摆。
怎么聊：按上节"怎么聊"工具箱推进——挖问题 → 发散 → 收敛。收敛到选定方向后落盘。
升降级：
落盘：收敛完成后写 .kflow/features/{feature}/{slug}-brainstorm.md。
目录约定：
只在用户确认进 design 那一刻落盘——对话期间不写文件。status 固定 confirmed，没有 draft。
文档模板见同目录 reference.md 的"feature brainstorm 模板"。frontmatter 字段口径跟 design / acceptance 共用一组，看 shared-frontmatter.md。
退出：主动问"这块够清楚了可以进 design 吗？"，确认后落盘。如果愿景（用户故事 / 痛点 / 边界）已经聊透了，提示用户可以先 k-req draft 把愿景落成 requirement，design 会读到这份 req 做对齐。告诉用户"下一步 k-feat-design 会读到 {路径}"
信号：多 feature 规模，用户心里已有大致模块划分，能说出拆法，想直接做拆解和接口契约。
处理：
k-roadmap 会做拆解和依赖梳理，我把讨论交给它"roadmap new 自己建目录和主文档退出："移交给 k-roadmap"（附聊到的要点汇总），不落盘
信号：多 feature 规模，但用户说不清模块边界、想先发散探索——"帮我问问清楚"、"先把想法理一理存着"、"方向还乱，聊开了再说"。
这是创意空间，不是设计文档。目标是产生可留存的想法、方向和洞察，供后续 roadmap 消费。
怎么聊：启动深挖模式（见上节"对话节奏 > 深挖模式"），同时自由发散——聊方案、聊类比、聊技术可能性、聊限制。对话比 case 2 更开放，不急着收敛。
升降级：
落盘：用户说"先这样"/"差不多了"/"存一下"，或 AI 判断深挖已到 3-5 轮上限，主动说"这块我先帮你落到 brainstorms 里，之后 roadmap 会读到"。
路径：.kflow/brainstorms/{slug}/
.kflow/brainstorms/{slug}/
└── brainstorm.md 创意记录
目录不存在就创建。slug 根据方向自拟英文小写连字符。
文档模板见同目录 reference.md 的"open brainstorm 模板"。
doc_type: brainstorm 区别于 case 2 的 feature-brainstorm和 roadmap 的衔接：k-roadmap 启动时会搜 .kflow/brainstorms/ 看有没有相关 brainstorm。如果有，roadmap 把 brainstorm 当输入材料读，不重复分诊直接拆。
退出：落盘后告诉用户"想法存到 {路径} 了，准备好了就触发 k-roadmap，它会读到这份脑暴记录"。如果深挖过程中愿景（用户故事 / 痛点 / 边界）已经比较清楚了，提示用户可以先 k-req draft 把愿景落成 requirement，后续 roadmap 拆解和 design 都有稳定对齐基准