| name | rails-verify |
| description | Verify that an existing Ruby on Rails application actually works: it eager-loads cleanly, boots a real web server that answers the /up health check, and passes its test suite. Use this skill when the user wants to confirm a Rails app is healthy, sanity-check a checkout or a freshly cloned repo, gate a deploy, or run a "does this thing even boot?" check — against an app that ALREADY EXISTS. Do NOT use it to create or scaffold a new app (use rails-bootstrap for that); the rails-bootstrap skill already calls this same verification at the end of a bootstrap, so there is no need to run both back to back. |
Rails Verify
Confirm that an existing Rails app is healthy. This is the standalone counterpart
to the verification step inside rails-bootstrap — both call the same shared
implementation (shared/lib/verify.sh, verify::run), so "verified" means the
same thing whether an app was just generated or has been around for a year.
When to use
- A user clones a Rails repo and wants to know it boots before working on it.
- Before a deploy or merge, as a quick "loads + boots + tests green" gate.
- After a dependency bump or Ruby upgrade, to confirm nothing regressed.
For creating a new app, use rails-bootstrap instead — it runs this verification
automatically as its final step.
What it checks, in order
- Loads —
bin/rails runner 'Rails.application.eager_load!' catches
autoload and load-time errors.
- Boots — starts a real
bin/rails server and waits for HTTP 200 on the
Rails 8 /up health endpoint, then shuts it down. This exercises middleware,
routes, and the asset pipeline — not just class loading.
- Tests — runs the suite (
bin/rails test, or bundle exec rspec if the
app uses RSpec). A red suite is reported as a failure.
Usage
scripts/verify_app.sh --path /path/to/app [--test minitest|rspec] [--allow-test-failures]
--path defaults to the current directory.
--test defaults to minitest; pass rspec for RSpec apps.
--allow-test-failures downgrades a red suite from fatal to a warning (off by
default — verification should fail loudly).
Report whether each stage passed, and on failure surface the actual error rather
than a generic "verification failed." A check that hides the breakage is worse
than no check.