Deployment inspection
End-to-end investigation of a live client deployment — platform detection, subdomain discovery, deployment API access (Netlify), JS bundle analysis, repo discovery.From its SKILL.md
npx -y skills add S3YED/appie-kit --skill deployment-inspectionAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
7.2 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it
Deployment Inspection
When to Use
Load this skill when the user says:
- "Vind het project [domain]" / "Open de site"
- "Check de deploy" / "Kijk in de codebase"
- "Waar staat dit project?"
- Any request to investigate a live web project, its hosting platform, codebase, or deployment setup
Detection Flow
1. Platform Detection
Run these checks in order to identify where the site is hosted:
# Check HTTP response headers
curl -sI https://domain.com | grep -i "server\|x-powered-by\|x-served-by\|cache-status"
| Header value | Platform |
|---|---|
server: cloudflare | Behind Cloudflare — check further |
server: Netlify + Netlify Edge cache | Netlify |
server: Vercel | Vercel |
x-powered-by: Express | Custom Node.js server |
x-served-by: Webflow or scripts from cdn.prod.website-files.com | Webflow |
Webflow confirmation — check script sources in the HTML for cdn.prod.website-files.com:
curl -s https://domain.com | grep -o 'src="[^"]*"' | grep -i 'website-files'
2. Subdomain Discovery
When the user says the app is at a subdomain that doesn't resolve:
# Check DNS first
dig booking.domain.com +short
dig book.domain.com +short
dig app.domain.com +short
# Check nameservers for hosting clues
dig domain.com NS +short
# Check local screenshot tool configs for the real URL
grep -r 'domain.com\|domain' ~/clawd/projects/*/screenshot-tool.js 2>/dev/null
grep -r 'domain.com\|domain' ~/clawd/tools/*.js 2>/dev/null
Known pattern: The screenshot-tool.js in Weblyfe projects often has the correct subdomain URLs for client sites. Always check there first when a subdomain doesn't resolve.
3. Netlify API Access
When the site is confirmed on Netlify:
# Token location
source ~/.weblyfe-secrets/.env # exports NETLIFY_AUTH_TOKEN
# List sites and search by name
curl -s -H "Authorization: Bearer $NETLIFY_AUTH_TOKEN" \
"https://api.netlify.com/api/v1/sites?page=1&per_page=100" | \
python3 -c "import sys,json; sites=json.load(sys.stdin); [print(f\"{s.get('name')} | {s.get('custom_domain','-')} | {s.get('ssl_url','-')}\") for s in sites]"
# Get full site info
curl -s -H "Authorization: Bearer $NETLIFY_AUTH_TOKEN" \
"https://api.netlify.com/api/v1/sites/{site_id}"
# Check deploys (latest 5)
curl -s -H "Authorization: Bearer $NETLIFY_AUTH_TOKEN" \
"https://api.netlify.com/api/v1/sites/{site_id}/deploys?page=1&per_page=5"
# Check environment variables
curl -s -H "Authorization: Bearer $NETLIFY_AUTH_TOKEN" \
"https://api.netlify.com/api/v1/sites/{site_id}/env"
Key fields from site info:
name— Netlify site namecustom_domain— custom domain (e.g. book.titantransfers.be)state—current= livebuild_settings.repo_url— GitHub repobuild_settings.repo_branch— deploy branchbuild_settings.cmd— build commandbuild_settings.dir— publish directorycreated_at— when it was deployed
Deploy fields:
state—ready= success,error= build failedpublished—true= currently servedcreated_at— deploy timecommit_ref— commit SHAcommit_url— link to GitHub commitdeploy_time— secondserror_message— build error details
4. GitHub Repo Discovery
The Netlify build settings include repo_url (e.g. https://github.com/S3YED/titan-transfers-2).
To access the repo:
# Try gh CLI first
gh repo view owner/repo --json name,description,defaultBranch,updatedAt,languages
# Fallback: GitHub API with token from .env
source ~/.weblyfe-secrets/.env
curl -s -H "Authorization: token $GITHUB_TOKEN" \
"https://api.github.com/repos/owner/repo"
# Check latest commit on branch
curl -s -H "Authorization: token $GITHUB_TOKEN" \
"https://api.github.com/repos/owner/repo/branches/main"
Pitfall: GitHub tokens expire. Check the token before relying on it:
source ~/.weblyfe-secrets/.env
curl -s -w "\nHTTP: %{http_code}" -H "Authorization: token $GITHUB_TOKEN" \
"https://api.github.com/user"
# 401 = expired/revoked token
5. JS Bundle Analysis (SPA Inspection)
When you need to understand what a production SPA does internally:
# Find the JS bundle from the HTML
curl -s https://app.domain.com | grep -o 'src="[^"]*\.js[^"]*"'
# Download and analyze
curl -s https://app.domain.com/assets/index-hash.js > /tmp/bundle.js
# Check for framework clues
head -1 /tmp/bundle.js | grep -o 'react|vue|svelte|angular|preact'
# Search for key features
grep -c 'admin\|dashboard' /tmp/bundle.js
grep -c 'supabase\|firebase\|auth0\|clerk' /tmp/bundle.js
grep -c 'stripe\|payment\|checkout' /tmp/bundle.js
# Extract admin routes (Supabase pattern)
grep -oP '/admin/[a-z_/]+' /tmp/bundle.js | sort -u
# Check Vite/Vue/React indicator
curl -s https://app.domain.com | grep -i 'vite\.svg\|_nuxt\|__NEXT_DATA__\|__NUXT__'
Admin dashboard patterns: Supabase admin routes commonly include:
/admin/generate_link— invite links/admin/users— user management/admin/users/{id}/factors— auth factors
Framework indicators:
vite.svgfavicon = Vite-based (React/Svelte/Vue)__NEXT_DATA__script = Next.js_nuxt/in script paths = Nuxt.js/assets/index-{hash}.js= Vite default
6. Live App Navigation
For SPA booking apps and multi-step forms:
- Check the console for the actual route/state after interacting
- Try common protected routes:
/admin,/dashboard,/login,/api - Check footer for platform attribution ("App created by Weblyfe", "Powered by...")
- Identify the auth provider (Supabase, Firebase, Auth0) from JS bundle
Pitfalls
- Subdomain confusion — User says "booking." but the actual URL is "book." (or "app.", "portal."). Always check DNS + screenshot configs before reporting failure.
- Published deploy confusion — Netlify recent deploys can show
published: nulleven when the site is live. An older deploy may be published. - Empty SPA routes — Protected routes like
/adminshow an empty page shell when not authenticated. This doesn't mean the admin panel doesn't exist — check the JS bundle for route patterns. - GitHub token expiry — GH tokens in
.weblyfe-secrets/.envmay be expired. Check before relying on them. The Netlify token is more stable. - JS bundle size — Production bundles can be 500KB+. For large bundles, use streamed extraction instead of loading the full file:
curl -s https://domain.com/assets/bundle.js | grep -oP '.{0,100}admin.{0,100}' | head -5
Related
web-research— for general web research and SEO content extractionwebflow-seo-audit— for Webflow-specific site auditssecurity-scanning— for security header and CVE checks on deployed sitesgithub-repo-management— for working with discovered repos
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.