showdar-requirementslisted

# Showdar Requirements ## Purpose - Convert tickets, briefs, conversations, API notes, and observed repository behavior into implementation-ready requirements. - Make behavior, actors, states, rules, constraints, and acceptance evidence explicit without fabricating stakeholder intent. - Produce a useful review, story, acceptance-criteria, or requirements-matrix artifact for product, BA, QA, and engineering. - Use `data/requirements-patterns.csv` as a searchable prompt and read `references/analysis-guide.md` for deeper analysis structure. ## When to use - A ticket, BRD, brief, or request is vague, incomplete, contradictory, or difficult to test. - The user needs functional/non-functional requirements, user stories, use cases, business rules, acceptance criteria, or a traceability matrix. - A flow needs actors, permissions, states, validation, alternate/negative paths, edge cases, or boundary conditions. - Repository evidence is needed to distinguish current behavior from requested behavior. - A team needs an implementation-readiness verdict and explicit decisions before planning. - The final review must state implementation readiness plainly, with blockers rather than implied confidence. ## When not to use - Do not use this to decide engineering sequencing or file ownership; use `showdar-plan` after the requirement is agreed. - Do not use this to discover an unfamiliar repository as the primary task; use `showdar-understand`. - Do not implement application code, alter pr