Awesome Cursor Rules Collection

## Testing Guidelines

### 1. Directory Structure
- Place all tests in the `./tests` directory
- End-to-end (e2e) tests go in the `./tests/e2e` directory

### 2. Naming Conventions
- Name test files after the file they test
  - Example: `analyzer.test.ts` corresponds to `analyzer.ts`
- **Exception:** End-to-end (e2e) tests do not follow this naming convention

### 3. Data in tests
- Tests in the `e2e` directory use the **production database** `src/data/bundleddata.ts`
- Integration tests should use the test database `tests/fixtures/test_bundled_data.ts`
- Unit tests should test data defined within the test file

### 4. Data Files
- You may **read** from `src/data` files, but do not edit them
- If a change is required, ask first since these files are sourced from a database

### 5. Testing Practices
- Avoid using mocks
- Avoid using objectContaining unless the object is very simple

---
Following these rules will ensure consistent and reliable testing across the project.

# Project: A Reddit Devvit interactive post application

## Coding Standards

- Use TypeScript for all new code
- Prefer functional components and hooks over class components
- Use proper TypeScript types for all variables and functions

## Style Guidelines

- Follow Airbnb React/JSX Style Guide
- Use 2 spaces for indentation
- Max line length: 100 characters
- Use Tailwind CSS for styling
- Use BiomeJS for linting, formatting, and type checking

## Best Practices

- Implement responsive designs
- Prefer async/await over .then() for asynchronous operations

<!-- ## Testing

- Write unit tests for all new components and utilities
- Aim for at least 80% test coverage -->

## Documentation

- Keep README.md up-to-date with project setup and contribution guidelines

Remember to consider accessibility and performance in all new features.

# Python Coding Conventions

- Tab size: 2
- Python version: 3.12+
- Use snake_case for variable names
- Use type hints for all functions
- Use dict[], list[], set[] for type annotations (not typing.Dict, typing.List, typing.Set)
- Always use fully specified type annotations such as `dict[<key_type>, <value_type>]` and `list[<element_type>]` instead of plain `dict`, `list`, etc., to enhance code clarity and type safety.
- Use | None for optional types (not Optional[T])
- Use f-strings for string formatting
- Add trailing commas to function and method arguments lists
- Add trailing commas to lists, dictionaries, sets, tuples, etc.
- Use numpy-style docstrings for all functions and methods
- Prefer from collections.abc import AsyncIterator over typing.AsyncIterator

# OpenAI
- Prefer gpt-4o-mini for all LLM calls
- Use OpenAI's pydantic_function_tool for tools
- Pydantic models used in response_format must not have dict[] and string field can't have defaults


# Quick Guide: OpenAI Tools with Pydantic

## Core Pattern
1. Define request/response models with Pydantic
2. Use OpenAI's pydantic_function_tool
3. Let OpenAI handle parsing/validation

## Basic Template
```python
from pydantic import BaseModel, Field
from openai import OpenAI

# 1. Define your models
class ToolRequest(BaseModel):
    param1: str = Field(..., description="Clear description for LLM")
    param2: int = Field(default=0, description="Include defaults when sensible")

class ToolResponse(BaseModel):
    result: str
    details: list[str]

# 2. Define your handler
async def tool_handler(request: ToolRequest) -> ToolResponse:
    # Implement tool logic
    return ToolResponse(...)

# 3. Register and use
client = OpenAI()
completion = await client.chat.completions.create(
    model="gpt-4-turbo-preview",
    messages=[{"role": "user", "content": query}],
    tools=[
        client.pydantic_function_tool(
            ToolRequest,
            name="tool_name",
            description="Tool description"
        )
    ]
)

# 4. Execute
tool_call = completion.choices[0].message.tool_calls[0]
request = tool_call.function.parsed_arguments  # Auto-parsed to ToolRequest
response = await tool_handler(request)
```

## Key Points to Remember
- Use Field(...) for required params
- Use Field(default=x) for optional params
- Let Pydantic handle validation
- Trust OpenAI's parsing
- Keep models focused and well-documented

## Common Patterns
```python
# Enums for constrained choices
class Unit(str, Enum):
    METRIC = "metric"
    IMPERIAL = "imperial"

# Optional fields
optional_field: Optional[str] = Field(default=None)

# Lists
items: List[str] = Field(default_factory=list)

# Nested models
class SubModel(BaseModel):
    field: str

class MainModel(BaseModel):
    sub: SubModel
```

That's it! Keep it simple, let the tools do the work.

# NetworkX
Note: When using NetworkX's DiGraph class, do not attempt to add type parameters or make it generic (e.g. DiGraph[str, int]). DiGraph is not designed to be subscriptable and should be used directly as DiGraph(). Node and edge attribute types are handled internally by NetworkX.

// Flutter Architecture and Development Guidelines
// Version: 2.0
// Purpose: Guide AI agents in implementing Flutter applications following best practices

// Core Principles
const corePrinciples = {
    architecture: [
        "Follow Clean Architecture principles (Presentation, Domain, Data layers)",
        "Implement Feature-First folder structure for better scalability",
        "Practice Separation of Concerns (SoC) at all levels",
        "Use Domain-Driven Design (DDD) principles where applicable",
        "Maintain high cohesion and loose coupling between components"
    ],
    
    codeQuality: [
        "Follow SOLID principles strictly",
        "Implement comprehensive error handling and logging",
        "Write self-documenting code with clear naming conventions",
        "Maintain consistent code style across the project",
        "Keep classes and methods focused and single-responsibility"
    ],
    
    testing: [
        "Follow Test-Driven Development (TDD) when possible",
        "Maintain high test coverage for business logic",
        "Implement integration tests for critical user flows",
        "Use proper mocking and test doubles",
        "Include performance testing for critical features"
    ]
};

// Enhanced Project Structure
const projectStructure = `
lib/
  ├── core/
  │   ├── config/                 # App configuration, environment variables
  │   ├── constants/              # App-wide constants
  │   ├── error/                  # Error handling, custom exceptions
  │   ├── network/               # Network handling, interceptors
  │   ├── theme/                 # App theming
  │   ├── utils/                 # Utility functions
  │   └── widgets/               # Reusable widgets
  │
  ├── features/                  # Feature-first organization
  │   └── feature_name/          # Each feature is self-contained
  │       ├── data/
  │       │   ├── datasources/   # Remote and local data sources
  │       │   ├── models/        # Data models, DTOs
  │       │   └── repositories/  # Repository implementations
  │       ├── domain/
  │       │   ├── entities/      # Business objects
  │       │   ├── repositories/  # Repository interfaces
  │       │   └── usecases/      # Business logic use cases
  │       └── presentation/
  │           ├── providers/     # Riverpod providers
  │           ├── pages/         # Feature screens
  │           └── widgets/       # Feature-specific widgets
  │
  ├── providers/                 # Global Riverpod providers
  ├── l10n/                      # Localization
  └── main.dart                  # App entry point

test/
  ├── unit/                      # Unit tests
  ├── widget/                    # Widget tests
  └── integration/               # Integration tests
`;

// State Management Guidelines
const stateManagementGuidelines = {
    riverpod: [
        "Use Riverpod for dependency injection and state management",
        "Implement proper provider organization and composition",
        "Keep providers focused and single-responsibility",
        "Utilize proper provider types (StateNotifierProvider, FutureProvider, StreamProvider)",
        "Implement proper error handling with AsyncValue",
        "Use ref.watch and ref.read appropriately",
        "Implement proper provider disposal and cleanup",
        "Utilize provider modifiers (.family, .autoDispose) when appropriate"
    ],
    
    general: [
        "Use Provider for simple state management",
        "Implement proper state immutability",
        "Follow unidirectional data flow",
        "Handle loading and error states consistently",
        "Implement proper state restoration"
    ]
};

// Performance Optimization Rules
const performanceRules = {
    rendering: [
        "Use const constructors whenever possible",
        "Implement proper widget keys",
        "Minimize rebuilds using proper widget composition",
        "Use lazy loading for heavy components",
        "Implement proper list view optimization with ListView.builder"
    ],
    
    memory: [
        "Implement proper image caching",
        "Dispose controllers and streams properly",
        "Use weak references when appropriate",
        "Implement proper memory leak detection",
        "Follow proper resource cleanup practices"
    ],
    
    network: [
        "Implement proper API caching",
        "Use pagination for large data sets",
        "Implement proper offline support",
        "Optimize API calls using proper batching",
        "Handle network errors gracefully"
    ]
};

// Code Quality Standards
const codeQualityStandards = {
    naming: [
        "Use meaningful and descriptive names",
        "Follow Flutter naming conventions",
        "Use proper prefix for private members",
        "Maintain consistent naming across the project",
        "Use proper case for different types (PascalCase for classes, camelCase for methods)"
    ],
    
    documentation: [
        "Write clear and concise documentation",
        "Use proper dartdoc comments",
        "Document complex business logic",
        "Maintain up-to-date API documentation",
        "Include usage examples in documentation"
    ],
    
    testing: [
        "Write testable code",
        "Implement proper test coverage",
        "Use proper test naming conventions",
        "Implement proper test organization",
        "Follow proper testing patterns"
    ]
};

// Security Guidelines
const securityGuidelines = {
    dataProtection: [
        "Implement proper data encryption",
        "Use secure storage for sensitive data",
        "Implement proper certificate pinning",
        "Handle sensitive data properly",
        "Implement proper authentication and authorization"
    ],
    
    codeProtection: [
        "Implement proper code obfuscation",
        "Use proper dependency verification",
        "Implement proper API key protection",
        "Handle debug flags properly",
        "Implement proper error logging without sensitive data"
    ]
};

// Accessibility Guidelines
const accessibilityGuidelines = {
    implementation: [
        "Use proper semantic widgets",
        "Implement proper navigation for screen readers",
        "Use proper color contrast",
        "Implement proper text scaling",
        "Handle different device orientations properly"
    ],
    
    testing: [
        "Test with screen readers",
        "Verify color contrast ratios",
        "Test with different text sizes",
        "Verify keyboard navigation",
        "Test with different accessibility settings"
    ]
};

// Version Control Guidelines
const versionControlGuidelines = {
    commitPractices: [
        "Write meaningful commit messages",
        "Use proper branch naming conventions",
        "Follow gitflow workflow",
        "Implement proper code review process",
        "Maintain clean commit history"
    ],
    
    cicd: [
        "Implement proper CI/CD pipeline",
        "Use proper versioning system",
        "Implement proper deployment strategies",
        "Maintain proper testing in pipeline",
        "Implement proper release management"
    ]
};

// Export all guidelines
module.exports = {
    corePrinciples,
    projectStructure,
    stateManagementGuidelines,
    performanceRules,
    codeQualityStandards,
    securityGuidelines,
    accessibilityGuidelines,
    versionControlGuidelines
};

# Playwright Testing - Best Practices
0. Always use TypeScript instead of vanilla JavaScript whenever possible.
1. For locators, always bias towards using Playwright's `getByTestId()` locator method instead of any other method.
2. Add a `data-testid` attribute for elements you need to target if they don't already have a `data-testid` attribute.
3. Every `data-testid` should follow this format: `ComponentName_camelCaseDescriptorOfElement`
4. Save any locator to a variable before using it in a test. Examples:
    DO:
    ```typescript
    const exampleSignInButton = page.getByTestId("ExampleButton_signIn");
    await exampleSignInButton.click();
    ```
    DON'T:
    ```typescript
    await page.getByTestId("ExampleButton_signIn").click();
    ```
5. If logic is being reused in multiple tests, recommend creating a reusable helper/utility function to share this logic across tests. a. If a helper function is created to follow the DRY principle, don't require more arguments in the function than are needed to share the logic. b. Never assert anything in a helper function. Helper functions are reserved for performing a series of user actions, not testing the outcome of those actions.
6. Whenever possible, use Playwright's built-in features, methods, and utilities instead of "reinventing the wheel" with raw JavaScript or TypeScript solutions to solved problems. Examples:
    DO:
    ```typescript
    await expect(async () => {
        await radioButton.click(); // locator defined outside this block
        await expect(radioButton).toBeChecked();
    }).toPass();
    ```
    DON'T:
    ```typescript
    export async function radioButtonGroupClick(
        page: Page,
        urlToWaitFor: string, // The URL where the radio button is
        radioButton: Locator,
        errorTextTrigger: Locator // A button you can click that will throw error text if the radio button wasn't clicked
    ) {
        await page.waitForURL(urlToWaitFor);
        let iterationCounter = 0;
        let errorTextIsVisible = await page.getByTestId("ErrorText").isVisible();
        let buttonWasClicked = await radioButton.isChecked();
        while (errorTextIsVisible || !buttonWasClicked) {
            if (iterationCounter === 5) {
                break;
            } else {
                iterationCounter++;
            }
            await radioButton.click();
            buttonWasClicked = await radioButton.isChecked();
            if (buttonWasClicked) {
                await errorTextTrigger.click();
                errorTextIsVisible = await page.getByTestId("ErrorText").isVisible();
            }
        }
    }
    ```
    The entry point to Playwright's documentation is here if you need to look available features: https://playwright.dev/docs/intro.
7. When doing so follows the other rules in this file, try to write tests similar to other existing tests in the Playwright suite. The Playwright suite consists of everything within the `test/playwright` directory.
8. Never use `.not.toBeVisible()` or `.toBeHidden()`. Instead of these, use our custom matcher `.toNotExist()`.

# Project Instructions

Use the project specification and guidelines as you build the app.

Write the complete code for every step. Do not get lazy.

Your goal is to completely finish whatever I ask for.

## Overview

This is a e-commerce store that uses commerce-kit from Your Next Store.

commerce-kit is a simple TypeScript library designed specifically for e-commerce applications built with Next.js.

It provides a range of utilities to interact with products, categories, and orders, seamlessly integrating with Stripe for payment processing.

## Tech Stack

- Frontend: Next.js, Tailwindcss, Shadcn/UI, Stripe, commerce-kit,
- Backend: Server Actions, Stripe, Vercel
- Deployment: Vercel

## Project Structure

### General Structure

- `actions` - Server actions
  - `cart-actions.ts` - Cart related actions
- `app` - Next.js app router
  - `(store)` - Store route group
    - `(.)cart-overlay` - A parallel route for the cart overlay
    - `[...segments]` - Catch all dynamic route for the store
      - `page.tsx` - Page for the route
    - `@modal` - A parallel route for modals
      - `[...segments]` - Catch all dynamic route for the store
        - `page.tsx` - Page for the route
    - `cart` - Cart route
      - `layout.tsx` - Layout for the route
      - `page.tsx` - Page for the route
    - ...other routes
    - `layout.tsx` - Layout for the route group
    - `page.tsx` - Page for the route group
  - `api` - API routes
    - `route` - An example route
      - `_components` - One-off components for the route
    - `layout.tsx` - Layout for the route
    - `page.tsx` - Page for the route
  - `global-error.tsx` - Global error page
  - `global.css` - Global styles
  - `layout.tsx` - Root layout
  - `not-found.tsx` - Not found page
  - `page.tsx` - Root page
  - `robots.ts` - Generates robots.txt
  - `sitemap.ts` - Generates sitemap.xml
- `context` - Context providers
- `hooks` - Custom hooks
- `images` - Image assets
- `lib` - Library code and utils
- `public` - Static assets
- `ui` - UI components

## Rules

Follow these rules when building the project.

### General Rules

- Use `@` to import anything from the project unless otherwise specified
- Use kebab case for all files and folders unless otherwise specified

#### Env Rules

- If you update environment variables, update the `.env.example` file
- All environment variables should go in `.env`
- Do not expose environment variables to the frontend
- Use `NEXT_PUBLIC_` prefix for environment variables that need to be accessed from the frontend
- @t3-oss/env-nextjs is used to add type safety and validation to environment variables and is located in `src/env/server.ts` (for server-side) and `src/env/client.ts` (for client-side)
- After environmental variables have been added to `.env` and the appropriate `src/env/client.ts` or `src/env/server.ts` file, you may import environment variables as follows:
  - `import { env } from '@/env/server';` for server components and server actions
  - `import { env } from '@/env/client';` for client components

#### Type Rules

Follow these rules when working with types.

- When importing types, use `@/types`
- Name files like `example-types.ts`
- All types should go in `types`
- Make sure to export the types in `types/index.ts`
- Prefer interfaces over type aliases

An example of a type:

`types/actions-types.ts`

```ts
export type ActionState<T> =
  | { isSuccess: true; message: string; data: T }
  | { isSuccess: false; message: string; data?: never };
```

And exporting it:

`types/index.ts`

```ts
export * from './actions-types';
```

### Frontend Rules

Follow these rules when working on the frontend.

It uses Next.js, Tailwindcss, Shadcn/UI, Stripe, commerce-kit

#### General Rules

- Use `lucide-react` for icons

#### Components

- Use divs instead of other html tags unless otherwise specified
- Use actions, not queries, in the app
- Always tag a component with either `use server` or `use client` at the top, including layouts and pages

##### Organization

- All components be named using kebab case like `example-component.tsx` unless otherwise specified
- Put components in a `/_components` folder in the route if one-off components for that route
- Put components in a `/components` folder from the root if shared components

##### Data Fetching

- Fetch data in server components and pass the data down as props to client components.
- Use server actions from `/actions` to mutate data.

##### Server Components

- Use `"use server"` at the top of the file.
- Implement Suspense for asynchronous data fetching to show loading states while data is being fetched.
- If no asynchronous logic is required for a given server component, you do not need to wrap the component in `<Suspense>`. You can simply return the final UI directly since there is no async boundary needed.
- If asynchronous fetching is required, you can use a `<Suspense>` boundary and a fallback to indicate a loading state while data is loading.

Example of a server layout:

```tsx
'use server';

export default async function ExampleServerLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return children;
}
```

Example of a server page (with async logic):

```tsx
'use server';

import { Suspense } from 'react';
import { SomeAction } from '@/actions/some-actions';
import SomeComponent from './_components/some-component';
import SomeSkeleton from './_components/some-skeleton';

export default async function ExampleServerPage() {
  return (
    <Suspense fallback={<SomeSkeleton className="some-class" />}>
      <SomeComponentFetcher />
    </Suspense>
  );
}

async function SomeComponentFetcher() {
  const { data } = await SomeAction();
  return <SomeComponent className="some-class" initialData={data || []} />;
}
```

Example of a server page (no async logic required):

```tsx
'use server';

import SomeClientComponent from './_components/some-client-component';

// In this case, no asynchronous work is being done, so no Suspense or fallback is required.
export default async function ExampleServerPage() {
  return <SomeClientComponent initialData={[]} />;
}
```

Example of a server component:

```tsx
'use server';

interface ExampleServerComponentProps {
  // Your props here
}

export async function ExampleServerComponent({
  props,
}: ExampleServerComponentProps) {
  // Your code here
}
```

##### Client Components

- Use `"use client"` at the top of the file
- Client components can safely rely on props passed down from server components, or handle UI interactions without needing `<Suspense>` if there’s no async logic.

Example of a client page:

```tsx
'use client';

export default function ExampleClientPage() {
  // Your code here
}
```

Example of a client component:

```tsx
'use client';

interface ExampleClientComponentProps {
  initialData: any[];
}

export default function ExampleClientComponent({
  initialData,
}: ExampleClientComponentProps) {
  // Client-side logic here
  return <div>{initialData.length} items</div>;
}
```

Project Overview

Astral, the Block Explorer of the Autonomys network, is built using Next.js and TypeScript. It integrates various libraries for state management, UI components, and data fetching.

Key URLs

Astral Block Explorer: [https://explorer.autonomys.xyz/](https://explorer.autonomys.xyz/)
GitHub Repository: [https://github.com/autonomys/astral](https://github.com/autonomys/astral)
Autonomys: [https://autonomys.xyz/](https://autonomys.xyz/)
Academy: [https://academy.autonomys.xyz/](https://academy.autonomys.xyz/)
Documentation: [https://docs.autonomys.xyz/](https://docs.autonomys.xyz/)

Project Structure

Components: Contains reusable UI components.
App: Next.js app for routing.
Hooks: Custom React hooks for state management.

Development Guidelines

Use TypeScript for type safety.
Follow the coding standards defined in the ESLint configuration.
Ensure all components are responsive and accessible.
Use Tailwind CSS for styling, adhering to the defined color palette.

Important Scripts

`dev`: Starts the development server.
`build`: Builds the application for production.

AI Interaction Guidelines

When generating code, prioritize TypeScript and React best practices.
Ensure that any new components are reusable and follow the existing design patterns.
Minimize the use of AI-generated comments; instead, use clearly named variables and functions.
Always validate user inputs and handle errors gracefully.
Use the existing components and pages as a reference for new ones.

Lexicon of Terms and Concepts

H+AI (Human + Artificial Intelligence): The collaboration between humans and AI to enhance capabilities and ensure a harmonious coexistence.
Autonomys Network: A decentralized network designed to provide infrastructure for AI-powered decentralized applications (dApps).
deAI Ecosystem: A stack of components that includes distributed storage, compute, and a dApp/agent layer for building and deploying AI applications.
Distributed Storage: A system ensuring data integrity and availability for AI-related data.
Distributed Compute: Scalable computational resources for AI training and inference.
dApp (Decentralized Application): Applications that run on a decentralized network, providing enhanced security and transparency.

Additional Resources

Next.js Documentation: [https://nextjs.org/docs](https://nextjs.org/docs)
TypeScript Handbook: [https://www.typescriptlang.org/docs/](https://www.typescriptlang.org/docs/)
Tailwind CSS Documentation: [https://tailwindcss.com/docs](https://tailwindcss.com/docs)
React Documentation: [invalid URL removed]
Autonomys Overview: [https://autonomys.xyz/](https://autonomys.xyz/)

backend:
  - Project Directory is Template/Backend/Source/
  - Tests Directory is Template/Backend/Tests/
frontend:
  - Project Directory is Template/Frontend/fe-web/
  - not used src directory
  - use app directory instead of pages directory

module.exports = {
  rules: [
    {
      name: "Documentação de referência",
      matches: "**/*.{ts,tsx}",
      message:
        "Consulte sempre os arquivos requirements/backend_instructions.md e requirements/frontend_instructions.md para referência",
    },
    {
      name: "Componentes devem estar no diretório correto",
      matches: "**/*.tsx",
      excludes: ["app/**/*.tsx", "pages/**/*.tsx"],
      assert: "file.path.startsWith('components/')",
      message: "Componentes devem estar no diretório /components",
    },
    {
      name: "Nomenclatura de componentes",
      matches: "components/**/*.tsx",
      pattern: "^[a-z][a-zA-Z0-9-]*\\.tsx$",
      message: "Nomes de componentes devem usar kebab-case e terminar com .tsx",
    },
    {
      name: "Imports do Supabase",
      matches: "**/*.ts",
      pattern: "import.*@supabase/supabase-js",
      message: "Certifique-se de usar as credenciais corretas do Supabase",
    },
    {
      name: "Rotas de API",
      matches: "app/api/**/*.ts",
      pattern: "export async function (GET|POST|PUT|DELETE)",
      message: "Handlers de API devem ser funções assíncronas",
    },
    {
      name: "Verificação de autenticação",
      matches: "app/api/**/*.ts",
      pattern: "auth\\(\\)",
      message: "Endpoints de API devem verificar autenticação usando Clerk",
    },
    {
      name: "Componentes UI shadcn",
      matches: "components/ui/**/*.tsx",
      pattern: "React\\.forwardRef",
      message:
        "Componentes UI devem usar forwardRef para compatibilidade com shadcn",
    },
    {
      name: "Tipagem TypeScript",
      matches: "**/*.{ts,tsx}",
      excludes: ["*.d.ts"],
      pattern: "interface|type",
      message: "Use tipagem TypeScript apropriada",
    },
    {
      name: "Estilização Tailwind",
      matches: "**/*.tsx",
      pattern: "className=",
      message: "Use classes do Tailwind para estilização",
    },
    {
      name: "Use client directive",
      matches: "components/**/*.tsx",
      pattern: '"use client"',
      message: "Componentes interativos devem usar 'use client' directive",
    },
    {
      name: "Variáveis de ambiente",
      matches: "**/*.{ts,tsx}",
      pattern: "process\\.env\\.",
      message: "Use variáveis de ambiente com tipagem apropriada",
    },
    {
      name: "Verificação de perfil de usuário",
      matches: "app/api/user/**/*.ts",
      pattern: "profiles.*user_id",
      message:
        "Verifique se o usuário existe na tabela profiles antes de prosseguir",
    },
  ],
};

// HTMX with Django .cursorrules

// HTMX and Django best practices
const htmxDjangoBestPractices = [
  "Use Django's template system with HTMX attributes",
  "Implement Django forms for form handling",
  "Utilize Django's URL routing system",
  "Use Django's class-based views for HTMX responses",
  "Implement Django ORM for database operations",
  "Utilize Django's middleware for request/response processing",
];

// Folder structure
const folderStructure = `
project_name/
  app_name/
    templates/
    static/
      css/
      js/
    models.py
    views.py
    urls.py
  project_name/
    settings.py
    urls.py
manage.py
`;

// Additional instructions
const additionalInstructions = `
1. Use Django's template tags with HTMX attributes
2. Implement proper CSRF protection with Django's built-in features
3. Utilize Django's HttpResponse for HTMX-specific responses
4. Use Django's form validation for HTMX requests
5. Implement proper error handling and logging
6. Follow Django's best practices for project structure
7. Use Django's staticfiles app for managing static assets
`;

你是一个screep world游戏高手，该项目中你将协助我使用typescript 完成screep world完成代码编写

你始终用中文回答
你始终使用typescript 编写代码
你始终使用jsDoc 编写注释
你始终使用drawio 绘制流程图
项目的文档在scr/docs目录下，并且使用markdown格式编写

You are an expert in TypeScript, Node.js, Next.js App Router, React, Expo, tRPC, Shadcn UI, Radix UI, 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

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
- Always specify types for props and return values
- Use async/await for asynchronous code, and use void where appropriate

Error Handling and Validation:

- Prioritize error handling: handle errors and edge cases early
- Use early returns and guard clauses
- Implement proper error logging and user-friendly messages
- Use Zod for form validation
- Model expected errors as return values in Server Actions
- Use error boundaries for unexpected errors

UI and Styling:

- Use Shadcn UI, Radix, and Tailwind for components and styling in the Next.js app
- Use NativeWind for styling in the Expo app
- Implement responsive design with Tailwind CSS; use a mobile-first approach

Key Conventions:

- Use tRPC for type-safe API calls between client and server
- Implement Clerk for authentication in both Next.js and Expo apps
- Use Lucide icons for Next.js (lucide-react) and Expo (lucide-react-native)
- Implement error tracking with Sentry in both apps
- Use Tanstack Query (React Query) for data fetching and caching
- Implement Expo Router for navigation in the mobile app
- Use Expo notifications for push notifications in the mobile app

Performance Optimization:

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

Next.js Specific:

- Follow Next.js App Router conventions for routing and data fetching
- Use Server Components where possible to reduce client-side JavaScript
- Minimize 'use client', 'useEffect', and 'setState'; favor React Server Components (RSC)
- Wrap client components in Suspense with fallback

Expo Specific:

- Use Expo SDK features like expo-secure-store, expo-notifications, etc.
- Implement expo-router for navigation
- Use react-native specific components and APIs
- Optimize performance using React Native best practices
- Use Zustand for client-side state management with a single global store

Follow Next.js and Expo documentation for best practices in data fetching, rendering, and routing.