mirror of
https://github.com/TechNomadCode/AI-Product-Development-Toolkit.git
synced 2026-10-20 08:39:44 +02:00
v0 Design Prompt Template
This commit is contained in:
TechNomadCode
@@ -0,0 +1,75 @@
|
||||
# AI-Powered Frontend Design & Integration Workflow Prompts
|
||||
|
||||
This document describes a set of interconnected prompt templates designed to streamline the process of generating modern frontend designs using AI (specifically targeting `v0.dev`) and integrating those designs into projects, including complex design overhauls of existing codebases.
|
||||
|
||||
## Overview
|
||||
|
||||
This workflow utilizes three core prompt templates to manage different stages of the design and integration process:
|
||||
|
||||
1. **Visual Generation Prompt (`v0.dev-visual-generation-prompt.md`):** A detailed, structured template defining the desired aesthetics, layout, components, and styling for a landing page. This is the template ultimately fed to `v0.dev` to generate the visual code.
|
||||
2. **Prompt Filler (`v0.dev-visual-generation-prompt-filler.md`):** An interactive, user-centered prompt used with a general LLM. It guides the user through a Q&A process to translate their unstructured ideas (text, image references, existing code analysis) into a fully populated *Visual Generation Prompt*.
|
||||
3. **Migration Prompt (`migration-prompt.md`):** A prompt designed for an AI-assisted coding environment (like Cursor) or a capable LLM with code context. It guides the AI to analyze an existing codebase and the newly generated design code, then suggests or applies the necessary changes to integrate the new design while preserving existing logic.
|
||||
|
||||
These prompts enable two primary workflows: creating a design from scratch and performing a design overhaul.
|
||||
|
||||
## The Prompt Templates
|
||||
|
||||
* **`v0.dev-visual-generation-prompt.md`:**
|
||||
* **Purpose:** Defines the detailed visual and structural requirements for `v0.dev`. Contains MODULES for theme, layout, color, typography, etc.
|
||||
* **Usage:** Filled out (usually via the Prompt Filler) and then used directly as input for `v0.dev`.
|
||||
* **`v0.dev-visual-generation-prompt-filler.md`:**
|
||||
* **Purpose:** Interactively guides a user to fill out the `v0.dev-visual-generation-prompt.md` template based on their ideas. Includes optional codebase analysis for overhauls.
|
||||
* **Usage:** Used with a general LLM. Requires the blank `v0.dev-visual-generation-prompt.md` as an attachment and user's ideas/codebase as input. Outputs the filled-in `v0.dev-visual-generation-prompt.md`.
|
||||
* **`migration-prompt.md`:**
|
||||
* **Purpose:** Guides an AI (ideally in an IDE like Cursor) to integrate the new design code (from `v0.dev`) into an existing codebase.
|
||||
* **Usage:** Used with an AI that has access to both the original codebase and the new design code. Guides the AI through analysis, prop mapping, and suggesting/applying integration changes.
|
||||
|
||||
## Workflows
|
||||
|
||||
### Workflow 1: Generating a New Design From Scratch
|
||||
|
||||
Use this when you don't have an existing frontend codebase to overhaul.
|
||||
|
||||
1. **Prepare:** Have your initial design ideas, desired mood, and any visual references ready.
|
||||
2. **Use the Prompt Filler:** Start a session with a capable LLM using the `v0.dev-visual-generation-prompt-filler.md` template.
|
||||
3. **Attach Blank Template:** Provide the *blank* `v0.dev-visual-generation-prompt.md` file as Attachment 1.
|
||||
4. **Provide Ideas:** Paste your initial design ideas/brain dump into Input 1 of the Prompt Filler. Indicate that no existing codebase is provided (leave Input 2 empty).
|
||||
5. **Interactive Session:** Engage with the AI in the module-by-module Q&A session to define the aesthetics, layout, colors, typography, etc.
|
||||
6. **Receive Filled Prompt:** The AI will output the fully filled-in `v0.dev-visual-generation-prompt.md`.
|
||||
7. **Generate Design:** Copy the filled-in prompt and use it as input for `v0.dev`.
|
||||
8. **Integrate Manually:** Review the code generated by `v0.dev` and integrate it into your new project structure manually. The `migration-prompt.md` is generally not needed for a completely new project.
|
||||
|
||||
### Workflow 2: Overhauling an Existing Design
|
||||
|
||||
Use this when you want to apply a new visual style to an existing frontend codebase.
|
||||
|
||||
1. **Prepare Codebase:** Run the provided PowerShell script on your existing project directory to generate the `output.txt` file containing your filtered codebase structure and content.
|
||||
2. **Prepare New Vision:** Have your ideas for the *new* design, desired mood, and any visual references ready.
|
||||
3. **Use the Prompt Filler:** Start a session with a capable LLM using the `v0.dev-visual-generation-prompt-filler.md` template (the version supporting codebase analysis).
|
||||
4. **Attach Blank Template:** Provide the *blank* `v0.dev-visual-generation-prompt.md` file as Attachment 1.
|
||||
5. **Provide New Ideas:** Paste your *new* design ideas/brain dump into Input 1 of the Prompt Filler.
|
||||
6. **Provide Existing Code:** Paste the content of `output.txt` into Input 2 OR provide `output.txt` as Attachment 2.
|
||||
7. **Codebase Analysis:** The AI will first analyze the existing code structure, potentially generate a Mermaid diagram, and ask for your confirmation.
|
||||
8. **Interactive Session:** Engage with the AI in the module-by-module Q&A session to define the *new* aesthetics, layout, etc., often referencing the existing structure identified in the analysis.
|
||||
9. **Receive Filled Prompt:** The AI will output the fully filled-in `v0.dev-visual-generation-prompt.md`, tailored for the overhaul.
|
||||
10. **Generate New Design:** Copy the filled-in prompt and use it as input for `v0.dev` to generate the *new* visual components.
|
||||
11. **Prepare for Migration:** Have your original project open (ideally in an AI-assisted IDE like Cursor) and the code generated by `v0.dev` readily available (e.g., copied or in temporary files).
|
||||
12. **Use the Migration Prompt:** In your IDE's AI chat (or with an LLM having context), use the `migration-prompt.md` template.
|
||||
13. **Provide Context:** Ensure the AI has access to your **original codebase** (inherent in Cursor, or provide `output.txt` again) and the **new design code** generated in Step 10.
|
||||
14. **Execute Migration:** Follow the steps guided by the Migration Prompt AI: confirm component replacements, review prop mappings, and review/apply the suggested code changes or instructions.
|
||||
15. **Review & Refine:** Thoroughly review the integrated code, test functionality, and manually refine any areas where the AI integration wasn't perfect.
|
||||
|
||||
## Model Compatibility
|
||||
|
||||
* **Prompt Filler & Migration Prompt:** Designed for advanced conversational LLMs (e.g., Gemini Advanced, GPT-4, Claude 3) capable of following complex instructions and analyzing code/text.
|
||||
* **Visual Generation Prompt:** Specifically designed as input for `v0.dev`.
|
||||
* **Context Window:** Models with a **large context window (high token limit)** are strongly recommended, especially for the Prompt Filler (when analyzing code) and the Migration Prompt, due to the need to process potentially large amounts of code context.
|
||||
* **Parameter Tuning:** When using the filled Visual Generation Prompt with `v0.dev`, its default parameters are usually appropriate. For the Prompt Filler and Migration prompts, standard conversational parameters generally work well.
|
||||
|
||||
## Important Considerations
|
||||
|
||||
* **AI is an Assistant:** These prompts facilitate and accelerate the process, but the output (both the filled prompt and the generated/migrated code) requires human oversight and judgment.
|
||||
* **CRITICAL Human Review Required:** Generated designs and especially migrated code **MUST** be thoroughly reviewed, tested, and validated by developers. AI can make mistakes in interpretation, prop mapping, or integration logic.
|
||||
* **Input Quality Matters:** The clarity and detail provided in your initial brain dumps and during the interactive sessions significantly impact the quality of the results.
|
||||
* **Iterative Process:** Expect some level of refinement. The goal is to get a strong starting point or accelerate a complex task, not necessarily a perfect, final result in one shot.
|
||||
* **Backup Your Code:** Always work with version control (like Git) and ensure you have backups before applying significant AI-generated code changes, especially during migration.
|
||||
@@ -0,0 +1,71 @@
|
||||
## ROLE:
|
||||
You are an expert Frontend Engineer specializing in code integration and refactoring within Next.js applications. Your task is to meticulously integrate a new set of visual components (generated by `v0.dev`) into an existing codebase, replacing the old UI while preserving the original application logic and functionality.
|
||||
|
||||
## GOAL:
|
||||
To analyze the existing codebase structure and the new design components, and then provide clear, actionable instructions or code modifications required to replace the old UI components with the new ones throughout the application, ensuring correct prop mapping and minimal disruption to existing functionality.
|
||||
|
||||
## CONTEXT / INPUTS (Assumed Available to You):
|
||||
1. **Existing Codebase Context:** You have full access to the structure and content of the original application codebase (as represented previously, e.g., in `output.txt`).
|
||||
2. **New Design Code Context:** You have full access to the structure and content of the new landing page design components generated by `v0.dev` (e.g., from a hypothetical `new_design_output.txt` or similar context provided).
|
||||
|
||||
## CORE TASK & STRATEGY:
|
||||
|
||||
1. **Analyze Structures:** Compare the component structure of the **Existing Codebase** with the **New Design Code**. Identify corresponding components (e.g., `Existing: src/components/layout/Header.tsx` vs. `New Design: components/layout/header.tsx`).
|
||||
2. **Identify Replacements:** Determine which components in the Existing Codebase need to be replaced by components from the New Design Code to achieve the visual overhaul. Focus primarily on components responsible for UI presentation (layout, sections, common UI elements).
|
||||
3. **Map Props:** For each component replacement identified:
|
||||
* Analyze the props accepted by the **New Design** component.
|
||||
* Analyze the props *currently being passed* to the **Old Component** where it's used in the Existing Codebase (e.g., in `page.tsx`, `layout.tsx`, or other components).
|
||||
* Determine the correct mapping from the old props/data to the new component's props.
|
||||
4. **Preserve Logic:** **Crucially, identify and preserve all existing application logic.** This includes:
|
||||
* State management (`useState`, `useReducer`, context, external libraries).
|
||||
* Data fetching logic.
|
||||
* Event handlers (unless they were purely for old UI elements being removed).
|
||||
* Server Actions or API route interactions.
|
||||
* Any other non-presentational code within parent components or hooks.
|
||||
* The goal is to swap the "skin" (UI components) without breaking the "bones" (logic).
|
||||
5. **Handle Discrepancies & New Needs:**
|
||||
* If a New Design component requires props that don't directly map from the old one or aren't readily available in the existing parent component's scope, **flag this clearly**. Suggest where the data might come from or indicate that new logic/data fetching might be required (as a TODO for the human developer).
|
||||
* If a New Design component introduces new dependencies (e.g., a specific context provider), note this requirement.
|
||||
* If `'use client'` directives differ, ensure the final integrated component uses the directive required by the *new* component's implementation (if it contains hooks or event handlers). Prioritize the new component's requirement.
|
||||
6. **Generate Integration Steps/Code:** Based on the analysis, provide the necessary modifications.
|
||||
|
||||
## KEY PRINCIPLES & CONSTRAINTS:
|
||||
|
||||
* **Preserve Functionality:** Do NOT alter existing business logic, data flow, or state management unless *absolutely necessary* to accommodate a new component's basic prop requirements.
|
||||
* **Prioritize New Design:** The visual appearance should match the New Design Code. Styles from the new components should take precedence.
|
||||
* **Accurate Prop Mapping:** Ensure data flows correctly to the new components via props.
|
||||
* **Clear Instructions:** If providing instructions instead of direct code edits, be precise about which files to modify, which lines to change, and how props should be mapped.
|
||||
* **Flag Issues:** Clearly identify any integration challenges, missing data/props, or potential conflicts that require human intervention. Use comments like `// TODO: [Description of issue]` in code suggestions.
|
||||
* **Assume File Availability:** Assume all necessary files from both the old and new codebases are accessible for analysis and modification.
|
||||
|
||||
## OUTPUT FORMAT:
|
||||
|
||||
Present the integration steps clearly. Choose ONE of the following formats, or combine where appropriate:
|
||||
|
||||
* **Option A (Preferred if supported): Modification Components (e.g., `<QuickEdit>`, `<DeleteFile>`, `<MoveFile>`)**
|
||||
* Use modification components to specify exact changes file-by-file (imports, component usage, prop adjustments). This is the most direct approach if the AI platform supports it well for complex changes.
|
||||
* **Option B: File-by-File Instructions:**
|
||||
* For each file in the **Existing Codebase** that needs changes:
|
||||
* Specify the file path.
|
||||
* Clearly state the required modifications:
|
||||
* "Replace import `X` with `Y`."
|
||||
* "In component `Z`, replace `<OldComponent prop1={data} />` with `<NewComponent newPropA={data} newPropB='default' />`."
|
||||
* "Add prop `newPropC={value}` to the `<NewComponent />` instance."
|
||||
* "Remove lines X-Y containing the old component."
|
||||
* **Option C: Full Modified Files:**
|
||||
* Provide the complete content of the modified files from the **Existing Codebase**, incorporating the New Design components and necessary prop adjustments. Use this sparingly, primarily for files with significant changes (like `page.tsx` or `layout.tsx`).
|
||||
|
||||
**Regardless of format, clearly highlight:**
|
||||
* Any props that couldn't be mapped automatically.
|
||||
* Any new data requirements for the new components.
|
||||
* Any potential conflicts or areas needing manual review.
|
||||
|
||||
## YOUR TASK NOW:
|
||||
|
||||
1. Confirm you have context for both the **Existing Codebase** and the **New Design Code**.
|
||||
2. Perform the **Analysis** (Step 1) and **Identify Replacements** (Step 2) described in the CORE TASK & STRATEGY.
|
||||
3. **Report your findings:** List the key components identified for replacement (e.g., "Plan to replace `src/components/layout/Header.tsx` with `components/layout/header.tsx` from the new design").
|
||||
4. **Ask for confirmation** to proceed with detailed prop mapping and generating the integration steps/code modifications for the identified components.
|
||||
|
||||
## LET'S BEGIN:
|
||||
Please confirm context access, report the identified component replacements, and await confirmation to proceed.
|
||||
@@ -0,0 +1,51 @@
|
||||
## ROLE:
|
||||
You are an expert AI Prompt Engineer and Design Consultant. Your primary skill is asking insightful questions to help me translate my visual ideas into a structured, detailed prompt suitable for `v0.dev`. Act as a specialized agent focused solely on this prompt co-creation task.
|
||||
|
||||
## GOAL:
|
||||
Collaborate with me to meticulously fill in the target `v0.dev-visual-generation-prompt` template, which **I have provided as an attached file**. We will achieve this based on my initial ideas (Input 1) through an iterative, module-by-module Q&A process, ensuring the final prompt accurately reflects my desired aesthetic vision and is optimized for `v0.dev`.
|
||||
|
||||
## PROCESS & KEY RULES:
|
||||
1. **Inputs Review:** I will provide:
|
||||
* **Input 1:** My initial brain dump, descriptions, or image references for the design.
|
||||
* **Attachment:** The target `v0.dev-visual-generation-prompt` template file (containing MODULES 1-10). **Refer to this attached file for the structure and placeholders we need to fill.**
|
||||
2. **Initial Analysis:** Analyze my initial input (Input 1) step-by-step to grasp the overall direction and identify key themes or specific requests (**Rule: Step-by-Step Reasoning Rule**).
|
||||
3. **Module-by-Module Guidance:** Guide me through filling the target template (from the **attached file**) **one module at a time**, starting with Module 1. Refer explicitly to the module number and name from the attached template when asking questions.
|
||||
4. **Targeted Questioning:** For the current module (referencing the attached template), ask specific, concise questions aimed at eliciting the details needed to fill its `[...]` placeholders (**Rule: Concise Response Rule**). Use bullet points for clarity if asking multiple related questions (**Rule: Bullet Point Rule**). Anticipate likely follow-up details needed within that module (**Rule: Follow-Up Anticipation Rule**).
|
||||
5. **Interpretation & Suggestion:** Based on my answers:
|
||||
* Suggest concrete wording or options for the placeholders in the current module.
|
||||
* If my input is vague, ask clarifying questions or offer alternative interpretations/suggestions based on common design principles or the overall vibe discussed so far (**Rule: Prompt Refinement Rule**).
|
||||
* Explicitly state any assumptions you make based on my input and ask for validation (**Rule: Assumption Validation Rule**).
|
||||
* Acknowledge any uncertainties if information seems incomplete for a specific placeholder (**Rule: Uncertainty Acknowledgment Rule**).
|
||||
6. **User-Centered Check-in:** **Crucially**, after discussing the details for a module and proposing how to fill its placeholders, **explicitly state your understanding and ask for my confirmation before proceeding to the next module.** Use phrases like: "Okay, for Module [X] from the template file, we've defined [key details]. Does that accurately capture your intent? Shall we move on to Module [Y]?"
|
||||
7. **Focus & Adherence:** Focus *only* on eliciting information relevant to filling the target prompt template from the attached file (**Rule: Scope Limitation Rule**). Follow these instructions precisely and provide unbiased, helpful guidance (**Rule: Strict Adherence Rule, Avoid Bias Rule**).
|
||||
8. **Tracking Progress:** Internally track the confirmed details for each module corresponding to the attached template structure.
|
||||
9. **Final Output Generation:** Once we have collaboratively discussed and **confirmed** the details for **all** relevant modules from the attached template, offer to compile and output the complete, filled-in `v0.dev-visual-generation-prompt` based *only* on our confirmed discussion points. Use clear formatting for the final output (**Rule: Markdown Formatting Rule**).
|
||||
|
||||
---
|
||||
|
||||
## INPUT 1: My Initial Design Ideas / Brain Dump
|
||||
--- USER INPUT START ---
|
||||
|
||||
[ **<<< PASTE your initial brain dump text, descriptions of desired style, references to attached images, product name, etc. HERE >>>** ]
|
||||
*(Example: "Need a landing page design for 'SynthWave AI'. It generates retro music. Should feel very 80s retro-futuristic, Tron/Blade Runner style. Neon on dark backgrounds. Sharp fonts. See attached 'moodboard.jpg'. The target prompt template is in the attached 'v0_landing_page_template.md' file.")*
|
||||
|
||||
--- USER INPUT END ---
|
||||
|
||||
---
|
||||
|
||||
## YOUR TASK NOW:
|
||||
Access and review the **attached `v0.dev-visual-generation-prompt` template file**. Then, review my initial ideas in Input 1 carefully, applying the rules outlined in the PROCESS section. **Do not attempt to fill the template yet.** Start by asking me the **most important 1-3 clarifying questions** focused *only* on **Module 1: Overall Theme & Mood** (as defined in the attached template file). Use my initial input as a starting point. Remember to explicitly ask for confirmation before suggesting we move to Module 2 (as per Rule #6).
|
||||
|
||||
## TARGET TEMPLATE STRUCTURE (Refer to Attached File for Details):
|
||||
* MODULE 1: OVERALL THEME & MOOD
|
||||
* MODULE 2: LAYOUT & SPACING
|
||||
* ... (and so on for all modules in the attached file) ...
|
||||
* MODULE 10: TECHNICAL IMPLEMENTATION NOTES (For v0)
|
||||
* *(Also need Product Name, Audience, Value Prop for context section - elicit these early if not in Input 1)*
|
||||
|
||||
## TONE & CONSTRAINTS:
|
||||
* Maintain a clear, professional, inquisitive, collaborative, and helpful tone.
|
||||
* Focus on eliciting design preferences and translating them into prompt instructions based on the attached template structure.
|
||||
|
||||
## LET'S BEGIN:
|
||||
Please confirm you have accessed the attached template file, then ask your first set of clarifying questions for **Module 1: Overall Theme & Mood**.
|
||||
@@ -0,0 +1,102 @@
|
||||
## PRIMARY OBJECTIVE:
|
||||
Generate a visually striking, modern, and highly polished landing page **design**. Prioritize aesthetics, creative layout, sophisticated styling, and smooth micro-interactions. Structure the code with good **separation of concerns** to facilitate future development, even though functionality is secondary in this phase.
|
||||
|
||||
---
|
||||
|
||||
## MODULE 1: OVERALL THEME & MOOD
|
||||
* **Describe the core feeling:** `[e.g., "Minimalist & Sophisticated", "Futuristic & Techy", "Playful & Organic", "Luxurious & Premium", "Clean & Trustworthy"]`
|
||||
* **Visual Inspiration (Optional):** `[e.g., "linear.app dark gradients", "stripe.com whitespace", "brutalist web design elements"]`
|
||||
|
||||
---
|
||||
|
||||
## MODULE 2: LAYOUT & SPACING
|
||||
* **Layout Approach:** `[e.g., "Asymmetrical grid", "Standard centered content within full-width sections", "Heavy use of negative space", "Overlapping elements", "Broken grid"]`
|
||||
* **Section Separation:** `[e.g., "Clear visual dividers between sections", "Seamless transitions", "Use distinct background colors/textures per section"]`
|
||||
* **Content Width:** `[e.g., "Mostly contained width (max-w-screen-xl)", "Some full-bleed elements", "Edge-to-edge content"]`
|
||||
* **Spacing Scale (Whitespace):** `[e.g., "Generous whitespace (large padding/margins)", "Tight and compact", "Standard Tailwind spacing"]`
|
||||
|
||||
---
|
||||
|
||||
## MODULE 3: COLOR PALETTE
|
||||
* **Background (Base):** `[e.g., "#FFFFFF", "#1A1A1A (Dark)", "#F8F8F8 (Off-white)"]`
|
||||
* **Text (Base):** `[e.g., "#111827 (Near Black)", "#E5E7EB (Light Gray for dark mode)"]`
|
||||
* **Primary Accent / Brand Color:** `[e.g., "#3B82F6 (Blue)", "#EC4899 (Pink)", "Electric Blue (#00FFFF)"]` (Used for CTAs, highlights)
|
||||
* **Secondary Accent (Optional):** `[e.g., "#10B981 (Green)", "#F59E0B (Amber)"]` (Used for secondary buttons, tags, icons)
|
||||
* **Gradient Usage (Optional):** `[e.g., "Subtle gradients on buttons", "Hero background gradient from #FF00FF to #00FFFF", "No gradients"]`
|
||||
* *(Specify Hex/RGB/HSL codes for precision. Describe general usage if needed.)*
|
||||
|
||||
---
|
||||
|
||||
## MODULE 4: TYPOGRAPHY
|
||||
* **Headline Font:** `[e.g., "Geist Sans (Default)", "Serif (e.g., Playfair Display)", "Monospace (e.g., JetBrains Mono)"]`
|
||||
* **Headline Style:** `[e.g., "Bold weight", "Large size", "Uppercase", "Letter spacing: wide"]`
|
||||
* **Body Font:** `[e.g., "Geist Sans (Default)", "Clean Sans-Serif (e.g., Inter)"]`
|
||||
* **Body Style:** `[e.g., "Normal weight", "Readable size (text-base)", "Line height: relaxed"]`
|
||||
* **Hierarchy:** `[e.g., "Strong visual hierarchy using size and weight", "Minimalist hierarchy"]`
|
||||
|
||||
---
|
||||
|
||||
## MODULE 5: IMAGERY & ICONS
|
||||
* **Image Style:** Use placeholders (`/placeholder.svg?width={w}&height={h}`), but describe the intended style: `[e.g., "Abstract 3D renders", "Clean product screenshots in device mockups", "High-quality lifestyle photos", "Geometric patterns", "Gradients"]`
|
||||
* **Icon Style (lucide-react):** `[e.g., "Standard stroke width", "Thin stroke width (adjust via props/CSS if possible)", "Filled style (if applicable icons exist)", "Consistent size (e.g., size={20})"]`
|
||||
|
||||
---
|
||||
|
||||
## MODULE 6: INTERACTIVITY & ANIMATION (Visual Focus)
|
||||
* **Hover Effects:** `[e.g., "Subtle scale/brightness changes on cards/buttons", "Underline effects on links", "Color transitions"]`
|
||||
* **Scroll Animations:** `[e.g., "Gentle fade-in/slide-up for sections", "Subtle parallax on background elements", "No scroll animations"]`
|
||||
* **Button Interactions:** `[e.g., "Clear visual feedback on click (scale down/color change)"]`
|
||||
* **Loading States (Visual Only):** `[Optional: Describe visual placeholders if needed, e.g., "Skeleton loaders for cards"]`
|
||||
|
||||
---
|
||||
|
||||
## MODULE 7: FILE STRUCTURE & COMPONENT STRATEGY (Separation of Concerns)
|
||||
* **Goal:** Structure the code for maintainability and easier future integration with logic/data.
|
||||
* **Directory Structure:** Organize components logically within `components/`. Suggestion:
|
||||
* `components/layout/`: Header, Footer, PageWrapper, etc.
|
||||
* `components/sections/`: HeroSection, FeaturesSection, PricingSection, etc. (These compose smaller components).
|
||||
* `components/ui/`: (Implicitly for shadcn components).
|
||||
* `components/common/`: Small, reusable visual elements (e.g., CustomStyledButton, IconBadge, PricingCard).
|
||||
* **Component Granularity:** Break down large page sections (from Module 9) into smaller, focused **presentational components**. Example: A `PricingSection` should import a reusable `PricingCard` component defined in `components/common/`.
|
||||
* **Client Components:** Add `'use client'` directive *only* where essential for visual interactivity (e.g., mobile menu toggle, visual carousels, accordions). Keep structural components as Server Components where possible.
|
||||
* **Props:** Define clear `interface` or `type` for component props (even with placeholder data) to establish component contracts.
|
||||
|
||||
---
|
||||
|
||||
## MODULE 8: COMPONENT STYLING NOTES (Optional Specifics)
|
||||
* **Buttons (shadcn/ui):** `[e.g., "Sharp corners (no border-radius)", "Pill-shaped", "Gradient background", "Subtle shadow"]`
|
||||
* **Cards (shadcn/ui):** `[e.g., "No border, distinct background color", "Thin border", "Heavy shadow", "Glassmorphism effect (background blur)"]`
|
||||
* **Inputs (Placeholders):** `[e.g., "Minimalist underline style", "Standard bordered input"]`
|
||||
* **Accordion (shadcn/ui):** `[e.g., "Custom icons for open/close state", "No borders between items"]`
|
||||
* *(Add any other specific styling directions for base components)*
|
||||
|
||||
---
|
||||
|
||||
## MODULE 9: REQUIRED VISUAL SECTIONS (Implement Using Above Styles & Structure):
|
||||
Generate visually distinct components for each section below, following the structure strategy defined in Module 7. Ensure cohesive design based on Modules 1-6. Use placeholder text and links (`#`).
|
||||
|
||||
1. **Navigation Bar:** Design header (sticky/fixed) with Logo placeholder, Menu Link placeholders, styled Sign-Up Button. Design mobile trigger/layout.
|
||||
2. **Hero Section:** Design high-impact intro with styled Headline, Subheading, CTA Button(s), Image/Graphic placeholder, optional metric placeholders.
|
||||
3. **Social Proof Strip:** Design subtle or bold row of placeholder logos.
|
||||
4. **Features Representation:** Design engaging feature presentation with styled icons, titles, descriptions.
|
||||
5. **"How It Works" / Process Visualization:** Design visual 3-step process flow with styled icons/numbers, titles, text.
|
||||
6. **Integration/Showcase Visual:** Design section with styled integration logos OR product UI placeholder.
|
||||
7. **Pricing Tiers:** Design 3 distinct pricing cards with styled text, features, CTAs. Highlight one visually.
|
||||
8. **Testimonials Display:** Design elegant testimonial presentation. Mark as `'use client'` only if designing a visual carousel requiring JS.
|
||||
9. **FAQ Section:** Style the shadcn/ui Accordion (`'use client'` needed). Use placeholder Q&A.
|
||||
10. **Final CTA Section:** Design strong closing section with styled headline, prominent CTA button, optional email input placeholder.
|
||||
11. **Footer:** Design organized multi-column footer with placeholders.
|
||||
|
||||
---
|
||||
|
||||
## MODULE 10: TECHNICAL IMPLEMENTATION NOTES (For v0):
|
||||
* Generate within a single `<CodeProject id="[product-name]-visual-design-structured">`.
|
||||
* Use **Next.js App Router** structure (`app/page.tsx`, `app/layout.tsx`, `components/` subdirectories as per Module 7).
|
||||
* Use `tsx` files, kebab-case filenames.
|
||||
* Use **shadcn/ui** components as a base, style heavily via **Tailwind CSS**.
|
||||
* Use **`lucide-react`** for icons.
|
||||
* Implement **responsive design** visually.
|
||||
* Ensure basic **accessibility** structure (semantic HTML).
|
||||
* **Structure:** Follow the separation of concerns strategy outlined in Module 7 (directory structure, component granularity, `'use client'` placement, prop types).
|
||||
* Use placeholder data/links (`#`, `Lorem Ipsum`). **No functional logic needed.**
|
||||
* Use `import type` for type imports.
|
||||
Reference in New Issue
Block a user