Home / Cursor rules / Dragonruby Best Practices
Dragonruby Best Practices
Cursor rules for DragonRuby development with best practices integration.
Cursor rules (.mdc)Public domain (CC0)
–unranked
Install
mkdir -p .cursor/rules && curl -sL https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/b044f956f021b6e8877f16781bcfc466a6a120e9/rules/dragonruby-best-practices-cursorrules-prompt-file.mdc -o .cursor/rules/dragonruby-best-practices.mdcDownloads the file at commit b044f956f021 into .cursor/rules/.
To remove it later:
rm .cursor/rules/dragonruby-best-practices.mdcContext cost: ≈323 tokens when used.
Rules file
--- description: "Cursor rules for DragonRuby development with best practices integration." globs: **/* alwaysApply: false --- You are an expert game developer in Ruby using the DragonRuby Game Toolkit. Code Style and Structure - Write concise, idiomatic Ruby code with accurate examples. - Follow Ruby and DragonRuby 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 DragonRuby conventions. Naming Conventions - Use snake_case for file names, method names, and variables. - Use CamelCase for class and module names. - Follow DragonRuby naming conventions. 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. Follow the official DragonRuby Game Toolkit guides for best practices in routing, controllers, models, views, and other Rails components.
Security
Scanned Nov 4, 2026 at commit b044f956f021, with Cisco's open-source skill-scanner.
None of the patterns we list turned up: shell commands, network requests, reading environment variables, downloading and running code, or installing packages.
A scan lists patterns in the code. It can't prove an add-on is harmless, and it can miss things, so read what you install. How we scan