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 |
tools
Configure the official SonarQube plugin + MCP as Lisa's single Sonar substrate across every supported coding agent. Installs/updates the SonarQube CLI, authenticates (browser login on a dev machine, or SONARQUBE_CLI_TOKEN headless), selects the Test Manager target, runs `sonar integrate <agent>` for each supported agent (Claude, Codex, Cursor, Copilot, Antigravity) and wires the MCP for OpenCode, then writes only non-secret policy to .lisa.config.json. Separate from the CI SonarCloud scan gate, which is unchanged.
tools
Configure the official SonarQube plugin + MCP as Lisa's single Sonar substrate across every supported coding agent. Installs/updates the SonarQube CLI, authenticates (browser login on a dev machine, or SONARQUBE_CLI_TOKEN headless), selects the Test Manager target, runs `sonar integrate <agent>` for each supported agent (Claude, Codex, Cursor, Copilot, Antigravity) and wires the MCP for OpenCode, then writes only non-secret policy to .lisa.config.json. Separate from the CI SonarCloud scan gate, which is unchanged.
tools
Configure the official SonarQube plugin + MCP as Lisa's single Sonar substrate across every supported coding agent. Installs/updates the SonarQube CLI, authenticates (browser login on a dev machine, or SONARQUBE_CLI_TOKEN headless), selects the Test Manager target, runs `sonar integrate <agent>` for each supported agent (Claude, Codex, Cursor, Copilot, Antigravity) and wires the MCP for OpenCode, then writes only non-secret policy to .lisa.config.json. Separate from the CI SonarCloud scan gate, which is unchanged.
tools
Configure the official SonarQube plugin + MCP as Lisa's single Sonar substrate across every supported coding agent. Installs/updates the SonarQube CLI, authenticates (browser login on a dev machine, or SONARQUBE_CLI_TOKEN headless), selects the Test Manager target, runs `sonar integrate <agent>` for each supported agent (Claude, Codex, Cursor, Copilot, Antigravity) and wires the MCP for OpenCode, then writes only non-secret policy to .lisa.config.json. Separate from the CI SonarCloud scan gate, which is unchanged.