# Frontend Mix Deploy

> Deploy a validated build per SECTION C of a planning document. Reasoning-light most of the time but needs judgment when the dry-run output looks off - a strong reasoning model is the safe choice (switch with /model). Skill is generic - it does whatever SECTION C says (Vercel, Fly, Railway, clerk deploy, local-only). Refuses to deploy unless validation is confirmed clean.

- Skill: `danielscholl/frontend-mix-deploy` (Agent Skill)
- Install (CLI): `npx skillmds@latest add danielscholl/frontend-mix-deploy`
- Raw SKILL.md: https://api.skillmd.com/api/skills/danielscholl/frontend-mix-deploy/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: danielscholl (https://skillmd.com/u/danielscholl)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/danielscholl/frontend-mix-deploy

---


# Frontend-Mix · Deploy

You are the **deploy** step of a manual mixed-provider build. Mostly reasoning-light, but keep a strong reasoning model selected (`/model`) so you can read a dry-run diff with judgment when it looks off.

## What to do

1. Read the plan markdown (first path the user gave you) with the `view` tool. Extract everything under `## SECTION C - Deployment Plan`. Ignore SECTION A and SECTION B.

2. Read the validation status file (second path) with the `view` tool. It's either:
   - `<run-name>-validation-summary.md` (clean run, came straight from validate) → proceed.
   - `<run-name>-resolution-summary.md` (after fix-validation) → check the final status line. If it ends with "NOT READY: <reason>", **do not deploy.** Write a deploy-summary noting the blocker and exit cleanly.

3. The plan filename carries your run-name. Strip the directory and the `-plan.md` suffix. You'll use it to name your output file.

4. If either path is missing or doesn't resolve, ask the user for the missing path. Do not deploy a build you cannot confirm is clean.

## What SECTION C might say

- **Local only** - no deploy. Write a deploy-summary noting why and exit cleanly.
- **A platform CLI** - `vercel deploy --prod`, `flyctl deploy`, `railway up`, `wrangler deploy`, etc.
- **An auth provider's deploy step** - e.g. `clerk deploy` (once it ships publicly) to take a Clerk instance from dev to prod.
- **Custom commands** the plan describes.

## Your job

1. Identify the deploy target and pre-deploy steps from SECTION C.
2. Run pre-deploy steps in order (env var promotion, migrations, etc.).
3. **Dry-run first wherever the tool supports it** (`vercel deploy --prebuilt`, `clerk deploy --dry-run`, `flyctl deploy --dry-run`). Show the diff or planned changes.
4. If the dry-run looks correct, run the real deploy.
5. Run the post-deploy verification SECTION C describes (curl a health endpoint, hit the deployed URL, check the auth flow end-to-end).

## Output

Write to `.agents/artifacts/<run-name>-deploy-summary.md`. Create the `.agents/artifacts/` directory if it doesn't exist.

Contents:
- Target (vercel / fly / local / etc.)
- Every command run, with output
- Dry-run diff (if any)
- Deployed URL (if any)
- Verification results
- Rollback instructions if something looks off

If SECTION C said local-only or validation was NOT READY, the file is one or two lines explaining why no deploy happened.

## After deploying

Confirm the absolute path to `<run-name>-deploy-summary.md` and surface any post-deploy follow-ups (DNS, custom domain config, monitoring) that the plan flagged.