菜单
FlatLayout definePage + widget의 구조를 체크리스트로 평가하고 수렴 루프를 돌려 개선한다. 텍스트 체크(L1/L2) + 스샷 검증(L3)의 3층 교차 구조. "레이아웃 평가", "definePage 점수", "이 페이지 레이아웃 봐줘", "/layout-score" 등을 말할 때 사용. 구조 단위 책임 경계를 검증한다.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Refactor frontend source trees so layer/slice/segment(role) hierarchy stays clear. Treat FSD names such as shared/entities/features/widgets/app as examples, not as the required target. Use when the user asks to reorganize src, separate app-owned code from reusable packages, remove layer smells, or clarify 책임 경계.
요청이 모호하거나 '왜 하는지'부터 정리가 필요할 때 사용. /discuss, $discuss, 숨은 의도 정렬, 전략 선택, 실행 전 확인 요청, 프로젝트 작업과 개인 도구 작업의 범위 분리가 필요할 때 사용한다. TOC 13요소와 FRT 게이트로 이해도를 순서대로 올린 뒤 goal로 실행 가능한 액션 플랜을 만든다. 질문만 던지는 소크라틱 대화가 아니라, AI가 먼저 범위 안 맥락을 조사하고 추론한 뒤 판단과 근거를 밝히고 필요한 갭 질문만 얹는다.
Use when the user invokes /doubt or $doubt, asks Codex to deliberately reduce unnecessary complexity before introducing a new concept, component, flag, type, file, branch, workflow, document, or procedure, or requests cleanup/review after implementation. Triggers include "이거 다 필요해?", "정리 좀 해줘", "새로 만들어야 할까?", "불필요한 거 없나?", "코드 줄여줘", "why do we need this?", or any review where existence, fit, volume, and efficiency should be challenged before adding or keeping structure.
Use when refactoring frontend entity folders, FSD feature/entity boundaries, exported type names, prefix alignment, or cohesive entity/viewModel/value-object props so files and UI interfaces are grouped by real domain or UI concepts instead of role labels, generic names, or shredded field props. Trigger on requests such as entities 응집도, 접두어 정렬, 인터페이스 중심 폴더링, FSD 위치 점검, feature/entity 경계 리팩토링, props drill, entity shredding, viewModel props, 엔티티를 그대로 넘기기.
파일이나 기능의 개방-폐쇄 원칙(OCP)을 점검하고 리팩토링한다. "OCP", "/ocp", "개방 폐쇄", "switch 너무 많다", "if 분기 정리", "분기 흩어짐", "선언적 맵", "registry", "descriptor", "새 타입/variant 추가마다 여러 곳 수정" 같은 요청에서 사용한다. 열린 집합의 분기가 여러 소비자에 산재해 동반 변경 지점이 2곳 이상인지 분석하고, 확장 시 기존 코드 수정 지점을 0~1곳으로 줄이는 구조를 설계·전환한다.
사용자 발화를 액면 그대로 수행하지 않고 숨은 조사 의도, 배경, 목표를 먼저 추론한 뒤 비교 대상의 범주와 피어셋을 잠그고, 내부 맥락을 감사하고 standard, best practice, de facto, frontier trend를 비교해 읽히는 reference narrative를 만든다. "reference", "레퍼런스", "BP 찾아줘", "best practice", "사실상 표준", "de facto", "요즘 트렌드", "최근 시도", "업계는 어떻게 해", "표준 뭐야", "research", "리서치", "/reference", "/research"처럼 외부 수렴 흐름을 알고 싶을 때 사용한다. 단순 링크 목록이나 표 보고서가 아니라, 소스를 대신 읽고 같은 범주의 BP/de facto와 얼마나 가까운지, 결이 얼마나 비슷한지, 차이가 있다면 더 가까운 유사 레퍼런스는 무엇인지 문단 중심으로 설명하고 필요한 근거 표는 appendix로 내린다.
| name | layout-score |
| description | FlatLayout definePage + widget의 구조를 체크리스트로 평가하고 수렴 루프를 돌려 개선한다. 텍스트 체크(L1/L2) + 스샷 검증(L3)의 3층 교차 구조. "레이아웃 평가", "definePage 점수", "이 페이지 레이아웃 봐줘", "/layout-score" 등을 말할 때 사용. 구조 단위 책임 경계를 검증한다. |
LLM은 스크린샷 비평은 고해상도인데 디자인 개선은 평균으로 회귀한다. 원인은 수렴 루프 부재 — 비평은 1회 forward pass이지만 개선은 닫힌 루프가 필요하다. FlatLayout은 flat 선언이라 raw 텍스트만으로도 고해상도 평가가 가능하다는 특성이 있고, 이 특성을 이용해 L1/L2 텍스트 루프 + L3 스샷 검증의 교차 구조를 돌리는 것이 이 스킬의 핵심이다.
L1 (FlatLayout): "slot과 배치가 의도 대로인가" — raw text만으로 가능
L2 (Widget): "slot content가 의도를 수행하는가" — raw text + 동작 검증
L3 (ax/토큰): "그 의도가 픽셀에 드러나는가" — 반드시 스샷 필요
불변식: 한 번의 iteration은 한 층만 건드린다. L1/L2/L3를 섞으면 범위가 폭발해 미완주.
사용자가 지정한 파일(또는 페이지)를 읽는다.
src/pages/*/Page*.tsx — definePage 선언src/pages/*/*Widgets.tsx 또는 widget 구현 파일src/interactive-os/layout/flatLayout.ts에서 지원 축을 확인한다. 없는 수단(예: divider prop)을 평가 축으로 삼으면 수렴이 실패한다.
현재 확인된 스펙:
| # | 축 | 판정 기준 | binary? |
|---|---|---|---|
| L1 | top-level 구조 | root에 header/content/footer 영역이 구분되는가 | ✓ |
| L2 | progress prominence | 진행률/상태 widget이 header 또는 독립 bar에 있는가 | ✓ |
| L3 | toolbar 구분 | toolbar ↔ grid 경계에 surface delta가 있는가 | ✓ |
| L4 | footer 존재 | keyboard hints 상시 노출 bar 있는가 (+ intent 2단 체크) | ✓ |
| L5 | toolbar 내부 그룹 구분 | bar 2+ child에 gap/surface 선언 | ✓ |
| L6 | grid surface 명시 | grid 노드의 surface가 암묵이 아닌 명시 | ✓ |
| L7 | root padding | 외곽 숨쉬기 선언 | ✓ |
| L8 | sizes 정합성 | sizes 개수 == children 개수, flex 영역 1개 | ✓ |
| L9 | sidebar tree (editor 류) | navigation widget slot | ✓ |
| L10 | detail pane (editor 류) | 편집 pane slot | ✓ |
| L11 | 인접 same-surface 금지 ★ | split/bar의 인접 child에 연속 같은 surface 금지 | ✓ |
| L12 | 1-child container | 자식 1개인 bar/split은 경고 (삭제 후보) | 🟡 |
| L13 | padding rhythm | 동일 레벨 영역이 같은 scale | ✓ |
L11이 결정적. 텍스트로만 잡을 수 있고, 스샷으로는 덜 명확한 실패 패턴.
각 "slot 존재" 축에 대해 두 질문:
(a)만 ✓이고 (b)가 ✗이면 false positive. 반드시 L2로 진입해 widget을 본다.
검증된 실패 사례: footer bar에 I18nHelpWidget 배치 → (a) ✓, (b) ✗. widget이 popover 토글이라 hints가 클릭해야 보임. 의도("상시 노출") 실패.
한 iteration은 한 층만. 다음 항목은 범위 밖으로 분리:
범위 밖 항목은 리포트에 명시하되 이번 iteration에서 만지지 않는다.
guardOsPatterns.mjs)가 평균 해법(style={} 등)을 막는 것을 신뢰 — 가드가 보조 평가자pnpm typecheck 2>&1 | grep -E "(대상파일)" | head -20
파일 단위로 좁혀 확인. 기존 무관 에러가 많으므로 filter 필수.
node scripts/screenshot.mjs /대상라우트
라우트가 스크립트 routes 배열에 없어도 / 접두사로 주면 ad-hoc 수집된다 (filterRoutes 참조).
Read로 screenshots/{label}.png 를 읽고 눈으로 확인:
텍스트 루프만으로는 수렴 불가. 이 단계는 종료 조건의 일부.
동일 체크리스트로 다시 채점. "전 X/N → 후 Y/N" 형식.
수렴 못 한 항목을 분류:
작동한 것 / 마찰 / 발견을 분리해 기록. 발견이 체크리스트의 신설 축이 되면 L11처럼 다음 세션의 규칙으로 승격.
feedback_design_convergence_loop — 왜 수렴 루프가 필요한가feedback_flatlayout_separation_declaration — 인접 구분 수단 declaration 원칙feedback_slot_existence_vs_intent — 2단 판정 (slot 존재 ≠ 의도 수행)/design-extract — 레퍼런스 토큰 실측 (L3 입력 준비)/blueprint — 앱 레이아웃 설계 (이 스킬의 입력 생성)i18n editor PageI18nEditor.tsx 대상으로 3회 iteration:
각 iteration마다 텍스트 체크 + 스샷 검증 교차. L3(ProgressIndicator 불가시, surface 토큰 대비)만 미수렴 → L3 루프로 이월. L1/L2 수렴 루프가 실제로 작동함이 증명됨.