— 根因：<root cause summary> • ... 【桌面 Rust】N 个高优 issue • ... 【iOS】N 个高优 issue • ... 【Expo】N 个高优 issue • ... 修复命令：/sentry-fix <top-issue-id> ``` Omit any project section with zero matching issues. When step 0 found the quota exhausted, put that first, above every section: ``` ⚠️ Sentry 配额已耗尽（<usage>/<reserved>），<date> 起事件全部被丢弃，<billingPeriodEnd> 重置。以下列表停留在最后一条被接收的事件，不代表当前状态。 ``` ### 4. Report Out Present the report in the conversation. **Pushing to WeCom is a separate step that needs the user's go-ahead**, unless this run is the scheduled daily report (`/loop 24h /sentry-monitor`), where pushing is the whole point. When the user asked for an analysis rather than a daily report, show the report and offer to push — do not push unasked, since it posts to a group chat. ```bash wecom-cli msg send_message '{"chat_type": 2, "chatid": "wrOOClYgAA5gMJijxEUfWC6M0RAjwlWQ", "msgtype": "text", "text": {"content": "<report text>"}}' ``` If no fatal/high issues exist anywhere **and the quota gate was clean**: ``` Sentry 日报 <YYYY-MM-DD> — 全部正常，无高优 issue ``` ## Usage - One-time: `/sentry-monitor` - Recurring: `/loop 24h /sentry-monitor` ## Constraints - This skill is READ-ONLY. Never modify any code files. - Do not attempt to fix issues. Only report them. - If `sentry` CLI is not authenticated, prompt the user to run `sentry auth login`. - Never pipe a `sentry` command through `tail`/`head` when you care about success — the pipeline's exit code is the pager's, so a failed call reads as exit 0. Redirect to a file and check `$?`.

--- name: sentry-monitor description: Use when the user wants to check Sentry issues, run a Sentry daily report, or monitor error trends. Triggers on "sentry 监控", "sentry 日报", "查看 sentry", "sentry report", "sentry monitor". --- # Sentry Monitor — Daily Issue Report Scan the TeamClu Sentry projects for unresolved fatal/high issues, analyze root causes, and report. ## Projects | Project | Sentry Slug | Platform | |---------|-------------|----------| | Web / desktop frontend | `ucar-inc/teamclu-react` | JavaScript React | | Desktop Rust process | `ucar-inc/teamclu-rust` | Rust | | iOS | `ucar-inc/teamclu-ios` | apple-ios | | Expo | `ucar-inc/teamclu-expo` | react-native | `ucar-inc/teamclu` (the old Rust slug) **does not exist** — it was deleted, and `sentry issue list` 404s on it. `teamclu-rust` replaced it on 2026-09-04, so that project has no history before then; an empty result there is expected for a while rather than a signal. Re-verify with `sentry project list ucar-inc/ --json` if a scan errors on an unknown project. ## Execution Steps ### 0. Quota gate — do this FIRST The org is on Sentry's free tier: **5,000 errors/month, `onDemandMaxSpend = 0`**, billing period resetting on the **19th**. When the quota runs out Sentry drops every incoming event **silently** — from the issue list that looks identical to "no new errors." This has already happened twice (2026-08-17 and 2026-09-02), and the second time the projects sat blind for over two weeks. Never report "全部正常" without clearing this check. ```bash sentry api "/organizations/ucar-inc/stats_v2/?field=sum(quantity)&groupBy=outcome&category=error&statsPeriod=7d&interval=1d" ``` Read the `accepted` and `rate_limited` series: - `accepted` non-zero for the most recent day → ingestion is healthy, continue. - `accepted` at 0 with `rate_limited` climbing → **quota exhausted**. Stop the normal report. Lead with this instead, get the exact numbers from `sentry api "/customers/ucar-inc/"` (`categories.errors`: `usage` / `reserved` / `usageExceeded`, plus `billingPeriodEnd`), and say plainly that the issue list below is stale as of the last accepted event. ### 1. Scan Issues Run these in parallel, one per project: ```bash sentry issue list ucar-inc/teamclu-react --query "is:unresolved" --period 48h --json --fields shortId,title,priority,level,status --limit 30 sentry issue list ucar-inc/teamclu-rust --query "is:unresolved" --period 48h --json --fields shortId,title,priority,level,status --limit 30 sentry issue list ucar-inc/teamclu-ios --query "is:unresolved" --period 48h --json --fields shortId,title,priority,level,status --limit 30 sentry issue list ucar-inc/teamclu-expo --query "is:unresolved" --period 48h --json --fields shortId,title,priority,level,status --limit 30 ``` Use `--period` for the time window (`24h` / `48h` / `14d`), not a `lastSeen:` clause. Default is 90 days, which is far wider than a daily report wants. Filter results: keep only issues where `level` is `fatal` OR `priority` is `high`. **`--fields` gotcha (CLI 0.26.1):** `count`, `userCount`, `firstSeen` and `lastSeen` are listed in `--help` but are silently dropped from `issue list` output — you get the key omitted, not an error. Volume and recency have to come from `sentry issue view --json`, which does return them. Do not report event counts sourced from `issue list`. If no issues match **and step 0 was clean**, skip to step 4 with the "全部正常" message. If step 0 was not clean, say so instead — an empty list under an exhausted quota means nothing. ### 2. Analyze Root Causes (Local) For each filtered issue (max 10 total), perform local root cause analysis: 1. Fetch issue details with stack trace, which also carries the volume numbers: ```bash sentry issue view --json ``` 2. From the stack trace / error message, identify the relevant source files and functions in the codebase. 3. Read those source files to understand the code context around the error site. 4. Produce a one-sentence root cause summary based on the stack trace + source. Two things worth checking before writing the summary: - **Group splits.** The same defect often appears as several issues — a sourcemapped build and a minified one group separately. Compare `metadata.value` across the filtered set and treat identical values as one root cause rather than reporting the same bug three times. - **Prefer a sourcemapped frame.** When several groups share a value, analyze the one whose `culprit` is a repo path (`/src/...`) rather than a bundle (`assets/index-*.js`) — it names the file directly. When there are more than ~4 issues to analyze, run them as parallel subagents via the Agent tool; each runs `sentry issue view`, reads the relevant sources, and returns one sentence. For fewer than that, just do it inline — spawning agents costs more than it saves. If analysis cannot determine a root cause, use the error title as-is and say the root cause is undetermined. Do not guess. ### 3. Format Report ``` Sentry 日报【Web / 桌面】N 个高优 issue • [] — 根因：<root cause summary> • ... 【桌面 Rust】N 个高优 issue • ... 【iOS】N 个高优 issue • ... 【Expo】N 个高优 issue • ... 修复命令：/sentry-fix <top-issue-id> ``` Omit any project section with zero matching issues. When step 0 found the quota exhausted, put that first, above every section: ``` ⚠️ Sentry 配额已耗尽（<usage>/<reserved>），<date> 起事件全部被丢弃，<billingPeriodEnd> 重置。以下列表停留在最后一条被接收的事件，不代表当前状态。 ``` ### 4. Report Out Present the report in the conversation. **Pushing to WeCom is a separate step that needs the user's go-ahead**, unless this run is the scheduled daily report (`/loop 24h /sentry-monitor`), where pushing is the whole point. When the user asked for an analysis rather than a daily report, show the report and offer to push — do not push unasked, since it posts to a group chat. ```bash wecom-cli msg send_message '{"chat_type": 2, "chatid": "wrOOClYgAA5gMJijxEUfWC6M0RAjwlWQ", "msgtype": "text", "text": {"content": "<report text>"}}' ``` If no fatal/high issues exist anywhere **and the quota gate was clean**: ``` Sentry 日报 <YYYY-MM-DD> — 全部正常，无高优 issue ``` ## Usage - One-time: `/sentry-monitor` - Recurring: `/loop 24h /sentry-monitor` ## Constraints - This skill is READ-ONLY. Never modify any code files. - Do not attempt to fix issues. Only report them. - If `sentry` CLI is not authenticated, prompt the user to run `sentry auth login`. - Never pipe a `sentry` command through `tail`/`head` when you care about success — the pipeline's exit code is the pager's, so a failed call reads as exit 0. Redirect to a file and check `$?`.