plugins/lisa-rails-copilot/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) |
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.