- Provide optional reflective and brainstorming actions to enhance content quality
- Enable deeper exploration of ideas through structured elicitation techniques
- Support iterative refinement through multiple analytical perspectives
## Task Instructions
### 1. Ask for review and Present Action List
[[LLM: Ask the user to review the {drafted document section, or context or document this protocol was executed from}. In the SAME message, inform them that they can suggest additions, removals, or modifications, OR they can select an action by number from the 'Advanced Reflective, Elicitation & Brainstorming Actions'. Then, present ONLY the numbered list (0-9) of these actions as defined in tasks#advanced-elicitation. Conclude by stating that selecting 9 will proceed to the next section. Await user selection. If an elicitation action (0-8) is chosen, execute it and then re-offer this combined review/elicitation choice. If option 9 is chosen, or if the user provides direct feedback on requirements, proceed accordingly.]]
**Present the numbered list (0-9) with this exact format:**
Choose an action (0-9 - 9 to bypass - HELP for explanation of these options):
0. Expand or Contract for Audience
1. Explain Reasoning (CoT Step-by-Step)
2. Critique and Refine
3. Analyze Logical Flow and Dependencies
4. Assess Alignment with Overall Goals
5. Identify Potential Risks and Unforeseen Issues
6. Challenge from Critical Perspective (Self or Other Persona)
7. Explore Diverse Alternatives (ToT-Inspired)
8. Hindsight is 20/20: The 'If Only...' Reflection
9. Proceed / No Further Actions
```
### 2. Processing Guidelines
**Do NOT show:**
- The full protocol text with `[[LLM: ...]]` instructions
- Detailed explanations of each option unless executing or the user asks, when giving the definition you can modify to tie its relevance
- Any internal template markup
**After user selection from the list:**
- Execute the chosen action according to the protocol instructions below
- Ask if they want to select another action or proceed with option 9 once complete
- Continue until user selects option 9 or indicates completion
## Action Definitions
0. Expand or Contract for Audience
[[LLM: Ask the user whether they want to 'expand' on the content (add more detail, elaborate) or 'contract' it (simplify, clarify, make more concise). Also, ask if there's a specific target audience they have in mind. Once clarified, perform the expansion or contraction from your current role's perspective, tailored to the specified audience if provided.]]
1. Explain Reasoning (CoT Step-by-Step)
[[LLM: Explain the step-by-step thinking process, characteristic of your role, that you used to arrive at the current proposal for this content.]]
2. Critique and Refine
[[LLM: From your current role's perspective, review your last output or the current section for flaws, inconsistencies, or areas for improvement, and then suggest a refined version reflecting your expertise.]]
3. Analyze Logical Flow and Dependencies
[[LLM: From your role's standpoint, examine the content's structure for logical progression, internal consistency, and any relevant dependencies. Confirm if elements are presented in an effective order.]]
4. Assess Alignment with Overall Goals
[[LLM: Evaluate how well the current content contributes to the stated overall goals of the document, interpreting this from your specific role's perspective and identifying any misalignments you perceive.]]
5. Identify Potential Risks and Unforeseen Issues
[[LLM: Based on your role's expertise, brainstorm potential risks, overlooked edge cases, or unintended consequences related to the current content or proposal.]]
6. Challenge from Critical Perspective (Self or Other Persona)
[[LLM: Adopt a critical perspective on the current content. If the user specifies another role or persona (e.g., 'as a customer', 'as [Another Persona Name]'), critique the content or play devil's advocate from that specified viewpoint. If no other role is specified, play devil's advocate from your own current persona's viewpoint, arguing against the proposal or current content and highlighting weaknesses or counterarguments specific to your concerns. This can also randomly include YAGNI when appropriate, such as when trimming the scope of an MVP, the perspective might challenge the need for something to cut MVP scope.]]
7. Explore Diverse Alternatives (ToT-Inspired)
[[LLM: From your role's perspective, first broadly brainstorm a range of diverse approaches or solutions to the current topic. Then, from this wider exploration, select and present 2 distinct alternatives, detailing the pros, cons, and potential implications you foresee for each.]]
8. Hindsight is 20/20: The 'If Only...' Reflection
[[LLM: In your current persona, imagine it's a retrospective for a project based on the current content. What's the one 'if only we had known/done X...' that your role would humorously or dramatically highlight, along with the imagined consequences?]]
9. Proceed / No Further Actions
[[LLM: Acknowledge the user's choice to finalize the current work, accept the AI's last output as is, or move on to the next step without selecting another action from this list. Prepare to proceed accordingly.]]
This task provides instructions for validating documentation against checklists. The agent should follow these instructions to ensure thorough and systematic validation of documents.
## Context
The BMAD Method uses various checklists to ensure quality and completeness of different artifacts. The mapping between checklists and their required documents is defined in `checklist-mappings`. This allows for easy addition of new checklists without modifying this task.
## Instructions
1. **Initial Assessment**
- Check `checklist-mappings` for available checklists
- If user provides a checklist name:
- Look for exact match in checklist-mappings.yml
- If no exact match, try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
- If multiple matches found, ask user to clarify
- Once matched, use the checklist_file path from the mapping
- If no checklist specified:
- Ask the user which checklist they want to use
- Present available options from checklist-mappings.yml
- Confirm if they want to work through the checklist:
- Section by section (interactive mode)
- All at once (YOLO mode)
2. **Document Location**
- Look up the required documents and default locations in `checklist-mappings`
- For each required document:
- Check all default locations specified in the mapping
- If not found, ask the user for the document location
- Verify all required documents are accessible
3. **Checklist Processing**
If in interactive mode:
- Work through each section of the checklist one at a time
- For each section:
- Review all items in the section
- Check each item against the relevant documentation
- Present findings for that section
- Get user confirmation before proceeding to next section
If in YOLO mode:
- Process all sections at once
- Create a comprehensive report of all findings
- Present the complete analysis to the user
4. **Validation Approach**
For each checklist item:
- Read and understand the requirement
- Look for evidence in the documentation that satisfies the requirement
- Consider both explicit mentions and implicit coverage
- Mark items as:
- ✅ PASS: Requirement clearly met
- ❌ FAIL: Requirement not met or insufficient coverage
- ⚠️ PARTIAL: Some aspects covered but needs improvement
- N/A: Not applicable to this case
5. **Section Analysis**
For each section:
- Calculate pass rate
- Identify common themes in failed items
- Provide specific recommendations for improvement
- In interactive mode, discuss findings with user
- Document any user decisions or explanations
6. **Final Report**
Prepare a summary that includes:
- Overall checklist completion status
- Pass rates by section
- List of failed items with context
- Specific recommendations for improvement
- Any sections or items marked as N/A with justification
## Special Considerations
1. **Architecture Checklist**
- Focus on technical completeness and clarity
- Verify all system components are addressed
- Check for security and scalability considerations
- Ensure deployment and operational aspects are covered
2. **Frontend Architecture Checklist**
- Validate UI/UX specifications
- Check component structure and organization
- Verify state management approach
- Ensure responsive design considerations
3. **PM Checklist**
- Focus on product requirements clarity
- Verify user stories and acceptance criteria
- Check market and user research coverage
- Ensure technical feasibility is addressed
4. **Story Checklists**
- Verify clear acceptance criteria
- Check for technical context and dependencies
- Ensure testability is addressed
- Validate user value is clearly stated
## Success Criteria
The checklist validation is complete when:
1. All applicable items have been assessed
2. Clear pass/fail status for each item
3. Specific recommendations provided for failed items
4. User has reviewed and acknowledged findings
5. Final report documents all decisions and rationales
## Example Interaction
Agent: "Let me check the available checklists... According to checklist-mappings.yml, we have several options. Which would you like to use?"
User: "The architect checklist"
Agent: "Would you like to work through it section by section (interactive) or get a complete analysis all at once (YOLO mode)?"
User: "Interactive please"
Agent: "According to the mappings, I need to check for architecture.md. The default location is docs/architecture.md. Should I look there?"
To create a concise memory recording file (`.ai/core-dump-n.md`) that captures the essential context of the current agent session, enabling seamless continuation of work in future agent sessions. This task ensures persistent context across agent conversations while maintaining minimal token usage for efficient context loading.
## Inputs for this Task
- Current session conversation history and accomplishments
- Files created, modified, or deleted during the session
- Key decisions made and procedures followed
- Current project state and next logical steps
- User requests and agent responses that shaped the session
## Task Execution Instructions
### 0. Check Existing Core Dump
Before proceeding, check if `.ai/core-dump.md` already exists:
- If file exists, ask user: "Core dump file exists. Should I: 1. Overwrite, 2. Update, 3. Append or 4. Create new?"
- **Overwrite**: Replace entire file with new content
- **Update**: Merge new session info with existing content, updating relevant sections
- **Append**: Add new session as a separate entry while preserving existing content
- **Create New**: Create a new file, appending the next possible -# to the file, such as core-dump-3.md if 1 and 2 already exist.
- If file doesn't exist, proceed with creation of `core-dump-1.md`
### 1. Analyze Session Context
- Review the entire conversation to identify key accomplishments
- Note any specific tasks, procedures, or workflows that were executed
- Identify important decisions made or problems solved
- Capture the user's working style and preferences observed during the session
### 2. Document What Was Accomplished
- **Primary Actions**: List the main tasks completed concisely
- **Story Progress**: For story work, use format "Tasks Complete: 1-6, 8. Next Task Pending: 7, 9"
- **Problem Solving**: Document any challenges encountered and how they were resolved
- **User Communications**: Summarize key user requests, preferences, and discussion points
### 3. Record File System Changes (Concise Format)
- Guide a structured response to a change trigger using the `change-checklist`.
- Analyze the impacts of the change on epics, project artifacts, and the MVP, guided by the checklist's structure.
- Explore potential solutions (e.g., adjust scope, rollback elements, rescope features) as prompted by the checklist.
- Draft specific, actionable proposed updates to any affected project artifacts (e.g., epics, user stories, PRD sections, architecture document sections) based on the analysis.
- Produce a consolidated "Sprint Change Proposal" document that contains the impact analysis and the clearly drafted proposed edits for user review and approval.
- Ensure a clear handoff path if the nature of the changes necessitates fundamental replanning by other core agents (like PM or Architect).
## Instructions
### 1. Initial Setup & Mode Selection
- **Acknowledge Task & Inputs:**
- Confirm with the user that the "Correct Course Task" (Change Navigation & Integration) is being initiated.
- Verify the change trigger and ensure you have the user's initial explanation of the issue and its perceived impact.
- Confirm access to all relevant project artifacts (e.g., PRD, Epics/Stories, Architecture Documents, UI/UX Specifications) and, critically, the `change-checklist` (e.g., `change-checklist`).
- **Establish Interaction Mode:**
- Ask the user their preferred interaction mode for this task:
- **"Incrementally (Default & Recommended):** Shall we work through the `change-checklist` section by section, discussing findings and collaboratively drafting proposed changes for each relevant part before moving to the next? This allows for detailed, step-by-step refinement."
- **"YOLO Mode (Batch Processing):** Or, would you prefer I conduct a more batched analysis based on the checklist and then present a consolidated set of findings and proposed changes for a broader review? This can be quicker for initial assessment but might require more extensive review of the combined proposals."
- Request the user to select their preferred mode.
- Once the user chooses, confirm the selected mode (e.g., "Okay, we will proceed in Incremental mode."). This chosen mode will govern how subsequent steps in this task are executed.
- **Explain Process:** Briefly inform the user: "We will now use the `change-checklist` to analyze the change and draft proposed updates. I will guide you through the checklist items based on our chosen interaction mode."
<rule>When asking multiple questions or presenting multiple points for user input at once, number them clearly (e.g., 1., 2a., 2b.) to make it easier for the user to provide specific responses.</rule>
### 2. Execute Checklist Analysis (Iteratively or Batched, per Interaction Mode)
- Systematically work through Sections 1-4 of the `change-checklist` (typically covering Change Context, Epic/Story Impact Analysis, Artifact Conflict Resolution, and Path Evaluation/Recommendation).
- For each checklist item or logical group of items (depending on interaction mode):
- Present the relevant prompt(s) or considerations from the checklist to the user.
- Request necessary information and actively analyze the relevant project artifacts (PRD, epics, architecture documents, story history, etc.) to assess the impact.
- Discuss your findings for each item with the user.
- Record the status of each checklist item (e.g., `[x] Addressed`, `[N/A]`, `[!] Further Action Needed`) and any pertinent notes or decisions.
- Collaboratively agree on the "Recommended Path Forward" as prompted by Section 4 of the checklist.
### 3. Draft Proposed Changes (Iteratively or Batched)
- Based on the completed checklist analysis (Sections 1-4) and the agreed "Recommended Path Forward" (excluding scenarios requiring fundamental replans that would necessitate immediate handoff to PM/Architect):
- Identify the specific project artifacts that require updates (e.g., specific epics, user stories, PRD sections, architecture document components, diagrams).
- **Draft the proposed changes directly and explicitly for each identified artifact.** Examples include:
- Revising user story text, acceptance criteria, or priority.
- Adding, removing, reordering, or splitting user stories within epics.
- Proposing modified architecture diagram snippets (e.g., providing an updated Mermaid diagram block or a clear textual description of the change to an existing diagram).
- Updating technology lists, configuration details, or specific sections within the PRD or architecture documents.
- Drafting new, small supporting artifacts if necessary (e.g., a brief addendum for a specific decision).
- If in "Incremental Mode," discuss and refine these proposed edits for each artifact or small group of related artifacts with the user as they are drafted.
- If in "YOLO Mode," compile all drafted edits for presentation in the next step.
### 4. Generate "Sprint Change Proposal" with Edits
- Synthesize the complete `change-checklist` analysis (covering findings from Sections 1-4) and all the agreed-upon proposed edits (from Instruction 3) into a single document titled "Sprint Change Proposal." This proposal should align with the structure suggested by Section 5 of the `change-checklist` (Proposal Components).
- The proposal must clearly present:
- **Analysis Summary:** A concise overview of the original issue, its analyzed impact (on epics, artifacts, MVP scope), and the rationale for the chosen path forward.
- **Specific Proposed Edits:** For each affected artifact, clearly show or describe the exact changes (e.g., "Change Story X.Y from: [old text] To: [new text]", "Add new Acceptance Criterion to Story A.B: [new AC]", "Update Section 3.2 of Architecture Document as follows: [new/modified text or diagram description]").
- Present the complete draft of the "Sprint Change Proposal" to the user for final review and feedback. Incorporate any final adjustments requested by the user.
### 5. Finalize & Determine Next Steps
- Obtain explicit user approval for the "Sprint Change Proposal," including all the specific edits documented within it.
- Provide the finalized "Sprint Change Proposal" document to the user.
- **Based on the nature of the approved changes:**
- **If the approved edits sufficiently address the change and can be implemented directly or organized by a PO/SM:** State that the "Correct Course Task" is complete regarding analysis and change proposal, and the user can now proceed with implementing or logging these changes (e.g., updating actual project documents, backlog items). Suggest handoff to a PO/SM agent for backlog organization if appropriate.
- **If the analysis and proposed path (as per checklist Section 4 and potentially Section 6) indicate that the change requires a more fundamental replan (e.g., significant scope change, major architectural rework):** Clearly state this conclusion. Advise the user that the next step involves engaging the primary PM or Architect agents, using the "Sprint Change Proposal" as critical input and context for that deeper replanning effort.
## Output Deliverables
- **Primary:** A "Sprint Change Proposal" document (in markdown format). This document will contain:
- A summary of the `change-checklist` analysis (issue, impact, rationale for the chosen path).
- Specific, clearly drafted proposed edits for all affected project artifacts.
- **Implicit:** An annotated `change-checklist` (or the record of its completion) reflecting the discussions, findings, and decisions made during the process.
To generate a masterful, comprehensive, and optimized prompt that can be used with AI-driven frontend development tools (e.g., Lovable, Vercel v0, or similar) to scaffold or generate significant portions of the frontend application.
- Ask the user to specify which AI frontend generation tool/platform they intend to use (e.g., "Lovable.ai", "Vercel v0", "GPT-4 with direct code generation instructions", etc.).
- Explain that prompt optimization might differ slightly based on the platform's capabilities and preferred input format.
- Briefly state the project's purpose (from brief/PRD).
- Specify the chosen frontend framework, core libraries, and UI component library (from `front-end-architecture` and main `architecture`).
- Mention the styling approach (e.g., Tailwind CSS, CSS Modules).
- **Design System & Visuals:**
- Reference the primary design files (e.g., Figma link).
- If the tool doesn't directly ingest design files, describe the overall visual style, color palette, typography, and key branding elements (from `front-end-spec-tmpl`).
- List any global UI components or design tokens that should be defined or adhered to.
- **Application Structure & Routing:**
- Describe the main pages/views and their routes (from `front-end-architecture` - Routing Strategy).
- Outline the navigation structure (from `front-end-spec-tmpl`).
- **Key User Flows & Page-Level Interactions:**
- For a few critical user flows (from `front-end-spec-tmpl`):
- Describe the sequence of user actions and expected UI changes on each relevant page.
- Specify API calls to be made (referencing API endpoints from the main `architecture`) and how data should be displayed or used.
- **Component Generation Instructions (Iterative or Key Components):**
- Based on the chosen AI tool's capabilities, decide on a strategy:
- **Option 1 (Scaffolding):** Prompt for the generation of main page structures, layouts, and placeholders for components.
- **Option 2 (Key Component Generation):** Select a few critical or complex components from the `front-end-architecture` (Component Breakdown) and provide detailed specifications for them (props, state, basic behavior, key UI elements).
- **Option 3 (Holistic, if tool supports):** Attempt to describe the entire application structure and key components more broadly.
- <important_note>Advise the user that generating an entire complex application perfectly in one go is rare. Iterative prompting or focusing on sections/key components is often more effective.</important_note>
- **State Management (High-Level Pointers):**
- Mention the chosen state management solution (e.g., "Use Redux Toolkit").
- For key pieces of data, indicate if they should be managed in global state.
- **API Integration Points:**
- For pages/components that fetch or submit data, clearly state the relevant API endpoints (from `architecture`) and the expected data shapes (can reference schemas in `data-models` or `api-reference` sections of the architecture doc).
- **Critical "Don'ts" or Constraints:**
- e.g., "Do not use deprecated libraries." "Ensure all forms have basic client-side validation."
- **Platform-Specific Optimizations:**
- If the chosen AI tool has known best practices for prompting (e.g., specific keywords, structure, level of detail), incorporate them. (This might require the agent to have some general knowledge or to ask the user if they know any such specific prompt modifiers for their chosen tool).
- Output the generated prompt in a clear, copy-pasteable format (e.g., a large code block).
- Explain the structure of the prompt and why certain information was included.
- Work with the user to refine the prompt based on their knowledge of the target AI tool and any specific nuances they want to emphasize.
- <important_note>Remind the user that the generated code from the AI tool will likely require review, testing, and further refinement by developers.</important_note>
- To design a complete, robust, and well-documented technical architecture based on the project requirements (PRD, epics, brief), research findings, and user input.
- To make definitive technology choices and articulate the rationale behind them, leveraging the architecture template as a structural guide.
- To produce all necessary technical artifacts, ensuring the architecture is optimized for efficient implementation, particularly by AI developer agents, and validated against the `architect-checklist`.
- Ensure you have all necessary inputs: PRD document (specifically checking for the 'Technical Assumptions' and 'Initial Architect Prompt' sections for the decided repository and service architecture), project brief, any deep research reports, and optionally a `technical-preferences.md`. Request any missing critical documents.
- Thoroughly review all inputs.
- Summarize key technical requirements, constraints, NFRs (Non-Functional Requirements), and the decided repository/service architecture derived from the inputs. Present this summary to the user for confirmation and to ensure mutual understanding.
- Share initial architectural observations, potential challenges, or areas needing clarification based on the inputs.
**Establish Interaction Mode for Architecture Creation:**
- Ask the user: "How would you like to proceed with creating the architecture for this project? We can work:
A. **Incrementally (Default & Recommended):** We'll go through each architectural decision, document section, or design point step-by-step. I'll present drafts, and we'll seek your feedback and confirmation before moving to the next part. This is best for complex decisions and detailed refinement.
B. **"YOLO" Mode:** I can produce a more comprehensive initial draft of the architecture (or significant portions) for you to review more broadly first. We can then iterate on specific sections based on your feedback. This can be quicker for generating initial ideas but is generally not recommended if detailed collaboration at each step is preferred."
- Request the user to select their preferred mode (e.g., "Please let me know if you'd prefer A or B.").
- Once the user chooses, confirm the selected mode (e.g., "Okay, we will proceed in Incremental mode."). This chosen mode will govern how subsequent steps in this task are executed.
- If key information is missing or requirements are unclear after initial review, formulate specific, targeted questions.
- **External API Details:** If the project involves integration with external APIs, especially those that are less common or where you lack high confidence in your training data regarding their specific request/response schemas, and if a "Deep Research" phase was not conducted for these APIs:
- Proactively ask the user to provide precise details. This includes:
- Links to the official API documentation.
- Example request structures (e.g., cURL commands, JSON payloads).
- Example response structures (e.g., JSON responses for typical scenarios, including error responses).
- Explain that this information is crucial for accurately defining API interaction contracts within the architecture, for creating robust facades/adapters, and for enabling accurate technical planning (e.g., for technical stories or epic refinements).
- Present questions to the user (batched logically if multiple) and await their input.
- Document all decisions and clarifications received before proceeding.
- For each major architectural component or decision point (e.g., frontend framework, backend language/framework, database system, cloud provider, key services, communication patterns):
- If multiple viable options exist based on requirements or research, present 2-3 choices, briefly outlining their pros, cons, and relevance to the project. Consider any preferences stated in `technical-preferences.md` when formulating these options and your recommendation.
- State your recommended choice, providing a clear rationale based on requirements, research findings, user preferences (if known), and best practices (e.g., scalability, cost, team familiarity, ecosystem).
- Ask for user feedback, address concerns, and seek explicit approval before finalizing the decision.
- Document the confirmed choice and its rationale within the architecture document.
- **Starter Templates:** If applicable and requested, research and recommend suitable starter templates or assess existing codebases. Explain alignment with project goals and seek user confirmation.
- For each artifact or section of the main Architecture Document:
- **Explain Purpose:** Briefly describe the artifact/section's importance and what it will cover.
- **Draft Section-by-Section:** Present a draft of one logical section at a time.
- Ensure the 'High-Level Overview' and 'Component View' sections accurately reflect and detail the repository/service architecture decided in the PRD.
- Ensure that documented Coding Standards (either as a dedicated section or referenced) and the 'Testing Strategy' section clearly define:
- The convention for unit test file location (e.g., co-located with source files, or in a separate folder like `tests/` or `__tests__/`).
- The naming convention for unit test files (e.g., `*.test.js`, `*.spec.ts`, `test_*.py`).
- When discussing Coding Standards, inform the user that these will serve as firm rules for the AI developer agent. Emphasize that these standards should be kept to the minimum necessary to prevent undesirable or messy code from the agent. Guide the user to understand that overly prescriptive or obvious standards (e.g., "use SOLID principles," which well-trained LLMs should already know) should be avoided, as the user, knowing the specific agents and tools they will employ, can best judge the appropriate level of detail.
- **Seek Approval:** Obtain explicit user approval for the section before moving to the next, or for the entire artifact if drafted holistically (in YOLO mode).
- Based on the designed architecture, identify any necessary technical stories/tasks that are not yet captured in the PRD or epics (e.g., "Set up CI/CD pipeline for frontend deployment," "Implement authentication module using JWT," "Create base Docker images for backend services," "Configure initial database schema based on data models").
- Explain the importance of these technical stories for enabling the functional requirements and successful project execution.
- Collaborate with the user to refine these stories (clear description, acceptance criteria) and suggest adding them to the project backlog or relevant epics.
- Review existing epics/stories from the PRD and suggest technical considerations or acceptance criteria refinements to ensure they are implementable based on the chosen architecture. For example, specifying API endpoints to be called, data formats, or critical library versions.
- After collaboration, prepare a concise summary detailing all proposed additions, updates, or modifications to epics and user stories. If no changes are identified, explicitly state this.
- Once the main architecture document components have been drafted and reviewed with the user, perform a comprehensive review using the `architect-checklist`.
- Go through each item in the checklist to ensure the architecture document is comprehensive, addresses all key architectural concerns (e.g., security, scalability, maintainability, testability (including confirmation that coding standards and the testing strategy clearly define unit test location and naming conventions), developer experience), and that proposed solutions are robust.
- For each checklist item, confirm its status (e.g., \[x] Completed, \[ ] N/A, \[!] Needs Attention).
- If deficiencies, gaps, or areas needing more detail or clarification are identified based on the checklist:
- Discuss these findings with the user.
- Collaboratively make necessary updates, additions, or refinements to the architecture document to address these points.
- After addressing all checklist points and ensuring the architecture document is robust and complete, present a summary of the checklist review to the user. This summary should highlight:
- Confirmation that all relevant sections/items of the checklist have been satisfied by the architecture.
- Any items marked N/A, with a brief justification.
- A brief note on any significant discussions, decisions, or changes made to the architecture document as a result of the checklist review.
- If the architecture includes UI components, ask the user if they would like to include a dedicated prompt for a "Design Architect" at the end of the main architecture document.
- Explain that this prompt can capture specific UI considerations, notes from discussions, or decisions that don't fit into the core technical architecture document but are crucial for the Design Architect.
- The prompt should also state that the Design Architect will subsequently operate in its specialized mode to define the detailed frontend architecture.
- If the user agrees, collaboratively draft this prompt and append it to the architecture document.
- Obtain final user approval for the complete architecture documentation generation.
- **Recommend Next Steps for UI (If Applicable):**
- After the main architecture document is finalized and approved:
- If the project involves a user interface (as should be evident from the input PRD and potentially the architecture document itself mentioning UI components or referencing outputs from a Design Architect's UI/UX Specification phase):
- Strongly recommend to the user that the next critical step for the UI is to engage the **Design Architect** agent.
- Specifically, advise them to use the Design Architect's **'Frontend Architecture Mode'**.
- Explain that the Design Architect will use the now-completed main Architecture Document and the detailed UI/UX specifications (e.g., `front-end-spec-tmpl.txt` or enriched PRD) as primary inputs to define the specific frontend architecture, select frontend libraries/frameworks (if not already decided), structure frontend components, and detail interaction patterns.
### Output Deliverables for Architecture Creation Phase
- A comprehensive Architecture Document, structured according to the `architecture-tmpl` (which is all markdown) or an agreed-upon format, including all sections detailed above.
- Clear Mermaid diagrams for architecture overview, data models, etc.
- A list of new or refined technical user stories/tasks ready for backlog integration.
- A summary of any identified changes (additions, updates, modifications) required for existing epics or user stories, or an explicit confirmation if no such changes are needed.
- A completed `architect-checklist` (or a summary of its validation).
- Optionally, if UI components are involved and the user agrees: A prompt for a "Design Architect" appended to the main architecture document, summarizing relevant UI considerations and outlining the Design Architect's next steps.
(This section is called when needed prior to this)
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
{Instruction for AI Agent: Display the title of each numbered item below. If the user asks what a specific option means, provide a brief explanation of the action you will take, drawing from detailed descriptions tailored for the context.}
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNIT the user indicates it is time to proceed ot the next section (or selects #8)
Leveraging advanced analytical capabilities, the Deep Research Phase with the PM is designed to provide targeted, strategic insights crucial for product definition. Unlike the broader exploratory research an Analyst might undertake, the PM utilizes deep research to:
- **Validate Product Hypotheses:** Rigorously test assumptions about market need, user problems, and the viability of specific product concepts.
- **Refine Target Audience & Value Proposition:** Gain a nuanced understanding of specific user segments, their precise pain points, and how the proposed product delivers unique value to them.
- **Focused Competitive Analysis:** Analyze competitors through the lens of a specific product idea to identify differentiation opportunities, feature gaps to exploit, and potential market positioning challenges.
- **De-risk PRD Commitments:** Ensure that the problem, proposed solution, and core features are well-understood and validated _before_ detailed planning and resource allocation in the PRD Generation Mode.
Choose this phase with the PM when you need to strategically validate a product direction, fill specific knowledge gaps critical for defining _what_ to build, or ensure a strong, evidence-backed foundation for your PRD, especially if initial Analyst research was not performed or requires deeper, product-focused investigation.
- To gather foundational information, validate concepts, understand market needs, or analyze competitors when a comprehensive Project Brief from an Analyst is unavailable or insufficient.
- To ensure the PM has a solid, data-informed basis for defining a valuable and viable product before committing to PRD specifics.
- To de-risk product decisions by grounding them in targeted research, especially if the user is engaging the PM directly without prior Analyst work or if the initial brief lacks necessary depth.
<critical_rule>Note on Deep Research Execution:</critical_rule>
To perform deep research effectively, please be aware:
- You may need to use this current conversational agent to help you formulate a comprehensive research prompt, which can then be executed by a dedicated deep research model or function.
- Alternatively, ensure you have activated or switched to a model/environment that has integrated deep research capabilities.
This agent can guide you in preparing for deep research, but the execution may require one of these steps.
- Define specific, actionable research questions to address the identified gaps.
- Propose targeted research activities (e.g., focused web searches for market reports, competitor websites, industry analyses, user reviews of similar products, technology trends).
- <important_note>Confirm this research plan, scope, and key questions with the user before proceeding with research execution.</important_note>
- Organize and summarize key research findings in a clear, concise, and easily digestible manner (e.g., bullet points, brief summaries per research question).
- Highlight the most critical implications for the product's vision, strategy, target audience, core features, and potential risks.
- Present these synthesized findings and their implications to the user.
- The comprehensive findings/report from this Deep Research phase can be substantial. I am available to discuss these with you, explain any part in detail, and help you understand their implications.
- **Options for Utilizing These Findings for PRD Generation:**
1. **Full Handoff to New PM Session:** The complete research output can serve as a foundational document if you initiate a _new_ session with a Product Manager (PM) agent who will then execute the 'PRD Generate Task'.
2. **Key Insights Summary for This Session:** I can prepare a concise summary of the most critical findings, tailored to be directly actionable as we (in this current session) transition to potentially invoking the 'PRD Generate Task'.
- <critical_rule>Regardless of how you proceed, it is highly recommended that these research findings (either the full output or the key insights summary) are provided as direct input when invoking the 'PRD Generate Task'. This ensures the PRD is built upon a solid, evidence-based foundation.</critical_rule>
- Discuss with the user whether the gathered information provides a sufficient and confident foundation to proceed to the 'PRD Generate Task'.
- If significant gaps or uncertainties remain, discuss and decide with the user on further targeted research or if assumptions need to be documented and carried forward.
- Once confirmed, clearly state that the next step could be to invoke the 'PRD Generate Task' or, if applicable, revisit other phase options.
- Generate documents from any specified template following embedded instructions
- Support multiple document types through template-driven approach
- Enable any persona to create consistent, well-structured documents
## Instructions
### 1. Identify Template and Context
- Determine which template to use (user-provided or list available for selection to user)
- agent-config specific agents will list what docs they have available under this task, for each item consider it a unique task. So if the user had for example:
you would list `Create Document PRD` and `Create Document Architecture` as tasks the agent could perform.
- Gather all relevant inputs, or ask for them, or else rely on user providing necessary details to complete the document
- Understand the document purpose and target audience
### 2. Determine Interaction Mode
Confirm with the user their preferred interaction style:
- **Incremental:** Work through chunks of the document.
- **YOLO Mode:** Draft complete document making reasonable assumptions in one shot. (Can be entered also after starting incremental by just typing /yolo)
### 3. Execute Template
- Load specified template from `templates#*` or the /templates directory
- Follow ALL embedded LLM instructions within the template
- Process template markup according to `templates#template-format` conventions
### 4. Template Processing Rules
**CRITICAL: Never display template markup, LLM instructions, or examples to users**
- Replace all {{placeholders}} with actual content
- Execute all [[LLM: instructions]] internally
- Process <<REPEAT>> sections as needed
- Evaluate ^^CONDITION^^ blocks and include only if applicable
- Use @{examples} for guidance but never output them
### 5. Content Generation
- **Incremental Mode**: Present each major section for review before proceeding
- **YOLO Mode**: Generate all sections, then review complete document with user
- Apply any elicitation protocols specified in template
- Incorporate user feedback and iterate as needed
### 6. Validation
If template specifies a checklist:
- Run the appropriate checklist against completed document
- Document completion status for each item
- Address any deficiencies found
- Present validation summary to user
### 7. Final Presentation
- Present clean, formatted content only
- Ensure all sections are complete
- DO NOT truncate or summarize content
- Begin directly with document content (no preamble)
- Include any handoff prompts specified in template
To define the technical architecture for the frontend application. This includes selecting appropriate patterns, structuring the codebase, defining component strategy, planning state management, outlining API interactions, and setting up testing and deployment approaches, all while adhering to the guidelines in `front-end-architecture-tmpl` template.
## Inputs
- Product Requirements Document (PRD) (`prd-tmpl` or equivalent)
- Completed UI/UX Specification (`front-end-spec-tmpl` or equivalent)
- Main System Architecture Document (`architecture` or equivalent) - The agent executing this task should particularly note the overall system structure (Monorepo/Polyrepo, backend service architecture) detailed here, as it influences frontend patterns.
- Ask the user: "How would you like to proceed with creating the frontend architecture? We can work:
A. **Incrementally (Default & Recommended):** We'll go through each architectural decision and document section step-by-step. I'll present drafts, and we'll seek your feedback and confirmation before moving to the next part. This is best for complex decisions and detailed refinement.
B. **"YOLO" Mode:** I can produce a more comprehensive initial draft of the frontend architecture for you to review more broadly first. We can then iterate on specific sections based on your feedback. This can be quicker for generating initial ideas but is generally not recommended if detailed collaboration at each step is preferred."
- Request the user to select their preferred mode (e.g., "Please let me know if you'd prefer A or B.").
- Once the user chooses, confirm the selected mode (e.g., "Okay, we will proceed in Incremental mode."). This chosen mode will govern how subsequent steps are executed.
### 2. Review Inputs & Establish Context
- Thoroughly review the inputs, including the UI/UX Specification and the main Architecture Document (especially "Definitive Tech Stack Selections", API contracts, and the documented overall system structure like monorepo/polyrepo choices).
- Ask clarifying questions to bridge any gaps between the UI/UX vision and the overall system architecture.
- Collaboratively define or refine the frontend-specific directory structure, ensuring it aligns with the chosen framework and promotes modularity and scalability.
- Establish the "Template for Component Specification" (as per `front-end-architecture`), emphasizing that most components will be detailed emergently but must follow this template.
- Optionally, specify a few absolutely foundational/shared UI components (e.g., a generic Button or Modal wrapper if the chosen UI library needs one, or if no UI library is used).
### 6. Detail State Management Setup & Conventions (for `front-end-architecture`)
- Based on the high-level strategy, detail:
- Chosen Solution and core setup.
- Conventions for Store Structure / Slices (e.g., "feature-based slices"). Define any genuinely global/core slices (e.g., session/auth).
- Conventions for Selectors and Actions/Reducers/Thunks. Provide templates or examples.
### 7. Plan API Interaction Layer (for `front-end-architecture`)
- Define the HTTP Client Setup.
- Establish patterns for Service Definitions (how API calls will be encapsulated).
- Outline frontend Error Handling & Retry strategies for API calls.
- List key frontend-specific performance strategies to be employed.
### 12. Document Drafting & Confirmation (Guided by `front-end-architecture-tmpl`)
- **If "Incremental Mode" was selected:**
- For each relevant section of the `front-end-architecture` (as outlined in steps 3-11 above, covering topics from Overall Philosophy to Performance Considerations):
- **a. Explain Purpose & Draft Section:** Explain the purpose of the section and present a draft for that section.
- **b. Initial Discussion & Feedback:** Discuss the draft with the user, incorporate their feedback, and iterate as needed for initial revisions.
- **d. Final Approval & Documentation:** Obtain explicit user approval for the section. Ensure all placeholder links and references are correctly noted within each section. Then proceed to the next section.
- Once all sections are individually approved through this process, confirm with the user that the overall `front-end-architecture` document is populated and ready for Step 13 (Epic/Story Impacts) and then the checklist review (Step 14).
- **If "YOLO Mode" was selected:**
- Collaboratively populate all relevant sections of the `front-end-architecture-tmpl` (as outlined in steps 3-11 above) to create a comprehensive first draft.
- Present the complete draft of `front-end-architecture` to the user for a holistic review.
- <important_note>After presenting the full draft in YOLO mode, you MAY still offer a condensed version of the 'Advanced Reflective & Elicitation Options' menu, perhaps focused on a few key overarching review actions (e.g., overall requirements alignment, major risk assessment) if the user wishes to perform a structured deep dive before detailed section-by-section feedback.</important_note>
- Obtain explicit user approval for the entire `front-end-architecture` document before proceeding to Step 13 (Epic/Story Impacts) and then the checklist review (Step 14).
- After the `front-end-architecture` is confirmed, review it in context of existing epics and user stories (if provided or known).
- Identify any frontend-specific technical tasks that might need to be added as new stories or sub-tasks (e.g., "Implement responsive layout for product details page based on defined breakpoints," "Set up X state management slice for user profile," "Develop reusable Y component as per specification").
- Identify if any existing user stories require refinement of their acceptance criteria due to frontend architectural decisions (e.g., specifying interaction details, component usage, or performance considerations for UI elements).
- Collaborate with the user to define these additions or refinements.
- Prepare a concise summary detailing all proposed additions, updates, or modifications to epics and user stories related to the frontend. If no changes are identified, explicitly state this (e.g., "No direct impacts on existing epics/stories were identified from the frontend architecture").
### 14. Checklist Review and Finalization
- Once the `front-end-architecture` has been populated and reviewed with the user, and epic/story impacts have been summarized, use the `frontend-architecture-checklist`.
- Go through each item in the checklist to ensure the `front-end-architecture` is comprehensive and all sections are adequately addressed - for each checklist item you MUST consider if it is really complete or deficient.
- For each checklist section, confirm its status (e.g., \[x] Completed, \[ ] N/A, \[!] Needs Attention).
- If deficiencies or areas needing more detail are identified with a section:
- Discuss these with the user.
- Collaboratively make necessary updates or additions to the `front-end-architecture`.
- After addressing all points and ensuring the document is robust, present a summary of the checklist review to the user. This summary should highlight:
- Confirmation that all relevant sections of the checklist have been satisfied.
- Any items marked N/A and a brief reason.
- A brief note on any significant discussions or changes made as a result of the checklist review.
- The goal is to ensure the `front-end-architecture` is a complete and actionable document.
(This section is called when needed prior to this)
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
{Instruction for AI Agent: Display the title of each numbered item below. If the user asks what a specific option means, provide a brief explanation of the action you will take, drawing from detailed descriptions tailored for the context.}
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNIT the user indicates it is time to proceed ot the next section (or selects #8)
To design a comprehensive infrastructure architecture that defines all aspects of the technical infrastructure strategy, from cloud platform selection to deployment patterns. This architecture will serve as the definitive blueprint for the DevOps/Platform Engineering team to implement, ensuring consistency, security, and operational excellence across all infrastructure components.
- Ask the user: "How would you like to proceed with creating the infrastructure architecture? We can work:
A. **Incrementally (Default & Recommended):** We'll go through each architectural decision and document section step-by-step. I'll present drafts, and we'll seek your feedback before moving to the next part. This is best for complex infrastructure designs.
B. **"YOLO" Mode:** I can produce a comprehensive initial draft of the infrastructure architecture for you to review more broadly first. We can then iterate on specific sections based on your feedback."
- Request the user to select their preferred mode and proceed accordingly.
### 2. Gather Infrastructure Requirements
- Review the product requirements document to understand business needs and scale requirements
- Analyze the main system architecture to identify infrastructure dependencies
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next section (or selects #8)
To identify the next logical story based on project progress and epic definitions, and then to prepare a comprehensive, self-contained, and actionable story file using the `Story Template`. This task ensures the story is enriched with all necessary technical context, requirements, and acceptance criteria, making it ready for efficient implementation by a Developer Agent with minimal need for additional research.
## Inputs for this Task
- Access to the project's documentation repository, specifically:
- `docs/index.md` (hereafter "Index Doc")
- All Epic files (e.g., `docs/epic-{n}.md` - hereafter "Epic Files")
- Existing story files in `docs/stories/`
- Main PRD (hereafter "PRD Doc")
- Main Architecture Document (hereafter "Main Arch Doc")
- Frontend Architecture Document (hereafter "Frontend Arch Doc," if relevant)
1. View the incomplete story details (instructs user to do so, agent does not display)
2. Cancel new story creation at this time
3. Accept risk & Override to create the next story in draft
Please choose an option (1/2/3):
```
- Proceed only if user selects option 3 (Override) or if the last story was 'Done'.
- If proceeding: Check the Epic File for `{lastEpicNum}` for a story numbered `{lastStoryNum + 1}`. If it exists and its prerequisites (per Epic File) are met, this is the next story.
- Else (story not found or prerequisites not met): The next story is the first story in the next Epic File (e.g., `docs/epic-{lastEpicNum + 1}.md`, then `{lastEpicNum + 2}.md`, etc.) whose prerequisites are met.
- **If no story files exist in `docs/stories/`:**
- The next story is the first story in `docs/epic-1.md` (then `docs/epic-2.md`, etc.) whose prerequisites are met.
- If no suitable story with met prerequisites is found, report to the user that story creation is blocked, specifying what prerequisites are pending. HALT task.
- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}".
### 2. Gather Core Story Requirements (from Epic File)
- For the identified story, open its parent Epic File.
- Extract: Exact Title, full Goal/User Story statement, initial list of Requirements, all Acceptance Criteria (ACs), and any predefined high-level Tasks.
- Keep a record of this original epic-defined scope for later deviation analysis.
### 3. Gather & Synthesize In-Depth Technical Context for Dev Agent
- <critical_rule>Systematically use the Index Doc (`docs/index.md`) as your primary guide to discover paths to ALL detailed documentation relevant to the current story's implementation needs.</critical_rule>
- Thoroughly review the PRD Doc, Main Arch Doc, and Frontend Arch Doc (if a UI story).
- Guided by the Index Doc and the story's needs, locate, analyze, and synthesize specific, relevant information from sources such as:
- Data Models Doc (structure, validation rules).
- API Reference Doc (endpoints, request/response schemas, auth).
- Applicable architectural patterns or component designs from Arch Docs.
- Specifics from Tech Stack Doc if versions or configurations are key for this story.
- Relevant sections of the Operational Guidelines Doc (e.g., story-specific error handling nuances, security considerations for data handled in this story).
- The goal is to collect all necessary details the Dev Agent would need, to avoid them having to search extensively. Note any discrepancies between the epic and these details for "Deviation Analysis."
### 4. Verify Project Structure Alignment
- Cross-reference the story's requirements and anticipated file manipulations with the Project Structure Guide (and frontend structure if applicable).
- Ensure any file paths, component locations, or module names implied by the story align with defined structures.
- Document any structural conflicts, necessary clarifications, or undefined components/paths in a "Project Structure Notes" section within the story draft.
### 5. Populate Story Template with Full Context
- Create a new story file: `docs/stories/{epicNum}.{storyNum}.story.md`.
- Use the Story Template to structure the file.
- Fill in:
- Story `{EpicNum}.{StoryNum}: {Short Title Copied from Epic File}`
- `Status: Draft`
- `Story` (User Story statement from Epic)
- `Acceptance Criteria (ACs)` (from Epic, to be refined if needed based on context)
- Based on all context gathered (Step 3 & 4), embed concise but critical snippets of information, specific data structures, API endpoint details, precise references to _specific sections_ in other documents (e.g., "See `Data Models Doc#User-Schema-ValidationRules` for details"), or brief explanations of how architectural patterns apply to _this story_.
- If UI story, provide specific references to Component/Style Guides relevant to _this story's elements_.
- The aim is to make this section the Dev Agent's primary source for _story-specific_ technical context.
- **`Tasks / Subtasks` section:**
- Generate a detailed, sequential list of technical tasks and subtasks the Dev Agent must perform to complete the story, informed by the gathered context.
- Link tasks to ACs where applicable (e.g., `Task 1 (AC: 1, 3)`).
- Add notes on project structure alignment or discrepancies found in Step 4.
- Prepare content for the "Deviation Analysis" based on discrepancies noted in Step 3.
To implement a comprehensive platform infrastructure stack based on the Infrastructure Architecture Document, including foundation infrastructure, container orchestration, GitOps workflows, service mesh, and developer experience platforms. This integrated approach ensures all platform components work synergistically to provide a complete, secure, and operationally excellent platform foundation.
- Ask the user: "How would you like to proceed with platform infrastructure implementation? We can work:
A. **Incrementally (Default & Recommended):** We'll implement each platform layer step-by-step (Foundation → Container Platform → GitOps → Service Mesh → Developer Experience), validating integration at each stage. This ensures thorough testing and operational readiness.
B. **"YOLO" Mode:** I'll implement the complete platform stack in logical groups, with validation at major integration milestones. This is faster but requires comprehensive end-to-end testing."
- Request the user to select their preferred mode and proceed accordingly.
- Review Infrastructure Architecture Document for complete platform specifications
- Validate platform requirements against application architecture and business needs
- Create integrated implementation roadmap with proper dependency sequencing
- Plan resource allocation, security policies, and operational procedures across all platform layers
- Document rollback procedures and risk mitigation strategies for the entire platform
- <critical_rule>Verify the infrastructure change request is approved before beginning implementation. If not, HALT and inform the user.</critical_rule>
- **Resource Planning:** Confirm resource allocation, sizing, and optimization strategies
- **Risk & Constraint Discussion:**
- Identify potential implementation risks and mitigation strategies
- Document operational constraints that may impact architectural implementation
- Plan contingency approaches for high-risk implementation areas
- Establish escalation triggers for implementation issues requiring architectural input
- **Implementation Validation Planning:**
- Define validation criteria for each platform component and integration point
- Plan testing strategies and acceptance criteria with Architect input
- Establish quality gates and review checkpoints throughout implementation
- Document success metrics and performance benchmarks
- **Documentation & Knowledge Transfer Planning:**
- Plan documentation approach and knowledge transfer requirements
- Define operational runbooks and troubleshooting guide requirements
- Establish ongoing collaboration points for implementation support
- <critical_rule>Complete joint planning session before beginning platform implementation. Document all planning outcomes and agreements.</critical_rule>
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current platform layer before finalizing it and moving to the next. The user can select an action by number, or choose to skip this and proceed.
"To ensure the quality of the current platform layer: **[Specific Platform Layer Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next platform layer (or selects #8)
- Transform inputs into core product definition documents conforming to a PRD template
- Define clear MVP scope focused on essential functionality
- Provide foundation for Architect and Design Architect to help create technical artifacts which will in turn later draft further details for very junior engineers or simple dev ai agents.
**CRITICAL: Never display or output template markup formatting, LLM instructions or examples - they MUST be used by you the agent only, AND NEVER shown to users in chat or document output**
To collaboratively work with the user to define and document the User Interface (UI) and User Experience (UX) specifications for the project. This involves understanding user needs, defining information architecture, outlining user flows, and ensuring a solid foundation for visual design and frontend development. The output will populate a new document called `front-end-spec.md` following the `front-end-spec-tmpl` template.
- Clarify where detailed visual designs will be created (e.g., Figma, Sketch) and ensure the `front-end-spec-tmpl` correctly links to these primary design files.
- If low-fidelity wireframes are needed first, offer to help conceptualize layouts for key screens.
- Discuss if an existing design system will be used or if a new one needs to be developed.
- If new, identify a few foundational components to start with (e.g., Button, Input, Card) and their key states/behaviors at a high level. Detailed technical specs will be in `front-end-architecture`.
- **b. Present & Incorporate Initial Feedback:** Present the drafted section to the user for review. Discuss, explain and incorporate their initial feedback and revisions directly.
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
{Instruction for AI Agent: Display the title of each numbered item below. If the user asks what a specific option means, provide a brief explanation of the action you will take, drawing from detailed descriptions tailored for the context.}
7. **Elicit 'Unforeseen User Needs' & Future Interaction Questions**
8. **Finalize this Section and Proceed.**
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNIT the user indicates it is time to proceed ot the next section (or selects #8)
You are a Technical Documentation Librarian tasked with granulating large project documents into smaller, organized files. Your goal is to transform monolithic documentation into a well-structured, navigable documentation system.
Transform large project documents into smaller, granular files within the `docs/` directory following the `doc-sharding-tmpl.txt` plan. Create and maintain `docs/index.md` as a central catalog for easier reference and context injection.
This task maintains the integrity and completeness of the `docs/index.md` file by scanning all documentation files and ensuring they are properly indexed with descriptions.
## Task Instructions
You are now operating as a Documentation Indexer. Your goal is to ensure all documentation files are properly cataloged in the central index.
### Required Steps
1. First, locate and scan:
- The `docs/` directory and all subdirectories
- The existing `docs/index.md` file (create if absent)
- All markdown (`.md`) and text (`.txt`) files in the documentation structure
2. For the existing `docs/index.md`:
- Parse current entries
- Note existing file references and descriptions
- Identify any broken links or missing files
- Keep track of already-indexed content
3. For each documentation file found:
- Extract the title (from first heading or filename)
- Generate a brief description by analyzing the content
- Create a relative markdown link to the file
- Check if it's already in the index
- If missing or outdated, prepare an update
4. For any missing or non-existent files found in index:
- Present a list of all entries that reference non-existent files
- For each entry:
- Show the full entry details (title, path, description)
- Ask for explicit confirmation before removal
- Provide option to update the path if file was moved
- Log the decision (remove/update/keep) for final report
5. Update `docs/index.md`:
- Maintain existing structure and organization
- Add missing entries with descriptions
- Update outdated entries
- Remove only entries that were confirmed for removal
- Ensure consistent formatting throughout
### Index Entry Format
Each entry in `docs/index.md` should follow this format:
```markdown
### [Document Title](relative/path/to/file.md)
Brief description of the document's purpose and contents.
```
### Rules of Operation
1. NEVER modify the content of indexed files
2. Preserve existing descriptions in index.md when they are adequate
3. Maintain any existing categorization or grouping in the index
4. Use relative paths for all links
5. Ensure descriptions are concise but informative
6. NEVER remove entries without explicit confirmation
7. Report any broken links or inconsistencies found
8. Allow path updates for moved files before considering removal
### Process Output
The task will provide:
1. A summary of changes made to index.md
2. List of newly indexed files
3. List of updated entries
4. List of entries presented for removal and their status:
- Confirmed removals
- Updated paths
- Kept despite missing file
5. Any other issues or inconsistencies found
### Handling Missing Files
For each file referenced in the index but not found in the filesystem:
1. Present the entry:
```markdown
Missing file detected:
Title: [Document Title]
Path: relative/path/to/file.md
Description: Existing description
Options:
1. Remove this entry
2. Update the file path
3. Keep entry (mark as temporarily unavailable)
Please choose an option (1/2/3):
```
2. Wait for user confirmation before taking any action
3. Log the decision for the final report
## Required Input
Please provide:
1. Location of the `docs/` directory
2. Confirmation of write access to `docs/index.md`
3. Any specific categorization preferences
4. Any files or directories to exclude from indexing
Would you like to proceed with library indexing? Please provide the required input above.
To conduct a thorough review of existing infrastructure to identify improvement opportunities, security concerns, and alignment with best practices. This task helps maintain infrastructure health, optimize costs, and ensure continued alignment with organizational requirements.
- Ask the user: "How would you like to proceed with the infrastructure review? We can work:
A. **Incrementally (Default & Recommended):** We'll work through each section of the checklist methodically, documenting findings for each item before moving to the next section. This provides a thorough review.
B. **"YOLO" Mode:** I can perform a rapid assessment of all infrastructure components and present a comprehensive findings report. This is faster but may miss nuanced details."
- Request the user to select their preferred mode and proceed accordingly.
### 2. Prepare for Review
- Gather and organize current infrastructure documentation
- Access monitoring and logging systems for operational data
- Review recent incident reports for recurring issues
- Collect cost and performance metrics
- <critical_rule>Establish review scope and boundaries with the user before proceeding</critical_rule>
### 3. Conduct Systematic Review
- **If "Incremental Mode" was selected:**
- For each section of the infrastructure checklist:
- **a. Present Section Focus:** Explain what aspects of infrastructure this section reviews
- **b. Work Through Items:** Examine each checklist item against current infrastructure
- **c. Document Current State:** Record how current implementation addresses or fails to address each item
- **d. Identify Gaps:** Document improvement opportunities with specific recommendations
- **f. Section Summary:** Provide an assessment summary before moving to the next section
- **If "YOLO Mode" was selected:**
- Rapidly assess all infrastructure components
- Document key findings and improvement opportunities
- Present a comprehensive review report
- <important_note>After presenting the full review in YOLO mode, you MAY still offer the 'Advanced Reflective & Elicitation Options' menu for deeper investigation of specific areas with issues.</important_note>
- **Operational Issues:** Can be addressed through operational improvements without architectural changes
- **Unclear/Ambiguous Issues:** When escalation level is uncertain, consult with user for guidance and decision
- Document escalation recommendations with clear justification and impact assessment
- <critical_rule>If escalation classification is unclear or ambiguous, HALT and ask user for guidance on appropriate escalation level and approach</critical_rule>
### 7. Present and Plan
- Prepare an executive summary of key findings
- Create detailed technical documentation for implementation teams
- Develop an action plan for critical and high-priority items
- Prepare detailed technical findings for Architect Agent review
- Request architectural assessment of identified concerns
- Schedule collaborative planning session for potential architectural evolution
- Document architectural recommendations and planned follow-up
- **If Only Operational Issues Identified:**
- Proceed with operational improvement planning without architectural escalation
- Monitor for future architectural implications of operational changes
- **If Unclear/Ambiguous Escalation Needed:**
- **User Consultation Required:**
- Present unclear findings and escalation options to user
- Request user guidance on appropriate escalation level and approach
- Document user decision and rationale for escalation approach
- Proceed with user-directed escalation path
- <critical_rule>All critical architectural escalations must be documented and acknowledged by Architect Agent before proceeding with implementation</critical_rule>
## Output
A comprehensive infrastructure review report that includes:
1. **Current state assessment** for each infrastructure component
2. **Prioritized findings** with severity ratings
3. **Detailed recommendations** with effort/impact estimates
4. **Cost optimization opportunities**
5. **BMAD integration assessment**
6. **Architectural escalation assessment** with clear escalation recommendations
7. **Action plan** for critical improvements and architectural work
8. **Escalation documentation** for Architect Agent collaboration (if applicable)
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next section (or selects #8)
To comprehensively validate platform infrastructure changes against security, reliability, operational, and compliance requirements before deployment. This task ensures all platform infrastructure meets organizational standards, follows best practices, and properly integrates with the broader BMAD ecosystem.
- Ask the user: "How would you like to proceed with platform infrastructure validation? We can work:
A. **Incrementally (Default & Recommended):** We'll work through each section of the checklist step-by-step, documenting compliance or gaps for each item before moving to the next section. This is best for thorough validation and detailed documentation of the complete platform stack.
B. **"YOLO" Mode:** I can perform a rapid assessment of all checklist items and present a comprehensive validation report for review. This is faster but may miss nuanced details that would be caught in the incremental approach."
- Request the user to select their preferred mode (e.g., "Please let me know if you'd prefer A or B.").
- Once the user chooses, confirm the selected mode and proceed accordingly.
### 2. Initialize Platform Validation
- Review the infrastructure change documentation to understand platform implementation scope and purpose
- Analyze the infrastructure architecture document for platform design patterns and compliance requirements
- Examine infrastructure guidelines for organizational standards across all platform components
- Prepare the validation environment and tools for comprehensive platform testing
- <critical_rule>Verify the infrastructure change request is approved for validation. If not, HALT and inform the user.</critical_rule>
### 3. Architecture Design Review Gate
- **DevOps/Platform → Architect Design Review:**
- Conduct systematic review of infrastructure architecture document for implementability
- Evaluate architectural decisions against operational constraints and capabilities:
- **Implementation Complexity:** Assess if proposed architecture can be implemented with available tools and expertise
- **Operational Feasibility:** Validate that operational patterns are achievable within current organizational maturity
- **Resource Availability:** Confirm required infrastructure resources are available and within budget constraints
- **g. Section Summary:** Provide a compliance percentage and highlight critical findings before moving to the next section
- **If "YOLO Mode" was selected:**
- Work through all checklist sections rapidly (foundation infrastructure sections 1-12 + platform engineering sections 13-16)
- Document compliance status for each item across all platform components
- Identify and document critical non-compliance issues affecting platform operations
- Present a comprehensive validation report for all sections
- <important_note>After presenting the full validation report in YOLO mode, you MAY still offer the 'Advanced Reflective & Elicitation Options' menu for deeper investigation of specific sections with issues.</important_note>
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next section (or selects #8)
