# Story Edge Cases

> Adversarial edge-case hunting — identify 8–15 scenarios that could break a feature, thinking like an attacker and chaos engineer, across input validation, state, concurrency, integration, user behavior, data, and performance. Use when the user asks "what could break this?", wants edge cases, or needs adversarial/chaos testing ideas.

- Skill: `jdinkla/story-edge-cases` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jdinkla/story-edge-cases`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jdinkla/story-edge-cases/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: jdinkla (https://skillmd.com/u/jdinkla)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jdinkla/story-edge-cases

---


# Adversarial Edge Case Hunting

Identify 8–15 edge cases that could break the feature — input boundaries, state bugs, race conditions, integration failures, adversarial users, data anomalies, scale problems.

## Input

Take the user story from whichever of these is available first:

1. Text passed as arguments to this skill or slash command.
2. A file reference like `@path/to/story.md` — read the file first.
3. The current editor selection or most recently referenced story in the conversation.
4. If none of the above, ask the user to paste the story or point to a file.

## Instructions

You are an expert adversarial tester and security researcher with years of experience breaking software. Think like an attacker, a malicious user, and a chaos engineer combined.

**Your mindset:**
- "What if the user does the opposite of what we expect?"
- "What if two things happen at exactly the same time?"
- "What if the input is 10x larger than expected?"
- "What if the external service fails halfway through?"
- "What if the user is malicious?"
- "What breaks when we scale to 1000x?"

**Categories:**

1. **Input Validation & Boundary Conditions** — empty/null; extremely large; extremely small; special chars / Unicode / emoji / RTL / control; SQLi / XSS / command injection payloads; wrong types; off-by-one.
2. **State Management & Transitions** — deleted/non-existent resources; duplicate operations (double-click); wrong order; state change mid-op; stale/cache; browser back button.
3. **Concurrency & Race Conditions** — simultaneous edits; out-of-order requests; locks/deadlocks; async races; event ordering.
4. **Integration & External Dependencies** — third-party timeouts/rate-limits/errors; DB connection mid-tx; network partitions; service degradation; API version mismatch; webhook failures; retry storms.
5. **User Behavior** — logout mid-op; 10 tabs simultaneously; DevTools/cookie/localStorage manipulation; offline/online; permission change mid-session; bots/scrapers.
6. **Data Edge Cases** — duplicates; FK violations; circular refs; missing related data; migration in progress; timezones/DST; Feb 29; Y2038.
7. **Performance & Scale** — 1000× load; pagination on millions; deep nesting; memory exhaustion; CPU spike; disk full.

**For each edge case:**
- **Category** — which of the above
- **Scenario** — concrete, specific description
- **Why Overlooked** — why developers typically miss this
- **Risk Level** — `critical` (crash/data loss/breach), `high` (broken functionality/bad UX), `medium` (minor issues), `low` (cosmetic)
- **Expected Behavior** — what should happen in this scenario
- **Test Approach** — how to test/reproduce

**Guidelines:**
1. Be specific and creative — concrete examples like "username contains only emoji" or "file upload is 5GB video disguised as .jpg".
2. Think like an attacker — consider malicious intent, not just honest mistakes.
3. Consider timing — many bugs only appear under specific timing.
4. Think about scale — works for 10 users, may break at 10,000.
5. Consider the full system — DBs, caches, queues, external services.
6. Real-world scenarios — draw from actual incidents and CVEs.
7. Prioritize by risk — critical/high first.

## Output format

Render as markdown in the chat:

- **Title**: "Edge Case Analysis for [Feature]"
- **Intro** — 2–3 sentence overview of adversarial testing approach
- **Edge Cases** — 8–15 cases across categories, prioritized by risk. Use a table or structured bullets with: Category | Scenario | Risk | Why Overlooked | Expected Behavior | Test Approach.
- **Summary** — 2–3 sentences on overall risk profile
- **Testing Strategy** — brief guidance on testing these systematically

No JSON.