automate-me

自动化我

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

此技能会协调另外三项技能：内联挖掘流程（见步骤 1）、../poteto-mode/playbooks/authoring-a-skill.md 中的编写指南，以及 unslop 技能（行文规范）。它负责安排这些技能的执行顺序，不会取代它们。

流程

0. 检查是否已有技能

递归查找与用户标识匹配的 .agents/skills/**/*-mode/SKILL.md 和 ~/.agents/skills/*-mode/SKILL.md。Mode 技能可以放在个人分类目录（.agents/skills/<handle>/）中，不一定只在顶层目录。如果找到了，使用 AskQuestion 确认用户的意图（除非用户已经说过“更新我的技能”之类的话）：

• 更新现有技能（重复运行时的默认选项）
• 重新开始（少见；操作前先询问原因）

更新模式会改变流程的其余部分：

• 步骤 1 只挖掘该技能上次编辑之后的历史记录（git log -1 --format=%cI <path>）。
• 步骤 2 询问有哪些变化或缺失，而不是从零开始询问要记录什么。
• 步骤 4 在原文件中编辑。保留用户未曾否定的章节；根据新证据修订相关章节。只有确实出现新规则时才添加新章节。将 frontmatter 中的 disable-model-invocation 行替换为步骤 4 所述的门控设置。

1. 挖掘用户的历史记录

使用 pstack-harness 技能，在并行展开任务前定位当前工作区的对话记录。只使用此工作区的存储。不要读取其他工作区的会话记录。这会跨越工作区边界，并读取无关项目中的私人聊天。

在此范围内调查近期的 Agent 对话，找出反复出现的模式。针对历史记录的不同时间段，同时运行多个 routine 角色的子 Agent（例如，调查最近 2–4 周，并拆分为 3 个时间段，确保每段都有足够材料）。使用 pstack-harness 技能中的 Spawn a role 章节来解析角色。每个负责挖掘某个时间段的子 Agent 都会读取父 Agent 提供的工作区范围路径下的对话记录，查找以下信号，并返回一份简短的结构化模式清单及其证据指针。默认值得查找的信号：

• 回复偏好（长度、语气、格式，以及“说得简单些”之类的纠正）
• 委派习惯（子 Agent、模型、专用工作流、并行处理）
• 验证方式（“完成”的标准、单元测试与实时复现、审查者）
• 代码与行文规范（风格、引用的原则、lint/格式化工具）
• 流程约定（worktree、提交、PR、审查/合并工具）
• 元偏好（任务中途修正技能、提出新技能）

在提炼某个信号之前，先对照不同时间段的结果。在至少 2 个时间段中出现的模式可信度较高。只出现一次的信号较弱，通常应舍弃。

2. 直接询问用户

挖掘无法捕捉尚未出现过的意图。使用 AskQuestion 工具（结构化多选题），而不是让用户从头输入。

形式：提出一到两个问题，每题提供 4–6 个选项；对于类别问题，设置 allow_multiple: true。先问较宽泛的问题（“哪些方面对你最重要？”），再针对用户选择的方面提供具体选项。完成结构化问题后，再通过一个开放式聊天问题补充选项未涵盖的内容。

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

3. 归纳发现

将综合信号整理为各个部分。常见部分如下（仅使用适用的部分）：

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

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

4. 起草技能

按照 ../poteto-mode/playbooks/authoring-a-skill.md 编写技能。放置位置：

• 路径：保留现有模式技能的类别。对于新模式，如果仓库已有适用于该标识符的个人类别，则使用 .agents/skills/<handle>/<handle>-mode/SKILL.md。否则，默认放在项目中的 .agents/skills/<handle>-mode/SKILL.md（如果用户偏好个人技能，则放在 ~/.agents/skills/<handle>-mode/）。
• 标识符：使用用户的名字或其选择的标识符。
• Frontmatter description：在用户提及其姓名 + /<handle>-mode + “按其风格工作”时触发，不要使用“编写代码”或“审查 PR”等通用关键词。
• Frontmatter 格式：确保 frontmatter 是有效的 YAML。将 description 写成单个 YAML 标量。若标点或换行有需要，可加引号，或使用 description: >- 并在后续行缩进。
• 默认启用门控，仅在用户输入技能名称或其他技能调用该技能时加载。在 SKILL.md 旁写入 agents/openai.yaml，在 policy: 下设置 allow_implicit_invocation: false，以便在 Codex 中启用门控。在 Claude Code 中，按照 setup-pstack 为 pstack 自有技能执行的步骤 0c，询问用户是否愿意在其 ~/.claude/settings.json 的 skillOverrides 下添加 "<handle>-mode": "name-only"。只有用户同意后才写入该项，并保留所有其他键。切勿写入 disable-model-invocation，否则当其他技能调用该技能时，Claude Code 的 Skill 工具会拒绝执行。只有在用户明确希望其模式在每一轮对话中都生效时，才不启用门控。

5. 迭代润色文本

使用 unslop 技能逐行检查，并遵循 authoring-a-skill playbook 的写作指南。

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

6. 合并落地

从 main 创建工作树。在其中提交并创建 PR。不要直接推送到 main。

防护原则

• 不要针对单次对话过度拟合。 某项偏好只出现过一次，且另一次表达了相反意见，就视为噪声。只有多次出现后才将其写入。
• 不要自作聪明。 复述其他技能的内容、编造比喻或为 Agent 读者写“诗意”的文本，都徒增成本。保持可操作性。
• 引用，不要内嵌。 使用“使用 技能。”来提及用户依赖的其他技能，例如“使用 unslop 技能。”按 authoring playbook 的要求，只使用技能的原名，不要粘贴摘录。通过路径指向用户在其他位置维护的原则文档。
• 精简章节。 只有当用户在某方面有明确的非默认规则时，才添加相应章节。“清晰沟通”不算一个章节。“段落要短。比较选项时使用表格。只在条目确实并列时使用项目符号。”则算。
• 命名约定应保持通用。 在指令中使用“用户”或“人”，而非作者的名字。
• 不要强求对称。 如果用户没有值得记录的流程规则，就完全省略“流程”部分。

评估

-mode 技能的输出具有主观性。测试/迭代基准循环在这里没有用。请让用户感受一下：读起来像他们的风格吗？有没有遗漏什么？然后发布。

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

何时不使用

• 用户想要的是针对特定任务的技能（而非工作惯例）：只需使用编写技能的操作手册，无需挖掘。
• 用户想要记录一个狭窄的工作流（例如“我如何撰写提交消息”）。这属于常规技能，而非模式技能。