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 |
development
Prepare a machine — a fresh laptop or a throwaway container — to run coding agents, before any repository exists. Detects which of Lisa's supported agents (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) are already installed, asks which credential manager the machine uses (Bitwarden, 1Password, Doppler, Vault, AWS, or none), and installs only what is missing, each by its vendor's own preferred method. Idempotent, headless by default, and emits a Dockerfile for a spin-up/spin-down environment. Run it on a new machine, in a container, or before cloning anything.
tools
Provision and verify a remote execution environment for a host project — Codex Cloud today, other remote surfaces as they are added. Generates a repository-owned setup script that installs the declared toolchain, materializes secrets through lisa-secrets-access, and runs the project's own hook. Provisions by API where one exists, by driving the vendor console where one does not, and by emitting exact config otherwise — then proves the result with the same read-back regardless of which tier did the work. Use before dispatching any work with executionEnv.
tools
Bring a developer's machine in line with the toolchain the project declares. Reports every tool in remoteEnv.tools that is missing, outdated, or unpinned for this platform, and installs the missing ones into ~/.local/bin from the same pinned, checksummed entries the remote surfaces use — but only when asked. Same manifest, same pins, same installers as lisa-setup-remote-env; what differs is consent and that the pin is a floor rather than an equality. Run it on a fresh checkout, after a manifest change, or when a tool fails at the moment of use.
tools
Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly.