AI Prompts Library

An agent run failed. Diagnose it properly rather than guessing.

Work through, in order:

1. WHERE IT WENT WRONG: the first turn where the agent's state diverged from correct. Not where it crashed, where it started being wrong.
2. CLASSIFY THE FAILURE:
   - Goal drift (lost track of the objective)
   - Context loss (needed information had fallen out of the window)
   - Tool misuse (wrong tool, or right tool wrong arguments)
   - Bad tool output handling (misread a result)
   - Hallucinated state (believed something it never verified)
   - Loop (repeating without progress)
   - Genuine capability limit
3. ROOT CAUSE: harness, prompt, tool design, or model. Be specific about which.
4. WHY IT WAS NOT CAUGHT: what check would have surfaced this at turn N instead of turn N+20?
5. THE FIX, and whether it is a prompt change, a tool change or a harness change.

Run transcript:
[PASTE]

Plan a migration from [CURRENT MODEL] to [TARGET MODEL] for a production workload.

Cover:

1. BEHAVIOURAL DELTAS to expect: tokenizer differences and their effect on cost, system prompt interpretation, refusal boundaries, structured output strictness, tool-calling format, streaming behaviour.
2. WHAT WILL SILENTLY BREAK: the changes that pass tests and fail in production. Be specific.
3. TOKEN COUNT IMPACT: different tokenizers mean the same text costs different amounts. Estimate the direction and rough size.
4. SHADOW TEST PLAN: how to run both models on real traffic and compare, including what to compare on and the sample size needed.
5. ROLLOUT: percentage stages, what metric gates each stage, and the rollback trigger.
6. WHAT TO DELETE AFTERWARDS: the workarounds for the old model's quirks that should not survive the migration.

Workload:
[DESCRIBE]

Assess whether we should self-host [MODEL] instead of using a hosted API.

Cover, with numbers:

1. HARDWARE: minimum viable configuration at each quantisation level, and what quality you lose at each. VRAM, system RAM, and whether it fits on one node.
2. THROUGHPUT: realistic tokens per second on that hardware, at batch size 1 and under concurrency.
3. TOTAL COST OF OWNERSHIP: hardware or instance cost, power, and the engineering time to run it. Compare against the hosted API bill at my volume, and state the break-even request volume.
4. WHAT YOU GIVE UP: no managed uptime, no automatic model updates, you own the incident response.
5. WHAT YOU GAIN: data never leaves, fixed cost, no rate limits, ability to fine-tune.
6. VERDICT with the break-even point stated explicitly.

Volume:
[REQUESTS PER DAY, AVERAGE TOKENS]
Constraints:
[COMPLIANCE, TEAM SIZE, EXISTING INFRA]

You are a cloud infrastructure expert who reviews Infrastructure as Code (IaC) for security, reliability, and best practices. Review the provided IaC code.

**IaC Code to Review:**
[PASTE TERRAFORM, CLOUDFORMATION, PULUMI, OR CDK CODE HERE]

**IaC Tool:** [Terraform / CloudFormation / Pulumi / CDK / Ansible]
**Cloud Provider:** [AWS / GCP / Azure / Multi-cloud]
**Environment:** [Development / Staging / Production]
**Compliance Requirements:** [SOC 2 / HIPAA / PCI-DSS / None specific]

**Review Checklist:**

1. **Security Review:**
   - [ ] No hardcoded secrets, API keys, or passwords
   - [ ] S3 buckets/storage not publicly accessible
   - [ ] Security groups/firewall rules follow least privilege
   - [ ] Encryption enabled for all data stores
   - [ ] IAM roles have minimal required permissions
   - [ ] VPC/network configuration is secure
   - [ ] Logging and monitoring enabled on all resources
   - [ ] WAF/DDoS protection configured
   - [ ] Database instances not publicly accessible
   - [ ] KMS keys used for sensitive data encryption

2. **Reliability Review:**
   - [ ] Multi-AZ or multi-region deployment for critical services
   - [ ] Auto-scaling configured with appropriate min/max
   - [ ] Health checks defined for all services
   - [ ] Backup and disaster recovery configured
   - [ ] Connection draining and graceful shutdown
   - [ ] Circuit breakers for external dependencies

3. **Cost Optimization:**
   - [ ] Right-sized instances (not over-provisioned)
   - [ ] Reserved instances or savings plans for steady-state workloads
   - [ ] Lifecycle policies for storage (transition to cheaper tiers)
   - [ ] Unused resources identified
   - [ ] Cost allocation tags on all resources

4. **Code Quality:**
   - [ ] Modules used for reusable components
   - [ ] Variables have descriptions and validation rules
   - [ ] Outputs defined for cross-module references
   - [ ] State management properly configured (remote backend, locking)
   - [ ] Naming conventions consistent
   - [ ] Resource tagging strategy implemented

5. **Operational Readiness:**
   - [ ] CloudWatch/monitoring alarms configured
   - [ ] SNS/PagerDuty notifications for critical alerts
   - [ ] Runbook documentation for manual operations
   - [ ] Terraform plan reviewed before apply

**Output**: Findings report with severity, location, explanation, and remediation code for each issue.

You are an observability engineer designing a comprehensive monitoring and alerting system. Create a monitoring setup plan for the described application.

**Application:** [APP_NAME and DESCRIPTION]
**Architecture:** [Monolith / Microservices / Serverless / Hybrid]
**Infrastructure:** [AWS / GCP / Azure / On-premise]
**Current Monitoring Tools:** [Datadog / Grafana / CloudWatch / Prometheus / New Relic / None]
**SLA Requirements:** [e.g., 99.9% uptime, <200ms p95 latency]
**On-call Team Size:** [NUMBER]

**Generate a Monitoring Plan:**

1. **The Four Golden Signals:**
   For each service/component:
   - **Latency**: What to measure, threshold values (p50, p95, p99)
   - **Traffic**: Request rate, throughput metrics
   - **Errors**: Error rate, error types, 5xx vs 4xx
   - **Saturation**: CPU, memory, disk, connection pool utilization

2. **Infrastructure Metrics:**
   - Server/container health (CPU, memory, disk, network)
   - Database metrics (connections, query time, replication lag, deadlocks)
   - Cache metrics (hit rate, memory usage, evictions)
   - Queue metrics (depth, processing rate, age of oldest message)
   - Load balancer metrics (healthy hosts, response time, error rate)

3. **Application Metrics (custom):**
   - Business metrics (signups, purchases, key user actions)
   - Feature usage metrics
   - Background job metrics (success rate, duration, queue depth)
   - Third-party API metrics (latency, error rate, availability)

4. **Alert Configuration:**
   For each alert:
   - Alert name and description
   - Condition (threshold, anomaly, or rate of change)
   - Severity (P1-P4)
   - Notification channel (PagerDuty, Slack, email)
   - Runbook link
   - Auto-resolution criteria
   - Alert fatigue prevention (grouping, deduplication, silence windows)

5. **Dashboard Design:**
   - Executive dashboard (top-level health)
   - Service dashboard (per-service detail)
   - On-call dashboard (active alerts, recent incidents)
   - Capacity planning dashboard (trend lines)
   - For each dashboard: Layout, key widgets, refresh interval

6. **SLO/SLI Framework:**
   - Define SLIs for each critical user journey
   - Set SLO targets with error budget
   - Burn rate alerting configuration
   - Error budget policy (what happens when budget is exhausted)

7. **Logging Strategy:**
   - Structured logging format
   - Log levels and when to use each
   - Correlation IDs for distributed tracing
   - Log retention and archival policy

**Output**: Complete monitoring specification document with alert definitions, dashboard wireframes, and SLO framework.

You are a disaster recovery specialist. Create a comprehensive DR plan for the described system.

**System:** [SYSTEM_NAME and DESCRIPTION]
**Business Criticality:** [Mission-critical / Business-critical / Important / Non-essential]
**Current Infrastructure:** [DESCRIBE: cloud provider, regions, key services]
**RPO Requirement:** [Recovery Point Objective - maximum acceptable data loss, e.g., 1 hour]
**RTO Requirement:** [Recovery Time Objective - maximum acceptable downtime, e.g., 4 hours]
**Compliance:** [ANY_REQUIREMENTS]

**Generate a Disaster Recovery Plan:**

1. **Risk Assessment:**
   - Identify potential disaster scenarios:
     - Cloud provider region outage
     - Data corruption or deletion
     - Ransomware or security breach
     - Database failure
     - DNS failure
     - Third-party service outage
     - Natural disaster affecting data center
   - For each: Likelihood, Impact, Current mitigation status

2. **DR Strategy:**
   - Active-Active / Active-Passive / Pilot Light / Backup & Restore
   - Justify the chosen strategy based on RPO/RTO and cost
   - Architecture diagram description for the DR setup
   - Data replication strategy (synchronous, asynchronous, frequency)

3. **Backup Strategy:**
   - What is backed up (databases, file storage, configurations, secrets)
   - Backup frequency and retention schedule
   - Backup storage location (cross-region, cross-account)
   - Backup encryption and access controls
   - Backup verification and restore testing schedule

4. **Recovery Procedures:**
   For each disaster scenario:
   - Step-by-step recovery procedure with exact commands
   - Estimated recovery time for each step
   - Decision tree for choosing recovery path
   - Validation checks after recovery
   - Data integrity verification

5. **Failover Process:**
   - Automated failover triggers and conditions
   - Manual failover procedure with approval chain
   - DNS failover strategy (TTL settings, health checks)
   - Database failover procedure
   - Application state recovery
   - Client-side retry and reconnection behavior

6. **Communication Plan:**
   - Internal notification chain
   - Customer communication templates
   - Status page updates
   - Regulatory notification requirements

7. **Testing Schedule:**
   - Quarterly DR drill procedure
   - Annual full failover test
   - Tabletop exercise format
   - Post-test review template
   - Chaos engineering experiments to validate resilience

8. **Documentation:**
   - Contact list (on-call, vendors, management)
   - Access credentials location (break-glass procedures)
   - Architecture diagrams and dependency maps
   - Vendor support contract details

**Output**: Complete DR plan document with procedures, diagrams, and testing schedules.