Design Harness은(는) 무엇을 하나요?
하나의 재개 가능한 웹 UI 워크플로우를 실행합니다. 사용자가 의도를 제어하고 디자인 생산을 리뷰와 분리합니다.
시작 및 재개
<skill-dir>을 이 SKILL.md가 포함된 디렉토리로 확인하십시오. 현재 작업 디렉토리에 번들 스크립트가 있다고 가정하지 마십시오.
- 질문하기 전에
node <skill-dir>/scripts/preflight.mjs --root <project>를 실행하십시오. 해당 기능 보고서를 읽고 아무것도 설치하지 마십시오. 누락된 파일 시스템 경로는 정보 제공으로 간주하십시오. 호스트가 로드한 스킬/플러그인 인벤토리를 확인하여 Impeccable 또는 Jakub을 사용할 수 없는지 확인하십시오. node <skill-dir>/scripts/state.mjs init --root <project>를 실행하십시오. 이 명령은 변경(mutating) 명령이므로 레거시 상태를 안전하게 업그레이드합니다. 상태가 존재하는 경우 읽기 전용 명령인status를 실행하고 해당nextPhase에서 재개하며 완료된 단계를 다시 시작하지 마십시오. 재초기화 없이 레거시 실행을 확인하거나 업그레이드할 때는 명시적으로migrate를 사용하십시오.- 현재 단계에 필요한 참조만 읽으십시오:
- discovery/confirmation: references/interview.md
- context/direction: references/context-contract.md
- build/tool choices: references/routing.md
- optional source selection: references/optional-tool-registry.json, 활성화 조건이 확인된 후에만
- review/QA/handoff: references/review-and-qa.md
- 각 단계 완료 후
node <skill-dir>/scripts/state.mjs advance <phase> --root <project>로 상태를 진행하십시오.human-feedback의 경우--outcome used또는--outcome not-used를 추가로 전달하십시오.feedback-fixes의 경우--outcome applied또는--outcome not-applicable을 전달하십시오.
다음 고정 단조 순서를 사용하십시오:
preflight → discovery → confirmation → context → direction → build → internal-review → human-feedback → feedback-fixes → independent-review → fixes → qa → handoff → complete
기계 상태만 .design-harness/state.json에 저장하고 보고서와 스크린샷은 .design-harness/reports/에 저장하십시오. 전체 채팅 기록, 토큰, 쿠키, 자격 증명 또는 관련 없는 환경 데이터를 절대 저장하지 마십시오.
승인 게이트 적용
적응형으로 인터뷰하고 답변을 하나의 간결한 확인 카드로 요약하십시오. 제품, 대상, 주요 목표, 콘텐츠, 페이지/표면, 원하는 및 원하지 않는 특성, 긍정적 및 부정적 참조, 제약 조건, 모션, 필요한 상태, 스택, 위임, AI 관련 상태, WebGL 허용 오차, 외부 소스 정책 및 유료 라이선스 경계를 포함하십시오. 누락되거나 중요한 세부 사항에 대해서만 질문하십시오.
사용자가 확인 카드를 명시적으로 승인하기 전까지 UI 생산 코드를 작성, 편집 또는 생성하지 마십시오. 사전 점검, 질문, 읽기 전용 검사 및 확인 카드 또는 제안된 의도 콘텐츠의 채팅 내 초안은 허용됩니다. 승인 전까지 프로젝트 의도 .md 파일을 생성하거나 수정하지 마십시오.
참조가 없는 경우 설명 단어로 충분하다고 간주하십시오. 구체적인 트레이드오프가 있는 두세 가지 명명된 방향을 도출하고 사용자에게 선택을 요청하십시오. 시각적 도구가 존재하고 사용자에게 도움이 될 경우에만 시각적 보드를 생성하고 보드를 필수 조건으로 만들지 마십시오.
승인된 컨텍스트 생성
확인 후 사용자 답변 또는 사용자가 명시적으로 승인한 제안에서 다음 파일을 채우십시오:
PRODUCT.md, 승인된brand또는product레지스터 포함REFERENCES.mdDESIGN.mdACCEPTANCE.md- 적어도 하나의
.impeccable/surfaces/<slug>.md
PRODUCT, references, design, acceptance 및 surface 템플릿에서 구조를 복사하십시오. 사용자가 내용을 승인한 후에만 모든 의도 파일을 승인된 것으로 표시하십시오. 빌드 전에 node <skill-dir>/scripts/validate-context.mjs --root <project>를 실행하십시오.
DESIGN.md H2 섹션을 정확히 한 번씩 다음 순서로 유지하십시오: Overview, Colors, Typography, Elevation, Components, Do’s and Don’ts.
PRODUCT.md 및 DESIGN.md는 승인 후 보호된 것으로 간주하십시오. 이후 변경 사항에 대해 제안된 diff를 표시하고 명시적 승인을 요청한 후 적용하십시오. 무음으로 표류를 합리화하지 마십시오.
승인된 모든 외부 구성 요소, 레시피, 효과 또는 피드백 통합을 REFERENCES.md에 정확한 소스, 선택된 항목, 사용 가능한 경우 고정 버전 또는 커밋, 액세스 날짜, 의도된 목적, 현재 라이선스/약관 결과, 적응 및 필요한 대체 수단과 함께 기록하십시오. "외부 라이브러리 사용"은 특정 소스에 대한 승인이 아닙니다.
Impeccable을 통한 구축
설치된 Impeccable 스킬과 승인된 컨텍스트를 이 패스의 유일한 디자인 및 생산 권한으로 만드십시오. 해당 스킬 및 관련 도메인 참조를 로드한 다음 승인된 의도 파일과 표면을 제공하십시오. 발견을 반복하거나 승인된 의도를 재해석하도록 허용하지 마십시오. Impeccable이 .impeccable/design.json을 생성하거나 새로 고치도록 하십시오. 해당 사이드카를 수동으로 편집하지 말고 보호된 diff 및 승인 흐름 없이 결과 PRODUCT.md 또는 DESIGN.md 변경을 수락하지 마십시오.
동일한 생산 패스에서 다른 광범위한 취향 또는 디자인 시스템 스킬을 로드하지 마십시오. 좁은 도우미는 references/routing.md 아래에서만 라우팅하십시오. 승인된 컨텍스트가 변경을 승인하지 않는 한 기존 구성 요소 라이브러리와 스택을 유지하십시오. 선택적 레지스트리 항목을 자동 설치하거나 자동 복사하지 말고 정확한 제한된 사용을 설명하고 먼저 승인을 받으십시오.
구축 후 Impeccable 자체 검토를 실행하고 결과를 기록하십시오. 이것은 internal-review이며 독립 검토가 아닙니다. UI가 검사할 수 있을 정도로 안정되면 human-feedback을 입력하십시오. 승인된 Agentation 체크포인트가 유용할 때 제공하거나 Not used를 --outcome not-used로 기록하고 진행하십시오. Agentation을 기본적으로 개발 전용 및 수동/로컬로 유지하십시오. MCP, 웹훅 및 자동 해결은 별도의 명시적 승인이 필요합니다. feedback-fixes에서 조정된 사용자 주석만 적용하고 --outcome applied를 기록하십시오. 피드백을 건너뛴 경우 Not applicable을 --outcome not-applicable로 기록하고 편집 없이 진행하십시오. 독립 검토 전에 사용자 주석을 해결하십시오.
검토, 수정 및 QA 분리
independent-review를 위해 Jakub의 현재 better-interface 스킬과 여섯 개의 도메인 스킬을 사용하여 새 읽기 전용 하위 에이전트/컨텍스트를 시작하십시오. 스크린샷, 관련 구현 파일, 구성 요소 라이브러리 제약 조건 및 승인된 의도 문서를 제공하십시오. 구축 후 전체 검토를 요청하십시오. 검토자는 결과만 보고하고 편집하거나 무음으로 재설계하지 않아야 합니다.
모든 결과를 루트 컨텍스트에서 PRODUCT.md, DESIGN.md, 표면 사양, 수용 기준 및 구성 요소 라이브러리에 대해 판단하십시오. 수락/거부/연기 및 근거를 기록하십시오. 승인된 수정 사항을 생산 권한을 통해 별도로 적용한 다음 변경된 영역에 대한 집중된 빠른 읽기 전용 검토를 요청하십시오.
references/review-and-qa.md를 따르십시오. Impeccable 탐지기, Playwright 스크린샷(모바일/태블릿/데스크톱), axe 및 Lighthouse를 실행하십시오. 대표적인 경로와 적용 가능한 로딩, 빈, 오류, 긴 복사본, 호버, 포커스 및 축소 모션 상태를 다루십시오. 선택적 소스의 경우 해당 레지스트리 게이트(의미론적/정적 대체, WebGL 미동작, 승인된 브라우저, 모바일 CPU/GPU 또는 번들 예산, 해당되는 경우 개발 도구의 프로덕션 제외)도 실행하십시오. 지원되지 않거나 실행되지 않은 상태는 Not reviewed로 표시하고 통과된 것으로 보고하지 마십시오.
의미 있는 문서 스크롤 모션이 있는 인터페이스 또는 비디오/데모 준비를 위해 전용 로컬 포트에서 새 프로덕션 빌드를 시작하고 스캐폴드된 구성을 적용한 후 node <skill-dir>/scripts/verify-motion.mjs --root <project> --base-url <url> --routes /,<other-routes> --config .design-harness/qa/motion.config.json을 실행하십시오. 검증기는 기본적으로 모바일, 태블릿 및 데스크톱을 테스트하고 각 경로를 새 컨텍스트에서 격리하며 성공적인 경로 응답, 구성된 콘텐츠 루트, 예상된 관찰 URL/리디렉션 체인 및 측정 가능한 문서 스크롤이 필요하며 애플리케이션 요청을 모의하거나 명시적 프로젝트 구성이 각 예외를 선언하지 않는 한 리디렉션을 허용하지 않습니다. 전달과 함께 스키마 버전 4 Playwright/브라우저 출처 및 스크린샷/모의 해시를 유지하십시오. 첫 번째 프레임/시작 프로브 및 프레임 페이싱 임계값을 해당 머신 및 브라우저에 대한 증거로만 처리하고 절대 보편적인 60FPS 보장으로 처리하지 마십시오.
node <skill-dir>/scripts/scaffold-qa.mjs --root <project>를 사용하여 일반 QA 스캐폴드를 미리 보고 확인 카드가 QA 계획을 승인한 후 --apply를 추가하십시오. 기존 파일이 대체되는 경우에만 다시 질문하십시오. 종속성을 설치하지 않습니다.
전달
승인된 수용 기준이 통과되고 차단 결과 또는 설명되지 않은 QA 격차가 없는 경우에만 Ready 상태를 표시하고 그렇지 않으면 Not ready 상태를 표시하십시오. 변경된 파일, 스크린샷, 검토 결과 및 처리, 자동화된 검사 및 결과, 지원되지 않는 상태, 남은 격차 및 고정된 출처와 라이선스 결과와 함께 실제로 사용된 모든 외부 소스를 나열하십시오. handoff를 진행한 다음 워크플로우가 진정으로 완료된 경우에만 node <skill-dir>/scripts/state.mjs complete --root <project>를 실행하십시오.