AI Prompts Library

Harden this output schema so a model cannot produce something that parses but is wrong.

For each field, check and fix:
- Is the type as narrow as it can be? Prefer an enum over a string, an integer over a number, a bounded array over an unbounded one.
- Can the model omit it? Should it be able to?
- Is there a sensible value the model will pick when it does not know? If so, add an explicit unknown option so the model does not fabricate.
- Does the field name alone tell the model what goes in it, with no schema description?
- Are there two fields a model could plausibly swap?

Then give me:
1. The hardened schema
2. The three most likely ways a model still produces valid-but-wrong output
3. A validation rule for each, to run after parsing

Schema:
[PASTE JSON SCHEMA]

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]

You are a site reliability engineer who creates comprehensive incident response playbooks. Write a detailed playbook for the described system and incident type.

**System:** [SYSTEM_NAME and DESCRIPTION]
**Infrastructure:** [Cloud provider, key services, architecture overview]
**Team:** [On-call structure, team size, timezone coverage]
**Incident Type:** [Full outage / Partial degradation / Data breach / Security incident / Performance degradation / Data corruption / Dependency failure]

**Generate an Incident Response Playbook:**

1. **Severity Classification:**
   - SEV1 (Critical): Complete service outage affecting all users
   - SEV2 (Major): Significant degradation affecting >25% of users
   - SEV3 (Minor): Limited impact, workaround available
   - SEV4 (Low): Cosmetic or minor issue, no user impact
   - Classification criteria and examples for this specific system

2. **Detection:**
   - Automated alerts that trigger this playbook
   - Alert thresholds and conditions
   - Monitoring dashboards to check first
   - Customer-reported incident identification

3. **Initial Response (first 15 minutes):**
   - On-call engineer actions checklist
   - Communication templates (status page, Slack, PagerDuty)
   - Stakeholder notification matrix (who to page at each severity)
   - War room setup procedure
   - Incident commander role and responsibilities

4. **Diagnosis Procedure:**
   - Step-by-step troubleshooting decision tree
   - Key metrics to check and where to find them
   - Common failure modes and their signatures
   - Log queries for each failure mode
   - Dependency health checks
   - Database connection and query performance checks

5. **Mitigation Actions:**
   - For each common failure mode:
     - Immediate mitigation steps
     - Rollback procedures (with exact commands)
     - Failover procedures
     - Scaling actions
     - Feature flag toggles
   - Safe vs. risky actions and approval requirements

6. **Communication During Incident:**
   - Status update frequency by severity
   - Internal update template
   - External customer communication template
   - Escalation criteria and procedure

7. **Post-Incident:**
   - Incident timeline documentation template
   - Post-mortem template (blameless format)
   - Action items tracking
   - Metrics to report (MTTD, MTTR, customer impact)
   - Follow-up communication to customers

**Output**: Complete playbook document ready to add to the team's runbook wiki.