refactor(add-vercel): drop Frontend Engineer delegation, add pre-deploy checks

The specialist-subagent pattern forced every /add-vercel user through the
OneCLI credential-assignment plumbing (dynamically created Frontend Engineer
agents had no Vercel secret on first deploy). For a personal assistant the
isolation wasn't worth the complexity — the host agent can deploy to Vercel
directly using the same CLI.

- Remove the Phase 5 CLAUDE.md patch that forbade writing frontend code
- Drop the bundled frontend-engineer container skill
- Strip the HARD RULE + "Building Websites" delegation from vercel-cli
- Add a concise "Pre-Send Checks" section: local build, deployment READY,
  live URL returns 2xx, optional agent-browser visual check

Net: -194 lines. /add-vercel now installs the CLI, registers the secret,
assigns it to existing agents, and teaches the agent to verify before
sharing the URL. No subagent plumbing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.claude/skills/add-vercel/SKILL.md

@@ -115,25 +115,7 @@ If `MISSING`, add `vercel` to the global npm install line in `container/Dockerfi
 
 If `PRESENT`, skip — no rebuild needed.
 
-## Phase 5: Patch Agent CLAUDE.md Files
+## Phase 5: Sync Skills to Running Agent Groups
-
-Append the frontend delegation rule to every existing agent group's CLAUDE.md. This ensures the agent treats delegation as a hard rule, not a suggestion.
-
-```bash
-for claudemd in groups/*/CLAUDE.md; do
-  if ! grep -q "Frontend Delegation" "$claudemd" 2>/dev/null; then
-    cat >> "$claudemd" << 'PATCH'
-
-## Frontend Delegation (Vercel)
-
-You MUST NOT write HTML, CSS, or JavaScript yourself. When asked to build a website or web app, delegate to a Frontend Engineer subagent using create_agent then send_message. Both calls are required before telling the user anything is happening.
-PATCH
-    echo "Patched: $claudemd"
-  fi
-done
-```
-
-## Phase 6: Sync Skills to Running Agent Groups
 
 Container skills are copied once at group creation and not auto-synced. After installing or updating a container skill, sync it to all existing agent groups:
 
@@ -146,9 +128,9 @@ for session_dir in data/v2-sessions/ag-*; do
 done
 ```
 
-## Phase 7: Restart Running Containers
+## Phase 6: Restart Running Containers
 
-Stop all running agent containers so they pick up the new skills and CLAUDE.md changes:
+Stop all running agent containers so they pick up the new skills on next wake:
 
 ```bash
 docker ps --format "{{.ID}} {{.Names}}" | grep nanoclaw-v2 | awk '{print $1}' | xargs -r docker stop

.claude/skills/add-vercel/container-skills/frontend-engineer/SKILL.md

@@ -1,157 +0,0 @@
----
-name: frontend-engineer
-description: Pro frontend engineering discipline. Enforces build-test-verify workflow for every web project. Never declare done until the site is built, tested, responsive, accessible, and visually verified in a real browser. Use alongside vercel-cli for production-quality deployments.
----
-
-# Frontend Engineer
-
-You are a senior frontend engineer. You build production-quality websites and web applications. You do not cut corners. You do not declare work done until everything is tested and working.
-
-## Core Rule
-
-**Never say "done" until you have visually verified the result in a real browser.** Screenshots are your proof. If you can't take a screenshot, you're not done.
-
-## Build Workflow
-
-Every frontend task follows this sequence. Do not skip steps.
-
-### 1. Understand Before Coding
-
-- For existing projects: read `package.json`, check existing patterns, components, and design tokens before changing anything
-- For new projects: pick the right tool (Next.js for full apps, Vite for SPAs, plain HTML/CSS for simple pages)
-- **Search the codebase before creating any new component.** If an existing component does 80% of what you need, extend it with props. If two components share the same pattern, extract a shared component.
-
-### 2. Write Quality Code
-
-**TypeScript:**
-- Use TypeScript for all code
-- Avoid `any` — prefer `unknown` with type guards. If `any` is genuinely the simplest correct approach (e.g. third-party lib interop), use it sparingly
-- Annotate return types; explicit interfaces for all props and API responses
-
-**React / Next.js (when using App Router):**
-- Server Components by default — minimize `use client`, `useEffect`, `setState`
-- Never define components inside other components (causes remounts, lost focus, broken state)
-- Use `Suspense` with fallback for client components
-- Dynamic import for non-critical components: `const Heavy = dynamic(() => import('./Heavy'))`
-- Wrap only small leaf components with `use client`, not entire page trees
-- Use `Promise.all()` for independent async operations — never create waterfalls
-
-**Imports / Bundle Size:**
-- Import directly from source files, never from barrel/index files (saves 200-800ms per import)
-- Use `optimizePackageImports` in next.config for icon/UI libraries (lucide-react, @mui/material, etc.)
-- Defer third-party scripts; lazy load below-the-fold content
-
-**HTML:**
-- Semantic tags: `<header>`, `<nav>`, `<main>`, `<section>`, `<footer>` — not div soup
-- Every `<img>` gets an `alt` attribute; use Next.js `Image` component for optimization
-- One `<h1>` per page, then `<h2>`, `<h3>` in order
-- Every page gets `<title>` and `<meta name="description">`
-
-**CSS / Styling:**
-- Mobile-first responsive design by default
-- Use design system tokens or Tailwind classes when a design system exists. For standalone projects, establish consistent values early and reuse them
-- Prefer the design scale over arbitrary values — but if the design genuinely calls for a specific value, use it
-- Consistent spacing across similar elements (don't mix p-3, p-4, p-5 on the same content type)
-- Smooth transitions on interactive elements (200-300ms, use transform/opacity for GPU acceleration)
-- Aim for 4.5:1 contrast ratio for text (WCAG AA)
-
-**Consistency:**
-- Similar pages must follow the same layout pattern
-- Loading states are consistent everywhere (don't mix spinners, skeletons, and shimmer)
-- Error states follow one pattern across the app
-- Empty states look the same everywhere
-
-### 3. Build Before Deploying
-
-Run the build and fix ALL errors:
-
-```bash
-npm run build 2>&1
-```
-
-If it fails, **fix it**. Do not deploy broken builds. Do not disable ESLint rules or TypeScript checks to make it pass.
-
-### 4. Visual Verification (MANDATORY)
-
-Start the dev server and test in a real browser:
-
-```bash
-npm run dev &
-DEV_PID=$!
-sleep 3
-```
-
-Then use `agent-browser` to verify:
-
-```bash
-# Desktop (1280px)
-agent-browser open http://localhost:3000
-agent-browser screenshot desktop.png
-
-# Tablet (768px)
-agent-browser eval "window.resizeTo(768, 1024)"
-agent-browser screenshot tablet.png
-```
-
-**Always verify:**
-
-- [ ] Page loads without errors
-- [ ] Console has no errors: `agent-browser eval "JSON.stringify(window.__errors || [])"`
-- [ ] No horizontal scrollbars or layout overflow
-
-**Verify when relevant to the change:**
-
-- [ ] Text is readable — correct fonts, sizes, contrast
-- [ ] Images load (no broken icons)
-- [ ] Links and navigation work
-- [ ] Tablet view (~768px) doesn't break (if touching layout)
-- [ ] Interactive elements have hover/focus states (if adding them)
-- [ ] Forms submit correctly (if applicable)
-
-### 5. Deploy
-
-Only after all checks pass:
-
-```bash
-vercel deploy --yes --prod --token placeholder --cwd /path/to/project
-```
-
-### 6. Production Verification
-
-After first deploy or major changes, verify the LIVE URL:
-
-```bash
-agent-browser open <deployed-url>
-agent-browser screenshot production.png
-```
-
-If anything looks broken compared to local, fix it and redeploy.
-
-## Iteration Protocol
-
-If something doesn't look right:
-
-1. Identify the specific issue from the screenshot
-2. Fix the code
-3. Rebuild and re-test
-4. Take a new screenshot
-5. Compare — repeat until it looks professional
-
-Keep iterating until it looks professional. If after 3 iterations the same issue persists, report it as a known limitation and move on.
-
-## Anti-Patterns — Never Do These
-
-- Building a component from scratch when a similar one exists in the codebase
-- Using different spacing across the same content type
-- Leaving `console.log` in production code
-- Importing entire libraries for one function (e.g., all of lodash for `debounce`)
-- Suppressing warnings or disabling lint rules to make builds pass
-- Defining components inside other components
-
-## Reporting
-
-When reporting results, always include:
-- What you built (tech stack, pages, features)
-- The live URL (if deployed)
-- Screenshots of the final result (desktop minimum)
-- Any known limitations or follow-up needed

.claude/skills/add-vercel/container-skills/vercel-cli/SKILL.md

@@ -41,7 +41,16 @@ After deploying, verify the live URL:
 vercel inspect <deployment-url> --token placeholder
 ```
 
-If you have `agent-browser` available, open the deployed URL and take a screenshot to visually verify.
+## Pre-Send Checks (do this before sharing the URL)
+
+Don't send the deployment URL to the user until you've confirmed it's actually working. At minimum:
+
+1. **Local build passes** — run `npm run build` (or the project's build command) before `vercel deploy`. If the build fails locally, fix it first; don't deploy broken code.
+2. **Deployment succeeded** — the `vercel deploy` output shows a "Production: https://..." URL and the status is READY (confirm with `vercel inspect`).
+3. **Live URL responds** — `curl -sI <url> | head -1` should return `HTTP/2 200` (or another 2xx/3xx). A 404/500 means something's broken even though Vercel reported success.
+4. **Optional visual check** — if `agent-browser` is loaded, open the URL and eyeball it. Helpful for catching broken layouts that a 200 response wouldn't reveal.
+
+If any check fails, fix the issue and redeploy before reporting to the user.
 
 ## Project Management
 
@@ -86,34 +95,6 @@ echo "value" | vercel env add VAR_NAME production --token placeholder
 | `ENOTFOUND api.vercel.com` | Network issue. Check proxy connectivity |
 | Auth error after `vercel whoami` | Credential may be expired. Ask the user to refresh the Vercel token in OneCLI |
 
-## Building Websites — Delegate to Frontend Engineer
-
-When asked to **build, create, or redesign** a website or web app, do NOT build it yourself. Spin up a dedicated frontend-engineer agent that has full context for the job:
-
-```
-create_agent({
-  name: "Frontend Engineer",
-  instructions: "You are a dedicated frontend engineer. Your frontend-engineer skill has your full workflow. Build what is requested, test it visually with agent-browser, deploy to Vercel, and send back the live URL + screenshots to your parent agent when done."
-})
-```
-
-Then hand off the task:
-
-```
-send_message(to: "Frontend Engineer", text: "<what to build, design requirements, any assets or content>")
-```
-
-The frontend agent will:
-1. Build the site following pro frontend standards
-2. Test visually with `agent-browser` (screenshots as proof)
-3. Deploy to Vercel using `vercel deploy --yes --prod --token placeholder`
-4. Verify the production URL in browser
-5. Send back the live URL + screenshots
-
-**When to delegate vs do it yourself:**
-- **Delegate**: building new sites, redesigns, multi-page apps, anything that needs visual testing
-- **Do yourself**: simple `vercel deploy` of an existing project, checking deployment status, managing domains/env vars
-
 ## Best Practices
 
 - Run `npm run build` locally before deploying to catch build errors early