CtrlK
BlogDocsLog inGet started
Tessl Logo

igmarin/rails-agent-skills

Curated library of 42 public AI agent skills for Ruby on Rails development, plus 5 callable workflow skills. Organized by category: planning, testing, code-quality, ddd, engines, infrastructure, api, patterns, context, orchestration, and workflows. Covers code review, architecture, security, testing (RSpec), engines, service objects, DDD patterns, and TDD automation.

96

Quality

96%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Risky

Do not use without reviewing

Overview
Quality
Evals
Security
Files

SKILL.mdskills/engines/review-engine/

name:
review-engine
license:
MIT
description:
Use when reviewing a Rails engine, mountable engine, or Railtie. Covers namespace boundaries, host-app integration, safe initialization, migrations, generators, and dummy app test coverage. Prioritizes architectural risks.
metadata:
{"version":"1.0.0","user-invocable":"true"}

Review Engine

Use this skill when the task is to review an existing Rails engine or propose improvements.

Prioritize architectural risks over style comments. The main review targets are coupling, unclear host contracts, unsafe initialization, and weak integration coverage.

Quick Reference

Review AreaKey Checks
Namespaceisolate_namespace used; clear boundaries; no host constant leakage
Host integrationConfiguration seams, adapters; no direct host model access
InitNo side effects at load time; reload-safe hooks in config.to_prepare
MigrationsDocumented, copied via generator; no implicit or destructive steps
Dummy appPresent in spec/; used for integration tests; exercises real mount and config

Review Order

  1. Identify the engine type and purpose.

    • Read lib/<engine_name>/engine.rb and lib/<engine_name>/railtie.rb (if present).
    • Confirm whether it is isolated (isolate_namespace) or plain.
  2. Inspect the namespace and public API surface.

    • grep -r "isolate_namespace" lib/ — must appear in the engine class.
    • grep -rn "::\|^[A-Z]" lib/ — look for unqualified top-level constant references that may leak into or depend on the host.
  3. Check host-app integration points.

    • grep -rn "Rails.application\|::User\|::Account\|::Current" lib/ — flag direct host constant references.
    • Verify that any host dependency flows through a config seam or adapter (e.g., MyEngine.config.user_finder).
  4. Check initialization and reload behavior.

    • Inspect every initializer, config.to_prepare, and ActiveSupport.on_load block in engine.rb.
    • grep -n "initializer\|on_load\|to_prepare\|autoload" lib/<engine_name>/engine.rb
    • Flag anything that mutates global state or runs code at require time outside an initializer block.
  5. Check migrations, generators, and install flow.

    • Confirm migrations are copied via a generator (rails g <engine>:install) rather than loaded directly.
    • grep -rn "migrations_paths\|railties_order" lib/ — check for implicit or order-dependent migration setup.
    • Check for destructive or irreversible migrations (missing down or change with unsafe operations).
  6. Check dummy-app and integration tests.

    • Confirm spec/dummy/ (or test/dummy/) exists and contains a mounted route in config/routes.rb.
    • grep -rn "mount\|routes" spec/dummy/config/routes.rb
    • Verify integration tests boot the dummy app and exercise the mount point, not just unit-test engine classes in isolation.
  7. Pre-summary validation checkpoint. Before writing findings, confirm every row in the Quick Reference table has been addressed:

    • Namespace isolation verified
    • Host integration points checked
    • engine.rb initializer blocks inspected
    • Migration/generator flow confirmed
    • Dummy app presence and usage confirmed
    • Integration tests exercise real mount

    If any box cannot be checked (e.g., file not provided), record it as an open assumption.

  8. Summarize findings by severity.

Common Mistakes

MistakeReality
Reviewing code style before architectureStyle is low impact; coupling, host assumptions, and unsafe init cause production failures
Missing dummy app coverage checkDummy app must exist and be used; engines without it cannot prove host integration works
Ignoring engine.rbengine.rb often contains boot-time side effects; always inspect it

Severity Tiers

See FINDINGS.md for the full High / Medium / Low severity lists and Common Fixes if available. Otherwise apply these inline definitions:

  • High — causes production failures or breaks host integration (e.g., direct host constant coupling, unsafe boot-time side effects, irreversible migrations without a down method).
  • Medium — degrades maintainability or makes the engine fragile across host apps (e.g., undocumented configuration seams, missing install generator, no dummy app).
  • Low — style or minor clarity issues; do not surface before architecture findings.

Flag High findings first. Do not surface Low findings before architecture issues.

Output Format

Write findings first. For each finding include:

  • severity
  • affected file or area
  • why it is risky
  • the smallest credible fix

Then include:

  • open assumptions
  • recommended next changes

If no meaningful findings exist, say so explicitly and mention any residual testing gaps.

Examples

High-severity finding (engine reaching into host):

# Bad: engine assumes host model
class MyEngine::SomeService
  def call
    User.find(current_user_id)  # User is host app; engine is coupled
  end
end
  • Severity: High. Area: MyEngine::SomeService. Risk: Engine depends on host User; breaks when used in another app. Fix: Introduce config: MyEngine.config.user_finder = ->(id) { User.find(id) } (or an adapter), and use that in the engine.

Good (configuration seam):

# Good: engine uses configured dependency
class MyEngine::SomeService
  def call
    MyEngine.config.user_finder.call(current_user_id)
  end
end

See assets/examples.md for additional annotated examples if available.

Integration

SkillWhen to chain
create-engineWhen implementing suggested fixes or refactoring the engine
test-engineWhen adding missing dummy-app or integration coverage
upgrade-engineWhen assessing Rails/Ruby version support or deprecation impact

skills

README.md

tile.json