Sentry 运维助手

当 Sentry 集成变成一场认证泥潭

把 Sentry 的 API 接进自动化工具时，开发者通常得直面三座大山：OAuth token 的获取与刷新、多环境凭证的管理、CLI 工具的登录状态维护。一旦凭证过期或 scope 变更，脚本就会莫名其妙地失败——排查问题比修复本身更费时间。

这个技能做了什么

核心思路是让 OOMOL 接管认证层。 当技能调用 Sentry connector 时，oo CLI 会通过 OOMOL 的服务端注入凭证，客户端永远拿不到原始 token。这意味着：

• 你不用在代码里硬编码 sentry_token 或维护 .env 文件
• 凭证轮换、scope 调整由 OOMOL 统一处理
• CLI 的登录状态在首次连接后保持有效

技能暴露了 19 个动作，覆盖了 Sentry 日常运维的核心场景：

• 读操作：get_issue、list_alerts、get_organization_release、get_replay 等，直接执行安全
• 写操作：update_issue 更新 issue 状态、分配或书签，执行前必须与用户确认 payload 和影响
• 不存在删除动作：说明设计者有意避免不可逆操作

关键执行流程：先通过 oo connector schema 拉取权威的输入/输出契约，再构造符合 schema 的 JSON payload 传给 --data。这样避免了“猜参数”或“试错”，也降低了因 schema 变更导致的运行时错误。

适用边界与注意事项

这技能不解决 Sentry 本身的监控问题，它只是提供了一种更干净的 API 调用方式。如果你需要的是告警规则配置、数据看板搭建，它帮不上忙。

首次设置仍然需要人工介入：当命令报出 scope_missing、credential_expired 等错误时，你需要手动完成 OAuth2 连接。这不是技能能自动化的部分。

写操作需要明确的用户确认。虽然技能不会阻止你执行 update_issue，但它的设计意图是让你在执行前展示完整的 payload 和预期效果——尤其是当你在生产环境操作时。

它假设你已经安装了 oo CLI 并完成了登录。这不是一次性设置，而是前置条件。如果你从零开始，仍需要手动安装 CLI、登录 OOMOL 账户。

总的来说，这是一个认证抽象层，不是完整的 Sentry 自动化方案。它的价值在于让你专注于 Sentry API 本身的逻辑，而不是被 token 管理、登录状态、错误恢复这些琐事绊住脚。