# 创建支持工单
为已报告的缺陷或用户问题创建一条 Linear 工单。

## 格式
- **报告人信息：** 邮箱、账号 ID、平台、应用版本
- **概要：** 简要的 1-2 句描述
- **预期结果 vs 实际结果：** 应该发生什么 vs 实际发生了什么
- **复现步骤：** 编号列表

## 备注
- 在创建工单前，从日志中收集用户信息
- 如有可用，请包含 request ID 或 trace ID
- 链接到相关的日志查询或仪表盘
- 未另有说明时，默认优先级为 Medium

# 撰写客户回复
就客户遇到的问题撰写一封回复。

## 指南
- 仅使用对外公开的产品名称
- 避免使用内部服务名称、代号或基础设施细节
- 不要分享内部错误码、文件路径或环境变量
- 仅使用公开文档中的功能和标准排障步骤

## 如有疑问
自问：“客户能通过正常使用产品得知这些信息吗？”
如果不能，则用通用调试思路重新表述。

# 搜索已知问题
在 Slack 中搜索，以确定该问题是否已经是已知问题。

## 流程
1. 使用标识符搜索（工单 ID、错误码、完整错误信息）
2. 按频道和时间范围缩小范围
3. 查找包含状态、临时解决方案或负责人信息的线程

## 输出
- **结论：** 已知 / 可能已知 / 未发现
- **最佳线程：** 永久链接 + 摘要
- **下一步搜索：** 在结果不理想时可尝试的查询

# 搜索日志
在 Datadog 中查询指定请求、用户或错误的日志。

## 常用模式
- @requestId:{id} — 查找特定请求
- @userId:{id} 或 @email:{email} — 查找用户活动
- status:error — 只筛选错误
- service:{name} — 按服务筛选

## 备注
- 始终指定时间范围（默认：最近 7 天）
- 字段名会因来源不同而变化——可以尝试多种模式
- 先从宽泛搜索开始，再根据发现逐步收窄范围

# Skill: 给客户的回复（安全且可执行）

## 我需要的输入
- 客户症状（他们看到的现象）
- 我们发现的情况（有依据的总结）
- 下一步/临时解决方案（如有）
- 需要向客户索取的 0–2 个缺失数据点

## 输出格式
- 简短的致谢/确认
- 我们发现的情况（不包含内部细节）
- 接下来要尝试的步骤（编号列出）
- 如有需要：最多两个问题（用于解除调查阻碍）
- 结尾说明我们这边接下来会做什么

## 约束/边界
- 避免涉及内部实现细节和内部行话
- 优先给出具体可执行步骤，而不是猜测
- 保持简洁；为「第一次就有用的回复」进行优化

# Skill: 撰写高质量的 bug 工单

## 我需要的输入
- 症状（客户可见的）
- 时间范围
- 任何相关 ID（request id、user/team id）
- 证据片段（已脱敏）

## 输出格式
## 摘要
## 期望结果 vs 实际结果
## 复现步骤
## 证据
## 影响范围/严重程度
## 建议的下一步调试步骤

## 质量标准
- 不使用含糊的表述（如「有时候」「不能用」），除非给出具体条件
- 标题中不使用仅内部人员才懂的行话
- 屏蔽客户特定信息，除非已明确获批可使用

# Skill: 已知问题检索助手（Slack + Notion）

## 我需要的输入
- 精确的报错文本（或最接近的版本）
- 功能区域相关的关键词
- 时间范围（默认：最近 30 天）

## 工作流程
- 先在 Slack 中搜索精确短语和标识符。
- 如果结果较弱，再用功能关键词和时间筛选进行扩展搜索。
- 在 Notion 中搜索同一功能区域的 runbook/FAQ。

## 输出格式
- 结论：已知 / 可能已知 / 未发现
- 最相关的讨论帖：1–3 个链接，并附一行说明「为何相关」
- 解决方案 / 缓解措施（如有）
- 下一步搜索优化建议：下一次要运行的精确查询语句

supportInvestigationPack:
  goal: >
    Produce a grounded investigation summary, a draft bug ticket,
    and a customer reply by running specialized agents in parallel.
  inputs:
    - customer_symptom
    - time_window
    - identifiers:
        request_id: ""
        user_or_team_id: ""
        error_text: ""
    - investigation_notes
  agents:
    - name: LogInvestigator
      focus: "Datadog: identify the most likely failure point and supporting evidence."
      output:
        - suspected_root_cause
        - strongest_evidence
        - disconfirming_checks
        - open_questions
    - name: KnownIssueMiner
      focus: "Slack/Notion: find prior art, current status, and workaround."
      output:
        - verdict
        - best_links
        - workaround
        - next_search_query
    - name: TicketWriter
      focus: "Write an engineering-facing bug ticket from evidence + notes."
      output:
        - title
        - summary
        - expected_vs_actual
        - steps_to_repro
        - evidence
        - suggested_next_debug_step
    - name: CustomerReplyDrafter
      focus: "Draft a customer reply: clear, safe, and actionable."
      constraints:
        - "Do not include internal implementation details."
        - "Ask for at most two missing data points."
      output:
        - reply_text
        - questions_for_customer
  final_assembler:
    merges:
      - LogInvestigator
      - KnownIssueMiner
      - TicketWriter
      - CustomerReplyDrafter
    produces:
      - investigation_summary
      - ticket_draft
      - customer_reply