I Built a Claude Skill That Audits Your Code for Edge Cases Before They Reach Production

Every product I shipped had edge cases I missed. I found them the hard way: through user reports, midnight rollbacks, and refund spirals that should have been caught during review. The pattern repeated across projects: the happy path worked, but the real world found gaps I had overlooked. A phone call mid-payment. A network drop during an upload. Two tabs racing each other to submit the same form. These are the moments that define whether a product feels reliable or fragile. I kept thinking there had to be a structured way to find these failures before users did. That question became interruptions.

interruptions is a Claude skill. A Claude skill is a set of instructions and references you install into your Claude environment, and it activates when you ask Claude specific questions. Once installed, this skill triggers whenever you ask Claude to audit a flow, find what could go wrong, or stress test a feature. Claude then walks your code through 12 structured categories of failure modes, writes a comprehensive audit report to a Markdown file called interruptions-audit.md, and waits for you to read it and confirm before touching anything. After you confirm, Claude helps you fix each issue in order of severity. The installation takes one command: npx skills add omrajguru05/interruptions. From that point, the skill is available across Claude Code, Claude Desktop, and Claude.ai.

The 12 categories exist because failure modes cluster into recognizable patterns. I pulled these patterns from years of shipping and watching the same classes of bugs appear across different products and teams. UX and user psychology covers how users behave irrationally, accidentally, or in ways your design overlooked. Security covers replay attacks, insecure direct object references, frontend tampering, and weak authentication. An insecure direct object reference happens when a user can guess or modify a URL parameter to access data that belongs to another user. Design and visual state covers how the UI communicates, or fails to communicate, what happened after an action. System flow and logic design covers breakdowns in workflow sequencing and state transitions.

The remaining categories go deeper into the infrastructure and data layers. State and data integrity covers situations where the frontend, backend, and cache hold different versions of the same truth at the same time. Network and infrastructure covers timeouts, lost responses, and partial requests that leave the system in an ambiguous state. Concurrency and race conditions covers two operations happening simultaneously and producing a result that neither operation intended in isolation. Payment and transaction integrity covers the class of errors where money is involved and the cost of a mistake is real. Device and environment covers actual behavior differences across operating systems, browsers, and screen sizes that synthetic testing often overlooks. Synthetic testing means running automated scripts against your code in a controlled environment, which produces different results from a real user on a real device with a slow connection and five background tabs open.

The final three categories address the boundaries of your inputs and your error paths. Accessibility and inclusion covers screen reader compatibility, keyboard navigation, right-to-left language support, zoom behavior, and color contrast ratios. Data validation and input handling covers malformed, extreme, or intentionally hostile input that reaches your backend. Error handling and recovery covers what happens after a failure and whether a user has a path forward, or is left with a generic toast message and a phone call to support. Each category has its own set of questions, red flags, and example fixes stored inside a references file that Claude loads during the audit. These references come from real production failures observed across multiple product types and team sizes. The checklist in references/checklist.md is the canonical source the skill reads from during each audit run. It is also the file where community contributions make the biggest difference.

When you trigger the skill, the audit phase runs first. Claude greets you, asks which flow or file you want audited, and then walks the 12 categories against your code one by one. The output is a structured audit written to interruptions-audit.md, a Markdown file that lives in your project directory. Each finding in that file includes a severity rating, a file and line reference pointing to the exact location in your code, and a concrete fix with enough context to understand the change. Severity ratings follow a consistent scale so you can prioritize what to address first. The audit covers every category regardless of which flow you asked about, because failures in one area often trace back to a gap in another. After the audit is complete, the skill pauses and waits for you to read it.

This waiting behavior is intentional and the most important design decision in the entire skill. Edge case fixes touch payment paths, authentication logic, and state machines. A state machine is a structure that tracks every possible state your application can be in, and which transitions between those states are valid. If Claude starts implementing changes before you read the audit, you lose the understanding of why each change is being made. So the skill holds at step four and asks you to read the audit and confirm in plain words before a single fix is applied. This confirmation gate is the difference between a tool that helps you ship better code and one that rewrites your codebase in ways you have to reverse engineer afterward. You stay in control of what gets changed and when.

The fix phase runs under a strict set of safety rules I designed to prevent the skill from creating problems while solving them. Before any fix is applied, the skill checks that you are on a working branch, inventories your test, typecheck, and lint commands, and glances at your CI configuration to flag branches that auto-deploy to production. CI, which stands for continuous integration, is an automated system that runs your tests and checks whenever you push code. For each individual fix, the skill produces the smallest possible diff. A diff is a record of exactly which lines changed in a file and how they changed. The skill touches the function in question and its direct callers, shows you the planned change before applying it on high-risk paths, and runs your test suite after each edit. When a fix causes an existing test to fail, the skill stops entirely rather than rewriting the test to make the failure disappear.

The project accepts contributions, and the contribution bar is high by design. The edge case checklist is a production tool, and the quality of its output depends on the quality of what goes into it. You can add new edge case scenarios across any of the 12 categories, improve clarity on existing ones, or propose an entirely new category if you find a recurring failure pattern that the current structure misses. Every contribution needs three things: a concrete scenario describing the failure, an impact section describing what goes wrong for the user or the system, and a suggested safeguard describing how to prevent or handle the failure. Vague descriptions belong outside the checklist. Specific, reproducible failure paths belong inside it. The process is: fork the repository, create a branch, make your changes, and submit a pull request with a clear explanation of what you changed and why it improves the project.

I built interruptions because asking a developer to hold twelve distinct failure categories in their head during a focused review is an exercise in futility. A structured checklist handed to Claude and run against every flow is fundamentally more reliable than human memory and far more objective than a self-review written by the person who already "knows" the code works. This skill surfaces exactly what you missed, documents it clearly, and waits for your confirmation before helping you address each finding in order of priority. To ensure stability, the fix phase executes only one change at a time, followed by immediate test verification so you can see the impact of every individual tweak before moving to the next.

If you run this on a flow and it flags a bug you were seconds away from shipping to production, then it is doing exactly what I built it to do.