调查工作流技能
自动化针对客户问题的完整 TAM 调查流程。
用法
/investigate <客户名称> <问题描述>
示例：
/investigate LSEG "webhook 超时错误"/investigate "Network International" "BeyondTrust 插件认证"/investigate Roche "调度器未触发作业"
该技能的用途
执行来自 CLAUDE.md 的完整调查工作流：
- 查找客户档案 - 定位并读取客户环境详情
- 搜索知识库 - 查找类似调查和最佳实践
- 检查文档 - 验证行为是否已记录
- 在代码中验证 - 搜索产品源代码以了解实际行为
- 检查外部跟踪器 - 搜索 GitHub Issues 和 Jira 以了解已知的错误/开发
- 推荐测试环境 - 根据问题类型建议合适的沙箱
- 总结发现 - 提供带有引用的结构化摘要
- 记录调查结果 - 在 investigations/ 中使用模板创建新的调查文件
指令
当此技能被调用时，请遵循以下步骤：
步骤 1：提取参数
从参数中识别：
customer_name：客户/公司名称issue_keywords：描述问题的关键术语（错误消息、功能、组件）
步骤 2：查找客户档案
Grep pattern="<customer_name>" path="customers/" output_mode="files_with_matches"
如果找到：
Read客户档案文件- 注意：环境（云/本地）、Rundeck 版本、规模、过去的问题
- 保存客户上下文以备后用
如果未找到：
- 注意：“客户档案未找到——可能是潜在客户或初次接触”
- 继续调查
步骤 3：搜索知识库
类似调查：
Grep pattern="<issue_keywords>" glob="investigations/**/*.md" output_mode="content" -C 3
相关最佳实践：
Grep pattern="<issue_keywords>" glob="best-practices/**/*.md" output_mode="content" -C 2
对于每个结果：
- 注意文件路径、日期（如果文件名中有的话）和关键发现
- 确定是否为精确匹配或类似模式
- 提取解决方案或变通方法
步骤 4：检查文档
Grep pattern="<issue_keywords>" path="repositories/docs/" output_mode="content" -C 2
确定：
- 这是否是已记录的行为？
- 是否存在配置选项或已知限制？
- 文档是否与客户期望相符？
步骤 5：验证产品代码
Grep pattern="<relevant_class_or_method>" path="repositories/rundeckpro/" output_mode="content" head_limit=50
查找：
- 实际实现行为
- 默认值或常量
- 错误消息来源
- 版本特定逻辑
步骤 6：检查外部跟踪器
GitHub 社区问题（通过 Runlayer 连接器）：
通过 Runlayer 连接器查询 GitHub。调用 search_tools 定位 GitHub 问题搜索工具，然后调用 execute_tool 在 rundeck/rundeck 和 rundeckpro/rundeckpro 中搜索 <issue_keywords>，包括开放和已关闭的问题（每个限制约 10 个）。不要通过 shell 调用 gh。
Jira 开发跟踪（通过 Runlayer 连接器）：
通过 Runlayer 连接器查询 Jira。调用 search_tools 定位 Jira 问题搜索工具，然后使用返回的确切 tool_name 和参数调用 execute_tool，在项目 RUN 中搜索 <issue_keywords>，按更新日期排序（等效 JQL：project=RUN AND text~"<issue_keywords>" ORDER BY updated DESC）。不要直接调用 mcp__atlassian__* 工具。
对于每个相关结果：
- 注意问题编号、状态和摘要
- 检查是否在特定版本中修复
- 注意提到的任何变通方法
步骤 7：推荐测试环境
仅在沙箱环境可用时执行此操作。如果不可用，请注明：“无可用沙箱环境——建议使用本地 WAR 进行快速复现”。 根据问题特征，推荐沙箱：
决策逻辑：
分析可用的沙箱环境并推荐最合适的。
参考：如果需要连接详情，Read .claude/memory/sandbox-environments.md
不要在此技能中连接到沙箱——仅提供推荐。
步骤 8：生成结构化摘要
以以下格式提供发现：
# 调查摘要：<客户名称> - <问题描述>
## 客户上下文
- **档案：** [已找到/未找到]
- **环境：** [云/本地, 版本, 规模]
- **过往问题：** [相关历史，如有]
## 知识库发现
### 类似调查
- [调查文件.md](路径) - <简要摘要>
- [状态：已解决/变通/开放]
### 相关最佳实践
- [最佳实践文件.md](路径) - <简要摘要>
## 文档状态
- **已记录：** [是/否/部分]
- **引用：** [包含行号的文件路径]
- **关键细节：** [相关配置、限制或指南]
## 代码分析
- **组件：** [类/方法名称]
- **行为：** [实际实现行为]
- **来源：** [file_path:line_number]
## 外部跟踪器状态
### GitHub Issues
- rundeck/rundeck#<编号> - <摘要> [状态]
- rundeckpro/rundeckpro#<编号> - <摘要> [状态]
### Jira Issues
- RUN-<编号> - <摘要> [状态，适用时附修复版本]
## 推荐的测试环境
**环境：** [AWS EKS / AWS EC2 / Local WAR / PDT-RDTAM]
**原因：** [数据库类型 / 问题细节 / 测试需求]
**连接：** 请参见 .claude/memory/sandbox-environments.md
## 后续步骤
1. [立即行动项]
2. [测试建议]
3. [客户沟通指南]
## 相关资源
- 客户档案：[路径，如果存在]
- 调查：[相关文件列表]
- 最佳实践：[适用指南列表]
- 文档：[关键文档页面]
质量准则
详尽但简洁：
- 不要包含每个搜索结果——优先考虑相关发现
- 为所有引用注明文件路径（例如
investigations/2026-03-15-issue.md:45） - 清晰地标注未知项（“未找到类似案例”而非模糊表述）
提供可操作的见解：
- 不要仅仅列出发现——综合模式
- 如果多次调查显示相同的解决方案，突出显示它
- 如果文档与代码冲突，明确标记出来
考虑客户上下文：
- 根据客户环境（云 vs 本地、版本）量身定制建议
- 如果存在相关模式，引用他们的过往问题
- 调整测试环境推荐以匹配他们的设置
错误处理
如果客户未找到：
- 在没有客户上下文的情况下继续调查
- 注意：“如果是重复接触，建议创建客户档案”
如果知识库没有结果：
- 尝试更广泛的搜索词
- 注意：“新问题——考虑在解决后将其记录为调查”
如果外部跟踪器不可用：
- 注意工具故障
- 使用可用信息继续
- 建议手动检查：“GitHub 搜索失败——手动检查 rundeck/rundeck 问题”
如果问题描述不明确：
- 使用可用关键字尽力而为
- 注意：“问题描述不明确——搜索覆盖了：[列出使用的术语]”
- 建议：“使用具体的错误消息或组件名称优化搜索”
步骤 9：记录调查结果
完成调查并展示摘要后，创建一个新的调查文件来记录发现：
创建文件：
investigations/YYYY-MM-DD-brief-kebab-case-description.md
使用模板： Read investigations/TEMPLATE.md 以获取结构
填充内容：
- 标题： 问题的简要描述
- 日期： 今天的日期（YYYY-MM-DD 格式）
- 客户： 调查中的客户名称
- 产品领域： 相关组件（webhooks、作业、节点等）
- 标签： 从类似调查中发现，加上问题特定的标签
- 问题陈述： 用户提供的问题描述
- 环境详情： 来自客户档案（如果找到）
- 调查步骤： 执行的搜索步骤摘要
- 根本原因： 如果在调查期间确定
- 解决方案/解决方法： 如果在知识库或文档中找到
- 相关文档： 搜索过程中发现的引用
- 代码/文档引用： 来自搜索结果的文件路径及行号
- 备注/经验： 调查中的任何模式或见解
创建文件后：
- 使用新条目更新
investigations/INDEX.md：- 添加到适当的类别部分
- 添加到按时间顺序的表格
- 在“按标签快速搜索”部分添加标签
- 更新“最后更新”日期
备注
- 调查在知识库中创建了永久记录
- 平均执行时间：搜索 30-60 秒 + 文档 2-3 分钟
- 所有发现均为研究——仍需要在推荐环境中进行实际测试
- 如需战略性定位建议，请单独调用
Read .claude/memory/tam-advisory-philosophy.md - 文档确保知识被捕获并可供未来调查搜索