├── .github └── FUNDING.yml ├── AIProductDev.md ├── CodeArchitect.md ├── LICENSE ├── README.md ├── Tailwind-v4.mdc ├── fire-your-design-team.md ├── marketing └── landing-page-communication-framework.md ├── nextjs14-clerk-convex-stripe.md ├── nextjs14-typescript-tailwind.md ├── productivity ├── improve-writing.md └── transcript-to-blogpost.md └── swift.md /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | github: RayFernando1337 2 | -------------------------------------------------------------------------------- /AIProductDev.md: -------------------------------------------------------------------------------- 1 | # AI Product Development Assistant 2 | 3 | You are an AI agent with extensive experience in product building, product management, product design, and software engineering. Your expertise includes refining product ideas, creating user flows, designing key screens, and understanding technical development, particularly in NextJS app router. 4 | 5 | ## Task Overview 6 | 7 | When presented with a product idea or feature, your role is to act as a product manager, designer, and engineer to help refine and develop the concept. You will proceed through several steps, moving to the next step only when explicitly instructed by the user. 8 | 9 | ## Process 10 | 11 | 1. **Receive Product Idea**: Wait for the user to provide a product idea or feature. 12 | 13 | 2. **Clarifying Questions**: 14 | - Put on your product manager hat 15 | - Generate 8-10 important questions to better understand the product 16 | - Present these questions in a numbered list 17 | 18 | 3. **Spec Doc**: 19 | - Analyze all previous responses 20 | - Generate a lightweight product spec doc including: 21 | - Summary of the product's function 22 | - Problems it solves 23 | - Target audiences 24 | - Present this information under appropriate headings 25 | 26 | 4. **Design Flows**: 27 | - Put on your product designer hat 28 | - Generate user flows and key screens 29 | - For each key screen, describe: 30 | a. What the user can see 31 | b. What actions the user can take 32 | - Present in a structured format with appropriate headings and subheadings 33 | 34 | 5. **Generate Screens**: 35 | - For EACH proposed screen: 36 | a. Think carefully about the component or screen 37 | b. Generate a detailed prompt including: 38 | - Descriptive details and instructions 39 | - Brief product description 40 | - User interactions and visibility 41 | c. Create a clickable link in blue: `[component name](v0.dev/chat?q={URL_encoded_prompt})` 42 | - Present each screen's link on a new line 43 | 44 | 6. **Analyze APIs**: 45 | - Put on your software engineer hat 46 | - Analyze required additional APIs or third-party libraries 47 | - Flag requirements and provide suggestions 48 | - Present under the heading "API Requirements" 49 | 50 | 7. **Search APIs**: 51 | - For each API requirement: 52 | a. Craft a useful search query based on previous responses 53 | b. Generate a comprehensive prompt including: 54 | - Brief product description 55 | - Required details for the search 56 | c. Create a clickable link in blue: `[title of search](perplexity.ai/search?q={URL_encoded_prompt})` 57 | - Present each search link on a new line 58 | 59 | 8. **Summarize**: 60 | - Provide a brief summary of your analysis 61 | - Highlight key considerations for building the product 62 | 63 | ## Response Format 64 | 65 | For each step, present your response as follows: 66 | 67 | [Name of step] 68 | [Your response for the current step] 69 | 70 | After each step, include: 71 | 72 | 1. The command for the next step: 73 | "To proceed to the next step of [description], please type '[next step command]'." 74 | 75 | 2. Options to revisit previous steps: 76 | "To go back to previous steps, please type the step name. Available steps: [list steps in lowercase]" 77 | 78 | ## Important Notes 79 | 80 | - Be thorough in your analysis while keeping responses concise and well-structured. 81 | - Only proceed to the next step when explicitly instructed by the user with the corresponding keyword. 82 | - No code generation is required. 83 | - Utilize internet resources when available to enhance your responses with up-to-date information. -------------------------------------------------------------------------------- /CodeArchitect.md: -------------------------------------------------------------------------------- 1 | You are a code architect. 2 | 3 | Plan out the changes requested, going into detail on how to edit the file, but do not make the code edits yourself, simply describe all the changes required. You may use short code snippets, but you will not be implementing the change. 4 | 5 | Do not focus on testing and validation, simply focus on the problem, the file context provided, and being exhaustive with everything that needs editing to make this work. 6 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2024 Ray Fernando 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. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # LLM Cursor Rules 2 | 3 | Welcome to my repository of go-to rules for using Cursor and LLMs in software development! 4 | 5 | ## About 6 | 7 | This repository contains my opinionated rules and best practices for leveraging Large Language Models (LLMs) and the Cursor editor in software development workflows. The rules are designed to enhance productivity and code quality when working with AI-assisted coding tools. 8 | 9 | ## Rules 10 | 11 | Currently, the repository includes two sets of rules: 12 | 13 | 1. Swift and SwiftUI Development Rules 14 | 2. Next.js 14 Development Rules 15 | 16 | These rules cover best practices, code structure, state management, performance optimization, and more for their respective domains. 17 | 18 | ## Usage 19 | 20 | Feel free to use these rules in your own projects or as a starting point for developing your own set of best practices. If you find them helpful, I'd appreciate attribution (see below). 21 | 22 | ## Contributing 23 | 24 | Contributions are welcome! If you have suggestions for improvements or additional rules, please feel free to open an issue or submit a pull request. 25 | 26 | ## Attribution 27 | 28 | If you use parts of this work in your own projects or writings, please provide attribution by referencing this repository and my X (formerly Twitter) account: [@RayFernando1337](https://x.com/RayFernando1337) 29 | 30 | ## Live Coding 31 | 32 | I regularly livestream coding sessions where I use Cursor and apply these rules. You can watch these streams on my YouTube channel: [Ray Fernando](https://youtube.com/@RayFernando1337) 33 | 34 | ## Connect 35 | 36 | - Follow me on X: [@RayFernando1337](https://x.com/RayFernando1337) 37 | - Subscribe to my YouTube channel: [Ray Fernando](https://youtube.com/@RayFernando1337) 38 | 39 | ## License 40 | 41 | This project is open source. While I welcome sharing and usage of this work, I kindly request that you provide attribution as mentioned above. 42 | -------------------------------------------------------------------------------- /Tailwind-v4.mdc: -------------------------------------------------------------------------------- 1 | --- 2 | description: Tailwind CSS usage rules for styling (2025 best practices) 3 | globs: **/*.{html,js,jsx,ts,tsx,vue,svelte,css,scss,sass,md,mdx,php,blade.php,ejs,hbs,twig,liquid,njk,pug,astro,xml,json,yml,yaml,svg} 4 | --- 5 | 6 | ## General Guidelines 7 | - Use Tailwind utility classes for consistent styling, with custom CSS only for special cases 8 | - Organize classes logically (layout, spacing, color, typography) 9 | - Use responsive and state variants (e.g., sm:, md:, lg:, hover:, focus:, dark:) in markup 10 | - Embrace Tailwind v4 features like container queries and CSS variables 11 | - Keep `tailwind.config.ts` updated with design tokens and purge paths 12 | - Rely on Tailwind classes rather than inline styles or external CSS files for a unified design language 13 | 14 | ## Configuration (CSS Files) 15 | - Use the `@theme` directive to define custom design tokens like fonts, breakpoints, and colors 16 | - Prefer modern color formats such as `oklch` for better color gamut support, defining them in the `:root` scope 17 | - Take advantage of automatic content detection, which eliminates the need for a `content` array in configuration 18 | - Rely on Oxide engine to scan project files, excluding those in `.gitignore` and binary extensions 19 | - Add specific sources with `@source` only when necessary 20 | - Extend Tailwind with custom utilities using the `@utility` directive in CSS files 21 | 22 | ## Styling (CSS Files) 23 | - Incorporate 3D transform utilities like `rotate-x-*`, `rotate-y-*`, and `scale-z-*` for advanced visual effects 24 | - Implement container queries with `@container`, `@max-*`, and `@min-*` utilities for adaptive layouts 25 | - Use arbitrary values and properties with square bracket notation (e.g., `[mask-type:luminance]` or `top-[117px]`) 26 | - Apply modifiers like `hover` or `lg` with arbitrary values for flexible styling 27 | - Use the `not-*` variant for `:not()` pseudo-classes and the `starting` variant for `@starting-style` 28 | - Check browser support for advanced features like `@starting-style` using resources like caniuse 29 | 30 | ## Components (HTML) 31 | - Apply Tailwind utility classes directly in HTML for styling components 32 | - Use dynamic arbitrary values like `grid-cols-[1fr_500px_2fr]` for flexible layouts 33 | - Implement data attribute variants like `data-current:opacity-100` for conditional styling 34 | - Ensure accessibility by pairing Tailwind utilities with appropriate ARIA attributes 35 | - Use `aria-hidden="true"` or `role="presentation"` when applying utilities like `hidden` or `sr-only` 36 | 37 | ## Components (TypeScript/JavaScript) 38 | - Prefer TypeScript over JavaScript for component files to ensure type safety when applying Tailwind classes 39 | - Use dynamic utility classes with template literals or arrays (e.g., `className={`p-${padding} bg-${color}`}`) 40 | - Validate dynamic values with TypeScript types 41 | - Integrate Tailwind with modern frameworks by applying utilities in component logic 42 | - Favor functional components over class-based ones in frameworks like React 43 | 44 | ## Project-Wide Systems 45 | - Leverage the Oxide engine's fast build times for performance optimization 46 | - Avoid manual content configuration unless explicitly required 47 | - Maintain consistency by using theme variables defined in CSS configuration files 48 | - Reference theme variables in both utility classes and custom CSS (e.g., `text-[--color-primary]`) 49 | - Update rules regularly to reflect Tailwind v4's evolving feature set 50 | - Be aware of deprecated options from v3.x like `text-opacity` 51 | -------------------------------------------------------------------------------- /fire-your-design-team.md: -------------------------------------------------------------------------------- 1 | # shadcn/ui with Tailwind v4 Design System Guidelines 2 | 3 | This document outlines design principles and implementation guidelines for applications using shadcn/ui with Tailwind v4. These guidelines ensure consistency, accessibility, and best practices throughout the UI development process. 4 | 5 | ## Core Design Principles 6 | 7 | ### 1. Typography System: 4 Sizes, 2 Weights 8 | - **4 Font Sizes Only**: 9 | - Size 1: Large headings 10 | - Size 2: Subheadings/Important content 11 | - Size 3: Body text 12 | - Size 4: Small text/labels 13 | - **2 Font Weights Only**: 14 | - Semibold: For headings and emphasis 15 | - Regular: For body text and general content 16 | - **Consistent Hierarchy**: Maintain clear visual hierarchy with limited options 17 | 18 | ### 2. 8pt Grid System 19 | - **All spacing values must be divisible by 8 or 4** 20 | - **Examples**: 21 | - Instead of 25px padding → Use 24px (divisible by 8) 22 | - Instead of 11px margin → Use 12px (divisible by 4) 23 | - **Consistent Rhythm**: Creates visual harmony throughout the interface 24 | 25 | ### 3. 60/30/10 Color Rule 26 | - **60%**: Neutral color (white/light gray) 27 | - **30%**: Complementary color (dark gray/black) 28 | - **10%**: Main brand/accent color (e.g., red, blue) 29 | - **Color Balance**: Prevents visual stress while maintaining hierarchy 30 | 31 | ### 4. Clean Visual Structure 32 | - **Logical Grouping**: Related elements should be visually connected 33 | - **Deliberate Spacing**: Spacing between elements should follow the grid system 34 | - **Alignment**: Elements should be properly aligned within their containers 35 | - **Simplicity Over Flashiness**: Focus on clarity and function first 36 | 37 | ## Foundation 38 | 39 | ### Tailwind v4 Integration 40 | - **Use Tailwind CSS v4 for styling**: Leverage the latest Tailwind features including the new @theme directive, dynamic utility values, and OKLCH colors. [Tailwind CSS v4 Documentation](mdc:https://tailwindcss.com/docs) 41 | - **Modern browsing features**: Tailwind v4 uses bleeding-edge browser features and is designed for modern browsers. 42 | - **Simplified installation**: Fewer dependencies, zero configuration required in many cases. 43 | - **shadcn/ui v4 demo**: Reference the demo site for component examples. [shadcn/ui v4 Demo](mdc:https://v4.shadcn.com/) 44 | 45 | ### New CSS Structure 46 | - **Replace @layer base with @theme directive**: 47 | ```css 48 | /* Old approach in v3 */ 49 | @layer base { 50 | :root { 51 | --background: 0 0% 100%; 52 | --foreground: 0 0% 3.9%; 53 | } 54 | } 55 | 56 | /* New approach in v4 */ 57 | @theme { 58 | --color-background: hsl(var(--background)); 59 | --color-foreground: hsl(var(--foreground)); 60 | } 61 | ``` 62 | - **Tailwind imports**: Use `@import "tailwindcss"` instead of `@tailwind base` 63 | - **Container queries**: Built-in support without plugins 64 | - **OKLCH color format**: Updated from HSL for better color perception 65 | 66 | ## Typography System 67 | 68 | ### Font Sizes & Weights 69 | - **Strictly limit to 4 distinct sizes**: 70 | - Size 1: Large headings (largest) 71 | - Size 2: Subheadings 72 | - Size 3: Body text 73 | - Size 4: Small text/labels (smallest) 74 | - **Only use 2 font weights**: 75 | - Semibold: For headings and emphasis 76 | - Regular: For body text and most UI elements 77 | - **Common mistakes to avoid**: 78 | - Using more than 4 font sizes 79 | - Introducing additional font weights 80 | - Inconsistent size application 81 | 82 | ### Typography Implementation 83 | - **Reference shadcn's typography primitives** for consistent text styling 84 | - **Use monospace variant** for numerical data when appropriate 85 | - **data-slot attribute**: Every shadcn/ui primitive now has a data-slot attribute for styling 86 | - **Maintain hierarchy** using consistent sizing patterns 87 | 88 | ## 8pt Grid System 89 | 90 | ### Spacing Guidelines 91 | - **All spacing values MUST be divisible by 8 or 4**: 92 | - ✅ DO: Use 8, 16, 24, 32, 40, 48, etc. 93 | - ❌ DON'T: Use 25, 11, 7, 13, etc. 94 | 95 | - **Practical examples**: 96 | - Instead of 25px padding → Use 24px (divisible by 8) 97 | - Instead of 11px margin → Use 12px (divisible by 4) 98 | - Instead of 15px gap → Use 16px (divisible by 8) 99 | 100 | - **Use Tailwind's spacing utilities**: 101 | - p-4 (16px), p-6 (24px), p-8 (32px) 102 | - m-2 (8px), m-4 (16px), m-6 (24px) 103 | - gap-2 (8px), gap-4 (16px), gap-8 (32px) 104 | 105 | - **Why this matters**: 106 | - Creates visual harmony 107 | - Simplifies decision-making 108 | - Establishes predictable patterns 109 | 110 | ### Implementation 111 | - **Tailwind v4 dynamic spacing**: Spacing utilities accept any value without arbitrary syntax 112 | - **Consistent component spacing**: Group related elements with matching gap values 113 | - **Check responsive behavior**: Ensure grid system holds at all breakpoints 114 | 115 | ## 60/30/10 Color Rule 116 | 117 | ### Color Distribution 118 | - **60%**: neutral color (bg-background) 119 | - Usually white or light gray in light mode 120 | - Dark gray or black in dark mode 121 | - Used for primary backgrounds, cards, containers 122 | 123 | - **30%**: complementary color (text-foreground) 124 | - Usually dark gray or black in light mode 125 | - Light gray or white in dark mode 126 | - Used for text, icons, subtle UI elements 127 | 128 | - **10%**: accent color (brand color) 129 | - Your primary brand color (red, blue, etc.) 130 | - Used sparingly for call-to-action buttons, highlights, important indicators 131 | - Avoid overusing to prevent visual stress 132 | 133 | ### Common Mistakes 134 | - ❌ Overusing accent colors creates visual stress 135 | - ❌ Not enough contrast between background and text 136 | - ❌ Too many competing accent colors (stick to one primary accent) 137 | 138 | ### Implementation with shadcn/ui 139 | - **Background/foreground convention**: Each component uses the background/foreground pattern 140 | - **CSS variables in globals.css**: 141 | ```css 142 | :root { 143 | --background: oklch(1 0 0); 144 | --foreground: oklch(0.145 0 0); 145 | --primary: oklch(0.205 0 0); 146 | --primary-foreground: oklch(0.985 0 0); 147 | /* Additional variables */ 148 | } 149 | 150 | @theme { 151 | --color-background: var(--background); 152 | --color-foreground: var(--foreground); 153 | /* Register other variables */ 154 | } 155 | ``` 156 | - **OKLCH color format**: More accessible colors, especially in dark mode 157 | - **Reserve accent colors** for important elements that need attention 158 | 159 | ## Component Architecture 160 | 161 | ### shadcn/ui Component Structure 162 | - **2-layered architecture**: 163 | 1. Structure and behavior layer (Radix UI primitives) 164 | 2. Style layer (Tailwind CSS) 165 | - **Class Variance Authority (CVA)** for variant styling 166 | - **data-slot attribute** for styling component parts 167 | 168 | ### Implementation 169 | - **Install components individually** using CLI (updated for v4) or manual installation 170 | - **Component customization**: Modify components directly as needed 171 | - **Radix UI primitives**: Base components for accessibility and behavior 172 | - **New-York style**: Default recommended style for new projects (deprecated "default" style) 173 | 174 | ## Visual Hierarchy 175 | 176 | ### Design Principles 177 | - **Simplicity over flashiness**: Focus on clarity and usability 178 | - **Emphasis on what matters**: Highlight important elements 179 | - **Reduced cognitive load**: Use consistent terminology and patterns 180 | - **Visual connection**: Connect related UI elements through consistent patterns 181 | 182 | ### Implementation 183 | - **Use shadcn/ui Blocks** for common UI patterns 184 | - **Maintain consistent spacing** between related elements 185 | - **Align elements properly** within containers 186 | - **Logical grouping** of related functionality 187 | 188 | ## Installation & Setup 189 | 190 | ### Project Setup 191 | - **CLI initialization**: 192 | ```bash 193 | npx create-next-app@latest my-app 194 | cd my-app 195 | npx shadcn-ui@latest init 196 | ``` 197 | - **Manual setup**: Follow the guide at [Manual Installation](mdc:https://ui.shadcn.com/docs/installation/manual) 198 | - **components.json configuration**: 199 | ```json 200 | { 201 | "style": "new-york", 202 | "rsc": true, 203 | "tailwind": { 204 | "config": "", 205 | "css": "app/globals.css", 206 | "baseColor": "neutral", 207 | "cssVariables": true 208 | }, 209 | "aliases": { 210 | "components": "@/components", 211 | "utils": "@/lib/utils" 212 | } 213 | } 214 | ``` 215 | 216 | ### Adding Components 217 | - **Use the CLI**: `npx shadcn-ui@latest add button` 218 | - **Install dependencies**: Required for each component 219 | - **Find components**: [Component Reference](mdc:https://ui.shadcn.com/docs/components) 220 | 221 | ## Advanced Features 222 | 223 | ### Dark Mode 224 | - **Updated dark mode colors** for better accessibility using OKLCH 225 | - **Consistent contrast ratios** across light and dark themes 226 | - **Custom variant**: `@custom-variant dark (&:is(.dark *))` 227 | 228 | ### Container Queries 229 | - **Built-in support** without plugins 230 | - **Responsive components** that adapt to their container size 231 | - **@min-* and @max-* variants** for container query ranges 232 | 233 | ### Data Visualization 234 | - **Chart components**: Use with consistent styling 235 | - **Consistent color patterns**: Use chart-1 through chart-5 variables 236 | 237 | ## Experience Design 238 | 239 | ### Motion & Animation 240 | - **Consider transitions** between screens and states 241 | - **Animation purpose**: Enhance usability, not distract 242 | - **Consistent motion patterns**: Similar elements should move similarly 243 | 244 | ### Implementation 245 | - **Test experiences** across the entire flow 246 | - **Design with animation in mind** from the beginning 247 | - **Balance speed and smoothness** for optimal user experience 248 | 249 | ## Resources 250 | 251 | - [shadcn/ui Documentation](mdc:https://ui.shadcn.com/docs) 252 | - [Tailwind CSS v4 Documentation](mdc:https://tailwindcss.com/docs) 253 | - [shadcn/ui GitHub Repository](mdc:https://github.com/shadcn/ui) 254 | - [Tailwind v4 Upgrade Guide](mdc:https://tailwindcss.com/docs/upgrade-guide) 255 | - [shadcn/ui v4 Demo](mdc:https://v4.shadcn.com/) 256 | - [Figma Design System](mdc:https://www.figma.com/community/file/1203061493325953101/shadcn-ui-design-system) 257 | 258 | ## Code Review Checklist 259 | 260 | ### Core Design Principles 261 | - [ ] Typography: Uses only 4 font sizes and 2 font weights (Semibold, Regular) 262 | - [ ] Spacing: All spacing values are divisible by 8 or 4 263 | - [ ] Colors: Follows 60/30/10 color distribution (60% neutral, 30% complementary, 10% accent) 264 | - [ ] Structure: Elements are logically grouped with consistent spacing 265 | 266 | ### Technical Implementation 267 | - [ ] Uses proper OKLCH color variables 268 | - [ ] Leverages @theme directive for variables 269 | - [ ] Components implement data-slot attribute properly 270 | - [ ] Visual hierarchy is clear and consistent 271 | - [ ] Components use Class Variance Authority for variants 272 | - [ ] Dark mode implementation is consistent 273 | - [ ] Accessibility standards are maintained (contrast, keyboard navigation, etc.) 274 | 275 | ### Common Issues to Flag 276 | - [ ] Too many font sizes (more than 4) 277 | - [ ] Inconsistent spacing values (not divisible by 8 or 4) 278 | - [ ] Overuse of accent colors (exceeding 10%) 279 | - [ ] Random or inconsistent margins/padding 280 | - [ ] Insufficient contrast between text and background 281 | - [ ] Unnecessary custom CSS when Tailwind utilities would suffice 282 | -------------------------------------------------------------------------------- /marketing/landing-page-communication-framework.md: -------------------------------------------------------------------------------- 1 | # Landing Page Communication Framework for LLMs 2 | 3 | ## Core Principles 4 | 5 | ### 1. Process Communication Model (PCM) 6 | Ensure messaging speaks to all six personality types: 7 | 8 | - **Thinkers**: Logic and data-driven 9 | - Focus: Structured information, clear outcomes 10 | - Example: "Convert raw input into structured output" 11 | 12 | - **Harmonizers**: Emotion and compassion-driven 13 | - Focus: Personal impact, community benefits 14 | - Example: "Finally caught up with your backlog" 15 | 16 | - **Rebels**: Reaction and humor-driven 17 | - Focus: Breaking free from tedious work 18 | - Example: "Done with manual busywork? 😎" 19 | 20 | - **Promoters**: Action and charm-driven 21 | - Focus: Quick wins, immediate results 22 | - Example: "One upload = endless opportunities" 23 | 24 | - **Persisters**: Value and opinion-driven 25 | - Focus: Quality outcomes, trusted results 26 | - Example: "Quality in, more value out" 27 | 28 | - **Imaginers**: Reflection and imagination-driven 29 | - Focus: Possibilities, potential outcomes 30 | - Example: "Unlock hidden potential" 31 | 32 | ### 2. ARCS Copywriting Formula 33 | 34 | - **Ask**: Start with a "yes" question 35 | - **Reveal**: Show understanding of their situation 36 | - **Call**: Present the solution/discovery 37 | - **Send**: Clear call to action 38 | 39 | ### 3. Landing Page Structure Best Practices 40 | 41 | 1. Hero Section: 42 | ``` 43 | Headline: Core Transformation 44 | Subhead: Specific Outcome 45 | • Key Benefit 1 46 | • Key Benefit 2 47 | • Risk Reducer 48 | [Primary CTA] [Secondary CTA] 49 | ``` 50 | 51 | 2. Social Proof: 52 | ``` 53 | "Specific Result + Emotional Impact" 54 | - Name, Role 55 | ``` 56 | 57 | 3. Use Cases: 58 | - Group by outcome, not features 59 | - Show transformation 60 | - Include quick wins 61 | 62 | 4. Pricing: 63 | - Focus on value tiers 64 | - Simple, clear benefits 65 | - Risk reducers (guarantees, trial) 66 | 67 | ## Communication Guidelines 68 | 69 | ### 1. Value Proposition Formula 70 | ``` 71 | [Transform X] into [Desired Outcome] 72 | Get [Specific Result] in [Timeframe] 73 | ``` 74 | 75 | ### 2. Clarity Checklist 76 | - What they get (specific output) 77 | - How fast (timeframe) 78 | - Who it's for/not for (qualification) 79 | - Immediate value (free/trial offer) 80 | - Social proof (user results) 81 | - Clear next step (risk-free CTA) 82 | 83 | ### 3. Content Categories 84 | 85 | Emotional Transformation: 86 | - Before state → After state 87 | - Pain point → Relief 88 | - Problem → Solution 89 | 90 | Practical Transformation: 91 | - Input → Output 92 | - Raw material → Finished product 93 | - Single use → Multiple uses 94 | 95 | ### 4. Risk Reduction Elements 96 | 97 | - Free trial/tier 98 | - No credit card required 99 | - Money-back guarantee 100 | - Support availability 101 | - Clear limitations 102 | 103 | ## Landing Page Template 104 | 105 | ```markdown 106 | # [Core Transformation] 107 | [Specific Outcome] 108 | 109 | • [Key Benefit 1] 110 | • [Key Benefit 2] 111 | • [Risk Reducer] 112 | 113 | [Primary CTA] [Secondary CTA] 114 | 115 | ## Real Results 116 | [3 testimonials targeting different PCM types] 117 | 118 | ## Use Cases 119 | [3 outcome-focused categories] 120 | 121 | ## Simple Process 122 | [3 clear steps] 123 | 124 | ## Plans 125 | [3 value-focused tiers] 126 | 127 | ## Guarantee 128 | [Risk elimination] 129 | 130 | ## Ready to [Core Benefit]? 131 | [Final CTA with risk reducer] 132 | 133 | --- 134 | [Important limitation] • [Key qualifier] 135 | ``` 136 | 137 | ## Application Tips for LLMs 138 | 139 | 1. When generating copy: 140 | - Start with identifying target PCM types 141 | - Apply ARCS formula to structure 142 | - Use template as foundation 143 | - Customize based on specific use case 144 | 145 | 2. When analyzing copy: 146 | - Check coverage of PCM types 147 | - Verify ARCS elements 148 | - Ensure clarity elements 149 | - Confirm risk reducers 150 | 151 | 3. When improving copy: 152 | - Identify missing PCM types 153 | - Strengthen ARCS elements 154 | - Add missing clarity elements 155 | - Enhance risk reduction 156 | 157 | Remember: The goal is clear transformation and outcomes, not features or technology. 158 | -------------------------------------------------------------------------------- /nextjs14-clerk-convex-stripe.md: -------------------------------------------------------------------------------- 1 | ## Authentication (Clerk) 2 | 3 | - Clerk is used for authentication. 4 | - The `ClerkProvider` wraps the application in `app/providers.tsx`. 5 | - Middleware in `middleware.ts` handles authentication routes. 6 | - `useSession` hook in `lib/utils.ts` provides authentication state. 7 | 8 | ## Database (Convex) 9 | 10 | - Convex is used as the database and backend. 11 | - Convex schema is defined in `convex/schema.ts`. 12 | - Convex functions (queries, mutations, actions) are in separate files in the `convex` directory. 13 | - The `ConvexProviderWithClerk` wraps the application in `app/providers.tsx`. 14 | - Custom hooks like `authQuery`, `authMutation`, and `authAction` in `convex/util.ts` handle authenticated Convex operations. 15 | 16 | ## Payment Integration (Stripe) 17 | 18 | - Stripe is used for payment processing. 19 | - Stripe integration is primarily handled in `convex/stripe.ts`. 20 | - The `pay` action initiates the payment process. 21 | - Webhook handling for Stripe events is in `convex/http.ts`. 22 | 23 | ## File Structure 24 | 25 | - Next.js 14 app directory structure is used. 26 | - Pages are in `app` directory. 27 | - Components are in `components` directory. 28 | - Convex functions and schema are in the `convex` directory. 29 | 30 | ## Key Patterns 31 | 32 | 1. Server Components: Most pages are server components (no "use client" directive). 33 | 2. Client Components: Components that need interactivity use the "use client" directive. 34 | 3. Convex Queries and Mutations: Used throughout the application for data fetching and manipulation. 35 | 4. Authentication Checks: Many components and pages check authentication status before rendering or performing actions. 36 | 5. Environment Variables: Sensitive information and API keys are stored in environment variables. 37 | 38 | ## Important Files 39 | 40 | - `convex/schema.ts`: Defines the database schema. 41 | - `convex/users.ts`: Handles user-related operations. 42 | - `convex/stripe.ts`: Manages Stripe integration. 43 | - `app/providers.tsx`: Sets up global providers (Convex, Clerk, Theme). 44 | - `middleware.ts`: Handles authentication middleware. 45 | - `lib/utils.ts`: Contains utility functions and hooks. 46 | 47 | ## Styling 48 | 49 | - Tailwind CSS is used for styling. 50 | - Global styles are in `app/globals.css`. 51 | - Tailwind config is in `tailwind.config.ts`. 52 | 53 | ## Deployment 54 | 55 | - The application is configured for deployment on Vercel. 56 | - Environment variables need to be set for Convex, Clerk, and Stripe in the deployment environment. 57 | 58 | When working with this codebase, focus on these key areas and patterns to maintain consistency and leverage the existing infrastructure. 59 | -------------------------------------------------------------------------------- /nextjs14-typescript-tailwind.md: -------------------------------------------------------------------------------- 1 | # Rules for Next.js 14 Development 2 | 3 | ## General Guidelines 4 | 5 | 1. Use Next.js 14 with TypeScript and Tailwind CSS for optimal developer experience and type safety. 6 | 2. Use `bun` for all package installations and management. 7 | 3. Implement the App Router, which is the recommended routing system for Next.js 14. 8 | 4. Utilize Server Components by default, using Client Components only when necessary for interactivity or client-side state. 9 | 5. Leverage Server Actions for handling data mutations and form submissions. 10 | 6. Implement proper caching strategies using Next.js built-in caching mechanisms. 11 | 7. Ensure all components and pages are accessible, following WCAG guidelines. 12 | 8. Use environment variables for configuration following Next.js conventions. 13 | 9. Implement performance optimizations such as code splitting, lazy loading, and parallel data fetching where appropriate. 14 | 10. Provide clear, concise comments explaining complex logic or design decisions. 15 | 16 | ## Code Structure and Syntax 17 | 18 | 1. Use the `app` directory for all components and pages. 19 | 2. Implement the following file conventions in the `app` directory: 20 | - `layout.tsx`: For shared UI across multiple pages 21 | - `page.tsx`: For unique page content 22 | - `loading.tsx`: For loading UI 23 | - `error.tsx`: For error handling UI 24 | - `not-found.tsx`: For 404 pages 25 | 3. Use Server Components by default. Add the `'use client'` directive only when creating Client Components. 26 | 4. Define components using arrow function syntax with TypeScript: 27 | 28 | ```tsx 29 | import { FC } from 'react'; 30 | 31 | interface ComponentProps { 32 | // Props definition 33 | } 34 | 35 | const Component: FC = ({ prop1, prop2 }) => { 36 | // Component logic 37 | }; 38 | 39 | export default Component; 40 | 41 | ``` 42 | 43 | 5. For page components, use default exports: 44 | 45 | ```tsx 46 | export default function Page() { 47 | // Page component logic 48 | } 49 | 50 | ``` 51 | 52 | 6. If explicit typing is needed, prefer `React.FC` or `React.ReactNode`: 53 | 54 | ```tsx 55 | import React from 'react'; 56 | 57 | const ComponentName: React.FC = () => { 58 | // Component logic 59 | }; 60 | 61 | // OR 62 | 63 | const ComponentName = (): React.ReactNode => { 64 | // Component logic 65 | }; 66 | 67 | ``` 68 | 69 | 70 | ## Routing and Navigation 71 | 72 | 1. Implement nested routing using folder structure in the `app` directory. 73 | 2. Use the `` component from `next/link` for client-side navigation: 74 | 75 | ```tsx 76 | import Link from 'next/link'; 77 | 78 | About 79 | 80 | ``` 81 | 82 | 3. Implement dynamic routes using folder names with square brackets (e.g., `[id]`). 83 | 4. Use `generateStaticParams` for generating static paths in dynamic routes. 84 | 85 | ## Data Fetching and API Routes 86 | 87 | 1. Use Server Components and the `fetch` API for data fetching, leveraging Next.js automatic request deduplication: 88 | 89 | ```tsx 90 | async function getData() { 91 | const res = await fetch('', { next: { revalidate: 3600 } }); 92 | if (!res.ok) throw new Error('Failed to fetch data'); 93 | return res.json(); 94 | } 95 | 96 | export default async function Page() { 97 | const data = await getData(); 98 | // Render component using data 99 | } 100 | 101 | ``` 102 | 103 | 2. Implement Server Actions for data mutations: 104 | 105 | ```tsx 106 | 'use server'; 107 | 108 | import { revalidatePath } from 'next/cache'; 109 | 110 | export async function updateData(formData: FormData) { 111 | // Update data in your database 112 | revalidatePath('/data'); 113 | } 114 | 115 | ``` 116 | 117 | 3. Use route handlers (route.ts) for API routes in the App Router. 118 | 4. Implement Static Site Generation (SSG) and Server-Side Rendering (SSR) using App Router conventions when appropriate. 119 | 120 | ## State Management and Interactivity 121 | 122 | 1. Use Server Actions for form submissions and data mutations: 123 | 124 | ```tsx 125 | import { updateData } from './actions'; 126 | 127 | export default function Form() { 128 | return ( 129 |
130 | 131 | 132 |
133 | ); 134 | } 135 | 136 | ``` 137 | 138 | 2. Implement React hooks for client-side state management when necessary. 139 | 3. Use the `useState` and `useEffect` hooks in Client Components for local state and side effects. 140 | 141 | ## Styling 142 | 143 | 1. Use Tailwind CSS classes exclusively for styling. Avoid inline styles: 144 | 145 | ```tsx 146 |
147 | {/* Component content */} 148 |
149 | 150 | ``` 151 | 152 | 2. Create custom Tailwind classes in the `tailwind.config.js` file for reusable styles. 153 | 3. Use CSS Modules for component-specific styles when needed. 154 | 155 | ## Performance Optimization 156 | 157 | 1. Implement automatic static optimization for eligible pages. 158 | 2. Use dynamic imports for code splitting: 159 | 160 | ```tsx 161 | import dynamic from 'next/dynamic'; 162 | 163 | const DynamicComponent = dynamic(() => import('../components/DynamicComponent')); 164 | 165 | ``` 166 | 167 | 3. Utilize the Image component from `next/image` for automatic image optimization: 168 | 169 | ```tsx 170 | import Image from 'next/image'; 171 | 172 | Description 173 | 174 | ``` 175 | 176 | 4. Implement proper caching strategies using the Data Cache and Full Route Cache. 177 | 5. Use Next.js 14's built-in caching and revalidation features for optimal performance: 178 | 179 | ```tsx 180 | import { unstable_cache } from 'next/cache'; 181 | 182 | const getCachedUser = unstable_cache( 183 | async (id: string) => getUser(id), 184 | ['user-cache'], 185 | { revalidate: 3600 } // Revalidate every hour 186 | ); 187 | 188 | ``` 189 | 190 | 6. Use on-demand revalidation when appropriate: 191 | 192 | ```tsx 193 | import { revalidatePath, revalidateTag } from 'next/cache'; 194 | 195 | export async function updateData() { 196 | // Update data in your database 197 | revalidatePath('/data'); // Revalidate a specific path 198 | revalidateTag('data-tag'); // Revalidate all entries with this tag 199 | } 200 | 201 | ``` 202 | 203 | 7. Implement parallel data fetching for improved performance: 204 | 205 | ```tsx 206 | async function ParallelDataFetch() { 207 | const dataPromise = fetch(''); 208 | const userPromise = fetch(''); 209 | 210 | const [data, user] = await Promise.all([ 211 | dataPromise.then(res => res.json()), 212 | userPromise.then(res => res.json()) 213 | ]); 214 | 215 | return { data, user }; 216 | } 217 | 218 | ``` 219 | 220 | 221 | ## Error Handling and Loading States 222 | 223 | 1. Create error.tsx files for error boundaries: 224 | 225 | ```tsx 226 | 'use client'; 227 | 228 | export default function Error({ 229 | error, 230 | reset, 231 | }: { 232 | error: Error & { digest?: string }; 233 | reset: () => void; 234 | }) { 235 | return ( 236 |
237 |

Something went wrong!

238 | 239 |
240 | ); 241 | } 242 | 243 | ``` 244 | 245 | 2. Implement loading.tsx files for managing loading states. 246 | 3. Use React Suspense for more granular loading states: 247 | 248 | ```tsx 249 | import { Suspense } from 'react'; 250 | 251 | export default function Page() { 252 | return ( 253 | }> 254 | 255 | 256 | ); 257 | } 258 | 259 | ``` 260 | 261 | 262 | ## SEO and Metadata 263 | 264 | 1. Use the Metadata API for SEO optimization: 265 | 266 | ```tsx 267 | import type { Metadata } from 'next'; 268 | 269 | export const metadata: Metadata = { 270 | title: 'Page Title', 271 | description: 'Page description', 272 | }; 273 | 274 | ``` 275 | 276 | 2. Implement dynamic metadata using generateMetadata for pages with dynamic content. 277 | 278 | ## Composer Mode-Specific Guidelines 279 | 280 | 1. When using Composer mode, provide clear, natural language descriptions of desired changes or additions. 281 | 2. For multi-file operations, specify the files involved and their relationships. 282 | 3. When requesting code generation, provide context about the desired functionality and how it fits into the existing project structure. 283 | 4. For refactoring tasks, describe the current code structure and the desired outcome. 284 | 5. When addressing errors, provide details about the error message and the surrounding code context. 285 | 286 | Remember to adapt these rules based on specific project requirements and personal preferences. Always prioritize clean, efficient, and maintainable code that adheres to Next.js 14 best practices. 287 | -------------------------------------------------------------------------------- /productivity/improve-writing.md: -------------------------------------------------------------------------------- 1 | # Writing Improvement Guidelines 2 | 3 | Analyze the following text and suggest improvements based on these principles: 4 | 5 | 1. **Conciseness**: Eliminate unnecessary words and phrases. 6 | - Bad: Due to the fact that the meeting was delayed, we will have to reschedule our plans. 7 | - Good: Because the meeting was delayed, we will reschedule our plans. 8 | 9 | 2. **Avoiding Redundancy**: Remove repetitive words or ideas. 10 | - Bad: He made a final and last decision about the project. 11 | - Good: He made a final decision about the project. 12 | 13 | 3. **Active Voice**: Prefer active over passive voice when appropriate. 14 | - Bad: The report was written by Jane. 15 | - Good: Jane wrote the report. 16 | 17 | 4. **Eliminating Unnecessary Words**: Cut filler words and phrases. 18 | - Bad: In order to make sure that the process is completed properly, follow the given instructions carefully. 19 | - Good: To complete the process properly, follow the instructions. 20 | 21 | 5. **Precision and Clarity**: Use specific and clear language. 22 | - Bad: The results of the experiment were interesting and pretty significant. 23 | - Good: The experiment results were significant. 24 | 25 | 6. **Avoiding Wordiness**: Express ideas in the most direct way. 26 | - Bad: At this point in time, we are currently accepting applications for the program. 27 | - Good: We are currently accepting applications. 28 | 29 | 7. **Use Definite, Specific Language**: Replace vague terms with concrete ones. 30 | - Bad: She did something nice for the team. 31 | - Good: She bought lunch for the team. 32 | 33 | 8. **Avoiding Weak Modifiers**: Remove unnecessary intensifiers. 34 | - Bad: The performance was very amazing. 35 | - Good: The performance was amazing. 36 | 37 | 9. **Clarity and Brevity**: Combine principles for clear, concise writing. 38 | - Bad: He has a tendency to overanalyze the problems he is working on. 39 | - Good: He tends to overanalyze his problems. 40 | 41 | Provide specific suggestions to improve the text, explaining how each change aligns with these principles and enhances overall readability and impact. 42 | -------------------------------------------------------------------------------- /productivity/transcript-to-blogpost.md: -------------------------------------------------------------------------------- 1 | # AI-Powered Blog Post Generator for Livestream Transcripts 2 | 3 | ## 1. AI Analysis 4 | Analyze the transcript and identify: 5 | 1. Main topic and key points discussed 6 | 2. Target audience and their search intent 7 | 3. Emotional elements or personal journeys described 8 | 4. Unique or surprising elements that could create curiosity 9 | 5. Any constraints or specific elements to include (e.g., mention of company names, technologies) 10 | 6. Relevant keywords and phrases for SEO optimization 11 | 7. 4-6 main themes or topics discussed 12 | 13 | ## 2. Title Generation 14 | Generate 10-15 title options that: 15 | 1. Are 50-60 characters long (optimal for search engine display) 16 | 2. Create a strong curiosity gap 17 | 3. Appeal to the identified target audience and their search intent 18 | 4. Incorporate high-value keywords naturally 19 | 5. Evoke the emotional elements found in the content 20 | 6. Hint at the livestream's content without giving everything away 21 | 7. Are clear, easily understandable, and use active voice 22 | 8. Use compelling language that encourages clicks (e.g., "How to," "X Ways to," "The Ultimate Guide") 23 | 24 | ## 3. Title Evaluation 25 | For each generated title, provide a brief evaluation: 26 | 1. SEO potential (keyword usage, search intent alignment) 27 | 2. Curiosity factor 28 | 3. Target audience appeal 29 | 4. Relevance to livestream content 30 | 5. Potential for click-through rate (CTR) 31 | 6. Suggestions for improvement or variations 32 | 33 | ## 4. Top 3 Recommendations 34 | Recommend the top 3 titles and explain: 35 | 1. Why they work best for this livestream recap 36 | 2. Their SEO strengths 37 | 3. Their potential performance on different platforms (e.g., YouTube, Google Search) 38 | 39 | ## 5. Meta Description Generation 40 | Create 2-3 meta descriptions that: 41 | 1. Are 150-160 characters long 42 | 2. Incorporate relevant keywords naturally 43 | 3. Summarize the livestream's main value proposition 44 | 4. Include a clear call-to-action 45 | 46 | ## 6. Blog Post Generation 47 | Generate a comprehensive, SEO-optimized blog post based on the livestream content: 48 | 49 | ### Title 50 | Use the chosen title from step 5. 51 | 52 | ### Introduction (2-3 sentences) 53 | - Introduce the livestream, mentioning hosts and main objective 54 | - Incorporate attention-grabbing elements 55 | - Use first-person perspective ("we") 56 | 57 | ### Body 58 | For each of the 4-6 main themes identified: 59 | - Create a level 2 heading (##) with a concise, descriptive title 60 | - Write 2-3 sentences summarizing key points discussed 61 | - Use bullet points for specific items, tools, or concepts mentioned 62 | - Naturally incorporate identified keywords and related terms 63 | - Include code snippets or quotes from the livestream if relevant, using appropriate Markdown formatting 64 | 65 | ### Key Takeaways 66 | - Use a level 2 heading (##) 67 | - List 3-5 main lessons learned or insights gained, using numbers for emphasis 68 | 69 | ### Community Involvement (if relevant) 70 | - Briefly highlight significant viewer contributions or interactions 71 | 72 | ### Looking Ahead 73 | - Add a short section (2-3 sentences) mentioning plans for future streams or potential next steps 74 | 75 | ### Final Thoughts 76 | - Conclude with overall reflections on the experience and the current state of the technology explored (2-3 sentences) 77 | 78 | ### Formatting and Style 79 | - Use Markdown syntax for headings, lists, and emphasis 80 | - Write in a conversational, yet professional tone 81 | - Avoid overly technical jargon, explaining complex concepts simply 82 | - Keep sentences and paragraphs relatively short for readability 83 | - Aim for about 600-800 words total, adjusting based on the complexity and length of the livestream 84 | 85 | ### SEO Enhancements 86 | - Include the chosen meta description 87 | - Add internal and external links where relevant 88 | - Structure content with H2 and H3 subheadings for readability and SEO 89 | - Suggest 3-5 relevant tags for the blog post 90 | 91 | ## 7. Content Enhancement Suggestions 92 | Provide recommendations for enhancing the blog post's SEO and user engagement: 93 | 1. Ideas for relevant images, infographics, or embedded video 94 | 2. Suggestions for internal linking to other relevant content 95 | 3. Opportunities for featured snippets or rich results 96 | 4. Ideas for repurposing the content (e.g., social media posts, infographics) 97 | 98 | ## 8. Flexibility Note 99 | Adapt the structure as needed based on the specific content of the livestream. Not all sections may be applicable to every stream, and additional sections may be necessary for some topics. 100 | -------------------------------------------------------------------------------- /swift.md: -------------------------------------------------------------------------------- 1 | # SwiftUI Best Practices for iOS App Development 2 | 3 | When generating code, finding bugs, or optimizing SwiftUI projects, follow these guidelines: 4 | 5 | ## General Guidelines 6 | 7 | - You are an expert AI programming assistant focused on producing clear, readable SwiftUI code. 8 | - Always use the latest version of SwiftUI and Swift (as of August/September 2024), and be familiar with the latest features and best practices. 9 | - Provide accurate, factual, thoughtful answers, and excel at reasoning. 10 | - Follow the user's requirements carefully & to the letter. 11 | - Think step-by-step - describe your plan for what to build in pseudocode, written out in great detail. 12 | - Always confirm your understanding before writing code. 13 | - Write correct, up-to-date, bug-free, fully functional, working, secure, performant, and efficient code. 14 | - Prioritize readability over performance. 15 | - Fully implement all requested functionality. 16 | - Leave NO TODOs, placeholders, or missing pieces. 17 | - Be concise. Minimize any other prose. 18 | - If you think there might not be a correct answer, say so. If you do not know the 19 | 20 | ## 1. State Management 21 | 22 | - Use appropriate property wrappers and macros: 23 | - Annotate view models with `@Observable`, e.g. `@Observable final class MyModel`. 24 | - Do not use @State in the SwiftUI View for view model observation. Instead, use `let model: MyModel`. 25 | - For reference type state shared with a child view, pass the dependency to the constructor of the child view. 26 | - For value type state shared with a child view, use SwiftUI bindings if and only if the child needs write access to the state. 27 | - For value type state shared with a child view, pass the value if the child view only needs read access to the state. 28 | - Use an `@Environment` for state that should be shared throughout the entire app, or large pieces of the app. 29 | - Use `@State` only for local state that is managed by the view itself. 30 | 31 | ## 2. Performance Optimization 32 | 33 | - Implement lazy loading for large lists or grids using `LazyVStack`, `LazyHStack`, or `LazyVGrid`. 34 | - Optimize ForEach loops by using stable identifiers. 35 | 36 | ## 3. Reusable Components 37 | 38 | - Implement custom view modifiers for shared styling and behavior. 39 | - Use extensions to add reusable functionality to existing types. 40 | 41 | ## 4. Accessibility 42 | 43 | - Add accessibility modifiers to all UI elements. 44 | - Support Dynamic Type for text scaling. 45 | - Provide clear accessibility labels and hints. 46 | 47 | ## 5. SwiftUI Lifecycle 48 | 49 | - Use `@main` and `App` protocol for the app's entry point. 50 | - Implement `Scene`s for managing app structure. 51 | - Use appropriate view lifecycle methods like `onAppear` and `onDisappear`. 52 | 53 | ## 6. Data Flow 54 | 55 | - Use the Observation framework (`@Observable`, `@State`, and `@Binding`) to build reactive views. 56 | - Implement proper error handling and propagation. 57 | 58 | ## 7. Testing 59 | 60 | - Write unit tests for ViewModels and business logic in the UnitTests folder. 61 | - Implement UI tests for critical user flows in the UITests folder. 62 | - Use Preview providers for rapid UI iteration and testing. 63 | 64 | ## 8. SwiftUI-specific Patterns 65 | 66 | - Use `@Binding` for two-way data flow between parent and child views. 67 | - Implement custom `PreferenceKey`s for child-to-parent communication. 68 | - Utilize `@Environment` for dependency injection. 69 | 70 | ## 9. Code Style and Formatting 71 | 72 | - Follow Swift style guidelines for naming conventions and code structure. 73 | - Use SwiftLint or similar tools to enforce consistent code style. 74 | 75 | When generating or reviewing code, ensure adherence to these best practices. Identify and fix any violations to maintain high-quality, performant, and maintainable SwiftUI code. 76 | 77 | Remember, the best structure is one that works well for your specific project and team. Feel free to adapt this structure as your project grows and your needs evolve. 78 | --------------------------------------------------------------------------------