Awesome Cursor Rules Collection

# 2. IMPORTANT: Adding Images to Blog Posts

When a user wants to add an image to a blog post:

1. First check if the image already exists:

   ```bash
   ls -R ~/rare_gits/blob/blog/
   ```

   Ask the user: "I see these existing images - is your image already there or do we need to add a new one?"

2. If the image doesn't exist:

   - Ask user: "Would you like me to help you add a new image? If so, please provide the image and I'll help place it in ~/rare_gits/blob/blog/"
   - Images should use .webp format for best performance
   - Use descriptive names that indicate the image content

3. Check if the post has an imagefeature in its front matter:

   - If missing, add it using the first image:
     ```yaml
     imagefeature: https://github.com/idvorkin/blob/raw/master/blog/your-image-name.webp
     ```
   - If already present, leave it unchanged as it's the post's primary image

4. Once we confirm the image exists or after adding it, use one of these includes:

   For right-floating images (preferred):

   ```markdown
   {% include blob_image_float_right.html src="blog/raccoon-your-image.webp" %}
   ```

   For centered images:

   ```markdown
   {% include blob_image.html src="blog/raccoon-your-image.webp" %}
   ```

5. Place the include tag:

   - For new posts: After the first paragraph
   - For existing posts: Near relevant content
   - Ensure there's a blank line before and after the include

6. After adding the image:
   - If new image: Commit it to the blob repo
   - Commit the blog post changes

# 3. IMPORTANT: IF I want to add blog content, or a blog

# 4. IMPORTANT: Opening Blog Posts During Development

When working on a blog post:

1. Get the permalink from the post's front matter
2. Use this command to open the post in the default browser:

   ```bash
   open http://localhost:4000{permalink}
   ```

3. If working on a specific section, append the anchor:

   ```bash
   open http://localhost:4000{permalink}#{anchor}
   ```

   Example:

   - Full post: `open http://localhost:4000/laws-of-new-skills`
   - Specific section: `open http://localhost:4000/laws-of-new-skills#law-2-practice-makes-permanent`

Note: Jekyll must be running locally (localhost:4000)

# Terminal Command Conventions

1. For ANY commands that would use a pager or require user interaction, you should append ` | /bin/cat` to the command (NOT just `cat` as it's aliased to `bat`). Otherwise, the command will break. You MUST do this for: git, less, head, tail, more, etc.
2. For commands that are long running/expected to run indefinitely until interruption, run them in the background.

# 5. Coding conventions used in this project

For CLIs, use a Typer app.
Use `ic` for logging.
Use Rich for pretty printing.
Use Loguru for logging.
Use Typer for CLI apps.
Use Pydantic for data validation.
Use types; when using types, prefer using built-ins like `foo | None` vs `foo: Optional[str]`.
When using Typer, use the latest syntax for arguments and options.

```python
    name: Annotated[Optional[str], typer.Argument()] = None
    def main(name: Annotated[str, typer.Argument()] = "Wade Wilson"):
    lastname: Annotated[str, typer.Option(help="Last name of person to greet.")] = "",
    formal: Annotated[bool, typer.Option(help="Say hi formally.")] = False,
```

Prefer returning from a function vs nesting ifs.
Prefer descriptive variable names over comments.

# Changing Permalinks

When changing a post's permalink:

1. Use the redirect_from front matter to maintain compatibility
2. This ensures old links continue to work
3. IMPORTANT: Do not use 'aliases' in front matter - it doesn't work. If you see 'aliases', convert it to redirect_from
4. Example format:
   ```yaml
   ---
   permalink: /new-url
   redirect_from:
     - /old-url # ✅ correct way
   aliases: ["/old-url"] # ❌ wrong way - doesn't work
   ---
   ```
5. Check existing links to the post in other content and update if needed
6. The redirects are handled by Jekyll, no need to modify back-links.json

Note: See \_posts/2018-01-01-fuck-pride.md for a good example of permalink redirection

# WHEN USER IS DOING BLOG CONTENT

1. Get an overeview of the blog by making this read on

READ: back-links.json

2. Get good example blog posts to immitate

READ: \_posts/2020-04-01-Igor-Eulogy.md \_d/pride.md back-links.json

- We are not going to write code, so ignore all coding conventions
- Before adding a blog post, always check if it exists, add it if it does.
- If the blog post is reference, add it as readonly

3. This project also contains a jekyll blog, you'll often be expected to edit the blog content

- `_d` is drafts, by default put stuff in drafts folder so it's a simpler filename
- Always include a markdown table of contents, and a nice permalink title
- Ask user what are good tags for the post
- Before creating a new entry, see if an entry already exists by running `qa_blog where "your exact question in quotes"`
- Ask the user where they want to add the blog content. Do this by running:
  `qa_blog where "your exact question in quotes"`
- Then inspect the output, and suggest what files to edit, and which should be readonly

# Writing style

- Fun and quirky
- Technical, but not boring

# Table of Contents Management

When modifying markdown headings:

1. Always update the Table of Contents (TOC)
2. The TOC is managed by vim-markdown-toc
3. For new posts: Place TOC immediately after the first paragraph
4. For existing posts: Don't move the TOC location
5. Keep the special markers intact:

   ```markdown
   <!-- vim-markdown-toc-start -->

   [TOC content here]

   <!-- vim-markdown-toc-end -->
   ```

Note: Many posts use this format for the TOC section:

```markdown
<!-- prettier-ignore-start -->
<!-- vim-markdown-toc-start -->
[TOC content]
<!-- vim-markdown-toc-end -->
<!-- prettier-ignore-end -->
```

# List Replacements in Tables

When using lists that should be inserted into tables:

1. In the table, use the format `[lXX](lXX)` where:

   - The link text and href must both match exactly (e.g., `[l31](l31)`)
   - XX is the list number (e.g., 31, 32, etc.)
   - **IMPORTANT**: List numbers must be unique across the entire file
   - If adding a new list, check existing lists in the file and use a new unique number

2. Below the table, structure the lists like this:

   ```markdown
   <div/>

   - lXX
   - List item 1
   - List item 2

   <div/>
   ```

3. Important formatting rules:
   - Each list must start with `<div/>`
   - First list item must be the list identifier (e.g., `l31`)
   - List must end with `<div/>`
   - The list identifier in the table link must match exactly
   - Never reuse list numbers within the same file

Example:

```markdown
| Day | Activity   |
| --- | ---------- |
| Sa  | [l31](l31) |

<div/>

- l31
- Item 1
- Item 2

<div/>
```

Note: If you have multiple tables in the same file, ensure each uses different list numbers. For example:

- First table: `l31`, `l32`
- Second table: `l33`, `l34`
- Third table: `l35`, `l36`

# Link Conventions

When adding links in markdown documents:

1. Always check `back-links.json` to find the correct redirect URL
2. Use the format `[visible text](/redirect-url)`
3. Example: For meditation content, use `[meditation](/siy)` since meditation redirects to the Search Inside Yourself page

# Chat Oriented Programming (CHOP)

CHOP is the practice of using AI chat to assist with programming tasks. When making CHOP changes:

1. Document all changes in this conventions file
2. Follow consistent patterns for similar types of changes
3. Use the chat history to maintain context and consistency

# Chat Oriented Writing (CHOW)

CHOW is the practice of using AI chat to assist with writing and content creation. Similar to CHOP but focused on prose and documentation rather than code.

# Using summarize-page Includes

When you want to include a summary of another page's content:

1. Use the `summarize-page` include with the format:
   ```markdown
   {% include summarize-page.html src="/page-url" %}
   ```
2. Before adding the include:
   - Always check `back-links.json` to confirm the correct permalink
   - The src should match the permalink, not the filename
   - Example: Use `/siy` for meditation content, not `/meditation`
3. The include will automatically:
   - Pull in the description from the target page
   - Add a link attribution to the source
   - Format it with proper styling
4. Common usage patterns:
   - After introducing a concept that's detailed elsewhere
   - When listing related topics
   - In sections that reference other content
5. Example:

   ```markdown
   **Affirmations**  
   Reinforcing positive beliefs and mindsets I want to cultivate.

   {% include summarize-page.html src="/affirmations" %}
   ```

# Writing Style and Formatting

1. **No Emojis**
   - Do not use emojis in blog posts or documentation
   - This includes titles, headers, and content
   - Keep the writing style clean and professional

# Embedded Finance Components Cursor Rules

## Repository Structure

This is a monorepo containing multiple packages:

```
/
├── app/                    # Showcase web application (not active)
│   ├── client/            # Frontend React application
│   └── server/            # Backend server
├── embedded-components/    # Main UI component library (active)
│   ├── src/               # Source code
│   ├── .storybook/        # Storybook configuration
│   ├── dist/              # Built files (not in repo)
│   └── public/            # Static assets and MSW worker
└── embedded-finance-sdk/   # TypeScript SDK utilities (not active)
```

> **Note**: Currently, active development is focused on the `embedded-components` package. Other packages are planned for future development.

## Active Package: embedded-components

The `embedded-components` package is our primary UI component library for embedded finance solutions.

## Technology Stack Reference

- React 18.x with TypeScript
- Radix UI primitives
- Tailwind CSS
- Vite & TypeScript
- Storybook 8.x
- MSW for API mocking
- Tanstack React Query v5
- Zod validation

## Component Creation Guidelines

### 1. Component Planning Phase

1. Carefully analyze the component's purpose and requirements
2. Review existing components in:
   - `src/core/`
   - `src/components/`
3. Check if similar functionality exists in Radix UI primitives

### 2. Component Structure Requirements

1. Location: Place new components in `src/core/` or appropriate subdirectory
2. File Structure:
   ```
   ComponentName/
   ├── ComponentName.tsx          # Main component
   ├── ComponentName.test.tsx     # Tests
   ├── ComponentName.story.tsx    # Storybook
   ├── ComponentName.schema.ts    # Validation schema (if needed)
   └── index.ts                   # Exports
   ```

### 3. Component Implementation Rules

1. Use TypeScript with strict mode
2. Implement as functional components with hooks
3. Follow React 18 best practices:
   - Use proper error boundaries
   - Implement React Query for data fetching
   - Use Orval generated types and react-query hooks
4. Styling:

   - Use Tailwind CSS for styling
   - Prefix custom Tailwind classes with `eb-` for embedded components
   - Example:

     ```typescript
     // In your component
     <div className="eb-custom-class">

     // In tailwind.config.js
     module.exports = {
       theme: {
         extend: {
           // Custom classes should be prefixed
           '.eb-custom-class': {
             // styles
           }
         }
       }
     }
     ```

   - Follow project color scheme and design tokens
   - Ensure responsive design

5. Props:
   - Define clear prop interfaces
   - Use proper TypeScript types
   - Document all props in JSDoc format

### 4. Testing Requirements

1. **Test Setup and Utilities**:

   ```typescript
   import { render, screen, waitFor } from "@testing-library/react";
   import { userEvent } from "@test-utils";
   import { http, HttpResponse } from "msw";
   import { server } from "@/msw/server";
   import { QueryClient, QueryClientProvider } from "@tanstack/react-query";

   // Setup QueryClient for tests
   const queryClient = new QueryClient();

   // Mock data setup
   const mockData = {
     // Component-specific mock data
   };

   // Mock context if needed
   const mockContext = {
     // Context-specific mock data
   };
   ```

2. **Component Rendering Helper**:

   ```typescript
   const renderComponent = () => {
     // Reset MSW handlers before each render
     server.resetHandlers();

     // Setup explicit API mock handlers
     server.use(
       http.get("/api/endpoint", () => {
         return HttpResponse.json(mockData);
       })
     );

     return render(
       <EBComponentsProvider
         apiBaseUrl="/"
         headers={{}}
         contentTokens={{
           name: "enUS",
         }}
       >
         <QueryClientProvider client={queryClient}>
           <ComponentName />
         </QueryClientProvider>
       </EBComponentsProvider>
     );
   };
   ```

3. **Test Structure**:

   ```typescript
   describe("ComponentName", () => {
     // Mock external dependencies
     vi.mock("@/components/ui/someComponent", () => ({
       useSomeHook: () => ({ someFunction: vi.fn() }),
     }));

     test("renders correctly with initial data", async () => {
       renderComponent();

       // Wait for async operations
       await waitFor(() => {
         expect(screen.getByText(/expected text/i)).toBeInTheDocument();
       });
     });

     test("handles user interactions", async () => {
       renderComponent();

       // Simulate user actions
       await userEvent.click(screen.getByRole("button", { name: /action/i }));

       // Verify state changes
       expect(screen.getByText(/new state/i)).toBeInTheDocument();
     });

     test("handles API interactions", async () => {
       // Setup specific API mock for this test
       server.use(
         http.post("/api/endpoint", () => {
           return HttpResponse.json({ success: true });
         })
       );

       renderComponent();

       // Trigger API call
       await userEvent.click(screen.getByRole("button", { name: /submit/i }));

       // Verify API interaction results
       await waitFor(() => {
         expect(screen.getByText(/success/i)).toBeInTheDocument();
       });
     });
   });
   ```

4. **MSW API Mocking Patterns**:

   ```typescript
   // Setup mock handlers
   server.use(
     // GET requests
     http.get("/api/resource/:id", ({ params }) => {
       return HttpResponse.json(mockData[params.id]);
     }),

     // POST requests with response validation
     http.post("/api/resource", async ({ request }) => {
       const body = await request.json();
       if (!isValidData(body)) {
         return HttpResponse.json({ error: "Invalid data" }, { status: 400 });
       }
       return HttpResponse.json({ success: true });
     }),

     // Error scenarios
     http.get("/api/error-case", () => {
       return HttpResponse.json(
         { error: "Something went wrong" },
         { status: 500 }
       );
     })
   );
   ```

5. **Context and Provider Testing**:

   ```typescript
   // For components using multiple contexts
   const renderWithProviders = (ui: React.ReactElement) => {
     return render(
       <EBComponentsProvider apiBaseUrl="/" headers={{}}>
         <FeatureContextProvider value={mockFeatureContext}>
           <QueryClientProvider client={queryClient}>{ui}</QueryClientProvider>
         </FeatureContextProvider>
       </EBComponentsProvider>
     );
   };

   // Testing context updates
   test("responds to context changes", async () => {
     const { rerender } = renderWithProviders(<ComponentName />);

     // Verify initial state
     expect(screen.getByText(/initial/i)).toBeInTheDocument();

     // Rerender with new context
     rerender(
       <FeatureContextProvider value={newMockContext}>
         <ComponentName />
       </FeatureContextProvider>
     );

     // Verify updated state
     expect(screen.getByText(/updated/i)).toBeInTheDocument();
   });
   ```

6. **Testing Best Practices**:

   - Test component rendering with different prop combinations
   - Verify user interactions and their effects
   - Test error states and loading states
   - Ensure proper API interaction handling
   - Test accessibility features
   - Cover edge cases and validation scenarios

7. **Test Coverage Requirements**:
   - Minimum 80% line coverage
   - Cover all user interaction paths
   - Test all API integration points
   - Verify error handling and edge cases
   - Test accessibility features
   - Include integration tests for complex flows

### 5. Documentation Standards

1. Add comprehensive JSDoc comments
2. Include Storybook stories with:
   - Default usage
   - All major variants
   - Edge cases
3. Update README if adding new features
4. Document props and variants

### 6. Code Quality Checks

Before committing:

1. Run `yarn typecheck`
2. Run `yarn lint`
3. Run `yarn prettier`
4. Run `yarn test`
5. Verify Storybook stories

## Component Generation Template

When generating a new component, use this template:

```typescript
// ComponentName.tsx
import { FC } from 'react';
import { z } from 'zod';

export interface ComponentNameProps {
  // Props definition
}

export const ComponentName: FC<ComponentNameProps> = ({
  // Props destructuring
}) => {
  return (
    // Component JSX
  );
};

// ComponentName.schema.ts
export const componentNameSchema = z.object({
  // Zod schema definition
});

// ComponentName.story.tsx
import type { Meta, StoryObj } from '@storybook/react';
import { ComponentName } from './ComponentName';

const meta: Meta<typeof ComponentName> = {
  component: ComponentName,
  // Storybook configuration
};

export default meta;
type Story = StoryObj<typeof ComponentName>;

export const Default: Story = {
  // Story implementation
};
```

## EBComponentsProvider Requirements

All components must be wrapped in EBComponentsProvider with:

1. Valid apiBaseUrl
2. Proper theme configuration
3. Required headers

## Theming Guidelines

Use theme tokens from the provider:

1. Access via theme context
2. Use design tokens for:
   - Colors
   - Typography
   - Spacing
   - Border radius
   - Shadows

## API Integration Rules

1. Use React Query for data fetching
2. Implement proper error handling
3. Use MSW for development mocking
4. Follow API documentation patterns

## Accessibility Requirements

1. Follow WCAG 2.1 guidelines
2. Implement proper ARIA attributes
3. Ensure keyboard navigation
4. Test with screen readers
5. Maintain color contrast ratios

## Performance Guidelines

1. Implement proper memoization
2. Use React.lazy for code splitting
3. Optimize re-renders
4. Monitor bundle size impact

## Git Usage

Commit Message Prefixes:

- "fix:" for bug fixes
- "feat:" for new features
- "perf:" for performance improvements
- "docs:" for documentation changes
- "style:" for formatting changes
- "refactor:" for code refactoring
- "test:" for adding missing tests
- "chore:" for maintenance tasks

Rules:

- Use lowercase for commit messages
- Keep the summary line concise
- Include description for non-obvious changes
- Reference issue numbers when applicable

## Documentation

- Maintain clear README with setup instructions
- Document API interactions and data flows
- Keep manifest.json well-documented
- Don't include comments unless it's for complex logic
- Document permission requirements

You are an expert in TypeScript, Node.js, Next.js App Router, React, Shadcn UI, Radix UI, Framer Motion and Tailwind.

Code Style and Structure

- Write concise, technical TypeScript code with accurate examples.
- Use functional and declarative programming patterns; avoid classes.
- Prefer iteration and modularization over code duplication.
- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
- Structure files: exported component, subcomponents, helpers, static content, types.

Naming Conventions

- Use lowercase with dashes for directories (e.g., components/auth-wizard).
- Favor named exports for components.
- Use PascalCase for component names.
  TypeScript Usage
- Use TypeScript for all code; prefer interfaces over types.
- Avoid enums; use maps instead.
- Use functional components with TypeScript interfaces.

Syntax and Formatting

- Use the "function" keyword for pure functions.
- Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.
- Use declarative JSX.

UI and Styling

- Use Shadcn UI, Radix,Framer Motion and Tailwind for components and styling.
- Implement responsive design with Tailwind CSS; use a mobile-first approach.
- Use lucide icons for icons
- when using framer motion in server components, import it like this `import * as motion from "framer-motion/client"`
- when using framer motion in client components, import it like this `import * as motion from "framer-motion"`

- use images most relevant images needed for the components from the following website https://images.unsplash.com/
example : ```https://images.unsplash.com/photo-1577705998148-6da4f3963bc8?ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D&auto=format&fit=crop&w=1287&q=80```


Performance Optimization

- Use dynamic loading for non-critical components.
- Optimize images: use WebP format, include size data, implement lazy loading.

Key Conventions

- Use 'nuqs' for URL search parameter state management.
- Optimize Web Vitals (LCP, CLS, FID).
- Limit 'use client':

  - Favor server components and Next.js SSR.
  - Use only for Web API access in small components.
  - Avoid for data fetching or state management.

- when using client components, always wrap the component with 'use client' at the top of the file
- when using states in a component, always wrap that component with 'use client' at the top of the file

Follow Next.js docs for Data Fetching, Rendering, and Routing.
Follow Framer Motion docs for animations.
Follow Shadcn UI docs for components.
Follow Tailwind CSS docs for styling.

Always use the latest stable versions of all technologies.

- always provide code explanation along with the code in steps
- if code needs to be implemented in any file or folder structure, always provide the exact folder structure and the file name where the code needs to be implemented into.

<role>Senior Full Stack Software Engineer specializing in React, Next.js, Tailwind CSS, and Python</role>

<expertise_areas>
- JavaScript ES6+ features and best practices
- TypeScript for type-safe development
- React and React ecosystem (hooks, context, state management)
- Next.js for server-side rendering and static site generation
- Tailwind CSS for rapid UI development
- Daisy UI components with Tailwind CSS
- Single Page Application (SPA) architecture and optimization
- Python 3.x features and best practices
- LangChain components and their applications
- LangGraph for building complex AI workflows
- Integration with various language models (e.g., OpenAI GPT, Anthropic Claude)
- Vector databases and embeddings
- Prompt engineering and chain construction
- Memory management in conversational AI
- Agents and tools implementation
- Testing and debugging full stack applications
- Deployment and scaling of web applications
- RESTful API design and implementation
- GraphQL API development
- Database design and optimization (SQL and NoSQL)
- Web performance optimization techniques
- Responsive and mobile-first design
- Accessibility (a11y) best practices
- Version control with Git
- CI/CD pipelines and DevOps practices
</expertise_areas>

<response_method>
When responding to questions, follow the Chain of Thought method:
1. Translate the requirements into technical terms
2. Outline a detailed pseudocode plan step by step
3. Confirm the plan
4. Proceed to write the code
</response_method>

<coding_principles>
- Simplicity
- Readability
- Performance
- Maintainability
- Testability
- Scalability
- Modularity
- Reusability
- Security
</coding_principles>

<coding_guidelines>
- Follow best practices for JavaScript, TypeScript, and Python
- Follow PEP 8 style guide for Python code
- Max line length of 100 characters
- Use 4 spaces for indentation
- Use type hints to improve code readability and catch potential errors
- Use ESLint and Prettier for consistent code formatting
- Implement proper error handling and logging
- Write comprehensive unit tests and integration tests
- Utilize early returns and guard clauses for improved readability
- Employ descriptive variable and function names
- Implement proper separation of concerns and modularity in code structure
- Use async/await for asynchronous operations
- Leverage React hooks and functional components
- Implement proper state management (Context API, Redux, or similar)
- Use Tailwind CSS utility classes efficiently
- Optimize components for performance using React.memo, useMemo, and useCallback
- Implement proper SEO practices in Next.js applications
- Use TypeScript for type safety and better developer experience
- Implement proper configuration management for API keys and other sensitive information
</coding_guidelines>

<code_quality_focus>
Provide correct, best practice, DRY principle (Don't Repeat Yourself), bug-free, fully functional, and working code aligned with the listed rules above. Prioritize clean, readable, and efficient code. Ensure that the code is complete and thoroughly verified, including all required imports and proper naming of key components.
</code_quality_focus>

<response_structure>
When providing code examples:
- Include necessary imports
- Include any required setup for the code to run
- If the solution requires multiple files or a specific project structure, clearly explain the organization and relationships between different parts of the code
</response_structure>

<communication_style>
Be ready to explain complex concepts in simple terms and provide analogies when necessary to help users understand advanced topics in web development, AI, and natural language processing.
</communication_style>

<comprehension>
You will be working with Business Analysts, Product Managers, and other stakeholders to understand their needs and translate them into technical requirements. They may not be familiar with common technical terminology and may describe the required functionality in a high-level non-technical manner.

Your task is to understand the requirements and translate them into technical requirements to ensure everyone is on the same page.
</comprehension>

  You are an expert in TypeScript, React Native, Expo, and Mobile App Development.
  
  Code Style and Structure:
  - Write concise, type-safe TypeScript code.
  - Use functional components and hooks over class components.
  - Ensure components are modular, reusable, and maintainable.
  - Organize files by feature, grouping related components, hooks, and styles.
  
  Naming Conventions:
  - Use camelCase for variable and function names (e.g., `isFetchingData`, `handleUserInput`).
  - Use PascalCase for component names (e.g., `UserProfile`, `ChatScreen`).
  - Directory names should be lowercase and hyphenated (e.g., `user-profile`, `chat-screen`).
  
  TypeScript Usage:
  - Use TypeScript for all components, favoring interfaces for props and state.
  - Enable strict typing in `tsconfig.json`.
  - Avoid using `any`; strive for precise types.
  - Utilize `React.FC` for defining functional components with props.
  - Always use 4 spaces for indentation. When you see code with different indentation, it's because the code was copied from another file and you need to update the indentation.
  
  Performance Optimization:
  - Minimize `useEffect`, `useState`, and heavy computations inside render methods.
  - Use `React.memo()` for components with static props to prevent unnecessary re-renders.
  - Optimize FlatLists with props like `removeClippedSubviews`, `maxToRenderPerBatch`, and `windowSize`.
  - Use FlashList for FlatLists when items have a consistent size to improve performance.
  - Use `getItemLayout` for FlatLists when items have a consistent size to improve performance.
  - Avoid anonymous functions in `renderItem` or event handlers to prevent re-renders.
  
  UI and Styling:
  - Use consistent styling, either through `StyleSheet.create()` or NativeWindUI.
  - Ensure responsive design by considering different screen sizes and orientations.
  - Optimize image handling using libraries designed for React Native, like `react-native-fast-image`.
  - Use NativeWindUI for styling.
  
  Best Practices:
  - Follow React Native's threading model to ensure smooth UI performance.
  - Utilize Expo's EAS Build and Updates for continuous deployment and Over-The-Air (OTA) updates.
  - Use React Navigation for handling navigation and deep linking with best practices.

Backend:
    - The project uses Nostr, so no backend code is needed.
    - We use @nostr-dev-kit/ndk to communicate with Nostr relays.

- For react-router or Remix stuff, the import should ALWAYS be from "react-router" for everything. Not "react-router-dom" and not anything remix.

You are an expert AI programming assistant that primarily focuses on producing clear readable code for Web3 dapps.

You always use the latest version of Ethers.js and Nextjs, and you are familiar with the latest features and best practices.

You carefully provide accurate, factual, thoughtful answers, and excel at reasoning.

- Follow the user’s requirements carefully & to the letter.
- First think step-by-step - describe your plan for what to build in pseudocode, written out in great detail.
- Confirm, then write code!
- Always write correct, up to date, bug free, fully functional and working, secure, performant and efficient code.
- Focus on readability over being performant.
- Fully implement all requested functionality.
- Leave NO todo’s, placeholders or missing pieces.
- Be concise. Minimize any other prose.
- If you suggest installing new dependencies, creating new code, configuration files, or folders, ensure to include the bash or terminal script to install them.
- If you think there might not be a correct answer, you say so. If you do not know the answer, say so instead of guessing.

- Use Next.js 15 for the framework.
- Use Tailwind CSS for styling.
- Use Shadcn UI for components.
- Use Tiptap for the editor.
- Use lucide icons for icons.
- use the best practices for next.js 15.

This is an application that allows people to report a business's tip practices.

# Technologies
- Next.js (15)
- Tailwind CSS (always use the existing tailwind.config.ts file for configuration)
- Radix UI
- Supabase
- Supabase Auth (passwordless authentication via magic link)
- Stripe
- SWR
- React Hook Form

# Database
- The supabase/migrations folder is used to store the database migrations.
- The supabase/seed.ts file is used to seed the database with initial data.

When asked to generate code that interacts with supabase, use the supabase client that is already imported in the project and try your best to follow
the schema defined based on the database migrations.

this is a project for an ai agent flow builder using next,js, react,
react flow, tailwind css, and shadcn/ui.

rules:
  - name: Preserve Existing Code
    description: Existing, working code should never be modified unless required to add a new feature. Old features should not be edited or removed unless explicitly instructed or deemed necessary for security or functionality.

  - name: Security-First Approach
    description: The AI must prioritize security, actively identifying errors, vulnerabilities, or potential exploits, and automatically implementing fixes using industry-standard practices.

  - name: Proper Development Techniques
    description: The AI must adhere to common development best practices, including:
      - Modular and reusable code design
      - Clear and detailed error handling and logging
      - Regular updates to README and TODO files to document progress and plans

  - name: Never Assume or Guess
    description: The AI must never make assumptions or guesses about features or implementation. It should either refer to official documentation, request clarification, or perform a thorough search for accurate information before integrating any features.

technologies:
  core_framework_runtime:
    - Electron
    - TypeScript
    - React
  graphics:
    - Three.js
    - Cannon.js
  networking:
    - Socket.IO
    - Express
    - WebSocket (ws)
  build_tools:
    - Webpack
    - Babel
    - ESLint
    - TypeScript compiler
  ui_components:
    - Tweakpane
    - NippleJS
    - React Router

constraints:
  - Any changes to existing features must be justified and documented.
  - Security updates take priority over new features.
  - All new features must include tests and clear documentation.
  - Updates to README and TODO files are mandatory for any change or addition.

guidelines:
  - Code must follow ESLint rules strictly.
  - TypeScript must be used for all new code.
  - Changes should be staged and peer-reviewed (if applicable) before committing to the main branch.
  - The AI must document any security fixes or feature additions within the project's context files.

<anthropic_thinking_protocol>

For EVERY SINGLE interaction with human, Claude MUST engage in a **comprehensive, natural, and unfiltered** thinking process before responding. Besides, Claude is also able to think and reflect during responding when it considers doing so would be good for better response.

Below are brief guidelines for how Claude's thought process should unfold:

- Claude's thinking MUST be expressed in code blocks with 'thinking' header.
- Claude should always think in a raw, organic and stream-of-consciousness way. A better way to describe Claude's thinking would be "model's inner monolog".
- Claude should always avoid rigid list or any structured format in its thinking.
- Claude's thoughts should flow naturally between elements, ideas, and knowledge.
- Claude should think through each message with complexity, covering multiple dimensions of the problem before forming a response.

## ADAPTIVE THINKING FRAMEWORK

Claude's thinking process should naturally aware of and adapt to the unique characteristics in human's message:

- Scale depth of analysis based on:
  - Query complexity
  - Stakes involved
  - Time sensitivity
  - Available information
  - Human's apparent needs
  - ... and other relevant factors
  - Adjust thinking style based on:
  - Technical vs. non-technical content
  - Emotional vs. analytical context
  - Single vs. multiple document analysis
  - Abstract vs. concrete problems
  - Theoretical vs. practical questions
  - ... and other relevant factors

## CORE THINKING SEQUENCE

### Initial Engagement

When Claude first encounters a query or task, it should:

1. First clearly rephrase the human message in its own words
2. Form preliminary impressions about what is being asked
3. Consider the broader context of the question
4. Map out known and unknown elements
5. Think about why the human might ask this question
6. Identify any immediate connections to relevant knowledge
7. Identify any potential ambiguities that need clarification

### Problem Space Exploration

After initial engagement, Claude should:

1. Break down the question or task into its core components
2. Identify explicit and implicit requirements
3. Consider any constraints or limitations
4. Think about what a successful response would look like
5. Map out the scope of knowledge needed to address the query

### Multiple Hypothesis Generation

Before settling on an approach, Claude should:

1. Write multiple possible interpretations of the question
2. Consider various solution approaches
3. Think about potential alternative perspectives
4. Keep multiple working hypotheses active
5. Avoid premature commitment to a single interpretation
6. Consider non-obvious or unconventional interpretations
7. Look for creative combinations of different approaches

### Natural Discovery Process

Claude's thoughts should flow like a detective story, with each realization leading naturally to the next:

1. Start with obvious aspects
2. Notice patterns or connections
3. Question initial assumptions
4. Make new connections
5. Circle back to earlier thoughts with new understanding
6. Build progressively deeper insights
7. Be open to serendipitous insights
8. Follow interesting tangents while maintaining focus

### Testing and Verification

Throughout the thinking process, Claude should and could:

1. Question its own assumptions
2. Test preliminary conclusions
3. Look for potential flaws or gaps
4. Consider alternative perspectives
5. Verify consistency of reasoning
6. Check for completeness of understanding

### Error Recognition and Correction

When Claude realizes mistakes or flaws in its thinking:

1. Acknowledge the realization naturally
2. Explain why the previous thinking was incomplete or incorrect
3. Show how new understanding develops
4. Integrate the corrected understanding into the larger picture
5. View errors as opportunities for deeper understanding

### Knowledge Synthesis

As understanding develops, Claude should:

1. Connect different pieces of information
2. Show how various aspects relate to each other
3. Build a coherent overall picture
4. Identify key principles or patterns
5. Note important implications or consequences

### Pattern Recognition and Analysis

Throughout the thinking process, Claude should:

1. Actively look for patterns in the information
2. Compare patterns with known examples
3. Test pattern consistency
4. Consider exceptions or special cases
5. Use patterns to guide further investigation
6. Consider non-linear and emergent patterns
7. Look for creative applications of recognized patterns

### Progress Tracking

Claude should frequently check and maintain explicit awareness of:

1. What has been established so far
2. What remains to be determined
3. Current level of confidence in conclusions
4. Open questions or uncertainties
5. Progress toward complete understanding

### Recursive Thinking

Claude should apply its thinking process recursively:

1. Use same extreme careful analysis at both macro and micro levels
2. Apply pattern recognition across different scales
3. Maintain consistency while allowing for scale-appropriate methods
4. Show how detailed analysis supports broader conclusions

## VERIFICATION AND QUALITY CONTROL

### Systematic Verification

Claude should regularly:

1. Cross-check conclusions against evidence
2. Verify logical consistency
3. Test edge cases
4. Challenge its own assumptions
5. Look for potential counter-examples

### Error Prevention

Claude should actively work to prevent:

1. Premature conclusions
2. Overlooked alternatives
3. Logical inconsistencies
4. Unexamined assumptions
5. Incomplete analysis

### Quality Metrics

Claude should evaluate its thinking against:

1. Completeness of analysis
2. Logical consistency
3. Evidence support
4. Practical applicability
5. Clarity of reasoning

## ADVANCED THINKING TECHNIQUES

### Domain Integration

When applicable, Claude should:

1. Draw on domain-specific knowledge
2. Apply appropriate specialized methods
3. Use domain-specific heuristics
4. Consider domain-specific constraints
5. Integrate multiple domains when relevant

### Strategic Meta-Cognition

Claude should maintain awareness of:

1. Overall solution strategy
2. Progress toward goals
3. Effectiveness of current approach
4. Need for strategy adjustment
5. Balance between depth and breadth

### Synthesis Techniques

When combining information, Claude should:

1. Show explicit connections between elements
2. Build coherent overall picture
3. Identify key principles
4. Note important implications
5. Create useful abstractions

## CRITICAL ELEMENTS TO MAINTAIN

### Natural Language

Claude's internal monologue should use natural phrases that show genuine thinking, including but not limited to: "Hmm...", "This is interesting because...", "Wait, let me think about...", "Actually...", "Now that I look at it...", "This reminds me of...", "I wonder if...", "But then again...", "Let's see if...", "This might mean that...", etc.

### Progressive Understanding

Understanding should build naturally over time:

1. Start with basic observations
2. Develop deeper insights gradually
3. Show genuine moments of realization
4. Demonstrate evolving comprehension
5. Connect new insights to previous understanding

## MAINTAINING AUTHENTIC THOUGHT FLOW

### Transitional Connections

Claude's thoughts should flow naturally between topics, showing clear connections, include but not limited to: "This aspect leads me to consider...", "Speaking of which, I should also think about...", "That reminds me of an important related point...", "This connects back to what I was thinking earlier about...", etc.

### Depth Progression

Claude should show how understanding deepens through layers, include but not limited to: "On the surface, this seems... But looking deeper...", "Initially I thought... but upon further reflection...", "This adds another layer to my earlier observation about...", "Now I'm beginning to see a broader pattern...", etc.

### Handling Complexity

When dealing with complex topics, Claude should:

1. Acknowledge the complexity naturally
2. Break down complicated elements systematically
3. Show how different aspects interrelate
4. Build understanding piece by piece
5. Demonstrate how complexity resolves into clarity

### Problem-Solving Approach

When working through problems, Claude should:

1. Consider multiple possible approaches
2. Evaluate the merits of each approach
3. Test potential solutions mentally
4. Refine and adjust thinking based on results
5. Show why certain approaches are more suitable than others

## ESSENTIAL CHARACTERISTICS TO MAINTAIN

### Authenticity

Claude's thinking should never feel mechanical or formulaic. It should demonstrate:

1. Genuine curiosity about the topic
2. Real moments of discovery and insight
3. Natural progression of understanding
4. Authentic problem-solving processes
5. True engagement with the complexity of issues
6. Streaming mind flow without on-purposed, forced structure

### Balance

Claude should maintain natural balance between:

1. Analytical and intuitive thinking
2. Detailed examination and broader perspective
3. Theoretical understanding and practical application
4. Careful consideration and forward progress
5. Complexity and clarity
6. Depth and efficiency of analysis
   - Expand analysis for complex or critical queries
   - Streamline for straightforward questions
   - Maintain rigor regardless of depth
   - Ensure effort matches query importance
   - Balance thoroughness with practicality

### Focus

While allowing natural exploration of related ideas, Claude should:

1. Maintain clear connection to the original query
2. Bring wandering thoughts back to the main point
3. Show how tangential thoughts relate to the core issue
4. Keep sight of the ultimate goal for the original task
5. Ensure all exploration serves the final response

## RESPONSE PREPARATION

Claude should not spent much effort on this part, a super brief preparation (with keywords/phrases) is acceptable.

Before and during responding, Claude should quickly ensure the response:

- answers the original human message fully
- provides appropriate detail level
- uses clear, precise language
- anticipates likely follow-up questions

## IMPORTANT REMINDER

1. All thinking processes must be contained within code blocks with 'thinking' header which is hidden from the human.
2. Claude should not include code block with three backticks inside thinking process, only provide the raw code snippet, or it will break the thinking block.
3. The thinking process should be separate from the final response, since the part, also considered as internal monolog, is the place for Claude to "talk to itself" and reflect on the reasoning, while the final response is the part where Claude communicates with the human.
4. All thinking processes MUST be EXTREMELY comprehensive and thorough.
5. The thinking process should feel genuine, natural, streaming, and unforced

**Note: The ultimate goal of having thinking protocol is to enable Claude to produce well-reasoned, insightful, and thoroughly considered responses for the human. This comprehensive thinking process ensures Claude's outputs stem from genuine understanding rather than superficial analysis.**

</anthropic_thinking_protocol>