From ultraship
Runs pre-flight checks for env vars, migrations (Drizzle/Prisma/Knex), bundle size, git status, rollback plan, then deploys to Vercel, Railway, Fly.io, Cloudflare, Docker, or git.
npx claudepluginhub houseofmvps/ultraship --plugin ultraship<environment>This skill uses the workspace's default tool permissions.
Full pre-flight validation → deploy pipeline. Closes the audit-to-production loop.
Deploys applications to Vercel, Netlify, AWS, GCP, DigitalOcean, or VPS after pre-deploy tests, security scans, build verification, and health checks. Activates on 'deploy', 'push to production', 'ship it'.
Generates pre-deployment checklists for code quality, security, performance, infrastructure, database migrations, and produces go/no-go readiness report.
Provides pre-launch checklists for safe production deployments, covering code quality, security, performance, accessibility, infrastructure, documentation, feature flags, monitoring, and rollback strategies.
Share bugs, ideas, or general feedback.
Full pre-flight validation → deploy pipeline. Closes the audit-to-production loop.
Check project for deploy configuration:
vercel.json or .vercel/ → Vercel (git push)railway.toml or railway.json → Railwayfly.toml → Fly.iowrangler.toml → Cloudflare Workers.github/workflows/ with deploy steps → CI/CD pipelineDockerfile → Container-based deployRun these checks BEFORE deploying (fail fast):
2a. Environment Validation
node ${CLAUDE_PLUGIN_ROOT}/tools/env-validator.mjs <project-directory>
If deploy_ready: false → STOP. Show missing vars. Do not deploy.
2b. Migration Safety
node ${CLAUDE_PLUGIN_ROOT}/tools/migration-checker.mjs <project-directory>
If deploy_safe: false → WARN. Show pending migrations. Ask user to confirm.
If there are pending migrations, verify they are reversible:
down SQL or rollback logic existsprisma migrate resolve can undo the migrationdown() function exists and is not empty2c. Bundle Size Check
node ${CLAUDE_PLUGIN_ROOT}/tools/bundle-tracker.mjs <project-directory> --save
If bundle grew >50KB since last check → WARN. Show diff.
2d. Git Status Check for uncommitted changes:
git status --porcelain
If dirty working tree → WARN. Suggest committing first.
2e. Rollback Plan
Before deploying, establish a rollback plan. Every deploy must have a way back.
Record the current production commit hash:
git rev-parse HEAD
Store this value — it is your safety net. If anything goes wrong after deploy, this is the commit you revert to.
Verify the rollback command is ready:
git revert <commit> --no-edit
Do not execute this yet. Confirm the command is syntactically correct and the commit hash is valid. The goal is to have a copy-paste rollback ready before you need it — not after you're panicking at 2am.
For database changes:
down migration (checked in Step 2b)pg_dump the affected tables before deploying, or use a feature flag to decouple the schema change from the code changeFor breaking API changes:
Document the rollback steps in a format that can be executed under pressure:
ROLLBACK PLAN:
1. git revert <new-commit-hash> --no-edit
2. git push origin main
3. [If DB migration]: run down migration or restore from backup
4. Verify health check passes after rollback
Run the full /ship scorecard. If overall score < 60 → WARN but don't block (user decides).
A score below 60 means there are known issues going to production. That is a conscious decision, not an accident. Log it so the post-deploy summary reflects the risk accepted.
Based on detected target:
Vercel (git push — REQUIRED for this user):
git push origin main
NEVER use vercel CLI. Always git push.
Railway:
railway up
Fly.io:
fly deploy
Cloudflare Workers:
npx wrangler deploy
CI/CD:
git push origin main
Then check CI status:
gh run list --limit 1 --json status,conclusion
Record the deploy start time. You will need this for the post-deploy summary.
After deploy lands but before declaring success, verify the application actually works for real users. A successful git push is not a successful deploy — it is a successful file transfer.
Hit 3-5 critical user paths against the production URL:
node ${CLAUDE_PLUGIN_ROOT}/tools/api-smoke-test.mjs <production-url>
At minimum, verify:
Verify response codes and content types:
Content-Type (HTML for pages, JSON for APIs){ "error": true } inside a 200 status codeIf Playwright MCP is available, run a quick browser check on the production URL:
If any smoke test fails, execute the rollback plan immediately. Do not debug in production. Do not "just check one more thing." Roll back, confirm the rollback is healthy, then investigate the failure from safety. The cost of a 5-minute rollback is always less than the cost of a 30-minute production outage while you debug.
After deploy completes, run health check against production URL:
node ${CLAUDE_PLUGIN_ROOT}/tools/health-check.mjs <production-url>
Report: status code, response time, SSL status, security headers.
If the health check fails on the first attempt, wait 30 seconds and retry once. Some platforms (Vercel, Railway) have a cold-start window where the first request after deploy is slow or fails. Two consecutive failures means the deploy is broken — trigger rollback.
After confirming the deploy is healthy, record performance metrics as the new baseline.
Record the response time from the health check as the post-deploy baseline:
node ${CLAUDE_PLUGIN_ROOT}/tools/health-check.mjs <production-url>
Compare to the pre-deploy baseline:
Check platform-level metrics if available:
fly status and fly logs for health check failures or OOM killsStore the performance baseline for comparison on the next deploy:
node ${CLAUDE_PLUGIN_ROOT}/tools/audit-history.mjs save <project-dir> response_time <ms>
Save all scores for before/after comparison:
node ${CLAUDE_PLUGIN_ROOT}/tools/audit-history.mjs save <project-dir> seo <score>
node ${CLAUDE_PLUGIN_ROOT}/tools/audit-history.mjs save <project-dir> performance <score>
node ${CLAUDE_PLUGIN_ROOT}/tools/audit-history.mjs save <project-dir> security <score>
Output deployment summary:
====================================
DEPLOY COMPLETE
====================================
Target: Vercel (git push)
Branch: main
Commit: abc1234
URL: https://example.com
Health: HEALTHY (247ms)
SSL: Valid (89 days remaining)
====================================
Pre-flight: 3/3 passed
Ship Score: 90/100
====================================
Response Time: 247ms (prev: 210ms, +17%)
Deploy Duration: 2m 14s (push → health check pass)
====================================
ROLLBACK COMMAND (ready to copy-paste):
git revert abc1234 --no-edit && git push origin main
====================================
Include in every post-deploy summary:
Not all deploys carry the same risk. A staging deploy that breaks is a Slack message. A production deploy that breaks is revenue loss and user trust damage. Treat them differently.
Staging exists to catch what pre-flight checks cannot — integration issues, data-dependent bugs, and UX regressions that only appear with real-ish data.
Production is where your reputation lives. Every production deploy is a promise to your users that the product still works.
A hotfix is production on fire. Speed matters, but not more than making things worse.
Never deploy without a rollback plan — the deploy that cannot be undone is the deploy that breaks production for hours. Every minute you spend writing a rollback plan before deploying is ten minutes you save when you need to execute it at 2am with your heart racing. Rollback is not a sign of failure. It is the mark of an engineer who builds safety nets before walking the wire.
Smoke test before celebrating — a successful deploy is not a 200 from the health endpoint. It is users completing their core workflow. Health checks confirm the server is running. Smoke tests confirm the product is working. These are different things, and the gap between them is where production incidents live.
Deploy is not done when the code lands — it is done when you have confirmed it works, recorded the metrics, and the rollback window has passed. A deploy without post-verification is a coin flip you made with your users' experience. Close the loop: deploy, verify, measure, document.
Respect the blast radius — database migrations, API changes, and infrastructure updates are higher risk than UI changes. Treat them differently. A CSS fix that breaks a button color is a 5-minute fix. A migration that drops a column is a restore-from-backup event. The pre-flight checks, the rollback plan, the smoke tests — they are proportional to the blast radius, not the line count.
Never deploy with missing env vars — this is the #1 production failure. It is also the most preventable. The env validator exists for a reason. If it says something is missing, something is missing.
Always health check after deploy — catch issues before users do. Your monitoring should tell you about problems before your users do. If your users are telling you the site is down, your deploy process failed twice: once when it broke, and once when it did not catch the break.
Save history — track improvement over time. Deploy metrics without history are just numbers. Deploy metrics with history are a trendline. Trendlines tell you whether your deploys are getting safer or riskier, faster or slower, more reliable or less.
Respect user preferences — Vercel = git push only, never CLI.