plugins/lisa-rails/skills/ops-run-local/SKILL.md
Manage the local Docker Compose development environment for Rails applications. Supports start, stop, restart, and status for the full stack or individual services.
npx skillsauth add codyswanngt/lisa ops-run-localInstall 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.
Manage the local Docker Compose development environment.
Argument: $ARGUMENTS — start, stop, restart, status, start-app, start-services (default: start)
Verify Docker is running:
docker info > /dev/null 2>&1 && echo "Docker OK" || echo "ERROR: Docker is not running — start Docker Desktop"
Check port availability:
lsof -i :3000 2>/dev/null | grep LISTEN
lsof -i :5432 2>/dev/null | grep LISTEN
Verify Ruby and Bundler are available:
ruby --version && bundle --version
Read the project's docker-compose.yml (or compose.yaml) to identify available services. Common services include:
web or app — the Rails applicationpostgres or db — PostgreSQL databaseworker — Solid Queue background workercss — Tailwind CSS watch processRead Procfile.dev if it exists — it defines the local development process manager configuration (typically run via bin/dev).
Read config/database.yml to understand which databases need to exist locally.
Start all Docker Compose services and the Rails application.
Start infrastructure services (PostgreSQL, etc.):
docker compose up -d postgres
Wait for PostgreSQL (up to 30 seconds):
for i in $(seq 1 30); do
docker compose exec -T postgres pg_isready -U postgres > /dev/null 2>&1 && echo "PostgreSQL ready" && break
sleep 1
done
Create and migrate databases (if needed):
bin/rails db:prepare
Start the full stack via bin/dev (Procfile.dev) or Docker Compose:
# Option A: Procfile.dev (preferred — starts web, worker, CSS watcher)
bin/dev
Run this in the background using the Bash tool with run_in_background: true.
# Option B: Docker Compose (if all services are containerized)
docker compose up -d
Wait for Rails (up to 60 seconds):
for i in $(seq 1 60); do
curl -sf http://localhost:3000/up > /dev/null 2>&1 && echo "Rails ready" && break
sleep 1
done
Report status table.
Start only infrastructure services (database, cache) without the Rails app.
docker compose up -d postgres
Wait for readiness:
for i in $(seq 1 30); do
docker compose exec -T postgres pg_isready -U postgres > /dev/null 2>&1 && echo "PostgreSQL ready" && break
sleep 1
done
bin/dev
Run in background. Verify:
for i in $(seq 1 60); do
curl -sf http://localhost:3000/up > /dev/null 2>&1 && echo "Rails ready" && break
sleep 1
done
Stop all local services.
# Stop Rails processes (bin/dev uses foreman which spawns child processes)
lsof -ti :3000 | xargs kill -9 2>/dev/null || echo "No Rails process on :3000"
# Stop Docker Compose services
docker compose down
sleep 2Check what is currently running and responsive.
echo "=== Port Check ==="
echo -n "Rails :3000 — "; lsof -i :3000 2>/dev/null | grep LISTEN > /dev/null && echo "LISTENING" || echo "NOT LISTENING"
echo -n "Postgres :5432 — "; lsof -i :5432 2>/dev/null | grep LISTEN > /dev/null && echo "LISTENING" || echo "NOT LISTENING"
echo ""
echo "=== Health Check ==="
echo -n "Rails /up — "; curl -sf -o /dev/null -w "HTTP %{http_code} in %{time_total}s" http://localhost:3000/up 2>/dev/null || echo "UNREACHABLE"
echo ""
echo "=== Docker Compose ==="
docker compose ps 2>/dev/null || echo "No Docker Compose services running"
echo ""
echo "=== Solid Queue Worker ==="
bin/rails runner "puts SolidQueue::Process.where('last_heartbeat_at > ?', 5.minutes.ago).count.to_s + ' active workers'" 2>/dev/null || echo "Cannot query Solid Queue (app may not be running)"
Report results as a table:
| Service | Port | Listening | Responsive | |---------|------|-----------|------------| | Rails (web) | 3000 | YES/NO | YES/NO | | PostgreSQL | 5432 | YES/NO | N/A | | Solid Queue worker | N/A | N/A | YES/NO (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.