support-cases — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited support-cases (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Use this skill when investigating an incident and you need to review AWS Support cases — either the current case associated with the incident or historical cases that may contain relevant context, similar symptoms, or proven remediation steps.
Unified Operations plan (required for the AWS Support API).
support:DescribeCases andsupport:DescribeCommunications in the target account.
24 months cannot be retrieved via the API.
Before searching support cases, gather key details from the current incident:
Use these details as search criteria when filtering support cases.
Use the AWS Support API to retrieve cases that may be relevant.
aws support describe-cases \
--include-resolved-cases \
--include-communications \
--after-time "<ISO-8601-start>" \
--before-time "<ISO-8601-end>" \
--language "en"aws support describe-cases \
--case-id-list "case-123456789010-muen-2024" \
--include-communications| Strategy | How to Apply |
|---|---|
| By time window | Use --after-time and --before-time to scope cases to the relevant period (e.g., past 30 days, or around a previous incident date), because recent cases are more likely to reflect current infrastructure state. |
| By service | Review the serviceCode field in returned cases to match the affected service (e.g., amazon-elastic-compute-cloud, amazon-rds), because the same service often exhibits recurring failure patterns. |
| By severity | Check the severityCode field — focus on urgent and critical cases for major incidents, because higher-severity cases tend to have more detailed root cause analysis from AWS Support. |
| By status | Use --include-resolved-cases to include closed cases, because resolved cases contain the root cause and remediation steps that are most valuable for correlating with the current incident. |
| By subject keywords | Scan the subject field of returned cases for keywords matching the current incident symptoms, because similar symptoms often share underlying causes. |
The describe-cases response with includeCommunications: true returns the most recent communications for each case in the recentCommunications field (up to 5 messages). Since root cause analysis and resolution steps are typically in the final messages of a resolved case, this is usually sufficient.
If the recentCommunications field includes a nextToken, the case has additional older messages. Only paginate using describe-communications if the recent messages do not contain a clear root cause or resolution — for example, if the last messages are follow-up questions rather than a final answer.
aws support describe-communications \
--case-id "case-123456789010-muen-2024" \
--max-results 10 \
--next-token "<nextToken-from-recentCommunications>"When reviewing communications, look for:
cause in their final response.
"increased max_connections", "applied security group rule", "scaled up instance type").
provided by AWS.
analysis from specialized teams.
After reviewing relevant cases, correlate the findings:
Rate each historical case on relevance to the current incident:
| Score | Criteria |
|---|---|
| High | Same service, same error, same resource type, similar timeframe |
| Medium | Same service, different error but related symptoms |
| Low | Different service but similar architectural pattern or failure mode |
Provide a structured summary including:
criteria.
the top matches.
were permanent fixes or temporary workarounds.
paths or remediation steps for the current incident.
flag it as a recurring problem requiring a permanent fix or architectural change.
Is there a known case ID associated with the current incident?
├── YES → Retrieve that specific case and its communications (Step 2, filter by case ID)
└── NO → Continue below
Is the affected AWS service known?
├── YES → Search cases in the past 90 days for that service, then expand to 12 months if needed
└── NO → Search all cases in the past 30 days and filter by error keywords
Were relevant historical cases found?
├── YES → Review communications (Step 3), correlate findings (Step 4), summarize (Step 5)
└── NO → Broaden search criteria:
- Expand time window
- Search by related services (e.g., if ELB is affected, also check EC2 and Target Group cases)
- Search by error code or symptom keywords in case subjectswindow) and expand only if no relevant cases are found.
resolved cases where root cause and fix are documented.
at critical severity, the current incident may warrant similar urgency.
deployment, check if a similar deployment occurred before the current incident.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.