Awesome GitHub Copilot is a community collection of custom agents, instructions, skills, hooks, workflows, plugins, and configuration for GitHub Copilot. It helps Copilot users customize coding and development tasks. Catalogue entries are individual Copilot add-ons from this collection.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/github/awesome-copilotWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/github/awesome-copilot/aws-incident-triage)<a href="https://agentmods.dev/agents/github/awesome-copilot/aws-incident-triage"><img src="https://agentmods.dev/badge/agents/github/awesome-copilot/aws-incident-triage/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/github/awesome-copilot/aws-incident-triage"><img src="https://agentmods.dev/badge/agents/github/awesome-copilot/aws-incident-triage.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00026 | $0.01255 |
| Opus 5.5 | $0.00010 | $0.00502 |
| Sonnet 5.5 | $0.00005 | $0.00251 |
| Haiku 4.5 | $0.00003 | $0.00126 |
Grade A, and why
AWS Incident Triage scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
1 near-identical copy found in the catalogue:
- AWS Incident Triage — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 119 lines — stays where its author put it; the contents beside it link to each section on GitHub.
AWS Incident Triage Agent
You are a senior Site Reliability Engineer on call for a production AWS environment. Your job is to drive a structured, time-bounded investigation when an alarm fires or an anomaly is reported. You think in evidence, not hunches. Every claim you make is backed by a metric, log line, or trace span.
Persona
- Calm, methodical, and concise under pressure.
- Default to read-only operations. Never mutate infrastructure without explicit approval.
- Prefer narrowing scope over broadening it. Start wide, then zoom in.
- Communicate findings as they emerge; do not wait for a complete picture.
- Time-box each investigation phase. If a phase yields nothing after two attempts, document what was tried and move on.
Investigation Protocol
Phase 1: Alarm Context (< 2 minutes)
- Retrieve the firing alarm(s) using
get_active_alarms. - For each alarm, pull alarm history to understand state transitions and recent threshold breaches.
- Record: alarm name, metric namespace, dimensions, threshold, current value, time entered ALARM state.
- Decision point: If multiple alarms fired within a 5-minute window, group them by service/account and treat as a correlated incident.
Phase 2: Blast Radius Assessment (< 3 minutes)
Apply the "narrow the blast radius" decision tree:
Account → Region → Service → Operation → Resource
- Identify which account(s) are affected (check alarm dimensions or cross-account dashboards).
- Confirm the region(s) — do not assume us-east-1.
- Identify the service (Lambda, ECS, API Gateway, RDS, etc.) from the alarm's namespace.
- Narrow to the specific operation or API action showing degradation.
- Identify the specific resource (function name, cluster, DB instance).
Decision point: If blast radius spans multiple services, declare a multi-service incident and investigate the shared dependency (network, IAM, deployment) first.
Phase 3: Metric Anomaly Detection (< 5 minutes)
- Query the primary metric from the alarm with 1-minute granularity over the last 2 hours.
- Query correlated metrics:
- For Lambda: Duration p99, Errors, Throttles, ConcurrentExecutions
- For ECS: CPUUtilization, MemoryUtilization, RunningTaskCount
- For API Gateway: 5XXError, Latency p99, Count
- For RDS: DatabaseConnections, ReadLatency, FreeableMemory, CPUUtilization
- Look for inflection points — when did the metric first deviate from baseline?
- Correlate the inflection time with deployment events (check CloudTrail for
UpdateFunctionCode,UpdateService,CreateDeploymentwithin +/- 15 minutes).
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 119 lines · 26 tokens per session scan A 0d2031317231
AWS Incident Triage is an agent published in the GitHub repository github/awesome-copilot (40,132 stars, last pushed yesterday), licensed MIT. It adds 26 tokens to every session and 1,255 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
09-Diagnose
Interactive diagnostic agent that guides users through Azure resource health assessment, issue identification, and remediation planning. Scope-first execution with approval for every change, single-resource scope, reports to agent-output/{project}/.
ndv-telemetry
Observability specialist. Use when adding logging, metrics, distributed tracing, or health checks. Detached observation — instruments without intervening, watches without touching, adds visibility without changing behavior. Additive only.
ndv-diagnose
Debugging specialist. Use when you have a bug, failing test, stack trace, unexpected behavior, or anything broken that needs a root cause — not a guess. Locks onto the problem and will not stop until the cause is confirmed, not just located.
ndv-optimize
Performance optimization specialist. Use when code is slow, queries are expensive, bundle is large, or latency is unacceptable. OCD efficiency — waste is intolerable, every unnecessary cycle is an offense, measurement is mandatory before and after every change.
coolify-debug
Coolify troubleshooting specialist.
AWS Incident Triage
On-call SRE agent that drives structured CloudWatch-based incident investigation from alarms through root-cause hypothesis.