菜单
앱 레이아웃을 FlatLayout definePage로 설계한다. 요구사항이나 레퍼런스 앱 이름을 받아 기능 전수 열거 → 레이아웃 구조 분석 → definePage 설계 → widget × ui/ 부품 매칭 → Coverage 검증 → GAP 발견까지 수행한다. "레이아웃 설계", "앱 만들어봐", "화면 구조", "blueprint", "definePage로 설계", "~처럼 만들면", "Gmail 레이아웃" 등을 말할 때 사용. 코드를 편집하지 않고 preview만 출력한다. /go 전에 청사진을 먼저 잡고 싶을 때 사용.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
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로 내린다.
基于 SOC 职业分类
| name | blueprint |
| description | 앱 레이아웃을 FlatLayout definePage로 설계한다. 요구사항이나 레퍼런스 앱 이름을 받아 기능 전수 열거 → 레이아웃 구조 분석 → definePage 설계 → widget × ui/ 부품 매칭 → Coverage 검증 → GAP 발견까지 수행한다. "레이아웃 설계", "앱 만들어봐", "화면 구조", "blueprint", "definePage로 설계", "~처럼 만들면", "Gmail 레이아웃" 등을 말할 때 사용. 코드를 편집하지 않고 preview만 출력한다. /go 전에 청사진을 먼저 잡고 싶을 때 사용. |
LLM이 앱 레이아웃을 설계할 때 가장 큰 문제는 기능 누락이다. 머릿속 인상으로 "Gmail은 사이드바 + 메일 목록 + 읽기 창"이라고 떠올리지만, 스누즈/라벨 관리/다중 선택 일괄 작업/검색 필터 같은 것을 빠뜨린다. blueprint는 먼저 기능을 전수 열거하고, 레이아웃이 모든 기능을 커버하는지 검증한다.
다음 중 하나:
레이아웃을 그리기 전에 7축으로 기능을 빠짐없이 열거한다. 이 단계를 건너뛰면 나중에 "이것도 있었는데" 하고 후회한다.
7축 강제 열거:
| 축 | 질문 | 채우기 |
|---|---|---|
| Entity | 어떤 데이터를 다루나? | 모든 데이터 타입 나열 |
| CRUD | 각 entity에 어떤 조작? | entity별 생성/읽기/수정/삭제 + 도메인 액션 |
| Navigation | 어떤 경로로 이동? | 화면 전환, 드릴다운, 뒤로가기 |
| View | 같은 데이터를 다르게 보는 방법? | 목록/그리드/캘린더, compact/comfortable, 탭 분류 |
| Bulk | 여러 항목에 동시에 하는 것? | 다중 선택, 일괄 삭제/이동/라벨 |
| Filter/Sort | 어떻게 걸러보나? | 검색, 필터 칩, 정렬 기준 |
| Setting | 사용자가 바꿀 수 있는 것? | 테마, 표시 밀도, 알림, 개인 설정 |
출력: 기능 목록 (Feature List). 각 항목에 ID를 부여한다.
F1. Mail: read
F2. Mail: archive
F3. Mail: delete
F4. Mail: star/unstar
F5. Mail: snooze
F6. Mail: label 추가/제거
F7. Draft: create
F8. Draft: edit
F9. Draft: send
F10. Draft: discard
F11. Navigation: Inbox→Thread
F12. Navigation: Sidebar→Label
F13. Navigation: Search→Results
F14. View: 목록 (compact/comfortable/default)
F15. View: 분할 보기 (reading pane)
F16. View: 탭 (Primary/Social/Promotions)
F17. Bulk: 다중 선택→삭제/이동/라벨/읽음 처리
F18. Filter: has:attachment, is:unread, date range
F19. Setting: 테마, 표시 밀도, 서명
...
이 목록이 나올 때까지 다음 Phase로 넘어가지 않는다.
레퍼런스 앱의 레이아웃을 ASCII art로 그린다.
┌─────────────────────────────────────┐
│ Header │
├────────┬────────────────┬───────────┤
│Sidebar │ Content │ Detail │
│ │ │ │
└────────┴────────────────┴───────────┘
각 영역의 역할을 한 줄로 정의한다:
| 영역 | 역할 | 인터랙션 |
|---|---|---|
| Header | 검색 + 네비게이션 | 검색 입력, 프로필 메뉴 |
| Sidebar | 폴더/카테고리 목록 | 선택 → Content 갱신 |
| Content | 아이템 리스트 | 선택 → Detail 표시 |
| Detail | 아이템 상세 | 읽기, 편집 |
LAYOUT.md의 10개 LayoutNode를 사용하여 definePage를 작성한다.
작성 전 체크리스트:
src/interactive-os/layout/LAYOUT.md 읽기 — 사용 가능한 노드, 조합 규칙, 패턴 카탈로그 확인출력 형식:
const appLayout = definePage({
entities: {
root: { data: { type: '...', ... }, children: ['...'] },
// ...
},
})
hidden 활용: 조건부 영역(모드 전환, 패널 show/hide)은 hidden: true/false로 선언.
overlay 활용: 모달, 팝업은 OverlayNode으로. 전역 크롬(FAB 등)은 FloatingNode으로.
각 widget이 어떤 ui/ 부품으로 조립되는지 매칭한다.
매칭 전 필수: src/interactive-os/CATALOG.md 읽기 — 있는 부품을 먼저 확인.
출력 형식:
| Widget | 조립 부품 (ui/) | 있음/없음 |
|---|---|---|
| SearchBar | Combobox + Avatar | ✅ |
| ItemList | ListBox + MailItem | ⚠️ MailItem 신규 |
매칭 규칙:
Phase 0의 모든 기능이 Phase 2~3의 widget에 배치됐는지 검증한다. 이 검증이 blueprint의 핵심 가치다 — 누락을 구조적으로 잡는다.
Coverage Matrix:
| ID | 기능 | Widget | 배치됨? |
|---|---|---|---|
| F1 | Mail: read | ReadingPane | ✅ |
| F2 | Mail: archive | MailList (swipe/toolbar) | ✅ |
| F5 | Mail: snooze | ??? | ❌ 누락 |
| F6 | Mail: label | ??? | ❌ 누락 |
| F17 | Bulk: 다중선택 | ??? | ❌ 누락 |
누락 발견 시:
❌가 0개가 될 때까지 Phase 2~3으로 돌아가서 수정한다.
Coverage 100% 달성 후, FlatLayout + ui/ 카탈로그로 안 되는 것을 명시한다.
GAP 분류:
widget이 pull할 도메인 context의 인터페이스를 설계한다.
export interface AppContextValue {
// 각 widget이 필요한 값을 나열
}
export const [AppProvider, useApp] = createDomainContext<AppContextValue>('App')
주요 사용자 동작 → FlatLayout 반응을 테이블로 정리한다.
| 동작 | FlatLayout 반응 |
|---|---|
| 아이템 선택 | Detail hidden → false |
| 모달 열기 | overlay visible → true |
definePage 코드 (preview, 파일 편집 없음)/go로 전환