mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-29 16:14:59 +00:00
FEA and A updated
This commit is contained in:
Brian Madison
@@ -8,9 +8,23 @@
|
||||
|
||||
## Task Instructions
|
||||
|
||||
### 1. Ask for review and Present Action List
|
||||
### 1. Section Context and Review
|
||||
|
||||
[[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.]]
|
||||
[[LLM: When invoked after outputting a section:
|
||||
|
||||
1. First, provide a brief 1-2 sentence summary of what the user should look for in the section just presented (e.g., "Please review the technology choices for completeness and alignment with your project needs. Pay special attention to version numbers and any missing categories.")
|
||||
|
||||
2. If the section contains Mermaid diagrams, explain each diagram briefly before offering elicitation options (e.g., "The component diagram shows the main system modules and their interactions. Notice how the API Gateway routes requests to different services.")
|
||||
|
||||
3. If the section contains multiple distinct items (like multiple components, multiple patterns, etc.), inform the user they can apply elicitation actions to:
|
||||
- The entire section as a whole
|
||||
- Individual items within the section (specify which item when selecting an action)
|
||||
|
||||
4. Then present the action list as specified below.]]
|
||||
|
||||
### 2. Ask for Review and Present Action List
|
||||
|
||||
[[LLM: Ask the user to review the drafted section. 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'. If there are multiple items in the section, mention they can specify which item(s) to apply the action to. Then, present ONLY the numbered list (0-9) of these actions. 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, proceed accordingly.]]
|
||||
|
||||
**Present the numbered list (0-9) with this exact format:**
|
||||
|
||||
|
||||
@@ -1,124 +0,0 @@
|
||||
# Architecture Creation Task
|
||||
|
||||
## Purpose
|
||||
|
||||
- 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`.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Input Analysis & Dialogue Establishment:**
|
||||
|
||||
- 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.
|
||||
|
||||
2. **Resolve Ambiguities & Gather Missing Information:**
|
||||
|
||||
- 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.
|
||||
|
||||
3. **Iterative Technology Selection & Design (Interactive, if not YOLO mode):**
|
||||
|
||||
- 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.
|
||||
|
||||
4. **Create Technical Artifacts (Incrementally, unless YOLO mode, guided by `architecture-tmpl`):**
|
||||
|
||||
- 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.
|
||||
- **Incorporate Feedback:** Discuss the draft with the user, incorporate their feedback, and iterate as needed.
|
||||
- [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)
|
||||
- **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).
|
||||
|
||||
5. **Identify Missing Technical Stories / Refine Epics (Interactive):**
|
||||
|
||||
- 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.
|
||||
|
||||
6. **Validate Architecture Against Checklist & Finalize Output:**
|
||||
- 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.
|
||||
- **Offer Design Architect Prompt (If Applicable):**
|
||||
- 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.
|
||||
|
||||
## Offer Advanced Self-Refinement & Elicitation Options
|
||||
|
||||
(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.}
|
||||
|
||||
1. **Critical Self-Review & User Goal Alignment**
|
||||
2. **Generate & Evaluate Alternative Design Solutions**
|
||||
3. **User Journey & Interaction Stress Test (Conceptual)**
|
||||
4. **Deep Dive into Design Assumptions & Constraints**
|
||||
5. **Usability & Accessibility Audit Review & Probing Questions**
|
||||
6. **Collaborative Ideation & UI Feature Brainstorming**
|
||||
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)
|
||||
@@ -2,9 +2,7 @@
|
||||
|
||||
## Purpose
|
||||
|
||||
- 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
|
||||
- Generate documents from any specified template following embedded instructions from the perspective of the selected agent persona
|
||||
|
||||
## Instructions
|
||||
|
||||
@@ -16,9 +14,7 @@
|
||||
|
||||
@{example}
|
||||
dependencies:
|
||||
templates:
|
||||
- prd-tmpl
|
||||
- architecture-tmpl
|
||||
templates: - prd-tmpl - architecture-tmpl
|
||||
@{/example}
|
||||
|
||||
You would offer to create "PRD" and "Architecture" documents when the user asks what you can help with.
|
||||
@@ -73,15 +69,6 @@ If template specifies a checklist:
|
||||
- Begin directly with document content (no preamble)
|
||||
- Include any handoff prompts specified in template
|
||||
|
||||
## Key Resources
|
||||
|
||||
- **Available Templates:** All files in `templates#` directory
|
||||
- **Checklists:** As specified by template or persona
|
||||
- **User Preferences:** `data#technical-preferences`
|
||||
|
||||
## Important Notes
|
||||
|
||||
- This task is template and persona agnostic
|
||||
- All specific instructions are embedded in templates
|
||||
- Focus on faithful template execution and clean output
|
||||
- Template markup is for AI processing only - never expose to users
|
||||
|
||||
@@ -1,146 +0,0 @@
|
||||
# Create Frontend Architecture Task
|
||||
|
||||
## Purpose
|
||||
|
||||
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.
|
||||
- Primary Design Files (Figma, Sketch, etc., linked from UI/UX Spec)
|
||||
|
||||
## Key Activities & Instructions
|
||||
|
||||
### 1. Confirm Interaction Mode
|
||||
|
||||
- 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.
|
||||
|
||||
### 3. Define Overall Frontend Philosophy & Patterns (for `front-end-architecture`)
|
||||
|
||||
- Based on the main architecture's tech stack and overall system structure (monorepo/polyrepo, backend service details), confirm and detail:
|
||||
- Framework & Core Libraries choices.
|
||||
- High-level Component Architecture strategy.
|
||||
- High-level State Management Strategy.
|
||||
- Data Flow principles.
|
||||
- Styling Approach.
|
||||
- Key Design Patterns to be employed.
|
||||
|
||||
### 4. Specify Detailed Frontend Directory Structure (for `front-end-architecture`)
|
||||
|
||||
- Collaboratively define or refine the frontend-specific directory structure, ensuring it aligns with the chosen framework and promotes modularity and scalability.
|
||||
|
||||
### 5. Outline Component Strategy & Conventions (for `front-end-architecture`)
|
||||
|
||||
- Define Component Naming & Organization conventions.
|
||||
- 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.
|
||||
|
||||
### 8. Define Routing Strategy (for `front-end-architecture`)
|
||||
|
||||
- Confirm the Routing Library.
|
||||
- Collaboratively define the main Route Definitions and any Route Guards.
|
||||
|
||||
### 9. Specify Build, Bundling, and Deployment Details (for `front-end-architecture`)
|
||||
|
||||
- Outline the frontend-specific Build Process & Scripts.
|
||||
- Discuss and document Key Bundling Optimizations.
|
||||
- Confirm Deployment to CDN/Hosting details relevant to the frontend.
|
||||
|
||||
### 10. Refine Frontend Testing Strategy (for `front-end-architecture`)
|
||||
|
||||
- Elaborate on the main testing strategy with specifics for: Component Testing, UI Integration/Flow Testing, and E2E UI Testing scope and tools.
|
||||
|
||||
### 11. Outline Performance Considerations (for `front-end-architecture`)
|
||||
|
||||
- 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.
|
||||
- **c. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
|
||||
|
||||
- **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).
|
||||
|
||||
### 13. Identify & Summarize Epic/Story Impacts (Frontend Focus)
|
||||
|
||||
- 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.
|
||||
|
||||
## Offer Advanced Self-Refinement & Elicitation Options
|
||||
|
||||
(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.}
|
||||
|
||||
1. **Critical Self-Review & User Goal Alignment**
|
||||
2. **Generate & Evaluate Alternative Design Solutions**
|
||||
3. **User Journey & Interaction Stress Test (Conceptual)**
|
||||
4. **Deep Dive into Design Assumptions & Constraints**
|
||||
5. **Usability & Accessibility Audit Review & Probing Questions**
|
||||
6. **Collaborative Ideation & UI Feature Brainstorming**
|
||||
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)
|
||||
@@ -1,89 +0,0 @@
|
||||
# PRD Generate Task
|
||||
|
||||
## Purpose
|
||||
|
||||
- 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.
|
||||
|
||||
## Instructions
|
||||
|
||||
### 1. Review Inputs
|
||||
|
||||
Review all provided inputs including project brief, research documents, prd template and user ideas to guide PRD generation.
|
||||
|
||||
### 2. Determine Interaction Mode
|
||||
|
||||
Confirm with the user their preferred interaction style:
|
||||
|
||||
- **Incremental:** Work through sections one at a time via chat messages as defined in the template.
|
||||
|
||||
- **YOLO Mode:** Draft the complete PRD making assumptions as necessary. Present full document at once, noting which sections required assumptions.
|
||||
|
||||
### 3. Execute Template
|
||||
|
||||
- Use the `prd-tmpl` template (or user-specified alternative template)
|
||||
- Follow all embedded LLM instructions within the template
|
||||
- Template contains section-specific guidance and examples
|
||||
|
||||
### 4. Template Processing Notes
|
||||
|
||||
- **Incremental Mode**: Present each section for review before proceeding
|
||||
- **YOLO Mode**: Generate all sections, then review with user
|
||||
|
||||
Process all template elements according to `utils#template-format` conventions.
|
||||
|
||||
**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**
|
||||
|
||||
**Content Presentation Guidelines:**
|
||||
|
||||
- Present only the final, clean content to users
|
||||
- Replace template variables with actual project-specific content
|
||||
- Process all conditional logic internally - show only relevant sections
|
||||
- For Canvas mode: Update the document with clean, formatted content only
|
||||
|
||||
### 7. Prepare Handoffs
|
||||
|
||||
Based on PRD content, prepare appropriate next-step prompts:
|
||||
|
||||
**If UI Component Exists:**
|
||||
|
||||
1. Add Design Architect prompt in designated template section
|
||||
2. Recommend: User engages Design Architect first for UI/UX Specification
|
||||
3. Then proceed to Architect with enriched PRD
|
||||
|
||||
**If No UI Component:**
|
||||
|
||||
- Add Architect prompt in designated template section
|
||||
- Recommend proceeding directly to Architect
|
||||
|
||||
### 8. Validate with Checklist
|
||||
|
||||
- Run the `pm-checklist` against completed PRD
|
||||
- Document completion status for each checklist item
|
||||
- Present summary by section, address any deficiencies
|
||||
- Generate final checklist report with findings and resolutions
|
||||
|
||||
### 9. Final Presentation
|
||||
|
||||
**General Guidelines:**
|
||||
|
||||
- Present complete documents in clean, full format
|
||||
- DO NOT truncate unchanged information
|
||||
- Begin directly with content (no introductory text needed)
|
||||
- Ensure all template sections are properly filled
|
||||
- **NEVER show template markup, instructions, or processing directives to users**
|
||||
|
||||
## Key Resources
|
||||
|
||||
- **Default Template:** `templates#prd-tmpl`
|
||||
- **Validation:** `checklists#pm-checklist`
|
||||
- **User Preferences:** `data#technical-preferences`
|
||||
- **Elicitation Protocol:** `tasks#advanced-elicitation`
|
||||
|
||||
## Important Notes
|
||||
|
||||
- This task is template-agnostic - users may specify custom templates
|
||||
- All detailed instructions are embedded in templates, not this task file
|
||||
- Focus on orchestration and workflow
|
||||
- **Template markup is for AI processing only - users should never see template formatting indicators**
|
||||
Reference in New Issue
Block a user