plugins/src/rails/skills/ops-deploy/SKILL.md
Deploy Rails applications via Kamal or CI/CD branch push to staging or production environments.
npx skillsauth add codyswanngt/lisa ops-deployInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Deploy the Rails application to remote environments.
Argument: $ARGUMENTS — environment (staging, production) and optional method (kamal, ci; default: kamal)
CRITICAL: Production deployments require explicit human confirmation before proceeding. Always ask for confirmation when $ARGUMENTS contains production.
config/deploy.yml to discover the Kamal configuration: service name, registry, image, servers, accessoriesconfig/deploy.staging.yml and config/deploy.production.yml for environment-specific overrides.env.staging / .env.production (or in SSM) without printing secret valuesDockerfile to understand the Docker build stagesThe standard deployment path is via CI/CD — pushing to environment branches triggers auto-deploy.
# Deploy to staging via CI/CD
git push origin HEAD:staging
# Deploy to production via CI/CD (requires human confirmation first)
git push origin HEAD:production
Monitor the deployment via GitHub Actions:
gh run list --branch {environment} --limit 3
gh run watch {run-id}
Verify Kamal is installed:
kamal version
Verify Docker builds locally:
docker build -t {app_name}:test .
Check current deployment state:
kamal details -d {environment}
Check for deploy lock:
kamal lock status -d {environment}
If locked from a previous interrupted deploy: kamal lock release -d {environment}
kamal deploy -d staging
Requires explicit human confirmation.
kamal deploy -d production
kamal deploy -d {environment} --version {git-sha-or-tag}
If a deploy causes issues, roll back to the previous version:
# List available versions
kamal app containers -d {environment}
# Rollback to previous version
kamal rollback {previous-version} -d {environment}
After any deployment:
Health check the deployed environment:
curl -sf -o /dev/null -w "HTTP %{http_code} in %{time_total}s" https://{app_host}/up
Verify ECS service stability (running count matches desired count):
aws ecs describe-services \
--cluster {cluster-name} \
--services {service-name} \
--region {aws-region} \
--query 'services[0].{Running:runningCount,Desired:desiredCount,Status:status}' \
--output table
Check for migration status (if migrations were included):
kamal app exec --roles=web "bin/rails db:migrate:status" -d {environment}
Check logs for errors in the first 5 minutes (use ops-check-logs skill)
Verify Solid Queue workers are running (use ops-verify-jobs skill)
Verify OpenTelemetry traces are being exported (use ops-verify-telemetry skill)
| Command | Purpose |
|---------|---------|
| kamal details -d {env} | Show current deployment details |
| kamal app logs -d {env} | Tail application logs |
| kamal app exec --roles=web "bin/rails console" -d {env} | Open Rails console on remote |
| kamal audit -d {env} | Show deploy audit log |
| kamal env push -d {env} | Push updated environment variables |
| kamal lock status -d {env} | Check deploy lock status |
| kamal lock release -d {env} | Release a stale deploy lock |
| kamal traefik reboot -d {env} | Restart the Traefik proxy |
Report deployment result as a table:
| Target | Environment | Method | Status | Verification | |--------|-------------|--------|--------|-------------| | Rails app | staging | Kamal | SUCCESS/FAIL | /up returns 200 | | ECS tasks | staging | N/A | STABLE/UNSTABLE | running == desired | | Solid Queue | staging | N/A | RUNNING/DOWN | workers have heartbeat |
tools
--- name: harper-realtime description: This skill should be used when adding or troubleshooting Harper (HarperDB/Fabric) real-time behavior: MQTT topics, WebSocket resource subscriptions, resource publish/subscribe handlers, SSE-style streaming routes, and local subscriber verification. Pairs with harper-resources, harper-config-yaml, harper-schema-graphql, and harper-build-and-deploy. --- # Harper Realtime ## Overview Harper exposes live data through the same Resource model used for REST and
tools
--- name: harper-realtime description: This skill should be used when adding or troubleshooting Harper (HarperDB/Fabric) real-time behavior: MQTT topics, WebSocket resource subscriptions, resource publish/subscribe handlers, SSE-style streaming routes, and local subscriber verification. Pairs with harper-resources, harper-config-yaml, harper-schema-graphql, and harper-build-and-deploy. --- # Harper Realtime ## Overview Harper exposes live data through the same Resource model used for REST and
tools
--- name: harper-realtime description: This skill should be used when adding or troubleshooting Harper (HarperDB/Fabric) real-time behavior: MQTT topics, WebSocket resource subscriptions, resource publish/subscribe handlers, SSE-style streaming routes, and local subscriber verification. Pairs with harper-resources, harper-config-yaml, harper-schema-graphql, and harper-build-and-deploy. --- # Harper Realtime ## Overview Harper exposes live data through the same Resource model used for REST and
tools
--- name: harper-realtime description: This skill should be used when adding or troubleshooting Harper (HarperDB/Fabric) real-time behavior: MQTT topics, WebSocket resource subscriptions, resource publish/subscribe handlers, SSE-style streaming routes, and local subscriber verification. Pairs with harper-resources, harper-config-yaml, harper-schema-graphql, and harper-build-and-deploy. --- # Harper Realtime ## Overview Harper exposes live data through the same Resource model used for REST and