用途
incident-triage 用于对 Superset 托管服务可能发生的生产事故做第一轮分诊。它的定位是“收集事实并起草建议”，最终决策和对外发布由人完成。开始前需阅读 docs/runbooks/incidents.md 中“Severity”和“Status page updates”两节。
主要约束
- 只读：不部署、不回滚、不关闭工作流、不改开关、不解决 Sentry issue、不执行写操作 SQL。
- 不发布：不向 status.superset.sh、Slack、Discord、Plain、X 等任何渠道发帖，不宣布事故；输出只是对话中的草稿。
- 不猜测：工具未连接或检查失败时，写“not checked”并注明原因。
- 全程使用 UTC 时间。
使用方式
1. 界定报告
各写一行：用户以自身语言描述看到的现象；开始时间（首次报告或发现的第一个信号）；受影响范围（全体、某区域、某功能、某版本或某用户）。若只影响一个用户或一台机器，则停止分诊，告知这是支持问题，并建议使用 superset doctor。
2. 采集信号
可并行的检查同时运行，并记录每项结果及其时间：
- 近期部署：
gh run list --workflow "Deploy Production" --limit 5
--json databaseId,headSha,status,conclusion,createdAt,updatedAt git log --since="6 hours ago" --oneline origin/main 对接近开始时间的运行，查看失败或缓慢的作业，尤其是 deploy-database（迁移）：gh run view <id> --json jobs。 - Sentry：连接 Sentry MCP 工具时，搜索过去 2 小时内首次出现或激增的 issue，覆盖 api、web、admin、marketing、docs、relay（含 realtime）、sandbox、desktop、host-service、mobile 各项目；每个匹配记录标题、事件数、首次出现时间和版本。
- 健康检查（仅 GET，10 秒超时）： curl -sS -m 10 -w ' %{http_code} %{time_total}s\n' https://relay.superset.sh/health curl -sS -m 10 -w ' %{http_code} %{time_total}s\n' https://realtime.superset.sh/health curl -sS -m 10 -w ' %{http_code} %{time_total}s\n' https://api.superset.sh/api/health 预期：relay {"ok":true,"proto":2} 200，realtime {"ok":true} 200，API {"ok":true,"database":"ok"} 200。API 返回 503 时会指明数据库状态；其他 5xx 或超时视为失败。另读取 https://status.superset.sh/api/v2/summary.json 查看状态页当前内容。
- Vercel（若 CLI 已链接）：vercel ls 查看近期生产部署，vercel logs <deployment-url> 查看开始时间附近的错误。
- 上游状态：指出信号指向的上游提供商（Vercel、Cloudflare、Neon、GitHub），请人工查看其状态页；除非人工要求，不自行抓取。
3. 提出建议
按固定格式回复分诊草稿（标记为未发布），包含：一句话摘要（什么坏了、从何时起、影响谁）；各信号结果（部署、Sentry、健康检查状态码、Vercel 或“not checked: 原因”、可能原因）；建议严重级别 SEV1/2/3 及依据；建议的状态页更新（Investigating/Identified/Monitoring/Resolved）及按运行手册模板填写的消息；给负责人建议的后续步骤（例如回滚某部署）。结尾说明等待批准，未发布、未部署、未更改任何内容。
4. 停止
等待人工。若批准，由人工在 incident.io 自行发布；若要求修改，则重新起草并再次停止。批准后本技能仍保持只读，回滚等写操作属于本技能之外的单独请求。
适用场景
适用于 Superset 托管服务疑似生产事故的快速事实收集与分级建议，帮助负责人在人工决策前获得结构化的信号汇总和状态页文案草稿。
限制
仅限只读检查，不执行任何修复或发布动作；各检查依赖相应工具、CLI 或 MCP 连接，未连接时只能标注未检查；严重级别和状态页措辞依赖运行手册内容。