verify-deployment
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- DevOps
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Shell exec
- Write / modify
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: verify-deployment
description: Use this skill when the user asks to "verify my deployment", "check if everything is working", "…
category: devops
runtime: no special runtime
---
# verify-deployment output preview
## PART A: Task fit
- Use case: Use this skill when the user asks to "verify my deployment", "check if everything is working", "test my deployment", "check if my services are up", "run health checks", or when invoked by deploy-project as the final step after CI/CD setup. Reads DEPLOYMENT_DOCS/DEPLOYED_ENV.md for service URLs, runs HTTP health checks on all services, uses agent-browser to visually verify the frontend loads, tests cross-service connectivity (frontend calls backend, backend connects to DB), and prints a pass/fail summary table. Retries Render backend endpoints up to 3 times due to free tier cold starts..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Step 1: Read DEPLOYMENTDOCS/DEPLOYEDENV.md / Step 2: HTTP health checks for all services / Step 3: agent-browser visual check of frontend” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Use this skill when the user asks to "verify my deployment", "check if everything is working", "test my deployment", "check if my services are up", "run health checks", or when invoked by deploy-project as the final step after CI/CD setup. Reads DEPLOYMENT_DOCS/DEPLOYED_ENV.md for service URLs, runs HTTP health checks on all services, uses agent-browser to visually verify the frontend loads, tests cross-service connectivity (frontend calls backend, backend connects to DB), and prints a pass/fail summary table. Retries Render backend endpoints up to 3 times due to free tier cold starts.”.
- **02** When the source has headings, the agent prioritizes “Step 1: Read DEPLOYMENTDOCS/DEPLOYEDENV.md / Step 2: HTTP health checks for all services / Step 3: agent-browser visual check of frontend” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, run shell commands, write/modify files; may access external network resources; usually needs no extra API key.
## Running Rules
- read files, run shell commands, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/dev`, `/health`, `/api`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, run shell commands, write/modify files.
Start with a small task and check whether the result follows “Step 1: Read DEPLOYMENTDOCS/DEPLOYEDENV.md / Step 2: HTTP health checks for all services / Step 3: agent-browser visual check of frontend”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: verify-deployment
description: Use this skill when the user asks to "verify my deployment", "check if everything is working", "…
category: devops
source: tomevault-io/skills-registry
---
# verify-deployment
## When to use
- Use this skill when the user asks to "verify my deployment", "check if everything is working", "test my deployment", "…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Step 1: Read DEPLOYMENTDOCS/DEPLOYEDENV.md / Step 2: HTTP health checks for all services / Step 3: agent-browser visual check of frontend” and keep inference separate from source facts.
- read files, run shell commands, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "verify-deployment" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Step 1: Read DEPLOYMENTDOCS/DEPLOYEDENV.md / Step 2: HTTP health checks for all services / Step 3: agent-browser visual check of frontend
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, run shell commands, write/modify files | may access external network resources
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} verify-deployment
Confirms all deployed services are live, reachable, and communicating correctly. Produces a pass/fail summary table and a frontend screenshot.
Step 1: Read DEPLOYMENT_DOCS/DEPLOYED_ENV.md
Extract: FRONTEND_URL, BACKEND_URL, and any other service URLs.
If the file doesn't exist:
"No DEPLOYED_ENV.md found. Please provide your deployed service URLs manually, or run deploy-project first."
Load the values into shell variables for use in the checks below.
Step 2: HTTP health checks for all services
check_url() {
local name=$1 url=$2 max_retries=${3:-1}
for i in $(seq 1 $max_retries); do
STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 30 "$url" 2>/dev/null || echo "000")
if [ "$STATUS" -ge 200 ] && [ "$STATUS" -lt 400 ]; then
echo "✓ $name → HTTP $STATUS"
return 0
fi
if [ $i -lt $max_retries ]; then
echo " $name: HTTP $STATUS, retrying in 30s (attempt $i/$max_retries)..."
sleep 30
fi
done
echo "✗ $name → HTTP $STATUS (FAILED)"
return 1
}
# Frontend (2 attempts — no cold start)
check_url "Frontend" "$FRONTEND_URL" 2
# Backend health endpoint (3 attempts — Render free tier cold start ~30s)
check_url "Backend /health" "$BACKEND_URL/health" 3
Track whether each check passed or failed for the summary table in Step 5.
Step 3: agent-browser visual check of frontend
agent-browser open "$FRONTEND_URL"
agent-browser wait --load networkidle
agent-browser screenshot DEPLOYMENT_DOCS/verify-frontend.png
agent-browser snapshot -i
After getting the snapshot, inspect the HTML for error indicators:
- If snapshot contains any of:
"Error","404","Cannot GET","Application error","Something went wrong"→ mark frontend visual check as FAILED - If snapshot shows normal UI elements (nav, content, buttons, forms) → mark as PASSED
agent-browser close
Step 4: Cross-service connectivity test
# Test backend API health endpoint that also checks DB connectivity
API_RESPONSE=$(curl -s --max-time 30 "$BACKEND_URL/api/health" 2>/dev/null)
if echo "$API_RESPONSE" | python3 -c "import sys,json; d=json.load(sys.stdin); assert d.get('status') in ['ok','healthy','up'], f'unexpected: {d}'" 2>/dev/null; then
echo "✓ Backend API responding correctly"
else
echo "ℹ Backend /api/health returned: $API_RESPONSE"
echo " (This is OK if your backend doesn't have a /api/health endpoint)"
fi
# Test DB connectivity via backend (if backend exposes it)
DB_RESPONSE=$(curl -s --max-time 30 "$BACKEND_URL/api/health/db" 2>/dev/null)
if [ -n "$DB_RESPONSE" ]; then
if echo "$DB_RESPONSE" | python3 -c "import sys,json; d=json.load(sys.stdin); assert d.get('db') in ['connected','ok','healthy']" 2>/dev/null; then
echo "✓ Database connection verified via backend"
else
echo "ℹ DB health response: $DB_RESPONSE"
fi
else
echo "ℹ No /api/health/db endpoint — skipping DB connectivity check"
fi
Step 5: Print summary table
=== Deployment Verification Summary ===
Service Status URL
─────────────────────────────────────
Frontend ✓ PASS <FRONTEND_URL>
Backend ✓ PASS <BACKEND_URL>
Backend API ✓ PASS /api/health
Database ✓ PASS via backend
Screenshot saved: DEPLOYMENT_DOCS/verify-frontend.png
═══════════════════════════════════════
Fill in actual URLs and actual pass/fail results from Steps 2–4. Use ✗ FAIL for any check that did not pass.
Step 6: On failure
If any check FAILS:
- Print clearly:
"VERIFICATION FAILED: [service name] is not responding" - Suggest a specific fix based on which service failed:
- Frontend fails: "Check Vercel/Netlify dashboard for build errors"
- Backend fails: "Check Render dashboard for deploy status — free tier may still be cold-starting (up to 30s)"
- DB fails: "Check Supabase/Neon dashboard — project may have paused"
- Ask the user:
"Would you like me to re-run verification after you've checked? (yes/no)" - Do NOT claim the deployment is successful if any check fails.
Source: AayushMS/deploy-skills — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review