send-to-linear

发送到 Linear

将非结构化输入整理成结构清晰的 Linear 工单。

设置

配置解析

按以下顺序查找团队配置（以第一个匹配项为准）：

1. ~/.agents/configs/send-to-linear/config.json（用户覆盖配置）
2. references/config.json（随附的默认配置，相对于此技能文件）

如果找到用户配置，则使用该配置。否则回退到随附的 config.json。

如果不存在用户配置，且随附配置的必填字段（team、default_assignee）为空，请停止并提示用户：

未找到本地配置。随附的 references/config.json 中的默认值为空，并且每次此技能更新时都会被覆盖。

创建用户配置：~/.agents/configs/send-to-linear/config.json

将随附的 references/config.json 复制为起始文件，并填写你的团队、项目、负责人、标签和约定。

模板解析

工单模板也遵循相同模式：

1. ~/.agents/configs/send-to-linear/ticket-template.md（用户覆盖模板）
2. references/ticket-template.md（随附的默认模板）

模板很少需要自定义，因此如果只有随附版本，无需提示用户。

阶段 1：接收输入

接受以下任意组合：

• Slack 记录——粘贴的消息，或通过 Slack MCP 工具获取
• 通话转录——来自 Fireflies（mcp__fireflies__* 工具）、粘贴的文本或文件
• 截图——使用 Read 工具读取图像文件
• 会议笔记 / 文档——任何 Markdown、文本或文档内容
• 用户描述——自由形式的“我们需要 X、Y、Z”

如果用户输入含糊或不完整，继续处理前先提出一个澄清问题。不要过度追问。

对于 Fireflies 转录：同时获取摘要（fireflies_get_summary）和完整转录（fireflies_get_transcript）。使用摘要确定主题，使用完整转录提取细节。

阶段 2：提取主题和可执行事项

对于简短输入（<5K 字符）：直接在主上下文中提取。

对于较长输入（>5K 字符，例如完整通话转录）：启动并行子 Agent，每个子 Agent 负责一个主要主题或时间段，提取以下内容：

1. 具体示例和用例——最关键的产出。记录具体场景、公司 / 股票代码、KPI、原话、时间戳和推理链条。写着“修复解读错误”的工单毫无用处。写着“修复解读错误——例如，当评论称 Intel CapEx‘持平至下降’，而市场一致预期为‘下降’时，应识别为上调”的工单才具有可执行性。
2. 功能需求——需要构建或更改的内容
3. 限制 / 边界——明确排除的内容
4. 验收标准——可测试的条件

将事项分类为：

• 可执行工单——范围明确，可以立即着手处理
• 想法 / 需要进一步思考——有愿景或探索性质，需记录但暂不可执行

阶段 3：将工单草案写入临时文件

使用 references/ticket-template.md 中的格式，写入 .claude/scratchpad/linear-tickets-YYYY-MM-DD.md。

凡是包含源材料中真实示例的工单，必须原文包含该示例——不要在概述时省略具体内容。

阶段 4：验证（仅适用于长篇输入）

短小 / 简单输入可跳过此步骤。对于通话转录或较长的 Slack 讨论串：

启动验证子 Agent，使其阅读完整源材料和工单草案，然后列出遗漏项：

• 提及但未纳入工单的用例
• 分配给某人的行动项，但未被记录
• 已达成共识但未列入验收标准的设计决定
• 未纳入任何工单的“我们需要做 X”陈述

根据发现的遗漏更新草案。

阶段 5：用户审核

停止。 告知用户文件已准备就绪，并等待用户明确指示后再在 Linear 中创建任何内容。

用户可以重组、合并、拆分、重命名、添加备注，或要求跳过某些事项。继续之前，将所有反馈应用到临时文件中。

第 6 阶段：在 Linear 中创建（仅在明确批准后）

按照 Setup 中的解析顺序读取配置，然后：

1. mcp__linear__list_teams — 解析团队 ID
2. mcp__linear__list_issue_labels — 解析标签 ID
3. mcp__linear__list_projects — 解析项目 ID（如果已配置）
4. 使用 type: "current" 调用 mcp__linear__list_cycles — 解析当前周期（如果 assign_to_current_cycle 为 true）

使用 mcp__linear__create_issue 创建每张已批准的工单：

• team：来自配置
• project：来自配置
• assignee：来自配置
• cycle：当前周期编号
• state：来自配置中的 default_status
• labels：根据工单的 Labels 字段匹配
• title：来自工单
• description：完整的工单正文，使用 Markdown 格式
• links：来源链接（如果有，例如 Fireflies 转录文本 URL、Slack 永久链接）

向用户报告已创建工单的标识符。

关键规则

1. 具体示例不可或缺。 工程师需要根据具体场景了解要构建什么，而不是抽象描述。保留完整的推理链、准确引语和真实情境。
2. 未经用户批准，绝不创建工单。 始终先将草稿写入暂存区。
3. 配置项是默认值，而非限制。 用户可以在每次调用时覆盖团队、负责人、标签或任何其他字段。
4. 不要过度合并。 如果两个事项是彼此独立的工作，就应拆分为不同工单。只有当事项确实属于同一交付成果时才合并。
5. 埋藏在对话中的独立需求也要创建工单。 顺带提到的事项，例如“我们还需要比较日期”，都代表独立的工作项。