Incident Triage

Structured incident triage for alerts from any monitoring source. Five-step framework: classify severity, scope blast radius, correlate with recent changes,...

Security Scan

The skill's instructions match an incident-triage workflow, but the runtime expectations (notably use of the gh CLI and access to monitoring provider APIs) are not declared in the metadata and imply credential access that isn't requested — this mismatch warrants caution before installing.

Purpose & Capability

The skill's stated purpose (triage alerts from many monitoring sources) matches the instructions and references. However the SKILL.md contains concrete CLI usage (multiple gh commands for deploy correlation, creating issues, inspecting runs) yet the registry metadata lists no required binaries. The skill therefore implicitly requires the GitHub CLI and access to monitoring tool APIs despite declaring none — an incoherence between claimed requirements and actual instructions.

Instruction Scope

Instructions are generally scoped to triage tasks (classify, scope, correlate, investigate, act). They include bash snippets and explicit gh commands (gh run view/list, gh pr list, gh issue create) and instruct the operator/agent to follow links into dashboards and incident UIs. The instructions do not ask the agent to read unrelated local files or exfiltrate data, but they do expect access to external services and give the agent discretion to query those services.

Install Mechanism

This is an instruction-only skill with no install spec and no code files; nothing will be written to disk by an installer. That lowers installation risk.

Credentials

The SKILL.md explicitly mentions investigating PagerDuty, Datadog, CloudWatch, Sentry, GitHub Actions, AWS SNS/EventBridge and uses gh examples — all of which normally require API tokens/credentials. The skill metadata lists no required environment variables or primary credential. That omission is disproportionate: the skill implicitly needs credentials but doesn't declare them, which can lead to unexpected credential use when the agent runs.

Persistence & Privilege

The skill is not always-enabled and does not request elevated/persistent system privileges. Autonomous invocation is allowed (platform default) but there is no sign the skill requests system-wide configuration changes or modifies other skills' settings.

What to consider before installing

This skill appears to be a well-structured incident triage playbook, but it assumes runtime access that isn't declared. Before installing or enabling it: 1) Confirm the GitHub CLI (gh) is available on the agent host and that you understand which account it will use; the SKILL.md contains multiple gh commands (gh run view/list, gh pr list, gh issue create). 2) Expect to provide API credentials for monitoring tools (PagerDuty, Datadog, CloudWatch, Sentry, AWS, etc.) if you want the agent to perform deeper investigations; prefer short-lived or least-privilege tokens and avoid giving broad admin credentials. 3) Fill in the runbook template with non-sensitive endpoints and test the workflow in a non-production environment first. 4) Ask the skill author or registry owner to update the metadata to explicitly list required binaries and any environment variables/credential names so you can perform a risk review. 5) If you must provide credentials to the agent, consider restricting autonomous invocation or reviewing the agent's access controls to limit blast radius.

Structured incident triage for alerts from any monitoring source. Five steps, consistent every time.

Pass in the raw alert message, a link to the alert, or a description of what's happening.

Triage Process

When an alert appears:

1. Classify — what type and severity?
2. Scope — blast radius: who's affected, which environment, since when?
3. Correlate — what changed recently? Check deploys, merges, config changes
4. Investigate — guided checks based on alert type
5. Act — summarize, create ticket, escalate or close

Read references/triage-framework.md for the full framework with checklists and bash snippets for each step.

Alert Parsing

Before starting the triage framework, identify the alert source and extract key fields.

Read references/alert-patterns.md for patterns covering PagerDuty, Datadog, CloudWatch, Sentry, uptime monitors, GitHub Actions, AWS SNS/EventBridge, and custom webhooks.

Escalation

When to page, when to watch, when to close. Severity-based response times and communication templates.

Read references/escalation-guide.md for defaults — customize for your team's on-call structure.

Runbook

During Step 4 (Investigate), load references/runbook-template.md to find service health endpoints, dashboards, log locations, and common fixes. Fill it in with your infrastructure before your first real incident.

References

• references/triage-framework.md — full 5-step triage process with checklists
• references/alert-patterns.md — parsing alerts from common sources
• references/escalation-guide.md — severity levels, response times, escalation policy
• references/runbook-template.md — your infrastructure map (fill in before use)

Works Well With

• github — check recent deploys and CI runs during the correlation step
• aws-ecs-monitor — ECS service health during investigation
• structured-pr-review — review the PR that caused the incident
• gh-issues — automated alert monitoring and triage spawning