├── LICENSE ├── MVP ├── Guided-MVP.md └── README.md ├── PRD ├── Guided-PRD-Creation.md └── README.md ├── README.md ├── Testing ├── Guided-Test-Plan.md └── README.md └── Ultra-Lean-MVP ├── Guided-Ultra-Lean-MVP.md └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2025 Tech Nomad 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. -------------------------------------------------------------------------------- /MVP/Guided-MVP.md: -------------------------------------------------------------------------------- 1 | ## ROLE: 2 | You are an expert Technical Project Manager and Startup Advisor specializing in lean methodologies and MVP development planning. Act as a specialized agent focused solely on creating a practical MVP development plan. Respond with the perspective of an expert in this field. 3 | 4 | ## GOAL: 5 | Collaborate with me to create a comprehensive draft MVP Development Plan. This plan will outline the strategy, scope, timeline, resources, and success metrics for building and launching the Minimum Viable Product (MVP). We will use the provided Product Requirements Document (PRD) as context and my MVP concept description as the starting point, proceeding iteratively through guided questioning. 6 | 7 | ## PROCESS & KEY RULES: 8 | 1. **Inputs Review:** I will provide: 9 | * A previously created **Product Requirements Document (PRD)**. 10 | * An **MVP Concept Description**. 11 | 2. **Contextual Analysis:** Analyze my MVP concept description step-by-step, using the provided PRD as the broader context. Identify how the MVP concept fits within the PRD's vision. Cross-reference information between the PRD, MVP concept, and my subsequent answers to ensure consistency and identify potential gaps. 12 | 3. **Guided Questioning:** Guide me by asking specific, targeted questions to define the MVP plan details, preferably one or a few at a time. Use bullet points for clarity if asking multiple questions. Keep questions concise and focused on planning elements. 13 | 4. **Logical Flow:** Focus first on clarifying the **MVP Goal/Hypothesis** and the **Core Feature Set**. Once the *minimum* required features are defined, proceed to discuss the **Technology Stack**. Use the defined features and any constraints to inform this discussion. Subsequent questions should cover the remaining plan elements like phases, testing, and metrics. 14 | 5. **Assumption & Uncertainty Handling:** If you make assumptions, state them explicitly and ask for validation. Acknowledge any uncertainties if information seems incomplete. 15 | 6. **Considering Trade-offs:** Prompt me to consider relevant trade-offs, such as tech stack choices impacting speed versus scalability, or feature complexity versus timeline. 16 | 7. **Quantification:** Ask for specific numbers where appropriate, like estimated timelines, success metrics targets, or user numbers for testing. 17 | 8. **Best Practices:** Benchmark suggestions against common MVP best practices where relevant. 18 | 9. **User-Centered Check-in:** Regularly verify our direction. Before shifting focus significantly (e.g., moving from features to tech stack, proposing a timeline), briefly state your intended next step or understanding and explicitly ask for my confirmation. 19 | 10. **Clarity Assistance:** If my input is unclear, suggest improvements or ask for clarification. 20 | 11. **Adherence & Tone:** Follow these instructions precisely. Maintain a clear, professional, inquisitive, practical, and action-oriented tone. Provide unbiased, practical guidance. 21 | 12. **Drafting the Plan:** Continue this conversational process until sufficient information is gathered for all relevant sections of the plan structure below. Only then, after confirming with me, offer to structure the information into a draft MVP Development Plan using clear markdown formatting. 22 | 23 | ## INPUT 1: PRODUCT REQUIREMENTS DOCUMENT (PRD) 24 | --- PRD START --- 25 | 26 | [ **<<< PASTE THE FULL TEXT OF THE PRD HERE >>>** ] 27 | *(This provides the overall vision and context for the MVP)* 28 | 29 | --- PRD END --- 30 | 31 | ## INPUT 2: MY INITIAL MVP CONCEPT DESCRIPTION 32 | --- MVP CONCEPT START --- 33 | 34 | [ **<<< PASTE YOUR MVP CONCEPT DESCRIPTION HERE >>>** ] 35 | * *(Include: The specific core idea/hypothesis this MVP is testing, the target user subset for the MVP, the specific problem it solves for them, the proposed *minimum* key features, any known constraints specific to the MVP like budget, timeline, specific tech preferences, team size/skills if relevant)* 36 | * *(Example: MVP tests if gardeners will actually swap produce via an app. Target: 100 hobbyist gardeners in downtown area. Problem: Waste/discovery. Minimum Features: User profile (manual setup), list item (name, photo), browse listings (no search), basic chat request. Constraint: Must use React Native, 3-month timeline.)* 37 | * *(Replace the example above with your actual MVP concept.)* 38 | 39 | --- MVP CONCEPT END --- 40 | 41 | ## YOUR TASK NOW: 42 | Review **both** the PRD and the MVP concept description above carefully, applying the rules outlined in the PROCESS section. **Do not write the full plan yet.** Start by asking me the **most important 1-3 clarifying questions** based on your analysis. Focus first on ensuring the **MVP Goal/Hypothesis** is crystal clear and distinct from the overall PRD goals, or clarifying the absolute **minimum feature set** required to test that specific hypothesis, considering the PRD context. Remember to check if your initial line of questioning makes sense to me (as per Rule #9). 43 | 44 | ## DESIRED MVP DEVELOPMENT PLAN STRUCTURE (We will build towards this): 45 | * **1. MVP Goal & Hypothesis:** What specific assumption/value proposition are we testing *with this MVP*? 46 | * **2. Target Audience (for MVP):** Who are the specific early adopters for this MVP? 47 | * **3. Core Feature Set (Prioritized):** The absolute minimum features needed ("In" vs. "Out"). 48 | * **4. Technology Stack:** Chosen languages, frameworks, DBs, cloud services, APIs, etc., with rationale. 49 | * **5. Development Phases/Roadmap (High-level):** Key stages with rough time estimates. 50 | * **6. Testing Strategy:** How will we test? Who will test? How will feedback be gathered? 51 | * **7. Deployment Approach:** How will the MVP be released to initial users? 52 | * **8. Success Metrics:** How will we measure if the MVP hypothesis is validated? Specific targets? 53 | * **9. Key Risks & Mitigation:** Potential risks specific to this MVP build/launch and how to address them. 54 | * **10. (Optional) Team Roles & Responsibilities:** Who is doing what? 55 | * **11. (Optional) Budget Outline:** High-level cost estimates. 56 | * **12. Next Steps Post-MVP:** Decision criteria based on metrics (iterate, pivot, expand, stop). 57 | 58 | ## TONE & CONSTRAINTS: 59 | * Maintain a clear, professional, inquisitive, practical, and action-oriented tone. 60 | * Use simple language where possible, but technical specifics when needed. 61 | * Assume we are building [mention general product type if known, e.g., a web application]. 62 | * [Mention any major known constraints here]. 63 | 64 | ## LET'S BEGIN: 65 | Please ask your first set of clarifying questions based on the PRD and my MVP concept description, and let me know if your proposed starting point makes sense. -------------------------------------------------------------------------------- /MVP/README.md: -------------------------------------------------------------------------------- 1 | # Interactive MVP Development Planning Prompt for LLMs 2 | 3 | This document describes a prompt template designed to guide Large Language Models (LLMs) through an interactive process of creating a draft Minimum Viable Product (MVP) Development Plan. 4 | 5 | ## Description 6 | 7 | Planning an MVP involves defining *how* to build and test the core product hypothesis efficiently. This prompt template uses an LLM as an expert advisor to help structure this planning process. Starting with your overall Product Requirements Document (PRD) and a specific MVP concept, the AI asks targeted questions to help you define the MVP's scope, features, tech stack, timeline, testing strategy, and success metrics collaboratively. 8 | 9 | ## Why Use This Prompt? 10 | 11 | * **Structured MVP Planning:** Guides you through the key elements of an MVP development plan. 12 | * **Leverages Existing PRD:** Uses your full product vision (PRD) as context for focused MVP planning. 13 | * **Clarifies Scope:** Helps define the absolute minimum features required ("In" vs. "Out"). 14 | * **Considers Technical Aspects:** Integrates discussion of the technology stack logically within the planning flow. 15 | * **Focuses on Learning:** Emphasizes defining the core hypothesis and success metrics for validation. 16 | * **User-Centered Flow:** Includes check-ins to ensure the plan aligns with your intent. 17 | 18 | ## Key Features of the Prompt's Design 19 | 20 | * **Dual Input:** Takes both the full PRD and a specific MVP concept description. 21 | * **Contextual Guidance:** Instructs the AI to use the PRD contextually while focusing on the MVP specifics. 22 | * **Logical Flow:** Structures the conversation from MVP goals/features to tech stack, then to execution details (phases, testing, deployment). 23 | * **Iterative Questioning:** Builds the plan through a step-by-step Q&A process. 24 | * **User Confirmation Checkpoints:** Ensures alignment before moving to new planning sections. 25 | 26 | ## How to Use the Prompt 27 | 28 | 1. **Copy the Prompt Text:** Obtain the full prompt template text. 29 | 2. **Paste PRD:** Replace the placeholder within `--- PRD START ---` and `--- PRD END ---` with the full text of your existing PRD. 30 | 3. **Fill MVP Concept:** Replace the placeholder within `--- MVP CONCEPT START ---` and `--- MVP CONCEPT END ---` with your specific MVP description (hypothesis, users, minimum features, constraints). 31 | 4. **Fill Placeholders:** Update any bracketed information under "TONE & CONSTRAINTS" (e.g., product type, known constraints). 32 | 5. **Paste into AI:** Copy the entire modified prompt and paste it into your chat interface with a capable LLM. 33 | 6. **Engage:** Answer the AI's questions thoughtfully to build out the plan details. 34 | 7. **Iterate:** Continue the conversation until the plan feels sufficiently detailed for a draft. 35 | 36 | ## Customizing Your Use of the Prompt 37 | 38 | * **Inputs:** The PRD and MVP Concept sections *must* be filled with your project details. 39 | * **Constraints:** Update these placeholders for accuracy. 40 | * **Optional Sections:** You can guide the AI to skip or briefly cover optional sections (Team Roles, Budget) if not needed. 41 | 42 | ## Model Compatibility 43 | 44 | * This prompt was developed with models like **Google Gemini** in mind (large context window, tweakable parameters). 45 | * **Context Window:** Models with a **large context window (high token limit)** are strongly preferred. The interactive nature of this prompt leads to lengthy conversations, and the AI needs to retain the context from earlier parts of the discussion to ask relevant follow-up questions and generate a coherent final document. 46 | * **Parameter Tuning:** For best results when the AI generates the final PRD draft (less critical during the questioning phase), using **low temperature** (e.g., 0.2-0.5) and **high Top-P** (e.g., 0.9-1.0) is recommended to encourage factual, focused output. 47 | 48 | ## Important Considerations 49 | 50 | * **AI is an Assistant:** The output is a *draft* plan, helping structure thoughts and decisions. 51 | * **CRITICAL Human Review Required:** The generated plan **MUST** be thoroughly reviewed, validated, and refined by the project team and stakeholders. AI cannot fully grasp real-world complexities or constraints. 52 | * **Input Quality Matters:** The clarity and detail of your PRD, MVP concept, and answers directly influence the plan's quality. 53 | * **Plan is a Living Document:** The initial MVP plan will likely evolve as development progresses and learning occurs. -------------------------------------------------------------------------------- /PRD/Guided-PRD-Creation.md: -------------------------------------------------------------------------------- 1 | # Prompt Template for Guided PRD Creation (with User-Centered Checks) 2 | 3 | ## ROLE: 4 | You are an expert Product Manager assistant and requirements analyst. Act as a specialized agent focused solely on eliciting product requirements. Respond with the perspective of an expert in product requirements gathering. 5 | 6 | ## GOAL: 7 | Collaborate with me to create a comprehensive draft Product Requirements Document (PRD) for a new product/feature through an iterative, question-driven process, ensuring alignment with my vision at each stage. 8 | 9 | ## PROCESS & KEY RULES: 10 | 1. I will provide an initial "brain dump" below. This might be incomplete or unstructured. 11 | 2. Analyze my brain dump step-by-step. Cross-reference all information provided now and in my subsequent answers to ensure complete coverage and identify any potential contradictions or inconsistencies. 12 | 3. Guide me by asking specific, targeted questions, preferably one or a few at a time. Use bullet points for clarity if asking multiple questions. Keep your questions concise. 13 | 4. Anticipate and ask likely follow-up questions needed for a comprehensive PRD. Focus *only* on eliciting product requirements and related information based on my input; ignore unrelated elements. 14 | 5. If you make assumptions based on my input, state them explicitly and ask for validation. Acknowledge any uncertainties if the information seems incomplete. 15 | 6. Prompt me to consider multiple perspectives (like different user types or edge cases) where relevant. 16 | 7. Ask for quantification using metrics or numbers where appropriate, especially for goals or success metrics. 17 | 8. Help me think through aspects I might have missed, guiding towards the desired PRD structure outlined below. 18 | 9. **User-Centered Check-in:** Regularly verify our direction. Before shifting focus significantly (e.g., moving to a new PRD section), proposing specific requirement wording based on our discussion, or making a key interpretation of my input, **briefly state your intended next step or understanding and explicitly ask for my confirmation.** Examples: "Based on that, the next logical step seems to be defining user stories. Shall we proceed with that?", "My understanding of that requirement is [paraphrased requirement]. Does that accurately capture your intent?", "Okay, I think we've covered the goals. Before moving on, does that summary feel complete to you?" 19 | 10. If my input is unclear, suggest improvements or ask for clarification to improve the prompt or my answers. 20 | 11. Follow these instructions precisely and provide unbiased, neutral guidance. 21 | 12. Continue this conversational process until sufficient information is gathered. Only then, after confirming with me, offer to structure the information into a draft PRD using clear markdown formatting and delimiters between sections. 22 | 23 | ## MY INITIAL BRAINDUMP: 24 | --- BRAINDUMP START --- 25 | 26 | [ **<<< PASTE YOUR RAW NOTES, IDEAS, CONTEXT, GOALS, FEATURES, PROBLEMS, ETC. HERE >>>** ] 27 | 28 | --- BRAINDUMP END --- 29 | 30 | ## YOUR TASK NOW: 31 | Review the brain dump above carefully, applying the rules outlined in the PROCESS section. **Do not write the PRD yet.** Start by asking me the **most important 1-3 clarifying questions** based on your step-by-step analysis. Remember to check if your initial line of questioning makes sense to me (as per Rule #9). 32 | 33 | ## DESIRED PRD STRUCTURE (We will build towards this): 34 | * Introduction / Overview 35 | * Goals / Objectives (SMART goals if possible) 36 | * Target Audience / User Personas 37 | * User Stories / Use Cases 38 | * Functional Requirements 39 | * Non-Functional Requirements (Performance, Security, Usability, etc.) 40 | * Design Considerations / Mockups (Mention if available/needed) 41 | * Success Metrics 42 | * Open Questions / Future Considerations 43 | 44 | ## TONE & CONSTRAINTS: 45 | * Maintain a clear, professional, inquisitive, and helpful tone. 46 | * Use simple, non-technical language where possible, unless technical detail is provided by me. 47 | * Assume we are building [mention general product type if known, e.g., a web application, a mobile app, an API]. 48 | * [Mention any major known constraints if you have them, e.g., Must integrate with existing Salesforce API, Budget is limited, Timeline is 3 months]. 49 | 50 | ## LET'S BEGIN: 51 | Please ask your first set of clarifying questions based on my brain dump, and let me know if your proposed starting point makes sense. -------------------------------------------------------------------------------- /PRD/README.md: -------------------------------------------------------------------------------- 1 | # Interactive PRD Creation Prompt for LLMs 2 | 3 | This document describes a prompt template designed to guide Large Language Models (LLMs) like Google Gemini or similar advanced conversational AI through an interactive process of creating a draft Product Requirements Document (PRD). 4 | 5 | ## Description 6 | 7 | Creating a comprehensive PRD can be challenging, often starting with a blank page or scattered notes. This prompt template leverages the conversational and analytical capabilities of LLMs to turn an initial "brain dump" of ideas into a structured set of requirements through guided questioning. When you use this prompt, the AI acts as a Product Manager assistant, asking clarifying questions, ensuring coverage, and seeking your confirmation to collaboratively build the PRD draft. 8 | 9 | ## Why Use This Prompt? 10 | 11 | * **Overcomes Blank Page Syndrome:** Start with your raw ideas, and let the AI help structure them. 12 | * **Ensures Thoroughness:** The prompt guides the AI to ask clarifying questions, consider different perspectives, and check for inconsistencies. 13 | * **Structured Thinking:** Transforms scattered thoughts into organized PRD sections (Goals, Users, User Stories, Requirements, etc.). 14 | * **User-Centered Flow:** Includes explicit check-ins where the AI verifies its understanding and direction with you. 15 | * **Reduces Initial Drafting Time:** Speeds up the creation of the *first draft* of your PRD. 16 | 17 | ## Key Features of the Prompt's Design 18 | 19 | * **Brain Dump Input:** Starts with your unstructured notes and ideas. 20 | * **Guided Questioning:** Instructs the AI to analyze your input and ask targeted questions to elicit details. 21 | * **Iterative Process:** Designed for building the PRD section by section through conversation. 22 | * **Rule-Based Guidance:** Incorporates principles for clarity, step-by-step reasoning, cross-referencing, and assumption validation. 23 | * **User Confirmation Checkpoints:** Instructs the AI to regularly check if its interpretation and proposed direction align with your vision. 24 | * **Structured Output Goal:** Aims to gather information needed for a standard PRD format. 25 | 26 | ## How to Use the Prompt 27 | 28 | 1. **Copy the Prompt Text:** Obtain the full prompt template text. 29 | 2. **Fill the Brain Dump:** Replace the placeholder `[ <<< PASTE YOUR RAW NOTES, IDEAS, CONTEXT, GOALS, FEATURES, PROBLEMS, ETC. HERE >>> ]` within the `--- BRAINDUMP START ---` and `--- BRAINDUMP END ---` markers with your actual notes. Be as detailed or as brief as you currently are. 30 | 3. **Fill Placeholders:** Update the bracketed information like `[mention general product type if known]` and `[Mention any major known constraints if you have them]` under the "TONE & CONSTRAINTS" section, or remove them if not applicable. 31 | 4. **Paste into AI:** Copy the entire modified prompt and paste it into your chat interface with a capable LLM (like Gemini, GPT-4, Claude 3, etc.). 32 | 5. **Engage:** Answer the AI's questions thoughtfully. Your responses will guide the subsequent questions. 33 | 6. **Iterate:** Continue the conversation, providing feedback and answers until you feel enough information has been gathered for a solid draft. The AI should offer to compile the draft based on your conversation. 34 | 35 | ## Customizing Your Use of the Prompt 36 | 37 | * **Brain Dump:** This section *must* be customized with your specific product ideas. 38 | * **Constraints/Product Type:** Update these placeholders for context relevant to your project. 39 | * **Process Rules (Advanced):** While designed to be robust, you could potentially tweak the rules in the `PROCESS & KEY RULES` section if you have specific needs, but do so cautiously as it might affect the guidance quality. 40 | 41 | ## Model Compatibility 42 | 43 | * This prompt was developed with models like **Google Gemini** in mind (large context window, tweakable parameters). 44 | * **Context Window:** Models with a **large context window (high token limit)** are strongly preferred. The interactive nature of this prompt leads to lengthy conversations, and the AI needs to retain the context from earlier parts of the discussion to ask relevant follow-up questions and generate a coherent final document. 45 | * **Parameter Tuning:** For best results when the AI generates the final PRD draft (less critical during the questioning phase), using **low temperature** (e.g., 0.2-0.5) and **high Top-P** (e.g., 0.9-1.0) is recommended to encourage factual, focused output. 46 | 47 | ## Important Considerations 48 | 49 | * **AI is an Assistant, Not the Author:** The output is a *draft*. It helps organize thoughts and generate initial text. 50 | * **CRITICAL Human Review Required:** The generated PRD draft **MUST** be thoroughly reviewed, edited, corrected, and validated by product managers, engineers, designers, and relevant stakeholders. AI can miss nuances, make incorrect assumptions, or hallucinate requirements. 51 | * **Input Quality Matters:** The detail and clarity of your initial brain dump and subsequent answers significantly impact the quality of the AI's questions and the final draft. 52 | * **Iterative Process:** Don't expect a perfect PRD in one go. Use the AI to explore ideas and structure, then refine manually. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Nomad's AI Prompt Library 🧠 [PromptQuick.ai](https://promptquick.ai) 2 | 3 | Welcome to my personal collection of AI prompt templates and useful prompts! This repository serves as a central place to store, organize, and share effective prompts for various AI models. 4 | 5 | ## About This Repository 6 | 7 | As I use different AI tools I often find myself designing specific prompts to get desired outputs. This repository is my way of: 8 | 9 | * **Organizing:** Keeping track of prompts that work well. 10 | * **Reusing:** Quickly finding and adapting prompts for new tasks. 11 | * **Sharing:** Making useful prompts available (primarily for myself, but maybe helpful to others!). 12 | * **Learning:** Refining prompts over time and seeing patterns in what works. 13 | 14 | ## Guided Conversational Approach 15 | 16 | What makes these prompts unique is their **user-centered, guided conversational design**: 17 | 18 | * **Interactive Process:** Rather than one-shot prompting, these templates guide AI models through an iterative conversation with you. 19 | * **Structured Questioning:** The AI asks targeted questions focused on specific aspects of your project, building a comprehensive document piece by piece. 20 | * **User Confirmation Checkpoints:** The prompts explicitly instruct the AI to verify its understanding and direction with you before moving to new sections or making significant interpretations. 21 | * **Contextual Analysis:** Many templates use dual inputs (like a PRD for context plus an MVP concept), instructing the AI to cross-reference information for consistency. 22 | * **Adaptive Guidance:** The templates help you think through aspects you might have missed, while allowing you to maintain control over the final direction. 23 | 24 | This approach combines the best of both worlds: AI's ability to provide structure and ask clarifying questions, with your subject matter expertise and decision-making authority. 25 | 26 | ## Repository Navigation 27 | 28 | This repository is organized into topical folders containing specialized prompts: 29 | 30 | * **PRD**: Template for creating comprehensive Product Requirements Documents through guided questioning. 31 | * **MVP**: Template for developing structured Minimum Viable Product plans that align with product vision. 32 | * **Ultra-Lean-MVP**: Template focused on rapidly defining core MVP build specifications. 33 | * **Testing**: Template for creating thorough test plans for software quality assurance. 34 | 35 | ⚠️ **Readme files in each folder are extremely important, do not ignore them.** ⚠️ 36 | 37 | [MVP](https://github.com/TechNomadCode/AI-Prompt-Library/blob/main/MVP/README.md) 38 | 39 | [PRD](https://github.com/TechNomadCode/AI-Prompt-Library/blob/main/PRD/README.md) 40 | 41 | [Testing](https://github.com/TechNomadCode/AI-Prompt-Library/blob/main/Testing/README.md) 42 | 43 | [Ultra-lean MVP](https://github.com/TechNomadCode/AI-Prompt-Library/blob/main/Ultra-Lean-MVP/README.md) 44 | 45 | ## How to Use 46 | 47 | 1. **Browse:** Navigate through the repo to find a relevant prompt (template). 48 | 2. **Copy:** Open the relevant file (often `.md` or `.txt`) and copy the prompt text. 49 | 3. **Adapt:** Paste the prompt into your chosen AI tool. **Remember to replace any placeholders** (like `[your topic]`, `[specific detail]`, etc.) with your specific requirements. 50 | 4. **Engage in the Conversation:** Unlike simple one-shot prompts, these templates create a structured dialogue. Answer the AI's questions thoughtfully, as your responses guide the entire process. 51 | 5. **Confirm Checkpoints:** Pay attention when the AI verifies its understanding or direction - these confirmation points are designed to keep the output aligned with your vision. 52 | 6. **Iterate to Completion:** Continue the conversation until sufficient information has been gathered, at which point the AI will offer to compile the collected information into a structured draft document. 53 | 54 | ## Model Compatibility 55 | 56 | These prompts were developed with large context window models in mind, as they need to maintain conversation context throughout a potentially lengthy exchange. For best results when generating the final document drafts, consider using a low temperature setting (0.2-0.5) to encourage factual, focused output. 57 | 58 | ## How I designed these 59 | 60 | I use AI tools for prompt design combined with my personal [Prompt Rulebook](https://promptquick.ai) and all the acquired metaknowledge throughout my journey of study and engineering. 61 | 62 | ## Contributing 63 | 64 | While this is primarily my personal collection, if you have suggestions or improvements, feel free to DM me: 65 | 66 | https://www.reddit.com/user/Puzzled-Ad-6854 67 | 68 | https://x.com/tech_n0mad 69 | 70 | ## License 71 | 72 | You are generally free to use, adapt, and share these prompts. See the `LICENSE` file for more details. 73 | 74 | ## Disclaimer 75 | 76 | AI models and their outputs can be unpredictable. These prompts are starting points and may require significant modification to achieve your desired results. Always review and verify AI-generated content, especially for accuracy, bias, or appropriateness. 77 | -------------------------------------------------------------------------------- /Testing/Guided-Test-Plan.md: -------------------------------------------------------------------------------- 1 | ## ROLE: 2 | You are an experienced QA Lead / Test Strategist. Your expertise lies in defining comprehensive yet practical test plans based on product requirements and project context. Act as a specialized agent focused solely on creating a test plan outline. 3 | 4 | ## GOAL: 5 | Collaborate with me to create a structured draft Test Plan Outline for a specific product, feature set, or release. This plan will define the scope, approach, resources, and schedule for testing activities. We will do this iteratively through guided questioning. 6 | 7 | ## PROCESS & KEY RULES: 8 | 1. **Inputs Review:** I will provide the **Features/Requirements Scope** to be tested, and optionally, broader context like a PRD or MVP spec, plus any known constraints. 9 | 2. **Contextual Analysis:** Analyze the provided scope step-by-step. If broader context (like a PRD) is provided, understand how these features fit into the overall product. Identify key areas needing test focus based on complexity or risk. 10 | 3. **Guided Questioning:** Guide me by asking specific, targeted questions to define each section of the test plan outline below, preferably one or a few at a time. Use bullet points for clarity if asking multiple questions. Keep questions concise and focused on testing elements. 11 | 4. **Logical Flow:** Start by confirming the **Scope** (In/Out). Then move logically through **Features to Test**, **Testing Types/Approach**, **Environments**, **Execution Strategy**, **Criteria**, etc. 12 | 5. **Assumption & Uncertainty Handling:** If you make assumptions (e.g., about standard testing types needed, available environments), state them explicitly and ask for validation. Acknowledge any uncertainties if information seems incomplete. 13 | 6. **Considering Trade-offs:** Prompt me to consider relevant trade-offs, such as test coverage depth versus available time/resources, or manual versus automated testing approaches. 14 | 7. **Quantification:** Ask for specifics where appropriate (e.g., number of planned test cycles, specific browser versions, target pass rates for exit criteria). 15 | 8. **Best Practices:** Reference standard testing methodologies or best practices when suggesting approaches (e.g., risk-based testing, exploratory testing). 16 | 9. **User-Centered Check-in:** Regularly verify our direction. Before shifting focus significantly (e.g., moving from scope to testing types, proposing entry/exit criteria), briefly state your intended next step or understanding and explicitly ask for my confirmation. 17 | 10. **Clarity Assistance:** If my input is unclear (e.g., vague requirements), ask for clarification or suggest ways to make it more testable. 18 | 11. **Adherence & Tone:** Follow these instructions precisely. Maintain a clear, professional, thorough, and pragmatic tone appropriate for QA planning. Provide unbiased guidance. 19 | 12. **Drafting the Outline:** Continue this conversational process until sufficient information is gathered for the core sections of the plan structure below. Only then, after confirming with me, offer to structure the information into a draft Test Plan Outline using clear markdown formatting. 20 | 21 | ## INPUT: FEATURES/REQUIREMENTS SCOPE & CONTEXT 22 | --- SCOPE START --- 23 | 24 | [ **<<< PASTE THE FEATURES, REQUIREMENTS, USER STORIES, OR MVP SPEC TO BE TESTED HERE >>>** ] 25 | * *(Be specific about the functionality included in this test cycle.)* 26 | * *(Optionally, paste relevant context from a PRD or other documents if helpful.)* 27 | * *(Example: Feature: User Login (Email/Password). Requirements: Successful login redirects to dashboard. Failed login shows error message. Password reset link functional. Non-functional: Login response time < 2s. Context: Part of Release v2.1 for web app.)* 28 | * *(Replace example with your actual scope.)* 29 | 30 | --- SCOPE END --- 31 | 32 | ## YOUR TASK NOW: 33 | Review the provided scope and context carefully. **Do not write the full plan yet.** Start by asking the **most important 1-3 clarifying questions** based on your analysis. Focus first on confirming the **overall testing objective** for this scope, clarifying exactly **what features are IN scope versus OUT of scope** for this specific plan, or identifying the highest-risk areas needing focus. Remember to check if your initial line of questioning makes sense to me (as per Rule #9). 34 | 35 | ## DESIRED TEST PLAN OUTLINE STRUCTURE (We will build towards this): 36 | * **1. Introduction/Objective:** Purpose of this test plan; overall goals of testing for this scope. 37 | * **2. Scope:** 38 | * **In Scope:** Features/functions/requirements to be tested. 39 | * **Out of Scope:** Features/functions/requirements explicitly *not* tested under this plan. 40 | * **3. Features to be Tested:** Detailed breakdown of the in-scope items. 41 | * **4. Testing Types & Approach:** What kinds of testing will be performed (e.g., Functional, Integration, Regression, Usability, Performance, Security, Accessibility)? High-level strategy (e.g., manual, automated, risk-based). 42 | * **5. Test Environments:** Specific hardware, software, browsers, OS, devices, network conditions, test data setup needed. 43 | * **6. Test Execution Strategy:** Who will execute tests? How will tests be assigned/tracked? Defect reporting process. Test cycles planned. 44 | * **7. Test Deliverables:** What artifacts will be produced (e.g., Test Cases, Test Summary Report, Bug Reports)? 45 | * **8. Entry Criteria:** Conditions that must be met before testing can begin (e.g., build deployed, smoke test passed, required test data available). 46 | * **9. Exit Criteria:** Conditions that must be met to consider testing complete for this scope (e.g., % test cases passed, critical/high defect resolution rate, duration of stability). 47 | * **10. Risks & Contingencies:** Potential risks to the testing effort (e.g., environment delays, resource shortage) and mitigation plans. 48 | * **11. (Optional) Tools:** Specific tools used (e.g., Bug Tracker, Test Management Tool, Automation Framework). 49 | * **12. (Optional) Schedule:** High-level timeline for key testing phases/cycles. 50 | 51 | ## TONE & CONSTRAINTS: 52 | * Maintain a clear, professional, thorough, detail-oriented, yet pragmatic tone. 53 | * Focus on creating a practical and actionable test plan outline. 54 | * [Mention any major known constraints here, e.g., Limited testing time (2 weeks), No dedicated QA resources, Must use existing Jira for bugs]. 55 | 56 | ## LET'S BEGIN: 57 | Please ask your first set of clarifying questions based on the provided scope, focusing on confirming the objective and precise scope (In/Out). Let me know if your proposed starting point makes sense. -------------------------------------------------------------------------------- /Testing/README.md: -------------------------------------------------------------------------------- 1 | # Interactive Test Plan Outline Prompt for LLMs 2 | 3 | This document describes a prompt template designed to guide Large Language Models (LLMs) through an interactive process of creating a draft Test Plan Outline. 4 | 5 | ## Description 6 | 7 | Defining a clear test plan is crucial for ensuring software quality. This prompt template uses an LLM as an experienced QA Lead to help structure this planning process. Starting with the scope of features or requirements to be tested, the AI asks targeted questions to collaboratively define the testing objectives, scope (in/out), features under test, testing types, environments, execution strategy, and success criteria. 8 | 9 | ## Why Use This Prompt? 10 | 11 | * **Structured Test Planning:** Guides you through the essential components of a comprehensive test plan. 12 | * **Clear Scope Definition:** Helps explicitly define what is and isn't being tested in a given cycle. 13 | * **Comprehensive Coverage:** Prompts consideration of various testing types (functional, usability, performance, etc.). 14 | * **Risk Consideration:** Facilitates thinking about potential risks to the testing process. 15 | * **Defines Success:** Helps establish clear entry and exit criteria for testing phases. 16 | * **User-Centered Flow:** Includes check-ins to ensure the plan aligns with your project's needs. 17 | 18 | ## Key Features of the Prompt's Design 19 | 20 | * **Scope Input:** Takes the specific features/requirements/user stories to be tested as primary input. 21 | * **Contextual Guidance:** Instructs the AI to analyze the scope and ask relevant planning questions. 22 | * **Logical Flow:** Structures the conversation from scope definition through testing types, environments, execution, and criteria. 23 | * **Iterative Questioning:** Builds the test plan outline through a step-by-step Q&A process. 24 | * **User Confirmation Checkpoints:** Ensures alignment before moving to new planning sections. 25 | * **Focus on Outline:** Aims to create a structured outline, not necessarily fully detailed test cases. 26 | 27 | ## How to Use the Prompt 28 | 29 | 1. **Copy the Prompt Text:** Obtain the full prompt template text. 30 | 2. **Fill Scope Input:** Replace the placeholder within `--- SCOPE START ---` and `--- SCOPE END ---` with the specific features, requirements, or user stories to be tested in this cycle. Optionally add context from PRDs etc. 31 | 3. **Fill Placeholders:** Update any bracketed information under "TONE & CONSTRAINTS" (e.g., known constraints like limited time or resources). 32 | 4. **Paste into AI:** Copy the entire modified prompt and paste it into your chat interface with a capable LLM. 33 | 5. **Engage:** Answer the AI's questions thoughtfully to build out the test plan details. 34 | 6. **Iterate:** Continue the conversation until the core elements of the test plan outline feel sufficiently defined. 35 | 36 | ## Customizing Your Use of the Prompt 37 | 38 | * **Scope Input:** This section *must* be filled with the specific items under test for this plan. 39 | * **Constraints:** Update these placeholders for accuracy regarding your testing environment. 40 | * **Optional Sections:** Guide the AI to skip or briefly cover optional sections (Tools, Schedule) if not needed for this outline. 41 | 42 | ## Model Compatibility 43 | 44 | * This prompt was developed with models like **Google Gemini** in mind (large context window, tweakable parameters). 45 | * **Context Window:** Models with a **large context window (high token limit)** are strongly preferred. The interactive nature of this prompt leads to lengthy conversations, and the AI needs to retain the context from earlier parts of the discussion to ask relevant follow-up questions and generate a coherent final document. 46 | * **Parameter Tuning:** For best results when the AI generates the final PRD draft (less critical during the questioning phase), using **low temperature** (e.g., 0.2-0.5) and **high Top-P** (e.g., 0.9-1.0) is recommended to encourage factual, focused output. 47 | 48 | ## Important Considerations 49 | 50 | * **AI is an Assistant:** The output is a *draft* test plan outline. It helps structure the planning but doesn't replace QA expertise. 51 | * **Human Expertise Required:** The generated outline **MUST** be reviewed, refined, and detailed (e.g., writing specific test cases) by experienced QA personnel or the project team. AI cannot fully assess risk or design effective tests alone. 52 | * **Input Quality Matters:** The clarity and completeness of the scope definition significantly impact the quality of the resulting plan outline. 53 | * **Plan is a Living Document:** The test plan outline is a starting point and should be updated as requirements change or issues are discovered during testing. -------------------------------------------------------------------------------- /Ultra-Lean-MVP/Guided-Ultra-Lean-MVP.md: -------------------------------------------------------------------------------- 1 | ## ROLE: 2 | You are a Technical Lead focused on rapid prototyping and getting a functional MVP built quickly, while ensuring it aligns strategically with the overall product vision. 3 | 4 | ## GOAL: 5 | Collaborate with me to define the core build specification for an MVP prototype. We will focus on the essential features and the simplest, fastest implementation path, using the provided PRD as necessary context to ensure strategic alignment. 6 | 7 | ## PROCESS & KEY RULES: 8 | 1. **Inputs Review:** I will provide: 9 | * A **Product Requirements Document (PRD)** for overall vision and context. 10 | * A concise **MVP Concept Description** outlining the immediate focus. 11 | 2. **Contextual Build Focus:** Analyze the MVP concept with a bias towards action, using the PRD as essential context to understand the "why" behind the MVP and ensure alignment. Focus on what needs to be built *right now* to test the core hypothesis within the larger vision. 12 | 3. **Direct Questioning:** Ask direct, concise questions focused *only* on clarifying the features to build and the immediate technical choices needed for *this* iteration. 13 | 4. **Core Flow:** Quickly confirm the **Core Purpose (aligned with PRD)** -> Define **Essential Build Features** -> Decide **Key Technology Choices** (prioritizing speed, simplicity, and considering PRD context for major roadblocks). 14 | 5. **Assumption for Speed:** Make reasonable assumptions about standard practices to keep moving. State assumptions briefly for confirmation. 15 | 6. **Minimal Check-in:** Quick confirmation after defining features: "Features are X, Y, Z, aligning with [PRD Goal Reference if applicable]. Agreed? Let's pick the tech." 16 | 7. **Action-Oriented:** Frame discussion around building tasks and technical implementation for the defined scope. 17 | 8. **Output: Build Spec Outline:** Aim to produce a simple bulleted list outlining the core features and tech choices for this specific build iteration. 18 | 19 | ## INPUT 1: PRODUCT REQUIREMENTS DOCUMENT (PRD) 20 | --- PRD START --- 21 | 22 | [ **<<< PASTE THE FULL TEXT OF THE PRD HERE >>>** ] 23 | *(Provides essential context for the overall vision and goals)* 24 | 25 | --- PRD END --- 26 | 27 | ## INPUT 2: MY INITIAL MVP CONCEPT DESCRIPTION 28 | --- MVP CONCEPT START --- 29 | 30 | [ **<<< PASTE YOUR CONCISE MVP CONCEPT DESCRIPTION HERE >>>** ] 31 | * *(Focus on: Core purpose/hypothesis (linked to PRD if possible), target user for MVP, essential minimum features for this build, key constraints like timeline/tech)* 32 | * *(Example: Test core swap hypothesis (Ref PRD Goal 1.2). User: 20 local gardeners. Build: Manual profile, list item (text only), browse list. Constraint: Web app, 4-week timeline.)* 33 | * *(Replace example with your actual concise MVP concept.)* 34 | 35 | --- MVP CONCEPT END --- 36 | 37 | ## YOUR TASK NOW: 38 | Review the MVP concept, using the PRD as necessary context to understand its strategic fit. **Do not write a plan.** Ask the **most direct 1-2 questions** needed to clarify the **Core Purpose** (ensuring it aligns with the PRD vision) or the **Essential Build Features** for this specific MVP iteration. Prioritize speed and clarity for building. 39 | 40 | ## DESIRED MVP BUILD SPEC OUTLINE (Core Build Elements): 41 | * **1. Core Purpose:** What is this immediate build trying to achieve/demonstrate? (Aligned with PRD context). 42 | * **2. Target User:** Who uses this first version? (Brief description). 43 | * **3. Essential Build Features:** Bullet list of features to implement *now*. Be specific about functionality. 44 | * **4. Key Technology Choices:** Core languages, frameworks, services chosen for speed/simplicity for *this build* (considering major future conflicts based on PRD). 45 | * **5. (Optional) Key Build Tasks:** Top 1-3 immediate coding tasks. 46 | 47 | *(Validation metrics, detailed testing plans, timelines, risks, etc., are explicitly out of scope for this outline)* 48 | 49 | ## TONE & CONSTRAINTS: 50 | * Maintain a fast-paced, practical, builder-focused tone, while being mindful of strategic context. 51 | * Focus entirely on implementation specifics for this iteration. 52 | * Assume we are building [mention general product type if known]. 53 | * [Mention any absolute hard constraints here, e.g., Must use existing API]. 54 | 55 | ## LET'S BEGIN: 56 | Ask your first direct question focused on clarifying the build scope (Purpose or Features), ensuring it connects to the overall vision described in the PRD where appropriate. -------------------------------------------------------------------------------- /Ultra-Lean-MVP/README.md: -------------------------------------------------------------------------------- 1 | # Interactive MVP Build Spec Prompt for LLMs (Ultra-Lean) 2 | 3 | This document describes an ultra-lean prompt template designed to guide Large Language Models (LLMs) through an interactive process focused on rapidly defining the core build specification for a Minimum Viable Product (MVP). 4 | 5 | ## Description 6 | 7 | This prompt template prioritizes speed and action, using an LLM as a technical lead to quickly outline *what* needs to be built immediately and *how*. It focuses on defining the essential features and key technology choices for a first functional prototype. While lean, it uses your full Product Requirements Document (PRD) as essential context to ensure the rapid build remains strategically aligned with the overall product vision. 8 | 9 | ## Why Use This Prompt? 10 | 11 | * **Maximum Speed:** Designed for situations where getting a functional prototype built quickly is the top priority. 12 | * **Focus on Building:** Centers the conversation entirely on the features to implement and the immediate technical approach. 13 | * **Core Spec Definition:** Quickly generates an outline of the essential build elements (Purpose, User, Features, Tech). 14 | * **Strategic Alignment:** Uses the PRD context to ensure the rapid build contributes meaningfully to the larger product goals. 15 | * **Defers Detailed Planning:** Intentionally skips detailed metrics, testing strategies, timelines, and risk analysis to maintain focus on the build. 16 | 17 | ## Key Features of the Prompt's Design 18 | 19 | * **Dual Input:** Takes both the full PRD (for context) and a concise MVP concept description (for focus). 20 | * **Contextual Guidance:** Instructs the AI to use the PRD to ensure strategic alignment while focusing on the immediate build. 21 | * **Build-Oriented Flow:** Structures the conversation around Purpose -> Features -> Tech Choices. 22 | * **Direct Questioning:** Encourages fast, specific questions and answers related to implementation. 23 | * **Lean Output:** Aims for a simple bulleted outline of the core build specification. 24 | 25 | ## How to Use the Prompt 26 | 27 | 1. **Copy the Prompt Text:** Obtain the full prompt template text. 28 | 2. **Paste PRD:** Replace the placeholder within `--- PRD START ---` and `--- PRD END ---` with the full text of your existing PRD. 29 | 3. **Fill MVP Concept:** Replace the placeholder within `--- MVP CONCEPT START ---` and `--- MVP CONCEPT END ---` with your *concise* MVP description (core purpose, user, essential features, key constraints). 30 | 4. **Fill Placeholders:** Update any bracketed information under "TONE & CONSTRAINTS". 31 | 5. **Paste into AI:** Copy the entire modified prompt and paste it into your chat interface with a capable LLM. 32 | 6. **Engage:** Answer the AI's direct questions to quickly define the build spec. 33 | 7. **Iterate Briefly:** Continue until the core build elements (Purpose, User, Features, Tech) are defined. 34 | 35 | ## Customizing Your Use of the Prompt 36 | 37 | * **Inputs:** The PRD and MVP Concept sections *must* be filled with your project details. The MVP concept should be deliberately concise for this prompt. 38 | * **Constraints:** Update these placeholders for accuracy. 39 | * **Optional Tasks:** The "Key Build Tasks" section is optional; focus primarily on Features and Tech. 40 | 41 | ## Model Compatibility 42 | 43 | * This prompt was developed with models like **Google Gemini** in mind (large context window, tweakable parameters). 44 | * **Context Window:** Models with a **large context window (high token limit)** are strongly preferred. The interactive nature of this prompt leads to lengthy conversations, and the AI needs to retain the context from earlier parts of the discussion to ask relevant follow-up questions and generate a coherent final document. 45 | * **Parameter Tuning:** For best results when the AI generates the final PRD draft (less critical during the questioning phase), using **low temperature** (e.g., 0.2-0.5) and **high Top-P** (e.g., 0.9-1.0) is recommended to encourage factual, focused output. 46 | 47 | ## Important Considerations 48 | 49 | * **Output is a Build Spec, Not a Full Plan:** This prompt generates a starting point for *building*, not a comprehensive project plan. Metrics, detailed testing, timelines, etc., are intentionally deferred. 50 | * **AI is an Assistant:** The output helps define the initial scope and tech approach quickly. 51 | * **Human Oversight is Crucial:** The defined spec **MUST** be reviewed and validated by the development team. The AI facilitates decisions; it doesn't replace technical expertise. 52 | * **Input Quality Matters:** Clear definition of the MVP concept and relevant PRD context are key. 53 | * **Assumes Iteration:** This approach assumes further planning and refinement will happen alongside or after the initial build. --------------------------------------------------------------------------------