kata-requirements-brief

To turn a product brief into testable acceptance criteria, the Skill extracts actors, entities, and behaviors from the brief's problem context to generate sequential Given/When/Then acceptance criteria suited for testing.

Documenting Definition of Done and out-of-scope items is achieved by processing the brief's Work Type and Additional Context, outputting a structured requirements markdown file that explicitly defines completion boundaries and excluded features.

During requirements elicitation, unresolved risks and unknowns are converted into objective user questions and marked as PENDING rather than inventing answers, ensuring unknowns are captured safely for future resolution.

To generate Given When Then statements for issue-driven workflows, the Skill reads the Phase 1 issue brief and converts the problem context, work type, and risks into observable behaviors formatted as measurable acceptance criteria.

This requirements elicitation process requires a Phase 1 issue brief located at .ahrena/issues/{n}/01-brief.md as the source of truth, meaning prior issue creation and brief documentation are necessary before execution.

A limitation of automating Definition of Done from a brief is that the process strictly avoids inventing answers for unresolved risks, meaning any incomplete brief context will result in PENDING questions rather than fully defined requirements.