teo-claude-code

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로 내린다.

파일 단위 단일 책임 원칙(SRP)을 점검하고 리팩토링을 수행한다. "단일 책임", "책임 분리", "파일이 너무 크다", "이 파일 쪼개자", "/srp", "/srp 300", "/goal srp 300" 등으로 트리거된다. 숫자 인자는 import/export-from 라인을 제외한 LOC 기준의 후보 발견 하한이며, 목표 라인 수나 절대 분할 기준이 아니다. 파일명과 실제 구현 책임을 대조해 책임이 1개면 유지하고, 2개 이상이면 분리 계획을 표로 명시한 뒤 분리한다.

두 방향이 양립 불가능해 보일 때 대립 해소 다이어그램(Evaporating Cloud)으로 숨겨진 전제를 찾아 돌파구(Injection)를 도출한다. "A vs B", "이러지도 저러지도", "트레이드오프", "딜레마", "양립 불가", "/conflict", "$conflict" 등을 말할 때 사용. 옹호자 A/B 서브에이전트로 양쪽 전제를 각각 최대한 강하게 세운 뒤, 중재자가 깨지는 지점을 찾는다.

코드·설계·개념을 해설하는 문서를 생성한다. 민토 피라미드 — 답을 먼저, Why를 그 다음에, 수직(왜?/어떻게?)·수평(연역/귀납)으로 피라미드를 쌓는다. Insight 제목 + Mermaid 다이어그램 최소 2개 필수. "이게 뭐야", "왜 이렇게 했어", "어떻게 작동해", "설명해줘", "/explain" 등 이해/해설 요청 시 사용. 프로젝트의 기존 문서 관행을 감지해 따르며, 관행이 없으면 사용자 확인 후 저장한다.

도메인 분석 + 유비쿼터스 언어 사전. 프로젝트의 핵심 용어·개념·관계를 대화로 추출하여 ./glossary.md에 누적한다. 3모드: (1) 파일 없으면 Init으로 초안 생성, (2) 호출 시 현재 대화 맥락에서 용어 Capture, (3) 대화 중 AI가 모르던 용어를 passive buffer에 쌓고 세션 종료 시 자동 Flush. "용어 정리", "도메인 분석", "유비쿼터스 언어", "용어 사전", "glossary", "/glossary" 등을 말할 때 사용. DDD Event Storming·Bounded Context 같은 방법론 의례는 포함하지 않는다 — 용어·관계·동의어·맥락 구분만.

방향은 합의됐는데 "다 되면 어떤 모습인지"가 아직 추상적일 때, 이상적 결과를 구체적 산출물(코드·표·다이어그램·저니맵)로 시뮬레이션한다. "이상적으로는...", "결과물이 어떤 모습이어야", "다 되면 어떻게 생겼을까", "API가 어떻게 보여야", "사용자 경험이 어떨지", "/ideal" 등을 말할 때 사용. 추상적 합의("좋은 걸 만들자")를 "이게 맞나?"를 판단할 수 있는 구체 산출물로 바꾸는 것이 목적이다.

파편화된 생각을 민토 피라미드로 구조화하여 논리적 빈칸을 찾는다. 사용자의 메모, 아이디어, 강의 노트 등을 입력받아 피라미드로 재배치하고 깊이 있는 질문을 한다. "정리해줘", "구조화", "논리 검증", "피라미드", "민토", "SCQA", "/minto" 등을 말할 때 사용.

네이밍 일관성(consistency)과 적합성(aptness) 감사. 동의어 드리프트, 형식 불일치, 패턴 과적, 역할 분산을 감지한다. "/naming-audit", "이름 점검", "네이밍 확인", "네이밍 일관성" 등을 말할 때 사용. 프로젝트에 전용 수집 스크립트(scripts/namingReport.ts 등)가 있으면 그걸 쓰고, 없으면 ripgrep/grep으로 직접 수집한다.

반복된 패치가 먹히지 않거나 같은 불만이 계속 들어올 때 멈추고 문제를 다시 이해한다. 사용자가 "아닌데", "이게 아니야", "그거 아니라고", "왜 자꾸 그래", "다시 생각해", "/reframe" 등 현재 수정 방향에 불만을 표현하면 사용. "고장난 걸 고치는" 상황이 아니라 "뭘 고치는지 자체를 잘못 이해한" 상황에 대응한다.

과제를 수행할 에이전트 팀을 편성한다. 필수 3역할(계획자/실행자/평가자) + 과제 특화 페르소나 + 팀 내 커뮤니케이션 프로토콜을 설계한다. "/team", "팀 짜줘", "누구를 붙일까", "에이전트 편성", "팀 구성", "병렬로" 등을 말할 때 사용. 실행 단계 진입 전, Task/Agent 디스패치로 병렬 실행할 때 편성표가 필요할 때.

발견된 안티패턴을 훅 하네스로 전환한다. "이거 하지 마", "이건 안티패턴", "훅으로 막아", "하네스 만들어", "antipattern", "/antipattern" 등으로 트리거. 메모리에 기록하는 게 아니라 guardOsPatterns.mjs 등의 훅에 정적 검사 규칙을 추가하여 구조적으로 재발을 차단하는 것이 목적이다. 정적 탐지가 어려운 경우는 프로젝트 안티패턴 매뉴얼 파일에 추가한다. 안티패턴을 발견했을 때, 또는 코드리뷰 중 "이건 하면 안 돼"라는 피드백이 나왔을 때 사용한다.

자율 파이프라인 트리거. /discuss로 문제를 구조화하고 /team으로 편성한 뒤 자율 실행한다. "/auto", "끝까지 알아서", "파이프라인 자동", "무인 실행" 등을 말할 때 사용.

앱 레이아웃을 FlatLayout definePage로 설계한다. 요구사항이나 레퍼런스 앱 이름을 받아 기능 전수 열거 → 레이아웃 구조 분석 → definePage 설계 → widget × ui/ 부품 매칭 → Coverage 검증 → GAP 발견까지 수행한다. "레이아웃 설계", "앱 만들어봐", "화면 구조", "blueprint", "definePage로 설계", "~처럼 만들면", "Gmail 레이아웃" 등을 말할 때 사용. 코드를 편집하지 않고 preview만 출력한다. /go 전에 청사진을 먼저 잡고 싶을 때 사용.

레퍼런스 웹사이트에서 디자인 토큰을 실측 추출하여 DESIGN.md와 tokens.css를 생성한다. "디자인 시스템 만들어줘", "이 사이트 디자인 따라해", "레퍼런스 디자인 추출", "토큰 추출", "디자인 토큰 뽑아줘", "/design-extract" 등을 말할 때 사용. 디자인 관련 작업에서 LLM이 "평균적인 디자인"을 생성하는 문제를 해결한다 — 생성이 아니라 실측 수치 추출이 핵심.

디자인 결정을 discuss 스타일로 점진 구체화한다. LLM이 widget부터 조립하지 않고 디자이너의 사고 순서(Job → Content → Priority → Hierarchy → Component)를 따르도록 강제한다. 한 번에 완성하지 않고 매 턴 이해도 🔴🟡🟢을 갱신하며 13 결정을 채운다. Blueprint/구현 단계 앞에 위치하며 "디자인 사고", "화면 brief", "시각 의사결정", "/design-think" 등 시각 결정 필요 시 사용. /blueprint → /go 파이프라인의 선행 스킬.

Use this skill whenever the user asks Claude to build, mock, design, or lay out a UI screen — Gmail clone, dashboard, settings page, anything visual — EVEN when they say "just build it" or "quickly make a screen." This skill forces Claude to think like a designer (Job → Content → Priority → Hierarchy) BEFORE picking components, instead of the default "grab widgets and assemble" pattern that produces functional-but-broken output (truncated chips, invisible stars, no unread contrast). Runs as a discuss-style turn-by-turn dialog with a 🔴🟡🟢 understanding table across 13 design decisions. Triggers on "design this", "make a screen", "UI for X", "build the Y page", "mock up Z", and similar — also when you catch yourself about to write widget code without a decision trail. Sits before /blueprint and /go in the pipeline.

가장 최근 작업물이 고장났을 때 자동 재현→디버깅→수정. "/fix", "안 돼", "고장", "왜 안 돼", "방금 만든 거 안 돼" 등 문제 보고 시 사용. /debugging보다 짧고, "뭐가 고장났는지"를 자동 추론하는 Step 0이 추가됨. repro recorder JSON이 첨부되면 그것을 재현 증거로 사용.

자율 실행 오케스트레이터. /team 편성표를 소비하여 TaskCreate + Agent 디스패치로 작업을 자율 완주한다. "/go", "실행해", "만들어줘" 등 구현 요청 시 사용.

작업을 깔끔하게 마무리하거나 다음 세션으로 이어 넘기는 단일 오케스트레이터. 산업 표준 GitHub Flow (branch → commit → push → PR → CI → merge → cleanup) 위에 프로젝트 특유의 A0 역PRD 감사 + A1 verify 6단 + A8~A9 미완료 계승을 덧댄다. Blueprint PRD가 있으면 역PRD 체크리스트를 먼저 채우고 Blueprint ⊃ Implementation 검증을 통과해야 나머지 단계가 진행된다. 세션 시작 시 `/handoff`를 치면 가장 최근 미소비 handoff를 이어받는다. "/handoff", "마무리", "닫자", "정리하자", "여기까지", "다음에 이어서", "중단" 등 명시적 의도 표현 시 사용. **사용자가 명시적으로 호출할 때만 실행한다. AI가 자율 판단으로 발동하지 않는다.**

정보 구조(IA) 설계. story의 화면 목록을 받아 사이트맵, 네비게이션 구조, 화면별 콘텐츠 모델을 인터뷰로 채워간다. "IA", "정보 구조", "사이트맵", "네비게이션 설계", "화면 구조", "/ia" 등을 말할 때 사용. /story 이후, /wireframe 이전에 위치한다.

릴리즈 품질 루프. 기능이 아니라 사용자의 Job을 기준으로 제품을 평가하고 개선한다. "개선해", "품질 올려", "릴리즈 수준으로", "더 다듬어", "/improve" 등을 말할 때 사용. /go 이후 또는 단독 호출 가능.

FlatLayout definePage + widget의 구조를 체크리스트로 평가하고 수렴 루프를 돌려 개선한다. 텍스트 체크(L1/L2) + 스샷 검증(L3)의 3층 교차 구조. "레이아웃 평가", "definePage 점수", "이 페이지 레이아웃 봐줘", "/layout-score" 등을 말할 때 사용. 구조 단위 책임 경계를 검증한다.

Use this skill whenever the user asks Claude to design, prototype, lay out, or visually build a UI screen — BEFORE /go or /blueprint's Phase 3. This skill runs a multi-turn fidelity-ladder loop (Data → Importance → Low-fi wireframe → Mid-fi → Hi-fi) where each turn consumes one step, produces a concrete artifact (schema file, screenshot, etc.), and gates progress with explicit completion criteria — the user must approve before the next phase. Unlike one-shot design tools, this skill uses turns like /discuss does, showing actual rendered screenshots at each fidelity tier so the user SEES the design before committing to implementation. Triggers on "design this screen", "mock up", "let's prototype", "how should this look", "make a screen for X", and implicit cues like "Gmail clone" or "dashboard for Y" where visual validation matters before real implementation.

오래된 inbox 문서(type=inbox, status 미소비)를 읽고 frontmatter의 type/status/project/layer/tags를 적절히 승격시켜 지식으로 편입시킨다. "inbox 정리", "문서 정리", "para", "/para" 등 inbox 관리 의도가 보이면 사용. inbox 문서가 쌓여있을 때 주기적으로 사용을 제안해도 좋다.

제품 수준 화면 검증 테스트 작성. 사용자 입력(click/keyboard) → 화면 변화(라우트/DOM 시각 상태) 검증. 소스 코드 구조와 무관하게 요구사항을 검증한다. 개발 사이클 완료 후 TDD 메커니즘 테스트를 제품 수준으로 승격할 때, 또는 "화면 테스트", "통합 테스트 만들어", "이 기능 테스트", "/screen-test" 등을 말할 때 사용.

에이전트가 브라우저로 제품을 직접 사용하여 문제를 발견하고 개선까지 자율 완주한다. "/use", "써봐", "직접 써봐", "QA 해봐", "사용해봐", "테스트해봐", "돌려봐", "확인해봐" 등 실사용 테스트 의도가 보이면 사용. 특정 라우트를 인자로 받을 수 있다 (예: "/use /chat", "/use /viewer"). 에이전트끼리 논의하며 개선점을 찾으라는 요청에도 사용.

화면별 ui/ 부품 매칭 + 인터랙션 매트릭스 작성 + 적합성 검증. ia의 콘텐츠 모델을 받아 각 영역을 os 부품으로 조립한다. "와이어프레임", "부품 매칭", "컴포넌트 설계", "인터랙션 설계", "/wireframe" 등을 말할 때 사용. /ia 이후, /prd 이전에 위치한다.