菜单
방향은 합의됐는데 "다 되면 어떤 모습인지"가 아직 추상적일 때, 이상적 결과를 구체적 산출물(코드·표·다이어그램·저니맵)로 시뮬레이션한다. "이상적으로는...", "결과물이 어떤 모습이어야", "다 되면 어떻게 생겼을까", "API가 어떻게 보여야", "사용자 경험이 어떨지", "/ideal" 등을 말할 때 사용. 추상적 합의("좋은 걸 만들자")를 "이게 맞나?"를 판단할 수 있는 구체 산출물로 바꾸는 것이 목적이다.
用 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 | ideal |
| description | 방향은 합의됐는데 "다 되면 어떤 모습인지"가 아직 추상적일 때, 이상적 결과를 구체적 산출물(코드·표·다이어그램·저니맵)로 시뮬레이션한다. "이상적으로는...", "결과물이 어떤 모습이어야", "다 되면 어떻게 생겼을까", "API가 어떻게 보여야", "사용자 경험이 어떨지", "/ideal" 등을 말할 때 사용. 추상적 합의("좋은 걸 만들자")를 "이게 맞나?"를 판단할 수 있는 구체 산출물로 바꾸는 것이 목적이다. |
"다 되면 어떤 모습인가?"에 대한 답이 추상적일 때, 도메인에 맞는 시뮬레이션을 함께 만들어서 구체화한다.
추상적 합의는 위험하다. "좋은 API를 만들자"에 모두가 동의하지만, "좋은"의 의미가 각자 다르다. 이 스킬은 구체적 산출물을 먼저 만들어서 "이게 맞나?"를 판단할 수 있게 한다. README-driven development, consumer-first API design, journey mapping 등의 기법을 상황에 맞게 적용한다.
사용자의 맥락에서 도메인을 판별한다:
| 도메인 | 시그널 | 시뮬레이션 도구 |
|---|---|---|
| 개발 | hook, API, SDK, 컴포넌트, 함수 | Code Usage 시뮬레이션 |
| 경험 | 사용자 흐름, 온보딩, 워크플로우 | 저니맵 |
| 설계 | 아키텍처, 모듈, 레이어, 의존성 | Mermaid 다이어그램 |
| 데이터 | 스키마, 타입, 필드, 모델 | 스키마 네이밍 + 샘플 데이터 |
도메인이 겹치면 (예: "SDK의 사용자 경험") 주 도메인 하나를 선택하고, 나머지는 보조로 활용한다. 판단이 모호하면 사용자에게 확인한다.
핵심 원칙: 구현이 아니라 소비를 먼저 쓴다.
사용자가 만들려는 것을 "쓰는 쪽"의 코드를 먼저 작성한다. 내부 구현이 아니라, 완성된 후 소비자가 작성할 코드의 모습을 상상한다.
1. 가장 흔한 사용 시나리오의 코드를 작성한다
2. "이 코드가 자연스러운가?" 판단한다
3. 엣지 케이스 시나리오 1~2개를 추가한다
4. 시나리오들에서 API 시그니처를 역추출한다
예시:
// ❌ 구현부터 생각하기
function useTreeView(options: TreeViewOptions) { ... }
// ✅ 사용부터 생각하기
// 시나리오 1: 파일 탐색기
const tree = useTreeView(fileData)
return <nav {...tree.containerProps}>
{tree.items.map(item => <div {...item.props}>{item.label}</div>)}
</nav>
// 시나리오 2: 설정 메뉴 (깊이 제한)
const menu = useTreeView(settingsData, { maxDepth: 2 })
// → 역추출된 API: useTreeView(data, options?) → { containerProps, items }
작성한 usage 코드를 사용자에게 보여주고 "이 코드를 쓰고 싶은가?" 확인한다. 자연스럽지 않은 부분이 있으면 그게 곧 설계의 갭이다.
사용자의 경험을 시간 순서대로 시뮬레이션한다.
| 단계 | 행동 | 생각/감정 | 터치포인트 | 문제점 |
|------|------|----------|-----------|--------|
| 1. 진입 | ... | ... | ... | ... |
| 2. 탐색 | ... | ... | ... | ... |
| 3. 핵심 행동 | ... | ... | ... | ... |
| 4. 완료 | ... | ... | ... | ... |
빈 표를 먼저 만들고, 단계를 사용자와 함께 채운다. "이 단계에서 사용자가 뭘 느끼는가?"가 핵심 질문이다.
모듈 관계를 시각화한다.
1. 핵심 모듈 3~5개를 식별한다
2. 모듈 간 의존성/데이터 흐름을 Mermaid로 그린다
3. "이 화살표가 맞는가?" 확인한다
4. 빠진 모듈이나 잘못된 의존성을 발견한다
다이어그램은 현재 상태가 아니라 이상적 상태를 그린다. 현재 상태와의 차이가 곧 할 일 목록이 된다.
타입/스키마의 필드명과 구조를 구체화한다. 네이밍이 곧 설계이므로, 이름을 먼저 정하면 구조가 따라온다.
1. 핵심 타입의 필드를 나열한다 (이름 + 타입)
2. 샘플 데이터 2~3행을 채운다
3. "이 필드명이 자연스러운가?" 판단한다
4. 필드명에서 누락된 개념이나 중복을 발견한다
예시:
// 필드명 초안
type Section = {
id: string
title: string
items: Item[]
layout: 'grid' | 'list' // ← 이 필드명이 맞나?
}
// 샘플 데이터로 검증
const sample: Section = {
id: 'hero',
title: '메인 배너',
items: [{ ... }],
layout: 'grid' // ← "grid"가 레이아웃인가 표시 방식인가?
}
// → "layout"보다 "display"? "variant"? 네이밍 논의 시작점
샘플 데이터를 채우면 추상적이던 스키마에서 어색한 이름, 빠진 필드, 불필요한 필드가 드러난다.
시뮬레이션 결과에서 자연스럽게 갭이 드러난다:
발견된 갭을 정리하여 사용자에게 보여준다.
다음 조건을 모두 만족하면 완료:
완료되면 산출물과 발견된 갭을 요약하여 제시한다. 결과는 이후 설계·명세·구현 단계의 입력으로 쓰일 수 있다.
## 시뮬레이션: [도메인]
[산출물 — 코드/표/다이어그램]
### 발견된 갭
- 갭 1: ...
- 갭 2: ...
### 질문
제 판단: [판단]. 이유: [근거].
[구체화 질문]
/ideal 또는 "이상적으로는…", "다 되면 어떤 모습" 같은 신호로 바로 진입/discuss 드릴다운 — 상위 논의에서 "이상적 결과" 요소가 막힐 때(이해도 낮음) 이 스킬로 드릴다운하여 구체 산출물을 만들고, 결과·갭을 상위 논의의 해당 요소에 반영하여 복귀