用途：调查一个或多个工单，发布结构化“Triaging Notes”评论，既帮助 PM 理解问题并排优先级，也告诉工程师从哪里入手。开始时会声明“Using ticket-grooming to investigate [ticket(s)].”。
输入：从用户消息中提取工单键或 URL（如 ABC-1234、Atlassian 链接、#42），或问题的口头描述。支持标志 --dry-run（预览不发布）与 --full（发布完整报告，不折叠）。模式优先级：--full > CLAUDE.md 中的 grooming-mode > 默认短模式。
深度校准：按复杂度选择调查深度。外观类（标签、文案、UI 文本）只跑阶段 0、1（浅）和 5，跳过根因与风险评估，不做 staff review；已定位 bug（单一症状且有错误、堆栈或失败断言指明代码位置）跑完整流程，staff review 受限（5 次工具调用，聚焦“问题是否正确”与修复完整性）；标准 bug 或功能跑完整流程加完整 staff review；安全/数据完整性额外加安全检查清单。分类由编排器在派发前根据工单文本完成，通过 {REVIEW_BUDGET} 和 {REVIEW_SCOPE} 传入。不确定时用标准路径。
预检：解析配置（ticket 系统、站点、组织、仓库列表、grooming 模式、字段写入是否自动应用）；检查代码库索引并记录是否存在；校验工单键（须匹配 ^[A-Za-z][A-Za-z0-9]-[0-9]+$ 或 ^[a-z0-9][a-z0-9-]$，否则拒绝）；检测工单系统（Jira 用 getJiraIssue、searchJiraIssuesUsingJql、addCommentToJiraIssue；GitHub 用 gh issue view/list/comment；acli 作为回退）；解析 GitHub 远端信息；后端工单需解析所有配置仓库；多工单时检测共享上下文。
派发：每工单一个子代理（仅两级），最多 3 个并发，各自独立上下文，传绝对路径而非文件内容，输出到 {SCRATCHPAD}/{TICKET_KEY}/notes.md。调查后派发 staff review 子代理（model: "opus"），传 notes.md 路径。审查检查：是否针对报告者实际问题、命名实体是否在代码库验证、假设是否有证据与反证、可见部分是否 PM 可读、正确性/安全/模式遵循。外观类工单跳过 staff review。
发布：审查结论为 PASS 直接发布；PASS WITH NOTES 发布并告知用户；NEEDS FIXES 先修正 notes.md 再重新生成发布。用脚本转换：cd {SCRATCHPAD}/{TICKET_KEY} 后运行 python3 {SKILL_DIR}/scripts/md2adf.py --title "Full Investigation Details" > notes.adf.json（短模式）或加 --no-expand（完整模式）。随后读取 notes.md 与 notes.visible.md，用 jq 校验文档形状（短模式 expand 节点数 ==1，完整模式 ==0），非零退出则不发布。Jira 用 acli jira workitem comment create --key {TICKET_KEY} --body-file {SCRATCHPAD}/{TICKET_KEY}/notes.adf.json；GitHub 用 gh issue comment 直接发 Markdown。不要向 Jira 发原始 Markdown。
发布后：提议添加 has_notes 标签、设置优先级字段（需先确认项目实际用法），仅在配置 auto_apply_fields: true 时跳过询问。故事点只出现在注释文本中，不写入 Jira 字段。--dry-run 时在对话中展示摘要并询问是否发布。
无工单时：按口头描述跑调查流程（默认标准深度），在对话中呈现发现，询问是否创建工单。
限制：子代理不自行派发；不使用 ${CLAUDE_PLUGIN_ROOT}；不手改生成的 JSON；发布前必须亲自阅读文本；具体收费、价格、平台支持范围等资料未提供。