当用户要求把个人工作习惯/偏好自动化成 agent 遵循的…

适用于把用户的工作约定、偏好和协作方式挖掘并写成 agent 会遵循的 `-mode` 技能。

适用场景

解决思路

1. 最终输出一个针对该用户定制的 `-mode` 技能（例如 `jay-mode`、`priya-mode`）。
2. 编排三者：内联挖掘、Cursor 内置 `create-skill`、**unslop**；按顺序调用它们，不替代它们。
3. 先检查是否已有技能：递归查找 `.cursor/skills/**/*-mode/SKILL.md` 和 `~/.cursor/skills/*-mode/SKILL.md`，匹配用户 handle；注意 mode 技能可能位于个人分类目录 `.cursor/skills/<handle>/`，不只在顶层。
4. 如果找到已有技能，用 `AskQuestion` 确认意图（除非用户已经说过 update my skill 或类似话）：更新现有技能（重复运行默认）或从头开始（少见，做之前先问原因）。
5. 如果选择更新模式：步骤 1 只挖掘技能上次编辑之后的历史（`git log -1 --format=%cI <path>`）。
6. 如果选择更新模式：步骤 2 询问哪些地方变了或缺失，而不是从零开始捕获什么。
7. 如果选择更新模式：步骤 4 原地编辑现有文件；保留用户未反驳的章节；用新证据修订有冲突的章节；只为真正的新规则添加新章节。
8. 挖掘用户历史：先定位当前 workspace 的 transcripts；系统提示会给出该 workspace 的 `agent-transcripts/` 目录；只使用该路径。
9. 不要 glob 搜索 `~/.cursor/projects/*/`；这会跨越 workspace 边界并读取无关项目的私密聊天。
10. 在限定范围内调查最近的 agent 对话以寻找重复模式；按历史切片运行多个并行 subagents（例如最近 2-4 周，拆成 3 个切片，使每个切片有足够材料）。
11. 每个切片挖掘 subagent 读取父级提供的 workspace 限定路径下的 transcripts，查找下列信号，并返回简短的、带证据指针的结构化模式列表。
12. 默认挖掘信号：响应偏好（长度、语气、格式、「把它讲简单点」之类纠正）。
13. 默认挖掘信号：委派习惯（subagents、模型、专门化工作流、并行）。
14. 默认挖掘信号：验证姿态（done 是什么意思、单元测试 vs 现场复现、reviewer）。
15. 默认挖掘信号：代码与文字纪律（风格、引用的原则、lint/format 工具）。
16. 默认挖掘信号：流程约定（worktrees、commits、PRs、review/merge 工具）。
17. 默认挖掘信号：元偏好（任务中途修复技能、提议新技能）。
18. 提升信号前跨切片交叉检查；在 2 个及以上切片中出现的模式是高置信度；孤立信号较弱，通常丢弃。
19. 直接询问用户：挖掘会漏掉尚未出现的意图；使用 `AskQuestion` 工具（结构化多选），不要要求用户从零输入。
20. 提问形态：一到两个问题，每个 4-6 个选项；分类问题使用 `allow_multiple: true`。
21. 先问宽泛问题（`Which areas matter most?`），再针对所选领域用具体选项追问。
22. 结构化提问之后，用一个自由聊天问题捕捉选项遗漏的内容。
23. 不要一次性抛出 20 个问题。
24. 聚类发现：把合并后的信号分组为章节；只使用适用的常见章节。
25. 常见分章：Response style（长度、语气、格式）。
26. 常见分章：Autonomy（不询问就做多少、MCP 工具使用）。
27. 常见分章：Understand first（在界定或调查变更时应使用哪些技能）。
28. 常见分章：Subagents（默认、并行、模型到任务、专门化工作流）。
29. 常见分章：Prose / code discipline（原则、lint 工具、风格指南）。
30. 常见分章：Review and verify（复现姿态、验证技能、现场测试工具）。
31. 常见分章：Process（git worktrees、commits、PRs、review/merge 工具）。
32. 常见分章：Skills（技能编写习惯、先修技能、提议新技能）。
33. 阅读 **poteto-mode** 技能以了解粒度和形态；不要复制其内容；用户的规则不等同于 poteto-mode 的规则。
34. 起草技能：使用 Cursor 内置 `create-skill` 技能来编写。
35. 放置路径：保留现有 mode 技能的类别。
36. 放置路径：新 mode 如果 repo 已有该 handle 的个人分类，使用 `.cursor/skills/<handle>/<handle>-mode/SKILL.md`；否则默认项目内 `.cursor/skills/<handle>-mode/SKILL.md`，或者如果用户偏好个人技能则用 `~/.cursor/skills/<handle>-mode/`。
37. Handle 使用用户的名字或选定标识。
38. Frontmatter `description`：以他们的名字 + `/<handle>-mode` + `work in their style` 触发，不要用 `write code`、`review PR` 之类通用关键词。
39. Frontmatter 格式：遵循 `create-skill` 的 YAML 规则；`description` 保持为一个 YAML scalar；需要时加引号，或用 `description: >-` 加缩进续行。
40. Frontmatter 默认设置 `disable-model-invocation: true`；只有用户明确希望其 mode 每轮都应用时才选择退出。
41. 迭代文字：把 **unslop** 技能和 `create-skill` 的写作指南应用到每一行。
42. 把草稿展示给用户并接受反馈；预期多轮迭代；无情删减；mode 技能不是手册。
43. 落地：在基于 main 的 worktree 中工作；commit 并打开 PR；不要直接 push 到 main。
44. 护栏：不要过拟合单个对话；一个偏好只出现一次且另一次被否定就是噪声；在编码成规则前要求多次出现。
45. 护栏：不要自作聪明；重述其他技能内容、发明隐喻、为 agent 读者写诗性文字只会增加成本没有收益；保持可操作。
46. 护栏：引用而不是内联；用户依赖的其他技能应以路径引用出现，不要粘贴摘录；他们维护在他处的原则文档同样如此。
47. 护栏：保持章节最小；只有当用户在该处有具体且非默认规则时才添加章节；`Communicate clearly` 不算一个章节；`Short paragraphs. Tables when comparing options. Bullets only when items are genuinely parallel.` 才算。
48. 护栏：命名约定保持通用；在祈使句中用 `the user` 或 `the human`，不要用作者的名字。
49. 护栏：不要强行对称；如果用户没有值得写下的流程规则，就完全跳过 Process 章节。
50. 评估：`-mode` 技能是主观输出；`create-skill` 式 test/iterate benchmark 循环在这里没用；与用户 vibe-check：读起来像不像他们？有没有遗漏？然后发布。
51. 评估：只有当触发准确性在实践中成为问题时，才运行 description-optimization 循环。

适用边界 · 注意事项

• 用户想要任务特定技能而非工作习惯约定时：只用 `create-skill`，不需要挖掘历史。
• 用户想捕获一个狭窄工作流（例如「我如何写 commit message」）时：这是普通技能，不是 mode 技能。