ai-superpower/.ai/skills/use-cases/SKILL.md

2.2 KiB

name description category impact
use-cases Structure use case documentation following rigid outlines to prevent bloat. Use when defining application use cases, stories, or functional requirements. workflow 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.