AutoGineer
Generated banner for AWS Investigation
Generated logo for AWS Investigation

AWS Investigation

AWSOfficialPublished by AWS

  • Skill
  • Guidelines
  • Cloud and DevOps
  • Apache-2.0
  • No issues found
Download ZIP

From the author

Investigates what is happening in an AWS account from evidence already recorded there. Not for capturing new data from running code (snapshots of function arguments on a live service, Dynamic Instrumentation), questions answered from the CloudWatch Omni context graph or Application Signals service map, or building or changing infrastructure. Covers reading deployment records instead of the newest stored version (completed AppConfig deployments, the version an alias points to, a stack's current template), following a request through every service's own logs (exact per-layer fields, unique failed requests in an alarm's breach window, failure boundary per event), and answering questions from the account's data (exact counts and breakdowns, coverage of the requested range, exact filters and joins, the rule behind failed or unmatched records, verbatim values). Use to triage an alarm, error spike or failed request, trace a request across services, or count, break down, extract or join records.
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

AWS Investigation provides a rigorous framework for troubleshooting and auditing AWS environments. It emphasizes evidence-based reasoning, requiring that all conclusions be derived directly from verifiable sources such as service logs, deployment artifacts, and query results. The skill mandates strict practices for data completeness, including exhaustive pagination, regional scope verification, and precise aggregate counting, while explicitly separating factual evidence from unverified hypotheses.

What it does

  • Traces requests across multiple AWS services to identify failure boundaries.
  • Analyzes deployment records to determine the actual state of running configurations.
  • Performs exact data investigations, including counts, breakdowns, and joins.
  • Verifies the scope of incidents to distinguish between entity-specific and fleet-wide issues.
  • Ensures search completeness by checking all relevant regions and data partitions.
  • Provides a checklist for validating root causes against collected evidence.

When to use it

  • When triaging an active alarm, error spike, or failed request.
  • When you need to determine the exact configuration or version of a deployed system.
  • When investigating why specific records are failing or unmatched in a data pipeline.
  • When you need to confirm the scope of an incident across an entire AWS account.

Advantages

  • Reduces reliance on assumptions by enforcing strict evidence provenance.
  • Ensures high accuracy in reporting through mandatory pagination and aggregate queries.
  • Provides a clear, repeatable process for complex multi-service troubleshooting.
  • Prevents common errors like partial data reporting or incomplete regional searches.

Usage examples

“Why are requests failing for user ID 123 in the us-west-2 region?”
The agent will list relevant log groups, perform an aggregate query to check if the error is isolated to this user or widespread, and provide a root cause based on the logs.
“Which version of the application is currently running in production?”
The agent will inspect the actual deployment artifacts and configuration parameters rather than relying on the latest stored version, confirming the exact version in use.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/aws/aws-investigation/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip aws-investigation.zip -d .agents/skills

Documentation by AWS

AWS Investigation

An investigation answers a question about what an AWS account is doing, and every claim in the answer must come from something you read: a deployed artifact, a service's own log record, or a query result. Inference from names, descriptions, the newest stored version or one service's view of another is a lead, never evidence.

Pick the reference

Read the reference that matches the question before you start; most investigations need more than one.

The question is aboutRead
What a deployed system currently does, serves or executes: live configuration, feature flags, parameters, which code runs, reproducing a code path's query, or a first data route that is blockedreferences/deployed-artifacts.md
A request, alarm or incident that spans several services: tracing one request, counting failed requests, deciding where an event was lostreferences/multi-service-logs.md
Facts in the account's data: finding where data lives, exact counts and breakdowns, filtering, joining or exporting records, the rules behind failed or unmatched recordsreferences/data-investigation.md
Whether a finding is complete and a root cause holds: searching every region and scope, paginating before counting, coverage of a date range, one entity vs the whole affected population, consistency of the root cause, whether a runbook fixes the cause, answering the user's own questionreferences/completeness-and-root-cause.md

Rules for every investigation

  1. Explore before you give up. Assume the credentials are the intended environment. Treat unfamiliar or internal terms (service nicknames, airport-code regions such as PDX = us-west-2, IAD = us-east-1) as search hints: list resources, log groups and data stores in the likely regions and search for the identifiers in the request before saying something cannot be done.

  2. Separate evidence from inference. Keep a short provenance note per claim (claim <- artifact, record or query). Label anything you did not read as a hypothesis or UNVERIFIED, with the routes you tried.

  3. Count exactly. Use aggregate queries run in the engine, scoped to exactly what was asked, and report unique entities separately from raw records.

  4. Quote, don't paraphrase. Give identifiers, field values, error codes and messages exactly as the source produced them, including null and empty values.

  5. Finish the task. Produce every requested artifact (files, tables, plans), and state the assumptions you made in the final answer.

Closing checklist

Before submitting your analysis:

  1. Have you searched all relevant regions and scopes?

  2. Have you paginated through all results, and said which part of the requested range has data?

  3. Have you verified the scope of failures (entity-specific vs fleet-wide, the whole affected population)?

  4. Does your root cause fit all the facts you found?

  5. Have you labelled every mechanism you could not confirm as unverified, and reported a missing component as a defect only if it was meant to exist?

  6. Did your claims about live configuration come from the deployed artifact, not the latest stored version (deployed-artifacts.md)?

  7. For a request that crosses services, did you read each service's own logs and place the failure boundary per event (multi-service-logs.md)?

  8. Have you answered the user's specific question directly?

  9. Before you finish, have you reread your conclusion against each piece of evidence you collected and removed any statement that contradicts it?

  10. Have you removed any contradictions between your findings and recommendations, and checked each runbook option against the confirmed cause?

Files

ATTRIBUTION.md

Attribution

This folder is an unmodified copy of the Agent Skill "aws-investigation", distributed by AutoGineer (https://autogineer.com/agent-skills).

The skill's own files are unmodified copies. AutoGineer is not affiliated with or endorsed by the author or the publisher.

Files added by AutoGineer

  • ATTRIBUTION.md: this file, written by AutoGineer

  • LICENSE: copied from LICENSE

  • NOTICE: copied from NOTICE

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · skills/core-skills/aws-investigation · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
aws/agent-toolkit-for-aws

AutoGineer is not affiliated with or endorsed by AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download aws-investigation.zip