automate-me

自动化我

一个引导式流程，用于将用户的工作习惯转化为 Agent 会遵循的技能。输出是一个专为用户定制的 -mode 技能（例如 jay-mode、priya-mode）。

此技能会协调另外三项技能：内联挖掘流程（见步骤 1）、plugin-dev:skill-development 技能（编写）以及 unslop 技能（规范行文）。它负责安排这些技能的执行顺序，不会取代它们。

平台说明。 在 Codex 或其他非 Claude 运行环境中，以下提到的 Claude 工具名称、claude-* slug，以及 Claude 内置技能（包括 plugin-dev:skill-development）都是 Claude 默认项。请通过 codex-tools.md 解析它们。

流程

0. 检查是否已有技能

递归查找与用户 handle 匹配的 .claude/skills/**/*-mode/SKILL.md 和 ~/.claude/skills/*-mode/SKILL.md。Mode 技能可以放在个人类别目录（.claude/skills/<handle>/）中，不一定只在顶层目录。如果已存在，请用 AskUserQuestion 确认用户的意图（除非他们已经说过“更新我的技能”或类似的话）：

• 更新现有技能（重复运行时的默认选项）
• 从头开始（较少见，执行前先询问原因）

更新模式会改变后续流程：

• 步骤 1 仅挖掘技能上次编辑之后的历史记录（git log -1 --format=%cI <path>）。
• 步骤 2 询问有哪些变化或遗漏，而不是从零开始询问要记录什么。
• 步骤 4 在原文件中直接编辑。保留用户未提出异议的部分；根据新证据修订相应内容。仅在确有新规则时添加新章节。

1. 挖掘用户历史记录

启动多个子 Agent 并行处理之前，先找到当前工作区的对话记录。Claude Code 将这些记录存放在 ~/.claude/projects/<encoded-cwd>/*.jsonl，其中 <encoded-cwd> 是工作区的工作目录，将 / 替换为 -。只能使用该路径。不要对 ~/.claude/projects/ 进行全局匹配，否则会跨越工作区边界，并读取其他项目中的私人聊天记录。

在此范围内查看近期 Agent 对话，寻找反复出现的模式。针对不同时间段（例如最近 2 至 4 周，拆分成 3 段，确保每段都有足够材料）并行运行多个子 Agent。根据 poteto-mode 技能的 Subagents 部分，为任务选择各子 Agent 的工作量。每个负责挖掘一个时间段的子 Agent 都应读取父 Agent 提供的工作区限定路径中的对话记录，寻找以下信号，并返回一份简短的结构化模式列表，附上证据指针。默认值得查找的信号：

• 回复偏好（长度、语气、格式、“说简单点”之类的修正）
• 委派习惯（子 Agent、模型、专门工作流、并行处理）
• 验证方式（如何定义“完成”、单元测试还是实际复现、审查者）
• 代码和行文规范（风格、引用的原则、lint/格式化工具）
• 流程惯例（worktree、提交、PR、审查/合并工具）
• 元偏好（任务进行中修复技能、提议新技能）

交叉核对各时间段的结果，再提升信号的可信度。至少在 2 个时间段中出现的模式属于高置信度信号。仅出现一次的信号较弱，通常应舍弃。

2. 直接询问用户

挖掘无法发现尚未提及的意图。使用 AskUserQuestion 工具进行结构化多选，而不是让用户从头开始输入。

问题形式：提出 1 到 2 个问题，每个问题提供 4 到 6 个选项；对于类别问题，设置 allow_multiple: true。先从宽泛的问题开始（“哪些方面最重要？”），再根据用户选中的方面提供具体选项。完成结构化问答后，再提出一个开放式聊天问题，以补充选项未涵盖的内容。

不要一口气抛出 20 个问题。

3. 梳理发现

将汇总后的信号分组到各个章节。常见类别如下（仅使用适用的类别）：

• 响应风格：长度、语气、格式。
• 自主性：无需询问即可完成多少工作、MCP 工具的使用方式。
• 先理解再行动：在界定范围或调查变更时应调用哪些技能。
• 子 Agent：默认设置、并行处理、模型与任务的匹配、专用工作流。
• 文案 / 代码规范：原则、lint 工具、风格指南。
• 审查与验证：复现方式、验证技能、实时测试工具。
• 流程：Git worktree、提交、PR、审查 / 合并工具。
• 技能：编写技能的习惯、优先修复技能、提议新技能。

poteto-mode 技能展示了应有的细致程度。阅读它以了解粒度，不要照搬其中内容。用户的规则与 poteto-mode 的规则并不相同。

4. 起草技能

使用 plugin-dev:skill-development 技能编写该技能。放置位置：

• 路径：沿用现有模式技能的类别。对于新模式，如果仓库已有该标识符对应的个人类别，则使用 .claude/skills/<handle>/<handle>-mode/SKILL.md。否则，默认在项目中使用 .claude/skills/<handle>-mode/SKILL.md（如果用户偏好个人技能，则使用 ~/.claude/skills/<handle>-mode/）。
• 标识符：用户的名字或选定的标识符。
• Frontmatter description：通过用户的名字 + /<handle>-mode + “按他们的风格工作”来触发，不要使用“编写代码”或“审查 PR”这类通用关键词。
• Frontmatter 格式：遵循 plugin-dev:skill-development 的 YAML 规则。将 description 保持为单个 YAML 标量。若标点或换行需要，可加引号，或使用 description: >- 并在后续行缩进。
• Frontmatter 默认设置 disable-model-invocation: true。只有用户明确希望其模式每轮都生效时，才取消此设置。

5. 迭代文案

对每一行应用 unslop 技能和 plugin-dev:skill-development 的写作指南。

向用户展示草稿并征求反馈。应预期进行多轮迭代。大幅删减。模式技能不是手册。

6. 完成并提交

基于 main 在 worktree 中进行开发。提交并创建 PR。不要直接推送到 main。

护栏

• 不要过拟合单次对话。 某项偏好只出现一次，且另一次对话中与之矛盾，就属于噪声。只有多次出现后才将其写入规范。
• 不要耍小聪明。 复述其他技能的内容、编造比喻，或为 Agent 读者写“诗意”的文案，都是徒增成本，没有益处。保持可执行性。
• 引用，不要内嵌。 用户依赖的其他技能应以路径引用，而非粘贴摘录。同样适用于用户在其他地方维护的原则文档。
• 章节尽量精简。 只有用户在某方面有具体且非默认的规则时，才添加相应章节。“清晰沟通”不算一个章节。“段落简短。比较选项时使用表格。仅在条目确实并列时使用项目符号。”则算。
• 名称约定通用。 在指令中使用“用户”或“人工参与者”，不要使用作者的名字。
• 不要强行追求对称。 如果用户没有值得记录的流程规则，就完全跳过“流程”章节。

评估

-mode 技能的输出具有主观性。plugin-dev:skill-development 风格的测试 / 迭代基准循环在这里没有用。请与用户进行直觉评估：读起来像他们的风格吗？有没有遗漏？然后交付。

只有当技能的触发准确性在实际使用中出现问题时，才运行描述优化循环。

何时不适用

• 用户想要的是特定任务的技能（而非工作约定）：仅使用 plugin-dev:skill-development，无需挖掘。
• 用户想记录一个范围狭窄的工作流（例如“如何撰写提交消息”）。这属于常规技能，而非模式技能。