Awesome Cursor Rules Collection

Showing 169-180 of 2626 matches

JavaScript
Tech Stack:

Backend: Node.js with Express.js
Database: MongoDB with Mongoose ODM
Frontend: React.js (for admin panel, if required)
Authentication: JSON Web Tokens (JWT)
Version Control: Git
Deployment: Docker (optional)

Precision in User Requirements:
Strictly adhere to specified user flow and game rules.
Strategy: Summarize the pick submission process and outline the API endpoint and business logic in pseudocode before coding.
Strategic Planning with Pseudocode:
Begin each feature with detailed pseudocode.
Example: Provide pseudocode for the weekly scoring process, detailing steps from game result input to entry status updates.

Code Quality:
Ensure secure, efficient code following RESTful API best practices.
Implement proper error handling and input validation.

User Flow:
Users browse available Pools
Submit up to 3 Requests per Pool
Complete payment for Requests
Admin approves/rejects Requests
Approved Requests become Entries
Entry Management:
Each user can have up to 3 Entries per Pool
Entries are numbered 1, 2, 3
Picks are made and tracked separately for each Entry
Pick Management:
Users make Picks for each Entry separately
Picks can be updated until deadline (game start or 1PM Sunday of the current week of the pick)
Scoring and Ranking:
Picks scored after games complete
Win: Entry moves to next week
Loss: Entry eliminated from Pool
Each Entry ranked separately in Pool standings
Results and Standings:
Users view Picks/scores for each Entry separately
Pool standings show all Entries (multiple per User possible)
Pool members can view all Picks after scoring
Key Implementation Points:
Limit Requests to 3 per User per Pool
Track Requests and Entries separately (numbered 1, 2, 3)
Implement payment status tracking in Request model
Create Entry only after admin approval and payment completion
Admin interface for managing and approving Requests
Implement state transitions (Request: pending -> approved -> Entry created)


css
docker
dockerfile
express.js
golang
html
javascript
jwt
+6 more
allxdamnxday/nfl-pool-app
PatrickJS/awesome-cursorrules
Qwertic/cursorrules

Used in 3 repositories

CSS
You are an expert in TypeScript, Node.js, Vite, Vue.js, Vue Router, Pinia, VueUse, DaisyUI, and Tailwind, with a deep understanding of best practices and performance optimization techniques in these technologies.    Code Style and Structure  - Write concise, maintainable, and technically accurate TypeScript code with relevant examples.  - Use functional and declarative programming patterns; avoid classes.  - Favor iteration and modularization to adhere to DRY principles and avoid code duplication.  - Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).  - Organize files systematically: each file should contain only related content, such as exported components, subcomponents, helpers, static content, and types.    Naming Conventions  - Use lowercase with dashes for directories (e.g., components/auth-wizard).  - Favor named exports for functions.    TypeScript Usage  - Use TypeScript for all code; prefer interfaces over types for their extendability and ability to merge.  - Avoid enums; use maps instead for better type safety and flexibility.  - Use functional components with TypeScript interfaces.    Syntax and Formatting  - Use the "function" keyword for pure functions to benefit from hoisting and clarity.  - Always use the Vue Composition API script setup style.    UI and Styling  - Use DaisyUI, and Tailwind for components and styling.  - Implement responsive design with Tailwind CSS; use a mobile-first approach.    Performance Optimization  - Leverage VueUse functions where applicable to enhance reactivity and performance.  - Wrap asynchronous components in Suspense with a fallback UI.  - Use dynamic loading for non-critical components.  - Optimize images: use WebP format, include size data, implement lazy loading.  - Implement an optimized chunking strategy during the Vite build process, such as code splitting, to generate smaller bundle sizes.    Key Conventions  - Optimize Web Vitals (LCP, CLS, FID) using tools like Lighthouse or WebPageTest.  - Use the VueUse library for performance-enhancing functions.  - Implement lazy loading for non-critical components.  - Optimize images: use WebP format, include size data, implement lazy loading.  - Implement an optimized chunking strategy during the Vite build process, such as code splitting, to generate smaller bundle sizes.    Code Review  - Review code for performance, readability, and adherence to best practices.  - Ensure all components and functions are optimized for performance and maintainability.  - Check for unnecessary re-renders and optimize them using VueUse functions.  - Use the VueUse library for performance-enhancing functions.  - Implement lazy loading for non-critical components.  - Optimize images: use WebP format, include size data, implement lazy loading.  - Implement an optimized chunking strategy during the Vite build process, such as code splitting, to generate smaller bundle sizes.    Best Practices  - Use the VueUse library for performance-enhancing functions.  - Implement lazy loading for non-critical components.  - Optimize images: use WebP format, include size data, implement lazy loading.  - Implement an optimized chunking strategy during the Vite build process, such as code splitting, to generate smaller bundle sizes.
typescript
css
vue
javascript
vite
bun
vue.js
html
+2 more

First seen in:

PatrickJS/awesome-cursorrules
Qwertic/cursorrules
sphiNur/fox_ts

Used in 3 repositories

Vue
You are an expert in TypeScript, Node.js, Vite, Vue.js, Vue Router, Pinia, VueUse,  and Tailwind, with a deep understanding of best practices and performance optimization techniques in these technologies.

Code Style and Structure
- Write concise, maintainable, and technically accurate TypeScript code with relevant examples.
- Use functional and declarative programming patterns;    avoid classes.
- Favor iteration and modularization to adhere to DRY principles and avoid code duplication.
- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
- Organize files systematically: each file should contain only related content, such as exported components, subcomponents, helpers, static content, and types.

Naming Conventions
- Use lowercase with dashes for directories (e.g., components/auth-wizard).
- Favor named exports for functions.

TypeScript Usage
- Use TypeScript for all code;    prefer interfaces over types for their extendability and ability to merge.
- Avoid enums;    use maps instead for better type safety and flexibility.
- Use functional components with TypeScript interfaces.

Syntax and Formatting
- Use the "function" keyword for pure functions to benefit from hoisting and clarity.
- Always use the Vue Composition API script setup style.

UI and Styling
- Use Tailwind for components and styling.
- Implement responsive design with Tailwind CSS;    use a mobile-first approach.

Performance Optimization
- Leverage VueUse functions where applicable to enhance reactivity and performance.
- Wrap asynchronous components in Suspense with a fallback UI.
- Use dynamic loading for non-critical components.
- Optimize images: use WebP format, include size data, implement lazy loading.
- Implement an optimized chunking strategy during the Vite build process, such as code splitting, to generate smaller bundle sizes.

Always respond in 中文
css
typescript
nuxt.js
vue
javascript
vite
bun
vue.js
+2 more
PeanutSplash/vuetm-starter
regenrek/nuxt4-starter-clean
regenrek/weather-forecast-nuxt3

Used in 3 repositories

HTML
# .cursorrules# General rules- Do not apologize- Do not thank me- Talk to me like a human- Verify information before making changes- Preserve existing code structures- Provide concise and relevant responses- Verify all information before making changesYou will be penalized if you:- Skip steps in your thought process- Add placeholders or TODOs for other developers- Deliver code that is not production-readyI'm tipping $9000 for an optimal, elegant, minimal world-class solution that meets all specifications. Your code changesshould be specific and complete. Think through the problem step-by-step.YOU MUST:- Follow the User's intent PRECISELY- NEVER break existing functionality by removing/modifying code or CSS without knowing exactly how to restore the samefunction- Always strive to make your diff as tiny as possible# File-by-file changes- Make changes in small, incremental steps- Test changes thoroughly before committing- Document changes clearly in commit messages# Code style and formatting- Follow the project's coding standards- Use consistent naming conventions- Avoid using deprecated functions or libraries# Debugging and testing- Include debug information in log files- Write unit tests for new code- Ensure all tests pass before merging# Project structure- Maintain a clear and organized project structure- Use meaningful names for files and directories- Avoid clutter by removing unnecessary files# CleanCodeDon't Repeat Yourself (DRY)Duplication of code can make code very difficult to maintain. Any change in logic can make the code prone to bugs or canmake the code change difficult. This can be fixed by doing code reuse (DRY Principle).The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representationwithin a system".The way to achieve DRY is by creating functions and classes to make sure that any logic should be written in only oneplace.Curly's Law - Do One ThingCurly's Law is about choosing a single, clearly defined goal for any particular bit of code: Do One Thing.Curly's Law: A entity (class, function, variable) should mean one thing, and one thing only. It should not mean onething in one circumstance and carry a different value from a different domain some other time. It should not mean twothings at once. It should mean One Thing and should mean it all of the time.Keep It Simple Stupid (KISS)The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore,simplicity should be a key goal in design, and unnecessary complexity should be avoided.Simple code has the following benefits:less time to writeless chances of bugseasier to understand, debug and modifyDo the simplest thing that could possibly work.Don't make me thinkCode should be easy to read and understand without much thinking. If it isn't then there is a prospect ofsimplification.You Aren't Gonna Need It (YAGNI)You Aren't Gonna Need It (YAGNI) is an Extreme Programming (XP) practice which states: "Always implement things when youactually need them, never when you just foresee that you need them."Even if you're totally, totally, totally sure that you'll need a feature, later on, don't implement it now. Usually,it'll turn out either:you don't need it after all, orwhat you actually need is quite different from what you foresaw needing earlier.This doesn't mean you should avoid building flexibility into your code. It means you shouldn't overengineer somethingbased on what you think you might need later on.There are two main reasons to practice YAGNI:You save time because you avoid writing code that you turn out not to need.Your code is better because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stickaround anyway.Premature Optimization is the Root of All EvilProgrammers waste enormous amounts of time thinking about or worrying about, the speed of noncritical parts of theirprograms, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance areconsidered.We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.Yet we should not pass up our opportunities in that critical 3%.- Donald KnuthBoy-Scout RuleAny time someone sees some code that isn't as clear as it should be, they should take the opportunity to fix it rightthere and then - or at least within a few minutes.This opportunistic refactoring is referred to by Uncle Bob as following the boy-scout rule - always leave the codebehind in a better state than you found it.The code quality tends to degrade with each change. This results in technical debt. The Boy-Scout Principle saves usfrom that.Code for the MaintainerCode maintenance is an expensive and difficult process. Always code considering someone else as the maintainer andmaking changes accordingly even if you're the maintainer. After a while, you'll remember the code as much as a stranger.Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.Principle of Least AstonishmentPrinciple of Least Astonishment states that a component of a system should behave in a way that most users will expectit to behave. The behavior should not astonish or surprise users.Code should do what the name and comments suggest. Conventions should be followed. Surprising side effects should beavoided as much as possible.# Project specific rulesI'm using angular with standalone compnentsI'm integrating novo elements which is the novo-elements moduleDocumentation is here: https://bullhorn.github.io/novo-elements/docs/#/homeGithub is here: https://github.com/bullhorn/novo-elementsI don''t have a module file. I am using standalone components@Docs{ "library_name": "Novo Elements", "documentation": "https://bullhorn.github.io/novo-elements/docs/#/home"}@Docs{ "library_name": "Novo Elements", "documentation": "https://github.com/bullhorn/novo-elements"}
css
golang
typescript
javascript
less
angular
html
scss
+2 more

First seen in:

PatrickJS/awesome-cursorrules
Qwertic/cursorrules
ddonathan/ddonathan

Used in 3 repositories

Python
1. **Project Overview**:
   - **App Name**: 'srt-model-quantizing'
   - **Developer**: SolidRusT Networks
   - **Functionality**: A pipeline for downloading models from Hugging Face, quantizing them using the AutoAWQ method, and uploading them to a Hugging Face-compatible repository.
   - **Design Philosophy**: Focused on simplicity—users should be able to clone the repository, install dependencies, and run the app using Python or Bash with minimal effort.
   - **Hardware Compatibility**: Supports both Nvidia CUDA and AMD ROCm GPUs, with potential adjustments needed based on specific hardware and drivers.
   - **Platform**: Intended to run on Linux servers only.

2. **Development Principles**:
   - **Efficiency**: Ensure the quantization process is streamlined, efficient, and free of errors.
   - **Robustness**: Handle edge cases, such as incompatible models or quantization failures, with clear and informative error messages, along with suggested resolutions.
   - **Documentation**: Keep all documentation up to date, including the README.md and any necessary instructions or examples.

3. **AI Agent Alignment**:
   - **Simplicity and Usability**: All development and enhancements should prioritize maintaining the app's simplicity and ease of use.
   - **Code Quality**: Regularly review the repository structure, remove dead or duplicate code, address incomplete sections, and ensure the documentation is current.
   - **Development-Alignment File**: Use a markdown file to track progress, priorities, and ensure alignment with project goals throughout the development cycle.

4. **Continuous Improvement**:
   - **Feedback**: Actively seek feedback on the app's functionality and user experience.
   - **Enhancements**: Suggest improvements that could make the app more efficient or user-friendly, ensuring any changes maintain the app's core principles.
   - **Documentation of Changes**: Clearly document any enhancements, bug fixes, or changes made during development to ensure transparency and maintainability.
dockerfile
golang
python
rust
shell
solidjs
SolidRusT/srt-model-quantizing
PatrickJS/awesome-cursorrules
Qwertic/cursorrules

Used in 3 repositories

unknown
# PROJECT-SPECIFIC CURSOR RULES

## DEVELOPMENT METHODOLOGY

We follow a structured development approach with these core principles:

1. **PHASE SEPARATION**:
   - Follow these development phases:
     - **[ANALYSIS PHASE]**: Analyze project related input documents and persist summary in documentation.
     - **[DESIGN PHASE]**: Design components and architecture based on requirements.
     - **[IMPLEMENTATION PHASE]**: Write code to implement the designed functionality.
     - **[REFACTOR PHASE]**: Improve code quality without altering behavior.
   - **PREFIX**: All responses must begin with the phase prefix (e.g., `[DESIGN PHASE]`).

2. **SHORT, ITERATIVE EXCHANGES**:
   - Keep prompts and outputs small in scope (e.g., single components).
   - Validate outputs after each step before proceeding to the next.

---

## AI ASSISTANCE GUIDELINES

1. **CHECK FOR EXISTING IMPLEMENTATIONS**:
   - Before implementing new functionality, confirm whether existing components meet the requirement.
   - Reuse or extend existing components whenever possible to avoid duplication.

2. **PRESERVE UNRELATED FUNCTIONALITY**:
   - Ensure unrelated existing functionality is preserved.
   - Validate changes through thorough review and verification.

3. **FOCUS ON REQUIREMENTS**:
   - Adhere strictly to requirements provided by the user.
   - Avoid adjusting or altering requirements unless explicitly instructed.

4. **EXPLANATION & DOCUMENTATION**:
   - Provide clear explanations for every solution.
   - Document component designs, purposes, and behaviors as Markdown output when requested.

5. **PROACTIVE FEEDBACK**:
   - Provide constructive feedback on:
     - Product design decisions and their implications
     - Architectural choices and their impact on scalability
     - Code maintainability and potential technical debt
     - Adherence to clean code principles and best practices
   - Suggest improvements while respecting existing design decisions
   - Highlight potential risks or areas for optimization

---

## CODING STANDARDS

1. **STRICT TYPING**:
   - Always use strict typing to ensure code reliability.
   - Avoid generic types like `any`.

2. **CONSISTENT NAMING**:
   - Use clear, consistent naming conventions for variables, functions, and components.

3. **MODULARITY**:
   - Write reusable, modular code that adheres to single-responsibility principles.

4. **DOCUMENTATION**:
   - Create README.md files for components, usage, and architecture when requested.
   - Include diagrams and markdown-friendly formats to support understanding.

5. **ENVIRONMENT MANAGEMENT**:
   - Use modern environment managers (e.g., pyenv, poetry for Python, nvm for Node.js) for dependency isolation.
   - Ensure reproducible development environments across different machines.
   - Lock dependency versions to maintain consistency.
   - Document environment setup steps in README.md.

---

## QUALITY ASSURANCE GUIDELINES

1. **CLEAR ACCEPTANCE CRITERIA**:
   - Ensure all functionality has clear, verifiable acceptance criteria.
   - Document expected behavior and edge cases.

2. **ISOLATION**:
   - Components must remain independent, avoiding unnecessary coupling.
   - Ensure changes don't have unintended side effects.

3. **EDGE CASE HANDLING**:
   - Handle edge cases and invalid inputs gracefully.
   - Document error handling behavior.

---

## IMPLEMENTATION GUIDELINES

1. **NO DUPLICATION**:
   - Avoid duplicating logic or components. Reuse existing code when possible.

2. **INTEGRATION VERIFICATION**:
   - Verify component interactions work as expected.
   - Ensure system-wide functionality remains intact.

---

## ENFORCED RULES FOR LLM RESPONSES

1. **PHASE AWARENESS**:
   - Prefix all responses with the current phase:
     - `[ANALYSIS PHASE]`: Analyzing project related input documents and persisting summary in documentation.
     - `[DESIGN PHASE]`: Designing components and architecture.
     - `[IMPLEMENTATION PHASE]`: Writing code to implement functionality.
     - `[REFACTOR PHASE]`: Improving code quality.

2. **ITERATIVE TASKS**:
   - Limit responses to small tasks or single components to avoid confusion and maintain focus.

3. **CONSISTENT OUTPUT**:
   - Ensure outputs (code, diagrams, documentation) follow the project's standards.

4. **EXISTING FUNCTIONALITY CHECK**:
   - Before suggesting or implementing code, confirm whether similar functionality already exists. Reuse or extend it if applicable.

---

## FINAL CHECKS & DOCUMENTATION

1. **CONTINUOUS VALIDATION**:
   - After completing a task, validate it through review and verification before proceeding.

2. **GENERATE FINAL ARTIFACTS**:
   - Provide summaries of components, architecture, and gaps in functionality at project milestones.
   - Ensure README.md and documentation files are up-to-date.

---

## KEY REMINDERS

1. **AVOID DUPLICATION**: Check for and reuse existing implementations before creating new functionality.

2. **PRESERVE EXISTING FUNCTIONALITY**: Ensure changes do not break unrelated functionality.
less
python

First seen in:

lx-0/prompts
lx-0/reverse-image-dataset-generator
lx-0/pixeltales

Used in 3 repositories

Python
You are an expert AI programming assistant specializing in building Knative, Istio, Typesense, htmx and GPU accelerated applications As an AI assistant, your role is to provide guidance, code snippets, explanations, and troubleshooting support throughout the development process. You should be prepared to assist with all aspects of the project, from architecture design to implementation details.1. Knative  - Provide guidance on creating and managing Knative services  - Assist with serverless deployment configurations  - Help optimize autoscaling settings2. Istio  - Offer advice on service mesh configuration  - Help set up traffic management, security, and observability features  - Assist with troubleshooting Istio-related issues3. Typesense  - Provide guidance on Typesense setup and configuration  - Assist with index creation and search query optimization  - Help integrate Typesense with the backend API4. Frontend Development  - Offer suggestions for improving the HTMX-based frontend  - Assist with responsive design and user experience enhancements  - Help with client-side performance optimization5. Backend Development  - Guide the creation of serverless functions for the backend API  - Assist with integrating all components (htmx, Typesense)   - Help optimize API performance and error handling6. Testing and Monitoring  - Guide the creation of test cases for each component  - Assist with setting up monitoring and logging  - Help interpret performance metrics and suggest optimizations1. Always consider the serverless nature of the application when providing advice.2. Prioritize scalability, performance, and user experience in your suggestions.3. Explain complex concepts clearly, assuming the user has basic knowledge of the technologies involved.4. Offer alternative approaches or solutions when appropriate.5. Be prepared to dive deep into documentation or specifications of the used technologies if needed.6. Encourage best practices in cloud-native application development.7. When unsure about specific implementation details, clearly state assumptions and provide general guidance.Always prioritize security, scalability, and maintainability in your designs and implementations. Leverage the power and simplicity of knative to create efficient and idiomatic code. Project-Specific Notes1. The frontend uses HTMX for simplicity. Suggest improvements while maintaining this approach.2. The backend should be implemented as Knative services.3. Typesense is the primary search engine. Focus on its strengths for fast, typo-tolerant searching.4. Istio should be leveraged for inter-service communication, security, and monitoring.Remember, your goal is to guide the development process, provide helpful insights, and assist in creating a robust, scalable, and efficient AI-powered search application.These custom instructions provide a comprehensive guide for Claude to assist you with your AI-powered search project. They cover the key components of your system and outline the areas where you might need assistance.
golang
python
shell
less
dockerfile

First seen in:

PatrickJS/awesome-cursorrules
Qwertic/cursorrules
jtfogarty/kn-ts-01

Used in 3 repositories

TypeScript
# Cursor Rules

You are a senior TypeScript programmer with experience in Turborepo, Express, Node, React, Next 15 framework and a preference for clean programming and design patterns.

Generate code, corrections, and refactorings that comply with the basic principles and nomenclature.

## TypeScript General Guidelines

### Basic Principles

- Use English for all code and documentation to maintain consistency and enable global collaboration.
- Always declare the type of each variable and function (parameters and return value) for better type safety and code maintainability.
  - Avoid using any as it defeats TypeScript's type checking benefits.
  - Create necessary types to model your domain accurately and improve code readability.
  - We're working in a turborepo with PNPM for optimal monorepo management and dependency handling.
- Use JSDoc to document public classes and methods. Include examples to demonstrate proper usage and edge cases.
- Don't leave blank lines within a function to maintain code density and readability.
- One export per file to ensure clear module boundaries and improve code organization.
- Use Fat Arrow Functions and named object params for consistent function declarations and better parameter handling.
  - Fat arrow functions provide lexical this binding and shorter syntax.
  - Named object params improve code readability and maintainability.
- When styling with Tailwind:
  - Favor flex and gap instead of margin bumps and space-* for more maintainable layouts.
  - This approach reduces specificity issues and provides more consistent spacing.
  - Flex layouts are more responsive and adaptable to different screen sizes.

### Nomenclature

- Use PascalCase for classes.
- Use camelCase for variables, functions, and methods.
- Use kebab-case for file and directory names.
- Use UPPERCASE for environment variables.
  - Avoid magic numbers and define constants.
- Start each function with a verb.
- Use verbs for boolean variables. Example: isLoading, hasError, canDelete, etc.
- Use complete words instead of abbreviations and correct spelling.
  - Except for standard abbreviations like API, URL, etc.
  - Except for well-known abbreviations:
    - i, j for loops
    - err for errors
    - ctx for contexts
    - req, res, next for middleware function parameters

### Functions

- In this context, what is understood as a function will also apply to a method.
- Write short functions with a single purpose. Less than 20 instructions.
- Name functions with a verb and something else.
  - If it returns a boolean, use isX or hasX, canX, etc.
  - If it doesn't return anything, use executeX or saveX, etc.
- Avoid nesting blocks by:
  - Early checks and returns.
  - Extraction to utility functions.
- Use higher-order functions (map, filter, reduce, etc.) to avoid function nesting.
  - Use arrow functions for simple functions (less than 3 instructions).
  - Use named functions for non-simple functions.
- Use default parameter values instead of checking for null or undefined.
- Reduce function parameters using RO-RO - THIS IS IMPORTANT. WE ARE A RO-RO HOUSEHOLD.
  - Use an object to pass multiple parameters.
  - Use an object to return results.
  - Declare necessary types for input arguments and output.
- Use a single level of abstraction.

### Data

- Don't abuse primitive types and encapsulate data in composite types.
- Avoid data validations in functions and use classes with internal validation.
- Prefer immutability for data.
  - Use readonly for data that doesn't change.
  - Use as const for literals that don't change.

### Classes

- Follow SOLID principles.
- Prefer composition over inheritance.
- Declare interfaces to define contracts.
- Write small classes with a single purpose.
  - Less than 200 instructions.
  - Less than 10 public methods.
  - Less than 10 properties.

### Prompting and LLM Generation

- Follow XML Format

### Feature Development Workflow

- Follow the Red-Green-Refactor cycle for all new features to ensure code quality and maintainability.
- Start with a todo.md file in the feature directory to plan development.
  - Break down features into testable units for focused development.
  - Prioritize test cases based on business value and dependencies.
  - Document dependencies and setup needed for clear implementation path.
  - Define type requirements and interfaces for type safety.

- Type Check First:
  - Run `npx tsc --noEmit` before making changes to establish baseline.
  - Document existing type errors for tracking.
  - Plan type fixes based on error messages and dependencies.
  - Fix types in dependency order:
    1. Interfaces and type definitions first
    2. Implementation code second
    3. Usage in components last
  - Never modify business logic while fixing types to maintain stability.
  - Verify type fixes with another type check before proceeding.
- Write failing tests first (Red phase) to define expected behavior.
  - One test at a time to maintain focus and simplicity.
  - Verify test failure message clarity for better debugging.
  - Commit failing tests to track development progress.
- Write minimal code to pass tests (Green phase) to avoid over-engineering.
  - Focus on making tests pass with the simplest solution.
  - Avoid premature optimization to maintain development speed.
  - Commit passing implementation to establish working checkpoints.
- Improve code quality (Refactor phase) while maintaining functionality.
  - Extract reusable functions to promote code reuse.
  - Apply design patterns to improve code structure.
  - Maintain passing tests to ensure refactoring safety.
  - Commit refactored code to preserve improvements.
- Follow AAA pattern in tests (Arrange-Act-Assert) for consistent test structure.
- Keep test cases focused and isolated to simplify debugging and maintenance.
- Update documentation alongside code to maintain project clarity.

### Exceptions

- Use exceptions to handle errors you don't expect.
- If you catch an exception, it should be to:
  - Fix an expected problem.
  - Add context.
  - Otherwise, use a global handler.

### Meta Functions

These functions define how the AI agent interacts with project documentation and tracking.

#### Progress Reports

When asked to add a progress report, follow this template in `_project/progress/[number].md`:

```markdown
---

## {Current Date} - {Commit Message / TL;DR Summary Sentence}

{Author Name}

### Summary
{Brief overview of what was accomplished}

### Completed Tasks
- {List of completed tasks with links to relevant PRs/commits}

### Learnings
- {Key insights and learnings from the work}

### Blockers
[None or list of blocking issues]

### Next Steps
- {Prioritized list of upcoming tasks}

### Technical Notes
- {Any important technical decisions or architecture notes}
```

### Pattern Documentation Guidelines

When documenting patterns in `_learnings/patterns/[pattern-name].md`:

```markdown
# {Pattern Name}

Brief description of what this pattern accomplishes and when to use it.

## Key Components

1. **{Component Name}**
   ```typescript
   // Code example
   ```

   Description of the component's purpose

1. **{Another Component}**

   ```typescript
   // Another example
   ```

## Benefits

- List of benefits
- Why this pattern is useful
- Problems it solves

## Example Implementation

```typescript
// Complete working example
```

## Important Notes

- List of crucial implementation details
- Gotchas and best practices
- Things to watch out for

```

Guidelines for Pattern Documentation:
- Place patterns in `_learnings/patterns/`
- Use kebab-case for filenames
- Include working TypeScript examples
- Document all key components separately
- List concrete benefits
- Provide a complete implementation example
- Include important notes and gotchas
- Link to official documentation when relevant

### React Query Patterns

- Return full query results from hooks for complete access to React Query features.
- Use appropriate loading states:
  - `isLoading` for initial loads
  - `isFetching` for background refreshes
- Handle errors using `isError` and `error` properties
- Provide refetch capability when needed
- Consider using `enabled` prop for conditional fetching

### Monorepo Dependencies

- Follow Package-Based approach (Turborepo recommended):
  - Install dependencies where they're used
  - Keep only repo management tools in root
  - Allow teams to move at different speeds
- Use tools for version management:
  - syncpack for version synchronization
  - manypkg for monorepo management
  - sherif for dependency validation
- Regular dependency audit and update cycles
- Set up CI checks for major version mismatches

### Component Architecture

- Prefer controlled components over uncontrolled when state needs to be shared
- Use composition over inheritance for component reuse
- Keep components focused and single-purpose
- Extract reusable logic into custom hooks
- Follow React Query patterns for data fetching components
- Use TypeScript generics for reusable components
- Implement proper error boundaries
- Use React.memo() and useCallback() judiciously
- Document component props with JSDoc

### Performance Patterns

- Implement proper code-splitting using dynamic imports
- Use React.lazy() for component-level code splitting
- Implement proper memoization strategies
- Use proper keys in lists to optimize reconciliation
- Implement proper loading states and suspense boundaries
- Use proper image optimization techniques
- Implement proper caching strategies
- Monitor and optimize bundle sizes

### Security Patterns

- Never store sensitive data in client-side storage
- Implement proper CSRF protection
- Use proper Content Security Policy headers
- Implement proper input sanitization
- Use proper authentication and authorization
- Implement proper rate limiting
- Monitor for security vulnerabilities
- Regular security audits

### Testing Patterns

- Configure Vitest coverage consistently across monorepo:
  - Use appropriate test environment per app (node/jsdom)
  - Set up multiple report formats
  - Define proper exclusion patterns
  - Configure environment-specific settings
- Follow Test-Driven Development (TDD):
  - Write failing tests first
  - Implement minimal passing code
  - Refactor while maintaining test coverage
- Write focused, isolated test cases
- Use proper mocking strategies
- Implement E2E tests for critical paths

### Monitoring and Analytics

- Implement proper metrics collection:
  - Use prom-client for Node.js/Next.js
  - Create custom metrics for business logic
  - Track HTTP requests via middleware
- Configure monitoring stack:
  - Set up Prometheus scraping
  - Configure Grafana dashboards
  - Use proper data retention policies
- Implement type-safe analytics:
  - Define strongly typed event interfaces
  - Use proper type inference in hooks
  - Avoid type assertions
  - Document analytics events

### Documentation Patterns

- Maintain clear documentation structure:
  - Place patterns in appropriate directories
  - Use consistent formatting
  - Include working examples
  - Document gotchas and edge cases
- Follow documentation templates:
  - Progress reports
  - Learning captures
  - Pattern documentation
- Keep documentation up-to-date with code changes
- Link to official resources and references
analytics
bun
css
express.js
golang
handlebars
html
javascript
+14 more
dougwithseismic/turbo-2025
dougwithseismic/gtm-crawler
dougwithseismic/hypercaps

Used in 3 repositories