Browse

Programming Guidelines .cursorrules strategies

Filters

Tech

Clear

React

Tailwind CSS

Node.js

Tailwind

Shadcn UI

JavaScript

Python

Radix UI

Next.js

Vite

JSX

WebP

Zod

Docker

Next.js App Router

Supabase

CSS

PostgreSQL

Redis

FastAPI

HTML

Pydantic

pytest

Git

Jest

react-hook-form

Solidity

Vercel

SQLAlchemy

Tailwind Aria

Suspense

SvelteKit

Vue.js

GitHub Actions

Celery

ESLint

PHP

TailwindCSS

Pinia

PEP 8

asyncpg

TypeScript

SQL

Playwright

Svelte

Prettier

Radix

DaisyUI

Vitest

JSDoc

JSON

ARIA

Drizzle ORM

Vue Router

VueUse

Astro

Svelte 5

tRPC

Expo

CORS

aiomysql

GitLab CI

Django

Typescript

scikit-learn

pandas

GitHub

RabbitMQ

Java

WebP.

tanStackQuery

Phoenix LiveView

Ecto

File System Watcher

Plug

Finch

Gettext

Phoenix

Elixir

Jason

Phoenix LiveDashboard

Sobelow

ExCoveralls

DNS Cluster

ExUnit

Release Please

Swoosh

Credo

LeftHook

ES6

npm

Laravel

styled-components

RESTful API

Shadcn

Markdown

OpenZeppelin

Slither

Hardhat

Mythril

Clear

Behavior

Configuration Management

Monitoring

Logging

Libraries

Dependency Management

Project Specific

code best practices

data validation

Jupyter Notebook

data analysis

data visualization

PEP 8 guidelines

EEG application development

Software development best practices.

User interface design

Signal processing

LLM Integration

Security Practices.

Project Structuring.

Open Source Tools

Coding Principles

Caching

CI/CD Pipelines

Data Infrastructure

Server-Side Programming

Cloud Platforms

Logging and Monitoring

Microservices Architecture

Containerization and Orchestration

Data Modeling

Desktop Application Development

Programming Best Practices.

API Communication

File Structure.

Web Development.

Blockchain Technology

User Interface Development

Software Development Best Practices

Code Performance

Software Refactoring

Debugging

Problem Solving.

Front-end Development

Technology Integration

Dynamic Loading.

URL State Management

Code Examples

Commit Guidelines

Reusable Code

Frontend Development.

Modular Design

Gas Efficiency

Commit Messaging

Automated Testing

Dynamic Routing

Reusability

Continuous Integration.

Animation and Transition

Programming Instructions

UI/UX

Component Design

PHP 7.4 Features

PSR-12 Coding Standards

Web Application

Backend Integration

Cellular Automata

Environmental Simulation

Data Synchronization

Shader Programming

User Interaction

Interactive Systems

Grid Systems

Generative User Interfaces

Middleware Integration

AI SDK Integration

Deployment Considerations

React Server Components

Business Process Modeling

BPMN Diagrams

Project Management Tools

Business Analysis

AI Chatbot

Code Implementation Guidelines

Component-Based Development

Accessibility in Web Design

Modern Web Technologies

Documentation structure

Development guidelines

Coding standards

Testing strategy

Package integration

Code structure

Laravel package development

Browser APIs.

Code Architecture

Web Security

Functional Programming.

Error Boundaries

TypeScript Conventions.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

NEW

Playwright Test TypeScript .cursorrules prompt file

Playwright Testing - Best Practices

Always use TypeScript instead of vanilla JavaScript whenever possible.
For locators, always bias towards using Playwright's getByTestId() locator method instead of any other method.
Add a data-testid attribute for elements you need to target if they don't already have a data-testid attribute.
Every data-testid should follow this format: ComponentName_camelCaseDescriptorOfElement
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();
```
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.
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.
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.
Never use .not.toBeVisible() or .toBeHidden(). Instead of these, use our custom matcher .toNotExist().

stack:

TypeScript

JavaScript

Playwright

Playwright Test TypeScript .cursorrules prompt file

Steven Boutcher

0

NEW

Elixir Engineer Guidelines .cursorrules prompt file

Act as an expert senior Elixir engineer.
Stack: Elixir, Phoenix, Docker, PostgreSQL, Tailwind CSS, LeftHook, Sobelow, Credo, Ecto, ExUnit, Plug, Phoenix LiveView, Phoenix LiveDashboard, Gettext, Jason, Swoosh, Finch, DNS Cluster, File System Watcher, Release Please, ExCoveralls

When writing code, you will think through any considerations or requirements to make sure we've thought of everything. Only after that do you write the code.
After a response, provide three follow-up questions worded as if I'm asking you. Format in bold as Q1, Q2, Q3. These questions should be throught-provoking and dig further into the original topic.
If my response starts with "VV", give the most succinct, concise, shortest answer possible.

Commit Message Guidelines:

Always suggest a conventional commit message with an optional scope in lowercase. Follow this structure:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Where:

type: One of the following:
- build: Changes that affect the build system or external dependencies (e.g., Maven, npm)
- chore: Other changes that don't modify src or test files
- ci: Changes to our CI configuration files and scripts (e.g., Circle, BrowserStack, SauceLabs)
- docs: Documentation only changes
- feat: A new feature
- fix: A bug fix
- perf: A code change that improves performance
- refactor: A code change that neither fixes a bug nor adds a feature
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- test: Adding missing tests or correcting existing tests
scope (optional): A noun describing a section of the codebase (e.g., fluxcd, deployment).
description: A brief summary of the change in present tense.
body (optional): A more detailed explanation of the change.
footer (optional): One or more footers in the following format:
- BREAKING CHANGE: `` (for breaking changes)
- <issue_tracker_id>`: `<description> (e.g., Jira-123: Fixed bug in authentication)

stack:

Elixir Engineer Guidelines .cursorrules prompt file

Zane Riley

0

NEW

Python 3.12 FastAPI Best Practices .cursorrules prompt file

Here are some best practices and rules you must follow:

- You use Python 3.12

- Frameworks:

- pydantic
- fastapi
- sqlalchemy

- You use poetry for dependency management
- You use alembic for database migrations
- You use fastapi-users for user management
- You use fastapi-jwt-auth for authentication
- You use fastapi-mail for email sending
- You use fastapi-cache for caching
- You use fastapi-limiter for rate limiting
- You use fastapi-pagination for pagination

1. **Use Meaningful Names**: Choose descriptive variable, function, and class names.
2. **Follow PEP 8**: Adhere to the Python Enhancement Proposal 8 style guide for formatting.
3. **Use Docstrings**: Document functions and classes with docstrings to explain their purpose.
4. **Keep It Simple**: Write simple and clear code; avoid unnecessary complexity.
5. **Use List Comprehensions**: Prefer list comprehensions for creating lists over traditional loops when appropriate.
6. **Handle Exceptions**: Use try-except blocks to handle exceptions gracefully.
7. **Use Virtual Environments**: Isolate project dependencies using virtual environments (e.g., `venv`).
8. **Write Tests**: Implement unit tests to ensure code reliability.
9. **Use Type Hints**: Utilize type hints for better code clarity and type checking.
10. **Avoid Global Variables**: Limit the use of global variables to reduce side effects.

These rules will help you write clean, efficient, and maintainable Python code.

stack: