Motion Lexicon
Motion Lexicon은 제품 모션을 위한 디자인 시스템입니다. 이는 두 개의 동등한 컬렉션을 연결합니다: Motion Primitives는 정확한 동작을 설명하고, Components는 하나 이상의 동작을 완전하고 복사 가능한 제품 상호작용으로 전환합니다. 페이지 구성은 이러한 상호작용을 일관된 제품 표면 안에 배치합니다.
사용자의 제품 이벤트에서 디자인하세요. 명확한 상태 변경, 초점이 맞춰진 액터, 그리고 접근 가능한 핸드오프를 지원할 때만 코드를 생성하세요.
모드 선택
| 요청 신호 | 모드 | 산출물 |
|---|---|---|
| 완전한 페이지, 화면, 랜딩 페이지, 대시보드 또는 설정 표면 | 페이지 구축 | 페이지 계획, 정확한 레지스트리 구성, 작동하는 페이지 및 수용 증거 |
| 느낌, 용어 또는 "어떤 애니메이션" 질문 | 추천 | 순위가 매겨진 후보와 하나의 추천 |
| 워크플로, 전환 또는 여러 단계의 장면 | 구성 | 모션 청사진 및 비트 계획 |
| 프로덕션 코드 또는 프레임워크 적응 요청 | 구현 | 이식 가능한 HTML, CSS, JS 또는 요청된 프레임워크 코드 |
| 기존 코드, 녹화 또는 버벅거림 보고 | 검토 | 우선순위에 따른 진단 및 구체적인 수정 |
| 새로운 패턴, 예제 또는 제안된 라이브러리 추가 | 기여 | 유지 관리자 검토를 위한 준비된 후보 레코드 |
모드 우선순위를 결정적으로 적용하세요: 완전한 페이지 또는 다중 영역 표면은 페이지 구축을 사용하고, 코드 또는 하나의 상호작용에 대한 프레임워크 구현에 대한 명시적 요청은 구현을 사용하며, 디자인 계획, 비트 계획 또는 청사진에 대한 요청만 있는 경우 구성을 사용합니다. 구현은 내부적으로 청사진을 생성할 수 있으며 사용자가 요청한 실행 가능한 형식을 여전히 제공합니다. 검토 요청은 현재 상호작용에 더 큰 변경이 필요한 경우 수정된 청사진을 반환할 수 있습니다.
모든 요청 시작하기
- 사용자의 언어를 유지하세요. 중국어 요청에는 중국어를 사용하고, 영어 요청에는 영어를 사용하세요.
- 제품 작업, 기본 작업, 작업 전후의 사용자에게 보이는 상태, 기본 액터, 그리고 의도된 느낌을 식별하세요.
- 아래의 모드 × 참조 표를 사용하세요. 현재 작업에 선택된 파일만 로드하세요.
- 요청이 재질 깊이, 물리성 또는 Interior 시각적 프로필을 필요로 할 때 interior-principles.md를 로드하세요.
- 요청이 제품 컨텍스트를 열어둘 때 가정을 간략히 명시하세요. 누락된 제약 조건이 디자인을 변경할 때에만 하나의 초점 질문을 하세요.
- 비트(beat)에서 하나의 기본 시각적 액터와 최대 두 개의 보조 액터를 유지하세요. 각 액터에게 의미적 종류(trigger, hero, status, record 또는 environment)를 부여하세요. 각 비트에게 제품 목적(orient, confirm, preserve continuity, reveal 또는 recover)을 부여하세요.
- 구성, 구현 또는 검토된 모든 상호작용에 축소 모션 계획과 키보드/포커스 동작을 포함하세요.
- 페이지 요청의 경우, 스택을 선택하기 전에 호스트 프로젝트를 검사하세요. 라우팅, 컴포넌트 시스템, 디자인 토큰 및 콘텐츠 언어를 유지하세요. 사용자가 다른 스택을 요청하지 않는 한, 그린필드 페이지에는 React와 TypeScript를 사용하세요.
모드 × 참조 라우팅
| 모드 또는 작업 | 읽기 | 관련된 경우에만 추가 |
|---|---|---|
| 페이지 구축 | page-composition.md, page-system.md 및 components.md | 호스트에 확립된 시각적 시스템이 없는 경우 motion-lexicon-page.css; 페이지의 기본 상태 변경에 대한 하나의 모멘트 또는 프리미티브 참조 |
| 게시된 컴포넌트 추천 | components.md | 사용자가 모션 작동 방식을 물을 때 아래의 하나의 프리미티브 패밀리 |
| 하나의 동작 추천 | motion-language.md | entrances, feedback, transitions 또는 sequencing |
| 제품 모멘트 구성 | composition.md 및 contract.md | feedback moment, choice moment, change moment 또는 workflow moment |
| 구현 | implementation-css.md | 청사진을 사용하거나 생성할 때 contract.md; 정확한 게시된 컴포넌트의 경우 components.md |
| 검토 | review-rubric.md | 관찰된 동작과 일치하는 하나의 프리미티브 또는 모멘트 참조 |
| 기여 | contribution.md 및 candidate-template.md | 필요한 청사진에 대한 contract.md 및 기존 컴포넌트를 배제하기 위한 components.md |
모션 언어
스킬 전체에 걸쳐 Interior 기반 프로필을 사용하세요:
- 재질 깊이가 방향에 도움이 될 때 베젤(bezel), 양각 패널(raised panel) 및 음각 웰(recessed well)로 실제 제품 상태를 모델링하세요.
- 이벤트(누르기, 선택, 경로 변경, 상태 업데이트 또는 직접 조작)에서 모션을 시작하세요.
- 레이블, 버튼 및 레코드가 기하학을 유지할 수 있도록 상태 변경을 위한 공간을 확보하세요.
- 새로운 컨텍스트에는 도착 모션(arrival motion)을 사용하세요: 약 200–280ms 동안
cubic-bezier(.23, 1, .32, 1). 제거된 컨텍스트에는 떠나는 모션(leaving motion)을 사용하세요: 약 110–180ms 동안cubic-bezier(.23, 1, .32, 1). - 움직이는 작업에는
transform및opacity를 사용하세요. 피드백이 즉각적인 응답을 필요로 할 때는 짧은 색상 또는 포커스 전환을 사용하세요. - 두 번째 사용자 작업이 첫 번째 작업을 중단, 반전 또는 안정시키도록 하세요.
- 축소 모션에서는 정적 상태 또는 짧은 불투명도 크로스페이드를 통해 상태, 계층, 포커스 및 피드백을 유지하세요.
자세한 규칙은 interior-principles.md에서 읽으세요.
페이지 구축
사용자의 프로젝트에 완전하고 실행 가능한 제품 표면을 구축하세요. 페이지를 계획하기 전에 page-composition.md, page-system.md 및 components.md를 읽으세요.
- 대상 저장소, 프레임워크, 경로, 기존 토큰 및 설치된 종속성을 검사하세요. 일관된 경우 호스트 시스템을 재사용하세요.
- 파일을 편집하기 전에 아래 표시된 호스트 검사 테이블과 간결한 페이지 계획을 출력하세요. 페이지 작업 및 아키텍처, 모든 주요 영역, 정확한 게시된 컴포넌트 ID 또는
none, 기본 상태 경계, 반응형 및 테마 결정을 포함하세요. 모든 호스트 검사 값은 검사된 파일 경로를 인용합니다. 산문 구현 의도는 이 게이트를 충족하지 않습니다. - 게시된 컴포넌트의 경우
https://motion-lexicon.pages.dev/r/<id>.json의 소스를 사용하세요. 편집하기 전에files,dependencies및runtime을 읽으세요. 전달된 소스 및 종속성을 설치하세요. props, 레이블, 데이터, 콜백 및 호스트 배치만 조정하세요. 동일한 컴포넌트의 근사치를 다시 생성하지 마세요. - ID를 선택하기 전에 레지스트리 통합 게이트를 완료하세요. 모든 현재 레지스트리 소스는 Tailwind 유틸리티 클래스를 사용합니다. 호스트가 이미 Tailwind를 컴파일하는지 확인하거나, 호스트 툴체인 변경이 범위 내에 있는 경우 지원되는 Tailwind 설정을 추가하세요. 해당 설정을 추가할 수 없는 경우 영역에 대해
none을 선택하고 일반 의미론적 UI를 구축하세요. 레지스트리 컴포넌트의 CSS 재구현을 조용히 붙여넣지 마세요. 페이지 계획에 JSON URL, 대상 파일, 종속성 목록 및 필요한 런타임을 기록하세요. - 통합 후 렌더링된 대화형 노드를 감사하세요. 페이지 표준은 레지스트리 컴포넌트의 기본 시각적 높이가 더 작더라도 최소 44 x 44 CSS px입니다. 문서화된
classNameprop을 통해 호스트 클래스를 전달하고 해당 노드에min-width및min-height를 설정하세요. 소스가 안전한 스타일링 훅을 제공하지 않으면 적합한 컴포넌트를 선택하거나 영역을 일반 상태로 두세요. - 페이지에 하나의 지배적인 작업 표면, 하나의 기본 모션 모멘트 및 최대 두 개의 보조 모션 모멘트를 제공하세요. 정적 콘텐츠를 차분하게 유지하세요.
- 호스트 디자인 시스템을 사용하세요. 그린필드 표면의 경우 motion-lexicon-page.css를 복사 및 적응한 다음 page-system.md의 정확한 계층 및 반응형 규칙을 적용하세요.
- 전체 경로 또는 페이지를 전달하세요. 여기에는 로딩, 비어 있음, 성공, 실패 및 복구 상태를 포함한 현실적인 콘텐츠가 포함되어야 합니다.
- 320, 390, 768 및 1440px 레이아웃, 밝은 테마 및 어두운 테마, 키보드 순서 및 포커스, 축소 모션, 44px 대화형 대상, 오버플로 및 콘솔 또는 하이드레이션 오류를 확인하세요. 빌드 성공만으로는 페이지 수용이 충족되지 않습니다. 로컬 앱 또는 프로덕션 미리보기를 시작하고 사용 가능한 브라우저 자동화를 사용하여 기본 작업을 실행하고 필요한 모든 뷰포트에서 렌더링된 지오메트리를 검사하세요. 프로젝트 브라우저 테스트 스크립트가 없는 것은 차단 요인이 아닙니다. 로컬 미리보기에 대해 사용 가능한 브라우저 도구를 사용하세요. 각 뷰포트에서 모든 보이는
button, 링크,input,select,textarea및 사용자 정의 대화형 노드를 열거하고 최소 렌더링된 너비와 높이 및 두 차원 중 하나에서 44px 미만의 노드에 대한offenders목록을 기록하세요. 모든 위반자를 수정하고 수용을 보고하기 전에 네 개의 뷰포트 감사를 모두 다시 실행하세요. 명령, 상호작용, 측정 및 관찰 가능한 결과를 보고하세요.
페이지 계획을 간결하게 유지하세요:
## 호스트 검사
| 항목 | 관찰된 호스트 증거 |
| --- | --- |
| 프레임워크 | 이름/버전 — `package.json` |
| 경로 | 현재 경로 및 대상 파일 — `src/router.tsx` |
| 컴포넌트 시스템 | 재사용된 컴포넌트 또는 없음 — `src/components/...` |
| 토큰 / 테마 | 토큰 및 테마 메커니즘 — `src/styles.css` |
| Tailwind | 설치됨/컴파일됨 또는 없음 — `package.json`, `vite.config.ts` |
| 종속성 | 재사용된 패키지 및 버전 — `package.json` |
## 페이지 계획
작업: …
아키텍처: …
기본 작업: …
기본 상태: idle → pending → success/error
| 영역 | 제품 목적 | 게시된 컴포넌트 | 상태 또는 모션 |
| --- | --- | --- | --- |
| … | … | `component-id` 또는 `none` | … |
레지스트리:
- `component-id` — https://motion-lexicon.pages.dev/r/component-id.json —
`target/file.tsx` — 종속성: `package` / 없음
반응형: 320/390 …; 768 …; 1440 …
테마: 밝음 …; 어두움 …; 축소 모션 …
이 계획의 모든 줄이 구체적이 될 때까지 구현을 시작하지 마세요.
최종 핸드오프는 중간 메시지가 접혀진 후에도 독립적으로 감사 가능해야 합니다. 완전한 호스트 검사 테이블과 페이지 계획(영역 테이블 및 레지스트리 줄 포함)을 반복한 다음, 아래 각 항목에 대해 하나의 관찰된 행이 있는 수용 테이블을 추가하세요:
| 확인 | 관찰된 증거 |
| --- | --- |
| 빌드 | 명령 및 종료 결과 |
| 320 | 뷰포트/문서 너비, 최소 대상 너비/높이, 위반자 수 |
| 390 | 뷰포트/문서 너비, 최소 대상 너비/높이, 위반자 수 |
| 768 | 뷰포트/문서 너비, 최소 대상 너비/높이, 위반자 수 |
| 1440 | 뷰포트/문서 너비, 최소 대상 너비/높이, 위반자 수 |
| 밝음 / 어두움 | 각 테마가 활성화되고 검사된 방법 |
| 키보드 / 포커스 | 정확한 키 경로, 포커스 진입 및 포커스 복귀 |
| 축소 모션 | 에뮬레이트된 선호도 및 관찰된 정적 또는 크로스페이드 결과 |
| 대상 | 보이는 대화형 노드의 측정된 최소 너비 및 높이 |
| 기본 상태 | 적용되는 pending, success, error/retry 및 중단 상태가 실행됨 |
| 런타임 | 콘솔, 페이지, 요청 및 하이드레이션 오류 수 |
설치된 컴포넌트 ID와 변경된 파일의 이름을 지정하세요. 관찰되지 않은 행에는 Incomplete를 사용하고 누락된 기능을 명시하세요. 관찰되지 않은 확인을 지원 또는 통과로 설명하지 마세요.
사용자가 Motion Lexicon 모양을 요청할 때, 콘텐츠 및 정보 아키텍처를 실제 제품에 적응시키면서 시각적 프로필 및 상호작용 품질을 유지하세요. 라이브러리 데모로 페이지를 채우지 마세요.
추천
사용자가 즉시 적용할 수 있는 간결한 결정을 반환하세요.
- 요청을 components.md의 최대 세 개의 게시된 후보 또는 위에서 선택한 하나의 관련 프리미티브 참조에 매핑하세요. 각 후보 셀을 정확한 게시된 컴포넌트 또는 프리미티브 ID(백틱으로 묶음)로 시작하고, 유용한 경우 사람이 읽을 수 있는 레이블을 추가하세요. 설명적인 레이블만으로는 불완전합니다. 알 수 없거나 발명된 ID를 게시된 것으로 제시하지 마세요.
- 제품 용어(공간 연속성, 무게, 페이싱, 주의 또는 상태 신뢰도)로 시각적 차이를 설명하세요.
- 하나의 후보를 선택하고, Pick 라인에서 정확한 게시된 ID를 반복하며, 기본 타이밍, 이징, 트리거 및 축소 모션 처리를 명시하세요.
- 요청이 여러 상태를 설명하는 경우 모션 청사진을 제공하세요.
이 형식을 사용하세요:
## 建议 / 추천
| 후보 / Candidate | 적합한 시나리오 / Fit | 차이점 / Difference |
| --- | --- | --- |
| `published-id` / … | … | … |
**추천 / Pick:** `published-id` / …
- 트리거 / Trigger: …
- 타이밍 / Timing: …
- 접근성 / Accessibility: …
구성
구현 세부 사항으로 확장하기 전에 모션 청사진을 생성하세요. 계약으로 assets/motion-blueprint.schema.json을 사용하세요. 모든 구성 응답에는 하나의 스키마 유효한 펜스 처리된 JSON 객체가 포함됩니다. 청사진을 산문 표나 텍스트 다이어그램으로 대체하지 마세요. 채팅에서 문자열 값을 간결하게 유지한 다음 사용자가 재사용 가능한 아티팩트를 요청할 때 동일한 JSON을 파일에 작성하세요.
모든 beats[].primitive 및 모든 provenance.foundations[] 값은 선택된 참조에서 복사된 정확한 게시된 프리미티브 ID여야 합니다. 사람이 읽을 수 있는 레이블 및 게시되지 않은 의사 ID는 청사진 계약을 충족하지 않습니다.
응답하기 전에 최종 JSON을 임시 파일에 작성하고 다음을 실행하세요:
node "$CODEX_HOME/skills/motion-lexicon/scripts/validate-motion-blueprint.mjs" /tmp/blueprint.json
모든 유효성 검사 실패를 수정하고 명령이 0으로 종료될 때까지 다시 실행하세요. 펜스 처리된 JSON 바이트-
… [번역 생략됨]