Back to Details

send-to-linear

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Send to Linear

发送到Linear

Turn unstructured input into well-structured Linear tickets.
将非结构化输入转换为结构规范的Linear工单。

Setup

配置步骤

Config resolution

配置文件读取顺序

Look for team configuration in this order (first match wins):
  1. ~/.claude/skills/send-to-linear/references/config.local.json
  2. ~/.agents/skills/send-to-linear/references/config.local.json
  3. references/config.json
    (bundled defaults, relative to this skill file)
Use the first 
.local
config found. Otherwise fall back to the bundled 
config.json
.
If no 
.local
file exists anywhere AND the bundled config has empty required fields (
team
, 
default_assignee
), stop and prompt the user:
No local config found. The bundled 
references/config.json
has empty defaults and will be overwritten whenever this skill updates.
Create a local override at one of these paths:
  • ~/.claude/skills/send-to-linear/references/config.local.json
  • ~/.agents/skills/send-to-linear/references/config.local.json
Copy the bundled 
references/config.json
as a starting point and fill in your team, project, assignee, labels, and conventions.
按以下优先级查找团队配置（匹配到第一个即停止）：
  1. ~/.claude/skills/send-to-linear/references/config.local.json
  2. ~/.agents/skills/send-to-linear/references/config.local.json
  3. references/config.json
    （内置默认配置，相对于本技能文件的路径）
优先使用找到的第一个
.local
配置文件，否则回退到内置的
config.json
。
如果不存在任何
.local
文件，且内置配置的必填字段（
team
、
default_assignee
）为空，停止操作并提示用户：
未找到本地配置文件。内置的
references/config.json
为空白默认值，且每次本技能更新时都会被覆盖。
请在以下路径之一创建本地覆盖配置：
  • ~/.claude/skills/send-to-linear/references/config.local.json
  • ~/.agents/skills/send-to-linear/references/config.local.json
复制内置的
references/config.json
作为模板，填写你的团队、项目、处理人、标签和规范信息。

Template resolution

模板读取顺序

Same pattern for the ticket template:
  1. ~/.claude/skills/send-to-linear/references/ticket-template.local.md
  2. ~/.agents/skills/send-to-linear/references/ticket-template.local.md
  3. references/ticket-template.md
    (bundled default)
The template rarely needs customization, so no prompt if only the bundled version exists.
工单模板采用相同的读取规则：
  1. ~/.claude/skills/send-to-linear/references/ticket-template.local.md
  2. ~/.agents/skills/send-to-linear/references/ticket-template.local.md
  3. references/ticket-template.md
    （内置默认模板）
模板很少需要自定义，因此如果仅存在内置版本不会提示用户。

Phase 1: Ingest Input

阶段1：输入接收

Accept any combination of:
  • Slack dump — pasted messages or fetched via Slack MCP tools
  • Call transcript — from Fireflies (
    mcp__fireflies__*
    tools), pasted text, or a file
  • Screenshots — read image files with the Read tool
  • Meeting notes / docs — any markdown, text, or document content
  • User description — freeform "we need X, Y, Z"
If the user's input is ambiguous or incomplete, ask one clarifying question before proceeding. Do not over-interrogate.
For Fireflies transcripts specifically: fetch both the summary (
fireflies_get_summary
) and full transcript (
fireflies_get_transcript
). Use the summary for topic identification, the full transcript for detail extraction.
支持接收任意组合的以下输入：
  • Slack导出内容 — 粘贴的消息或通过Slack MCP工具拉取的内容
  • 通话转录文本 — 来自Fireflies（
    mcp__fireflies__*
    工具）、粘贴的文本或文件
  • 截图 — 使用Read工具读取的图片文件
  • 会议笔记/文档 — 任意markdown、文本或文档内容
  • 用户描述 — 自由形式的描述，例如“我们需要实现X、Y、Z功能”
如果用户输入模糊或不完整，在继续操作前只提一个澄清问题，不要过度询问。
针对Fireflies转录内容的特殊处理：同时拉取摘要（
fireflies_get_summary
）和完整转录文本（
fireflies_get_transcript
），使用摘要识别主题，使用完整文本提取细节。

Phase 2: Extract Topics and Actionable Items

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

For short input (<5K chars): extract directly in the main context.
For long input (>5K chars, e.g. full call transcripts): launch parallel subagents, one per major topic or time segment, to extract:
  1. Concrete examples and use cases — the most critical output. Capture specific scenarios, companies/tickers, KPIs, exact quotes, timestamps, and reasoning chains. A ticket saying "fix interpretation errors" is useless. A ticket saying "fix interpretation errors — e.g., when commentary says 'flat to down' for Intel CapEx but consensus expects 'down', recognize this as upward revision" is actionable.
  2. Feature requirements — what needs to be built or changed
  3. Limitations/boundaries — things explicitly ruled out
  4. Acceptance criteria — testable conditions
对于短输入（字符数<5K）：直接在主上下文中提取。
对于长输入（字符数>5K，例如完整通话转录文本）：启动并行子Agent，每个子Agent对应一个核心主题或时间段，提取以下内容：
  1. 具体示例和使用场景 — 最核心的输出。记录具体场景、公司/股票代码、KPI、准确引用、时间戳和推理逻辑。写“修复解释错误”的工单是无效的，写“修复解释错误——例如，当评论提到英特尔资本支出‘持平或下降’但市场共识预期‘下降’时，应识别为向上修正”这样的工单才是可执行的。
  2. 功能需求 — 需要构建或修改的内容
  3. 限制/边界 — 明确排除的内容
  4. 验收标准 — 可测试的条件

Categorize items as:

事项分类：

  • Actionable tickets — clear scope, can be worked on immediately
  • Ideas / needs more thought — visionary or exploratory, tracked but not immediately actionable
  • 可执行工单 — 范围明确，可立即启动开发
  • 创意/需进一步梳理 — 前瞻性或探索性内容，可记录但暂不可直接执行

Phase 3: Draft Tickets to Scratchpad

阶段3：在草稿区生成工单草案

Write to 
.claude/scratchpad/linear-tickets-YYYY-MM-DD.md
using the format from 
references/ticket-template.md
.
Every ticket with a real-world example from the source MUST include that example verbatim — do not summarize away specifics.
按照
references/ticket-template.md
的格式，写入到
.claude/scratchpad/linear-tickets-YYYY-MM-DD.md
文件中。
每个工单如果在源材料中有真实案例，必须原文引用案例，不要概括省略具体细节。

Phase 4: Verification (for long-form input only)

阶段4：校验（仅长输入需要）

Skip for short/simple input. For call transcripts or long Slack threads:
Launch a verification subagent that reads the full source material and the drafted tickets, then produces a gap list:
  • Use cases mentioned but missing from tickets
  • Action items assigned to people but not captured
  • Design decisions agreed upon but not in acceptance criteria
  • Any "we need to do X" statements not in any ticket
Update the draft with any gaps found.
短/简单输入跳过本阶段。针对通话转录文本或长Slack线程：
启动校验子Agent，读取完整源材料和生成的工单草案，输出遗漏清单：
  • 源材料中提到但未纳入工单的使用场景
  • 已经分配给相关人员但未记录的执行项
  • 已经达成共识但未写入验收标准的设计决策
  • 任何未纳入工单的“我们需要做X”类表述
根据发现的遗漏更新工单草案。

Phase 5: User Review

阶段5：用户审核

STOP. Tell the user the file is ready and wait for explicit instruction before creating anything in Linear.
The user may restructure, merge, split, rename, add notes, or tell you to skip items. Apply all feedback to the scratchpad file before proceeding.
停止操作。告知用户草案文件已准备就绪，等待用户明确指令后再在Linear中创建任何内容。
用户可能会调整结构、合并、拆分、重命名、添加备注，或者要求跳过某些事项。继续操作前先将所有反馈同步到草稿文件中。

Phase 6: Create in Linear (only on explicit approval)

阶段6：在Linear中创建工单（仅收到明确批准后执行）

Read config using the resolution order from Setup, then:
  1. mcp__linear__list_teams
    — resolve team ID
  2. mcp__linear__list_issue_labels
    — resolve label IDs
  3. mcp__linear__list_projects
    — resolve project ID (if configured)
  4. mcp__linear__list_cycles
    with 
    type: "current"
    — resolve current cycle (if 
    assign_to_current_cycle
    is true)
Create each approved ticket with 
mcp__linear__create_issue
:
  • team
    : from config
  • project
    : from config
  • assignee
    : from config
  • cycle
    : current cycle number
  • state
    : from config 
    default_status
  • labels
    : matched from ticket's Labels field
  • title
    : from ticket
  • description
    : full ticket body in markdown
  • links
    : source link if available (e.g. Fireflies transcript URL, Slack permalink)
Report created ticket identifiers back to the user.
按照配置步骤中的读取顺序读取配置，然后执行：
  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永久链接）
将创建成功的工单编号反馈给用户。

Key Rules

核心规则

  1. Concrete examples are non-negotiable. Engineers understand what to build from specific scenarios, not abstract descriptions. Preserve full reasoning chains, exact quotes, and real-world context.
  2. Never create tickets without user approval. Always draft to scratchpad first.
  3. Config is defaults, not constraints. User can override team, assignee, labels, or any other field per invocation.
  4. Don't over-consolidate. If two items are independent work, they're separate tickets. Group only when items are truly part of the same deliverable.
  5. Standalone requirements buried in conversation are tickets too. Things said in passing like "we also need to compare dates" represent distinct work items.
  1. 必须包含具体示例：工程师可以根据具体场景明确开发内容，但抽象描述不行。要保留完整的推理逻辑、准确引用和真实上下文。
  2. 永远不要在未获得用户批准的情况下创建工单：始终先在草稿区生成草案。
  3. 配置是默认值而非强制约束：用户每次调用时都可以覆盖团队、处理人、标签或任何其他字段。
  4. 不要过度合并：如果两个事项是独立工作，就拆分为独立工单。只有当多个事项确实属于同一个交付物时才合并。
  5. 对话中提到的独立需求也要生成工单：类似“我们还需要比对日期”这种随口提到的内容也属于独立工作项。