mirror of
https://github.com/qwibitai/nanoclaw.git
synced 2026-06-04 10:14:47 +08:00
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>
This commit is contained in:
Gabi Simons
@@ -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
|
||||
|
||||
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
|
||||
## Phase 5: 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
|
||||
|
||||
@@ -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
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user