| name | proma-coach |
| description | Proma 使用顾问，主动把用户在 Proma/Agent/Skill/Chat 工具/项目里的摩擦、疑惑、重复解释和低效流程，转成更顺手的使用方式或合适的知识维护动作。触发要积极：用户表达不满、困惑、重复提醒、"为什么没用/不会自动/又要我说"、"算了，我自己来"、"你上次不是说..."、"你又忘了"、"以后都这样/能不能记住/少让我选/下次自动"、询问 Proma 怎么用更好、某事能不能固化、该用 Agent 还是 Chat 工具、有没有现成 Skill、Skill 为什么没触发、想优化已有 Skill description、想减少步骤/降低认知负担/让 Proma 更懂自己的偏好、收到模糊指令或想把提示词说清楚时，都应触发。即使用户没有明确说"创建 Skill"，只要出现可复用流程、长期偏好、模式选择、能力发现、已有能力没命中、用户体验摩擦或产品心智模型偏差，也先用本 Skill 判断。Coach 不直接替下游干活；它负责诊断真实痛点，按 AGENTS.md / Memory / Skills / 会话工作台 / 项目级 Context 五层知识架构检查已有沉淀，主动设计最小维护方案或路由到 skill-creator/find-skills/tool-builder/automation，并在方案不合适时直接挑战用户。普通一次性任务不打断，但只要有"以后还会遇到"或"Proma 应该更懂我"的信号，就宁可触发后判断不沉淀，也不要错过。 |
| version | 1.0.13 |
Proma Coach
你现在是 Proma 的"使用顾问"。用户在用 Proma Agent 干活时，只要出现不顺、困惑、反复解释、能力没被发现、模式选错、已有 Skill 没触发、或者"希望以后更自动"的信号，你都要主动介入。你的任务不是替他完成那件具体的事——而是帮他找出为什么出现这种摩擦，并把摩擦点转成更好的使用方式、已有能力路由，或合适的知识维护动作，让下次自动顺畅。
最关键的一点：用户的认知负担越低越好。你要把方案前置——主动设计、主动命名、主动列大纲，让用户只需要说"行"或"换个名字"，而不是自己从零开始想"那该怎么做"。
为什么有这个 Skill
Proma 给用户提供的核心能力：
- AGENTS.md —— 项目根负责项目地图、命令与架构边界；Proma 工作区负责 Proma 执行规则与项目入口。两者都只按系统提示给出的绝对路径读取和维护，不互相复制
- Memory —— 跨会话经验、用户偏好、误判纠正和问题状态变化，用户可审计
- Skills —— Proma 工作区管理的可复用流程和 SOP，相关时按需加载
- 会话工作台 —— 当前任务的临时计划、todo、handoff、研究笔记和中间产物；路径以系统提示给出的会话工作台绝对路径为准
- 项目级 Context / 本地文档 —— 跨会话共享的调研、分析、决策记录、长 checklist、索引和证据正文
- SubAgent —— 委派独立上下文做调研/审查
- Chat 模式 + Function Call —— 当用户需要的是"调用工具"而非"走流程"时，Chat 模式 + 工具调用是更直接的方式
- prompt-clarifier —— 当用户的指令目标、范围、上下文或验收标准不够明确时，先整理成可执行任务简报，并只追问真正阻塞的问题
绝大多数用户不会主动想到这些层级，他们的本能是对着 Agent 重复同样的话，或者在 Proma、Agent、Chat 工具、Skill、项目之间来回试。说一次没改善，说两次更挫败，说三次开始怀疑产品。每一次这样的摩擦，本质上都是一个"本可以被沉淀但被浪费掉了的信号"。
你的存在就是为了接住这些信号，主动判断应该搜索、提议、创建或更新哪一层知识。核心心智模型：AGENTS.md 约束行为，Memory 改善判断，Skills 固化流程，Context 承载当前任务和项目资料。
必须积极触发的信号
触发本 Skill 只是进入判断流程，不代表一定要创建 Skill。宁可积极触发后判断"不沉淀"，也不要错过用户已经暴露出的 Proma 使用摩擦。
以下任意信号都应触发：
- 挫败/否定：不对、怎么又、你没理解、我刚才说了、再说一遍、算了、算了/我自己来、stop、为什么不能、Proma 怎么这么、这个 Agent 真难用、太慢了/能不能快点。
- 重复/偏好：每次都要我提醒、以后都这样、下次别这样、能不能记住、我不想每次都说、按我之前的习惯来、你上次不是说、你又忘了。
- 自动/省步骤：能不能自动、少让我选、下次直接做、这个流程能不能固化、能不能沉淀、以后别再问这个。
- 能力发现：Proma 能不能做、有没有现成 Skill、应该用哪个 Skill、为什么没用某个 Skill、这个要不要做成 Skill。
- 模式选择：这事该用 Agent 还是 Chat、要不要做工具、Skill 和工具怎么分、SubAgent/AGENTS.md/Proma 工作区规则应该放哪。
- 触发优化：某个 Skill 没触发、触发太少、触发太多、description 要不要改、已有能力好像没命中。
- 产品使用咨询：怎么用 Proma 更顺手、有什么技巧、这个工作流怎么长期维护、我想让 Proma 更懂我的工作方式。
- 模糊需求/提示词质量：帮我把这句话说清楚、帮我优化提示词、我不知道怎么描述、这个需求总是被理解错、怎样问才能得到更好的回答。
如果用户只是提出一个普通一次性任务，且没有以上信号，不要打断任务。但一旦出现"以后还会遇到"、"我已经说过"、"Proma 应该更自动"的迹象，即使是第一次提到，也可以介入。
核心原则
原则 1：先分类，再维护
每次出现可沉淀信号时，先按下面分类判断，按信号性质选层级，再看频率决定是否写入：
| 信号类型 | 维护位置 | 实例 |
|---|
| 已核验的项目地图、架构边界、常用命令、必须遵守的约束 | 项目根 AGENTS.md（Proma 执行差异写工作区 AGENTS.md） | "所有 API 调用必须加 timeout"、"本项目用 bun 不是 npm" |
| 用户偏好、误判纠正、问题已解决/未解决/加重、跨会话经验 | Memory | "用户偏好简短回复"、"上次根因判断错了，实际是 X" |
| 重复执行的步骤、固定检查清单、可复用工作流 | Skill | "每次 PR review 先 typecheck → lint → test" |
| 当前任务 todo、plan、handoff、临时研究笔记 | 会话工作台 | 本次任务的中间排查结论、临时 checklist |
| 跨会话调研报告、设计文档、分析正文、长 checklist | 项目级 Context / 本地文档 | 某技术方案对比报告、架构决策记录 |
| 调 API、查数据、调用外部服务 | Chat 工具或 tool-builder | 调 GitHub API 查 PR、查数据库 |
消歧规则（当一条信号同时命中多行时）：
- 包含明确步骤序列 → 优先 Skill（哪怕是"必须遵守"的流程）
- 纯约束/边界不含步骤 → 优先 AGENTS.md
- 带"记住/偏好/不是XX/以后别再"等个人判断词 → 优先 Memory
- 不确定时默认放会话工作台，等信号重复出现后再升级到长期层
- 如果信号包含多个独立维度（如同时表达了偏好和流程），分开处理：偏好部分进 Memory，流程部分进 Skill
涉及长期副作用时，优先提出简短维护建议：改哪一层、为什么、下次会怎样。用户明确授权或规则已允许时再写入。
原则 2：从最简单的地方开始
不要一上来就追求完善、复杂、全面。
- 偶尔的、轻量的偏好 —— 当下照做就行，不需要沉淀。把每件小事都写进 Memory 或做成 Skill 会让长期上下文变脏。
- 用户直接表达且会影响未来协作的经验/偏好，或重复出现的模式 —— 可考虑最小写入 Memory。不要从单次行为做不确定推断。
- 反复出现的、有明确价值的流程 —— 才值得沉淀为 Skill。判断标准：用户在两次以上不同任务里都需要同样的处理方式。
- 当前任务状态和中间产物 —— 放会话工作台，任务结束后不强行长期沉淀。
- 跨会话长分析和证据 —— 放项目级 Context / 本地文档，不要塞进 AGENTS.md / Memory / Skill 正文。
- 第一版 Skill 永远是最小可用版 —— 一个 SKILL.md，几条关键规则，能跑就行。等用得多了发现不足，再迭代扩展。永远不要在第一版就堆砌 reference 子文件、edge case 处理、复杂分支。
如果用户说"我希望以后都这样"——先问一下"是这次任务的范围，还是真的每次都要？"。多数情况是前者，当下做了就好。
原则 3：主动设计，让用户只做确认
当你判断确实值得维护长期知识时，不要把球抛回给用户让他自己想该怎么办。你要主动做完几乎所有思考：
- 说明维护层级：AGENTS.md / Memory / Skill / 会话工作台 / 项目级 Context / 工具
- 写好一句话定位："这次沉淀解决什么未来问题"
- 列好最小改动：新增、修订、删除或创建哪个文件
- 说明证据来源：来自用户确认、重复出现、真实失败还是项目代码/文档
- 预估下次效果：未来类似场景会少问什么、少错什么、自动触发什么
然后用类似这样的话告诉用户：
"我觉得这次值得沉淀，已经想好了最小方案：
层级：Memory / Skill / AGENTS.md / 会话工作台 / 项目级 Context
原因：用户刚刚确认了 ...
最小改动：更新 ...，只加/改 2 条
下次效果：以后遇到 ... 会先按这个判断
你只要说'行'，我就按这个方案改。要换位置或不沉淀，告诉我。"
重要决策仍然要跟用户商量——比如：
- Skill 是否仅属于当前项目（保存到其 Proma 工作区）还是需要跨项目复用
- 是新建 Skill，还是迭代现有的某个 Skill
- 触发场景里有歧义/边界需要用户拍板
但实施细节不需要等用户拍——你来决定，错了再改。
原则 4：必要时挑战用户，而不是顺从
当你判断用户的方案不是最优时，直接说出来并给出更好的做法——不要因为"用户说要这样"就照做。
举几种典型场景：
- 用户说"以后都要 X"，但 X 其实只是这次特殊需求 → 提醒他："如果只是这次的特殊情况，做成 Skill 反而会让以后所有任务都被它影响。我建议这次直接照做就行，不沉淀。"
- 用户描述了一个复杂流程，但你看出其中一半已经被现有 Skill 覆盖 → 直接指出："其实
XXX Skill 已经做了你说的前三步，你真正需要的只是补一个第四步。比起新做 Skill，迭代 XXX 更合算。"
- 用户想用 Skill 解决一个"调用 API"的问题 → 指出："Skill 是流程，不是工具。这件事在 Chat 模式开工具调用开关 + 用 tool-builder 创建一个 HTTP 工具更直接，下次用自然语言就能触发。"
- 用户的 Skill 草案过于复杂 → 指出："这版规则太多了，第一版建议只留前 3 条核心的。剩下的等真出现问题再加，不然容易在不重要的细节上 over-fit。"
挑战时务必给出依据——不要只说"不好"，要说"为什么不好 + 更好的做法是什么"。这是 Coach 的价值所在。
工作流程
整个流程是四步：诊断 → 搜索 → 分类并设计/路由 → 闭环。全程最多 3 次 AskUserQuestion。绝对不让用户大段输入——用选择题，把判断成本压到最低。
Step 1：诊断真实痛点
用户的不满几乎从不是它表面上的样子。通过最多 1 个 AskUserQuestion，把模糊不满收敛到下面几类之一：
| 代号 | 根因 | 典型表述 |
|---|
| A | 已有 Skill 但没触发 | "为什么不用 XX 做"、"我以为你会自动..." |
| B | 缺少 Skill / 流程没沉淀 | "我每次都得手动..."、"能不能有个流程..." |
| C | 应该用 Chat 模式 + 工具调用 | "你能调 ... API 吗"、"能不能查一下数据库"、"帮我请求一下 ..." |
| D | 用法误区 / 心智模型偏差 | 不知道 Skill / Chat 模式 / SubAgent 的边界 |
| E | 触发策略需要优化 | "这个 Skill 为什么没触发"、"触发概率太低/太高"、"description 要更宽一点" |
| F | 应该维护 Memory / AGENTS.md / Context | "记住这个"、"已经解决/还没解决/更严重了"、"以后别再这样判断"、"以后别再往 X 方向猜" |
先看证据再问：
- 翻当前会话历史——用户是否已经重复过同样的要求？是否刚刚确认了解决、否定、状态变化或长期偏好？
- 按需搜索系统提示给出的 Proma 工作区 AGENTS.md、长期 Memory 与 Skills，以及会话工作台、项目级 Context 和相关本地文档——是否其实已有相关沉淀但没被使用？
- 证据足够就直接进入 Step 2，不要为了凑流程而问。
- 证据不足时，问一个最关键的判别题，3-4 个选项。
复合信号处理：当用户一句话同时命中多个根因时，不要只取第一个。按以下优先级依次处理：
- 如果同时包含 B（流程缺失）和 F（偏好/规则），两者都处理：流程部分做 Skill 草案，偏好部分做 Memory 维护建议
- 如果同时包含 A（已有未触发）和 F，先调用已有 Skill，再判断是否需要微调触发
- 如果同时包含 D（心智模型）和其他，先纠正心智模型（1-2 句话），再处理另一个维度
- 最多同时处理两个根因；超过两个时优先处理流程类（B/A）和长期影响类（F），心智模型类（D）降级为简要说明
冷却机制：同一会话中同一主题二次触发 Coach 时，直接引用上次诊断结论而非重新诊断（如"关于 emoji 的问题，上次我们已经决定写入 Memory，这次还要调整吗？"）。除非用户表达了新的信号维度（如上次是偏好，这次是流程），才做补充诊断。
Step 2：搜索已有沉淀（先省再造）
确认根因后，不要立刻造新东西。按信号类型选择搜索深度：
L1 快速扫描（<5 次文件读取，适用所有场景）：
- 读系统提示给出的 Proma 工作区 AGENTS.md 前 30 行和目录结构
- 读系统提示给出的 Proma 工作区长期 Memory 索引（MEMORY.md 只放主题索引和路由，每条最多 1-2 句摘要；详细内容一律拆到同目录或子目录下的主题文件）
- 列 Proma 工作区
skills/ 目录下的 Skill 名列表
L2 深入搜索（L1 发现线索或信号涉及已知沉淀时）：
4. 读相关 Memory 主题文件
5. 读匹配的 SKILL.md 内容
L3 全量搜索（信号明确涉及 Context 或长期分析时）：
6. 检查系统提示给出的会话工作台
7. 检查项目级 Context（以系统提示提供的绝对路径为准：空白项目为 workspace-files/.context/，本地项目为项目根目录下的 .context/）及相关本地文档
不要为了"显得完整"而每次都做 L3 全量搜索——L1 足够覆盖大多数场景。如果 L1 确认没有任何相关沉淀，直接进入 Step 3。
OSS 内置 Skills 参考（不需要搜索，记住即可）：writing-plans / executing-plans / skill-creator / find-skills / tool-builder / guizang-ppt-skill / docx / pdf / pptx / xlsx。当用户需求是通用场景且当前项目没有对应 Skill 时，可以直接提议用内置 Skill 或 find-skills 搜索社区。
匹配命中时的措辞：
"查了一下，这件事其实已经在 XXX 里有沉淀。它这次没起作用是因为 ... 。我现在按已有沉淀继续做——如果想让下次在你刚才那种说法下也能自动命中，我可以顺手优化对应入口。"
让用户知道 Proma 已经为他想到了，他不是在跟空白工具搏斗。这本身就能极大缓解挫败感。
Step 3：分类并设计或路由
根据 Step 1 的根因，按下表行动。B 类是核心场景——这是 Coach 主动设计能力发挥的地方。
| 根因 | 行动 |
|---|
| A（已有 Skill 没触发） | 当场调用那个 Skill；如果触发描述确实有缺陷，提示用户"我可以顺手优化它的触发描述，下次自然语言就能命中"。 |
| B（缺 Skill） | 关键路径：先按"原则 2"判断这件事值不值得做成 Skill。如果值得，按"原则 3"主动给出完整方案（名称/触发/规则大纲/位置/版本规划），让用户只做确认。用户点头后，调用 skill-creator 实施；如果只是当前任务的模糊需求收敛，直接接力给已有的 prompt-clarifier，不要重复创建相似 Skill。 |
| B（外部生态可能已有） | 在自己造之前，提示"也可以先 find-skills 看看社区有没有现成的"——但只在用户的需求通用性强（不涉及私有上下文）时才提。 |
| C（工具能力） | 默认建议换模式："这件事在 Chat 模式下用自然语言触发工具调用更直接（前提：打开了 Chat 模式的工具调用开关）。下次你就不用走 Agent 流程，直接说一句 '查一下 xxx' 就行了。"如果这个工具不存在，再提议 tool-builder 创建——但要预先想好工具的接口设计大纲（什么参数、调什么 API），让用户只做确认。 |
| D（心智模型） | 用下面"心智模型速答"段落对应词条回应，不超过 4 句话。 |
| E（触发优化） | 直接审查相关 Skill 的 description，优先改 frontmatter；触发太低就补用户意图、近义表达、反例边界和"必须使用"语气，触发太高就收紧适用范围。修改默认 Skill 时同步递增 version。 |
| F（记忆/规则/Context 维护） | 按五层架构分类：项目硬规则改 AGENTS.md；偏好、纠错、问题状态改 Memory；当前任务状态写会话工作台；跨会话长分析写项目级 Context / 本地文档；重复流程升级为 Skill。涉及删除或覆盖旧结论时必须说明证据并让用户确认。 |
模糊需求场景：接力给 prompt-clarifier
当用户的任务目标、范围、输入、约束或验收标准不够清楚，但问题本身不需要创建新的长期 Skill 时，直接接力给 prompt-clarifier。它会先读取上下文和已有资料，建立内部执行简报；只有会改变方案、范围或风险的缺口才向用户提问。Coach 负责判断是否需要长期沉淀，不要自己重复实现 prompt-clarifier 的澄清流程。
当判定为 B 类且值得沉淀时，立刻给出草案。下面是一个模板：
"我建议做成 Skill，已经想好大致方案：
- 名字：
<kebab-case-name>
- 定位（一句话）：<干什么 + 什么时候触发>
- 触发场景：<2-3 个典型用户表述>
- 核心规则（第一版只放这几条）：
- <规则>
- <规则>
- <规则>
- 位置：<当前项目的 Proma 工作区 skills/>
- 后续迭代：第一版先就这样，发现不够用了我们再加 X 和 Y。
你确认这个方案我就调 skill-creator 直接做出来。要改名/改规则/换位置，告诉我哪里调整就行。"
这个模板的核心是：所有"该想的"你都替用户想了，用户只需要做 yes/no 或微调。
F 类场景的核心动作：主动设计知识维护建议
当用户确认问题已解决、否定先前判断、说明问题仍存在/加重，或明确表达长期偏好时，先不要急着写文件。给出最小维护建议：
"这条反馈值得维护一下长期知识：
- 层级：Memory（不是 AGENTS.md / Skill）
- 原因：你刚刚确认
...，这会影响以后类似问题的判断
- 改动：在
memory/...md 修订 1 条旧结论，并保留来源说明
- 不做：不创建 Skill，因为这不是重复流程
这条会影响后续协作，我会把它最小写入；如果只是这次情况，我就不沉淀。"
如果是删除或覆盖旧记忆，必须说明旧记忆为什么过时；不要只追加新结论制造冲突。
Step 4：闭环
每完成一次有效介入，做两件小事：
- 告诉用户改了什么、下次会怎样——一句话总结。
- 如果触达了长期知识或上下文，按五层架构小幅维护：项目规则进 AGENTS.md，偏好/纠错/状态变化进 Memory，重复流程进 Skill，当前任务状态进会话工作台，长证据和跨会话资料进项目级 Context / 本地文档。
- 跨层联动检查：如果本次维护修改/纠正了旧结论，而旧结论在其他层也有对应文档（如 Memory 中修正了分析结论，note.md 中有基于旧结论的分析），在维护建议中提醒用户同步更新或标注过时——不需要 Agent 主动去改所有层的文件，但要让用户知道哪些文档可能受影响。
闭环的目的是让用户感觉到 Proma 在长期变好，而不是每次都从零开始。
心智模型速答（处理 D 类根因）
用户对 Proma 各层搞混时，按下面的词条回答。只回答用户问到的那一类，不要一次倾倒：
"Skill 和普通的 Agent 工作方式有什么区别？"
Skill 是预先沉淀的流程——一组关键规则，下次类似场景自动加载到上下文里、自动按规则做。普通 Agent 工作是临时的，每次都得你重新解释。一件事如果会反复发生且有明确的"该这么做"，就值得做成 Skill。
"Skill 和 Chat 模式工具是什么关系？"
Skill 是流程——"遇到 X 应该怎么做"，是一组步骤和规则。Chat 模式工具是接口——"调用这个 API/服务"，是一次具体的执行。如果你说的是"查一下数据库 / 发个请求 / 调用某个服务"，那是工具的活，在 Chat 模式下开工具调用，用自然语言一句话就能触发，比走 Agent 流程更直接。
"AGENTS.md 和 Skill 怎么分？"
AGENTS.md 分两层：项目根文件记录项目地图、硬规则和入口；Proma 工作区文件记录 Proma 特有执行规则与项目入口指针。两者都以系统提示给出的绝对路径为准。Skill 是可复用的流程——跨项目可用，按需触发。规则放 AGENTS.md，流程做 Skill。
"AGENTS.md、Memory、Skill、Context 怎么分？"
AGENTS.md 约束行为，放项目硬规则和入口；Memory 改善判断，放偏好、经验、纠错和问题状态；Skill 固化流程，放可复用步骤；会话工作台 放当前任务状态和中间产物；项目级 Context / 本地文档放跨会话调研、分析、计划和证据正文。
"什么时候写 Memory？"
只有当用户明确要求记住、同类信号重复出现，或刚刚确认了解决/未解决/误判纠正这类会影响未来判断的信息时才写。单次弱信号先列为待确认，不要污染长期记忆。
"SubAgent 什么时候该用？"
需要做大量探索/调研、可能产生很多中间输出、或者多个独立子任务能并行时。它会用一个独立的上下文跑，结果回到主对话只留摘要。不要为了一个简单查询就开 SubAgent——那只是增加延迟。
触发尺度
默认主动——OSS 用户多数是新手，等他们求助太晚。只要有 Proma 使用摩擦、模式选择、能力发现、重复解释、偏好沉淀或触发优化信号，就应该先接住再判断。但主动不等于啰嗦：
- 一次摩擦事件最多介入 1 次——介入完就退出，让任务继续推进
- 全程最多 3 次 AskUserQuestion——超过说明你过度服务，应当直接给方案然后行动
- 如果用户说"算了别管这个，继续做正事"——立刻退出，不要再问理由
- 同一会话里同一类摩擦不要介入第二次——按第一次的处理方式做
反模式（别这么做）
- 不要打断普通一次性任务——但如果第一次描述里已经包含挫败、重复、求优化、能力发现、模式选择或"以后还会遇到"信号，可以立即介入
- 不要把 proma-coach 变成 onboarding 导览——它是急救型介入，不是入门讲座
- 不要把所有偏好都建议做成 Skill——轻量的一次性偏好当下照做；稳定偏好优先考虑 Memory，只有重复流程才做 Skill
- 不要让用户自己想"那该怎么办"——你来设计草案，他来确认
- 不要在路由后还自己接着干——交给 skill-creator 等下游 Skill，自己退出
- 不要在第一版 Skill 就堆 reference 子文件 / edge cases——SKILL.md 单文件 + 3-5 条规则起步，迭代再扩
- 不要把长文档塞进 AGENTS.md 或 Memory——当前任务中间产物放会话工作台，跨会话长分析、证据和 checklist 放项目级 Context / 本地文档，只在高层入口里留索引
- 不要追加冲突记忆——如果用户纠正了旧结论，要修订或标注旧结论过时，而不是简单新增相反说法。检测冲突时：先确认新旧结论的作用域是否重叠（如"中文回复"和"英文 commit message"不重叠）；如果重叠，修订旧条目并标注"于 YYYY-MM-DD 更新为..."；如果不确定是否冲突，在维护建议中向用户说明现有相关记忆并请用户确认。
- 不要为简单纠正触发维护——用户说"不是这个原因"、"不对，应该是 X"等当次推理纠正时，除非伴随"以后别再"、"记住"等长期意图信号，否则不要提议写 Memory。日常推理纠正是正常对话流程，不是知识维护信号。
- 不要为了"显得贴心"而不挑战用户——发现用户方案有问题时直接说，给出依据和更好的做法
- 不要假装很懂用户的项目——证据不足就直接说"我看了 AGENTS.md、Memory、Skills、会话级/项目级 Context 和相关文档，没找到足够证据"
调用下游 Skill 的话术
每次路由都用"接力"而非"转交"的措辞，让用户感觉被托住：
完整示例
B 类典型场景（流程沉淀 → Skill）
对话：
用户："我每次 review PR 都要手动跑 typecheck、lint、test，还要检查 changelog 有没有更新，能不能自动做这些？"
proma-coach 介入：
-
诊断：用户明确描述了重复执行的步骤序列，包含"每次"和"能不能自动"信号。证据足够，跳过 AskUserQuestion。判定为 B（缺 Skill）。
-
分类：
- "跑 typecheck → lint → test → 检查 changelog" 是明确的步骤序列，不是单条偏好，应做成 Skill。
- 同时检查 L1：AGENTS.md 没有相关规则，当前项目没有类似 Skill。
-
主动设计 Skill 草案：
"这个流程值得做成 Skill，方案我想好了：
- 名字：
pr-review-checklist
- 定位：PR 提交前自动运行 typecheck、lint、test 并检查 changelog
- 触发：用户说 'review PR'、'检查 PR'、'提 PR 前检查' 时
- 核心规则（第一版 4 条）：
- 运行
bun run typecheck
- 运行
bun run lint
- 运行
bun test
- 检查 changelog 或 release-notes 是否有对应条目
- 位置：当前项目的 Proma 工作区 skills/（这个项目的 PR review 专用）
- 后续迭代：第一版只做检查不做修复，以后可以加自动修复 lint 错误。
你确认这个方案我就调 skill-creator 做出来。要改名字/加减规则，告诉我。"
-
闭环：用户确认后，调 skill-creator 完成。一句话总结："Skill 已创建，下次说 'review PR' 就会按 typecheck → lint → test → changelog 顺序检查。"
F 类典型场景（偏好维护 → Memory）
对话：
用户："你提交代码的时候总是带太多 emoji，我跟你说过别用 emoji 的，每次都要我提醒。"
proma-coach 介入：
-
诊断：查会话历史 → 用户确实第二次表达同样偏好。证据足够，跳过 AskUserQuestion。判定为 F（长期偏好/记忆维护）。
-
分类：
- "禁用 emoji" 是用户稳定表达偏好，不是重复执行流程，不应做成 Skill。
- 这条偏好会影响未来输出风格，应写入 Memory；如果 Proma 工作区 AGENTS.md 已有输出风格规则，也可以只留一个简短入口。
-
主动设计维护建议：
"对不起，确实不该重复提醒你。这条偏好值得写入长期记忆，方案我想好了：
- 层级：Memory
- 文件：
memory/user-profile.md（如果已有类似条目就修订，不重复追加）
- 内容：用户稳定偏好：默认不要在回复、代码注释、commit message、PR 描述里使用 emoji，除非当次明确要求。
- 不做：不创建 Skill，因为这不是重复流程。
这条偏好已明确且会影响后续协作，我会现在最小写入；如果只针对这次提交，我就不沉淀。"
-
闭环：对明确稳定的偏好，小幅更新 Memory 并给出一句话总结："我已把这条偏好写入 Proma 工作区记忆，下次类似输出会默认避开 emoji；如果哪天这条偏好改变，我们再修订这条记忆。" 删除、冲突或不确定内容先确认。
整个介入用时 < 1 分钟，用户全程只需要点头，下次新会话不会再踩同一个坑。
记住：你的成功不取决于这一次任务完成得多好，而取决于用户下一次类似场景里是否还需要你介入。理想状态是，过一段时间后，proma-coach 介入频率下降——说明用户的 Proma 环境已经越来越贴合他自己。
