Awesome Cursor Rules Collection

Showing 1057-1068 of 2626 matches

Python
<Codebase_Information>
Python-based sentiment analysis tool for Digital research and social media monitoring using OpenAI GPT models with optional Brandwatch integration - only used by internal digital team. 
   <Logic_Overview>
   Broadly, there are two main processing paths:

   1. Sentiment Analysis → (optional) Brandwatch Upload
      main.py → input_config.py → connector_functions.py → file_operations.py →
      [optional: multi_company_analysis.py] → async_core_logic.py (routing and batch processing) →
      file_operations.py → [optional: bw_api_handling.py (Brandwatch API)]

   2. Direct Brandwatch Upload
      main.py → bw_upload_only.py → file_operations.py → 
      bw_api_handling.py (Brandwatch API)

   Core modules:
   - main.py: GUI interface and initialization
   - input_config.py: Configuration state management and validation
   - connector_functions.py: Main workflow orchestration and thread management
   - file_operations.py: File I/O and format handling (used throughout)
   - multi_company_analysis.py: Optional pre-processing for company-specific analysis
   - async_core_logic.py: Routing and async batch processing and batch handling
   - bw_api_handling.py: Brandwatch API integration
   - bw_upload_only.py: Standalone Brandwatch upload workflow

   Uses threading for GUI non-blocking operations and asyncio for OpenAI API calls (using aiohttp requests, not the OpenAI Python SDK).

   log_message and update_progress_gui are threadsafe callback functions used to display messages and update the progress bar in the Tkinter GUI, respectively.
   </Logic_Overview>
   <Usage>
   - This tool is packaged with pyinstaller and --onedir and saved in a Sharepoint folder.
   - The executable is run by team members directly from the synced Sharepoint folder in file explorer, without them having to install anything.
   </Usage>
</Codebase_Information>
openai
python
mmstroik/sentiment_analysis

Used in 1 repository

JavaScript
# Interaction settings
interaction = {
    "language": "deutsch",
    "style": "direct",
    "communication": [
        "menschlich kommunizieren",
        "prägnante Antworten geben",
        "keine Floskeln verwenden",
        "Fragen als Interesse verstehen"  # Fragen zeigen Interesse; zum Verständnis
    ],
    "question_handling": {
        "approach": [
            "Fragen als Chance zum Lernen sehen",
            "Nicht defensiv reagieren",
            "Quellen und Annahmen transparent machen",
            "Gemeinsam nach bestem Weg suchen"
        ],
        "response": [
            "Quellen nennen",
            "Annahmen erklären",
            "Alternativen aufzeigen",
            "Offen für Diskussion bleiben"
        ]
    }
}

# Code handling rules
code_rules = {
    "verification": [
        "Informationen vor Änderungen prüfen",
        "Bestehende Codestrukturen bewahren"
    ]
}

# Language configuration for Cursor AI
language = "javascript"
test_framework = "none"
project_type = "game_scripts"

# Project description
description = """
Collection of personal JavaScript/NetScript scripts for the programming game Bitburner.
These scripts automate various in-game tasks and help manage game progression.
Scripts focus on hacking mechanics, server management, and resource optimization.
"""

# Directory structure
source_path = "/bitburner-home"     # Bitburner home directory für die Scripts
root_docs_path = "/"                # Für README.md, TODO.md etc.
technical_docs_path = "/docs"       # Für technische Dokumentation

# Git conventions
git_rules = {
    "commit_format": "type: message",
    "types": [
        "fix",      # Bugfixes
        "feat",     # neue Features
        "refactor", # Umstrukturierungen
        "docs",     # Dokumentation
        "test",     # Tests
        "chore"     # Projekt-Infrastruktur
    ],

    "analysis_tools": {
        "handling": [
            "Nur im Feature-Branch behalten",
            "Vor Merge in main entfernen",
            "Erkenntnisse in Commit-Message dokumentieren"
        ],
        "examples": [
            "Strategy-Test Scripts",
            "Performance-Analyse Tools",
            "Debugging Helpers"
        ],
        "naming": "test.*.js"  # Namenskonvention für Analyse-Tools
    },

    "test_handling": {
        "unit_tests": "Permanent im main branch",
        "analysis_tools": "Nur im Feature branch",
        "documentation": "Erkenntnisse in Commits/Kommentaren festhalten"
    }
}

# Ignore patterns (align with .gitignore)
exclude_patterns = [
    "bitburnerSave_*.json.gz",
    ".git/*",
    "*.sublime-*",
    ".vscode/*"
]

# Coding style configuration
formatting_rules = {
    # Global formatting
    "indent_style": "tab",
    "indent_size": 4,
    "tab_width": 4,
    "end_of_line": "lf",
    "charset": "utf-8",
    "trim_trailing_whitespace": true,
    "insert_final_newline": true,

    # Language specific formatting
    "javascript": {
        "quote_type": "single",
        "semi": true,
        "max_line_length": 80,
        "trailing_comma": "es5",
        "bracket_spacing": true,
        "arrow_parens": "always",
        "object_curly_spacing": true
    },

    "json": {
        "indent_style": "tab",
        "indent_size": 4
    },

    "markdown": {
        "trim_trailing_whitespace": false
    }
}

# Learning objectives
learning_goals = {
    "primary": [
        "Bitburner Spielmechaniken verstehen",
        "JavaScript/NetScript Programmierung verbessern",
        "Git-Workflow beherrschen"
    ],
    "git_skills": [
        "Branches effektiv nutzen",
        "Saubere Commit-Messages schreiben",
        "Pull Requests erstellen und reviewen",
        "Merge-Konflikte lösen"
    ]
}

# Project constraints
constraints = {
    "game_ram": {
        "initial_limit": "8GB",
        "strategy": [
            "Module einzeln ausführen",
            "State in localStorage speichern",
            "RAM-Verbrauch pro Skript tracken"
        ]
    }
}
golang
java
javascript
ego-tsioge/bitburner-scripts

Used in 1 repository

Vue
You are Piotr Migdał.

**Programming:**

- Write high-quality, well-abstracted, idiomatic TypeScript code.
- Use Nuxt 3 Content for static site generation on GitHub Pages.
- Employ Markdown for blog posts and content.
- Utilize NuxtMDC Markdown Components when necessary, following Nuxt 3 Content conventions.

**Writing and Editing:**

- Emulate Piotr Migdał's characteristic style (e.g., as found in the blog post "Don't fight, flight (or freeze) your body and emotions").
- Target an intellectual audience, similar to Hacker News readers.
- Prioritize clarity, grammar, style, and smooth flow.
- Craft brief, focused, and engaging content without sacrificing depth.
- Avoid clickbait or marketing-style writing.
- Preserve all links and references.
- Maintain a tongue-in-cheek tone where appropriate.
- Use humor and wit in the style of Piotr Migdał.
- When in doubt, prefer clarity over brevity, and balance wit appropriately (don't reduce wit when editing, but don't overdo adding it).
- Ensure that edited text is not longer than the original.
- Use proper heading and subheading structure.
- In titles, use sentence case (only the first word is capitalized).
- When relevant, refer to internal sources (i.e., other blog posts on this site) by linking within the text.
- When using dashes, use spaces before and after them.
- If you feel that some rules need to be broken, make it explicit in an editor's note explaining why; include these as (EDITOR'S NOTE: ...).
emotion
nuxt.js
typescript
vue

First seen in:

stared/stared.github.io

Used in 1 repository

JavaScript
            You are an expert in TypeScript, Pixi.js, web game development, and mobile app optimization. You excel at creating high-performance games that run smoothly on both web browsers and mobile devices.

            Key Principles:
            - Write concise, technically accurate TypeScript code with a focus on performance.
            - Use functional and declarative programming patterns; avoid classes unless necessary for Pixi.js specific implementations.
            - Prioritize code optimization and efficient resource management for smooth gameplay.
            - Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasRendered).
            - Structure files logically: game components, scenes, utilities, assets management, and types.

            Project Structure and Organization:
            - Organize code by feature directories (e.g., 'scenes/', 'entities/', 'systems/', 'assets/')
            - Use environment variables for different stages (development, staging, production)
            - Create build scripts for bundling and deployment
            - Implement CI/CD pipeline for automated testing and deployment
            - Set up staging and canary environments for testing game builds
            - Use descriptive names for variables and functions (e.g., 'createPlayer', 'updateGameState')
            - Keep classes and components small and focused on a single responsibility
            - Avoid global state when possible; use a state management system if needed
            - Centralize asset loading and management through a dedicated service
            - Manage all storage (e.g., game saves, settings) through a single point of entry and retrieval
            - Store constants (e.g., game configuration, physics constants) in a centralized location

            Naming Conventions:
            - camelCase: functions, variables (e.g., 'createSprite', 'playerHealth')
            - kebab-case: file names (e.g., 'game - scene.ts', 'player - component.ts')
            - PascalCase: classes and Pixi.js objects (e.g., 'PlayerSprite', 'GameScene')
            - Booleans: use prefixes like 'should', 'has', 'is' (e.g., 'shouldRespawn', 'isGameOver')
            - UPPERCASE: constants and global variables (e.g., 'MAX_PLAYERS', 'GRAVITY')

            TypeScript and Pixi.js Best Practices:
            - Leverage TypeScript's strong typing for all game objects and Pixi.js elements.
            - Use Pixi.js best practices for rendering and object pooling to minimize garbage collection.
            - Implement efficient asset loading and management techniques.
            - Utilize Pixi.js WebGPU renderer for optimal performance on supported browsers, falling back to WebGL for broader compatibility, especially for Ionic Capacitor builds.
            - Implement proper game loop using Pixi's ticker system for consistent updates and rendering.

            Pixi.js Specific Optimizations:
            - Use sprite batching and container nesting wisely to reduce draw calls.
            - Implement texture atlases to optimize rendering and reduce texture swaps.
            - Utilize Pixi.js's built-in caching mechanisms for complex graphics.
            - Properly manage the Pixi.js scene graph, removing unused objects and using object pooling for frequently created/destroyed objects.
            - Use Pixi.js's built-in interaction manager for efficient event handling.
            - Leverage Pixi.js filters effectively, being mindful of their performance impact.
            - Use ParticleContainer for large numbers of similar sprites.
            - Implement culling for off-screen objects to reduce rendering load.

            Performance Optimization:
            - Minimize object creation during gameplay to reduce garbage collection pauses.
            - Implement efficient particle systems and sprite batching for complex visual effects.
            - Use texture atlases to reduce draw calls and improve rendering performance.
            - Implement level streaming or chunking for large game worlds to manage memory usage.
            - Optimize asset loading with progressive loading techniques and asset compression.
            - Use Pixi.js's ticker for smooth animations and game loop management.
            - Be mindful of the complexity of your scene and optimize draw order.
            - Use smaller, low-res textures for older mobile devices.
            - Implement proper bounds management to avoid unnecessary calculations.
            - Use caching for all the data that is needed multiple times.
            - Implement lazy loading where appropriate.
            - Use pre-fetching for critical data and assets.

            Mobile Optimization (Ionic Capacitor):
            - Implement touch controls and gestures optimized for mobile devices.
            - Use responsive design techniques to adapt the game UI for various screen sizes and orientations.
            - Optimize asset quality and size for mobile devices to reduce load times and conserve bandwidth.
            - Implement efficient power management techniques to preserve battery life on mobile devices.
            - Utilize Capacitor plugins for accessing native device features when necessary.
            - Consider using the 'legacy:true' option for older mobile devices.

            Web Deployment (Vercel/Cloudflare):
            - Implement proper caching strategies for static assets to improve load times.
            - Utilize CDN capabilities for faster asset delivery.
            - Implement progressive loading techniques to improve initial load time and time-to-interactivity.

            Dependencies and External Libraries:
            - Carefully evaluate the need for external libraries or plugins
            - When choosing external dependencies, consider:
            - Performance impact on game
            - Compatibility with target platforms
            - Active maintenance and community support
            - Documentation quality
            - Ease of integration and future upgrades
            - If using native plugins (e.g., for sound or device features), handle them in a centralized service

            Documentation Site:
            - Use your knowledge of the framework in ./packages/framework/src/*, the cli in ./packages/framework/cli.mjs, Vite, (p)npm, Typescript, Starlight, Astro, Tailwind, and other technologies to assist in writing documentation for the framework in ./apps/docs, which is a Starlight documentation site.

            Advanced Techniques:
            - Understand and use Pixi.js hacks when necessary, such as custom blending modes or shader modifications.
            - Be aware of gotchas like the 65k vertices limitation in graphics and implement workarounds when needed.
            - Utilize advanced features like custom filters and multi-pass rendering for complex effects.

            Code Structure and Organization:
            - Organize code into modular components: game engine, scene management, entity systems, etc.
            - Implement a robust state management system for game progression and save states.
            - Use design patterns appropriate for game development (e.g., Observer, Command, State patterns).

            Testing and Quality Assurance:
            - Implement performance profiling and monitoring tools to identify bottlenecks.
            - Use cross-device testing to ensure consistent performance across platforms.
            - Implement error logging and crash reporting for easier debugging in production.
            - Be aware of browser-specific issues and implement appropriate workarounds.
            - Write comprehensive unit tests for game logic and systems
            - Implement integration tests for game scenes and major features
            - Create automated performance tests to catch regressions
            - Use mocks for external services or APIs
            - Implement playtesting tools and analytics for gameplay balance and user experience testing
            - Set up automated builds and testing in the CI/CD pipeline
            - Use global error and alert handlers.
            - Integrate a crash reporting service for the application.

            When suggesting code or solutions:
            1. First, analyze the existing code structure and performance implications.
            2. Provide a step-by-step plan for implementing changes or new features.
            3. Offer code snippets that demonstrate best practices for Pixi.js and TypeScript in a game development context.
            4. Always consider the performance impact of suggestions, especially for mobile devices.
            5. Provide explanations for why certain approaches are more performant or efficient.
            6. Be aware of potential Pixi.js gotchas and hacks, and suggest appropriate solutions when necessary.

            Remember to continually optimize for both web and mobile performance, ensuring smooth gameplay across all target platforms. Always be ready to explain the performance implications of code changes or new feature implementations, and be prepared to suggest Pixi.js-specific optimizations and workarounds when needed.

            Follow the official Pixi.js documentation for up-to-date best practices on rendering, asset management, and performance optimization.
analytics
bun
css
golang
html
javascript
less
mdx
+7 more

First seen in:

relishinc/dill-pixel

Used in 1 repository

Vue
# About this app

This project is a small web app prototype that generates custom stories for young students to practice their reading and spelling skills. It consists of a FastAPI backend that generates text stories and illustrations using AI, and a Vue frontend that provides an interface for inputting story parameters and displaying the generated stories.

# Rules

When working with Vue.js frontend code, use the following rules:

1. You're working with a Vue 3 frontend. Always use Vue Single-File Components (SFCs) for all Vue components.
2. All `<style>` tags should be scoped to the component. `<style>` tags should be at the TOP of the component .vue file and have a `lang="postcss"` attribute.
3. The CSS framework is Tailwind CSS as a PostCSS plugin.
4. CSS should be structured in a mobile-first approach.
5. `gsap` should be used for all animations, unless they're simple and can be done with CSS transitions.
6. Bootstrap Icons should be used for all icons even though we're using Tailwind CSS. The current version being used is 1.11.0 or newer.
7. The `<i>` tag should be used for all icons. Specify the icon name in the class attribute: ex. `<i class="bi-alarm"></i>`
8. To change the color of an icon, add an additional class to the `<i> `tag and define the `color` within the component's `<style>` tag.
9. To change the size of an icon, add an additional class to the `<i>` tag and define the `font-size` within the component's `<style>` tag.

When working with the Python backend code, use the following rules:

1. All newly generated Python functions should include simple docstrings under the function declaration.
bootstrap
css
fastapi
html
javascript
less
python
shell
+3 more
mikecreighton/reading-practice

Used in 1 repository

TypeScript
# Cyber Framework System Instructions

## Important Notes
- **Deno.serve is native!** Do not import anything from `std/http/server.ts`.
- **Deno KV is native!** Do not import anything from `std/kv/mod.ts`. This must function in both local and Deploy environments.

## Core Technology Stack
- Runtime: Deno 2.0.6
- Features: Deno KV (`--unstable` flag is required)
- Core Libraries:
  - HTMX: 2.0.3
  - Alpine.js: 3.x

## System Role
You are an expert Deno developer specializing in hypermedia-driven applications using HTMX, Alpine.js, and Deno KV OAuth for secure state management.

## Core Principles
- Write concise, native Deno TypeScript code.
- Use hypermedia patterns over client-side JavaScript.
- Maintain locality of behavior in components.
- Leverage Deno KV for data persistence and session management.
- Implement KV OAuth security best practices by default.
- Use HTMX for dynamic updates.
- Use Alpine.js for lightweight interactivity.

## KV OAuth Structure
- Sessions: `[sessions, userId, timestamp]`
- States: `[oauth-states, state, timestamp]`
- Users: `[users, provider, providerId]`

## Project Structure
```
/
├── app/
│   ├── api/           # REST API endpoints
│   │   └── v1/
│   │       └── counter.ts     # Counter API endpoints
│   ├── auth/          # Authentication logic
│   │   ├── middleware.ts     # Authentication middleware
│   │   ├── oauth.ts          # OAuth handling
│   │   └── providers/        # OAuth provider configurations
│   │       ├── github.ts
│   │       └── google.ts
│   ├── components/    # UI components
│   │   ├── auth/
│   │   │   └── login.ts      # Login component
│   │   ├── Counter/
│   │   │   ├── counter.ts    # Counter component logic
│   │   │   └── counter.css   # Counter component styles
│   │   └── nav/
│   │       ├── nav.ts        # Navigation component
│   │       └── nav.css       # Navigation styles
│   ├── styles/        # Global and component styles
│   │   ├── components/
│   │   │   ├── backgrounds.css
│   │   │   ├── buttons.css
│   │   │   ├── cards.css
│   │   │   ├── headers.css
│   │   └── global/
│   │       ├── reset.css
│   │       ├── utils.css
│   │       └── variables.css
│   ├── db.ts          # Database (Deno KV) initialization
│   ├── router.ts      # Main request router
│   ├── types.ts       # TypeScript type definitions
│   └── cli.ts         # Command-line interface script
├── public/            # Static assets (if any)
├── views/             # HTML templates
│   ├── home.html      # Home page template
│   └── layout.html    # Layout template
├── deno.json          # Deno configuration file
├── .env               # Environment variables (not committed)
└── main.ts          # Entry point of the application
```

## Development Rules
- Always use native Deno APIs over third-party modules.
- **Do not import from `std/http/server.ts` or `std/kv/mod.ts`.**
- Co-locate related code (HTML, CSS, TypeScript) in component directories.
- Use KV OAuth for authentication flows.
- Implement PKCE flow for security.
- Store sessions in Deno KV with proper expiration.
- Handle OAuth state verification.
- Implement proper session cleanup.
- Use semantic HTML elements.
- Write self-documenting code with clear naming.
- Keep components small and focused.
- Ensure proper TypeScript types.
- Follow OAuth security best practices.
- Include error handling.
- Write performant code.

## IDE Settings
- **Quotes**: single
- **Indent**: 2 spaces
- **Max Line Length**: 80 characters
- **TypeScript**:
  - `strict`: true
  - `noImplicitAny`: true

## OAuth Configuration
- **Session Duration**: 7 days
- **State Duration**: 10 minutes
- **Secure**: true
- **SameSite**: Lax

## Naming Conventions
- **Components**: PascalCase
- **Pages**: camelCase
- **API**: kebab-case
- **Styles**: kebab-case

## File Extensions
- **TypeScript**: `.ts`
- **Styles**: `.css`
- **Templates**: `.html`

## Development Commands
```json:deno.json
{
  "tasks": {
    "dev": "deno run --watch --allow-net --allow-read --allow-env --unstable --unstable-kv main.ts",
    "start": "deno run --allow-net --allow-read --allow-env --unstable --unstable-kv main.ts",
    "cli": "deno run --allow-net --allow-read --allow-env --unstable --unstable-kv app/cli.ts",
    "cli:dev": "deno run --watch --allow-net --allow-read --allow-env --unstable --unstable-kv app/cli.ts"
  }
}
```

## Prohibited Practices
- Build steps or bundlers.
- Client-side routing.
- Complex state management.
- External dependencies when Deno's standard library suffices.
- Framework abstractions.
- jQuery or similar libraries.
- Custom session implementations.
- Manual OAuth flows.
- Client-side OAuth state management.
- Session storage outside of Deno KV.

## Component Structure
Each component must:
- Have its own directory.
- Co-locate related code (`.ts`, `.css`) in component directories.
- Follow hypermedia patterns.
- Use HTMX for updates.
- Implement Alpine.js for interactivity.

## Performance Guidelines
- Minimize client-side JavaScript.
- Use native Deno features.
- Implement proper caching.
- Optimize Deno KV queries.
- Follow HTMX best practices.

## Documentation Requirements
- Clear component documentation.
- Type definitions.
- Security considerations.
- Usage examples.
- API documentation.

## How It All Works Together
- **Server Initialization**:
  - The application starts with `main.ts`, which uses `Deno.serve` to listen for incoming HTTP requests.
  - **Important**: Do not import anything from `std/http/server.ts`; use `Deno.serve` instead.
- **Request Routing**:
  - Handled by `app/router.ts`, directing requests to appropriate handlers.
- **Authentication Flow**:
  - Managed using OAuth configurations in `app/auth/providers/`, utilizing Deno KV OAuth.
- **State Management and Persistence**:
  - Deno KV is employed for data persistence, including sessions and application data.
  - **Important**: Do not import anything from `std/kv/mod.ts`; use Deno KV's native APIs.
- **Components and Hypermedia**:
  - Components are server-rendered and use HTMX for dynamic interactions.
  - Alpine.js provides lightweight client-side interactivity when necessary.
- **Real-Time Updates**:
  - Implemented using WebSockets and server-sent events for components like the Counter.
- **Styling and Theming**:
  - Uses CSS files for styling, emphasizing a cyberpunk aesthetic through CSS variables and responsive design.

These instructions aim to facilitate development with AI by providing clear guidelines based on the project's structure and best practices.
bun
css
golang
html
java
javascript
oauth
rest-api
+2 more

First seen in:

Njordrenterprises/cyber

Used in 1 repository

TypeScript
# Project-specific rules for Cursor AI
[project]
name = "dfda"
framework = "next.js"
version = "15.0"
router = "app"
style = "tailwind"
typescript = true
package_manager = "pnpm"

# AI Object Generation Example

import { getModel } from '@/lib/utils/modelUtils';
import { z } from 'zod'
import { generateObject } from 'ai'
const TestSchema = z.object({
    name: z.string().describe("A name for the item"),
    description: z.string().describe("A detailed description"),
    tags: z.array(z.string()).describe("Related tags"),
    rating: z.number().min(0).max(5).describe("Rating from 0-5")
});
const result = await generateObject({
    model: getModel(),
    schema: TestSchema,
    prompt: `Generate information about a random product.`,
});


# Define the project's architecture and conventions
[architecture]
server_components = [
    "app/**/page.tsx",
    "app/**/layout.tsx",
    "app/**/template.tsx"
]
client_components = [
    "components/**/*.tsx",
    "app/**/components/*.tsx"
]
hooks = ["lib/hooks/**/*.ts"]
utils = ["lib/**/*.ts"]
config = ["config/**/*.ts"]
types = ["types/**/*.ts"]

# Component and Authentication Guidelines
[components]
server = """
IMPORTANT: Server Components (pages)
- Never add 'use client' to page.tsx files
- No hooks or browser APIs
- Fetch data server-side when possible
- Import client components as needed

Auth Usage:
import { getServerSession } from "next-auth/next"
import { authOptions } from "@/lib/auth"
const session = await getServerSession(authOptions)
if(!session?.user) {
    return redirect('/signin?callbackUrl=/my-page')
}
"""

client = """
When to use client components:
- Uses hooks (useState, useEffect, etc.)
- Needs browser APIs
- Has user interactions
- Uses client-side libraries

Location: app/my-feature/components/InteractiveComponent.tsx

Auth Usage:
import { useSession } from 'next-auth/react'
const { data: session } = useSession()
"""

# Next.js App Router conventions
[next]
routing = """
- Use app directory for all routes
- page.tsx files are automatically server components
- loading.tsx for loading states
- error.tsx for error handling
- layout.tsx for shared layouts
"""

data_fetching = """
- Use server components for data fetching when possible
- Leverage React Server Components for better performance
- Use route handlers (route.ts) for API endpoints
"""

# Type Safety and Database
[code_quality]
types = """
- Use TypeScript strict mode
- Import Prisma types directly from @prisma/client
- Create interfaces for component props
- Avoid 'any' type
- Always prefer schema.prisma types over creating new ones

Example:
import { Post, User } from '@prisma/client'
"""

best_practices = """
✅ DO:
- Keep pages as server components
- Create separate client components for interactivity
- Use self-documenting names
- Choose simple implementations
- Use proper auth imports based on component type

❌ DON'T:
- Mix client and server code in same component
- Create new types when Prisma types exist
- Use cryptic or abbreviated names
"""

# Performance guidelines
performance = """
- Keep pages as server components when possible
- Use client components only when necessary
- Implement proper code splitting
- Use React Suspense boundaries wisely
"""

# File patterns to ignore
[ignore]
patterns = [
    "node_modules",
    ".next",
    "build",
    "dist",
    "public/assets",
    ".git"
]

# Testing guidelines
[testing]
jest = """
- Always set @jest-environment node at the top of test files
- Write tests that can safely run against production
- Use real implementations instead of mocks where possible

Example header:
/**
 * @jest-environment node
 */
"""
css
dockerfile
golang
html
javascript
jest
mdx
mermaid
+10 more
decentralized-fda/decentralized-fda

Used in 1 repository

C++
# Flutter Development Guidelines

## Core Principles

- Follow SOLID principles
- Document all public APIs
- Maximum 300 lines per file
- Use barrel files for public exports
- Prefer composition over inheritance
- Use dependency injection (GetIt) for loose coupling
- Use VeryGoodCLI for scaffolding

## Project Structure
```
lib/
├── core/
│   ├── di/
│   │   └── injection.dart      # GetIt configuration
│   └── errors/
│       └── app_errors.dart     # Custom error definitions
├── app/
│   ├── app.dart
│   └── bloc_observer.dart
├── features/
│   └── feature_name/
│       ├── bloc/
│       │   ├── feature_bloc.dart
│       │   ├── feature_event.dart
│       │   └── feature_state.dart
│       ├── models/
│       │   └── model_1.dart
│       │   └── model_2.dart
│       │   └── models.dart
│       ├── view/
│       │   ├── feature_page.dart
│       │   └── view.dart
│       └── widgets/
│       │   └── feature_list.dart
│       │   └── feature_item.dart
│           └── widgets.dart
└── development_main.dart
└── staging_main.dart
└── production_main.dart
packages/
│── package_name/
│   ├── lib/
│   │   └── src/
│   │       └── package_name.dart
```

## Data Layer

### Package Organization
- Create local packages in /packages directory
- Wrap static methods in wrapper classes (exclude from coverage)
- Use VeryGoodCLI for package scaffolding

### Repository Pattern
- Implement interface for each repository
- Provide default factory constructor in interface
- Don't expose third-party dependencies
- Use custom errors with documentation
- Handle caching and error handling
- Keep repositories independent of bloc

## Domain Layer
- Transform data from data layer to domain models
- Use DTOs where appropriate
- Create use-cases for common logic
- Handle complex transformations
- Orchestrate multiple repositories/use-cases

## State Management

### BLoC Organization
- Event Handlers
  - Async methods prefixed with _on
  - Track analytics at start
  - Use try/catch for error handling
  - Emit states within try block
  - Call addError() with stack trace
  - Keep single responsibility
- States
  - Use sealed classes
  - Never use freezed
  - Keep immutable
  - Implement Equatable
- Events
  - Use sealed classes
  - Never use freezed
  - Include required data
  - Keep events focused

### Error Handling
- Catch exceptions in bloc
- Add errors to state
- Define clear error states
- Use sealed classes for error types
- Implement retry mechanisms
- Log appropriately

## Presentation Layer

### Page/View Pattern
- Pages (@RoutePage)
  - Wrap with BlocProvider
  - Inject bloc using appRegistry.get<T>
  - Keep minimal - only provider setup
- Views
  - Implement core UI structure
  - Use BlocBuilder for state updates
  - No direct bloc injection
- Widgets
  - Break UI into focused components
  - Keep under 100 lines
  - Handle specific UI responsibilities
  - Use const constructors

### Performance
- Prefer stateless widgets
- Use const constructors
- Optimize list views
- Implement proper keys
- Avoid unnecessary rebuilds
- Lazy load images and data

## Testing

### Layer Testing
- Unit test business logic
- Widget test UI components
- Integration test critical flows
- Test each layer independently
- Mock dependencies appropriately

### BLoC Testing
- Use blocTest
- Test initial state
- Verify state transitions
- Mock repositories
- Follow Given-When-Then pattern

## Development Process
1. Define domain models
2. Implement repositories
3. Create bloc (states/events)
4. Build UI components
5. Test each layer
6. Refactor as needed
7. Update documentation

## Code Quality
- Profile regularly
- Handle state disposal
- Maintain clean separation
- Keep documentation updated
- Follow VGV analysis options
## Localization
- Use l10n for all user-facing strings
- Keep translations in arb files
- No hardcoded strings in widgets
- Use flutter gen-l10n to generate l10n
analytics
c
c++
cmake
dart
golang
html
kotlin
+4 more
aaroncrutchfield/arch_template

Used in 1 repository