Shunqiang/skills

Figma to 프론트엔드 페이지

결과물과 범위

선택된 디자인을 현존 프로젝트에 구현하고 브라우저에서 결과를 검증합니다. 일반적으로 Figma URL만으로 충분히 시작할 수 있으며, 저장소로부터 프로젝트 규칙을 추론합니다. 디자인에 접근할 수 없는 경우 제공된 스크린샷이나 내보내기 파일을 대체 증거로 사용합니다.

사용자 지시가 이 가이드라인보다 우선합니다. 기존 변경 사항을 유지하고 작업 범위 내에서 수정을 제한합니다. 파일이나 라우트를 선택하기 전에 작업이 새 페이지인지, 기존 페이지 업데이트인지, 섹션인지, 또는 재사용 가능한 컴포넌트인지 식별합니다. 컴포넌트나 로컬 수정을 새 페이지로 전환하지 마십시오.

핵심 제약 사항

• 편집 전에 관련 저장소 코드를 읽습니다. 해당 프레임워크, 라우터, 스타일링, 토큰, 컴포넌트, 에셋 및 데이터 규칙을 적절히 재사용합니다.
• 디자인 지오메트리를 레이아웃 규칙으로 변환합니다. 일반 흐름, flex, grid를 선호하며, 실제 오버랩, 장식 또는 오버레이에는 절대 위치 지정을 사용합니다. Figma 그룹은 증거일 뿐, 필수적인 컴포넌트 경계는 아닙니다.
• 동일한 에셋을 재사용하고 적절한 매핑된 컴포넌트를 사용합니다. 독특한 이미지와 아이콘을 보존하며, 근사 기호로 대체하지 마십시오. 대화형 섹션 전체를 스크린샷으로 렌더링하지 마십시오.
• 요구사항, 프로토타입 또는 기존 제품 동작이 지원하는 동작을 구현합니다. sticky 포지셔닝, 필터 의미, API 계약 또는 탐색 대상을 외관만으로 추론하지 마십시오.
• 의미론적 컨트롤, 접근 가능한 이름, 키보드 작동 및 적절한 포커스 동작을 보존합니다. 요청되지 않은 경우 OS 상태 표시줄과 같은 장치 테두리를 포함하지 마십시오.
• 구현된 대상을 디자인과 비교하지 않고 시각적 일치성을 주장하지 마십시오. 차단되거나 검증되지 않은 요구사항은 명시적으로 보고합니다.

CSS 호환성

• flex, grid 및 반복 항목 간의 간격에는 margin을 사용하십시오. gap, row-gap 또는 column-gap을 사용하지 마십시오. 명명된 항목 클래스에 간격을 지정하고, 첫 번째 또는 마지막 항목의 여백이 다를 경우 명시적인 수정자 클래스를 제공하십시오. gap을 > * + *, :first-child 또는 :last-child와 같은 선택자로 대체하지 마십시오.
• 명시적 컴포넌트 클래스에 대해 선택자를 작성하십시오. 보편 선택자와 형제 결합자(+, ~)는 WXSS로 컴파일될 수 있는 스타일에서 사용하지 마십시오. 다른 의사 클래스나 결합자를 사용하기 전에 대상 플랫폼의 선택자 지원을 확인하십시오. 브라우저 CSS 지원이 WXSS 지원을 의미한다고 가정하지 마십시오.
• 마스크와 고정 패널의 경우 inset 대신 명시적인 top, right, bottom 및 left 선언을 사용하십시오. env(safe-area-inset-*)를 사용할 때는 env()를 사용하는 선언 바로 앞에 일반 값 폴백을 배치하십시오. 고정 너비와 패딩이 함께 맞아야 하는 경우 box-sizing: border-box를 설정하십시오.
• Taro H5에서 내장된 taro-button-core:active 스타일은 호버 클래스가 비활성화되어 있어도 눌린 버튼을 회색으로 만들 수 있습니다. 디자인에 눌린 색상 변경이 없는 경우 특정 버튼 클래스에 대해 활성 배경 및 텍스트 색상을 재정의하고 각 버튼의 일반 색상을 유지하십시오. 버튼을 전역적으로 재설정하거나 비활성화 스타일을 변경하지 마십시오.

증거와 결정

디자인 증거를 수집하거나 새로 고칠 때 design-evidence.md를 읽으십시오. 대상, 프로젝트 규칙, 에셋 매핑, 적용 가능한 기능 및 불확실성에 대한 간결한 작업 요약을 유지하십시오. 작은 작업의 경우 컨텍스트 메모로 충분합니다. 유용하거나 요청되지 않는 한 사양 파일을 생성하지 마십시오.

결정을 분류하십시오:

• 확인됨: 명시적 사용자 요구사항, 선택된 디자인 속성, 프로토타입 동작 또는 관련 기존 제품 계약.
• 추론됨: 일반적인 레이아웃 적응, 래핑 및 프로젝트와 일치하는 로컬 컴포넌트 경계. 가장 작은 합리적인 구현을 선택하고 중요한 가정을 공개하십시오.
• 알 수 없음: 누락된 제출 계약, 모호한 대상, 충돌하는 대상 프레임 또는 중대한 비즈니스 동작. 먼저 사용 가능한 증거를 검사하고 여전히 필요한 경우 집중된 질문을 하십시오. 답변을 기다리는 동안 독립적인 작업을 계속하십시오.

보이는 컨트롤만으로 비즈니스 동작이 확립되는 것은 아닙니다. 성공적인 제출을 위조하거나, 엔드포인트를 발명하거나, 조용히 모의 동작을 대체하지 마십시오. 작업이나 기존 미리보기 규칙이 지원하는 경우에만 픽스처를 사용하고 해당 제한 사항을 식별하십시오.

실행

고정된 순서를 반복하기보다는 의존성을 따라 진행하십시오. 로컬 수정의 경우 여전히 유효한 증거를 재사용하고 변경된 영역과 영향을 받는 공유 동작을 검사하십시오. 독립적인 저장소 및 디자인 읽기는 일괄 처리할 수 있습니다.

1. 대상 및 프로젝트 식별

파일 키와 노드 ID를 파싱하십시오. 선택된 노드의 유형, 크기 및 주변 컨텍스트를 검사하십시오. 노드 ID가 없는 경우 최상위 후보를 검사하고 대상이 명확할 때만 선택하십시오.

대상 검색 및 읽기를 사용하여 다음을 설정하십시오:

• 적용 가능한 저장소 지침 및 현재 변경 사항;
• 패키지 관리자, 개발 및 검증 명령어;
• 가능한 대상 파일 및 가장 가까운 기존 구현;
• 라우터, 스타일링, 토큰, 글꼴, 뷰포트/단위 처리 및 컴포넌트 규칙;
• 가능한 경우 기존 디자인-투-코드 매핑 및 에셋.

기존 페이지 또는 컴포넌트 작업의 경우 해당 진입점을 보존하십시오. 새 페이지의 경우 기존 라우트 패밀리 및 매개변수 규칙을 따르고 충돌을 확인하십시오. 프레임 이름은 폴백 명명 힌트로만 사용하고 일반적인 세부 라우트를 강요하지 마십시오.

2. 충분한 디자인 증거 확보

메타데이터, 스크린샷, 변수, 컴포넌트 매핑 및 에셋에 대해 사용 가능한 Figma 도구를 선호하십시오. 해당 도구를 호출하기 전에 필요한 도구별 스킬 전제 조건을 따르십시오. 액세스가 실패하면 사용 가능한 인증된 브라우저를 시도한 다음 제공된 스크린샷 또는 내보내기를 시도하십시오. 실제 디자인 대신 웹 검색을 사용하지 마십시오.

대상 스크린샷 및 구조적 개요로 시작한 다음 관련 하위 트리의 세부 정보를 가져오십시오. 스크롤 아래 콘텐츠를 검사하십시오. 전체 파일이나 관련 없는 프레임을 반복적으로 검색하지 마십시오. 측정할 수 없는 값이나 상태는 정확한 사실보다는 불확실성으로 기록하십시오.

3. 매핑 및 구현

디자인을 의미 있는 모듈로 매핑하고, 동작과 외관이 적합한 기존 컴포넌트를 선택하십시오. 재사용, 독립적인 동작 또는 복잡성이 정당화되는 경우 컴포넌트를 추출하십시오. 모든 래퍼를 분할하거나 한 페이지를 위해 디자인 시스템을 만들지 마십시오.

글꼴과 주요 에셋을 일찍 해결하십시오. 에셋의 종횡비, 투명도 및 적절한 해상도를 유지하고 저장소 저장 규칙과 의미 있는 파일 이름을 사용하십시오. 런타임 에셋이 프로젝트에서 지원하는 내구성 있는 위치에서 로드되는지 확인하십시오.

제공된 변형 및 기존 프로젝트 동작에서 유동적 크기, 최대 너비, 래핑 및 중단점을 파생하십시오. 하나의 디자인 크기로 보수적인 적응을 구현하고 디자이너가 지정한 반응형 레이아웃과 구분하십시오. 요청된 플랫폼에서 테스트하고 요청되지 않은 데스크톱 또는 모바일 재설계를 생성하지 마십시오.

H5와 미니프로그램 빌드 간에 스타일을 공유하는 Taro 프로젝트의 경우 소스 스타일시트뿐만 아니라 생성된 WXSS도 검사하십시오. 사용 가능한 각 런타임에서 간격과 눌린 상태를 확인하십시오.

관련 동작 분기만 활성화하십시오:

• 탐색: 기존 대상 및 라우팅 동작을 사용하십시오.
• 폼 및 컬렉션: 기존 데이터 계약을 사용하고 필요한 유효성 검사, 로딩, 빈, 오류 및 성공 상태를 구현하십시오.
• 탭 및 필터: 증거에서 상태 소유권 및 선택 의미를 설정하십시오. 초안/커밋 동작은 지원되는 경우에만 적용됩니다.
• 테이블: 정렬 및 표시된 테두리를 보존하고 대상 뷰포트에 적합한 오버플로를 제공하십시오.
• 오버레이 또는 고정 UI: overlays-and-sticky.md를 읽으십시오.
• 모션 또는 미디어: 확인된 동작을 재현하고 해당되는 경우 로딩 및 축소된 모션을 처리하십시오.

4. 검증 및 반복

적절한 실행 중인 서버를 재사용하거나 문서화된 개발 명령어를 사용 가능한 포트에서 시작하십시오. 사용 가능한 브라우저 자동화 인터페이스를 사용하고, 적합할 때는 앱 내 브라우저를 선호한 다음 인증된 외부 브라우저 또는 프로젝트의 브라우저 도구를 사용하십시오. 관련 라우트 또는 기존 컴포넌트 미리보기를 검사하십시오.

시각적 비교, 적용 가능한 상호작용 확인 및 완료 기준을 위해 acceptance-checklist.md를 읽으십시오. 로컬 마무리 전에 큰 구조적 차이를 수정하십시오. 각 변경 후에 영향을 받은 영역을 확인하고 최종 전체 대상 점검을 수행하십시오.

관련 저장소 점검을 실행하고 최종 diff를 검사하며 기존 실패와 도입된 실패를 구분하십시오. 검증을 수행하기 위해 종속성을 추가하거나 광범위한 리팩터링을 피하십시오. 기존 서버 세션을 보존하고 이 작업을 위해 시작된 모든 서버의 상태를 의도적으로 만드십시오.

복구 및 완료

액세스 또는 런타임 검증이 실패하면 구체적인 오류를 검사하고 사용 가능한 관련 대안을 시도하십시오. 새로운 증거 없이 변경되지 않은 실패를 반복하지 마십시오. 독립적으로 완료할 수 있는 작업을 계속한 다음 정확한 차단 항목, 구현된 내용 및 검증되지 않은 항목을 보고하십시오. 누락된 도구나 자격 증명은 성공적인 검증의 증거가 아닙니다.

요청된 대상이 구현되고, 적용 가능한 검사가 통과되고, 알려진 필수 결함이 남아 있지 않을 때 완료됩니다. 사소한 렌더링 차이는 문서화될 수 있습니다. 해결되지 않은 레이아웃 오류, 누락된 필수 동작 또는 차단된 브라우저 검사는 완전한 완료로 제시되어서는 안 됩니다.

간결하게 보고하십시오:

• 구현된 대상 및 진입점, 해당되는 경우 라우트 포함;
• 의미 있는 동작 및 컴포넌트 변경 사항;
• 미리보기 위치 및 실제로 수행된 검사;
• 중요한 가정, 해결되지 않은 차이 또는 차단 항목.