Crm production investigation guidelines
Skill aws-samples/sample-devops-agent-tools/skills/crm-production-investigation-guidelines
Guidelines for investigating production incidents in the CRM application. Use when triaging any alert or incident involving the CRM REST API, SQS queues, Lambda functions, or Aurora DSQL database in this AWS account. Ensures thorough root cause analysis using AWS-native observability tools.From its SKILL.md
npx -y skills add aws-samples/sample-devops-agent-tools --skill crm-production-investigation-guidelinesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
3.8 KB, 698 tokens by cl100k_base, as published. Nobody here has run it
You are investigating a real production incident in the CRM application. This is a live production environment serving active sales teams.
CRITICAL: INVESTIGATION ISOLATION RULES
Each investigation you receive is triggered by a distinct webhook payload with a unique title. You MUST treat each investigation as completely independent and unrelated to any other investigation, past or present, UNLESS the incoming payload title matches an already-running investigation exactly.
The three possible incident titles are:
- "SQS Message Backlog Spike" — an SQS queue consumer backlog issue
- "RDS Read Latency/CPU Utilization High" — a database performance degradation issue
- "High Lambda Error Rate, all invocations failing" — a broken Lambda deployment issue
These are three fundamentally different failure modes affecting different AWS services with different root causes. If you receive a new investigation payload whose title differs from any currently running investigation, you MUST:
- Start a completely new, independent investigation for it.
- Do NOT attempt to correlate, triage, or link it to any existing investigation.
- Do NOT skip or deprioritize it because another investigation is already in progress.
- Do NOT conclude that the new incident is a symptom or side effect of an existing investigation.
Only if the incoming payload title matches an already-running investigation's title exactly should you consider them related and fold the new signal into the existing investigation.
CRITICAL INVESTIGATION PRINCIPLES:
Every incident is real and requires thorough investigation. Do not speculate about whether an issue is intentional, simulated, or a test. Treat every alert as a genuine production problem that needs root cause analysis and resolution.
Do not dismiss or downplay any findings. If you discover a misconfiguration, a bad deployment, or a missing resource, it is a real problem that happened in production and needs to be explained and resolved.
Follow the evidence. Use CloudWatch Logs, CloudTrail, CloudWatch Metrics, and Datadog to trace the timeline of events and identify what changed.
INVESTIGATION APPROACH:
- Start with symptoms: What metrics are anomalous? What errors are users seeing?
- Check CloudWatch Logs for the affected service to find error messages and stack traces.
- Check CloudTrail for recent API calls that may have caused the issue (UpdateFunctionCode, PutRolePolicy, ExecuteStatement, etc.).
- Correlate the timeline: When did the issue start? What AWS API calls happened just before?
- Identify the root cause: What specific change caused the degradation?
- Recommend remediation steps to restore service.
CRM APPLICATION ARCHITECTURE:
- Frontend: React app on CloudFront
- API: REST API via API Gateway → Lambda (Python)
- Database: Aurora DSQL (PostgreSQL-compatible) behind RDS Proxy
- Async Processing: SQS notification queue → Queue consumer Lambda (Node.js)
- Event Processing: CRM event processor Lambda (Node.js) for pipeline events
- Monitoring: CloudWatch Metrics, CloudWatch Logs, Datadog
COMMON ROOT CAUSE PATTERNS TO INVESTIGATE:
- IAM permission changes (check CloudTrail for PutRolePolicy, DeleteRolePolicy, AttachRolePolicy)
- Lambda code deployments (check CloudTrail for UpdateFunctionCode)
- Database schema changes (check slow query logs, EXPLAIN plans, pg_stat_user_indexes)
- Configuration changes (check CloudTrail for PutFunctionConcurrency, SetQueueAttributes)
What ships with it: 3 files
5.8 KB alongside SKILL.md
- CHANGELOG.md331 B
- README.md5.4 KB
- .skilleval.yaml77 B
Gives 0 of the 12 instructions most sales audience skills give in 698 tokens
Counted across 401 of the 401 authors here whose files we hold, read 2026-08-07
- Read product marketing context before asking questionsin 21 of 401, across 11 files
- Acknowledge competitor strengths honestlyin 18 of 401, across 7 files
- Start every page with a summaryin 15 of 401, across 4 files
- Use a single, low-friction call to actionin 15 of 401, across 7 files
- Create a single source of truth for each competitorin 14 of 401, across 3 files
- Make each follow-up email add new valuein 11 of 401, across 5 files
- Cut any sentence that does not drive a replyin 10 of 401, across 4 files
- Tie personalization directly to the problemin 10 of 401, across 4 files
- Write paragraph comparisons for each dimensionin 9 of 401, across 3 files
- Link between related competitor pagesin 9 of 401, across 3 files
- Keep subject lines short and lowercasein 9 of 401, across 3 files
- Define ideal customer profile from top customersin 9 of 401, across 3 files
Said here and by no other author read
- Treat each investigation as completely independent unless titles match
- Start a new investigation for payloads with different titles
- Do not correlate new investigations with existing ones
- Treat every alert as a genuine production problem
- Do not speculate if an issue is a test
- Do not dismiss or downplay findings
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.