菜单
에이전트가 브라우저로 제품을 직접 사용하여 문제를 발견하고 개선까지 자율 완주한다. "/use", "써봐", "직접 써봐", "QA 해봐", "사용해봐", "테스트해봐", "돌려봐", "확인해봐" 등 실사용 테스트 의도가 보이면 사용. 특정 라우트를 인자로 받을 수 있다 (예: "/use /chat", "/use /viewer"). 에이전트끼리 논의하며 개선점을 찾으라는 요청에도 사용.
用 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 | use |
| description | 에이전트가 브라우저로 제품을 직접 사용하여 문제를 발견하고 개선까지 자율 완주한다. "/use", "써봐", "직접 써봐", "QA 해봐", "사용해봐", "테스트해봐", "돌려봐", "확인해봐" 등 실사용 테스트 의도가 보이면 사용. 특정 라우트를 인자로 받을 수 있다 (예: "/use /chat", "/use /viewer"). 에이전트끼리 논의하며 개선점을 찾으라는 요청에도 사용. |
개발자는 코드 안에서 바깥을 본다 — "이 함수가 맞나?". 이 스킬은 바깥에서 안을 본다 — "사용자가 이걸 쓰면 어떤 경험인가?". 코드의 존재 ≠ 코드의 작동. @media (max-width: 768px)가 있어도 container 안에서 안 먹을 수 있다. 써봐야 나온다.
| 인자 | 기본값 | 예시 |
|---|---|---|
| URL/라우트 | http://localhost:5173/ | /chat, /viewer, /ui |
| 페르소나 | 처음 접한 사용자 | "관리자", "개발자", "디자이너" |
| 깊이 | surface (UI만) | deep — OS 아키텍트 에이전트 추가 |
Step 1: 브라우저 탐색 (GIF 녹화)
↓
Step 2: 관찰 수집 + 코드 검증 → 재분류
↓
Step 3: /discuss — 진짜 문제 구조화
↓
Step 4 (deep만): OS 아키텍트 분석
↓
Step 5: /prd → /go 자율 완주
mcp__claude-in-chrome__tabs_context_mcp로 브라우저 상태 확인| 페르소나 | 탐색 항목 |
|---|---|
| 처음 접한 사용자 | 첫 화면 인상, 네비게이션 경로, 주요 CTA 클릭, 빈 상태 |
| 관리자 | CRUD 작업, 편집 흐름, 프리뷰, 저장/취소 |
| 개발자 | 키보드 내비게이션, 접근성, 콘솔 에러, 반응형 |
브라우저에서 발견한 것을 오진 허용 목록으로 정리:
| # | 관찰 | 판정 | 근거 |
|---|------|------|------|
| 1 | 모바일에서 카드 잘림 | ⚠️ 확인 필요 | — |
| 2 | 인라인 편집 불가 | ? | 의도된 설계일 수 있음 |
그 다음 코드 조사 에이전트 디스패치:
관찰을 재분류:
재분류된 진짜 문제들로 /discuss 호출. 12요소 이해도 테이블을 채워 구조화.
deep 인자가 있을 때만 실행. 2개 에이전트를 병렬 디스패치:
에이전트 A — 소비자 우회 패턴 탐색:
에이전트 B — OS 아키텍트 갭 분석:
두 에이전트의 결과를 합성하여 OS core 개선 후보 도출.
discuss 결과로 /prd 작성 → /go 자율 실행. 일반적인 파이프라인.
매 탐색마다 아래 항목을 순회한다. 해당 없으면 스킵.
mcp__claude-in-chrome__* 도구 필요.pnpm dev를 요청.