Communitygithub.com

레스토랑 데모 빌더

증거 기반의 영업 데모를 구축하여 레스토랑 주인이 자신의 가게를 알아보고, 상실된 온라인 기회를 명확히 인식하도록 돕습니다. 모바일 우선 웹사이트를 조사, 기획, 디자인, 구축 및 시각적으로 검증합니다.

레스토랑 데모 빌더란 무엇인가요?

이 스킬은 Codex와 같은 AI 에이전트가 독립 레스토랑을 위한 맞춤형 웹사이트 데모를 제작할 수 있도록 설계된 포괄적인 워크플로우입니다. 레스토랑의 실제 증거(리뷰, 메뉴, 위치 데이터)를 기반으로 단순한 템플릿이 아닌, 레스토랑 소유주가 자신의 가게임을 알아보고 온라인 부재로 인한 기회 손실을 인식하도록 돕는 영업 데모를 구축합니다. 분석, 빌드, 리프레시의 세 가지 모드를 지원하며, Google Maps, Facebook, 공식 웹사이트 등 다양한 출처에서 정보를 수집 및 검증합니다. 핵심 기능으로는 레스토랑 브랜드 팔레트 추출, 음식 및 외관 이미지 생성 스튜디오와의 통합, 증거 기반 메뉴 구성, 모바일 우선 레이아웃 라우팅 등이 있습니다. 이 스킬은 일반적인 레스토랑 디렉토리나 배달 마켓플레이스 구축이 아닌, 실제 영업 및 마케팅에 사용할 수 있는 맞춤형 데모 생성에 특화되어 있습니다.

지원 대상~Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/LucasH1225/restaurant-website-skills/tree/HEAD/skills/restaurant-demo-builder

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

레스토랑 데모 빌더은(는) 무엇을 하나요?

증거 기반의 영업 데모를 구축하여 레스토랑 주인이 자신의 가게를 알아보고, 상실된 온라인 기회가 명확히 드러나도록 하십시오. 데모를 레스토랑 이름만 붙인 일반 테마가 아니라, 레스토랑의 실제 웹사이트 첫 번째 유용한 버전으로 취급하십시오.

본격적인 리서치, 디자인, 이미지 제작 또는 구현 전에 references/demo-playbook.md를 읽으십시오. 요청과 관련된 섹션만 사용하십시오.

작업 모드 선택

행동하기 전에 요청된 모드를 확인하십시오:

  • 분석: 출처가 포함된 컨셉, 근거, 페이지 구조, 이미지 방향, 메뉴 계획 및 검증 간격을 반환합니다. 요청하지 않는 한 프로젝트 파일을 편집하지 마십시오.
  • 빌드: 레스토랑을 리서치하고, 적절한 에셋을 생성 또는 준비하고, 작동하는 데모를 구현하고, 실행한 후 데스크톱 및 모바일 뷰를 시각적으로 검증합니다.
  • 리프레시: 기존 데모와 현재의 공개된 사실을 검사한 후, 오래되었거나 약한 부분만 업데이트하고 시각적 검증을 다시 실행합니다.

동일한 이름의 여러 업체가 있고 올바른 위치를 추론할 수 없는 경우에만 명확히 설명을 요청하십시오. 그렇지 않은 경우, 먼저 로컬 리드 데이터와 공개 출처를 검사하십시오.

증거로 작업하기

  1. 브라우징 전에 현재 작업 공간을 검사하십시오. 리드 내보내기, 브리프, 기존 데모 및 디자인 에셋에서 레스토랑 이름, 위치, 장소 ID 및 URL을 검색하십시오.
  2. 레스토랑 정보는 자주 변경되므로 현재의 공개된 사실을 확인하십시오. 레스토랑의 자체 사이트 및 소셜 페이지, Google 리스팅 또는 Maps 데이터, 현재 메뉴 또는 주문 페이지, 최근 리뷰, 관련 공식 관광 또는 상공회의소 페이지를 확인하십시오.
  3. 데모에 제안된 이름, 주소, 전화번호, 영업 시간, 평점, 리뷰 수, 카테고리, 서비스, 메뉴 항목, 가격, 이벤트, 온라인 주문, 소셜 링크 및 장소 또는 외관 이미지에 대한 출처와 신뢰도를 기록하십시오.
  4. 작업 중에 콘텐츠를 세 가지 레이블로 구분하십시오:
    • 확인된 사실: 현재 출처에 의해 직접 뒷받침됨.
    • 합리적 추론: 리뷰나 위치 컨텍스트에서 반복되는 패턴에 의해 뒷받침됨.
    • 창의적 제안: 데모를 위해 생성된 태그라인, 아트 디렉션, 레이아웃 또는 캠페인 아이디어.
  5. 가능한 경우 가장 최근의 소유주 통제 출처로 상충되는 사실을 해결하십시오. 해결되지 않은 충돌은 소유주 확인 목록에 포함하십시오.
  6. 레스토랑 정체성, 웹사이트 문제, 메뉴 가용성, 핵심 연락처 세부정보, 주요 대상 고객 증거 및 반복되는 리뷰 테마가 충분히 확립되면 리서치를 중단하십시오. 분석 모드의 경우, 포괄적인 디렉토리 검색보다는 소수의 강력한 출처를 선호하고, 브리프를 지연시키는 대신 해결되지 않은 세부 사항을 나열하십시오.

메뉴 항목, 가격, 영업 시간, 수상 내역, 할인, 배달, 예약, 주문, 이벤트 일정 또는 접근성 주장을 절대 만들어내지 마십시오. 목적지와 서비스가 실제가 아닌 한 작동하는 것처럼 보이는 명령 버튼을 추가하지 마십시오.

하나의 상업적 포지셔닝 정의하기

증거에서 하나의 주요 대상 고객과 하나의 주요 전환 목표를 선택하십시오. 일반적인 대상 고객으로는 통과 여행자, 지역 가족, 아침 식사 단골, 스포츠 바 손님, 저녁 그룹이 있습니다. 일반적인 목표로는 메뉴 보기, 길찾기, 전화 걸기, 확인된 온라인 주문 등이 있습니다.

첫 번째 뷰포트는 5초 이내에 다음 질문에 답해야 합니다:

  1. 이곳은 어떤 레스토랑인가?
  2. 방문객이 이곳을 선택해야 하는 이유는?
  3. 영업 중인가, 아니면 언제 영업하는가?
  4. 방문객이 메뉴를 보거나 가려면 어떻게 해야 하는가?

레스토랑 이름을 H1으로 사용하십시오. 포지셔닝을 보조 카피에 배치하십시오. "훌륭한 음식" 또는 "신선한 재료"와 같은 일반적인 문구보다는 시간대, 시그니처 요리, 위치, 영업 시간, 양, 리뷰 테마와 같은 구체적인 증거를 선호하십시오.

디자인 라우팅

레스토랑 증거, 대상 고객, 상황 및 주요 행동이 확립된 후, references/design-routing.md를 읽으십시오. 레스토랑 프로필을 생성하고, scripts/select_recipe.py를 실행한 후 생성된 recipe-lock.json을 데모 리서치 기록과 함께 저장하십시오.

선택된 레시피 참조만 읽은 후, assets/layouts/<layout-id>/에서 독립적으로 선택된 레이아웃 스타터를 복사하십시오:

V2 라이브러리의 구조적 증거를 검토하거나, 레이아웃 문법을 확장하거나, 디자인 불일치를 진단할 때만 references/layout-research-2026-07-v2.md를 사용하십시오. 이전의 design-research-2026-07.md 및 assets/starters/는 V1 기록이며 새로운 데모 라우팅에 참여하지 않습니다. 참조 레스토랑의 코드, 사진, 글, 로고, 일러스트레이션 또는 독특한 전체 구성을 복사하지 마십시오.

레시피와 레이아웃 선택을 별도의 제약 조건으로 취급하십시오. 레시피는 대상 고객, 톤, 기능 및 시각적 태도를 제어합니다. 레이아웃 문법은 히어로, 미디어 구성, 증거 형식, 메뉴 기하학, 섹션 기하학 및 모바일 변환을 제어합니다. 확인된 레스토랑 증거는 계속해서 주문, 예약, 이벤트, 영업 시간, 서비스, 메뉴 콘텐츠, 리뷰 및 이미지를 제어합니다. V2 잠금을 수동으로 우회하지 마십시오. 결과가 잘못된 경우 프로필, 호환성 정의 또는 기록 지문을 수정하십시오.

레스토랑 브랜드 팔레트 잠그기

외관, 간판, 로고, 메뉴, 포장 또는 내부 이미지가 사용 가능한 아이덴티티 색상 증거를 제공하는 경우, 레시피 및 레이아웃 잠금 후 최종 시각적 스타일링 전에 $restaurant-brand-palette를 사용하십시오. 검증된 brand-palette.json을 저장하고 recipe-lock.json 옆에 미리보기를 저장하십시오.

팔레트, 레시피 및 레이아웃을 별도의 잠금으로 취급하십시오. 팔레트는 CSS 색상 역할과 비율을 제어합니다. 대상 고객, 기능, 히어로 문법 또는 섹션 기하학을 변경하지 않습니다. 구현 중에 직접 대체 16진수 값을 도입하지 마십시오.

증거 검토 후 신뢰할 수 있는 브랜드 색상이 남지 않은 경우, 팔레트 스킬이 명확하게 레이블이 지정된 레시피 폴백을 생성하도록 하십시오. 폴백이 레스토랑에서 나온 것이라고 주장하지 마십시오. 토큰 변경 후 재검증하고 텍스트 위의 사진을 별도로 검사하십시오.

결정을 중심으로 페이지 구축

선택된 레시피가 더 나은 증거 기반 순서를 지정하지 않는 경우 이 기본 순서를 사용하십시오. 증거가 부족한 섹션은 제거하십시오:

  1. 메뉴, 인기 메뉴 및 방문에 대한 컴팩트 네비게이션과 가치 높은 명령.
  2. 레스토랑 이름, 하나의 구체적인 가치 제안, 메뉴 보기 및 길찾기 또는 전화가 포함된 전체 너비 히어로.
  3. 확인된 평점/리뷰 수, 영업 시간, 가격 신호 또는 다운타운/위치 컨텍스트가 포함된 증거 스트립.
  4. 가능한 경우 확인된 이름을 사용하여 3~6개의 추천 요리; 요리에 확인된 실제 사진이 없는 경우 텍스트 중심의 카테고리나 대표 레이블을 사용하고 사실적인 음식 이미지를 만들어내지 마십시오.
  5. 카테고리 네비게이션이 있는 읽기 쉬운 HTML 메뉴.
  6. 경험 또는 시간대 섹션은 아침부터 늦은 밤, 가족 식사, 스포츠 또는 라이브 이벤트와 같이 비즈니스를 명확히 하는 경우에만 추가하십시오.
  7. 선택된 포지셔닝을 뒷받침하는 짧고 출처가 있는 리뷰 증거.
  8. 확인된 외관 사진이 인식이나 길찾기를 실질적으로 개선하는 경우 도착 또는 외관 밴드.
  9. 주소, 현재 영업 시간, 전화번호, 지도/길찾기 및 소유한 소셜 링크가 포함된 방문 섹션.
  10. 가장 중요한 명령에 대한 모바일 고정 액션.

경험을 직접적이고 유용하게 유지하십시오. 모든 섹션에 대한 장식용 카드, 가짜 예약 양식, 일반적인 셰프 스토리, 뒷받침되지 않는 "마을 최고" 주장 및 긴 마케팅 문구를 피하십시오.

일관된 이미지 시스템 만들기

실제 음식 참조 감사, 이미지 생성, 수리, 매니페스트 추적 및 출처 대 제안 연락처 시트를 위해 $restaurant-food-image-studio를 사용하십시오. 완전한 데모 빌드에서 먼저 여기서 레스토랑 증거 및 상업적 방향을 확립한 다음, 확인된 요리 후보 목록과 이미지 요구 사항을 해당 스킬에 전달하십시오. 최종 사이트에 대한 수용 조건으로 아래 원칙을 유지하십시오.

Food Image Studio Manifest V3 demo 유효성 검사를 통합 경계로 취급하십시오. AI로 재구성된 음식 에셋을 웹사이트에 복사하지 마십시오. 단, 동일한 레스토랑의 고유하고 기록된 실제 served-dish-photo가 하나 있고, 실제 사진이 이미지 입력으로 제공되었으며, 출처가 하나의 잠긴 고객 대상 사진 시스템으로 라우팅되었고, 두 표준 증거 시트가 해시 잠금되어 있으며, 다섯 가지 QA 게이트를 모두 통과하고, 현재 매니페스트가 <food-image-skill>/scripts/validate_manifest.py --stage demo를 통과하는 경우는 예외입니다. 각 출력을 복사하기 직전과 최종 데모 QA 중에 해당 검증기를 다시 실행하십시오. 출처, 사진 시스템, 증거 기록 또는 QA 게이트가 누락된 경우, 슬롯을 텍스트 중심으로 유지하거나 별도로 확인된 비음식 에셋을 사용하십시오. 메뉴 설명, 스톡 사진, 합성 스타일 이미지 또는 representative-concept 렌더링으로 이 게이트를 절대 우회하지 마십시오.

요리 정체성과 분위기는 증거이므로 실제 레스토랑 소유 이미지를 선호하십시오. 개인 영업 데모의 경우, Maps, 소셜 페이지, 리뷰 플랫폼, 디렉토리 및 메뉴 페이지의 공개 실제 사진은 업로더를 알 수 없더라도 임시 사실 또는 구성 참조로 사용될 수 있습니다. 출처와 불확실성을 기록하고, 참조 권한이 확보되었음을 암시하지 말며, 공개 출시 전에 승인 또는 대체 에셋을 얻으십시오.

별도의 게이트를 사용하십시오. 출처 게이트에서 고유한 실제 요리 출처, 출처 카메라 평가, 경로, 출처 및 해시를 자동으로 보존하십시오. 개인 데모 게이트에서 출처 대 설계 사진 비교, 생성 타이밍, 등록된 출력 각도 및 다섯 가지 게이트(충실도, 스타일 일관성, 식욕 최적화, AI 티 및 웹사이트 준비 상태)를 보존하십시오. 사용자는 나중에 두 아티팩트 중 하나를 검사하고 변경을 요청할 수 있습니다. 실제 공개 사진이 올바른 레스토랑에 신뢰할 수 있게 연결된 경우 업로더 신원은 필요하지 않습니다. 공개 출시 게이트에서 승인된 대체물 또는 관련 권리 보유자의 허가와 소유주의 사실 정확성 확인을 요구하십시오. 기록된 개인 또는 1:1 사용이 출판 권한을 부여한다고 암시하지 마십시오.

현재 디지털 메뉴가 없는 경우, $restaurant-food-image-studio가 Google Maps 우선 폴백을 실행하도록 하십시오. 반복되는 실제 요리 사진을 그룹화하고, 메뉴 사진, 소셜 게시물, 캡션 및 리뷰 언급과 대조한 다음, 3~6개의 추천 후보를 선정하십시오. 반복은 선택 신호이지 판매량 증거가 아닙니다: 기본적으로 추천을 사용하고, 인기, 최고 인기, 베스트셀러 또는 정확한 요리 이름은 뒷받침되는 주장을 위해 보류하십시오.

AI를 아트 디렉션 및 복원 레이어로 사용하십시오:

  • 생성하기 전에 모든 실제 출처를 검사하고 카메라 뷰를 분류하십시오.
  • 요리 유형, 재료, 양, 조리 방법, 사이드 및 서빙 용기를 보존하십시오. 출처를 필수 최종 구성이 아닌 음식 진실로 취급하십시오.
  • 레스토랑 세트에 대해 하나의 기본 고객 대상 카메라 패밀리, 각도 허용 오차, 피사체 스케일, 크롭, 배경, 조명 방향, 등급, 렌즈 느낌 및 소품 정책을 잠급니다.
  • 해당 시스템에 맞지 않는 출처를 reference-restage로 라우팅하십시오. 실제이기 때문에 부적절한 오버헤드 또는 캐주얼 스냅샷 각도를 보존하지 마십시오.
  • 익힘 정도, 표시, 양 또는 재료를 변경하지 않고 노출, 화이트 밸런스 및 출처가 지원하는 식욕 신호(예: 자연스러운 황금빛 빵 또는 보이는 갈변)를 개선하십시오.
  • 플라스틱 광택, 왁스 같은 질감, 반복, 완벽한 기하학, 불가능한 효과 및 기타 눈에 띄는 AI 신호를 거부하십시오.
  • 히어로에는 와이드 이미지를 사용하고 추천 음식에는 일관된 4:3 패밀리를 사용하십시오.
  • 추천 음식 이미지는 3~6개만 생성하십시오. 전체 메뉴는 텍스트 중심으로 유지하십시오.
  • 불확실한 출력은 컨셉 이미지로 표시하고 소유주 확인 세트에 포함하십시오.
  • Google Maps 스크린샷 및 기타 타사 원본을 데모 페이지 외부에 두고 내부 매니페스트 및 연락처 시트에만 기록하십시오.

참조가 재료를 입증하지 않는 경우 생성된 이미지를 정확한 메뉴 항목으로 레이블을 지정하지 마십시오. 불가능한 가니쉬, 과장된 스팀 또는 치즈 풀, 가짜 로고, 생성된 메뉴 텍스트, 과도한 완벽함 및 레스토랑과 모순되는 스톡 사진 광택을 피하십시오.

실제 외관 출처 감사, 보존 계획, AI 지원 복원 또는 참조 기반 재창조, 매니페스트 추적, 등록, 비교 및 6부분 QA를 위해 $restaurant-exterior-image-studio를 사용하십시오. 완전한 데모 빌드에서 먼저 여기서 도착 이미지 목적과 슬롯을 결정한 다음, 종횡비, 초점, 의도된 배치 및 길찾기 요구 사항을 해당 스킬에 전달하십시오.

Exterior Image Studio demo 유효성 검사를 통합 경계로 취급하십시오. 현재의 실제 출처가 간판, 입구, 외관 기하학, 외관 색상 및 고정 기능을 입증하지 않는 한, AI 지원 외관을 웹사이트에 복사하지 마십시오. 모든 출력 대상 영역이 지원되거나 잘려나가고, 보존 계약이 완료되었으며, 6개의 QA 게이트를 모두 통과하고, <exterior-skill>/scripts/validate_manifest.py --stage demo가 통합 직전에 성공해야 합니다.

식욕이 주요 전환인 경우 음식 중심의 히어로를 유지하십시오. 건물 자체가 확인된 명소가 아닌 한 외관을 방문 섹션 근처에 배치하십시오. 공개 플랫폼 원본을 내부에 유지하고, 개인 데모 출력을 사진 제안으로 레이블을 지정하며, 별도의 소유주 정확성 및 출판 권리 게이트를 보존하십시오. 공식 임베드 또는 링크를 제외하고 Street View는 연구 목적으로만 사용됩니다.

에셋을 계획하거나 배치하기 전에 references/demo-playbook.md의 외관 및 도착 이미지 섹션을 읽으십시오. 전문 스킬이 생산 세부 사항을 제어하도록 하십시오.

메뉴를 핵심 유틸리티로 만들기

메뉴를 구조화된 페이지 콘텐츠로 구축하십시오.

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

LucasH1225/restaurant-website-skills

Extract, interpret, record, and validate evidence-backed restaurant color systems for website demos. Use when Codex needs to inspect a storefront, sign, logo, menu, packaging, or interior photo for recurring brand colors; separate brand evidence from food, sky, foliage, lighting casts, asphalt, or camera noise; choose a harmonious palette combination; translate a real anchor color into accessible CSS design tokens; preview color roles; or hand a palette lock to restaurant-demo-builder. Do not use for generic color inspiration without restaurant evidence, logo redesign, image generation, layout selection, or blind extraction of the most frequent pixels.

LucasH1225/restaurant-website-skills

Initialize, parallelize, resume, integrate, and validate evidence-gated restaurant website Demo work orders across restaurant-demo-builder, restaurant-brand-palette, restaurant-food-image-studio, and restaurant-exterior-image-studio. Use when Codex needs to start a new restaurant Demo from a lead, coordinate design/food/storefront subagents, run the complete multi-Skill workflow, continue interrupted work without repeating passed stages, inspect blockers or artifacts, or verify that a private Demo is ready for review. Do not use it to publish a site, contact a restaurant, bypass a specialist manifest, or generate unsupported food or storefront imagery.

LucasH1225/restaurant-website-skills

Audit, restore, recreate, and verify evidence-backed restaurant storefront and arrival photography for private website demos. Use when Codex needs to turn real venue exterior references into a faithful AI-assisted door-front image, repair exposure or perspective, create a recognizable arrival band, preserve signage and architecture, record source-versus-output evidence, or decide whether an exterior image is safe for Demo or public use. Do not use for invented storefront concepts, interior-only work, food photography, generic architecture renders, detached Street View screenshots, or any image that cannot be grounded in current real venue evidence.

LucasH1225/restaurant-website-skills

Collect, restage, harmonize, and verify evidence-backed food photography for independent restaurant website demos. Use when Codex needs to retrieve real restaurant dish photos through Apify Google Maps or Masa, turn mixed phone snapshots into one coherent customer-facing camera and lighting system, improve exposure or source-supported appetite cues, prevent visible AI artifacts, bind every designed image to a real served-dish source, or retain source-versus-output evidence and timing records. Do not use for text-only food generation, generic stock-food requests, full-menu illustration, or any realistic dish image that lacks a matching real restaurant photo.

관련 스킬