Summary

Vigilante should support Ruby repositories with a dedicated Ruby-focused issue-implementation skill that teaches coding agents to work with Bundler and repo-standard Ruby tooling correctly and to account for current Ruby and gem-ecosystem security guidance during implementation.

Problem

• Vigilante currently has no Ruby-specific implementation skill.
• That makes coding agents more likely to miss Ruby-specific workflows such as Bundler lock discipline, repo-standard rubocop, framework-aware test commands, and gem security posture.
• Ruby's security posture is strongly shaped by gem and standard-library vulnerabilities, so a stack-specific skill is useful.

Context

• Ruby's official security page continues to publish current vulnerability advisories and points affected gem maintainers and users toward the correct reporting and upgrade paths.
• Ruby repositories often encode their standard validation path in Bundler, Rake, rubocop, rspec, Rails tasks, or similar commands; Vigilante should prefer those repo-defined paths.

Reference Material

• Ruby security: https://www.ruby-lang.org/en/security/
• Bundler docs: https://bundler.io/
• RubyGems guides: https://guides.rubygems.org/
• RuboCop docs: https://docs.rubocop.org/
• RSpec docs: https://rspec.info/documentation/
• bundler-audit: https://github.com/rubysec/bundler-audit
• Brakeman: https://brakemanscanner.org/

Desired Outcome

• Vigilante can detect Ruby repositories and attach a Ruby-specific implementation skill or equivalent prompt layer.
• The guidance tells the coding agent to use repo-standard Bundler, test, lint, and security-audit workflows.
• The guidance is concise and actionable and does not broaden issue scope unnecessarily.
• Existing operational policies, including vigilante commit, remain intact.

Implementation Notes

• Detect Ruby repositories using signals such as Gemfile, gems.rb, .ruby-version, Rails layout, or common Ruby package structure.
• Distill Ruby-specific execution rules for coding agents. Required areas to cover include:
  • using Bundler-managed commands rather than ad hoc gem execution
  • using repo-standard tests such as rspec, minitest, or framework-native tasks first
  • using repo-standard style and lint tooling such as rubocop when defined by the repo
  • dependency and gem-security checks such as bundler-audit when available and relevant
  • current security posture around unsafe deserialization, shell execution, secret handling, and framework defaults in Rails or similar stacks where applicable
• Preserve repo-specific instructions as authoritative over generic Ruby guidance.
• Preserve commit-path constraints: use vigilante commit only.

Acceptance Criteria

• Vigilante can recognize Ruby repositories and attach Ruby-specific implementation guidance.
• A dedicated Ruby-focused implementation skill or equivalent prompt layer exists.
• The guidance covers Bundler-managed validation and current Ruby/gem security posture.
• Existing issue-comment, validation-reporting, push/PR, and vigilante commit policies continue to apply.

Testing Expectations

• Add or update tests for Ruby repository detection and skill or prompt selection.
• Add or update tests for prompt content so Ruby repositories receive expected validation and security guidance and unrelated repositories do not.
• Cover regressions where the Ruby guidance is missing or incorrectly injected.

Operational / UX Considerations

• Prefer repo-defined tools over forcing Rails-specific or RuboCop-specific assumptions on every Ruby repository.

Recreated from #361 by Vigilante.