mode-creator

模式创建器

创建一个实用的笔记系统，而不只是生成有效的 JSON 文件。与用户访谈，提出一套精简的分类体系，获得批准后将其持久安装，配置可选提醒，重启工作进程，并证明活动模式已出现在启动上下文中。

基本原则

• 使用可用的交互式提问工具（AskUserQuestion、request_user_input 或等效工具）进行访谈。每次少量提问，并等待用户回答后再继续。
• 说明观察类型是互斥的笔记类别，而概念是可重复使用的标签。除非用户先使用术语，否则避免使用行话。
• 在创建新模式之前，检查现有的捆绑模式和用户模式。如果复用或改编相近模式对用户更有帮助，就采用这种做法。
• 不要修改插件缓存或捆绑模式。将自定义文件安装到已解析的 claude-mem 数据目录下的 modes/ 文件夹中。
• 不要在聊天、命令参数、日志或工具输出中暴露 Telegram 令牌。将其视为密码。
• 保留无关设置和现有 Telegram 触发器。辅助工具会创建带时间戳的备份，并合并所请求的触发器。
• 本地工作进程运行时支持自定义模式。如果 CLAUDE_MEM_RUNTIME 为 server，请说明此工作流无法安全地将用户专属模式安装到共享服务器上，并在修改前停止。
• 现有观察保留原有类型。新模式仅适用于之后生成的观察。

1. 以说明目的开场

在第一个交互式问题中，先发送以下消息：

自定义模式可让你针对手头的工作记录笔记。如果你是法学院学生，可能希望记下每次判例确立规则、教授指出考试陷阱或不同学说发生冲突的情况。如果你是建筑师，可能希望记录每项设计决策、规范限制、客户偏好或现场发现。你目前在做什么？

不要一开始就询问模式名称或 JSON 字段。先了解用户的工作。

如果用户的回答与代码相关，请说：

代码模式已经很适合软件开发。自定义变体或许会更适合你，因为它还能追踪［根据用户的工作推断出的 2–4 种具体笔记］，并为［2–4 个有用的跨领域主题］添加标签。你想保留标准代码模式，还是进行自定义？

给出具体建议。例如，对于机器学习平台工程师，可以建议记录实验结果、数据契约变更、生产事故、模型决策、成本发现和可复现性风险，而不是泛泛地说“自定义笔记”。如果用户选择标准代码模式，不要创建重复文件；继续询问可选通知并完成验证。

2. 了解哪些内容值得记住

通过后续问题了解：

1. 三个他们希望下周还能查到的时刻或发现示例。
2. 应跳过的日常活动。
3. 他们之后会搜索的人名、案件、材料、客户、限制条件、实验、事故等实体和决策。
4. 绝不能记录或发送到 Telegram 的敏感信息。
5. 笔记应该有所取舍，还是尽量详细。

根据对话中已有的信息推断答案，避免重复提问。当用户的回答较宽泛时，提出示例供其选择或修改。

3. 提议模式

起草前，请阅读 references/mode-authoring.md。

提议以下内容：

• 清晰的模式名称和小写 ID。
• 通常包含 4–8 种观察类型。每条观察记录恰好归入一种类型。
• 通常包含 4–8 个概念标签。一条观察记录可以带有多个概念标签。
• 各用一句话说明记录和跳过的策略。
• 提供两个模式会记录的真实示例，以及两个会跳过的示例。

用通俗语言呈现提案，并使用交互式提问工具征求批准。允许用户重命名、添加、删除或改写类别。用户批准分类体系和隐私边界之前，不要编写或安装模式。

优先采用继承式 ID，例如 code--architecture-practice，这样模式可以复用 claude-mem 稳定的输出协议，同时替换领域分类体系和行为提示词。父模式 code 是实现基础；覆盖内容必须从提示词中移除代码专属语义。仅当确实不适合继承时，才使用独立模式。

4. 询问是否需要 Telegram 提醒

分类体系获批后，询问：

当 claude-mem 记录特定类型或标签时，你希望收到 Telegram 通知吗？提醒会包含观察类型、标题、副标题、项目和观察 ID，因此请避免选择可能暴露敏感内容的类别。

如果用户同意：

• 让用户从已批准的模式中选择具体的观察类型和／或概念标签。
• 说明匹配方式为 OR：明确启用提醒后，任何选定的类型或概念都会触发提醒。仅选择触发条件并不会启用发送；每条观察记录的提醒默认关闭。征得用户同意后，在运行安装程序或凭据助手后，将 CLAUDE_MEM_TELEGRAM_OBSERVATION_ALERTS_ENABLED 设为 "true"，写入已解析的数据目录中的 settings.json。
• 询问用户是否已将 Telegram 机器人连接到 claude-mem。
• 阅读 references/telegram.md，然后引导新用户使用 BotFather 和安全设置助手。

如果用户不同意，保持所有 Telegram 设置不变。

5. 起草、验证并安装

解析包含此 SKILL.md 的绝对目录；所有助手路径都相对于此目录。

将已批准的模式写入临时 JSON 文件。使用作者参考文档中规定的精确继承覆盖结构。然后在不修改任何内容的情况下进行验证：

node <skill-directory>/scripts/install-mode.mjs \
  --mode <temporary-mode.json> \
  --mode-id <parent--custom-id> \
  --dry-run

安装前修复所有验证错误。然后安装并激活模式：

node <skill-directory>/scripts/install-mode.mjs \
  --mode <temporary-mode.json> \
  --mode-id <parent--custom-id> \
  --telegram-types <comma-separated-approved-types> \
  --telegram-concepts <comma-separated-approved-concepts>

如果用户拒绝提醒，则省略两个 Telegram 标志。安装程序会：

• 将覆盖内容与父模式合并，并验证完整模式。
• 将源覆盖内容安装到 <data-dir>/modes/ 下。
• 在 settings.json 中设置 CLAUDE_MEM_MODE。
• 合并已批准的提醒触发条件，不删除现有触发条件。
• 以原子方式写入，并报告任何备份路径。

检查其 JSON 结果。如果 ok 不为 true，不得声称安装成功。

6. 必要时连接 Telegram

如果用户请求提醒，且机器人令牌和聊天 ID 均已存在，则询问用户是否允许复用这些凭据并发送测试消息。如果缺少凭据，请说明 Telegram 参考文档中的 BotFather 步骤。

仅在明确征得同意后运行凭据助手：

node <skill-directory>/scripts/configure-telegram.mjs \
  --types <comma-separated-approved-types> \
  --concepts <comma-separated-approved-concepts>

助手通过隐藏的终端输入接收令牌，使用 getMe 验证令牌，查找或询问聊天 ID，发送测试消息，并以仅所有者可访问的权限存储设置。切勿将令牌作为参数传递。

如果 Agent 环境无法让用户控制交互式终端，则显示准确的助手命令，并暂停操作，让用户在本地运行。这是唯一可接受的人工操作边界；不得要求用户将令牌粘贴到聊天中作为替代方案。用户确认后，仅检查凭据字段是否存在，绝不打印其值。

7. 重启并验证结果

重启前先读取已配置的运行时。对于 worker 运行时，使用已验证的 CLI 重启路径：

npx claude-mem restart
npx claude-mem status

如果 CLI shim 不可用，请使用 Bun 运行已安装插件的 scripts/worker-service.cjs restart。如果已验证的 CLI 路径可用，切勿直接发送重启 HTTP 请求。

请验证以下所有内容：

1. 重启报告有一个新的健康 worker，并成功退出。
2. 已安装的文件存在于解析后的数据目录中。
3. settings.json 中指定了预期的 CLAUDE_MEM_MODE，且未显示任何机密。
4. 如果有可用的 session_start_context MCP 工具，请使用它请求完整的启动上下文。否则，向已配置的本地 worker 调用 /api/context/inject?project=mode-creator-verification&full=true。
5. 启动上下文包含 Mode: <mode name> (<mode id>)。
6. 如果已配置 Telegram，测试消息已送达。

如果 worker 回退到 code，请检查 worker 日志中的模式验证或查找错误，修复模式，然后重复重启。不要将回退描述为成功启用。

8. 清晰交接

最后说明：

• 活跃模式的名称和 ID。
• 已安装路径。
• 观察类型和概念。
• Telegram 触发类型/概念，或“未更改”。
• 重启和启动上下文验证结果。
• 用于回滚的备份路径。
• 一个简短示例，说明新模式现在会记住什么。

交接内容中绝不要包含 Telegram 机器人令牌。