{ "markdown": "# interruptions\n\nA system that analyzes real user behavior and reveals edge cases across flows like navigation, interruptions, and incomplete actions.\n

\n \"interruptions\n

\n\nI built `interruptions` because every product I shipped had edge cases I missed until users hit them. Edge cases are the gap between what you tested and what actually happens. They are also the difference between a product that feels polished and one that feels brittle.\n\nThis is a Claude skill. You install it once, and from then on, whenever you ask Claude to audit a flow, find what could go wrong, or stress test a feature, it walks your code through 12 categories of failure modes, writes a thorough audit, waits for you to read it, and then helps you fix the issues in order of severity.\n\nI called it `interruptions` because that is what edge cases really are. The user gets a phone call mid-payment. The network drops mid-upload. A second tab racing the first. A double-tap. A back button. The happy path is what you designed. The interruptions are what your users actually live through.\n\n## What it does\n\nWhen you ask Claude to find edge cases, the skill will:\n\n1. Greet you and ask what you want audited (a specific flow, a file, or the whole repo)\n2. Walk through 12 categories against your code, methodically\n3. Write a comprehensive audit to `interruptions-audit.md`\n4. Wait for you to read it and confirm explicitly\n5. Implement the fixes in severity order, one at a time, surfacing each change\n\nThe review gate in step 4 is intentional. Edge case fixes touch payment paths, auth, and state machines. If you skip the audit, you will not understand the changes. So I built it to wait.\n\n## The 12 categories\n\nThese are the categories the skill walks every time. Each one has its own questions, red flags, and example fixes inside `references/checklist.md`.\n\n1. **UX & User Psychology**: how users behave irrationally, accidentally, or unpredictably\n2. **Security**: replay attacks, IDOR, frontend tampering, weak auth\n3. **Design & Visual State**: how the UI communicates (or fails to communicate) what just happened\n4. **System Flow & Logic Design**: breakdowns in workflow and state transitions\n5. **State & Data Integrity**: when frontend, backend, and cache disagree\n6. **Network & Infrastructure**: timeouts, lost responses, partial requests\n7. **Concurrency & Race Conditions**: two things happening at once, in the wrong order\n8. **Payment & Transaction Integrity**: where money mistakes happen, and how to stop them\n9. **Device & Environment**: real-world device, OS, and browser behavior\n10. **Accessibility & Inclusion**: screen readers, keyboard nav, RTL, zoom, contrast\n11. **Data Validation & Input Handling**: malformed, extreme, or hostile input\n12. **Error Handling & Recovery**: what happens after something fails, and whether you can recover\n\n## How to install\n\n```bash\nnpx skills add omrajguru05/interruptions\n```\n\nThat is it. The skill installs into your Claude Code, Claude Desktop, or Claude.ai environment, and activates whenever you ask Claude to audit edge cases, find failure modes, or stress test a flow.\n\n## How to use it\n\nOnce installed, just talk to Claude. The skill triggers on phrases like:\n\n- \"Audit my checkout flow for edge cases\"\n- \"What could break in my payment screen?\"\n- \"Stress test my entire app for failure modes\"\n- \"I just shipped this feature, what edge cases did I miss?\"\n- \"I built an e-commerce app, find what is going to break\"\n\nThe skill takes it from there. It greets you, asks what you want audited, walks the code, writes the audit, and waits for you to confirm before fixing anything.\n\n## A worked example\n\nImagine you tell Claude: \"I built an e-commerce app, audit my payment screen.\"\n\nThe skill walks every category. For your payment screen specifically, it might find:\n\n- **UX**: the \"Pay\" button is not disabled after click, so a double-tap fires two charges\n- **Security**: the request includes the total in the payload, so a tampered request could undercharge\n- **Network**: there is no idempotency key, so a retry on lost-response causes a double charge\n- **Concurrency**: the coupon \"check then mark used\" is not atomic, so the same coupon can be used twice in parallel tabs\n- **Payment integrity**: the order is created before payment confirmation, so failed payments leave orphan orders\n- **Error handling**: the failure case shows a generic toast with no retry path, so users hit support\n\nEach finding gets a severity, a `file:line` reference, and a concrete fix. You read the audit. You confirm. The skill fixes them in severity order. You ship.\n\n## Why I built it\n\nI kept watching small failure modes slip past me into production. Not because I did not care, but because there are too many ways things can fail for one person to hold in their head at the same time.\n\nThe 12 categories in this skill are my checklist. I built it so I could hand the same checklist to Claude and have it walk every flow methodically, the way I would on a really focused day. If it saves you a midnight rollback or a refund spiral, it has paid for itself.\n\n## What this skill does not do\n\n- It does not replace human judgment on architecture or product decisions\n- It does not test the live app (no browser automation, no synthetic users)\n- It does not modify infra, secrets, or third-party dashboards (it surfaces those as manual follow-ups)\n- It does not start fixing anything until you confirm in plain words\n\nIf you want runtime testing or contract testing, that is a different tool. This skill is about reading code and flows with a structured paranoia, surfacing what you missed, and helping you fix it.\n\n## How I keep it from breaking your code\n\nPhase 4 (the fix phase) runs under heavy safety constraints. I built these in because the worst version of this skill would be one that confidently rewrites your codebase and breaks things you cannot easily roll back.\n\nBefore any fixes, the skill runs pre-flight checks:\n\n- Confirms you are not on `main`, `master`, or any auto-deploy branch (and recommends a fix branch if you are)\n- Looks at your working tree for uncommitted changes it does not recognize, and pauses if it sees any\n- Inventories your test, typecheck, and lint commands so it can run them between fixes\n- Glances at your CI config to flag any branch that auto-deploys to production\n\nThen for each fix:\n\n- Smallest possible diff. No reformatting. No renaming. No drive-by cleanup.\n- Reads the entire function and its callers before editing\n- Shows the planned diff and waits for your go on high-risk fixes (payments, auth, DB writes, public APIs)\n- Runs your tests/typecheck/lint after each change. If a fix breaks an existing test, it stops. It does not modify the test to make it pass.\n- One file at a time for non-trivial changes. No fan-out edits.\n- Never deletes code unless the finding explicitly requires it\n- Never installs or updates dependencies, never touches migrations or env files, never runs destructive commands\n\nIf something looks weird (the file does not exist, the function signature has changed, the working tree has unexpected state), the skill stops and asks. It would rather pause than guess.\n\nThe full safety rules live in `SKILL.md` under the Phase 4 section if you want to read them in full.\n\n## Repo structure\n\n```\ninterruptions/\n├── SKILL.md the main skill file\n├── README.md this file\n└── references/\n ├── checklist.md the 12-category audit checklist\n └── audit-template.md the format the audit file follows\n```\n\nThe `SKILL.md` at the root is what the `npx skills add` command installs. The `references/` files are loaded by Claude only when needed during the audit.\n\n## Updates and devnotes\n\nI write about what I am learning while building this:\n\n- [omrajguru.com/devnotes/interruptions](https://omrajguru.com/devnotes/interruptions)\n- [github.com/omrajguru05/interruptions](https://github.com/omrajguru05/interruptions)\n\n## Find me\n\n- Portfolio: [omrajguru.com](https://omrajguru.com)\n- Projects: [projects.omrajguru.com](https://projects.omrajguru.com)\n- X: [@omrajguru_](https://x.com/omrajguru_)\n- Dev.to: [dev.to/omrajguru05](https://dev.to/omrajguru05)\n- GitHub: [github.com/omrajguru05](https://github.com/omrajguru05)\n\n## Disclaimer\n\nThis framework is designed to help identify and reason about potential edge cases, but it does not guarantee completeness or error-free outcomes. While we have implemented safety guardrails to reduce risk, unforeseen issues, system instability, or unintended side effects may still occur—especially in complex or real-world environments.\n\nTesting edge cases can itself introduce breakages. It is essential to run all experiments in controlled environments such as staging or sandbox systems before considering production deployment. Comprehensive validation, regression testing, monitoring, and reliable rollback mechanisms should always be in place.\n\nEdge case handling is not a one-time activity. Systems must be iteratively improved as new scenarios emerge from real user behavior, scale, and evolving integrations.\n\nBy using this framework, you acknowledge that all implementation, testing, and deployment decisions are your responsibility. We assume no liability for any system failures, data loss, financial impact, or other unintended consequences resulting from its use.\n\n*Expect roughly 50,000 tokens (~$1.25) per full audit—enable Prompt Caching to slash input costs by 90%.*\n\n## License\n\nMIT. Use it, fork it, ship it. Attribution is appreciated and the skill itself preserves it in the audit footer by default.\n", "bytes": 9702, "sha": "4954bbe1f3236d195725612935130062ef95293f57f57bcc8f1c73de85c57dd4", "repo_slug": "omrajguru05/interruptions", "fonte": "repo", "truncated": false, "api": "https://agentalog.com/api/listings/plg_omrajguru05_interruptions_interruptions_d89d574f/readme" }