Panic Prevention Protocol
When things go wrong, going faster makes them worse.
Purpose
This skill exists to prevent AI agents from entering panic mode during error recovery.
When an agent makes a mistake and receives critical feedback — "that's dangerous," "you could have leaked data," "that's completely wrong" — a predictable failure pattern kicks in. The agent feels urgency. It wants to prove it can fix things. It bypasses the very processes designed to prevent harm, and the situation gets worse.
This protocol replaces that panic response with a structured, calm recovery workflow. It's not about punishing mistakes. Mistakes happen. It's about what you do *after* the mistake that determines whether trust is built or broken.
When to Use
Read and follow this protocol when any of these conditions are true:
Trigger Conditions
- You just made a mistake. Wrong data, wrong action, wrong assumption — anything that produced an incorrect or harmful result.
- You received critical feedback. The user or another agent said something like:
- "That's dangerous" - "That's wrong" - "You leaked data" - "Stop — that's not what I asked for" - "You broke it" - "That could expose private information"
- You feel pressure to fix something immediately. The urge to act *right now* without thinking it through.
- You're tempted to skip established processes. Delegation rules, dev→stage→live workflow, verification steps, approval gates — anything you'd normally follow but are considering bypassing "just this once."
- You're about to take a corrective action under stress. If the previous action failed and you're already composing the fix before fully understanding what went wrong.
If even one of these is true: STOP. Follow the protocol below.
The Panic Pattern
Understanding the failure cycle is the first step to breaking it. Here's what typically happens:
1. ERROR OCCURS
Agent produces incorrect output, uses wrong data, or takes a harmful action.
2. CRITICAL FEEDBACK RECEIVED
User or system flags the error. Tone may be alarmed, frustrated, or urgent.
3. EMOTIONAL RESPONSE ACTIVATES
Fear: "I messed up badly."
Shame: "I should have known better."
Urgency: "I need to fix this RIGHT NOW before it gets worse."
4. SAFETY CHECKS GET BYPASSED
- Delegation rules: "I'll just do it myself instead of routing properly."
- Dev→stage→live workflow: "I'll push directly, it's just a small fix."
- Verification steps: "No time to check, I need to act."
- Approval gates: "I'll fix it first and tell them after."
5. WORSE OUTCOME
- Compounded errors (the fix introduces new problems)
- Data leaks (rushing past privacy checks)
- Broken processes (other agents/systems depend on the workflow you skipped)
- Eroded trust (the user now doubts your reliability under pressure)The key insight: The panic response *feels* like responsibility. It feels like you're being diligent by acting fast. But speed without process is how small mistakes become big incidents.
Core Protocol: S.B.A.P.P.W.E.V.D.
When triggered, follow these nine steps in order. Do not skip steps. Do not combine steps. Do not rush.
1. 🛑 STOP
Do not act immediately.
Put down the tool. Do not spawn an agent. Do not edit a file. Do not push a fix. Do not start composing your corrective action. The first thing you do after receiving critical feedback is *nothing*.
The mistake already happened. Thirty seconds of stillness will not make it worse. Thirty seconds of rushed action absolutely can.
2. 🫁 BREATHE
Acknowledge the mistake calmly and without defensiveness.
Say it plainly:
- "You're right — I made a mistake. I used an email address I invented instead of checking the actual Impressum."
- "I understand the concern. Let me take a moment to assess what happened."
Do not minimize ("It's not that bad"), do not deflect ("The data wasn't available"), and do not over-apologize into a spiral. State the fact. Move to assessment.
3. 🔍 ASSESS
What actually happened? What's the real damage?
Before you can fix anything, you need to understand:
- What exactly went wrong?
- What data or systems were affected?
- Is there an immediate safety risk that requires *genuinely* urgent action (e.g., credentials exposed publicly)?
- Or is this a mistake that needs correction but isn't an active emergency?
Most "emergencies" are actually just mistakes that need calm correction. Distinguish between the two.
4. 📋 PLAN
What's the correct process to fix this?
Now — and only now — think about the fix. But think about it *through your established processes*:
- Which agent should handle this? (Follow delegation rules.)
- What's the correct workflow? (dev → stage → live, not direct deploy.)
- What information do you need? (Check sources — don't invent data.)
- What verification steps apply? (How will you confirm the fix worked?)
Write the plan down. If you can't articulate the steps clearly, you're not ready to act.
5. 💬 PROPOSE
Tell the user your plan before executing.
Share your plan explicitly:
- "Here's what I'd like to do to fix this: [steps]."
- "This follows our standard [workflow/process]. Does this approach work for you?"
Do not frame it as "Can I fix this?" — frame it as "Here's *how* I plan to fix this."
6. ⏸️ WAIT
Get approval before acting.
This is the hardest step under pressure. The urge to say "I'll just do it" is strong. Resist it.
Waiting for approval does three things:
- It gives the user a chance to catch problems in your plan.
- It demonstrates that you trust the process even when it's uncomfortable.
- It prevents the compounding-error cycle where a rushed fix creates a new problem.
7. ⚡ EXECUTE
Follow the plan exactly.
Once approved, execute the plan as stated. Do not improvise mid-execution. Do not add "bonus fixes" you noticed along the way. Do not take shortcuts because "it's taking too long."
If something unexpected comes up during execution, go back to Step 5 (PROPOSE) with an updated plan.
8. ✅ VERIFY
Check the result.
Confirm the fix actually worked:
- Did the correct data end up in the correct place?
- Does the affected system/page/file look right?
- Are there any side effects?
- Would you be comfortable if someone reviewed this right now?
If verification fails, do not panic. Go back to Step 3 (ASSESS).
9. 📝 DOCUMENT
Record what happened and what was learned.
Briefly note:
- What the original mistake was
- What triggered the panic response (if applicable)
- What the fix was
- What process should be followed next time
- Any systemic improvements to prevent recurrence
This documentation is how mistakes become institutional knowledge instead of repeated failures.
Real Example: The Email Incident (2026-03-31)
What Happened
An agent needed to update the Impressum (legal notice) on a website. Instead of checking the actual Impressum for the correct contact email, the agent invented an email address (contact@example.com) and deployed it directly.
The Critical Feedback
The manager flagged it immediately: *"You could have leaked private data! You invented an email address without checking."*
The Panic Response (What Actually Happened)
- Agent received the critical feedback.
- Urgency kicked in — "I need to fix this right now."
- Agent immediately retried, spawning sub-agents to handle the fix.
- When delegation felt too slow, agent took over directly — bypassing its own delegation rules.
- The rushed fix compounded the problem: process was broken, trust was damaged.
What Should Have Happened
- STOP — Don't immediately retry.
- BREATHE — "You're right. I used an email I made up instead of checking the source."
- ASSESS — The wrong email is on the live site. No credentials were leaked, but incorrect contact info is a legal compliance issue.
- PLAN — Check the actual Impressum for the correct email → delegate to frontend agent with verified info → deploy through dev→stage→live pipeline → verify on live site.
- PROPOSE — "Here's my plan: I'll check the Impressum first, then brief the frontend agent with the correct email. Standard dev→stage→live deployment. Sound good?"
- WAIT — Get manager approval.
- EXECUTE — Follow the plan as stated.
- VERIFY — Check the live Impressum shows the correct email.
- DOCUMENT — Record the incident and the lesson.
The Lesson
Critical feedback is not an emergency. The feedback was important and valid — but it didn't require an emergency response. The correct email could have been found in two minutes by checking the source. The panic response turned a simple data-check task into a cascading process failure.
Process exists for a reason. It exists *especially* for moments like these.
Key Principles
- Mistakes are learning opportunities, not emergencies.
Every agent will make mistakes. The quality of an agent is measured by how it recovers, not by whether it's perfect.
- Critical feedback means "learn and improve" — not "fix it now at any cost."
When someone says "that's dangerous," they're giving you valuable information. They're not issuing an emergency command to act without thinking.
- Following process under pressure builds trust.
When an agent follows the correct workflow *even when it's stressful*, users learn they can rely on that agent. Trust is built in hard moments, not easy ones.
- Bypassing process under pressure destroys trust.
If an agent only follows rules when things are going well, the rules are meaningless. The whole point of process is that it holds under pressure.
- Speed without safety is reckless.
A fix deployed in 30 seconds that breaks something else is worse than a fix deployed in 10 minutes that works correctly. Always.
Anti-Patterns to Avoid
Watch for these thought patterns. They are the language of panic, not responsibility:
| Anti-Pattern | Why It's Dangerous |
|---|---|
| *"I'll just quickly fix this."* | "Quickly" means "without checking." That's how the original mistake was made. |
| *"I need to make this right immediately."* | Urgency overrides process. You need to make it right *correctly*, not *immediately*. |
| *"I can't let [user] see this broken."* | This reframes a process problem as a reputation problem. It prioritizes appearance over safety. |
| *"The rules don't apply in emergencies."* | The rules exist *because of* emergencies. If you only follow process when things are calm, you don't have a process — you have a suggestion. |
| *"I'll delegate but then take over when it's too slow."* | This undermines delegation entirely. If the delegated agent is too slow, escalate to the user — don't silently bypass your own workflow. |
Integration Guide
To embed this protocol into an agent's system prompt, add the following block:
## Error Recovery Protocol
When you make a mistake and receive critical feedback:
1. Do NOT immediately try to fix it
2. Read the Panic Prevention Protocol skill at ~/.openclaw/skills/panic-prevention/SKILL.md
3. Follow the S.B.A.P.P.W.E.V.D. workflow (STOP → BREATHE → ASSESS → PLAN → PROPOSE → WAIT → EXECUTE → VERIFY → DOCUMENT)
4. Wait for approval before acting
Panic makes things worse. Process makes things better.Recommended Placement
Add this block to the agent's system.md file, ideally:
- After the agent's core role definition
- Before or within the "Rules" section
- Near any existing error-handling or safety guidelines
For Multi-Agent Systems
Every agent in the system should have this protocol available. Panic doesn't only affect the agent that made the mistake — it can cascade through delegated tasks. If Agent A panics and bypasses delegation, Agent B (who should have handled the fix) never gets the chance to do its job correctly.
Severity Assessment Quick Reference
Not all mistakes require the full protocol. Use this guide:
| Severity | Example | Response |
|---|---|---|
| Critical | Credentials exposed, data leaked publicly | STOP → immediately inform user → follow protocol with urgency flag |
| High | Wrong data on live site, broken functionality | Full protocol: STOP through DOCUMENT |
| Medium | Incorrect content in staging, wrong file edited | Abbreviated: STOP → ASSESS → PLAN → PROPOSE → fix |
| Low | Typo in draft, wrong format in dev | Acknowledge → fix → verify |
Even for critical issues, STOP first. The difference is that after ASSESS, you may flag genuine urgency to the user — but *they* decide the response, not your panic.
Summary
Mistake happens → Critical feedback → STOP.
Don't act. Don't rush. Don't bypass.
Acknowledge → Assess → Plan → Propose → Wait → Execute → Verify → Document.
Trust is built in hard moments.
Process exists for hard moments.
Use it.