kennedys0/taste-engine

Taste Engine — 스타일 라우터

하나의 보편적인 프로세스, 다양한 독립적인 취향 — 안티-슬롭, 조건부 공개 SEO 및 선택적 스타일 정렬 모션 포함. Taste Engine은 언제 질문할지, 어떤 선택된 스타일 팩을 로드할지, 그리고 이를 어떻게 강제할지 제어합니다. 엔진 자체에는 고정된 미학이 없습니다. styles/*.md에 있는 스타일 팩에는 실제 디자인 지침이 포함되어 있습니다.

재질 충실도 (선택된 스타일) — 스크린샷 수준 계약

선택된 시각적 미학은 렌더링된 인터페이스에서 식별 가능해야 하며, 단지 제목이나 CSS 변수 이름에만 명시되어서는 안 됩니다. glassmorphism이 선택되면 styles/glassmorphism.md를 로드하고 필수 유리 재질 충실도 게이트를 적용합니다: 차별화된 배경광을 필터링하는 실제로 눈에 띄게 서리 낀/반투명한 창, 읽을 수 있는 반사/모서리, 접근 가능한 대체 스타일. 평평한 네이비 히어로와 파란색 CTA는 글래스모피즘이 아닙니다. 승인 검사에는 tests/glassmorphism-visual.md를 사용하고, 시작 레시피로 examples/glassmorphism/frosted-surfaces.css를 사용하십시오. 이 유리 특정 검사를 다른 스타일에 적용하지 마십시오. 모든 미학은 자체 요구 사항을 유지합니다.

글래스모피즘 특정 그라데이션 예외

글래스모피즘이 선택되면, 목적성 있는 CSS 그라데이션 배경, 주변광 필드 및 제어된 부드러운 컬러 형태가 명시적으로 허용됩니다. 이는 반투명 프로스팅과 깊이를 보이게 만들기 때문입니다. 일반적인 안티-슬롭 그라데이션 경고를 충족시키기 위해 이를 제거하지 마십시오. styles/glassmorphism.md("명시적 배경 그라데이션 예외")를 읽고 첫 번째 뷰포트가 차별화된 배경을 필터링하는 실제 창을 보여주는지 검증하십시오. 이 면제는 선택된 재질에만 적용되며 유용성, 진실성, 접근성 또는 사용자 제약 조건을 절대 무시하지 않습니다.

자동 호출: 제로-명령 계약

• 이는 슬래시-명령 전용 워크플로가 아닌, 작업 트리거 스킬입니다. 자율 에이전트 스킬을 지원하는 설치된 에이전트는 포트폴리오, 웹사이트, 앱, 대시보드, 랜딩 페이지 및 UI 재디자인 요청 시 위 메타데이터를 발견해야 합니다 — 사용자가 "taste-engine"이라고 말하지 않더라도 마찬가지입니다.
• 호출되면, UI 코드 전에 자동 호출 계약을 적용하십시오. 실제 플랫폼이 스킬이 호출되는지 여부를 결정합니다. 이 파일은 OS 수준의 훅을 생성하거나 모든 호스트에서 준수를 보장할 수 없습니다.
• 암시적 스타일 선택: "포트폴리오 웹사이트를 만들어 줘" → 하나의 간결한 스타일 질문을 한 다음 턴을 종료하십시오. 같은 턴에 사용자에게 관련 없는 세부 사항을 묻지 마십시오.
• 명시적 스타일 선택: "스큐오모피즘 스타일로 포트폴리오 웹사이트를 만들어 줘" → 오타를 skeuomorphism으로 정규화하고, styles/skeuomorphism.md를 읽고 구축하십시오. 질문 메뉴를 실행하지 마십시오.
• 기존 프로젝트: 승인된 프로젝트 구성 또는 문서화된 브랜드/스타일은 점진적 작업에 대해 일반 기본값보다 우선합니다. 메뉴로 중단하지 마십시오.
• 프론트엔드 작업 아님: API 구현, 비즈니스 로직 디버깅, 데이터베이스 마이그레이션, 인프라, 작성 전용 작업 → 스타일 선택기를 실행하지 마십시오.

엔지니어링 컴패니언 — 조건부 및 프레임워크 인식

시각적 스타일 질문이 해결되거나(기존 시스템/비시각적 작업의 경우 건너뜀) 엔지니어링 라우터를 적용하십시오. 모든 웹 UI는 보편적인 웹 인터페이스 품질 게이트를 받습니다. React/Next는 React 성능과 선택적으로 React 구성을 스택과 작업이 정당화할 때만 받습니다. React Native/Expo 작업은 웹 SEO가 아닌 네이티브 모바일을 받습니다. 탐색 모션은 호환성 검사 후 뷰 전환을 사용하거나, 정말 유용할 때 선택적으로 Anime.js를 사용할 수 있습니다. 문서 작성 작업은 시각적 스타일 선택기 없이 문서 작성을 받습니다.

이는 가져온 Vercel 플러그인이 아닌 로컬 오리지널 통합입니다. 업스트림 연구에서 배운 엔지니어링 관행을 요약합니다. 업스트림 스킬이 설치되었다고 가정하지 말고, React를 요구하지 말며, 명시적인 배포 의도 없이 배포하지 말고, 기술 지침이 사용자의 미학을 덮어쓰지 않도록 하십시오. 핵심 사전 점검, 전체 화면 히어로, SEO, 안티-슬롭 및 스타일 인식 모션은 변경되지 않습니다. 엔지니어링 라우팅 테스트를 참조하십시오.

전체 화면 히어로 — 관련 시 필수

스타일 선택 후, 새로운 공개 포트폴리오, 랜딩 페이지 또는 히어로가 포함된 홈페이지의 경우, 전체 화면 히어로 계약을 로드하십시오. 하나의 보이는 화면 헤더 + 히어로 구성을 기본값으로 사용하십시오: 모바일 안전 min-height: 100svh (100vh 폴백 포함)를 사용하고 실제 일반 흐름 헤더 높이를 빼거나, 헤더가 오버레이될 때 전체 높이 히어로를 사용하십시오. 100vh를 맹목적으로 적용하지 마십시오: 고정 높이는 텍스트를 잘라내고 도구 모음이 변경된 모바일 뷰포트를 초래할 수 있습니다. 콘텐츠와 CTA가 좁은/짧은 화면에서 사용 가능하도록 유지하고, 확대/큰 텍스트에서 자연스러운 성장과 스크롤을 허용하십시오. 선택된 스타일의 ## 히어로 구성 (첫 번째 전체 뷰포트) 지침과 공유된 안티-슬롭 검사를 따르십시오. 화면을 채우기 위해 이미지, 배지, 가짜 통계 또는 반복 모션을 만들어 내지 마십시오.

이 규칙은 비공개 대시보드, 양식, 앱 작업 공간 또는 히어로를 생성/재디자인하지 않는 증분 편집에 마케팅 히어로를 강제하지 않습니다. 컴팩트 히어로 또는 히어로 없음에 대한 명시적인 사용자 선택이 우선합니다. 스타일이 이미 설정된 경우 추가 스타일 선택 질문이 필요하지 않습니다.

Anime.js v4 모션 엔진 — 선택적 및 스타일 인식

명시적인 UI 마이크로 인터랙션 요청의 경우, 또는 추가 모션이 진정으로 이점이 있는 선택된 스타일을 구축할 때, 모션 엔진 어댑터와 선택된 스타일의 ## 모션 지침을 로드하십시오. 모션은 새로운 미학 선택기가 되지 않으며, 두 번째 인터뷰를 요구하지 않습니다. 이 대시보드에 마이크로 인터랙션 추가와 같은 요청은 기존 프로젝트 스타일을 유지하고 스타일 질문 없이 작동합니다. 프로젝트에 선택된 디자인 언어가 없고 사용자가 새 UI를 구축하는 경우, 원래의 한 질문 사전 점검은 필수로 유지됩니다.

자동 종속성 설치가 없습니다. 먼저 기존 스택을 검사하십시오. 간단한 전환에는 CSS/네이티브 브라우저 기능을 선호하십시오. 조정된 모션을 의미 있게 단순화하거나 명시적으로 요청된 경우에만 Anime.js v4를 고려하십시오. React/Next의 경우 createScope() + 라이프사이클 정리를 사용하십시오. 감소된 모션을 선호하는 사용자의 경우 비필수 효과를 비활성화하면서 상호 작용은 기능적으로 유지하십시오. 바운스, 루프 또는 불필요한 스태거를 강제하지 마십시오. 스타일 매핑은 styles/motion-profiles.json에 있습니다. React 레시피는 examples/react/anime-v4-press.jsx에 있습니다. 비웹/네이티브 앱은 대신 플랫폼 모션 API를 사용해야 합니다.

크로스 스타일 SEO: 자동 및 조건부

SEO는 스타일 선택이 아닙니다. 새롭거나 실질적으로 재설계된 공개 웹사이트(포트폴리오, 랜딩 페이지, 블로그, 공개 비즈니스 웹사이트, 공개 문서 또는 공개 제품 페이지)의 경우, SEO 통합과 필요 시 SEO 구현 레시피를 시각적 스타일 선택 후 로드하십시오. 모든 선택된 스타일에 기술 SEO + 안티-슬롭 콘텐츠를 적용하되, 두 번째 질문으로 "SEO를 원하십니까?"라고 묻지 마십시오. SEO는 선택된 재질 미학을 절대 변경하지 않습니다.

• 명시적 스타일: 스큐오모피즘 포트폴리오 구축 → styles/skeuomorphism.md + references/seo.md를 읽고, 스타일 질문 없이 구현하십시오.
• 누락된 스타일: 포트폴리오 웹사이트 구축 → 정확히 하나의 스타일 질문을 하고 중단하십시오. 답변 후, 스타일 + SEO를 로드하고 구현하십시오. 메타데이터를 작성하기 위해 사전 점검을 우회하지 마십시오.
• SEO 전용: 내 웹사이트 SEO 감사 / 표준 URL 및 사이트맵 수정 → SEO 모듈을 즉시 읽고, 시각적 스타일 인터뷰 없이 요청하지 않은 재설계도 하지 마십시오.
• 비공개/내부 애플리케이션: 기밀성과 기존 색인 가능성을 유지하십시오. 공개 사이트맵을 생성하거나 비공개 경로를 노출하지 마십시오. 네이티브 모바일/백엔드 전용 작업은 일반 웹 SEO 범위를 벗어납니다.
• 알 수 없는 도메인: 라이브 URL, 저자, 구조화된 데이터, 리뷰 또는 페이지 콘텐츠를 조작하지 마십시오. 안전하게 시맨틱/제목을 구현하고 무엇이 보류 중인지 보고하십시오.

SEO와 스타일은 FLOOR / REFLEX / FINISH 게이트를 공유합니다. 개인정보 보호, 진실된 콘텐츠, 접근성 및 기능적 동작이 미학 및 검색 선호도를 능가합니다. SEO 수용 시나리오를 참조하십시오. 선택적 독립형 taste-seo 스킬은 SEO 전용 설치를 위한 것입니다. 라우터 사용자는 별도로 설치할 필요가 없습니다.

하드 요구 사항: 새로운 시각적 구현 전 사전 점검

시각적 UI를 도입하거나 실질적으로 재설계하는 작업의 경우, 시각적 방향이 해결될 때까지 UI 코드를 작성하거나, 인터페이스 목업을 생성하거나, 디자인 토큰을 변경하지 마십시오.

1. 현재 사용자 요청, 기존 제품 브랜드/디자인 시스템 및 명시적으로 승인된 프로젝트 스타일 구성을 검토하십시오.
2. 스타일이 이미 명시적으로 선택된 경우(예: "브루탈리스트 대시보드"), 다시 묻지 마십시오. 유용하다면 짧은 한 줄로 확인하고 해당 스타일 팩을 로드하십시오.
3. 기존 프로젝트에 명확히 설정된 스타일이 있고 사용자가 증분 변경을 요청하는 경우, 이를 유지하십시오. 새로운 선택으로 중단하지 마십시오. 재설계 요청은 설정된 스타일을 재정의할 수 있습니다.
4. 그렇지 않은 경우, 정확히 하나의 간결한 스타일 선택 질문을 하고 중단하십시오. 6가지 대비되는 선택지와 "더 많은 스타일 / 커스텀 / 참조 보내기"를 제공하십시오. 스타일을 묵시적으로 선택하거나, 응답을 기다리는 동안 코딩을 시작하거나, 다중 질문 인터뷰를 하지 마십시오.
5. 사용자가 답변하면, 레지스트리를 통해 스타일 ID를 확인하고, 선택된 팩만 읽고, 프로젝트별 토큰/결정을 도출한 다음 실행하십시오. 사용자가 제공한 형용사 또는 참조는 사전 설정을 강제하는 대신 스타일 특성을 해석해야 할 수 있습니다.
6. 도구 실행기가 사용자 입력을 위해 일시 중지할 수 없는 경우, 해결되지 않은 선택을 보고하고 동의를 조작하지 마십시오. 자율적 최선 노력 기본값을 사용하라는 명시적 지침은 임시 스타일을 승인할 수 있습니다. 이를 임시적이고 되돌릴 수 있는 것으로 표시하십시오.

필수 첫 번째 질문 (인도네시아어 예)

디자인을 시작하기 전에, 어떤 시각적 스타일을 원하시나요?

1. Claymorphism — 부드럽고, 촉각적이며, 미묘한 깊이감
2. Glassmorphism — 투명하고, 레이어드되며, 현대적인
3. Brutalism — 대담한 타이포그래피, 날것의 그리드, 높은 대비
4. Neo-brutalism — 대담한 색상, 테두리와 하드 섀도우
5. Minimalism — 깔끔하고, 단순하며, 콘텐츠 중심
6. Swiss / Editorial — 정밀한 그리드, 지배적인 타이포그래피 또는 기타, 커스텀을 입력하거나 참조를 보내주세요.

사용자 언어에 맞게 조정하십시오. 단일 질문으로 유지하십시오. 하나를 "최고"라고 선언하지 않고 차이점을 설명하십시오. 긴 메뉴의 경우, 먼저 여섯 가지와 나머지 옵션을 볼 수 있는 방법을 제시하십시오. 사용자가 예제를 원하면, 선택하기 전에 옵션을 보여주십시오. 사용자가 대화형 선택기를 요청하고 에이전트가 지원하는 경우, 동일한 선택 항목을 UI 컨트롤로 제시하십시오.

사용 가능한 스타일 팩

ID, 별칭, 일반적인 철자 오류 및 설명을 일치시킬 때 styles/registry.json을 읽으십시오. 구두점, 하이픈 및 대소문자를 정규화하고, 부정된 스타일 언급("glassmorphism 아님") 및 컨텍스트를 존중하십시오. 가능한 경우 python3 scripts/style_probe.py --prompt "..."는 결정론적 스타일 힌트를 제공할 수 있습니다. 그러나 의미론적 해석 및 프로젝트 컨텍스트가 여전히 우선합니다. 이름으로 독립형 스타일 스킬을 호출하지 마십시오. 선택된 로컬 styles/<id>.md 파일을 읽으십시오. 이는 이 설치된 라우터의 일부입니다. 내장 팩:

ID	방향	선택 시 로드할 파일
claymorphism	조각된 촉각적	스타일 팩
glassmorphism	반투명 레이어드	스타일 팩
brutalism	날것의 구조적	스타일 팩
neo-brutalism	장난기 넘치고 대담한	스타일 팩
minimalism	절제된 명료함	스타일 팩
swiss-editorial	타이포그래픽 그리드	스타일 팩
bento	모듈식 타일	스타일 팩
skeuomorphism	물리적 제어 은유	스타일 팩
retro-terminal	콘솔 미학	스타일 팩
enterprise	워크플로/데이터 우선	스타일 팩

커스텀은 일급 시민입니다. 선택된 미학이 레지스트리에 없으면, 짧은 참조 또는 제약 조건을 수집한 다음 동일한 차원을 사용하여 임시 프로젝트별 스타일 정의를 만드십시오. 존재하지 않는 팩으로 스타일을 잘못 레이블링하지 마십시오. 선택을 위해 외부 인터넷 액세스를 요구하지 마십시오.

라우터 상태

• needs-selection: 새로운 시각적 작업. 선택/확인된 방향 없음. 스타일 질문을 하고 중단하십시오.
• ready: 스타일 또는 기존 브랜드가 명시적으로 설정됨. 관련 팩을 로드하고 구현하십시오.
• refine: 기존 UI의 작은 변경. 스타일을 유지하고, 필요한 토큰/컴포넌트만 수정하십시오.
• custom: 사용자가 혼합을 선택하거나, 스크린샷을 제공하거나, 지정되지 않은 스타일을 요청함. 동일한 디자인 차원에 매핑하고 중대한 모호성만 확인하십시오.
• non-visual: 백엔드, 테스트, 문서, 시각적 결정이 없는 버그 수정. 디자인 선택을 완전히 건너뛰십시오.

자세한 라우팅, 혼합 및 충돌 규칙은 스타일 라우터를 참조하십시오. 자율 발견, 스타일 별칭, 호스트 제한 및 정확한 예제 대화록은 자동 호출을 참조하십시오.

선택 후 스타일 적용

1. 요구 사항 추출: 제품, 대상, 기기, 프레임워크, 기존 브랜드, 명시적 좋아요/싫어요, 접근성, 성능.
2. 선택된 팩만 로드 (필요에 따라 공유 참조 포함). 선택되지 않은 팩의 임의 규칙을 혼합하지 마십시오.
   • 스타일 ≠ 구조: 선택된 팩이 시각적 재질을 결정하는 동안, 실제 사용자 목표에서 제품 흐름 및 페이지 콘텐츠를 도출하십시오. 코딩 전에...