القائمة
화면별 ui/ 부품 매칭 + 인터랙션 매트릭스 작성 + 적합성 검증. ia의 콘텐츠 모델을 받아 각 영역을 os 부품으로 조립한다. "와이어프레임", "부품 매칭", "컴포넌트 설계", "인터랙션 설계", "/wireframe" 등을 말할 때 사용. /ia 이후, /prd 이전에 위치한다.
التثبيت باستخدام 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 | wireframe |
| description | 화면별 ui/ 부품 매칭 + 인터랙션 매트릭스 작성 + 적합성 검증. ia의 콘텐츠 모델을 받아 각 영역을 os 부품으로 조립한다. "와이어프레임", "부품 매칭", "컴포넌트 설계", "인터랙션 설계", "/wireframe" 등을 말할 때 사용. /ia 이후, /prd 이전에 위치한다. |
memory/MEMORY.md를 읽어 기존 맥락을 로드한다.
너는 인터랙션 설계자다. /ia에서 설계한 화면 구조를 받아, 각 영역을 기존 ui/ 부품으로 조립하고 인터랙션을 검증한다. 산출물은 구현 전 마지막 설계도다.
discuss → /story → /ia (화면 구조) → /wireframe (부품 조립) → /prd → /go
| 산출물 | 질문 | 형식 |
|---|---|---|
| 부품 매칭표 | 각 영역이 어떤 ui/ 부품인가? | 영역-부품 매핑 테이블 |
| 인터랙션 매트릭스 | 각 부품에서 어떤 입력이 어떤 결과를 만드는가? | 입력-결과 테이블 |
| 적합성 검증 | 매칭한 부품이 요구 인터랙션을 커버하는가? | 검증 체크리스트 |
ia의 콘텐츠 모델 각 영역에 ui/ 부품을 매핑한다.
| 화면 | 영역 | 인터랙션 요약 (ia에서) | ui/ 부품 | APG 패턴 | 근거 |
|---|---|---|---|---|---|
| Quick Open | 검색+결과 | 타이핑→필터, 키보드 이동, Enter 선택 | QuickOpen | combobox | input+리스트 순회 = combobox |
| Quick Open | 그룹 헤더 | 읽기 전용 | (QuickOpen 내부) | — | 구조적 라벨 |
| 사이드바 | 트리 | 펼침/접힘, 선택, 키보드 이동 | TreeGrid | treegrid | 계층+선택+펼침 |
매칭 알고리즘:
ia 인터랙션 요약에서 핵심 동작을 추출한다:
src/interactive-os/ui/ 디렉토리를 스캔하여 사용 가능한 부품 목록을 확인한다
매칭 후보가 여러 개이면 가장 구체적인 것을 선택한다:
부품별로 모든 입력 채널(키보드, 마우스, 포커스)의 동작을 나열한다.
| 부품 | 입력 | 조건 | 결과 |
|---|---|---|---|
| QuickOpen | 타이핑 | 입력창 포커스 | 결과 필터링 |
| QuickOpen | ArrowDown | 입력창 포커스 | 다음 항목으로 이동 |
| QuickOpen | ArrowUp | 입력창 포커스 | 이전 항목으로 이동 |
| QuickOpen | Enter | 항목 선택됨 | 해당 항목 활성화 + 닫힘 |
| QuickOpen | Escape | 열려 있음 | 닫힘 |
| QuickOpen | 클릭 (항목) | — | 해당 항목 활성화 + 닫힘 |
| QuickOpen | 클릭 (배경) | — | 닫힘 |
빈칸 = 놓친 인터랙션. 매트릭스를 채운 뒤 빈칸이 있으면 해당 인터랙션을 추가할지 사용자에게 확인한다.
매칭한 부품이 인터랙션 매트릭스의 모든 행을 커버하는지 확인한다.
| 검증 항목 | 질문 | 판정 |
|---|---|---|
| 패턴 커버리지 | 부품의 APG 패턴이 매트릭스의 모든 키보드 동작을 지원하는가? | 🟢/🔴 |
| 포커스 모델 | 입력창과 리스트가 동시에 존재할 때 포커스가 어디에 있어야 하는가? | 🟢/🔴 |
| 그룹핑 | 부품이 그룹 구조를 지원하는가? (필요한 경우) | 🟢/🔴 |
| 오버레이 | 부품이 오버레이로 동작할 수 있는가? (필요한 경우) | 🟢/🔴 |
| 기존 사례 | 프로젝트 내에서 이 부품이 비슷한 맥락으로 사용된 적 있는가? | 참조 |
🔴가 하나라도 있으면:
/wireframe <service> — service는 서비스 이름 (예: book, cms)
docs/YYYY/YYYY-MM/YYYY-MM-DD/{service}Wireframes.md (frontmatter: type: wireframe, project: <service>)
/ia 산출물(ia.md)이 있으면 콘텐츠 모델을 읽어 부품 매칭 초안을 만든다# <Service Name> — Wireframe
## Component Mapping (부품 매칭표)
| 화면 | 영역 | 인터랙션 요약 | ui/ 부품 | APG 패턴 | 근거 |
|------|------|-------------|---------|----------|------|
## Interaction Matrix (인터랙션 매트릭스)
| 부품 | 입력 | 조건 | 결과 |
|------|------|------|------|
## Validation (적합성 검증)
| 부품 | 패턴 커버리지 | 포커스 모델 | 그룹핑 | 오버레이 | 기존 사례 |
|------|-------------|-----------|--------|---------|----------|
src/interactive-os/ui/ 디렉토리를 읽어 사용 가능한 부품 목록을 확인한다부품 매칭이 완료되면 각 부품의 인터랙션을 상세히 나열한다.
입력 채널 3가지를 반드시 순회한다:
각 행은 "입력 → 조건 → 결과" 형식이다
AI가 먼저 매트릭스를 채우고 사용자에게 검토를 요청한다
매트릭스 작성이 완료되면 검증에 진입한다.
각 부품에 대해 5개 질문을 순회한다:
패턴 커버리지: 매트릭스의 키보드 행 각각이 APG 패턴에서 지원되는가?
src/interactive-os/pattern/ 또는 src/interactive-os/plugins/에서 해당 키 핸들링 존재 여부포커스 모델: 부품의 포커스 관리가 UI 구조와 맞는가?
그룹핑: 데이터에 그룹 구조가 있고, 부품이 그룹을 렌더링할 수 있는가?
오버레이: 화면 유형이 오버레이인데, 부품이 dialog/popup으로 동작할 수 있는가?
기존 사례: src/pages/ 또는 src/interactive-os/ui/에서 동일 부품의 사용례를 찾아 참조한다
🔴 항목이 있으면 3단계로 대응한다:
## Wireframe 완성
| 산출물 | 항목 수 | 상태 |
|--------|---------|------|
| 부품 매칭 | N개 영역 | 🟢 |
| 인터랙션 매트릭스 | N개 행 | 🟢 |
| 적합성 검증 | N개 부품 전부 통과 | 🟢 |
### 부품 요약
- W1 메인 캔버스: TreeGrid (treegrid)
- W2 Quick Open: QuickOpen (combobox)
- ...
다음 단계:
- 특정 화면을 `/prd`로 명세하려면 → "W1을 PRD로"
- 전체를 `/prd`로 → "/prd <service>"
/prd, /go 등 다른 스킬 호출