vicunav/vicunav-transform-claude-to-gutenberg

Transformar Claude Code a Gutenberg FSE (클로드 코드를 Gutenberg FSE로 변환)

목표

승인된 Claude Code 프로젝트를 네이티브하고 유지보수 가능한 WordPress 사이트로 변환합니다. WordPress가 블록을 통해 편집 가능한 솔루션을 이미 제공하는 경우, 프로토타입 프론트엔드 아키텍처를 그대로 가져오지 않으면서 합의된 디자인, 콘텐츠 및 동작을 보존합니다.

소스 프로젝트를 시각적 및 기능적 사양으로 취급합니다. 승인된 LocalWP에서만 작업합니다. 명시적 승인 없이 프로덕션을 수정하거나, 콘텐츠, Site Editor 사용자 정의, 로컬 데이터를 삭제하지 않습니다.

최소 컨텍스트 수집

편집 전에 확인하거나 발견할 사항:

• Claude Code에서 내보내거나 정제한 프로젝트 경로;
• LocalWP 사이트 및 대상 테마 경로;
• 승인된 디자인을 구성하는 정확한 커밋, 빌드 또는 상태;
• 포함된 페이지, 중단점, 상태 및 상호작용;
• 로컬 사이트의 실제 WordPress 및 PHP 버전;
• 목표가 1:1 동등성, 승인된 최적화 또는 재설계인지 여부;
• WordPress에서 편집 가능해야 하는 콘텐츠 및 통합;
• 플러그인, 사용자 정의 블록, 글꼴 및 에셋 라이선스 제한 사항.

콘텐츠, 아키텍처, 기능 또는 디자인을 변경하는 결정이 누락된 경우 중단하고 요청하십시오. 파일 시스템, 프론트엔드 또는 로컬 사이트에서 복구 가능한 데이터가 누락된 경우 이를 검사하고 가정을 기록하십시오.

재사용 가능한 베이스 로드

단계에 따라 설치된 공식 스킬을 적용합니다:

• wp-project-triage: WordPress 프로젝트 및 툴체인 분류;
• wp-block-themes: theme.json, 템플릿, 파트, 패턴 및 FSE 스타일 구현;
• wp-block-development: 상호작용이 사용자 정의 블록을 요구하는 경우에만 사용;
• wp-wpcli-and-ops: WP-CLI로 콘텐츠 및 옵션 검사 또는 변경;
• unlazy (설치된 경우): 상당한 규모의 마이그레이션(한 페이지 이상, 또는 지속적인 감독 없이 완료된 것으로 보고할 작업)에 대한 종료 규율. 아래 "각 단위를 게이트 규율로 마감" 참조.

먼저 대상 버전을 확인하십시오. 공식 스킬이 LocalWP보다 최신 WordPress 버전을 대상으로 하는 경우, 호환 가능한 API만 사용하고 공식 문서를 참조하여 차이점을 해결하십시오.

해당되는 경우 자체 리소스를 읽으십시오:

• source-contract.md: 베이스라인을 고정하고 마이그레이션 계약을 정의하기 전;
• migration-manifest.md: 베이스라인을 캡처하거나 시각적 영향을 미치는 변경을 구현하기 전;
• translation-map.md: Gutenberg 아키텍처를 결정하기 전과 각 컴포넌트를 변환하는 동안;
• localwp.md: 사이트 또는 데이터베이스를 건드리기 전;
• qa-checklist.md: 첫 번째 보이는 섹션 전과 작업 완료를 선언하기 전에 다시;
• upstream.md: 재사용된 베이스를 업데이트, 감사 또는 재배포할 때;
• templates/gates-fse-migration.md: 페이지 또는 섹션에 대해 $unlazy를 열 때, 게이트를 처음부터 작성하는 대신 복사하여 완성할 초기 원장(ledger)으로 사용.

흐름 실행

1. 두 프로젝트 모두에서 직접 관련된 로컬 지침, Git 상태 및 문서를 읽습니다.
2. scripts/audit_source.mjs <source-path>를 실행하고 그 결과를 수동으로 검토합니다. 휴리스틱 보고서를 아키텍처 결정으로 취급하지 마십시오.
3. 마이그레이션 매니페스트를 생성하고, 예상되는 모든 조합을 인덱싱한 후 scripts/validate_migration_manifest.mjs <manifest-path>를 실행합니다.
4. 깨끗한 환경에서 소스 프론트엔드를 실행하고 데스크톱, 태블릿, 모바일에서 관련 상호작용 상태를 포함한 베이스라인을 캡처합니다.
5. 마이그레이션 계약을 생성합니다: 페이지, 섹션, 카피, 에셋, 토큰, 상호작용, 데이터 소스, 통합 및 승인 기준.
6. 재사용 가능한 토큰을 로컬 형상(geometry)과 분리합니다. 전자는 theme.json에 매핑하고 후자는 블록, 레이아웃 및 최소 의미론적 클래스를 통해 유지합니다.
7. FSE 아키텍처를 설계합니다: 템플릿, 템플릿 파트, 패턴, 페이지 콘텐츠, 그리고 필요한 경우에만 사용자 정의 블록 또는 플러그인.
8. 먼저 대표적인 섹션을 구현합니다. 확장하기 전에 프론트엔드와 Site Editor를 비교합니다.
9. 페이지별, 섹션별로 마이그레이션합니다. 구현 전체에 걸쳐 소스 프로젝트를 참조로 계속 표시합니다. $unlazy가 가능한 경우, 해당 페이지 또는 섹션의 GATES.md를 구현하기 전에 templates/gates-fse-migration.md를 복사하여 단위를 엽니다.
10. 프로젝트 문서화된 흐름을 통해 LocalWP에 테마를 설치하거나 활성화합니다. 콘텐츠를 멱등적으로 생성 또는 업데이트하고 기존 항목을 보존합니다.
11. scripts/validate_fse_theme.mjs <theme-path>를 실행하고 모든 오류를 수정합니다. 적용 가능한 경고를 검토합니다.
12. 프론트엔드와 Site Editor에서 시각적, 구조적, 편집적, 반응형, 접근성 및 성능 QA를 완료합니다.
13. capture_visual_evidence.mjs, compare_visual_evidence.mjs 및 verify_visual_evidence.mjs를 통해 캡처, 비교 및 게이트를 실행합니다. 수동으로 나란히 및 오버레이를 검토합니다. 전체 너비 섹션이 하나 이상 있는 각 페이지에 대해 scripts/verify_editor_frontend_parity.mjs를 추가로 실행하고( scripts/wp_auth_cookies.php로 생성된 실제 세션 쿠키 필요. translation-map.md 참조) PARIDAD_EDITOR_FRONTEND_OK를 요구합니다. 인간의 시각적 비교만으로는 이 프로젝트에서 이미 두 번 문서화된 이 버그 클래스에 충분하지 않습니다. 단위에 GATES.md가 있는 경우 node <unlazy-skill-dir>/scripts/gate-check.mjs --reverify GATES.md를 실행하고 계속하기 전에 ALL MET를 요구합니다.
14. 증거, 제한 사항, 롤백 및 다음 작업 단위를 제공합니다. $unlazy를 사용한 경우, 충족, 미충족 및 중단된 게이트의 정규화된 ID를 포함합니다. 보류 또는 중단된 게이트가 있는 단위를 완료된 것으로 설명하지 마십시오.

각 단위를 게이트 규율로 마감 ($unlazy)

unlazy가 설치된 경우, 이 스킬의 종료 규율 계층으로 취급하고 대체품이 아닙니다. 이 스킬은 FSE 마이그레이션에서 무엇을 확인할지 결정하고, unlazy는 작업 전에 해당 기준을 실행 가능한 명령으로 선언하고, 완료되었다고 보고하기 전에 실제 증거로 재검증하도록 강제합니다. "괜찮아 보인다"는 시각적 판단에 의존하지 않습니다.

• 페이지 또는 섹션에 대해 unlazy의 독립 모드를 사용합니다(단위당 하나의 GATES.md, templates/gates-fse-migration.md에서 복사). 오케스트레이션 모드는 많은 독립적인 페이지가 있는 전체 사이트에만 사용하며, 각 페이지는 Depth Tree의 리프로, 자체 OWNS:(자체 템플릿/패턴 파일)와 교차 탐색, 공유 헤더/푸터 및 페이지 간 회귀 부재를 확인하는 통합 브랜치가 있습니다.
• 모든 사소한 수정을 게이트 원장으로 전환하지 마십시오. 규율을 페이지, 전체 사이트 마이그레이션 또는 조용히 불완전하게 남겨두는 비용이 정당화되는 모든 단위에 예약하십시오(실제 사례 참조: 템플릿에 하드코딩된 콘텐츠가 사이트 소유자가 수동으로 감지하기 전에 여러 작업 단위 동안 페이지를 비워두고 편집 불가능하게 만든 경우).
• 실제 콘텐츠 게이트(post_content 비어 있지 않음)를 프로젝트의 실제 WP-CLI 호출에 맞게 조정하십시오. LocalWP에서는 거의 항상 전역 wp 바이너리가 아닙니다(localwp.md 참조).
• 수동 게이트는 명령이 제대로 측정할 수 없는 항목(인지적 시각적 충실도, 카피에 대한 편집 검토)에 대해 여전히 유효합니다. 수동 게이트를 피하기 위해 자동 메트릭을 강제하지 마십시오. 이 스킬의 계약은 이미 인지적 메트릭을 자동 동등성 승인으로 전환하는 것을 금지합니다.
• unlazy의 선택적 Stop 훅을 사용자에게 명시적으로 요청하지 않고 설치하지 마십시오. 스킬 자체가 이를 요구합니다.
• 작업을 적절한 모델 수준으로 라우팅하십시오. unlazy의 오케스트레이션 모드와 이 스킬의 페이지별 마이그레이션 모두에서 기계적이고 잘 정의된 리프(다른 페이지에서 이미 해결된 구성 요소의 직접 변환, 클래스 조정, 이미 진단된 특정 수정)는 더 가벼운 모델로 이동합니다. 아키텍처 판단, 블록 vs 패턴 vs CPT 결정 또는 시각적 확인이 필요한 리프는 세션 모델이 유지합니다. 더 적은 조정으로 동일한 결과를 얻을 수 있다면, 모든 사소한 편집에 대해 완전한 에이전트를 분할하지 마십시오.

비협상 계약 유지

• 핵심 블록, 테마 패턴 및 WordPress 공개 API를 선호합니다.
• core/html을 프로토타입 HTML을 유지하기 위한 지름길로 사용하지 마십시오.
• 공유 토큰의 진실 공급원으로 theme.json을 사용하십시오.
• 전역 구조에는 템플릿과 파트를 유지하고, 편집 구성을 위해 페이지 콘텐츠 또는 패턴을 사용하십시오.
• 입증되고 승인된 요구 사항이 없는 한, WordPress 프론트엔드에 React, Tailwind 또는 프로토타입 런타임을 도입하지 마십시오.
• 핵심 블록이 유지보수 가능하게 표현할 수 없는 동작 또는 편집에 대해서만 사용자 정의 블록을 만드십시오.
• 비즈니스 로직, 예약, 주문 및 데이터 모델은 테마가 아닌 플러그인에 배치하십시오.
• 글꼴과 이미지를 로컬로 제공하고 라이선스, 출처 및 대체 텍스트를 보존하십시오.
• 프론트엔드와 Site Editor를 필수 표면으로 유지하십시오.
• 유효한 매니페스트와 완전한 매트릭스 없이 시각적 마이그레이션을 구현하지 마십시오.
• 인지적 메트릭을 자동 동등성 승인으로 전환하지 마십시오.
• 데이터베이스에 저장된 우발적인 전역 스타일에 의존하지 마십시오.
• prefers-reduced-motion, 키보드, 가시적 포커스 및 WCAG 2.1 AA를 준수하십시오.
• 디자인 공백을 메우기 위해 콘텐츠, 경로 또는 기능을 발명하지 마십시오.

레스토랑 데모 기준 적용

• 블록과 패턴으로 작고 순수하게 편집 가능한 메뉴를 모델링하십시오.
• 메뉴에 구조화된 편집, 필터, 재사용 또는 실제 성장이 필요한 경우에만 vicu_menu_item과 같은 CPT를 제안하고, 플러그인에 등록하고 동작을 테스트하십시오.
• 예약, 주문, 결제, 동적 시간 및 가용성을 별도의 기능 통합으로 취급하십시오. 정적 양식으로 조용히 시뮬레이션하지 마십시오.
• 헤더, 푸터, 예약 호출 및 연락처 모듈을 승인된 아키텍처와 동기화된 파트 또는 패턴을 통해 재사용하십시오.

검증 가능한 단위로 작업

다음 조건이 충족될 때만 페이지 또는 섹션을 마감하십시오:

• 콘텐츠, 링크 및 에셋이 계약과 일치합니다.
• 마크업이 유효하고 블록이 편집 가능한 상태로 유지됩니다.
• 프론트엔드와 편집기가 스타일을 올바르게 렌더링합니다.
• 데스크톱, 태블릿 및 모바일이 베이스라인과 비교되었습니다.
• hover, focus, active, loading 및 error 상태가 적용 가능한 경우 테스트되었습니다.
• 콘솔 오류, 예상치 못한 원격 리소스 또는 Claude Code 개발 서버에 대한 종속성이 없습니다.
• 증거가 테스트된 정확한 상태와 일치합니다.
• 조합이 매니페스트에 고유한 행을 가지며 pending 상태가 아닙니다.

검증 가능한 상태 전달

다음을 보고하십시오:

• 완료된 페이지 및 섹션;
• 영향을 받은 아키텍처 및 파일;
• 핵심 블록, 패턴, 사용자 정의 블록 또는 플러그인 결정;
• 실행된 명령 및 검사와 그 결과;
• 비교에 사용된 URL 및 뷰포트;
• 허용된 차이점, 잔여 위험 및 롤백;
• 검증된 매니페스트 경로 및 증거 매트릭스 요약.

사이트가 렌더링되거나 HTML에 동일한 카피가 포함되어 있다고 해서 시각적 동등성을 주장하지 마십시오. 동등성은 시각적 비교와 편집 가능성 검증을 요구합니다.

호출 예시

$transform-claude-to-gutenberg를 사용하여 이 Claude Code 프로젝트를 감사하고 지정된 LocalWP 사이트에 대한 홈페이지 마이그레이션 계약을 작성하세요.

$transform-claude-to-gutenberg를 사용하여 레스토랑 데모를 핵심 블록 및 로컬 에셋을 사용하는 1:1 FSE 블록 테마로 변환하세요.

$transform-claude-to-gutenberg를 사용하여 마이그레이션된 테마를 검토하고, 무엇이 이를 편집 가능하고 승인된 프로토타입과 시각적으로 동등하다고 간주하는 것을 방해하는지 열거하세요.