用途：针对 Linear 中 High/Urgent 级别的 bug，调查其发生原因，并按团队格式发布结构化根因评论。团队规则要求此类缺陷必须留下书面根因。
主要能力：先收集上下文，再定位真正根因，最后按固定格式起草并发布评论。流程强调先起草、经确认后再发布。
使用方式：第一步运行 /investigate $ARGUMENTS 拉取工单、同步的 Slack 线程、既往工作和相关代码；在工单与线程总结完成前不要开始代码搜索或 devsql。若未运行该命令，至少执行 linear issue view <id> 查看工单及其同步 Slack 线程，再用 git log -S、gh pr view 追踪引入和重新引入问题的写入路径或提交。第二步找出最早使 bug 成为可能的决策，以及后续重新引入或仅部分修复的每个 PR，目标是错误类别而非单行代码，且必须对照代码或数据验证，不得断言未验证的原因。第三步在聊天中按团队格式渲染草稿供审阅，结构包括根因一句话、2-4 句说明被违反的不变量与触发条件、时间线、分类、本 PR 的前向修复与回填范围、后续防止复发的改动；每个术语首次出现需解释，描述行为与影响而非代码内部，PR 与工单用 markdown 链接，未验证的声明标注 unconfirmed。第四步仅在明确批准后发布：将正文写入临时文件，用 linear issue comment add <issue-id> --body-file /tmp/root-cause.md 发布以保留 markdown；在已有线程中回复用 -p <parentCommentId>，ID 可通过 linear issue comment list <id> 获取。
适用场景：需要为高优先级缺陷撰写根因说明并归档到 Linear 的团队。
限制：发布前必须获得明确确认，绝不擅自发布；未验证内容不得当作事实；资料未提供具体收费、平台支持范围等信息。