UIUX 프로토타입
실제 작업을 중심으로 제품 인터페이스를 설계하세요. 애플리케이션 구현 전에 검토 가능한 HTML을 제공하세요. 사용자의 언어로 작업하며, 기본적으로 한국어 설명을 사용하되 필요한 영어 용어는 병기합니다. 이 스킬은 자체 완결적입니다. 상위 스킬과 유료 참조 서비스는 선택 사항이며 의존성이 아닙니다.
1. 제품 확립 및 기준선 보존
먼저 해당하는 AGENTS.md, HANDOFF.md, 기존 DESIGN.md 및 현재 프로토타입 파일을 읽으세요. 사용자, 시나리오, 진입점, 주요 작업, 결과, 비즈니스 가치, 요청된 화면 및 이번 버전의 범위를 식별하세요. 기존 브랜드 결정과 다른 사람의 편집 내용을 보존하세요. 일상적인 세부 사항은 스스로 해결하고, 디자인을 실질적으로 변경하는 누락된 정보에 대해서만 질문하세요.
브리핑에서 화면/플로우 목록을 임의의 페이지 수가 아닌 범위 내에서 합의하세요. 요청된 각 화면(웹, 미니 프로그램, 모바일, 데스크톱)을 다루되, 관련 없는 앱을 임의로 만들지 마세요. 화면 범위를 알 수 없고 프로젝트에서 이를 설정할 수 없는 경우, 진행 전에 한 번 질문하세요. 기존 UI를 상속받은 경우, 감사(audit)를 수행하고 덮어쓰지 않는 버전을 제공하며, 요청받지 않은 리디자인을 하지 마세요.
source-synthesis.md의 관련 의사결정 규칙 섹션(§1–7)을 읽고, 트레이드오프 설명이 필요할 때는 소스 맵(§8–10)을 사용하세요. 이 파일은 7개의 모든 소스 저장소를 통합합니다. 제품 작업 명확성, 기존 디자인 계약 및 사용자 선택이 랜딩 페이지 규칙, 스타일 금지 및 임의 테마보다 우선합니다.
2. 참조 조사 후 중단: 스타일 결정 대기
reference-research.md를 읽으세요. Dribbble부터 시작하고, Behance와 即时设计을 대체 또는 보충 자료로 사용하세요. 단순히 "예쁜 UI"가 아닌, 제품 카테고리, 사용자 작업 및 관련 플랫폼을 검색하세요. 사용 가능한 브라우저/검색 도구를 사용하고, 실제로 검사한 페이지와 이미지를 기록하세요. 검색 스니펫을 시각 검토라고 부르지 마세요. 접근 제한을 준수하고, 실제 사례를 볼 수 없는 경우 이를 보고하고 참조 자료 제공 또는 명시적 조사 면제를 요청하세요.
docs/prototype/versions/vX.Y.Z/(또는 프로젝트의 기존 프로토타입 루트) 아래에 새 버전을 만드세요. 아래 CLI를 사용하여 안전하게 시작하세요. 먼저 style-reference.html을 작성하세요. 일반적으로 2~3개의 차별화되고 작업에 적합한 방향, 실제 사례 링크/제작자, 관찰된 증거와 해석, 토큰 샘플 및 비교를 위한 동일한 작업의 원본 소규모 UI 연구를 포함하세요. 플랫폼 적합성, 제한 사항 및 권장 사항을 포함하세요. 알려진 브랜드 선택을 보존하고, 사용자가 이미 한 방향을 제시한 경우 대안을 강요하지 말고 검증하세요.
실제 style-reference HTML을 제공하고 사용자가 선택하거나 수정하도록 요청하세요. 여기서 멈추세요. 사용자가 명명된 방향을 명시적으로 승인(또는 현재 작업에서 해당 정확한 선택을 위임)할 때까지 전체 앱 화면, design-system.html 또는 최종 DESIGN.md를 만들지 마세요. 로컬에서 선택된 라디오/카드, 선호하는 권장 사항, 경과 시간 또는 CLI 기록은 사용자 승인이 아닙니다. 승인 증거를 승인된 HTML의 SHA-256과 함께 보관하세요. 해당 보드에 대한 실질적 변경은 새로운 결정이 필요합니다. 이 게이트를 이미 승인된 관련 없는 작업에 대해 다시 질문하는 권한으로 취급하지 마세요.
3. 승인 후 전체 HTML 프로토타입 구축
prototype-contract.md와 platforms-and-quality.md의 관련 섹션만 읽으세요. 사용자의 실제 결정을 기록하세요. 헬퍼가 증거를 기록하지만, 누가 결정을 내렸는지 검증할 수는 없습니다. 그런 다음 생성된 스캐폴드를 준비하고 설계된 작업 아티팩트로 대체하세요.
index.html: 버전, 화면 진입점, 핵심 플로우, 스타일 참조 및 시각 사양 링크가 있는 프로토타입 홈/내비게이션. 각 앱에는 자체 작업 중심 홈도 있습니다. 구현/상태 세부 정보는 제품 크롬(chrome)이 아닌 이 검토 허브에 유지하세요.design-system.html: 이 버전에서 사용된 컴포넌트에 대한 완전한 시각 사양: 의미론적 색상, 타이포그래피, 간격, 레이아웃/밀도, 아이콘, 화면, 해당 컴포넌트 상태, 상호작용/모션 및 반응형/플랫폼 차이점. 이름 표만이 아닌 실제 렌더링된 예제를 보여주세요.DESIGN.md: 표준 결정, 토큰 값, 화면/플로우 목록, 상호작용, 플랫폼 재정의, 접근성, 출처 및 알려진 프로토타입 제한 사항. 화면별 DESIGN.md는 관련 변형만 설명합니다.- 요청된 각 화면의 HTML: 합의된 중요 경로를 완전히 구현하고, 그럴듯한 라벨이 지정된 합성 데이터, 내비게이션 및 의미 있는 상태 변화를 포함하세요. 의미론적 토큰을 공유하고, 축소된 데스크톱 스크린샷이 아닌 플랫폼에 적합한 상호작용을 사용하세요.
기본적으로 시맨틱 HTML, CSS 변수 및 작은 로컬 스크립트를 사용하세요. 복잡성을 줄이는 경우 기존 프레임워크/컴포넌트를 재사용하고, React, Tailwind, shadcn 또는 네트워크 의존성을 강제하지 마세요. 정적 HTML 프로토타입은 로컬 HTTP 서버를 통해 열 수 있어야 하며, 가능하면 파일 URL로도 탐색 가능해야 합니다. 프로토타입 검토에 필요한 에셋은 로컬에 있고 라이선스가 있어야 합니다. 프로토타입을 애플리케이션 소스와 분리하여 유지하세요.
4. 검증, 버전 관리 및 전달
platforms-and-quality.md를 사용하여 좁은/넓은 뷰포트, 키보드 포커스, 확대/축소 및 모션 감소 상태에서 렌더링된 결과를 검토하고, 해당하는 장치/플랫폼 동작을 검사하세요. 실제 주요 경로와 빈 상태, 로딩, 오류, 성공 및 극단적 콘텐츠 상태 중 중요한 것을 테스트하세요. 브라우저 시뮬레이션으로 장치 또는 네이티브 SDK 승인을 단언하지 마세요. 발견된 문제를 수정하고 영향을 받은 경로를 다시 확인하세요.
구조적 검증을 실행한 후, 브라우저 증거, 뷰포트 크기, 테스트된 플로우 및 해결되지 않은 문제를 QA.md에 기록하세요. 구조적 검증만으로는 시각적 품질, 비즈니스 완전성, 권한 적용, 외부 통합 또는 프로덕션 준비 상태를 증명할 수 없습니다. 명시적으로 테스트되지 않은 항목을 보고하세요. 배포 작업의 경우, 기능적 검사만 보고하는 대신 관련 로딩/런타임/리소스 비용을 측정하세요. 일반적인 로컬 프로토타입은 프로덕션 벤치마크 제품군이 필요하지 않습니다.
이전 버전을 그대로 유지하세요. 승인 무효, 수정, 봉인된 스냅샷, 변경 로그 및 최신 버전 내비게이션에 대해서는 versioning.md를 읽으세요. 승인된 보드를 자동으로 편집하거나 이전 프로토타입을 덮어쓰지 마세요. 실제 파일 링크, 여는 방법, 검증된 내용 및 시뮬레이션된 상태를 전달하세요.
헬퍼 (Python 3, 표준 라이브러리)
<skill-dir>을 이 설치된 스킬의 디렉터리로 확인하세요. 명령어는 지정된 프로젝트에서만 작동하며, 애플리케이션 소스를 게시하거나 변경하지 않습니다.
python3 <skill-dir>/scripts/prototype.py init --project <project> --version v0.1.0 --surfaces web miniapp mobile desktop
# 실제 조사로 style-reference.html을 편집하고 사용자의 결정을 얻으세요.
python3 <skill-dir>/scripts/prototype.py record-approval --project <project> --version v0.1.0 --direction "B" --evidence "이 대화에서 나온 정확한 사용자 결정"
python3 <skill-dir>/scripts/prototype.py prepare --project <project> --version v0.1.0
# 모든 보류 중인 스캐폴드를 교체하고, 합의된 플로우를 구현하며, 렌더링/검토하세요.
python3 <skill-dir>/scripts/prototype.py validate --project <project> --version v0.1.0 --complete
python3 <skill-dir>/scripts/prototype.py seal --project <project> --version v0.1.0 --summary "범위 및 실질적 변경 검토 완료"
record-approval은 워크플로 레코드를 저장하지만, 신원 또는 보안 경계는 아닙니다. 증거를 절대 조작하지 마세요. prepare는 스캐폴드를 생성하며, 완성된 프로토타입이 아닙니다. seal은 파일 해시를 기록하며, 시각적 서명 또는 불변 저장소가 아닙니다. 매니페스트와 QA 증거를 함께 사용하세요.