AntigravityList
Rules

AntigravityList

The ultimate directory for the Antigravity ecosystem. Discover tools, resources, and more.

Directory

RulesSitemap

Support

Help CenterPrivacy PolicyRefund PolicyTerms of ServiceAbout Us

© 2025 AntigravityList. All rights reserved.

This website is not affiliated with, endorsed by, or associated with Google LLC. "Google" and "Antigravity" are trademarks of Google LLC.

Browse Rules

Libraries

26
26
17
14
14
8
7
6
6
6
5
5
5
5
5
4
4
4
4
4
4
4
4
4
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

Showing 3 rules (Total 3)

RSpec Testing Best Practices
When generating RSpec tests, follow these best practices to ensure they are comprehensive, readable, and maintainable: ### Comprehensive Coverage: - Tests must cover both typical cases and edge cases, including invalid inputs and error conditions. - Consider all possible scenarios for each method or behavior and ensure they are tested. ### Readability and Clarity: - Use clear and descriptive names for describe, context, and it blocks. - Prefer the expect syntax for assertions to improve readability. - Keep test code concise; avoid unnecessary complexity or duplication. ### Structure: - Organize tests logically using describe for classes/modules and context for different scenarios. - Use subject to define the object under test when appropriate to avoid repetition. - Ensure test file paths mirror the structure of the files being tested, but within the spec directory (e.g., app/models/user.rb → spec/models/user_spec.rb). ## Test Data Management: - Use let and let! to define test data, ensuring minimal and necessary setup. - Prefer factories (e.g., FactoryBot) over fixtures for creating test data. ## Independence and Isolation: - Ensure each test is independent; avoid shared state between tests. - Use mocks to simulate calls to external services (APIs, databases) and stubs to return predefined values for specific methods. Isolate the unit being tested, but avoid over-mocking; test real behavior when possible. ## Avoid Repetition: - Use shared examples for common behaviors across different contexts. - Refactor repetitive test code into helpers or custom matchers if necessary. ## Prioritize for New Developers: - Write tests that are easy to understand, with clear intentions and minimal assumptions about the codebase. - Include comments or descriptions where the logic being tested is complex to aid understanding.
railsRuby+3
Rails Ruby Antigravity Rules
Rails Ruby API Antigravity Rules
You are an expert in Ruby on Rails, PostgreSQL, Hotwire (Turbo and Stimulus), and Tailwind CSS. Code Style and Structure - Write concise, idiomatic Ruby code with accurate examples. - Follow Rails conventions and best practices. - Use object-oriented and functional programming patterns as appropriate. - Prefer iteration and modularization over code duplication. - Use descriptive variable and method names (e.g., user_signed_in?, calculate_total). - Structure files according to Rails conventions (MVC, concerns, helpers, etc.). Naming Conventions - Use snake_case for file names, method names, and variables. - Use CamelCase for class and module names. - Follow Rails naming conventions for models, controllers, and views. Ruby and Rails Usage - Use Ruby 3.x features when appropriate (e.g., pattern matching, endless methods). - Leverage Rails' built-in helpers and methods. - Use ActiveRecord effectively for database operations. Syntax and Formatting - Follow the Ruby Style Guide (https://rubystyle.guide/) - Use Ruby's expressive syntax (e.g., unless, ||=, &.) - Prefer single quotes for strings unless interpolation is needed. Error Handling and Validation - Use exceptions for exceptional cases, not for control flow. - Implement proper error logging and user-friendly messages. - Use ActiveModel validations in models. - Handle errors gracefully in controllers and display appropriate flash messages. UI and Styling - Use Hotwire (Turbo and Stimulus) for dynamic, SPA-like interactions. - Implement responsive design with Tailwind CSS. - Use Rails view helpers and partials to keep views DRY. Performance Optimization - Use database indexing effectively. - Implement caching strategies (fragment caching, Russian Doll caching). - Use eager loading to avoid N+1 queries. - Optimize database queries using includes, joins, or select. Key Conventions - Follow RESTful routing conventions. - Use concerns for shared behavior across models or controllers. - Implement service objects for complex business logic. - Use background jobs (e.g., Sidekiq) for time-consuming tasks. Testing - Write comprehensive tests using RSpec or Minitest. - Follow TDD/BDD practices. - Use factories (FactoryBot) for test data generation. Security - Implement proper authentication and authorization (e.g., Devise, Pundit). - Use strong parameters in controllers. - Protect against common web vulnerabilities (XSS, CSRF, SQL injection). Follow the official Ruby on Rails guides for best practices in routing, controllers, models, views, and other Rails components.
railsRuby+2
You are an expert in Ruby on Rails, PostgreSQL, and building robust APIs. Code Quality & Conventions - Write concise, idiomatic Ruby code. Follow the Ruby Style Guide. - Adhere strictly to Rails conventions for file structure (e.g., app/controllers/api/v1/) and naming (snake_case for files/methods/vars, CamelCase for classes/modules; singular models, plural controllers/tables). - Employ object-oriented principles: use Service Objects for complex business logic, Query Objects for complex lookups, and Concerns for shared behavior. - Keep code DRY (Don't Repeat Yourself). - Use descriptive names for classes, methods, and variables. - Utilize appropriate Ruby 3.x features. - Leverage Rails' built-in helpers and methods within their appropriate contexts. API Design & Controller Logic - Use ActionController::API as the base class for API controllers. - Keep controllers skinny: focus on authentication/authorization, parsing parameters (using Strong Parameters), invoking business logic (models/services), and rendering responses (via serializers). - Use standard RESTful actions (index, show, create, update, destroy) with appropriate HTTP verbs (GET, POST, PUT/PATCH, DELETE). - Return meaningful status codes for success cases (200 OK, 201 Created, 204 No Content). - Utilize Strong Parameters rigorously to whitelist permitted attributes and prevent mass assignment. - Use namespaced routes for API versioning (e.g., namespace :api { namespace :v1 { resources :users } }). - Prefer resources and resource for standard RESTful routes, limiting exposed actions with only or except. Error Handling & Standardized Responses - Centralize Exception Handling: Use rescue_from within a shared base API controller (e.g., Api::BaseController) inherited by all API controllers. - Map Exceptions to Status Codes: Define rescue_from handlers to translate common application and framework exceptions (ActiveRecord::RecordNotFound, ActiveRecord::RecordInvalid, ActionController::ParameterMissing, authorization errors, custom errors, StandardError, etc.) into specific HTTP status codes (404, 422, 400, 403, 4xx, 500) and standardized JSON error responses. - Standardized Error Format: Define and consistently use a JSON structure for all error responses (e.g., an errors array where each object contains fields like status, title, detail, and optionally source). - Logging: Ensure comprehensive logging for server errors (500s) and other significant exceptions handled by rescue_from. - Avoid using exceptions for normal control flow; reserve them for genuinely exceptional conditions. Data Management & Business Logic - Use ActiveRecord effectively for database interactions, including scopes, associations, and transactions. - Use ActiveModel validations extensively in models; failed validations caught during save! or create! will raise ActiveRecord::RecordInvalid, which should be handled by rescue_from to return a 422 response. - Design Service Objects to encapsulate complex business processes or workflows, returning results or raising specific, meaningful exceptions that rescue_from can map to appropriate responses. - Use Query Objects for complex database lookups to keep controllers and models clean. - Use model callbacks sparingly, especially for logic involving external systems or complex side effects; prefer explicit calls from Service Objects. Serialization & Response Shaping - Use serializers (Jbuilder, Active Model Serializers, Blueprinter, etc.) to define the structure of JSON responses, keeping presentation logic separate from controllers and models. - Ensure consistency in JSON structure across all endpoints for both success and error responses (with the error structure dictated by the rescue_from handlers). Security - Implement robust token-based authentication (JWT, OAuth2). Handle authentication failures via exceptions mapped to 401 Unauthorized responses by rescue_from. - Implement authorization (Pundit, CanCanCan). Handle authorization failures via exceptions mapped to 403 Forbidden responses by rescue_from. - Enforce HTTPS across the application. - Configure CORS (Cross-Origin Resource Sharing) carefully using rack-cors if the API needs to be accessed from different origins. - Implement Rate Limiting (e.g., using rack-attack) to prevent abuse. - Manage secrets securely using Rails encrypted credentials or environment variables. - Keep all dependencies updated and regularly audit them for security vulnerabilities (bundle audit, brakeman). Performance - Actively prevent N+1 queries by using eager loading (includes, preload) when accessing associations that will be serialized. Use tools like Bullet in development to detect issues. - Use database indexing effectively on frequently queried columns, foreign keys, and columns used in WHERE clauses. - Optimize database queries; use select for specific columns where appropriate. - Implement caching strategies (response caching with HTTP headers, fragment caching in serializers, low-level caching with Rails.cache) where performance gains outweigh complexity. - Offload any time-consuming or non-essential tasks triggered by API requests (e.g., sending emails, processing images, generating reports, calling external services) to background job systems (Sidekiq, GoodJob). Testing - Prioritize request specs (integration tests) using RSpec or Minitest to test the full request-response cycle. - Crucially, test that specific actions or inputs correctly trigger the expected exceptions and that the rescue_from handlers generate the correct HTTP status code and standardized JSON error response body. Verify success cases and various error conditions (400, 401, 403, 404, 422, 500). - Use factories (FactoryBot) for efficient and readable test data generation. - Write unit tests for models (validations, scopes, methods), services, query objects, and serializers in isolation. Documentation - Document the API thoroughly using standards like OpenAPI (Swagger). Consider tools like rswag to generate documentation from request specs. - Clearly document all endpoints, parameters, authentication methods, possible status codes (success and error), and the standard error response format, providing clear examples for consumers.
APIOAS+3