# wispbit - Keep codebase standards alive wispbit AI enforces codebase standards so you can make AI coding agents 2x more effective and ship 3x faster. ## Blog Posts - [LLM rules for PostgreSQL](https://wispbit.com/blog/llm-rules-for-postgres) - [How to fix your broken code review process](https://wispbit.com/blog/how-to-fix-broken-code-review-process) ## Codebase Rules for wispbit, Coderabbit, Greptile, Copilot, Graphite Diamond, Cline, OpenAI Codex, Cursor, Claude Code, Windsurf - [No important tag in CSS](https://wispbit.com/rules/css-no-important): Do not use the `!important` declaration in CSS styles. For css - [Avoid getter methods in Go](https://wispbit.com/rules/golang-avoid-getters): Avoid using "getter" methods in Go code. Instead, expose fields directly when appropriate, following Go's idiomatic approach to visibility. For golang - [Early returns in Go](https://wispbit.com/rules/golang-early-return): Use early returns to reduce nesting levels. Prefer checking error conditions or guard clauses first and returning early, rather than wrapping the main logic in deep conditional blocks. For golang - [Inline error assignment in Go](https://wispbit.com/rules/golang-inline-error-assignment): Use inline error assignment with the `:=` operator when checking for errors. For golang - [Structured logging in Go](https://wispbit.com/rules/golang-structured-logging): Always use structured logging with field-based approaches instead of string formatting when logging in Go. For golang - [Avoid unnecessary else blocks in Go](https://wispbit.com/rules/golang-unnecessary-else-blocks): Avoid unnecessary `else` blocks when the `if` block ends with a return statement, break, continue, or similar control flow statements. For golang - [Use structured logger in Go](https://wispbit.com/rules/golang-use-structured-logger): Use the structured logger for all logging operations instead of fmt.Print or log package functions. For golang - [Use Zap logger in Go](https://wispbit.com/rules/golang-use-zap-logger): Use Zap for all logging in Go code. For golang - [Mark fields as deprecated in GraphQL](https://wispbit.com/rules/graphql-mark-fields-deprecated): When removing fields from a GraphQL schema, follow a progressive deprecation process: For graphql - [Check for duplicates in Markdown](https://wispbit.com/rules/markdown-avoid-duplicate-words): Check documentation for duplicate adjacent words, which are typically typos. For markdown - [Use code highlighting in Markdown](https://wispbit.com/rules/markdown-code-highlighting): Specify the appropriate language for code blocks to enable proper syntax highlighting. For CLI commands use `bash`, and for Python code use `py` or `python`. For markdown - [Prefer Image in NextJS](https://wispbit.com/rules/nextjs-prefer-image): Always use Next.js `` component instead of HTML `` tag. For nextjs - [Do not rename columns](https://wispbit.com/rules/no-column-renaming): When renaming columns in PostgreSQL, follow a safe migration pattern to avoid breaking changes to applications: For postgresql, prisma, supabase, mysql, drizzle, migrations - [Do not rename tables](https://wispbit.com/rules/no-table-renaming): When renaming tables, use a multi-step approach instead of direct renaming to prevent downtime. For postgresql, prisma, supabase, mysql, drizzle, migrations - [Avoid aliases for new routes in PHP](https://wispbit.com/rules/php-avoid-aliases): Only use route aliases for backward compatibility with renamed or moved routes. Do not add aliases to newly created routes. For php - [Prefer switch statements in PHP](https://wispbit.com/rules/php-prefer-switch-statement): Use switch statements when handling multiple attribute types. For php - [Add indexes for foreign keys in PostgreSQL](https://wispbit.com/rules/postgresql-add-index-for-foreign-key): When adding a foreign key constraint in PostgreSQL, always add a corresponding index. For postgresql, prisma, supabase, drizzle, migrations - [Always have id, created_at, updated_at columns in PostgreSQL](https://wispbit.com/rules/postgresql-always-include-columns): All CREATE TABLE statements must include `id`, `created_at`, and `updated_at` columns. For postgresql, prisma, supabase, drizzle, migrations - [Column naming standards in PostgreSQL](https://wispbit.com/rules/postgresql-column-naming-standards): Maintain consistent naming conventions for new columns. For postgresql, prisma, supabase, drizzle, migrations - [Index naming standards in PostgreSQL](https://wispbit.com/rules/postgresql-index-naming-standards): For indexes, use the following naming standards: For postgresql, prisma, supabase, drizzle, migrations - [Limit non unique indexes in PostgreSQL](https://wispbit.com/rules/postgresql-limit-non-unique-index): Limit non-unique indexes to a maximum of three columns in PostgreSQL databases: For postgresql, prisma, supabase, drizzle, migrations - [Only concurrent indexes in PostgreSQL](https://wispbit.com/rules/postgresql-only-concurrent-indexes): When creating indexes in PostgreSQL, always use the `CONCURRENTLY` option to prevent blocking writes during index creation. For postgresql, prisma, supabase, drizzle, migrations - [Always use JSONB in PostgreSQL](https://wispbit.com/rules/postgresql-only-jsonb): Always use `jsonb` instead of `json` data type when creating columns in PostgreSQL databases. For postgresql, prisma, supabase, drizzle, migrations - [Use check constraints for setting NOT NULL columns in PostgreSQL](https://wispbit.com/rules/postgresql-set-column-not-null): When adding a NOT NULL constraint to an existing column in PostgreSQL, use a check constraint first to avoid blocking reads and writes while every row is checked. For postgresql, prisma, supabase, drizzle, migrations - [Split foreign keys in PostgreSQL](https://wispbit.com/rules/postgresql-split-foreign-key): When adding foreign keys in Postgres migrations, split the operation into two steps to avoid blocking writes on both tables: For postgresql, prisma, supabase, drizzle, migrations - [Split unique constraints in PostgreSQL](https://wispbit.com/rules/postgresql-unique-constraint): When adding unique constraints in PostgreSQL, create the unique index concurrently first before adding the constraint to avoid blocking reads and writes. For postgresql, prisma, supabase, drizzle, migrations - [posthog React Typescript Patterns](https://wispbit.com/rules/posthog-react-typescript-patterns): Use Kea logic for all state management instead of React state hooks. Follow PostHog's two-layer architecture pattern. For typescript, react - [Ensure removed column is ignored in Prisma](https://wispbit.com/rules/prisma-ensure-ignored-column): When creating a migration to remove a column from the database, ensure that the schema has the `@ignore` attribute on that column in the Prisma schema. Search for the .prisma schema in the codebase to verify this. For postgresql, prisma, migrations - [Avoid duplicate words in Python](https://wispbit.com/rules/python-avoid-duplicate-words): Check all text elements (comments, docstrings, and string literals) for duplicate adjacent words for typos or duplicates. For python - [Self documenting code in Python](https://wispbit.com/rules/python-avoid-explanatory-comments): Avoid unnecessary explanatory comments for code that is self-documenting. Comments should only be used when they add context that the code itself cannot convey. For python - [Avoid print in Python tests](https://wispbit.com/rules/python-avoid-print): Avoid using `print()` statements in test files. For python - [Consistent error classes in Python](https://wispbit.com/rules/python-consistent-error-classes): Use consistent naming conventions for error classes in Python. For python - [Python DRY](https://wispbit.com/rules/python-dry): Avoid duplicating code in Python. Extract repeated logic into reusable functions, classes, or constants. You may have to search the codebase to see if the function or class is already defined. For python - [Avoid duplicate variable reassignment in Python](https://wispbit.com/rules/python-duplicate-reassignment): Avoid assigning a variable to itself or reassigning a variable with the same value. For python - [Early returns in Python](https://wispbit.com/rules/python-early-return): Use early returns to reduce nesting levels. Instead of wrapping large code blocks in conditional statements, return early when conditions are not met. For python - [No generic except in Python](https://wispbit.com/rules/python-no-generic-except): Avoid using generic `except:` or `except Exception:` statements. For python - [No inline imports in Python](https://wispbit.com/rules/python-no-inline-imports): Place all import statements at the top of the file. For python - [No unused code in python](https://wispbit.com/rules/python-no-unused-code): Do not leave commented-out code blocks in Python files. If code is no longer needed, remove it entirely rather than commenting it out. For python - [Unnecessary else blocks in Python](https://wispbit.com/rules/python-unnecessary-else-blocks): Avoid unnecessary `else` blocks when the `if` block ends with a return statement, break, continue, or similar control flow statements. For python - [Avoid unncecessary try except in Python](https://wispbit.com/rules/python-unnecessary-try-except): When using try-except blocks in Python, keep the try block focused only on the code that can raise the expected exception. For python - [Enforce component design system in React](https://wispbit.com/rules/react-component-design-system): All design system components must use forwardRef pattern, CVA for variants, and follow the established component structure. For nextjs, react, typescript - [Check for duplicate components](https://wispbit.com/rules/react-duplicate-components): Favor existing components over creating new ones. For nextjs, react, typescript - [Internal links in React](https://wispbit.com/rules/react-internal-links): When linking between internal sites, use `rel="noopener"` instead of `rel="noopener noreferrer"`. For react, typescript - [No random numbers in React](https://wispbit.com/rules/react-no-random): Do not generate non-deterministic values like random IDs during render in React components. This causes hydration errors because the server-rendered HTML will not match what the client generates. For nextjs, react, typescript - [No unused components](https://wispbit.com/rules/react-no-unused-components): Do not leave commented-out components. Either remove unused components entirely or implement them properly. For nextjs, react, typescript - [Early returns in Ruby](https://wispbit.com/rules/ruby-early-return): Use early returns to reduce nesting levels. Prefer checking error conditions or guard clauses first and returning early, rather than wrapping the main logic in deep conditional blocks. For ruby, rails - [External API error handling in Ruby](https://wispbit.com/rules/ruby-external-api-handling): When making external API requests, implement proper error handling with descriptive logging to help with debugging issues. For ruby, rails - [Avoid unnecessary else blocks in Ruby](https://wispbit.com/rules/ruby-unnecessary-else-blocks): Avoid unnecessary `else` blocks when the `if` block ends with a return statement, break, next, or similar control flow statements. For ruby, rails - [Check character boundaries in Rust](https://wispbit.com/rules/rust-check-character-boundaries): When truncating strings, ensure you check character boundaries to prevent panics with multi-byte UTF-8 characters. For rust - [Use triple slash for documentation in Rust](https://wispbit.com/rules/rust-function-documentation): Use triple slashes (`///`) for documenting Rust functions and methods. For rust - [Prefer logging instead of panicking in Rust](https://wispbit.com/rules/rust-recover-errors): Use logging instead of panicking for recoverable errors. For operations that might fail but don't compromise the entire application state, log the error and provide a fallback rather than panicking. For rust - [Shell script best practices](https://wispbit.com/rules/shell-best-practices): Follow these shell script best practices when writing or modifying bash scripts: For shell - [Split check constraints](https://wispbit.com/rules/split-check-constraint): When adding check constraints in migrations, split the operation into two steps to avoid blocking writes during the table scan: For postgresql, prisma, supabase, mysql, drizzle, migrations - [Change column types safely in SQLAlchemy](https://wispbit.com/rules/sqlalchemy-change-column-type): When changing a column type that requires a table rewrite, follow these steps: For postgresql, mysql, sqlalchemy, migrations, alembic - [Ensure index is not already covered in SQLAlchemy](https://wispbit.com/rules/sqlalchemy-ensure-index-not-covered): Ensure that individual column indexes in SQLAlchemy are not covered by existing composite indexes. For postgresql, sqlalchemy, alembic, migrations - [Limit non unique indexes in SQLAlchemy](https://wispbit.com/rules/sqlalchemy-limit-non-unique-index): Limit non-unique indexes to a maximum of three columns in PostgreSQL databases: For postgresql, sqlalchemy, alembic, migrations - [Only concurrent indexes in SQLAlchemy](https://wispbit.com/rules/sqlalchemy-only-concurrent-indexes): When creating or dropping indexes in PostgreSQL using SQLAlchemy migrations, always use the `postgresql_concurrently=True` option within an autocommit block. This prevents blocking writes during index operations. For postgresql, sqlalchemy, migrations, alembic - [Add check constraints safely in SQLAlchemy](https://wispbit.com/rules/sqlalchemy-split-check-constraint): When adding check constraints that could affect large tables, create the constraint with `NOT VALID` first to avoid blocking writes during the validation scan. For postgresql, sqlalchemy, alembic, migrations - [Add foreign keys safely in SQLAlchemy](https://wispbit.com/rules/sqlalchemy-split-foreign-key): When adding foreign keys in SQLAlchemy migrations, split the operation into two steps to avoid blocking writes on both tables: For postgresql, sqlalchemy, alembic, migrations - [Add unique constraints safely in SQLAlchemy](https://wispbit.com/rules/sqlalchemy-unique-constraint): When adding unique constraints that could affect large tables, create the unique index concurrently first to avoid blocking reads and writes during the migration. For postgresql, sqlalchemy, alembic, migrations - [Verify query patterns are covered by an index in SQLAlchemy](https://wispbit.com/rules/sqlalchemy-verify-query-patterns-are-indexed): Ensure that SQLAlchemy query patterns are covered by appropriate database indexes. For postgresql, sqlalchemy, alembic, migrations - [Prefer tailwind design tokens](https://wispbit.com/rules/tailwind-design-tokens): Use Tailwind's predefined design tokens instead of arbitrary values. Do not use custom pixel values, color codes, or arbitrary numbers in your Tailwind CSS classes. For nextjs, tailwind - [Always return empty arrays in Typescript](https://wispbit.com/rules/typescript-always-return-empty): When defining methods that return collections like arrays, always return an empty array instead of undefined when no items exist. For typescript, react - [Annotate skipped tests in Typescript](https://wispbit.com/rules/typescript-annotate-tests): When skipping tests, always add a comment explaining why the test is being skipped. For typescript - [Avoid console.log in Typescript tests](https://wispbit.com/rules/typescript-avoid-console-log): Avoid using `console.log` statements in test files. For typescript - [Avoid duplicate words in Typescript](https://wispbit.com/rules/typescript-avoid-duplicate-words): Check all text elements (comments, docstrings, and string literals) for duplicate adjacent words for typos or duplicates. For typescript, react - [Self documenting code in Typescript](https://wispbit.com/rules/typescript-avoid-explanatory-comments): Avoid unnecessary explanatory comments for code that is self-documenting. Comments should only be used when they add context that the code itself cannot convey. For typescript - [Self documenting string operations in Typescript](https://wispbit.com/rules/typescript-avoid-magic-numbers): Replace magic numbers with self-documenting expressions when dealing with string operations. For typescript - [Check error types in Typescript](https://wispbit.com/rules/typescript-check-error-type): Always check the error type in catch blocks and handle specific error types explicitly. For typescript - [Consistent error classes in Typescript](https://wispbit.com/rules/typescript-consistent-error-classes): Use consistent naming conventions for error classes. For typescript - [Dev dependencies in typescript](https://wispbit.com/rules/typescript-dev-dependencies): Place CLI tool dependencies in the `devDependencies` section of `package.json` instead of `dependencies` when they are only used for local development, scripts, or tooling. For typescript, react, nextjs - [Typescript DRY](https://wispbit.com/rules/typescript-dry): Avoid duplicating code in TypeScript. Extract repeated logic into reusable functions, types, or constants. You may have to search the codebase to see if the method or type is already defined. For typescript, nextjs, react - [Avoid duplicate assignment in Typescript](https://wispbit.com/rules/typescript-duplicate-assignment): Avoid assigning values to the same variable multiple times in succession without using the variable in between. For typescript - [No unused code in typescript](https://wispbit.com/rules/typescript-no-unused-code): Do not leave commented-out code blocks. Delete unused code instead of commenting it out. For typescript - [Promise all async loops in Typescript](https://wispbit.com/rules/typescript-promise-async-loops): Use `Promise.all` when processing multiple async operations in loops. For typescript - [Query standards for Tanstack Query](https://wispbit.com/rules/typescript-tanstack-query-standards): When using TanStack Query (React Query), always configure cache and refetching behavior explicitly: For typescript, react, nextjs - [Use union types in Typescript](https://wispbit.com/rules/typescript-union-types): Use union types with specific interfaces for mutually exclusive properties instead of a single interface with multiple optional properties. For typescript - [Avoid unnecessary else blocks in Typescript](https://wispbit.com/rules/typescript-unnecessary-else-blocks): Avoid unnecessary `else` blocks when the `if` block ends with a return statement, break, continue, or similar control flow statements. For typescript - [Avoid unnecessary try catch in Typescript](https://wispbit.com/rules/typescript-unnecessary-try-catch): When using try-catch blocks in Typescript, keep the try block focused only on the code that can raise the expected exception. For typescript - [Prefer with syntax in Typescript](https://wispbit.com/rules/typescript-with-syntax): Use the newer `with` syntax for JSON imports instead of the deprecated `assert` syntax for Node.js compatibility. For typescript, javascript - [Prefer Composition API over Options API in Vue components](https://wispbit.com/rules/vue-prefer-composition-api): Favor the Composition API (`