How do I install the Frontend Mix Deploy skill?

Run npx skillmds@latest add danielscholl/frontend-mix-deploy in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Frontend Mix Deploy safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Frontend Mix Deploy?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Frontend Mix Deploy free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Frontend Mix Deploy?

danielscholl (@danielscholl) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Frontend Mix Deploy by danielscholl

Name: Frontend Mix Deploy
Author: danielscholl

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.

danielscholl Updated Sep 17, 2026

File contents

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

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.
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: ", do not deploy. Write a deploy-summary noting the blocker and exit cleanly.
The plan filename carries your run-name. Strip the directory and the -plan.md suffix. You'll use it to name your output file.
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

Identify the deploy target and pre-deploy steps from SECTION C.
Run pre-deploy steps in order (env var promotion, migrations, etc.).
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.
If the dry-run looks correct, run the real deploy.
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.

---name: frontend-mix-deploydescription: 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.---# Frontend-Mix · DeployYou 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 do1. 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 job1. 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).## OutputWrite 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 offIf SECTION C said local-only or validation was NOT READY, the file is one or two lines explaining why no deploy happened.## After deployingConfirm 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.

Frequently asked questions