Purpose

Take a local codebase or static site and publish it to a production URL with minimal DevOps friction.

Primary outcomes:

• repository created and synced,
• deployment triggered,
• live URL verified,
• custom-domain path documented when requested.

Required Installed Skills

Core:

• github-api (inspected latest: 1.0.3)
• One deploy path:
• vercel (inspected latest: 1.0.1), or
• netlify (inspected latest: 1.0.0)

• domain-dns-ops (inspected latest: 1.0.0, environment-specific)
• api-gateway (inspected latest: 1.0.29)

npx -y clawhub@latest install github-api
npx -y clawhub@latest install vercel
npx -y clawhub@latest install netlify
npx -y clawhub@latest install domain-dns-ops
npx -y clawhub@latest install api-gateway
npx -y clawhub@latest update --all

Verify:

npx -y clawhub@latest list

Important name mapping:

• If user says /netlifly, map it to /netlify.

Required Credentials

Mandatory:

• MATON_API_KEY (required for github-api, and for api-gateway routes)

• Vercel path: logged in vercel login or VERCEL_TOKEN
• Netlify path: logged in netlify login or NETLIFY_AUTH_TOKEN

• active app-specific OAuth connection in Maton control plane (ctrl.maton.ai)

echo "$MATON_API_KEY" | wc -c
echo "$VERCEL_TOKEN$NETLIFY_AUTH_TOKEN" | wc -c

Mandatory behavior:

• Never fail silently on missing keys/tokens.
• Always return MissingAPIKeys (or missing auth) with blocked stages.
• Continue with non-blocked stages and mark output as Partial when needed.

Inputs the LM Must Collect First

• project_path
• repo_name
• repo_visibility (private or public)
• deploy_target (vercel or netlify)
• framework_hint (optional)
• custom_domain (optional)
• domain_provider (optional; Cloudflare/Namecheap/etc.)
• infra_mode (frontend-static, fullstack-managed, vps-server)

Tool Responsibilities

github-api

Use for repository bootstrap and remote sync setup:

• create repository (user/org),
• configure visibility,
• store remote URL metadata for subsequent push/deploy linkage.

• requires MATON_API_KEY
• uses Maton-managed OAuth connections
• missing/invalid key leads to auth errors

vercel

Use for managed frontend/fullstack deploy path:

• link project,
• trigger deploy (vercel / vercel --prod),
• inspect deployment and domain status,
• manage domain attachments when needed.

netlify

Use as alternative managed deploy path:

• site create/link/init,
• CI/CD setup from GitHub,
• manual or prod deploy,
• environment variable and domain/dns capabilities.

domain-dns-ops

Use only when environment matches its assumptions.

Important limitation from inspected skill:

• this skill is documented as environment-specific ("for Peter", source of truth in ~/Projects/manager).
• if that source context does not exist, do not assume it is portable.

api-gateway

Use for optional infra/API-managed operations when connected apps exist.

Operational constraints from inspected skill:

• requires MATON_API_KEY
• requires active app-specific connection per target service
• 400 indicates missing app connection
• 401 indicates missing/invalid Maton key

• inspected list clearly includes Netlify and many SaaS apps.
• DigitalOcean/AWS are not explicitly listed as native app names in the inspected api-gateway skill index.
• treat VPS/server provisioning via gateway as conditional, not guaranteed.

Canonical Causal Signal Chain

• Code Audit
• scan project root for framework markers:
• package.json, next.config., vite.config., index.html, dist/, build/
• classify project type (Next.js, Vite, static HTML, other)
• determine default build and publish path
• Git Inception
• initialize git if needed,
• create remote repository via github-api,
• set origin, commit, and push branch.
• Infrastructure Gate
• present hosting recommendation based on project type:
• Vercel/Netlify for frontend-managed deploy,
• custom infra path only if supported connections exist.

• InfraGateStatus: available or blocked
• Reason: missing auth / missing connection / unsupported provider
• Action: exact next step

• provide neutral official onboarding links only.
• Deployment Trigger
• Vercel path: run vercel link (if needed), then deploy (vercel --prod).
• Netlify path: create/link/init and deploy (netlify deploy --prod).
• Status Monitoring
• poll deploy status/logs until final state:
• Ready/success -> proceed,
• failure -> return build error summary + remediation actions.
• Domain Wiring
• if custom domain requested:
• attach domain in provider (Vercel/Netlify),
• output required DNS records,
• verify DNS propagation and HTTPS readiness.
• Output
• return live URL,
• return domain instructions,
• return CI/CD update path (future pushes redeploy automatically).

Output Contract

Always return:

• ProjectDetection
• detected framework
• build/publish assumptions
• RepoStatus
• repository URL
• default branch
• push status
• InfraGateStatus
• provider selected
• gate status
• blockers and actions
• DeploymentStatus
• live URL
• deploy ID/reference
• final state (ready or failed)
• CustomDomainPlan
• required DNS records
• where to set them
• verification checklist
• NextActions
• exact command/portal steps if anything remains manual

Quality Gates

Before final output, verify:

• framework detection based on actual files (not guesswork)
• remote repo exists and push path is valid
• deployment URL resolves and status is successful
• custom domain records are explicit and provider-correct
• all missing credentials/connections are disclosed

Failure Handling

• Missing MATON_API_KEY: return MissingAPIKeys, skip github-api/api-gateway stages.
• Missing Vercel/Netlify auth: return missing auth state and provide exact login/token setup steps.
• Git push rejected: keep deployment blocked, return upstream remote/auth error and retry commands.
• Deploy build failed: return build log summary and required fixes.
• Missing domain control: return live platform URL and park custom-domain steps as pending.
• Unsupported VPS provider path in gateway: disclose limitation and provide managed-hosting fallback.

Guardrails

• Never claim deployment success without a reachable URL.
• Never claim custom domain is active before DNS + HTTPS checks pass.
• Never hide provider limitations or auth blockers.
• Keep recommendations bounded to inspected, available integrations.