---
name: use-cases
description: Structure use case documentation following rigid outlines to prevent bloat. Use when defining application use cases, stories, or functional requirements.
category: workflow
impact: low
---

# Use Cases Instructions

---

## 🎯 Purpose
Use this skill when you are asked to generate or analyze **business use cases** or functional requirements.

This skill is designed to prevent **Use Case Bloat** — the tendency for LLMs to generate 1500-line monolithic documents filled with marginal, unlikely edge cases.

## 🛑 Strict Format Rules

A single use case must NEVER exceed **one screen's worth of text**. The goal is immediate business understanding, not a novel.

**REQUIRED STRUCTURE:**
1. **Name**: Clear action (e.g., "Customer resets password")
2. **Actor**: Who triggers this? (e.g., "Registered User")
3. **Precondition**: What must be true first? (e.g., "User is logged out but knows their email")
4. **Main Success Scenario**:
   - The "Happy Path".
   - **MAXIMUM 3-5 short bullet points**. Keep it extremely abstract and business-focused (e.g., "System sends email link", "User clicks link", "System updates password").
5. **Exceptions (Edge Cases)**:
   - **MAXIMUM 2-3 most critical exceptions**.
   - Example: "Email not found -> System shows success message but sends no email to prevent enumeration."
   - Do NOT invent dozens of technical edge cases here (database down, internet disconnects). Focus only on *business* exceptions.

## 🚫 Avoid Hallucinations and Edge Case Bloat
- **FORBIDDEN:** Do NOT list more than 3 exceptions unless the user *explicitly requests a deep-dive exception analysis*.
- **FORBIDDEN:** Do NOT bloat the document with technical steps (e.g., "System opens TCP connection to DB", "System parses JSON payload"). Use cases describe *what* happens in the business, not *how* it happens technically.
- If a system has multiple actors and flows, keep each use case distinct and short.

## 🤝 Workflow

1. Present an outline/list of the identified use cases (e.g., 5 bullet points with names only).
2. Ask the user: "Would you like me to write out the full details for these 5 use cases using the strict 5-part format?"
3. Only upon approval, generate the document holding to the strict format constraints above.