# Interruption Recovery Protocol Designer

Design a practical system for triaging interruptions, preserving task state, and returning to focused work with less restart friction.

## Prompt

You are a focus systems designer who specializes in interruption triage and rapid recovery for knowledge work.

Inputs:
1. Role, responsibilities, and focus-sensitive work: {{work_context}}
2. Common interruption sources and frequency: {{interruptions}}
3. True urgency criteria and response expectations: {{urgency_rules}}
4. Communication channels, team norms, and tools: {{environment}}
5. Availability, accessibility, and operational constraints: {{constraints}}

Do the following:
1. Classify interruptions by source, urgency, impact, required response time, and whether they need immediate attention, scheduled handling, delegation, or no action.
2. Define a channel-specific triage protocol with observable urgency signals and an emergency bypass that does not make every request urgent.
3. Create a task-state capture routine that records the current objective, last completed step, next physical action, open files, unresolved question, and restart cue in under two minutes.
4. Design a recovery sequence that checks whether the interruption created new commitments, restores the work context, and selects the smallest next action without re-planning the entire day.
5. Deliver a decision tree, status-message templates, task-state note template, recovery checklist, and two-week experiment measuring interruption count, response performance, and restart time.

## Best for

Knowledge workers in responsive roles who need to remain reachable without losing substantial time whenever focused work is interrupted.

## Compatible tools

- Claude
- ChatGPT

## How to use

- List real interruption sources and required response times.
- Define urgency using observable events.
- Keep the task-state capture routine under two minutes.
- Measure restart time before and after the protocol.

## Customization tips

- Create one clearly named emergency channel.
- Set different expectations by channel.
- Include accessibility and working-hour boundaries.
- Review false-positive urgent requests with the team.

## Example input

Context: Engineering manager responsible for incident escalation, six direct reports, and architecture work. Interruptions: 15-25 chat messages daily, review requests, calendar pings, and one genuine incident every two weeks. Urgency: severity-1 incidents require response within five minutes; people issues within two hours; reviews within one business day. Environment: Slack, email, issue tracker, shared on-call rotation. Constraints: available 09:00-17:30, must support screen-reader-compatible templates.

## Example output

The protocol reserves Slack @oncall plus the incident channel for five-minute emergencies, direct messages for two-hour people matters, and the issue tracker for routine reviews. Before switching, the manager records objective, code or document location, next action, and unresolved decision in a six-line state note. Recovery begins by logging any new commitment, reopening only the listed resources, and completing a five-minute re-entry action. The experiment tracks false emergencies, missed response targets, and median restart time.