使用 Composio CLI 实现 Sentry 异常自动分诊awesome-codex-skills 中 sentry-triage 技能的完整实战指南【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skillsSentry Triage 是 awesome-codex-skills 仓库中一个面向「错误监控 AI 自动修复」场景的 Codex 技能。它的核心思路是让 Agent 通过 Composio CLI 直接拉取 Sentry 的 issue、事件、面包屑breadcrumbs与可疑提交suspect commits再把堆栈帧映射到本地源码逐行阅读最终由 Agent 直接输出修复补丁——彻底跳过复制堆栈、粘贴进聊天框的传统流程。读完本文你将掌握从单条 issue 深挖、批量分诊、编写可复用的 TypeScript 工作流文件到把未解决异常自动转成 Linear 工单的完整链路。技能定位与适用场景sentry-triage的元数据定义见 sentry-triage/SKILL.md 头部 frontmatter明确给出了它的触发条件与能力边界namesentry-triagedescription不依赖人工复制堆栈即可诊断 Sentry issue通过 Composio CLI 拉取 issue 详情、事件、面包屑和可疑提交并将堆栈帧映射到本地源码让 Agent 直接提出修复方案short-description通过 Composio CLI 进行 Sentry 错误诊断在实际工作中以下三类场景最值得触发该技能新告警即时响应Sentry 弹出一条新告警你希望 Agent 真正去调查而不是只复述告警标题。回归问题定位判断一次回归影响了哪些 release、哪些可疑提交、哪些文件快速圈定责任面。批量健康度盘点构建一份Top 10 未解决 issue摘要并附上可复现的线索culprit、发生次数、相关提交。这与仓库中 datadog-logs/SKILL.mdDatadog 日志过滤、pr-review-ci-fix/SKILL.mdPR 评审与 CI 自修复属于同一族用 Composio CLI 把外部可观测/协作工具接入 Agent 工作流的技能模式。环境准备安装 CLI、登录并授权 Sentry技能依赖 Composio CLI。完整的安装与授权流程如下curl -fsSL https://composio.dev/install | bash composio login composio link sentry # 授予 event:read project:read 权限的 auth tokencomposio login会在浏览器中完成 OAuth 认证并允许你选择默认组织与项目自动化流程中可用-y跳过交互提示该用法与仓库中 connect/SKILL.md 描述一致。composio link sentry只需完成一次 OAuth 授权连接会持久化保存后续命令无需重复授权。对于非交互式运行如 CI 或定时任务可通过环境变量COMPOSIO_API_KEY提供认证凭证COMPOSIO_BASE_URL可指定自定义 API 端点。发现可用工具从搜索到确认 SchemaComposio 以工具 slug如SENTRY_GET_AN_ISSUE为粒度暴露 Sentry 的能力。由于不同版本的工具集可能存在差异技能要求在使用前先执行发现与校验composio search get sentry issue --toolkits sentry composio search list events for issue --toolkits sentry composio tools list sentry常用 slug 如下务必先用--get-schema校验参数结构工具 slug用途SENTRY_GET_AN_ISSUE按 short ID如PROJ-1F4或数字 ID 获取单个 issueSENTRY_LIST_AN_ISSUES_EVENTS列出某个 issue 的事件可携带完整堆栈与面包屑SENTRY_RETRIEVE_AN_EVENT_FOR_A_PROJECT获取项目下某个具体事件SENTRY_LIST_A_PROJECTS_ISSUES按查询条件列出项目下的 issue批量分诊核心SENTRY_UPDATE_AN_ISSUE更新 issue 状态如标记 resolved、指定修复版本与仓库中其他技能一致推荐的口径是先composio search定位 slug再composio execute SLUG --get-schema确认入参必要时用--dry-run试跑最后才正式执行参见 connect/SKILL.md 的 Core Workflow。单条 issue 深度诊断五步闭环技能把诊断一条 Sentry 异常固化为五步操作闭环每一步都有对应的 CLI 命令支撑。第 1 步拉取 issue 主信息composio execute SENTRY_GET_AN_ISSUE -d {issue_id:PROJ-1F4}issue_id支持两种形式Sentry 的 short ID如PROJ-1F4或纯数字 ID。注意不要使用 URL slug——这是后续 Troubleshooting 中最常见的坑。第 2 步获取最新事件含完整堆栈与面包屑composio execute SENTRY_LIST_AN_ISSUES_EVENTS \ -d {issue_id:PROJ-1F4,full:true,limit:1}full: true表示返回包含完整堆栈stacktrace与面包屑breadcrumbs的详细事件limit: 1只取最新一条避免上下文被历史事件撑爆。第 3 步把每个堆栈帧映射到本地源码对堆栈中的每一个filenamelinenoAgent 直接打开本地对应文件并读取该行附近 ±20 行的代码file在line ± 20范围内阅读。这一步完全在本地文件系统完成不需要任何复制粘贴是跳过 copy-paste 舞蹈的关键设计。第 4 步核查可疑提交Sentry 在开启 release tracking 后会自动为 issue 关联 suspect commits可疑提交。Agent 定位到这些提交后在本地用git show sha查看具体改动确认回归是否由某个提交引入。第 5 步输出补丁并回写状态composio execute SENTRY_UPDATE_AN_ISSUE \ -d {issue_id:PROJ-1F4,status:resolved,statusDetails:{inNextRelease:true}}修复流程是Agent 依据本地源码起草 diff → 本地跑测试 → 测试通过后调用SENTRY_UPDATE_AN_ISSUE将 issue 标记为resolved并通过statusDetails.inNextRelease: true声明该修复将随下一个 release 发布。批量分诊Top N 未解决 issue 排行当需要扫一眼项目当前积压的未解决异常时使用SENTRY_LIST_A_PROJECTS_ISSUES配合 Sentry 搜索语法composio execute SENTRY_LIST_A_PROJECTS_ISSUES -d { organization_slug:acme, project_slug:api, query:is:unresolved age:-24h, sort:freq, limit:20 }参数含义organization_slug/project_slugSentry 中的组织与项目标识querySentry 搜索语法is:unresolved过滤未解决项age:-24h限定最近 24 小时也可替换为is:resolved、is:archived等其他状态sort排序方式freq按发生频率排序limit返回条数上限。由于 Composio 的输出是 JSONstdout可以继续管道给jq生成按频率降序的摘要composio execute SENTRY_LIST_A_PROJECTS_ISSUES -d {organization_slug:acme,project_slug:api,query:is:unresolved} \ | jq -r .[] | \(.count)\t\(.shortId)\t\(.title) | sort -rn | head这段命令输出count → shortId → title三列并排序取前 N 条即可快速生成Top 未解决 issue日报供人工或 Agent 进一步跟进。编写可复用的诊断工作流文件把多步操作固化为脚本是复用该技能的最佳实践。仓库中的 datadog-logs/SKILL.md 与 pr-review-ci-fix/SKILL.md 同样采用这种.ts工作流文件 composio run --file的模式。将下述内容保存为scripts/sentry-diag.ts然后执行composio run --file scripts/sentry-diag.ts -- --id PROJ-1F4const id process.argv[process.argv.indexOf(--id) 1]; const issue await execute(SENTRY_GET_AN_ISSUE, { issue_id: id }); const [event] await execute(SENTRY_LIST_AN_ISSUES_EVENTS, { issue_id: id, full: true, limit: 1 }); const frames (event?.entries ?? []) .filter(e e.type exception) .flatMap(e e.data.values.flatMap(v v.stacktrace?.frames ?? [])) .filter(f f.inApp) .map(f ({ file: f.filename, line: f.lineno, fn: f.function })); console.log(JSON.stringify({ title: issue.title, culprit: issue.culprit, frames }, null, 2));这段脚本的逻辑拆解从--id参数读取 issue ID依次调用SENTRY_GET_AN_ISSUE与SENTRY_LIST_AN_ISSUES_EVENTS拉取主信息与最新事件从事件的entries中筛出type exception的条目扁平化取出所有stacktrace.frames用f.inApp过滤掉第三方/框架代码只保留应用自身的帧输出结构化的{ title, culprit, frames }其中每帧包含file、line、fn。随后 Agent 依据frames中的每个file在line ± 20范围内读取本地源码并起草补丁。inApp过滤非常关键它把注意力锁定在项目自己的代码上避免被 vendor 代码干扰。链路编排把 Top 异常自动转成 Linear 工单技能的最后一段给出了分诊 → 转工单的组合拳用一条composio run内联脚本把频率最高的未解决 issue 自动创建为 Linear ticket。composio run const [top] await execute(SENTRY_LIST_A_PROJECTS_ISSUES, { organization_slug: acme, project_slug: api, query: is:unresolved, sort: freq, limit: 1 }); await execute(LINEAR_CREATE_ISSUE, { teamId: TEAM_ID, title: [Sentry] ${top.title}, description: Short ID: ${top.shortId}\nPermalink: ${top.permalink}\nCount: ${top.count} }); 要点说明第一步从 Sentry 取回is:unresolved且按freq排序的第一条 issue第二步调用LINEAR_CREATE_ISSUE创建工单标题加[Sentry]前缀描述中写入 short ID、Permalink 与发生次数保留完整追溯信息这种跨工具链式编排依赖 Linear 工具集已通过composio link linear完成授权。如果你的团队用 Linear MCP 而不是 Composio 工具集仓库中的 linear/SKILL.md 提供了另一条路径codex mcp add linear --url https://mcp.linear.app/mcp启用rmcp_client特性后用codex mcp login linear完成 OAuth再调用create_issue等工具。两条路线可按团队现有的集成方式任选其一。常见问题排查Troubleshooting技能内置了四个高频坑位的排障指引404 on issue_id→ 应使用 short ID如PROJ-1F4而非 URL slug。这是SENTRY_GET_AN_ISSUE入参最容易踩的雷。事件列表为空→ 说明该 issue 可能已被 resolved/archived改用query:is:resolved查询或调大limit。缺少 suspect commit→ 说明 Sentry 侧未配置 release tracking需要在 CI 中通过sentry-cli releases上报 release 信息Agent 才能拿到提交级线索。没有inApp帧→ 说明前端源码映射source map未上传堆栈只会显示 vendor 代码需要在上线流程中补充 source map 上传步骤。在 Codex 中安装并使用本技能sentry-triage位于仓库根目录下的 sentry-triage/ 文件夹安装方式与仓库内其他技能一致详见 README.md 的 Quickstart 章节手动安装将sentry-triage/整个目录复制到$CODEX_HOME/skills/默认~/.codex/skills/确保SKILL.md位于~/.codex/skills/sentry-triage/SKILL.md重启 Codex使其重新加载技能元数据在会话中自然描述任务如帮我看看 Sentry 里那个 PROJ-1F4 异常Codex 会根据 frontmatter 的description自动匹配并触发该技能。若需要批量管理多个技能也可使用仓库中的 skill-installer/SKILL.md 提供的安装脚本。需要说明的是技能只会驱动 Agent 执行查看、诊断、编写补丁、更新 issue 状态等操作仓库本身是只读的。总结sentry-triage把 Sentry 告警处理从人肉复制堆栈 → 粘贴提问 → 人工读代码的旧流程升级为Agent 自动拉取 issue/事件/可疑提交 → 帧级映射本地源码 → 直接产出补丁的新闭环。配合批量查询、composio run工作流文件与 Linear/Slack 链路编排它既可以服务单条告警的即时响应也能支撑每日未解决 issue 的自动盘点——这正是 awesome-codex-skills 仓库所倡导的给技能接入真实行动力理念在错误监控领域的落地示例。【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 Composio CLI 实现 Sentry 异常自动分诊：awesome-codex-skills 中 sentry-triage 技能的完整实战指南
使用 Composio CLI 实现 Sentry 异常自动分诊awesome-codex-skills 中 sentry-triage 技能的完整实战指南【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skillsSentry Triage 是 awesome-codex-skills 仓库中一个面向「错误监控 AI 自动修复」场景的 Codex 技能。它的核心思路是让 Agent 通过 Composio CLI 直接拉取 Sentry 的 issue、事件、面包屑breadcrumbs与可疑提交suspect commits再把堆栈帧映射到本地源码逐行阅读最终由 Agent 直接输出修复补丁——彻底跳过复制堆栈、粘贴进聊天框的传统流程。读完本文你将掌握从单条 issue 深挖、批量分诊、编写可复用的 TypeScript 工作流文件到把未解决异常自动转成 Linear 工单的完整链路。技能定位与适用场景sentry-triage的元数据定义见 sentry-triage/SKILL.md 头部 frontmatter明确给出了它的触发条件与能力边界namesentry-triagedescription不依赖人工复制堆栈即可诊断 Sentry issue通过 Composio CLI 拉取 issue 详情、事件、面包屑和可疑提交并将堆栈帧映射到本地源码让 Agent 直接提出修复方案short-description通过 Composio CLI 进行 Sentry 错误诊断在实际工作中以下三类场景最值得触发该技能新告警即时响应Sentry 弹出一条新告警你希望 Agent 真正去调查而不是只复述告警标题。回归问题定位判断一次回归影响了哪些 release、哪些可疑提交、哪些文件快速圈定责任面。批量健康度盘点构建一份Top 10 未解决 issue摘要并附上可复现的线索culprit、发生次数、相关提交。这与仓库中 datadog-logs/SKILL.mdDatadog 日志过滤、pr-review-ci-fix/SKILL.mdPR 评审与 CI 自修复属于同一族用 Composio CLI 把外部可观测/协作工具接入 Agent 工作流的技能模式。环境准备安装 CLI、登录并授权 Sentry技能依赖 Composio CLI。完整的安装与授权流程如下curl -fsSL https://composio.dev/install | bash composio login composio link sentry # 授予 event:read project:read 权限的 auth tokencomposio login会在浏览器中完成 OAuth 认证并允许你选择默认组织与项目自动化流程中可用-y跳过交互提示该用法与仓库中 connect/SKILL.md 描述一致。composio link sentry只需完成一次 OAuth 授权连接会持久化保存后续命令无需重复授权。对于非交互式运行如 CI 或定时任务可通过环境变量COMPOSIO_API_KEY提供认证凭证COMPOSIO_BASE_URL可指定自定义 API 端点。发现可用工具从搜索到确认 SchemaComposio 以工具 slug如SENTRY_GET_AN_ISSUE为粒度暴露 Sentry 的能力。由于不同版本的工具集可能存在差异技能要求在使用前先执行发现与校验composio search get sentry issue --toolkits sentry composio search list events for issue --toolkits sentry composio tools list sentry常用 slug 如下务必先用--get-schema校验参数结构工具 slug用途SENTRY_GET_AN_ISSUE按 short ID如PROJ-1F4或数字 ID 获取单个 issueSENTRY_LIST_AN_ISSUES_EVENTS列出某个 issue 的事件可携带完整堆栈与面包屑SENTRY_RETRIEVE_AN_EVENT_FOR_A_PROJECT获取项目下某个具体事件SENTRY_LIST_A_PROJECTS_ISSUES按查询条件列出项目下的 issue批量分诊核心SENTRY_UPDATE_AN_ISSUE更新 issue 状态如标记 resolved、指定修复版本与仓库中其他技能一致推荐的口径是先composio search定位 slug再composio execute SLUG --get-schema确认入参必要时用--dry-run试跑最后才正式执行参见 connect/SKILL.md 的 Core Workflow。单条 issue 深度诊断五步闭环技能把诊断一条 Sentry 异常固化为五步操作闭环每一步都有对应的 CLI 命令支撑。第 1 步拉取 issue 主信息composio execute SENTRY_GET_AN_ISSUE -d {issue_id:PROJ-1F4}issue_id支持两种形式Sentry 的 short ID如PROJ-1F4或纯数字 ID。注意不要使用 URL slug——这是后续 Troubleshooting 中最常见的坑。第 2 步获取最新事件含完整堆栈与面包屑composio execute SENTRY_LIST_AN_ISSUES_EVENTS \ -d {issue_id:PROJ-1F4,full:true,limit:1}full: true表示返回包含完整堆栈stacktrace与面包屑breadcrumbs的详细事件limit: 1只取最新一条避免上下文被历史事件撑爆。第 3 步把每个堆栈帧映射到本地源码对堆栈中的每一个filenamelinenoAgent 直接打开本地对应文件并读取该行附近 ±20 行的代码file在line ± 20范围内阅读。这一步完全在本地文件系统完成不需要任何复制粘贴是跳过 copy-paste 舞蹈的关键设计。第 4 步核查可疑提交Sentry 在开启 release tracking 后会自动为 issue 关联 suspect commits可疑提交。Agent 定位到这些提交后在本地用git show sha查看具体改动确认回归是否由某个提交引入。第 5 步输出补丁并回写状态composio execute SENTRY_UPDATE_AN_ISSUE \ -d {issue_id:PROJ-1F4,status:resolved,statusDetails:{inNextRelease:true}}修复流程是Agent 依据本地源码起草 diff → 本地跑测试 → 测试通过后调用SENTRY_UPDATE_AN_ISSUE将 issue 标记为resolved并通过statusDetails.inNextRelease: true声明该修复将随下一个 release 发布。批量分诊Top N 未解决 issue 排行当需要扫一眼项目当前积压的未解决异常时使用SENTRY_LIST_A_PROJECTS_ISSUES配合 Sentry 搜索语法composio execute SENTRY_LIST_A_PROJECTS_ISSUES -d { organization_slug:acme, project_slug:api, query:is:unresolved age:-24h, sort:freq, limit:20 }参数含义organization_slug/project_slugSentry 中的组织与项目标识querySentry 搜索语法is:unresolved过滤未解决项age:-24h限定最近 24 小时也可替换为is:resolved、is:archived等其他状态sort排序方式freq按发生频率排序limit返回条数上限。由于 Composio 的输出是 JSONstdout可以继续管道给jq生成按频率降序的摘要composio execute SENTRY_LIST_A_PROJECTS_ISSUES -d {organization_slug:acme,project_slug:api,query:is:unresolved} \ | jq -r .[] | \(.count)\t\(.shortId)\t\(.title) | sort -rn | head这段命令输出count → shortId → title三列并排序取前 N 条即可快速生成Top 未解决 issue日报供人工或 Agent 进一步跟进。编写可复用的诊断工作流文件把多步操作固化为脚本是复用该技能的最佳实践。仓库中的 datadog-logs/SKILL.md 与 pr-review-ci-fix/SKILL.md 同样采用这种.ts工作流文件 composio run --file的模式。将下述内容保存为scripts/sentry-diag.ts然后执行composio run --file scripts/sentry-diag.ts -- --id PROJ-1F4const id process.argv[process.argv.indexOf(--id) 1]; const issue await execute(SENTRY_GET_AN_ISSUE, { issue_id: id }); const [event] await execute(SENTRY_LIST_AN_ISSUES_EVENTS, { issue_id: id, full: true, limit: 1 }); const frames (event?.entries ?? []) .filter(e e.type exception) .flatMap(e e.data.values.flatMap(v v.stacktrace?.frames ?? [])) .filter(f f.inApp) .map(f ({ file: f.filename, line: f.lineno, fn: f.function })); console.log(JSON.stringify({ title: issue.title, culprit: issue.culprit, frames }, null, 2));这段脚本的逻辑拆解从--id参数读取 issue ID依次调用SENTRY_GET_AN_ISSUE与SENTRY_LIST_AN_ISSUES_EVENTS拉取主信息与最新事件从事件的entries中筛出type exception的条目扁平化取出所有stacktrace.frames用f.inApp过滤掉第三方/框架代码只保留应用自身的帧输出结构化的{ title, culprit, frames }其中每帧包含file、line、fn。随后 Agent 依据frames中的每个file在line ± 20范围内读取本地源码并起草补丁。inApp过滤非常关键它把注意力锁定在项目自己的代码上避免被 vendor 代码干扰。链路编排把 Top 异常自动转成 Linear 工单技能的最后一段给出了分诊 → 转工单的组合拳用一条composio run内联脚本把频率最高的未解决 issue 自动创建为 Linear ticket。composio run const [top] await execute(SENTRY_LIST_A_PROJECTS_ISSUES, { organization_slug: acme, project_slug: api, query: is:unresolved, sort: freq, limit: 1 }); await execute(LINEAR_CREATE_ISSUE, { teamId: TEAM_ID, title: [Sentry] ${top.title}, description: Short ID: ${top.shortId}\nPermalink: ${top.permalink}\nCount: ${top.count} }); 要点说明第一步从 Sentry 取回is:unresolved且按freq排序的第一条 issue第二步调用LINEAR_CREATE_ISSUE创建工单标题加[Sentry]前缀描述中写入 short ID、Permalink 与发生次数保留完整追溯信息这种跨工具链式编排依赖 Linear 工具集已通过composio link linear完成授权。如果你的团队用 Linear MCP 而不是 Composio 工具集仓库中的 linear/SKILL.md 提供了另一条路径codex mcp add linear --url https://mcp.linear.app/mcp启用rmcp_client特性后用codex mcp login linear完成 OAuth再调用create_issue等工具。两条路线可按团队现有的集成方式任选其一。常见问题排查Troubleshooting技能内置了四个高频坑位的排障指引404 on issue_id→ 应使用 short ID如PROJ-1F4而非 URL slug。这是SENTRY_GET_AN_ISSUE入参最容易踩的雷。事件列表为空→ 说明该 issue 可能已被 resolved/archived改用query:is:resolved查询或调大limit。缺少 suspect commit→ 说明 Sentry 侧未配置 release tracking需要在 CI 中通过sentry-cli releases上报 release 信息Agent 才能拿到提交级线索。没有inApp帧→ 说明前端源码映射source map未上传堆栈只会显示 vendor 代码需要在上线流程中补充 source map 上传步骤。在 Codex 中安装并使用本技能sentry-triage位于仓库根目录下的 sentry-triage/ 文件夹安装方式与仓库内其他技能一致详见 README.md 的 Quickstart 章节手动安装将sentry-triage/整个目录复制到$CODEX_HOME/skills/默认~/.codex/skills/确保SKILL.md位于~/.codex/skills/sentry-triage/SKILL.md重启 Codex使其重新加载技能元数据在会话中自然描述任务如帮我看看 Sentry 里那个 PROJ-1F4 异常Codex 会根据 frontmatter 的description自动匹配并触发该技能。若需要批量管理多个技能也可使用仓库中的 skill-installer/SKILL.md 提供的安装脚本。需要说明的是技能只会驱动 Agent 执行查看、诊断、编写补丁、更新 issue 状态等操作仓库本身是只读的。总结sentry-triage把 Sentry 告警处理从人肉复制堆栈 → 粘贴提问 → 人工读代码的旧流程升级为Agent 自动拉取 issue/事件/可疑提交 → 帧级映射本地源码 → 直接产出补丁的新闭环。配合批量查询、composio run工作流文件与 Linear/Slack 链路编排它既可以服务单条告警的即时响应也能支撑每日未解决 issue 的自动盘点——这正是 awesome-codex-skills 仓库所倡导的给技能接入真实行动力理念在错误监控领域的落地示例。【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考