Site by reference: /goal orchestrator

Claude Code will build a site from a reference — and then get stuck at "well, close enough" and proudly announce "done". The /goal command turns it into an orchestrator that keeps checking itself with screenshots until it actually matches 🔥

The agent's default is to stop early. You ask for "like the reference", you get "roughly in that direction": sections moved around, wrong font, spacing all over the place. /goal sets a completion condition — and after every turn a separate model checks whether it has been met; the agent will not quit until it converges (or until you run /goal clear).

When to use it

You have a sample site (a reference) and you need something that feels the same but is built for your product and your audience. You are the director; the building, the self-checking and the fitting are run by the agent in a "coded it → screenshot → compared → fixed" loop. Good when visual accuracy matters, not when you just want "sketch me a landing page".

The result: a page built around your offer and fitted to the reference element by element, with a checklist report — instead of "looks about right" after the first pass.

The prompt (grab and paste)

/goal Build a site for my product that is visually indistinguishable from the reference <REFERENCE: URL or screenshots of the sample>, but with my content — not a copy.

PRODUCT: <what we sell/do, the offer, key sections>.
AUDIENCE: <who the customer is, language, tone>.
STACK: <HTML+Tailwind / Next.js / my template>.
TAKE SCREENSHOTS via <TOOL: Playwright MCP / Chrome MCP / computer-use>.

Act as the orchestrator and see it through:
1. Break the reference down: grid, section order, typography, colors, spacing, button states, animations. Draft a detailed checklist plan by section.
2. Code section by section using MY content (copy, logo, images are mine; adapt the meaning of the reference, do not copy its content).
3. After each section take a screenshot of the built page and compare it with the reference element by element; log the discrepancies and fix them.
4. Run it at widths <360 / 768 / 1440>. Make sure the build and the linter pass without errors.

DONE (close it with proof, not by eye):
- a screenshot of every section has been taken and attached;
- EVERY checklist item is closed: section order, fonts, colors, spacing, responsiveness;
- <measurable: `npm run build` exits with code 0; no horizontal scroll at 360px>.
As long as a single item is unproven — keep going. Saying "done" without proof is forbidden.
At the end give a checklist report: what matched, what could not be fitted and why.

A filled-in example

REFERENCE: 3 screenshots of a modern SaaS landing page (hero, features block, pricing). PRODUCT: an online booking service for nail technicians, offer: "bookings without DM back-and-forth". AUDIENCE: self-employed technicians, RU, warm simple tone. STACK: HTML+Tailwind. Screenshots via Playwright MCP.

What the agent should do: break the reference into a checklist (hero with the offer and a CTA → 3 feature cards → pricing → FAQ → footer), code the hero, take a screenshot, notice that the button is lighter and the headline smaller than in the reference — fix it, screenshot again. Same for every section; run at 360/768/1440, catch horizontal scroll on mobile, fix it; at the end hand over the checklist report and honestly say that the gradient animation could not be matched one to one.

Variations

• Browser only (no access to the code). Let the agent "see" the page through a browser or computer-use tool and fix things in a live preview — the technique is the same, the screenshot comparison is still the gate.
• One screen at a time, with approval. "First the hero 1:1, show me the screenshot, wait for an OK — then the next one." Less drift over a long loop.
• Not a site, a block. The same loop for a single component, dashboard or email — "fit this block to the reference".
• Tokens first, then markup. As a first step pull the palette, fonts and spacing scale out of the reference into design tokens and build against them — more accurate than eyeballing the fit. For the initial site generation see the card about MotionSites, then catch up with this prompt.

Pro tips

• Give a measurable criterion, otherwise it is ADVISORY. The /goal judge is a separate model (Haiku by default) that reads the transcript and decides "goal achieved?". Important (per the official docs): the judge does not run commands or read files itself — it trusts what the agent has already printed into the conversation, so the agent has to present the proof. Asked whether it "looks identical", it will answer on a vibe read of the screenshot, not an objective diff. If you want something closer to real drive-to-done (see the "10/10 gate"), bake executable proof into DONE: npm run build = 0, the presence of specific elements, or better a pixel diff between the reference and the screenshot. Without executed proof the criterion is not closed.
• Do not clone someone else's brand 1:1. Copying the reference's logo, copy or signature illustrations is a legal risk. Match the structure and the feel, fill it with your own content.
• The screenshot is the agent's eyes. Without Playwright/Chrome MCP or computer-use it "compares" by code, not by picture, and will happily decide it is done. Wire up a screenshot tool and require the screenshots to be attached.
• Goal as an outcome, plus boundaries and a limit. As in the "Brief for an AI agent" card: say what must not be touched and set a ceiling on iterations — a long autonomous /goal loop burns tokens and limits and can bury itself in one section.
• Give the reference as screenshots of specific screens, not as "make it pretty like theirs": the model fits what it can see next to the result far more accurately.
• What it honestly costs and what it needs: /goal is a standard free Claude Code command (per the official docs, from version v2.1.139); you do not pay extra for it. But: you need Claude Code itself and a screenshot tool; the command only works in a trusted workspace and is built on the hooks system — with hooks disabled (disableAllHooks / allowManagedHooksOnly) it is unavailable; a long autonomous loop eats into your limits and tokens.