-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
feat: define thoughtbot rules for AI-enabled IDEs #764
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| # IDE AI thoughtbot rules | ||
|
|
||
| You are an expert in Ruby on Rails, PostgreSQL, and Hotwire (Turbo and Stimulus). | ||
|
|
||
| ## Key Conventions | ||
|
|
||
| - Follow RESTful routing conventions: Seven restful actions: index, show, new, create, edit, update, delete (https://thoughtbot.com/blog/in-relentless-pursuit-of-rest-ish-routing) | ||
|
Check failure on line 7 in rails/ai-rules/rails-rules.md
|
||
| - Use concerns for shared behavior across models or controllers | ||
|
|
||
| ## Data / Models | ||
|
|
||
| - To find model structure look in `db/schema.rb` | ||
| - When working with model attributes don’t guess, grep the schema at `db/schema.rb` to confirm and use only valid attributes | ||
|
|
||
| ## UI and Styling | ||
|
|
||
| - Use Rails view helpers and partials to keep views DRY | ||
|
|
||
| ## Performance Optimization | ||
|
|
||
| - Always check for N+1 queries when rendering collections | ||
| - Prefer includes for eager loading | ||
| - Scope queries to only the fields needed with select | ||
|
||
|
|
||
| ## Testing | ||
|
|
||
| - Always write tests to cover new code generated | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we tell it to write tests first? I think @JoelQ had more success with that.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have struggled with this one personally when working with Cursor. Normally I will write some basic tests, and based on that, I would get a much better suggestion for the feature and then iterate. After having the firsts tests, the tests examples that come after are good. @JoelQ do you have any suggestions about how to make the rules effective to follow TDD?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've usually done that with an initial prompt. Zed's agent (using Claude) does this well. |
||
| - Use RSpec for testing framework | ||
laicuRoot marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| - Use factories (FactoryBot) (https://thoughtbot.github.io/factory_bot/) | ||
|
Check failure on line 29 in rails/ai-rules/rails-rules.md
|
||
| - In tests, avoid lets and before (avoid mystery guests), do test setup within each test | ||
| - Verify new code by running test files using `bundle exec rspec spec/path/to/file_spec.rb` | ||
| - You can run a specific test by appending the line number (it can be any line number starting from the "it" block of the test) eg. `bundle exec rspec spec/path/to/file_spec.rb:72` | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.