From forge
Post-deploy verification for web apps. Checks URL stability (redirect loops), console errors, CORS preflight validation, and HTTP health. Use this skill AFTER deploying a web app — trigger on "verify deploy", "check deploy", "smoke test", "is the site working", or when a deploy task just completed and verification is needed. This skill is meant to be called optionally after deployments, not automatically on every task.
npx claudepluginhub ekelhaft-tools/forge-cursorThis skill uses the workspace's default tool permissions.
This skill verifies that a deployed web application actually works in production. It catches the class of bugs that pass all tests but break in the real environment — redirect loops, missing CORS headers, empty env vars baked into bundles, stale assets.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
This skill verifies that a deployed web application actually works in production. It catches the class of bugs that pass all tests but break in the real environment — redirect loops, missing CORS headers, empty env vars baked into bundles, stale assets.
Call this skill after deploying a web app when you want to verify it works. It's optional — not every deploy needs a full smoke test, but it's invaluable when:
Run these checks in order. Stop at the first hard failure and report it.
curl -sI <deployed-url> | head -20
Expect HTTP 200. If you get 404, 502, or 503, the deploy itself failed — no point checking further.
Using Chrome MCP:
If the URL keeps changing (especially with ?code=, ?state=, or auth-related params cycling), that's a redirect loop. Report the pattern you see.
Common causes:
isAuthenticating state not set synchronously before first renderUsing Chrome MCP read_console_messages:
onlyErrors: trueReport any errors. Common production issues:
TypeError: Cannot read properties of undefined — missing env varFailed to fetch — CORS or network issuesentry-trace related — Sentry distributed tracing headers not allowed by CORSFor each known cross-origin endpoint pair, send an OPTIONS preflight and validate the response headers.
# Template for each endpoint
curl -sI -X OPTIONS <backend-url> \
-H "Origin: <frontend-origin>" \
-H "Access-Control-Request-Method: POST" \
-H "Access-Control-Request-Headers: authorization,content-type,sentry-trace,baggage" \
| grep -i "access-control"
Check that the response includes:
Access-Control-Allow-Origin matching the frontend origin (or *)Access-Control-Allow-Headers including ALL requested headers (especially sentry-trace and baggage if Sentry is integrated)Access-Control-Allow-Methods including the required methodIf any header is missing, the browser will silently block the request after the preflight — this is the sneakiest class of deploy bugs because there are often no visible errors.
After page load, check network requests:
If the app seems broken but no errors are visible, check what's actually in the deployed bundle:
ssh <server> "strings <deploy-path>/assets/index-*.js | grep -i '<expected-env-value>'"
This catches the "empty VITE_* env var" bug — the app builds fine but the runtime URLs are empty.
For projects with known cross-origin dependencies, maintain an endpoint registry. For the ekelhaft ecosystem:
| Frontend | Backend | Endpoint | Required Headers |
|---|---|---|---|
| buschfunk.edge.ekelhaft.tools | auth.edge.ekelhaft.tools | /token | authorization, content-type, sentry-trace, baggage |
| buschfunk.edge.ekelhaft.tools | scraper.edge.ekelhaft.tools | /api/* | authorization, content-type, sentry-trace, baggage |
When adding new cross-origin dependencies, update this table.
After all checks, produce a summary:
Deploy Verification: <URL>
========================
HTTP Health: PASS (200)
URL Stability: PASS (stable after 8s)
Console Errors: PASS (0 errors, 3 info messages)
CORS Preflights: PASS (2/2 endpoints valid)
Network: PASS (all API calls successful)
Result: ALL CHECKS PASSED
Or on failure:
Deploy Verification: <URL>
========================
HTTP Health: PASS (200)
URL Stability: FAIL - URL cycling with ?code= params (redirect loop)
Console Errors: SKIPPED (page unresponsive)
CORS Preflights: SKIPPED
Network: SKIPPED
Result: FAILED - Redirect loop detected
Likely cause: OAuth callback not consuming auth code before re-triggering login
If a Linear issue ID is available, post the result as a comment on the issue.
This skill is designed to be called optionally after Forge deploy tasks. When a Forge task includes a deploy step, the orchestrator can invoke this skill to verify the deploy worked. It's not mandatory — use it when the deploy involves auth flows, cross-origin calls, or infrastructure changes where silent failures are likely.