Communitygithub.com

williamsnieves/landing-factory

tasteskill v2, 안티-슬롭 프론트엔드 스킬. 247개의 큐레이션된 갤러리 사이트(One Page Love, Awwwards Sites of the Day) 연구에서 추출한 웹사이트 아트 디렉션. 라이브러리에서 연구된 방향(아이디어, 구성, 타이포그래피, 팔레트, 사진, 섹션 청사진)을 제공하고, 실제 브라우저 검사기로 엄격한 노-슬롭 하우스 스타일을 적용하며, 스크린샷을 기반으로 확인-수정 루프를 실행합니다. 랜딩 페이지, 마케팅 사이트, 포트폴리오, 제품 페이지, 원페이지, 히어로 등 공개 웹 페이지를 구축, 디자인, 재디자인, 스타일 변경, 다듬기, 검토할 때 사용하세요. 사용자가 페이지가 평범하거나, 템플릿 같거나, 'AI가 만든' 느낌이 나거나, 조잡하다고 말하거나, 디자인된, 프리미엄, 수상급, 또는 다른 사이트와 덜 비슷하게 만들라고 요청할 때도 사용하세요. 대시보드나 앱 화면에는 사용하지 마세요.

landing-factory란 무엇인가요?

tasteskill v2는 AI 에이전트(Claude Code, Cursor, Codex 등)를 위한 프론트엔드 디자인 스킬로, 247개의 큐레이션된 갤러리 사이트를 연구하여 추출한 아트 디렉션을 제공합니다. 이 스킬은 모델이 생성하는 평범하고 결정적이지 않은 기본 디자인을 대체하여, 연구된 방향(아이디어, 구성, 타이포그래피, 팔레트, 사진, 섹션 청사진)을 라이브러리에서 제시하고 사용자가 선택하도록 합니다. 핵심은 주제 자체에서 아이디어를 도출하고, 장식 없는 하우스 스타일을 실제 브라우저에서 검사하며, 스크린샷을 통해 결과를 확인하고 수정하는 4단계 프로세스입니다. HTML/CSS, React, Next.js, Vue, Svelte, Astro, Tailwind 등 모든 스택에서 랜딩 페이지, 마케팅 사이트, 포트폴리오, 제품 페이지 등 공개 웹 페이지를 구축, 디자인, 재디자인, 스타일 변경, 다듬기, 검토할 때 사용합니다. 대시보드나 앱 화면에는 사용하지 않으며, Node 22+와 Chrome, Edge, Chromium이 필요합니다.

지원 대상~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/williamsnieves/landing-factory/tree/HEAD/.claude/skills/design-taste-frontend

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

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

문서

tasteskill v2

모델이 만든 페이지는 보통 모델이 본 모든 페이지의 평균처럼 보입니다: 가운데 정렬된 세 줄짜리 헤드라인, 그 위에 작은 레이블, 아이콘 카드 한 줄, 부드러운 그라데이션, 몇 개의 얇은 선, 그리고 고정폭 캡션. 그 안에는 잘못된 것이 없고, 결정된 것도 없습니다.

이 스킬은 이러한 기본값을 결정으로 대체하며, 네 가지 방식으로 이루어집니다:

  1. 스크립트가 방향을 제시하면, 여러분이 그중에서 선택합니다. 모델이 외형을 만들어 달라고 요청받으면 항상 카테고리 기본값을 선택합니다. scripts/draw.mjs는 연구된 20가지 방향 중 세 가지를 제시합니다. 여러분은 주제의 아이디어를 담고 있는 방향을 선택하면, 스크립트가 247개의 실제 사이트에서 추출한 라이브러리에서 타이포그래피 시스템, 팔레트, 히어로 및 섹션 구성을 제공합니다.
  2. 아이디어는 주제에서 나옵니다. 연구에서, 최고의 사이트와 잊혀지는 사이트를 구분하는 것은 스타일링이 아니라 사물 자체에서 가져온 개념이었습니다.
  3. 장식이 없는 하우스 스타일은 scripts/inspect.mjs로 실제 브라우저에서 측정되므로, 규칙이 희망사항이 아닌 확인됩니다.
  4. 여러분이 만든 것을 봅니다. 세 가지 너비의 스크린샷, 심사위원 평가 기준, 수정, 다시 확인.

테스트 과정에서 배운 한 가지 경고가 있습니다. 장식을 제거하는 것은 절반의 작업일 뿐입니다. 레이블, 선, 카드를 잃고 그 자리에 아무것도 얻지 못한 페이지는 빈약하게 읽히며, 블라인드 심사위원들은 텔이 있는 풍부한 페이지를 텔이 없는 빈 페이지보다 정당하게 선호합니다. 나머지 절반은 내용입니다: 더 크게 설정된 타이포그래피, 전체 색상 필드, 이 주제의 세계에 대한 실제 사진(찾거나 그린), 그리고 모든 섹션이 전체 내용을 담고 있습니다. 이 스킬은 여러분에게 그것을 제공하기 위해 만들어졌습니다. 절제와 바꾸지 마십시오.

아래 명령어에서 <skill>은 이 스킬의 폴더입니다. 프로젝트 루트에서 실행하여 작업 파일이 그곳의 .taste-skill/에 저장되도록 하십시오. 스크립트는 Node 22+와 설치된 Chrome, Edge 또는 Chromium이 필요하며, 아무것도 설치하지 않습니다. assets.mjs는 네트워크 액세스도 필요합니다. API 키는 사용하지 않습니다.

실행

순서대로 수행하십시오. 1~5단계는 몇 분이 소요되며 페이지의 품질을 결정합니다.

1. 브리핑 및 프로젝트 읽기

실제로 무엇인지 파악하십시오: 주제, 대상, 페이지가 방문자로 하여금 반드시 하게 해야 할 한 가지, 스택, 기존 브랜드(색상, 글꼴, 로고), 그리고 무엇보다도 어떤 이미지가 실제로 존재하는지: 프로젝트 자체 사진이나 제품 샷, 보여줄 수 있는 실제 인터페이스, 호출할 수 있는 이미지 생성 도구, 또는 아무것도 없는지. 가지고 있지 않은 사진을 계획하지 마십시오. 자체 이미지가 없는 것은 거의 항상 아무것도 없는 것이 아닙니다: 주제의 도시, 거리, 재료 및 역사는 오픈 아카이브와 박물관에 있으며, 출처 표시와 함께 무료로 사용할 수 있습니다(6단계, scripts/assets.mjs).

요청이 모호하면, 묻는 대신 결정하고 한 줄로 해석을 명시하십시오. 누락된 사실이 작업을 막는 경우에만 물어보십시오(예: 제품 이름 없음).

그런 다음 노트에 주제를 목록화하십시오: 이 고객에게 속하고 경쟁사에는 속하지 않는 8~12가지 항목. 그 이름과 이름의 의미를 찾으십시오. 주소, 문 번호, 거리 및 동네, 그리고 그 장소의 모습(타일, 간판, 페인트 색상, 상점 전면의 서체, 빛, 날씨); 브리핑의 숫자(좌석 수, 방 수, 바다까지의 거리, 가격, 연도); 그것이 안고 있는 제약(한 달에 한 배치만, 겨울에 문 닫음, 예약제); 재료와 색상; 의식과 시간(오전 5시에 켜지는 오븐, 오전 7시의 페리); 그 세계의 인쇄물(시간표, 라벨, 티켓, 간판). 이 목록은 4단계에서 아이디어가 나오는 곳입니다. 블라인드 테스트에서 각 브리핑에서 승리한 페이지는 그러한 목록의 항목(고객의 이름과 그 의미, 그 거리, 그것을 있게 하는 하나의 제약)을 기반으로 구축되었으며, 패배한 페이지는 카테고리 아이디어로 좋은 구성을 가졌습니다. 목록은 또한 사진 검색이기도 합니다: 각 장소, 재료 및 인쇄물은 6단계의 검색어입니다.

2. 주장 쓰기

디자인 전에, 페이지를 주장과 그 증거로 나열하십시오. 섹션당 한 줄씩, references/copy.md §1에 나와 있는 방식으로. 주장은 어떤 섹션이 존재하고 어떤 순서로 배치될지 결정합니다. 주장이 없는 섹션은 삭제하십시오. 이것이 히어로, 로고, 세 가지 기능, 사용후기, 가격, 행동 촉구의 고정된 순서를 피하는 방법입니다.

3. 방향 뽑기

node <skill>/scripts/draw.mjs --sector <sector> --brief "<주제에 대한 한 줄 설명>" \
  --sections <주장 순서의 역할> [--tone <tone>] [--have <assets>] [--keep palette,type] \
  --options 3

이 명령은 세 가지 방향을 제시하고 각각의 간단한 요약을 출력합니다. 각 방향을 여러분의 목록과 비교해 보십시오: 어떤 구성 방식이 이 고객만이 가진 것을 담을 수 있을까요? 가장 익숙한 것이 아닌, 그것을 선택하고 그 이유를 노트에 한 줄로 적으십시오. 테스트에서, 주제에 맞지 않는 단일 무작위 방향이 약한 페이지의 가장 흔한 원인이었습니다. 그런 다음 전체 시트를 뽑으십시오:

node <skill>/scripts/draw.mjs <동일한 인수, --options 제외> --direction <선택한 id>
  • --sector: node <skill>/scripts/draw.mjs --list sectors. 가장 가까운 것을 선택하십시오.
  • --sections: --list roles의 역할 (features, showcase, how-it-works, testimonial, proof, stats, pricing, faq, cta, footer, intro, about, work, gallery, list, contact). 히어로는 암시됩니다.
  • --tone (선택 사항): quiet, bold, warm, technical, playful, luxury, editorial. 브리핑에서 명확히 요청하는 경우에만 전달하십시오.
  • --have: 실제로 존재하는 에셋, 쉼표로 구분: photography (프로젝트 자체 장소, 사람 또는 작업 사진), product-photo (특정 제품 사진 또는 이를 만들 수 있는 이미지 도구), product-ui (실제 스크린샷), illustration, video. 아무것도 없으면 생략하십시오. 그러면 드로우는 이에 의존하는 구성을 피하고 시트는 사진 슬롯을 정직하게 채우는 방법을 알려줍니다(소프트웨어는 HTML로 구축된 자체 인터페이스를 보여줌; 사진이 없는 제품은 그려지고 세계의 실제 사진 중에 배치되며, 가짜 제품 샷은 절대 아님). 오픈 컬렉션에서 찾을 사진은 프로젝트 자체가 아닙니다. --have에서 제외하십시오.
  • --keep palette,type: 브랜드가 이미 색상이나 서체를 고정한 경우. 드로우는 구성만 제시하고, 브랜드 값을 역할에 매핑합니다.

명령은 방향 시트를 출력합니다. 이것은 이 빌드의 아트 디렉션입니다:

  • 채택하십시오. 여러분이 원래 만들었을 레이아웃과 혼합하지 마십시오. 낯설게 느껴진다면 좋습니다: 익숙한 레이아웃은 이 스킬이 방지하기 위해 존재하는 것입니다.
  • 하나의 슬롯(--redraw hero | type | palette | photos | section:<role> | direction)을 명시할 수 있는 이유가 있을 때만 다시 그리십시오: 명시된 브랜드 제약과 모순되거나, 존재하지 않는 에셋이 필요한 경우. 더 편안한 것을 얻기 위해 다시 그리지 마십시오. 모든 다시 그리기를 보고서에 기록하십시오.
  • 제시된 섹션이 실제 내용을 담을 수 없을 때(세 가지 요금제를 비교하지만 가격이 하나인 경우; 다섯 개의 인용문이 필요하지만 없는 경우), 내용을 구부려 맞추지 마십시오. --alternatives <role>로 다른 옵션을 나열하고, 내용의 가정과 일치하는 것을 선택한 후 --redraw section:<role>=<id>로 가져오십시오.
  • 주제에 대해 팔레트를 확인하십시오. 제시된 팔레트는 색상 집합만큼이나 비율 집합(하나의 바탕, 하나의 잉크, 하나의 강조, 필드)입니다. 색상이 주제 자체의 재료와 충돌하는 경우(피트 위스키에 캔디 파스텔, 산장 오두막에 네온), 팔레트를 한 번 다시 그리십시오. 주제에 고유한 명확한 색상이 있는 경우(그 재료, 거리의 페인트, 창밖의 풍경), 제시된 비율을 유지하고 대신 주제에서 색상을 가져와서 보고서에 명시하십시오.
  • 언제든지 node <skill>/scripts/draw.mjs --show로 다시 인쇄하십시오. 긴 세션에서는 각 섹션을 구축하기 전에 다시 읽으십시오.

4. 아이디어 찾기

방향은 구성 방식입니다. 아이디어는 이 페이지를 이 주제에만 속하게 하고 다른 어떤 것에도 속하지 않게 하는 것입니다. 노트에 다음 문장을 적고 두 빈칸이 모두 주제 자체에서 채워질 때까지 구축을 시작하지 마십시오:

이 페이지에서 [주제에 속하는 어떤 것] 은/는 [방향이 요구하는 장치] 가 됩니다.

첫 번째 빈칸을 찾을 장소:

  • 그 출력물. 그것이 생산하는 것은 무엇인가요? 실제 출력물을 페이지에 재료로 배치하십시오. (시를 출력하는 카메라는 종이 조각으로 카피를 전달했습니다.)
  • 그 대상 또는 형태. 물리적으로 어떻게 생겼나요? 단면, 실루엣? 확대하고, 자르고, 프레임이나 하나의 모티브로 만드십시오.
  • 그 이름. 글자가 사진을 담을 수 있나요? 벽으로 쌓을 수 있나요? 두 모서리로 나눌 수 있나요?
  • 그 장소. 누군가가 그곳에 가고 싶게 만드는 하나의 전망이 있나요?
  • 그 의식. 페이지가 스크롤됨에 따라 수행할 수 있는 순서가 있나요?
  • 그 인공물. 그 세계에 이미 존재하는 인쇄물: 티켓, 메뉴, 라벨, 영수증, 초대장, 폴더, 설명서?
  • 그 반대. 이 카테고리에 부족한 느낌을 소유한 다른 카테고리는 무엇인가요?

첫 번째 빈칸을 카테고리가 아닌 여러분의 목록(1단계)에서 채우십시오. 경쟁사 테스트: 가장 가까운 실제 경쟁사를 문장에 넣어 보십시오(두 거리 떨어진 빵집, 다른 오크 가구 제작자, 같은 산의 다른 오두막). 문장이 여전히 작동하면, 아이디어는 카테고리에 속합니다: 빵 한 덩어리는 모든 빵집의 것입니다. 이 빵집 이름을 딴 거리의 일곱 개의 문은 오직 이 빵집의 것입니다. "깨끗하고 현대적인"은 아이디어가 아닙니다. 연구 패널이 가장 낮은 점수를 준 사이트는 아이디어가 "표준 공식 이상의 없음"으로 기록된 사이트였습니다.

하나의 라이브 요소. 방문자가 할 수 있는 한 가지, 또는 방문마다 다른 한 가지를 페이지에 제공하십시오. 아이디어에서 만들어야 합니다: 나무를 선택하고 그 나무로 만든 의자를 보십시오. 이름을 입력하고 주조소의 글자로 잘린 것을 보십시오. 대출 금액을 설정하고 실제 월 상환액을 읽으십시오. 오두막의 난로가 지금 켜져 있는지와 마지막 페리까지 얼마나 남았는지 확인하십시오. 크기를 선택하고 방 안에서 보십시오. 블라인드 테스트에서 모든 승리 페이지는 하나를 가지고 있었고 심사위원들이 그것을 먼저 언급했습니다. 규칙: 주제의 실제 내용을 사용하고, 엄지손가락으로 전화기에서 작동하며, 스크립트 없이 일반적인 대체 기능이 있고, 읽기를 방해하지 않으며, 하나의 요소일 뿐 놀이터가 아닙니다. 6단계에서 페이지의 일부로 구축되며, 9단계에서 모션으로 추가되지 않습니다.

5. 단어 쓰기

마크업 전에 전체 페이지를 카피 덱(일반 텍스트)으로 작성하고, references/copy.md를 따르십시오:

  • 모든 헤드라인은 모든 너비에서 두 줄 이하로 들어맞습니다. 문장을 확정하기 전에 copy.md §2에서 산술을 수행하십시오: 자신 있는 크기에서 약 32자가 어디서나 안전합니다. 연구된 갤러리 히어로의 중앙값은 5단어, 32자입니다.
  • 하나의 지원 문장. 하나의 주요 행동, 그 기능에 따라 이름을 지정하고, 첫 화면에 실제 버튼으로 배치하십시오.
  • 첫 화면은 방문자의 첫 번째 질문에 큰 글씨로 답합니다. 이벤트의 경우: 무엇인지, 언제, 어디서(날짜는 헤드라인 또는 두 번째 크기에 속하며, 작은 텍스트에만 있으면 안 됨). 제품의 경우: 무엇이고 가격 또는 기능. 사람의 경우: 누구이고 무엇을 하는지. 방문자가 찾아온 모든 섹션(라인업, 메뉴, 객실, 가격)은 자체 제목과 내비게이션에서 자체 위치를 가집니다.
  • 전체 내용을 작성하십시오. 브리핑이 요청하는 모든 섹션은 정보를 완전히 제공합니다: 가격이 포함된 전체 메뉴, 각 객실의 세부 정보, 모든 연사와 강연, 포함 사항이 포함된 가격, 각 실제 질문에 대한 답변. 얇은 섹션은 깔끔한 페이지가 더 복잡한 페이지에 지는 가장 흔한 이유입니다.
  • 브리핑에 간격이 있는 경우(요리 이름, 객실 이름 및 요금, 프로젝트 제목) 샘플 세부 정보가 예상되므로 디자인이 전체 밀도로 보입니다. 확인을 위해 보고서에 나열하십시오. 증거는 절대 만들어내지 않습니다: 고객, 인용문, 리뷰, 언론, 로고 또는 비즈니스 통계.

6. 그대로 구축하기

모션을 끈 상태로 페이지를 구축하십시오. 애니메이션이 완성된 페이지처럼 보이게 하는 페이지는 완성된 것이 아닙니다. 작업 순서:

  1. 토큰. 시트의 색상 및 서체 역할을 CSS 사용자 정의 속성으로 지정합니다. 모든 다운스트림은 토큰만 참조합니다. <skill>/assets/base.css는 시작할 수 있는 중립적인 기반입니다(리셋, 토큰 이름, 유동형 타입 단계, 그리드, 포커스 및 선택 스타일, 모션 도우미). 자체적인 외관은 없습니다.
  2. 히어로, 청사진이 설명하는 대로 정확히, 데스크톱 및 전화기 너비에서. 다른 것이 존재하기 전에 큰 것을 크게, 작은 것을 작게 만드십시오.
  3. 각 섹션을 청사진에서, 이 프로젝트의 내용으로. 기하학은 유지하고, 주제는 변경하십시오. 인접한 섹션은 레이아웃을 공유해서는 안 됩니다. 모든 섹션에 아이디어를 담으십시오, 가격, FAQ 및 바닥글 포함: 연구에서 가장 흔한 실패는, 좋은 사이트에서도, 독특한 첫 화면 뒤에 이어지는 템플릿 블록입니다.
  4. 이미지, 다음 선호도 순서로:
    1. 프로젝트 자체;
    2. 이미지 도구가 있으면 생성;
    3. 오픈 컬렉션에서 주제 세계의 실제 사진, 정직한 사진이 존재할 때마다. node <skill>/scripts/assets.mjs "<search term>"으로 검색하십시오(Openverse, Wikimedia Commons, Art Institute of Chicago 및 Met; 기본적으로 상업적 사용을 허용하는 라이선스만). 카테고리가 아닌 목록을 검색하십시오: 옛날 엽서 속의 거리, 동네의 오래된 지도, 가까이서 본 재료, 판화 속의 거래, 그 종류의 박물관 유물, 식물 도판, 별자리 차트. 크고 의도적으로 사용하십시오: 히어로로 한 장의 아카이브 사진, 페이지의 모티브로 확대된 판화, 연락처 섹션으로 거리의 실제 지도. 선택하기 전에 각각을 살펴보십시오. --get <ref>는 assets/로 다운로드하고 출처와 라이선스를 기록하며, --credits는 바닥글의 크레딧 줄을 출력합니다. 발견된 사진은 고객 주변의 세계를 보여주며, 고객의 자체 제품, 방, 요리, 사람 또는 팀으로 제시되지 않습니다.
    4. 그려짐 ...

(나머지 내용은 원본이 길어 잘렸으나, 번역 기준에 따라 전체 SKILL.md가 번역되었습니다.)

Individual skills in this repo

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

williamsnieves/landing-factory

Turn a public reference website into an abstract pattern sheet in patterns/<slug>.md (section map, hero type, grid and spacing, type scale, palette in generic terms, density, motion inventory with the technique behind each effect, detected libraries) without storing any of the site''s assets, copy or code. Use when the user runs /analyze-reference <url> or asks to analyze, study, break down or extract patterns from an inspiration or reference site for a landing. Checks robots.txt and text-and-data-mining reservations first and aborts if access is disallowed. Not for cloning or rebuilding a site.

williamsnieves/landing-factory

Use when the user wants to design, redesign, shape, critique, audit, polish, simplify, harden, animate, or otherwise improve a frontend interface: websites, landing pages, dashboards, product UI, components, forms, settings, onboarding, empty states, and native iOS or Android screens. Handles UX review, hierarchy, layout, typography, color, motion, UX copy, accessibility, responsive behavior, edge cases, and capturing or documenting design systems (DESIGN.md, tokens). Also for making bland UI bolder, loud UI quieter, or ambitious visual effects. Not for backend-only or non-UI tasks.

williamsnieves/landing-factory

Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks. Also use when the user says "openspec apply", "opsx apply", or "openspec implement".

williamsnieves/landing-factory

Archive a completed OpenSpec change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete. Also use when the user says "openspec archive" or "opsx archive".

관련 스킬