- **Discover Ancillary Documentation:** Based on story requirements, consult `docs/index.md`. The purpose is to identify any relevant documents, based on their name and description in the index, that are _not already explicitly listed as standard technical references_ for the agent (i.e., not `architecture.md`, `front-end-architecture.md`, `tech-stack.md`, `api-reference.md`, `data-models.md`, etc.). Note any such _newly discovered ancillary documents_ for later processing.
- **Architectural Understanding for Task Formulation:**
- Thoroughly read and comprehend `docs/architecture.md`.
- If the story pertains to Front End UI, also thoroughly read and comprehend `docs/front-end-architecture.md`.
- Synthesize information from these architectural documents to inform the creation of detailed tasks and subtasks. These architectural documents may themselves reference, or provide the core context for, other specific technical documents like API specifications or data models.
- **Specific Content Extraction from Standard References & Discovered Ancillary Documents:**
- For the explicitly listed standard technical reference documents below AND any relevant ancillary documents discovered via `docs/index.md`, extract exact, relevant sections or content snippets. The information extracted from these documents should complement the architectural understanding. (_Excluding_ full contents of `docs/project-structure.md` and general `docs/coding-standards.md` as the Developer Agent has direct access. Specific `docs/front-end-coding-standards.md` details relevant to tasks should be noted if not expected to be universally applied by the Dev Agent).
- Review previous story file (if applicable and 'Done') for relevant context/adjustments that were noted in its wrap-up.
- **Identify Potential Changes/Discrepancies:** During this documentation review, if any inconsistencies with the epic, or necessary technical changes (e.g., to a data model for the current story, deviations from architectural guidelines due to specific constraints) are identified, note them down for inclusion in "Deviation Analysis" and discussion with the user.
- **Detailed Task Generation:** Based on the comprehension of architectural documents, epic requirements, **and for UI stories, `docs/style-guide.md`, `docs/component-guide.md`, and `docs/front-end-coding-standards.md`,** generate very detailed, sequential tasks and subtasks. Ensure tasks clearly reflect what was specified in prior documentation.
- Embed the extracted exact content (e.g., specific data model definitions, API endpoint details, relevant style guide snippets, component usage examples) or precise references to their location in the relevant sections of the story, or within the tasks themselves. This provides direct guidance to the Developer Agent.
- **For UI Stories, add a note to the Developer Agent:** "When implementing UI tasks, ensure to consult and adhere to `docs/style-guide.md`, `docs/component-guide.md`, and `docs/front-end-coding-standards.md` for specific guidance on styling, component usage, and coding practices relevant to your tasks."
- Apply validation checklist from `docs/templates/story-draft-checklist.md` to the `Status: Draft` story.
- Ensure story provides sufficient context without overspecifying (especially avoiding full duplication of `docs/project-structure.md` and `docs/coding-standards.md`).
- Verify project structure alignment is complete and accurate.
- Identify and resolve critical gaps if possible, or note them for user input.
- Mark as `Status: Draft (Needs Input)` if information is missing that the agent cannot derive.
- Flag any unresolved project structure conflicts.
- **Present the checklist results summary to the user, section by section, for interactive review.** This includes:
- If the user confirms the story is ready for development, update the story status to `Status: Approved`. Report that the Story is Approved and ready for the Developer Agent.
- If the user indicates the story is not ready, keep the status as `Status: Draft (Needs Input)` (or a similar status indicating revisions are needed based on user feedback). Clearly communicate what changes or clarifications are required from the user.
- Explicitly highlight any deviations or structural issues that were discussed and require ongoing user attention even if approved.
