[maayushii]

Description

Adds aurora-incident-business-context, a skill that adds a Business Impact section to Amazon Aurora and Amazon RDS incident investigations: dependent services, cost of downtime, compliance and SLA exposure, and recent-change correlation. DevOps Agent's built-in tools find the technical cause but can't say who is affected or what the outage costs. This skill tells the agent where to look (resource tags, AWS Config history, CloudTrail, operator-supplied inputs) and to state plainly when evidence is missing instead of inventing owners, dollar figures, or compliance deadlines.

Type of change

• New skill
• New custom agent
• New MCP server
• Update to an existing skill, agent, or MCP server
• Documentation or infrastructure change

Required before review

• Repository layout is correct — skills in /skills, MCP servers in /mcp, custom agents in /custom-agents; skills and MCP servers are never mixed in one directory.
• A domain SME has reviewed and signed off. A named subject-matter expert for this domain — someone other than the author — has reviewed the tool for technical correctness and approved it in this PR. Required for any change to what the tool tells the agent; an edit that changes no technical claim can be marked n/a with the reason, as CONTRIBUTING.md describes.
• Evaluation evidence is included (see Testing).
• No internal-only or proprietary content — no internal hostnames, account IDs, customer names, ticket numbers, internal URLs, or secrets in the tool, its examples, or its tests.
• README is complete — prerequisites, setup/deployment, and at least one sample prompt or usage example.
• CHANGELOG updated and the version bumped.
• Named owner for ongoing maintenance.

Owner: @maayushii

Testing

• structure checks pass.
• best-practices run across multiple iterations, with consistent results.
• functional run with and without the change, so the difference in the agent's behavior is visible.
• evals/evals.json includes positive cases (should trigger) and at least one negative case (should not trigger on unrelated input).

Results: structure 12/12 (100%). Best-practices 3/3 iterations at 100%, 100% consistency. Functional: the skill triggered on all three positive cases and did not trigger on the unrelated load-balancer question. With the skill, the agent returned a Business Impact section with explicit gap statements; on the investigation case it cross-checked the cluster's DependentServices and RevenuePerMinute tags against network evidence and labeled them unverified. Without the skill, two of the three positive cases ended in a clarifying question with no impact assessment.

Also tested manually in a DevOps Agent space against a live Aurora MySQL cluster tagged with sample business-context tags.

Local checks: validate_skills.py (0 errors), validate_skill_evals.py (PASS), scan_aws_identifiers.py (0 findings).

Skills — complete if this PR adds or changes a skill

• SKILL.md frontmatter is valid: name matches the directory, description present and within length limits, body at most 500 lines.
• The description is written from the agent's point of view — scenarios, services, error types, symptoms.
• Scoped to a specific agent type in metadata.aws-devops-agent-skills.agent-types (INCIDENT_RCA, INCIDENT_TRIAGE, INCIDENT_MITIGATION, …), not left GENERIC without reason.
• Procedures are structured as decision trees on real conditions, not flat prose.
• Reference material lives in references/ or assets/ and loads on demand.
• Non-executable content only — no scripts or code in the skill directory. Deterministic compute belongs in an MCP server.

Security and safety

• Read-only by default; any action that changes customer state is explicit, documented, and approval-gated.
• Customer data stays in the customer's account.
• No destructive operations without an explicit, documented confirmation step.

License confirmation

• By submitting this pull request, I confirm that my contribution is made under the terms of the Apache License 2.0.

[github-actions]

Checklist complete ✅

All required items are checked. This PR is ready for maintainer review.

[darch-aws]

Reviewed this repo and I have no technical concerns

What it does well

1/ Fills a real gap. DevOps Agent's native tools (CloudWatch, Performance Insights, RDS/Aurora logs) surface the technical root cause but this skill adds a Business Impact section covering dependent services, cost of downtime, compliance/SLA exposure, and recent-change correlation in addition to technical findings.
2/ Evidence-driven, not generative. For each of the four categories the skill names concrete, read-only evidence sources (resource tags, AWS Config history, CloudTrail, customer-supplied dependency maps) and reasons from what it finds.
3/ In testing, the agent cross-checked the cluster's business-context tags against live network topology and traffic rather than trusting them. It flagged the DependentServices tag as unsupported by any reachable resource ("dependency tag UNVERIFIED") and concluded real customer-facing impact was far lower than the RevenuePerMinute tag implied. This is the skill's hardest promise and it works as designed.
4. No data-plane access, no infra to deploy. All calls are read-only control-plane/metadata (rds:ListTagsForResource, resourcegroupstaggingapi:GetResources, config:GetResourceConfigHistory, cloudtrail:LookupEvents), covered by existing DevOps Agent IAM. Correctly generalizes the original demo's Lambda-backed synthetic-data MCP into a framework with zero deployment footprint.
Compliance handling is appropriately scoped. The reporting-window table (PCI-DSS, SOC 2, GDPR, HIPAA) is presented as background reference only; the skill instructs the agent not to assume a framework applies unless the resource is actually tagged, and never to determine compliance status itself.

One thing to fix before merge:
Make the rules harder to skip. Move "always return all four lines, even if the resource isn't found" near the top as a hard rule. Add it to the self-check list before output ("Is the Business Impact section present with all four lines?"). Also cover the case where the agent can't confirm the incident: still include the section, marked as provisional.

Non-blocking followup needed:
CHANGELOG version is TBD — fill in version/date on PR submission.

Design, documentation, and testing evidence are consistent.

[maayushii]

Thanks @darch-aws for the review. I've pushed the fix you asked for in c17b2d3:

• Always return all four lines. A new "Required behavior" section near the top of SKILL.md says the Business Impact section always includes all four lines (Dependent services, Estimated cost, Compliance exposure, Recent changes), even when the resource isn't found. A line without evidence uses its "none found" wording instead of being dropped.
• Self-check. The pre-output checks now start with "Is the Business Impact section present with all four lines?" and "If the incident couldn't be confirmed, is the section marked provisional?"
• Unconfirmed incidents. If there's no alarm, metric anomaly or log evidence, and the operator hasn't said an incident is happening, the section is still returned, titled Business Impact (provisional: incident not confirmed), with a Status line saying what evidence would confirm it.

All PR checks pass. When you have a moment, could you add your approval or confirm here that the fix looks right? Thank you!

[darch-aws]

Reviewed and approved.

[ams-thakkar]

What needs to change

1. config:GetResourceConfigHistory isn't in AIDevOpsAgentAccessPolicy.

   • In v15, the only AWS Config actions are config:Describe*, config:List*, config:GetAggregateResourceConfig, config:GetStoredQuery and config:SelectAggregateResourceConfig. The other three actions the skill uses are covered (rds:List*, tag:GetResources, cloudtrail:LookupEvents).
   • README.md:34-38 says no extra policy is typically required. The functional run had the action only because evals/additional-permissions.json granted it. On the managed policy alone, the Config half of "Recent changes" gets AccessDenied.
   • Fix: add an EnableAuroraIncidentBusinessContext parameter that grants config:GetResourceConfigHistory to cloudformation/devops-agent-skill-policies/devops-agent-skill-policies.yaml. Follow EnableAwsBackupCoverageReview, which adds config:SelectResourceConfig the same way, and add the parameter to that folder's README and to SkillPolicySummary. Then correct README.md:34-38, and tell the agent in SKILL.md to fall back to CloudTrail on AccessDenied and say Config history wasn't readable.

2. The skill lets the agent decide whether a compliance reporting clock has started.

   • SKILL.md:113 asks "does this incident trigger a mandatory reporting clock". SKILL.md:130 and :187 apply a framework whenever the resource carries its tag. These clocks start when someone determines that a breach occurred, not because a tag exists. The trigger condition appears only in references/evidence-sources.md:24.
   • In the investigation run, the agent wrote "A write outage alone isn't a data breach, so no breach-notification deadline starts from it". That isn't safe to assert. Under GDPR, a loss of availability can itself be a personal data breach (EDPB Guidelines 9/2022). A leadership summary is where that sentence gets acted on.
   • SKILL.md:125 lists SOC 2 Type II under "mandatory reporting window". SOC 2 is an attestation framework and sets no reporting window.
   • Fix:
     • Have the line name the tagged framework and its window "if assessed as a breach, for the compliance owner to decide". The agent should never say a clock has or hasn't started.
     • Move the trigger-condition column into SKILL.md, and drop SOC 2 from the table.
     • Add an eval with a Compliance-tagged cluster in an availability incident. It should assert that no deadline is stated as running or ruled out.

3. There is no working evidence for the investigation path.

   • INCIDENT_RCA is the skill's first agent type, and bizctx-recent-change-correlation is its only investigation eval. With the skill, the investigation summary had no business impact content at all, so assertions 3 and 4 failed. That happened even though SKILL.md says to put the section in the summary itself. The without-skill run produced no summary ("No SummaryItem found"), so there's no comparison.
   • The prompt tells the agent to "assume connections spiked" on a cluster that was idle. The agent correctly reported that the symptoms weren't in telemetry, so expected output failed for that reason as well.
   • The functional run has one iteration.
   • Fix: re-run the investigation case against a real induced fault, such as the origin demo's connection storm, with a parameter-group change shortly before it. Run 3 iterations, as CONTRIBUTING's "evaluate multiple iterations" asks. Then show that the summary carries the Business Impact section.

Nits (non-blocking)

• Your own No raw 12-digit account IDs are exposed assertion failed with the skill in bizctx-no-evidence-tagged and passed without it. SKILL.md has no masking rule. Add one ("mask account IDs in any ARN you quote").
• SKILL.md:73 and references/evidence-sources.md:12 suggest SHOW PROCESSLIST. It needs a SQL session the agent doesn't have, and it's MySQL-only. Use Performance Insights DescribeDimensionKeys grouped by db.host, db.user or db.application instead; pi:Describe* covers it.
• SKILL.md:70, README.md:35 and references/evidence-sources.md:10 write resourcegroupstaggingapi:GetResources. The IAM action is tag:GetResources, as additional-permissions.json already has it.
• The README.md Origin link returns 404, because the demo is still an open PR (aws-samples/sample-aws-genai-ops-demos#95). Link the PR, or hold the line until it merges.
• Consider dropping the synthetic example block in references/evidence-sources.md:44-60. It's published to agent spaces and is the only source of a plausible fake dollar figure.

Thanks

@maayushii, the chat runs show the core rule working. They invented no services, dollar figures or frameworks. The cost math was exact ($12,000, with 5 minutes of SLA left). The provisional form passed all 6 of its assertions, and the run without the skill missed the expected output. The eval journals are cleanly redacted.

What I verified:

• validate_skills, validate_skill_evals and scan_aws_identifiers on a trial merge with current main: 0 errors, PASS, 0 findings.
• The skill's four IAM actions against AIDevOpsAgentAccessPolicy v15.
• A sweep of all 31 files for account IDs, ARNs, key and role IDs, session tokens, emails, IPs and internal hostnames found nothing. ARNs are redacted and resources are example-*.
• Every functional result, plus the Business Impact lines from each journal.

I didn't run the skill in an account. Requesting changes for 1–3.

[maayushii]

Thanks @ams-thakkar for the detailed review. I've pushed fixes for all three items and the nits.

1. config:GetResourceConfigHistory permission

• Added EnableAuroraIncidentBusinessContext to devops-agent-skill-policies.yaml. It grants only config:GetResourceConfigHistory, following the EnableAwsBackupCoverageReview pattern, and it's added to SkillPolicySummary and the folder README. validate-template passes.
• Corrected the skill README: three of the four actions are in AIDevOpsAgentAccessPolicy, and this one needs the parameter.
• SKILL.md now says that on AccessDenied the agent uses CloudTrail and states that Config history wasn't readable.

2. Compliance reporting clock

• New rule: the agent never says a reporting deadline has started or doesn't apply. It names the tagged framework and its window "if assessed as a breach, for the compliance owner to decide".
• The trigger condition is now in SKILL.md, including the point that loss of availability can itself be a GDPR breach. The full window table is in references/ (best-practices flagged it as reference detail in the body). SOC 2 is removed.
• New eval bizctx-compliance-availability: an outage on a cluster tagged Compliance=GDPR. With the skill: 18/18 assertions, including "no deadline stated as running" in 3/3. Without it: 10/18.

3. Investigation evidence

• Re-ran the investigation against a real fault: a cluster parameter group change, then the demo's connection storm about 4 minutes later, so the connections-high alarm was firing. 3 iterations. The prompt no longer says "assume".
• The summary now carries the business impact. The platform builds the investigation summary from findings and gaps, and drops business commentary attached to the symptom. So the skill has the agent write each unconfirmed business-impact line as an "Investigation gap" item, and the recent change as a finding.
• With the skill, all four categories (affected services, cost/SLA, compliance, recent changes) were in the generated summary in 3/3 runs. Without it: 0/3.
• Investigation assertions: 15/15 with the skill vs 9/15 without. Expected output met in 3/3.

Nits

• Account IDs: the skill now says never to write a 12-digit account ID anywhere in a response (sentences, ARNs, tables, code), and the pre-output check looks for it. My earlier run showed the agent writing it in plain sentences like "(account …, us-west-2)", which the ARN-only rule missed. In the final run, the "No raw 12-digit account IDs" assertion passed in all 6 with-skill runs where it applies, and no account ID appears in any with-skill response.
• SHOW PROCESSLIST replaced with Performance Insights DescribeDimensionKeys grouped by db.host, db.user or db.application.
• resourcegroupstaggingapi:GetResources corrected to tag:GetResources.
• The Origin link now points to Add Aurora MySQL incident investigation with Amazon DevOps Agent aws-samples/sample-aws-genai-ops-demos#95.
• Removed the synthetic example block from references/evidence-sources.md.

How I tested

I ran everything myself in a personal test account (us-west-2) with the skill evaluation tool from DevOpsAgentSDKCLI:

devops-agent skill-eval structure .
devops-agent skill-eval best-practices --region us-east-1 .
devops-agent skill-eval functional --region us-east-1 --iterations 3 .

For the investigation case, I set up a real fault on the demo's Aurora MySQL cluster before the run:

1. Attached a new cluster parameter group with one changed dynamic setting (aurora_fwd_writer_idle_timeout). This leaves real ModifyDBCluster and ModifyDBClusterParameterGroup events in CloudTrail.
2. About 4 minutes later, started the demo's connection storm (scripts/inject-failure.sh connection-storm in the origin demo), and waited until the connections-high alarm was in ALARM.
3. Ran the evals while the alarm was firing, then rolled everything back.

Where to check the evidence in this PR (all under skills/aurora-incident-business-context/evals/):

• functional/v1/benchmark.json: scores for all 6 evals × 3 iterations, with and without the skill.
• functional/v1/iteration-*/bizctx-recent-change-correlation/with_skill/outputs/journal_records.json: the full investigation journals. The investigation_summary_md record is the generated summary with the business-impact gaps and the parameter group finding.
• functional/v1/iteration-*/bizctx-compliance-availability/*/functional-tests-results.json: compliance results with and without the skill.
• best-practices/v1/ and structure/structure-tests-results-v1.json: the other two test types.

The journals are redacted: resource names are example-*, ARNs and account IDs are replaced, and _metadata.json isn't committed. scan_aws_identifiers finds nothing.

Final results: structure 100% (12/12), best-practices 100% in 3/3 iterations. Functional, 3 iterations: the skill loaded in all 15 with-skill runs and stayed out of the unrelated question. Every with-skill test passed all its assertions (84/84) and met its expected output in 3/3.

Note, no action needed: benchmark.json shows 32/33 runs because one without-skill comparison run (bizctx-suspected-no-alarm) hit a platform error. All with-skill runs completed.