会话调试分析Skill dyad:session-debug

---

name: dyad:session-debug description: 分析会话调试数据，以识别可能引起用户报告问题的错误和问题。

会话调试

分析会话调试数据，以识别可能引起用户报告问题的错误和问题。

参数

• $ARGUMENTS: 预期两个以空格分隔的参数：
  1. 包含会话调试数据的JSON文件的URL（以http://或https://开头）
  2. GitHub问题编号或URL

指令

1. 解析和验证参数：

   在空白字符处分割$ARGUMENTS以获取恰好两个参数：

   • 第一个参数：会话数据URL（必须以http://或https://开头）
   • 第二个参数：GitHub问题标识符（如编号123或完整URL如https://github.com/owner/repo/issues/123）

   验证： 如果提供的参数少于两个，通知用户：

   “用法：/dyad:session-debug <会话数据URL> <问题编号或URL>” “示例：/dyad:session-debug https://example.com/session.json 123”

   然后停止执行。

2. 获取GitHub问题：

   gh issue view <issue-number> --json title,body,comments,labels
   

   理解：

   • 用户报告的问题是什么
   • 如果提供，重现步骤
   • 预期与实际行为
   • 用户提到的任何错误消息

3. 获取会话调试数据：

   使用WebFetch从提供的URL检索JSON会话数据。

4. 分析会话数据：

   查找可疑条目包括：

   • 错误： 任何错误消息、堆栈跟踪或异常日志
   • 警告： 可能指示问题的警告级别日志条目
   • 失败请求： HTTP错误、超时失败、连接问题
   • 意外状态： 期望数据时出现空值、空响应
   • 时间异常： 异常长时间的操作、超时
   • 失败前的用户操作： 用户在问题发生前做了什么

5. 与报告的问题关联：

   对每个发现的可疑条目进行评估：

   • 时间是否匹配用户报告问题发生时？
   • 错误消息是否与用户提到的功能/区域相关？
   • 这个错误是否会导致用户描述的症状？

6. 排序发现：

   创建一个可能原因的排序列表，按可能性排序：

   ## 最可能的原因
   
   ### 1. [错误/问题名称]
   - **证据：** 在会话数据中发现了什么
   - **时间戳：** 发生时间
   - **关联：** 如何与报告的问题相关
   - **置信度：** 高/中/低
   
   ### 2. [错误/问题名称]
   ...
   

7. 提供建议：

   对每个高置信度的发现，建议：

   • 在代码库中何处调查
   • 潜在根本原因
   • 如果明显，建议的修复方法

8. 总结：

   • 发现的错误/警告总数
   • 前三个最可能的原因
   • 调查的推荐下一步