42 lines
2.2 KiB
Markdown
42 lines
2.2 KiB
Markdown
---
|
|
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. |