Problem
The init Goose recipe at src/templates/init_rule.md enumerates manifest files to scan (package.json, Cargo.toml, go.mod, pyproject.toml, Makefile, Justfile, Taskfile, build.gradle, pom.xml, composer.json, mix.exs) but omits Ruby entirely — no Gemfile, no gems.rb.
It also has no general step for detecting runtime version pinning files (.ruby-version, .nvmrc, .python-version, .tool-versions, etc.).
The result: when ai-rules init runs in a Ruby repo, the generated example.md never tells the agent which Ruby to use. Coding agents default to whatever /usr/bin/ruby resolves to (often macOS system Ruby 2.6.x), which:
- fails to parse modern Ruby syntax (e.g. comments between fluent dots, added in Ruby 2.7)
- can't resolve gems pinned to a newer ABI
- skips pre-commit/pre-push hooks that depend on a project-pinned Ruby
This affects every Ruby service that has run `ai-rules init`. The same gap exists for any repo pinning Node/Python/etc. via `.nvmrc` / `.python-version` if the surrounding manifest doesn't carry version info.
Proposed fix
Two surgical edits to `src/templates/init_rule.md`:
-
Add `Gemfile, gems.rb` to the manifest list in Step 2, and instruct the recipe to read the `ruby ""` directive.
-
Add a new Step 3: "Detect runtime version pinning" that finds `.ruby-version`, `.nvmrc`, `.node-version`, `.python-version`, `.tool-versions`, `rust-toolchain.toml`, `mise.toml`, cross-references them against manifest declarations, and — if found — requires the generated rule file to include a "Runtime / Toolchain" section with the exact activation command (e.g. `rvm use $(cat .ruby-version)`).
The new section maps each pinning file to its common version managers, defaulting to whichever the user has on `$PATH` (rvm for Ruby, nvm for Node, pyenv for Python).
Draft PR to follow.
Problem
The init Goose recipe at
src/templates/init_rule.mdenumerates manifest files to scan (package.json, Cargo.toml, go.mod, pyproject.toml, Makefile, Justfile, Taskfile, build.gradle, pom.xml, composer.json, mix.exs) but omits Ruby entirely — noGemfile, nogems.rb.It also has no general step for detecting runtime version pinning files (
.ruby-version,.nvmrc,.python-version,.tool-versions, etc.).The result: when
ai-rules initruns in a Ruby repo, the generatedexample.mdnever tells the agent which Ruby to use. Coding agents default to whatever/usr/bin/rubyresolves to (often macOS system Ruby 2.6.x), which:This affects every Ruby service that has run `ai-rules init`. The same gap exists for any repo pinning Node/Python/etc. via `.nvmrc` / `.python-version` if the surrounding manifest doesn't carry version info.
Proposed fix
Two surgical edits to `src/templates/init_rule.md`:
Add `Gemfile, gems.rb` to the manifest list in Step 2, and instruct the recipe to read the `ruby ""` directive.
Add a new Step 3: "Detect runtime version pinning" that finds `.ruby-version`, `.nvmrc`, `.node-version`, `.python-version`, `.tool-versions`, `rust-toolchain.toml`, `mise.toml`, cross-references them against manifest declarations, and — if found — requires the generated rule file to include a "Runtime / Toolchain" section with the exact activation command (e.g. `rvm use $(cat .ruby-version)`).
The new section maps each pinning file to its common version managers, defaulting to whichever the user has on `$PATH` (rvm for Ruby, nvm for Node, pyenv for Python).
Draft PR to follow.