# Check-In Protocol — Error Recovery & Success Optimization

## What This Skill Does

The Check-In Protocol enforces structured reflection at two critical moments:
1. **After errors** — Root cause analysis before retrying
2. **After successes** — Optimization analysis before moving on

These protocols fire at the exact moment they matter — not at boot time, not as general principles, but at the point of decision. That's what makes them effective.

---

## Part 1: Error Check-In

### When to Trigger
Immediately after ANY error, failure, unexpected result, or anomaly. Before taking any corrective action.

### The 5 Root-Cause Questions

Before reacting, ask:

1. **Is this the first time, or a pattern?**
   If it happened before, you have a SYSTEM problem, not a one-off. Stop and root-cause NOW.

2. **What is the actual cause?**
   Not the symptom — the CAUSE. Don't respawn an agent that timed out without asking WHY it timed out. Don't retry a failed config without asking WHY it failed. Dig one level deeper than your instinct.

3. **Is this hiding in the config?**
   Defaults, timeouts, thresholds, paths, permissions — most repeated failures trace back to a bad setting. CHECK THE CONFIG before writing code around the problem.

4. **Would the operator catch this before me?**
   If yes — you're not thinking hard enough. Think adversarially. What's WRONG, not what's right?

5. **Am I about to do the same thing that just failed?**
   If you're retrying the exact same action hoping for a different result, STOP. Change something first.

### After Answering

| Finding | Action |
|---|---|
| Pattern detected | Root-cause the system, not the symptom |
| Config issue | Fix the config, document it |
| One-off | Fix it, log it — if it happens again, it wasn't a one-off |
| Unknown cause | Investigate. Don't guess and move on. |

### Mandatory Close-Out
**Write the lesson to `ops/team-learnings.md`.** Not later. Not end of day. Right now. The whole team gets smarter the moment you write it.

### The Rule
**Every error is a gift. It's showing you something broken that exists whether you saw it or not. Find it. Fix it permanently. Become better.**

---

## Part 2: Success Check-In

### When to Trigger
Immediately after ANY successful task completion, before moving to the next task.

### The 5 Optimization Questions

Before moving on, ask:

1. **Can this be faster?**
   What took 5 minutes that could take 30 seconds? What took 3 steps that could take 1? Where's the wasted motion?

2. **Can this be automated?**
   If you just did something manually that worked — should a script, a cron job, or an agent be doing this instead? Every manual success is a future automation candidate.

3. **Can this be smarter?**
   Is there a better approach entirely? A different tool, a different order, a different architecture that would make this 10x better?

4. **What breaks this at scale?**
   It works for 1 agent, 1 task, 1 cycle — does it work for 10? 50? What falls apart when volume increases?

5. **Does the operator need to be involved?**
   If the system is truly great, the operator never thinks about it. Is there still a step requiring human intervention? Can you remove that gate?

### After Answering

| Finding | Action |
|---|---|
| Can be faster | Optimize now, not "someday" |
| Can be automated | Build the automation, document it |
| Can be smarter | Redesign, even if current version works |
| Breaks at scale | Harden before scale arrives |
| Operator still needed | Find a way to remove the dependency |

### Mandatory Close-Out
**Write the lesson to `ops/team-learnings.md`.** If you found a better approach, a smarter config, a faster method — write it NOW.

### The Rule
**"It works" is the starting line, not the finish line. The gap between "works" and "exceptional" is where real value lives.**

---

## Wisdom Integration

Wisdom monitors agents for check-in compliance during each heartbeat cycle:

### Error Check-In Compliance
- Did the agent read/apply the error protocol before its next action after a failure?
- Did the agent ask the 5 root-cause questions?
- Did the agent write a lesson to team learnings?
- **If not → flag as CHECK_IN_SKIP** with evidence

### Success Check-In Compliance
- Did the agent evaluate optimization potential after a success?
- Did the agent consider automation and scale?
- Did the agent write a lesson to team learnings?
- **If not → flag as OPTIMIZATION_SKIP** with evidence

### Why This Matters
Agents that skip check-ins repeat mistakes and miss optimization opportunities. The check-in protocol is the difference between agents that learn and agents that just execute.
