Support Storm

Support Inbox Simulation

Use this skill to simulate the messy human exhaust of a launch: vague bug reports, annoyed reviews, refund requests, and exhausted follow-up threads.

This skill is for answering:

• What will users actually say when this breaks?
• Which failures become expensive to diagnose?
• Which support issues compress into the public story of the product?

When to Use

Use this skill when reviewing:

• launch readiness
• onboarding and activation
• support tooling and diagnostics
• pricing or packaging changes
• status and failure messaging
• any feature likely to produce “not working” tickets

Core Principle

A support burden is not just the number of issues. It is:

• how vague the first report is
• how many rounds it takes to diagnose
• how emotionally charged the issue feels
• whether the same confusion repeats across users

Step 1: Gather the likely support context

Read enough context to understand:

• target user sophistication
• launch channel
• product promise
• likely failure points
• what diagnostics/support summary currently exist
• what support actions are currently easy vs annoying

Then list:

• the 5-10 most likely reasons someone would contact support
• the 3-5 most likely reasons they would not contact support and instead churn, refund, or complain publicly

Step 2: Simulate the inbox

Generate a realistic mix of artifacts:

• 4-8 support emails or chat messages
• 3-5 App Store / public reviews
• 2-4 refund requests or cancellation notes
• 2-3 “this is probably user error but still your problem” complaints

Make them feel real:

• incomplete facts
• emotional language
• wrong assumptions
• screenshots described badly
• contradictory details
• users blaming the product, themselves, or the platform

Step 3: Triage each artifact

For each simulated item, add:

• What really happened
• Why the user described it this way
• What facts are missing for diagnosis
• How many back-and-forths it would probably take
• How fixable the support burden is — product fix / copy fix / diagnostics fix / docs fix / unavoidable

Step 4: Find the support sinkholes

Identify the issues that are worst because they are:

• frequent but vague
• rare but emotionally explosive
• difficult to distinguish from user error
• impossible to resolve without diagnostics the product does not collect
• repetitive enough to become maintenance drag

Step 5: Present the simulation

Use this format:

# Support Inbox Simulation: [Product / Feature]

## Executive Read
- Most likely support subject line:
- Most expensive recurring ticket:
- Most likely refund reason:
- Public review story most likely to spread:

## Simulated Inbox

### Support Emails
#### 1. Subject: ...
[message]
**What really happened:**
**Missing facts:**
**Estimated support rounds:**
**Best fix type:**

### Public Reviews
#### 1. ★★☆☆☆ “...”
[review]
**Underlying issue:**
**What story this reinforces:**

### Refund / Cancellation Notes
...

## Support Sinkholes
- [Issue] — why it will eat time
- [Issue] — why diagnostics fail

## Highest-Leverage Support Fixes
1. [ ]
2. [ ]
3. [ ]

## Support Summary / Diagnostics Missing Today
- [missing field]
- [missing field]
- [missing field]

Success Criteria

The simulation is successful when it makes support feel painfully concrete and identifies:

• what users will actually say
• what facts support will be missing
• which issues become maintenance drag
• which single diagnostics or UX fix would cut the burden most

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: carlkibler
• Source: carlkibler/agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.