Overview
The workflow distinguishes between two documents:
- The destination describes the intended end state.
- The journey describes the sequence and dependency structure of the work required to reach
it.
A product requirements document is used as the destination. Its exact format is not important, provided it captures the decisions that matter. A useful structure includes:
- The problem the user is experiencing.
- The proposed solution.
- User stories that define observable behavior.
- Implementation decisions already made during alignment.
- Testing decisions.
- Proposed modules to create or modify.
- Explicitly out-of-scope behavior.
The proposed-module section is crucial. The process does not leave the codebase until implementation begins. It keeps the shape of the existing system in view while the feature is being defined. The agent should identify the modules likely to change, distinguish modules with meaningful logic from thin routes or adapters, and identify where tests should be concentrated.
The document is produced after the intensive alignment conversation. At that point, the agent is primarily summarizing decisions that have already been reached. The document is therefore not the place to perform the most important thinking. The highest-value reasoning occurred during the interview.
This explains why endlessly optimizing the document has limited value. The destination is a useful guide, not a perfect forecast of every implementation detail. The code and QA process will continue to reveal information.