plugins/lisa-rails-agy/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 |
documentation
Onboard a user to the project via its LLM Wiki. Interviews the user about themselves in relation to the project, captures that to project-scoped memory only, then gives a guided tour of what the project is and sample questions they can ask. Use when someone is new to the project or asks to be onboarded. Read-mostly — it does not open PRs or write PII into the wiki.
documentation
Migrate an existing, hand-rolled wiki implementation onto the lisa-wiki kernel — phased and compatibility-first, with a strict no-loss guarantee. Use when adopting lisa-wiki in a repo that already has its own wiki/, ingest skills, docs, or roles. Renaming things into the canonical shape is fine; losing functionality or data is not. Ends by running /doctor.
development
Health-check the LLM Wiki. Reports orphan pages, contradictions, stale claims, broken internal links, missing index/log coverage, structure-manifest violations, and secret/tenant leaks. Use periodically or before hardening a wiki. Read-only — it reports findings, it does not fix them.
testing
Ingest source material into the LLM Wiki. With an argument (URL, file path, or prompt) it ingests that one source; with no argument it runs a full ingest across every enabled non-external-write source. Routes to the right connector, then runs the ordered pipeline (source note → synthesis → index → log → verify → state → commit/PR). Use whenever new knowledge should enter the wiki.