디자인 UAT
웹사이트의 시각적 구현을 디자인 참조와 비교하여 검토합니다. 기본값은 영어, 이슈 우선 HTML 보고서입니다. 요청된 언어나 보고 형식이 있으면 이를 따릅니다. 이 스킬은 여러 프로젝트에 재사용 가능합니다. 프로젝트 URL, 프레임 매핑, 허용된 편차, 자격 증명 및 실행 증거는 이 스킬 폴더에 속하지 않습니다.
사용자 범위부터 시작
제공된 웹사이트 및 Figma 링크를 초기 범위로 사용합니다. 적절한 프로젝트 프로파일이 있으면 재사용하고, 그렇지 않으면 준비된 경로 목록이나 구성을 요구하지 않고 발견 작업을 시작합니다. Figma 페이지가 버전 핸드오프를 나타내는 경우, 전체 페이지를 인벤토리하고 각 모듈의 자체 테스트 경로를 발견합니다. 제공된 웹사이트 URL은 진입점일 뿐, 경로 제한이 아닙니다. 명시적인 전체 페이지 범위를 존중하고, 샘플로 대체하지 않고 제외 사항 및 차단된 상태를 기록합니다. 지정되지 않은 큰 범위의 경우 유용한 검토 경계를 명시합니다. 하나의 화면을 샘플링해도 전체 모듈이 승인되지는 않습니다.
프로젝트 데이터를 현재 프로젝트의 쓰기 가능한 작업 공간에 유지하고, 저장소 지침을 존중합니다. 유용한 기본값은 design-uat/<project>/project.json 및 runs/<run-id>/이지만, 기존 위치가 있으면 유지합니다. 매핑 생성, 보고서 입력 구성 또는 재실행 기록 시 project-data.md를 참조하십시오.
실제로 사용 가능한 도구를 발견합니다. 디자인 구조 및 측정에는 Figma 커넥터를, 라이브 UI에는 브라우저 제어를 선호합니다. 필요 시 관련 도구 지침 및 필수 스킬을 사용합니다. 이 스킬은 해당 도구를 제공하지 않습니다. 가능하면 기존 승인된 로그인을 재사용합니다. 접근이 차단된 경우 유용한 독립적 작업을 계속하고, 검토할 수 없었던 상태를 정확히 보고합니다.
디자인-페이지 매핑 발견
이미지를 비교하기 전에 디자인 계층 구조와 라이브 네비게이션을 검사합니다. 캔버스에는 모듈 컨테이너, 스크린 프레임, 로컬 상태 예제, 노트, 주석 및 대체 제안이 포함될 수 있습니다. 전체 문서화 보드를 화면으로 내보내지 말고, 해당 구조 내에서 시각적 대상을 식별합니다.
연결된 노트 및 로컬 상태 예제를 읽습니다. 이들은 반응형 동작, 입력 치수, 텍스트 생략 또는 메인 프레임에 표시되지 않는 구성 요소 세부 사항을 지정할 수 있습니다. 보이는/유효한 노드 콘텐츠를 사용합니다. 숨겨진 구성 요소 도우미/오류 텍스트는 트리에 존재한다고 해서 활성 요구 사항이 아닙니다.
실제 페이지 사양을 일반 상호작용의 예시와 구별합니다. 일반적인 드로어 예제는 기존 모듈에서 불일치를 드러낼 수 있지만, 모든 카테고리의 필수 필드를 설정하지는 않습니다. 유용한 교차 모듈 발견 사항은 실제 경로, 네비게이션 컨텍스트 및 기준 제한과 함께 유지합니다. 이력을 알 수 없는 경우 의심되는 레거시 상태는 확인되지 않은 것으로 레이블을 지정합니다.
모듈 컨텍스트, 경로, 보이는 페이지 제목, 필드 레이블, UI 구조 및 렌더링된 모양의 결합된 증거를 사용하여 매칭합니다. 프레임 ID, 페이지/상태, 비교 영역, 신뢰도 및 매핑 상태를 프로젝트 데이터에 기록합니다. URL은 여러 시각적 상태를 가질 수 있습니다. 리스트, 열린 드로어, 포커스된 입력 및 빈 상태를 혼동하지 마십시오.
인간이 확인하지 않은 경우 잘 뒷받침된 매칭은 추정됨으로 표시하여 진행합니다. 진정으로 모호한 선택지는 사용자에게 배치로 질문하고, 차단되지 않은 경우는 계속 진행합니다. 대체/백업 디자인은 선택된 범위 밖으로 이유와 함께 기록합니다. 이름만으로 승인된 버전이 확립되지는 않습니다. 이전에 저장된 매핑을 재사용하기 전에 현재 디자인 및 라이브 페이지와 비교하여 확인합니다.
큰 Figma 파일의 경우 원시 메타데이터를 로컬에 유지하고, 컨텍스트에는 간결하고 얕은 요약만 반환합니다. 상세한 하위 트리나 스크린샷을 추출하기 전에 알려진 조상으로 범위를 좁힙니다. 전체 파일을 반복해서 로드하지 마십시오.
비교 가능한 증거 캡처
첫 캡처 전이나 비교 문제 진단 시 evidence-workflow.md를 읽으십시오. 아트보드 오버플로, 상태 매칭, 주석 제외, 동적 콘텐츠, 로컬 크롭 및 스크린샷 승인을 다룹니다.
네비게이션, 포커스 및 되돌릴 수 있는 입력 변경을 통해 필요한 시각적 상태를 노출합니다. 해당 변경에 대한 승인 없이 스크린샷을 얻기 위해 비즈니스 변경을 제출하지 마십시오. 상태에 사용할 수 없는 데이터나 쓰기 작업이 필요한 경우, 조작하지 말고 해당 제한을 기록합니다.
호환되는 뷰포트, 스케일 및 테마에서 정확한 디자인 영역과 브라우저 상태를 캡처합니다. 글꼴/콘텐츠가 로드되었고 대상이 안정적인지 확인합니다. 로딩 상태 자체가 검토 대상이 아닌 한 일시적인 로딩 캡처는 거부합니다. 저장된 스크린샷을 보고서에 사용하기 전에 검사합니다. 크롭, 오버레이 및 주석과 함께 원본 캡처를 보존합니다.
두 이미지 모두에서 차이점을 근거로 삼고, 유용한 경우 Figma 지오메트리 및 브라우저 요소 경계도 사용합니다. 측정값을 해당 소스에 귀속시킵니다. Pillow를 사용할 수 있는 경우 선택적 네이티브 스케일 쌍 크롭 및 마크를 위해 scripts/compare_regions.py를 사용합니다. 보고서 렌더러 자체는 Python 표준 라이브러리만 필요로 합니다.
개별 치수뿐만 아니라 제어 행 전체의 관계(인접 간격, 정렬, 남은 작업 공간 및 활성 필터 컨트롤이 나타날 때의 변경 사항)를 검사합니다. 증거나 명시적 검토자 피드백에 의해 뒷받침되는 경우, 공유 레이아웃 수정과 그 시각적 결과를 하나의 안정적인 이슈로 그룹화합니다. 이 그룹화를 코드 수준 근본 원인 진단과 구별합니다.
컨텍스트를 결함과 구별합니다. 샘플 데이터, 계정 ID, 확장된 네비게이션, 전역 공지 및 이후 구성 요소 버전은 스크린샷을 변경할 수 있습니다. 이를 기록하고, 레이아웃 효과를 묵묵히 무시하지 마십시오. 텍스트 값은 복사 일치에서 제외될 수 있지만, 줄 바꿈, 오버플로 및 정렬은 검토 가능한 상태로 유지됩니다. 차이점을 숨기기 위해 스크린샷을 늘리거나 전체 페이지 유사도 점수를 조작하지 마십시오.
실행 가능한 발견 사항 만들기
각 발견 사항을 증거가 뒷받침하는 바에 따라 분류합니다.
visual-defect: 잘림, 겹침 또는 확인된 구현 위반과 같은 재현 가능한 시각적 오류. 조건과 기대치의 출처를 명시합니다.baseline-mismatch: 제공된 참조와의 입증된 차이로, 현재 승인된 디자인/버전의 확인이 필요할 수 있음.design-clarification: 충분하지 않거나 상충되는 디자인 지침으로 인해 승인 여부를 결정할 수 없는 관찰 조건.
관찰 신뢰도, 제안된 우선순위 및 후속 상태를 분리합니다. 차이점이 명백하다고 해서 고신뢰도 스크린샷 차이를 승인된 결함으로 부르지 마십시오. 프로젝트의 우선순위 체계를 사용합니다. 결정되지 않은 경우 레이블로 제안하고 우선순위를 설정하지 않은 상태로 둡니다. 소유자, 대상 릴리스, 승인된 편차, 구현 완료 또는 성공적인 재테스트를 임의로 만들지 마십시오.
각 발견 사항에는 안정적인 ID, 페이지/상태, 간결한 제목, 실제 결과, 예상 결과 또는 명시적 불확실성, 증거 근거, 권장 조치 및 재현 단계가 필요합니다. 대상 비교 증거와 전체 현재 상태 캡처를 첨부합니다. 관련 Figma 참조를 포함합니다. 시각적 증거가 없는 발견 사항은 제한 사항 또는 질문일 뿐, 확인된 시각적 결함이 아닙니다.
확인된 검사와 차단/검토되지 않은 상태는 별도로 기록합니다. 재실행 시 동일한 이슈 ID를 유지합니다. 일치하는 새 증거가 있는 경우에만 발견 사항을 종료하거나 해결됨으로 표시하고, 이전 관찰을 유지하고 변경된 승인 기준을 설명합니다.
디자인 검토 통합
기본값은 검토 초안이며, 개발자 핸드오프를 생성하기 전에 디자이너의 결정을 통합합니다. 피드백 수신, 디자인 기준 수정 또는 공식 보고서 준비 시 review-workflow.md를 읽으십시오. 대화에서 이미 명시적 검토 및 승인이 이루어진 경우, 동일한 확인을 다시 요청하지 마십시오.
유지, 제외, 승인, 병합, 연기 및 디자인 업데이트 결정을 프로젝트 데이터에 출처와 범위와 함께 기록합니다. 디자인 참조 수정은 구현 수정이 아닙니다. 디자인 변경에 대한 검토자 피드백은 그 자체로 Figma 편집을 승인하지 않습니다. 초안과 결정 내역을 유지합니다. 개발자 핸드오프에는 명시적으로 유지된 설명이나 기존 모듈 후속 조치를 포함하여 유지된 작업 항목만 포함됩니다. 할당되지 않은 우선순위, 소유권, 릴리스 또는 재테스트 필드를 확인된 값으로 바꾸지 마십시오.
보고서 전달
보고서 작성 시 report-format.md를 읽으십시오. 입증된 읽기 순서(범위 지정 컨텍스트 → 간결한 이슈 레지스터 → 선택된 이슈의 실제/예상 시각적 증거 → 적용 범위 및 검토 노트)를 유지합니다. 시각적 증거를 보고서의 실질적인 내용으로 만들고, 분리된 부록이 되지 않도록 합니다. 모든 이슈와 통과된 각 검사에 대해 큰 스크린샷을 반복하지 마십시오.
project-data.md에 설명된 구조화된 실행 데이터를 작성한 후 다음을 렌더링합니다.
python3 <skill-dir>/scripts/render_report.py <run-dir>/report.json
이것은 기준이 제공될 때 자체 포함된 report.html, issue-register.csv 및 acceptance-checklist.csv를 생성합니다. 개발자 핸드오프에서 각 유지된 항목에는 직접 테스트 URL, 네비게이션/컨텍스트, 개발자 작업 및 관찰 가능한 승인 기준이 필요합니다. 렌더러는 이러한 필드를 직접 지원합니다. 생성된 HTML을 패치하여 추가하지 마십시오. 렌더러는 Python 3.9+ 및 타사 패키지가 필요하지 않습니다. 입력/증거를 검증하지만 검토 결정을 추론하거나, 외부 시스템에 액세스하거나, 개발자에게 보고서를 보내지 않습니다.
렌더링된 보고서, 이슈 전환/필터링, 이미지 확장 및 비교 컨트롤을 검사합니다. 사용 가능한 로컬 미리보기 도구를 사용하여 브라우저 규칙을 따라 결과를 엽니다. 필요한 경우 루프백에 바인딩된 충돌하지 않는 로컬 미리보기를 사용합니다. 요청되지 않은 한 외부 시스템에 게시하거나 쓰지 마십시오. 가능하면 임시 브라우저 뷰포트 오버라이드와 테스트 입력을 복원하고 변경된 상태가 있으면 보고합니다.
대화의 언어로 보고서 링크, 간결한 적용 범위 및 주요 결과를 전달합니다. 중요한 제한 사항을 설명합니다. 이미 요청된 보고서를 생성하기 위해 승인을 요구하지 마십시오. 접근 방식에 대한 토론 요청은 UAT 실행 요청이 아닙니다.