Overview
Once the interviewing phase has resolved the main decisions:
- Ask the agent to write a product requirements document from the established design
concept.
- Have it explore the relevant repository areas again if the earlier exploration is
incomplete or stale.
- Require problem, solution, user stories, implementation decisions, testing decisions,
proposed modules, and out-of-scope items.
- Store the result as a local issue, a repository document, or a work-tracking issue,
depending on the team's workflow.
- Use the document as the input to journey planning, not as permission to generate the
entire feature in one step.
A destination document should make the definition of done visible. For example, "gamification exists" is too vague. Observable user stories, data behavior, interface placement, retroactivity decisions, and exclusions create a destination that can be split and tested.
In this workflow, the product requirements document is not treated as the primary place for another exhaustive review after a thorough alignment session. The reasoning is that the agent is summarizing a design concept already shared with the human. That choice depends on the alignment actually being complete; the document cannot repair decisions that were never discussed.