Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From bopen-tools
Runs shell scripts to check deployment health, service connectivity (Vercel, Railway, Redis, PostgreSQL), validate environment variables, and perform pre-deploy smoke tests with structured JSON output.
npx claudepluginhub b-open-io/claude-plugins --plugin bopen-toolsHow this skill is triggered — by the user, by Claude, or both
Slash command
/bopen-tools:devops-scriptsThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Mechanical infrastructure checks are handled by scripts. The agent's job is to run them and act on the structured JSON they return — not to reinvent connectivity probes inline.
Runs production readiness checklist verifying environment variables, health endpoints, error monitoring, CORS, rate limiting, security headers, performance, database, and DNS/SSL config before deployment.
Generates pre-deployment checklists for code quality, security, performance, infrastructure, database migrations, and produces go/no-go readiness report.
Validates integrated build pipelines and running services using health checks and smoke tests. Use when verifying project builds and service health.
Share bugs, ideas, or general feedback.
Mechanical infrastructure checks are handled by scripts. The agent's job is to run them and act on the structured JSON they return — not to reinvent connectivity probes inline.
health-check.sh — Service ConnectivityChecks Vercel deployment status, Railway project status, Redis connectivity, and PostgreSQL connectivity. Each service is checked independently; missing CLI tools produce an informative JSON error rather than crashing the script.
bash <skill-path>/scripts/health-check.sh
Reads from environment:
REDIS_URL — defaults to redis://localhost:6379DATABASE_URL — defaults to postgresql://localhost:5432/devVERCEL_ORG_ID — optional, scopes the vercel ls checkReturns JSON:
{
"overall": "ok",
"services": {
"vercel": { "status": "ok", "error": "" },
"railway": { "status": "missing_tool", "error": "railway CLI not found — install with: bun add -g @railway/cli" },
"redis": { "status": "ok", "error": "" },
"postgres": { "status": "error", "error": "Connection refused" }
}
}
status value | Meaning |
|---|---|
ok | Service responded successfully |
error | CLI found but check failed — read error for details |
missing_tool | CLI not installed — error contains install instructions |
skipped | Not reached (should not appear in normal output) |
Act on results:
overall: "ok" — all checked services healthy, proceedoverall: "error" — at least one service failed; read the error field and fix before deployingmissing_tool — tell the user which CLI to install; do not block deployment for unrelated servicesverify-env.sh — Environment Variable ValidationTakes a list of variable names as arguments. Reports which are set and which are missing.
bash <skill-path>/scripts/verify-env.sh REDIS_URL DATABASE_URL VERCEL_TOKEN BSV_PRIVATE_KEY
Returns JSON:
{
"all_set": false,
"present": ["REDIS_URL", "DATABASE_URL"],
"missing": ["VERCEL_TOKEN", "BSV_PRIVATE_KEY"]
}
Use this before any deployment or migration. If all_set is false, report each missing variable and where to set it (Vercel dashboard, Railway variables, or .env.local) — then stop. Do not proceed with a deployment that is missing required secrets.
| Situation | Script |
|---|---|
| Pre-deploy smoke check | Both — verify env first, then health-check |
| Diagnosing a broken staging environment | health-check.sh |
| Setting up a new environment | verify-env.sh with the project's required vars |
| Post-deploy validation | health-check.sh |
| CI pre-flight gate | verify-env.sh with secrets the pipeline needs |
1. Run verify-env.sh with required vars → confirm all_set: true
2. Run health-check.sh → confirm overall: "ok"
3. Deploy
4. Run health-check.sh again post-deploy → confirm services still healthy
If any step produces an error, fix it before continuing. These scripts never retry or fall back silently — a clear failure now prevents a silent failure in production.