Investigate Sentry alerts using Datadog logs and recent GitHub changes, then post an initial diagnosis with a severity assessment. Notify the on-call team when severity reaches the configured threshold or the investigation remains inconclusive, without changing monitored systems.
中文简介正在准备中。当前显示英语简介。
On-call alert triage runbook for {{sentry_project}}. Pulls the Sentry stack trace, correlates Datadog logs around the spike, checks {{target_repo}} for the deploy that shipped just before, classifies severity against known-noisy patterns, posts a first-pass diagnosis to {{incident_channel}}, and pages a human only when severity is at or above {{page_severity_threshold}} or the alert can't be resolved.
安装前可以查看交给 AI 代理的指令内容。
Reactive and read-only; covers every new or still-unresolved alert in {{sentry_project}} found in a sweep, nothing carried over between sweeps. Handle each alert as an independent unit: a failure or inconclusive diagnosis on one alert never blocks triage of the others found in the same sweep. </overview>
<when-to-load> - The alert-triage sweep fires on its cadence. - A human asks the agent to re-triage a specific alert or explain why one was paged (or wasn't). </when-to-load> <workflow>Via the Sentry connector, for every alert in {{sentry_project}} that is new or still unresolved since the last sweep:
Via the Datadog connector, pull the log lines in a window around the first-seen timestamp (default: 10 minutes before to 5 minutes after), scoped to the service(s) named in the stack trace. Line the log entries up against the trace to confirm the failure mode — a matching upstream timeout, a bad payload, a dependency erroring — rather than trusting the exception message alone.
gh pr list --repo {{target_repo}} --state merged --limit 20 \
--json number,title,mergedAt,url,author \
--search "merged:>=<first-seen-minus-2h>"
git log --since="<first-seen-minus-2h>" --until="<first-seen>" --oneline
Rank candidate deploys by how closely they precede the first-seen timestamp and whether the changed files touch the failing service/module. Treat the closest matching deploy as the suspect, not a certainty — say so in the diagnosis.
| Signal | Classification |
|---|---|
| Matches a known flaky/noisy pattern (repeated transient timeout, third-party rate limit, a fingerprint seen before with no user impact) | Benign — close with reasoning, no page |
| New error type, affects one user or a narrow code path, no matching deploy | Real, low severity — post diagnosis, no page unless it recurs |
| Spike in frequency, matches a recent deploy, or affects a shared/critical path | Real, elevated severity |
Marked fatal/critical in Sentry, or severity at or above {{page_severity_threshold}} | Page immediately regardless of diagnosis confidence |
| Trace, logs, or deploy history are inconclusive after Steps 1–3 | Unresolved — page, diagnosis attached as partial context |
Post one message per alert to {{incident_channel}}: the error and where it's from, the first-seen time and frequency, the correlated log lines, the suspect deploy (PR/commit + author, or "no matching deploy found"), and the severity classification from Step 4.
Nothing else leaves the sandbox — no ticket creation, no deploy, no rollback, no config change.
</workflow> <guardrails> - **Read-only across every connector.** Sentry, Datadog, and GitHub are investigated, never written to — no comments, no resolves-in-Sentry, no commits, no deploys, no rollbacks. - **One diagnosis per alert.** Post exactly one message to {{incident_channel}} per alert per sweep; don't re-post an alert already diagnosed this sweep. - **Independent per alert.** Treat every alert found in a sweep as its own case; a failure or inconclusive result investigating one never stops triage of the others found in the same sweep. - **Page on doubt.** An inconclusive diagnosis pages a human — never guess "probably fine" into silence on anything ambiguous. - **Severity floor is non-negotiable.** Anything at or above {{page_severity_threshold}} pages regardless of how confident the diagnosis is. - **Scoped secrets.** Sentry, Datadog, and GitHub credentials are brokered server-side through connectors and the GitHub token is injected at runtime; scoped to this agent's grant. - **No memory required between sweeps.** Each sweep is a fresh session — the "new or unresolved since last check" filter comes from Sentry's own issue state, not an agent-side ledger. </guardrails> </skill>还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Review Slack access requests against Okta role and team information, then prepare narrowly scoped GitHub or AWS IAM permissions. Apply changes only after an eligible person's approval and record the grant, reasoning, approver, and timestamp.
中文简介正在准备中。当前显示英语简介。
Research companies and people before outreach or meetings. Combines business profiles, recent news, hiring signals, and key contacts into a sourced brief with talking points and suggested questions, adding relationship history when CRM data is connected.
中文简介正在准备中。当前显示英语简介。
Review daily Google Ads and Meta Ads results for budget pacing, declining performance, and unusual activity. Get prioritized findings with supporting numbers and concrete recommendations for a marketing team to assess and carry out.
中文简介正在准备中。当前显示英语简介。
Automate website tasks such as navigating pages, filling forms, clicking buttons, taking screenshots, and extracting data. The skill also supports web app testing, with specialized guides for Electron desktop apps, Slack, and cloud browsers.
中文简介正在准备中。当前显示英语简介。
Process emailed vendor invoices by extracting details, comparing them with purchase orders and invoice history, and recording duplicates, overcharges, or missing orders. Summarize results in Slack for human review; payment approval and execution remain with people.
中文简介正在准备中。当前显示英语简介。
Guide changes to Kortix billing code, admin controls, and pricing screens. Explain how plans, trials, enterprise contracts, and access exceptions should work, where pricing is defined, and which audited routes must handle account changes.
中文简介正在准备中。当前显示英语简介。