Rails Engine Reviewer

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 Order

1. Identify the engine type and purpose.
2. Inspect the namespace and public API surface.
3. Check host-app integration points.
4. Check initialization and reload behavior.
5. Check migrations, generators, and install flow.
6. Check dummy-app and integration tests.
7. Summarize findings by severity.

Common Mistakes

Severity Tiers

See FINDINGS.md for the full High / Medium / Low severity lists and Common Fixes. Flag High findings first — they cause production failures. Low findings are style; do not surface them 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

Integration