LucasH1225/restaurant-website-skills

Restaurant Demo Builder

Build an evidence-backed sales demo that makes the owner recognize their own restaurant and makes the lost online opportunity obvious. Treat the demo as a useful first version of the restaurant's website, not as a generic theme with the restaurant's name pasted onto it.

Read references/demo-playbook.md before substantial research, design, image production, or implementation. Use only the sections relevant to the request.

Choose The Task Mode

Determine the requested mode before acting:

• Analyze: Return a sourced concept, rationale, page structure, image direction, menu plan, and verification gaps. Do not edit project files unless asked.
• Build: Research the restaurant, create or prepare appropriate assets, implement the working demo, run it, and visually verify desktop and mobile views.
• Refresh: Inspect the existing demo and current public facts, then update only what is stale or weak and re-run visual verification.

Ask for clarification only when multiple businesses share the name and the correct location cannot be inferred. Otherwise, inspect local lead data and public sources first.

Work From Evidence

1. Inspect the current workspace before browsing. Search lead exports, briefs, existing demos, and design assets for the restaurant name, location, place ID, and URLs.
2. Verify current public facts because restaurant information changes frequently. Check the restaurant's owned site and social pages, Google listing or Maps data, current menu or ordering page, recent reviews, and relevant official tourism or chamber pages.
3. Record the source and confidence for name, address, phone, hours, rating, review count, categories, services, menu items, prices, events, online ordering, social links, and any venue or exterior imagery proposed for the demo.
4. Separate content into three labels while working:
   • Verified fact: Directly supported by a current source.
   • Reasonable inference: Supported by repeated patterns in reviews or location context.
   • Creative proposal: Tagline, art direction, layout, or campaign idea created for the demo.
5. Resolve conflicting facts with the most recent owner-controlled source when possible. Put unresolved conflicts on the owner-verification list.
6. Stop research when the restaurant identity, website problem, menu availability, core contact details, primary audience evidence, and repeated review themes are sufficiently established. For analysis mode, prefer a small set of strong sources over an exhaustive directory sweep; list unresolved details instead of delaying the brief.

Never invent menu items, prices, hours, awards, discounts, delivery, reservations, ordering, event schedules, or accessibility claims. Do not add a working-looking command button unless its destination and service are real.

Define One Commercial Position

Choose one primary audience and one primary conversion objective from the evidence. Typical audiences include pass-through travelers, local families, breakfast regulars, sports-bar guests, and evening groups. Typical objectives include viewing the menu, getting directions, calling, or placing a verified online order.

The first viewport must answer within five seconds:

1. What restaurant is this?
2. Why should this visitor choose it?
3. Is it open or when is it open?
4. How can the visitor see the menu or get there?

Use the restaurant name as the H1. Put the positioning in supporting copy. Prefer concrete proof such as dayparts, signature dishes, location, hours, portions, or review themes over generic phrases such as "great food" or "fresh ingredients."

Route The Design

After the restaurant evidence, audience, occasion, and primary action are established, read references/design-routing.md. Create a restaurant profile, run scripts/select_recipe.py, and save the generated recipe-lock.json with the Demo research record.

Read only the selected Recipe reference, then copy the independently selected layout Starter from assets/layouts/<layout-id>/:

• morning-regular: references/recipe-morning-regular.md
• hometown-table: references/recipe-hometown-table.md
• local-tavern: references/recipe-local-tavern.md
• occasion-dining: references/recipe-occasion-dining.md

Use references/layout-research-2026-07-v2.md only when reviewing the structural evidence behind the V2 library, expanding layout grammars, or diagnosing a design mismatch. The earlier design-research-2026-07.md and assets/starters/ are V1 history and do not participate in new Demo routing. Do not copy a reference restaurant's code, photographs, writing, logo, illustration, or distinctive full composition.

Treat Recipe and layout selection as separate constraints. Recipe controls audience, tone, functions, and visual attitude; layout grammar controls Hero, media composition, proof form, menu geometry, section geometry, and mobile transformation. Verified restaurant evidence continues to control ordering, reservations, events, hours, services, menu content, reviews, and imagery. Never manually bypass the V2 lock: correct the profile, compatibility definition, or history fingerprint when a result is wrong.

Lock The Restaurant Brand Palette

Use $restaurant-brand-palette after the Recipe and layout lock but before final visual styling whenever a storefront, sign, logo, menu, packaging or interior image provides usable identity color evidence. Save the validated brand-palette.json and preview beside recipe-lock.json.

Treat palette, Recipe and layout as separate locks. Palette controls CSS color roles and proportions; it does not change audience, function, Hero grammar or section geometry. Require the palette skill's handoff stage before importing tokens. Map the validated tokens into CSS variables and do not introduce ad hoc replacement hex values during implementation.

If no reliable brand color survives evidence review, let the palette skill create a clearly labeled Recipe fallback. Do not claim a fallback came from the restaurant. Revalidate after any token change and inspect text over photographs separately.

Build The Page Around Decisions

Use this default sequence when the selected recipe does not specify a better evidence-backed order. Remove any section that lacks evidence:

1. Compact navigation with Menu, Favorites, and Visit, plus a high-value command.
2. Full-bleed hero with the restaurant name, one concrete value proposition, View Menu, and Get Directions or Call.
3. Proof strip with verified rating/review count, hours, price signal, or downtown/location context.
4. Three to six featured dishes using confirmed names when available; use a text-led category or representative label when a dish lacks a verified real photo rather than inventing realistic food imagery.
5. A readable HTML menu with category navigation.
6. Experience or daypart section only when it clarifies the business, such as breakfast-to-late-night, family dining, sports, or live events.
7. Short, sourced review proof that supports the chosen positioning.
8. An arrival or exterior band when a verified storefront photo materially improves recognition or wayfinding.
9. Visit section with address, current hours, phone, map/directions, and owned social links.
10. Mobile sticky actions for the most important commands.

Keep the experience direct and useful. Avoid a decorative card for every section, fake reservation forms, generic chef stories, unsupported "best in town" claims, and long marketing copy.

Create A Consistent Image System

Use $restaurant-food-image-studio for actual food-reference auditing, image generation, repair, manifest tracking, and source-versus-proposal contact sheets. In a complete Demo build, establish the restaurant evidence and commercial direction here first, then pass the verified dish shortlist and image requirements into that skill. Keep the principles below as the acceptance contract for the final site.

Treat the Food Image Studio Manifest V3 demo validation as the integration boundary. Do not copy an AI-restaged food asset into the website unless it has one unique, recorded real served-dish-photo from the same restaurant, the real photo was supplied as an image input, the source was routed into one locked customer-facing Photography System, both canonical evidence sheets are hash-locked, all five QA gates pass, and the current manifest passes <food-image-skill>/scripts/validate_manifest.py --stage demo. Run that validator immediately before copying each output and again during final Demo QA. If the source, Photography System, evidence record or any QA gate is missing, keep the slot text-led or use a separately verified non-food asset. Never bypass this gate with a menu description, stock photo, synthetic style image or representative-concept render.

Prefer real restaurant-owned images because dish identity and atmosphere are evidence. For a private sales demo, public real photographs from Maps, social pages, review platforms, directories, and menu pages may serve as temporary factual or composition references even when the uploader is unknown. Record the source and uncertainty, do not imply that reference rights are cleared, and obtain approval or replacement assets before public launch.

Use separate gates. At the source gate, automatically retain the unique real dish source, source camera assessment, route, provenance and hashes. At the private Demo gate, retain the source-versus-designed-photo comparison, generation timing, registered output angle and the five gates: fidelity, style consistency, appetite optimization, AI tells and website readiness. The user may inspect either artifact later and request changes. Uploader identity is not required when a real public photo is credibly attached to the correct restaurant. At the public launch gate, require a cleared replacement or the relevant rightsholder permission plus owner confirmation of factual accuracy. Do not imply that a recorded private or one-to-one use grants publication rights.

When no current digital menu exists, have $restaurant-food-image-studio run its Google Maps-first fallback. Group repeated real dish photos, corroborate them with menu photographs, social posts, captions, and review mentions, then shortlist three to six featured candidates. Repetition is a selection signal, not proof of sales volume: use Featured by default and reserve Popular, Most Popular, Bestseller, or exact dish names for supported claims.

Use AI as an art-direction and restoration layer:

• Inspect every real source and classify its camera view before generating.
• Preserve the dish type, ingredients, portion, cooking method, sides and serving vessel; treat the source as food truth rather than a mandatory final composition.
• Lock one primary customer-facing camera family, angle tolerance, subject scale, crop, background, lighting direction, grade, lens feel and prop policy for the restaurant set.
• Route a source that does not fit that system to reference-restage; never preserve an unsuitable overhead or casual snapshot angle merely because it is real.
• Improve exposure, white balance and source-supported appetite cues such as natural golden bread or visible browning without changing doneness, marks, portion or ingredients.
• Reject plastic gloss, waxy texture, repetition, perfect geometry, impossible effects and other visible AI cues.
• Use a wide image for the hero and a consistent 4:3 family for featured food.
• Generate only three to six featured-food images; let the complete menu remain text-led.
• Mark uncertain output as concept imagery and include it in the owner-verification set.
• Keep Google Maps screenshots and other third-party originals out of the Demo page; record them only in the internal manifest and contact sheet.

Do not label a generated image as an exact menu item when the reference does not prove its ingredients. Avoid impossible garnishes, exaggerated steam or cheese pulls, fake logos, generated menu text, excessive perfection, and stock-photo polish that contradicts the restaurant.

Use $restaurant-exterior-image-studio for actual storefront-source auditing, preservation planning, AI-assisted restoration or reference-based recreation, manifest tracking, registration, comparison and six-part QA. In a complete Demo build, decide the arrival-image purpose and slot here first, then pass the aspect ratio, focal point, intended placement and wayfinding requirement into that skill.

Treat the Exterior Image Studio demo validation as the integration boundary. Do not copy an AI-assisted storefront into the website unless current real sources prove the sign, entrance, facade geometry, facade colors and fixed features; all output-facing regions are supported or cropped out; the preservation contract is complete; all six QA gates pass; and <exterior-skill>/scripts/validate_manifest.py --stage demo succeeds immediately before integration.

Keep a food-led hero when appetite is the primary conversion; place the exterior near the Visit section unless the building itself is the verified attraction. Keep public-platform originals internal, label a private-Demo output as a photo proposal, and preserve separate owner-accuracy and publication-rights gates. Street View remains research-only except for an official embed or link.

Read the Exterior And Arrival Imagery section in references/demo-playbook.md before planning or placing the asset; let the specialized Skill control production details.

Make The Menu The Core Utility

Build the menu as structured page content, not as a PDF or a gallery of menu photographs. Use the current menu as the source of truth and preserve spelling, options, and prices.

• Provide horizontally scrollable, sticky category navigation on mobile when the menu is long.
• Show item name, concise description when available, and right-aligned price.
• Use tags such as Popular, Spicy, or Vegetarian only when supported.
• Keep menu rows compact and scannable; do not turn every item into a card.
• Do not hide essential content behind hover interactions.
• When a current menu cannot be verified, show a clearly labeled sample menu layout without invented prices and add the missing menu to the owner-verification list.

Make Reviews Persuasive And Maps Useful

Treat reviews as decision evidence, not decoration. Prefer an editorial hierarchy with one short featured excerpt that proves the primary positioning and up to two supporting excerpts or themes that prove different decisions, such as menu breadth, portion size, service, or suitability as a travel stop.

• Quote only text checked against a current public source. Keep the reviewer name or clearly recognizable attribution, source, and available date close to the excerpt, and link to the source or the restaurant's current review surface.
• If exact text, reviewer identity, platform origin, or individual star rating cannot be verified, paraphrase the repeated theme and label it as a review theme. Do not format a paraphrase as a quotation.
• Show stars beside an individual excerpt only when that review's rating is verified. Do not reuse the restaurant's aggregate rating as if it belonged to every quoted reviewer.
• Keep the featured excerpt compact enough to remain readable in roughly two to five lines on mobile. Avoid walls of praise and three interchangeable quotes that all say only "great food" or "great service."
• When displaying reviews through a platform API, preserve the required author attribution, platform attribution, source link, and any other current display requirements.

Use a real interactive map when location and wayfinding affect the primary decision. Keep the map functional and subordinate to the visit actions.

• Use an official Google Maps embed or another verified map provider integration. Never imitate a map with a screenshot, generated image, or nonfunctional surface.
• Put the address and a direct Get Directions action before the map in mobile reading order. The map confirms location; the directions link remains the primary command.
• Keep the map compact, responsive, titled for accessibility, and lazy-loaded. A typical mobile height is 260-320px; do not let provider chrome consume the entire Visit section.
• Expect provider labels and controls to localize to the visitor's language. Do not treat that normal localization as a visual defect.
• Keep API keys out of source control and project documentation. Follow the provider's current attribution, key-restriction, loading, and privacy requirements.
• When a storefront arrival band is present, sequence the lower page as reviews -> exterior recognition -> visit details and map so the map does not compete with the exterior image.

Implement The Demo

Follow the repository's existing framework and component patterns. Keep the implementation scoped to the restaurant demo.

• Make the first screen the actual restaurant experience, not an explanation of the demo.
• Make phone numbers, directions, social links, and verified order links functional.
• Optimize images and avoid unnecessary scripts so the mobile page loads quickly.
• Provide accessible contrast, focus states, image alt text, semantic headings, and keyboard-operable menu controls.
• Keep content editable from a clear data structure when the existing project supports it.
• Do not publish or contact the restaurant unless the user explicitly asks.

Verify Before Handoff

For a built demo:

1. Run the appropriate formatter, lint, and focused tests.
2. Start the local server when required and keep it running for the user.
3. Inspect the site in a real browser at desktop and mobile sizes, including approximately 1440x900 and 390x844.
4. Confirm that images render, text does not overlap, menu labels fit, controls work, links point to real destinations, and the first viewport leaves a hint of following content.
5. Check the page against the factuality list. Report every item that still needs owner confirmation, the current private/public review gate, all publication-clearance gaps, exterior-photo rights, and any AI restoration.
6. Re-run the Brand Palette handoff validation when a palette lock is present, and the Exterior Image Studio demo validation when an AI-assisted storefront is present. Confirm the implemented CSS variables match the palette lock and the displayed exterior matches the registered output.

For an analysis-only request, give the recommendation first, then the evidence and assumptions. For a build, hand off the local URL, changed files, verification performed, and the short owner-confirmation list.

Example Invocations

• $restaurant-demo-builder Analyze Logger's Depot and propose an evidence-backed one-page demo.
• $restaurant-demo-builder Build a mobile-first demo for this restaurant using the lead row and public menu.
• $restaurant-demo-builder Refresh this restaurant demo, derive its palette from venue evidence, restore a faithful storefront image, and make the menu easier to scan.