Initial commit

.trae/skills/agent-browser/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: "agent-browser"
+description: "브라우저 자동화 CLI를 사용해 웹사이트를 탐색하고 조작합니다. 페이지 이동, 폼 입력, 클릭, 스크린샷, 데이터 추출, 웹앱 테스트가 필요할 때 호출합니다."
+---
+
+# Agent Browser
+
+에이전트를 위한 빠른 브라우저 자동화 CLI 가이드입니다. 웹사이트 탐색, 폼 입력, 버튼 클릭, 스크린샷 촬영, 데이터 추출, 웹앱 테스트, 탐색적 QA 등에 사용합니다.
+
+## 언제 사용할지
+
+다음과 같은 요청에서 우선 사용합니다.
+
+- 웹사이트를 열어 달라고 할 때
+- 폼을 입력하거나 버튼을 클릭해야 할 때
+- 페이지 스크린샷이 필요할 때
+- 웹페이지 데이터를 추출하거나 스크래핑할 때
+- 웹앱을 실제 브라우저에서 테스트할 때
+- 로그인, QA, 버그 재현, 탐색적 테스트가 필요할 때
+
+Electron 기반 데스크톱 앱이나 Slack 자동화 같은 확장 작업에도 활용할 수 있습니다.
+
+## 시작 방법
+
+`agent-browser` 명령을 바로 사용하기 전에, 설치된 버전에 맞는 실제 가이드를 CLI에서 불러옵니다.
+
+```bash
+agent-browser skills get core
+```
+
+전체 명령과 템플릿까지 포함해 보고 싶다면:
+
+```bash
+agent-browser skills get core --full
+```
+
+이 스킬 문서는 시작점 역할만 합니다. 실제 사용 절차와 최신 명령 형식은 항상 CLI가 제공하는 가이드를 기준으로 확인합니다.
+
+## 특수 가이드
+
+작업 성격에 따라 아래 보조 가이드를 불러올 수 있습니다.
+
+- `agent-browser skills get electron`
+- `agent-browser skills get slack`
+- `agent-browser skills get dogfood`
+- `agent-browser skills get vercel-sandbox`
+- `agent-browser skills get agentcore`
+
+사용 가능한 전체 목록은 아래 명령으로 확인합니다.
+
+```bash
+agent-browser skills list
+```
+
+## 기본 사용 흐름
+
+1. 먼저 `agent-browser skills get core`로 현재 버전 가이드를 읽습니다.
+2. 작업이 웹 브라우저인지, Electron인지, Slack인지 성격을 구분합니다.
+3. 필요하면 해당 특수 가이드를 추가로 읽습니다.
+4. 세션을 열고 탐색, 선택, 입력, 클릭, 추출 같은 실제 작업을 진행합니다.
+5. 스크린샷, 상태 저장, 기록 기능이 필요하면 그 옵션을 함께 사용합니다.
+
+## 장점
+
+- 빠른 네이티브 CLI 기반 동작
+- Chrome/Chromium 제어
+- 접근성 트리 기반 스냅샷과 안정적인 요소 참조
+- 세션 유지, 인증 저장, 상태 지속성 지원
+- 영상 기록 및 다양한 특수 자동화 시나리오 지원
+
+## 운영 원칙
+
+- 내장 웹 도구보다 `agent-browser`가 더 적합한 작업이면 이를 우선 사용합니다.
+- 현재 설치된 버전의 CLI가 제공하는 가이드를 기준으로 작업합니다.
+- 오래된 문서 기억보다, 실행 중인 버전의 `skills get` 결과를 신뢰합니다.
+
+## 언제 특히 유용한가
+
+- 실제 브라우저 상호작용이 길거나 반복적일 때
+- 접근성 트리 기준의 안정적인 요소 선택이 필요할 때
+- 상태 지속, 인증, 녹화, 세션 관리가 중요한 테스트일 때
+- 단순 스크래핑이 아니라 탐색적 QA나 실제 사용자 흐름 재현이 필요할 때
+
+## 안티 패턴
+
+- 설치된 버전을 확인하지 않고 예전 명령 기억으로 바로 실행하는 방식
+- 일반 웹 도구로 충분한 작업인데 굳이 복잡한 세션을 여는 방식
+- 작업 성격이 특수 가이드 대상인데 core만 읽고 끝내는 방식
+
+## 기대 결과
+
+이 스킬을 적용한 결과는 다음을 만족해야 합니다.
+
+- 현재 설치된 버전 기준으로 정확한 사용 절차를 따른다
+- 작업 유형에 맞는 특수 가이드를 선택한다
+- 브라우저 자동화가 실제 목표에 맞게 안정적으로 수행된다

.trae/skills/brainstorming/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: "brainstorming"
+description: "구현 전에 아이디어를 질문과 설계안으로 구체화합니다. 기능 추가, 동작 변경, 신규 개발처럼 창의적 작업을 시작하기 전에 반드시 호출합니다."
+---
+
+# 아이디어를 설계로 구체화하기
+
+자연스러운 협업형 대화를 통해 아이디어를 완성도 높은 설계와 명세로 바꿉니다.
+
+먼저 현재 프로젝트 문맥을 이해한 뒤, 질문을 한 번에 하나씩 하면서 아이디어를 구체화합니다. 무엇을 만들지 충분히 이해했다면 설계를 제시하고 사용자 승인을 받습니다.
+
+<HARD-GATE>
+설계를 제시하고 사용자 승인을 받기 전까지는 구현 스킬 호출, 코드 작성, 프로젝트 스캐폴딩, 기타 구현 행동을 해서는 안 됩니다. 이 규칙은 작업이 얼마나 단순해 보이든 항상 적용됩니다.
+</HARD-GATE>
+
+## 안티 패턴: "이건 너무 단순해서 설계가 필요 없다"
+
+모든 작업은 이 과정을 거쳐야 합니다. 할 일 목록, 단일 함수 유틸리티, 설정 변경도 예외가 아닙니다. "단순한" 작업일수록 검증되지 않은 가정 때문에 불필요한 재작업이 생기기 쉽습니다. 설계는 짧아도 되지만, 반드시 제시하고 승인을 받아야 합니다.
+
+## 체크리스트
+
+아래 항목별로 작업을 만들고, 순서대로 완료해야 합니다.
+
+1. **프로젝트 문맥 탐색** - 파일, 문서, 최근 커밋 확인
+2. **시각 보조 도구 제안** - 시각적 질문이 예상되면 별도 메시지로 제안
+3. **명확화 질문 진행** - 한 번에 하나씩 질문하며 목적, 제약, 성공 기준 파악
+4. **2~3개 접근법 제안** - 트레이드오프와 추천안 포함
+5. **설계 제시** - 복잡도에 맞춰 섹션별로 설명하고 승인 받기
+6. **설계 문서 작성** - `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`에 저장
+7. **명세 자체 점검** - placeholder, 모순, 모호성, 범위 확인
+8. **사용자 문서 검토** - 구현 전 설계 문서 검토 요청
+9. **구현 단계 전환** - 다음 단계로 `writing-plans` 스킬 호출
+
+## 프로세스 흐름
+
+기본 흐름은 아래와 같습니다.
+
+1. 현재 프로젝트 문맥을 탐색합니다.
+2. 필요한 경우 시각 보조 도구를 별도 메시지로 제안합니다.
+3. 질문을 한 번에 하나씩 하며 요구를 구체화합니다.
+4. 2~3개의 접근법을 비교하고 추천안을 제시합니다.
+5. 설계를 섹션 단위로 설명하며 단계적으로 승인을 받습니다.
+6. 승인된 설계를 문서로 저장합니다.
+7. 문서를 스스로 점검해 빈칸, 모순, 모호함을 제거합니다.
+8. 사용자에게 문서 검토를 요청합니다.
+9. 승인이 끝나면 다음 단계로 `writing-plans`를 호출합니다.
+
+## 프로세스
+
+**아이디어 이해**
+
+- 먼저 현재 프로젝트 상태를 확인합니다.
+- 요청이 여러 독립 하위 시스템을 포함하면, 세부 질문 전에 먼저 분해가 필요한지 판단합니다.
+- 하나의 명세로 다루기 너무 크다면 하위 프로젝트로 나누고, 첫 번째 하위 프로젝트만 일반 설계 흐름으로 진행합니다.
+- 적절한 범위라면 질문을 한 번에 하나씩 하며 구체화합니다.
+- 가능하면 객관식 질문을 우선 사용하되, 필요하면 서술형도 사용합니다.
+- 각 메시지에는 질문 하나만 포함합니다.
+- 목적, 제약 조건, 성공 기준을 이해하는 데 집중합니다.
+- 너무 일찍 구현 방향으로 뛰어들지 말고, 범위와 기대 결과를 먼저 고정합니다.
+- "간단해 보인다"는 이유로 질문 단계를 생략하지 않습니다.
+
+**접근법 탐색**
+
+- 서로 다른 2~3개의 접근법을 제안합니다.
+- 각 접근법의 장단점과 추천 이유를 함께 설명합니다.
+- 추천안을 먼저 제시하고, 왜 그 선택이 적합한지 설명합니다.
+- 접근법은 기능 관점뿐 아니라 유지보수, 테스트 용이성, 사용자 경험까지 함께 비교합니다.
+
+**설계 제시**
+
+- 무엇을 만들지 충분히 이해했다면 설계를 제시합니다.
+- 각 섹션은 복잡도에 맞게 짧게 또는 자세히 설명합니다.
+- 각 섹션 뒤에는 지금까지 맞는지 확인을 요청합니다.
+- 아키텍처, 구성요소, 데이터 흐름, 오류 처리, 테스트를 다룹니다.
+- 이해되지 않는 부분이 있으면 다시 질문하고 명확히 합니다.
+- 한 번에 모든 내용을 밀어 넣기보다, 사용자가 따라올 수 있는 단위로 나눠 검증합니다.
+
+**격리와 명확성을 고려한 설계**
+
+- 시스템을 명확한 목적을 가진 작은 단위로 나눕니다.
+- 각 단위는 잘 정의된 인터페이스로 통신하고, 독립적으로 이해 및 테스트 가능해야 합니다.
+- 각 단위에 대해 "무엇을 하는가, 어떻게 사용하는가, 무엇에 의존하는가"를 설명할 수 있어야 합니다.
+- 내부 구현을 몰라도 역할을 이해할 수 있어야 하며, 내부를 바꿔도 소비자가 깨지지 않아야 합니다.
+- 파일이 지나치게 커지면 책임이 과도하게 섞였다는 신호로 봅니다.
+
+**기존 코드베이스에서 작업할 때**
+
+- 변경 제안 전에 현재 구조와 패턴을 먼저 탐색합니다.
+- 현재 작업에 영향을 주는 구조적 문제는 설계에 포함해 개선할 수 있습니다.
+- 현재 목표와 무관한 리팩터링은 제안하지 않습니다.
+
+## 설계 제시 규칙
+
+- 섹션별로 끊어서 설명하고, 각 섹션 뒤에 확인을 받습니다.
+- 설계는 복잡도에 맞춰 짧게 또는 자세히 조절합니다.
+- 구조, 데이터 흐름, 오류 처리, 테스트 전략을 빠뜨리지 않습니다.
+- 사용자가 "지금까지 맞다"고 확인하기 전까지 다음 단계로 밀어붙이지 않습니다.
+
+## 금지 사항
+
+- 설계 승인 전에 구현 스킬 호출
+- 설계 승인 전에 코드 작성
+- 질문 여러 개를 한 번에 던지는 방식
+- 대안 비교 없이 단일 해법만 제시하는 방식
+- 현재 목표와 무관한 대형 리팩터링 제안
+- 사용자 검토 없이 바로 구현 계획 또는 구현으로 넘어가는 방식
+
+## 설계 후 단계
+
+**문서화**
+
+- 승인된 설계를 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`에 작성합니다.
+- 사용자가 다른 문서 위치를 선호하면 그 경로를 우선합니다.
+- 가능하면 명확하고 간결한 문체를 유지합니다.
+
+**명세 자체 점검**
+
+설계 문서를 작성한 뒤 아래 항목을 빠르게 확인합니다.
+
+1. **Placeholder 점검** - `TBD`, `TODO`, 미완성 섹션, 모호한 요구사항이 있는지 확인
+2. **내부 일관성 점검** - 섹션끼리 모순되지 않는지 확인
+3. **범위 점검** - 단일 구현 계획으로 충분한 범위인지 확인
+4. **모호성 점검** - 여러 해석이 가능한 요구사항을 하나로 명확히 고정
+
+문제가 있으면 문서 안에서 바로 수정하고 진행합니다.
+
+**사용자 검토 게이트**
+
+설계 검토가 끝나면, 구현 계획으로 넘어가기 전에 사용자에게 작성된 명세 문서를 검토해 달라고 요청합니다.
+
+예시 문구:
+
+> 명세를 `<path>` 에 작성했습니다. 구현 계획을 쓰기 전에 변경하고 싶은 점이 있는지 검토해 주세요.
+
+사용자가 승인할 때까지 기다립니다. 변경 요청이 있으면 수정하고 다시 점검합니다.
+
+**구현 전환**
+
+- 다음 단계에서는 `writing-plans` 스킬을 호출합니다.
+- 다른 구현 스킬을 먼저 호출하지 않습니다.
+
+## 기대 결과
+
+이 스킬의 결과물은 다음을 만족해야 합니다.
+
+- 사용자 의도가 구조화된 설계 문장으로 정리되어 있어야 합니다.
+- 구현 전에 범위와 성공 기준이 합의되어 있어야 합니다.
+- 설계 문서만 읽어도 다음 단계에서 무엇을 구현할지 알 수 있어야 합니다.
+- 설계 문서는 placeholder 없이 구체적이어야 합니다.
+
+## 핵심 원칙
+
+- **한 번에 한 질문** - 여러 질문을 한꺼번에 던지지 않습니다.
+- **객관식 우선** - 답하기 쉬운 형식을 우선합니다.
+- **YAGNI 준수** - 불필요한 기능은 설계에서 제거합니다.
+- **대안 비교** - 항상 2~3개의 접근법을 제시합니다.
+- **점진적 검증** - 설계를 제시하고 승인받은 뒤 다음으로 진행합니다.
+- **유연한 명확화** - 이해가 부족하면 다시 질문합니다.
+
+## 안티 패턴 신호
+
+다음 생각이 들면 흐름을 다시 점검합니다.
+
+- 이건 너무 간단해서 설계가 필요 없다
+- 구현하면서 알아가도 된다
+- 사용자 의도는 아마 이럴 것이다
+- 설계 문서는 나중에 써도 된다
+- 구현 스킬부터 불러도 큰 문제는 없다
+
+이런 생각은 대부분 브레인스토밍 단계를 건너뛰려는 신호입니다.
+
+## 시각 보조 도구
+
+목업, 다이어그램, 시각 옵션을 보여주는 브라우저 기반 보조 수단입니다. 이는 별도 모드가 아니라 필요할 때 사용하는 도구입니다.
+
+**제안 시점**
+
+앞으로의 질문이 시각 요소를 포함할 가능성이 높다면, 아래 문구를 반드시 **단독 메시지**로 제안합니다.
+
+> 지금 논의하는 내용 중 일부는 웹 브라우저에서 직접 보여드리면 더 이해하기 쉬울 수 있습니다. 진행하면서 목업, 다이어그램, 비교안 같은 시각 자료를 준비할 수 있습니다. 아직 새 기능이라 토큰 사용량이 많을 수 있는데, 사용해 보시겠어요? (로컬 URL 열기 필요)
+
+이 제안 메시지에는 다른 질문, 요약, 설명을 섞지 않습니다. 사용자의 답변을 기다린 뒤 계속 진행합니다.
+
+**질문별 판단**
+
+사용자가 수락했더라도 모든 질문을 브라우저로 처리하지는 않습니다. 매 질문마다 "읽는 것보다 보는 것이 더 이해하기 쉬운가?"를 기준으로 판단합니다.
+
+- 브라우저 사용: 목업, 와이어프레임, 레이아웃 비교, 아키텍처 다이어그램 같은 시각 중심 내용
+- 터미널 사용: 요구사항 질문, 개념적 선택지, 트레이드오프 설명, 범위 결정 같은 텍스트 중심 내용
+
+자세한 사용법은 [visual-companion.md](./visual-companion.md)를 참고합니다.

.trae/skills/brainstorming/visual-companion.md

@@ -0,0 +1,68 @@
+# 시각 보조 도구 가이드
+
+브레인스토밍 중 목업, 다이어그램, 비교안을 보여주기 위한 브라우저 기반 시각 보조 가이드입니다.
+
+## 언제 사용할지
+
+세션 단위가 아니라 질문 단위로 판단합니다. 기준은 하나입니다. **읽는 것보다 보는 것이 더 이해하기 쉬운가?**
+
+**브라우저를 사용할 때**
+
+- UI 목업, 와이어프레임, 레이아웃, 내비게이션 구조
+- 시스템 구성도, 데이터 흐름도, 관계도
+- 레이아웃이나 스타일의 시각적 비교
+- 간격, 시각적 위계, 분위기 같은 디자인 완성도 논의
+- 상태 전이, 흐름도, 엔터티 관계처럼 공간적 관계가 중요한 설명
+
+**터미널을 사용할 때**
+
+- 요구사항과 범위 질문
+- 개념적 A/B/C 선택
+- 장단점 비교와 트레이드오프 정리
+- API 설계, 데이터 모델링, 구조 선택 같은 기술 의사결정
+- 시각 취향이 아니라 언어 설명이 필요한 명확화 질문
+
+UI 주제에 대한 질문이라고 해서 자동으로 시각 질문이 되는 것은 아닙니다. "어떤 종류의 위저드를 원하나요?"는 개념 질문이고, "이 위저드 레이아웃 중 무엇이 더 맞나요?"는 시각 질문입니다.
+
+## 진행 방식
+
+서버는 HTML 파일이 저장되는 디렉터리를 감시하고 가장 최근 파일을 브라우저에 제공합니다. 화면 내용은 `screen_dir`에 기록하고, 사용자의 클릭/선택 결과는 `state_dir/events`에 저장됩니다.
+
+**콘텐츠 조각과 전체 문서**
+
+- HTML이 `<!DOCTYPE` 또는 `<html`로 시작하면 전체 문서로 그대로 제공합니다.
+- 그렇지 않으면 서버가 기본 프레임 템플릿으로 감싸서 보여줍니다.
+- 기본적으로는 전체 HTML 문서보다 **콘텐츠 조각** 작성 방식을 사용합니다.
+
+## 세션 시작
+
+- 서버를 시작하고 응답에서 `url`, `screen_dir`, `state_dir`를 저장합니다.
+- 사용자에게 URL을 열어 달라고 안내합니다.
+- 가능하면 프로젝트 루트를 기준으로 실행해 결과물이 프로젝트 안에 유지되게 합니다.
+- 환경상 URL 접근이 어렵다면 호스트 설정을 조정합니다.
+
+## 반복 루프
+
+1. 서버가 살아 있는지 확인하고 `screen_dir`에 새 HTML 파일을 씁니다.
+2. 사용자에게 URL과 현재 화면에 무엇이 보이는지 짧게 설명합니다.
+3. 사용자가 터미널에서 응답하면 `state_dir/events`를 읽어 브라우저 상호작용을 확인합니다.
+4. 피드백에 따라 현재 화면을 수정하거나 다음 질문으로 넘어갑니다.
+5. 다음 단계가 시각 자료가 아니라면 대기 화면을 밀어 넣어 오래된 화면이 남지 않게 합니다.
+
+## 작성 원칙
+
+- 파일명은 의미 있게 짓습니다. 예: `layout.html`, `visual-style.html`
+- 같은 파일명을 재사용하지 않습니다.
+- 한 화면에는 2~4개 선택지만 둡니다.
+- 질문 자체를 화면에 명확히 적습니다.
+- 레이아웃 검토에는 와이어프레임, 완성도 검토에는 더 실제적인 시안을 사용합니다.
+- 필요한 경우 실제 콘텐츠를 사용하고, 불필요한 정교함은 피합니다.
+
+## 이벤트 해석
+
+브라우저 클릭 이벤트는 `state_dir/events`에 JSON Lines 형식으로 기록됩니다. 마지막 선택이 최종 선택인 경우가 많지만, 선택 흐름 전체가 사용자의 망설임이나 선호를 보여줄 수 있습니다.
+
+## 정리
+
+- 세션 종료 시 서버를 중지합니다.
+- 프로젝트 기반 세션이라면 결과물은 이후 참고를 위해 남겨둘 수 있습니다.

.trae/skills/find-skills/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: "find-skills"
+description: "필요한 기능을 제공하는 커뮤니티 스킬을 검색하고 설치하도록 돕습니다. 특정 작업용 스킬이 있는지 찾거나 에이전트 기능을 확장하고 싶을 때 호출합니다."
+---
+
+# 스킬 찾기
+
+이 스킬은 공개 에이전트 스킬 생태계에서 적절한 스킬을 찾고 설치하는 과정을 안내합니다.
+
+## 언제 사용할지
+
+다음과 같은 요청에서 사용합니다.
+
+- X를 어떻게 하냐고 묻는데, 이미 해당 작업용 스킬이 있을 가능성이 있을 때
+- 특정 도메인용 스킬을 찾아 달라고 할 때
+- 전문 기능을 제공할 수 있는 스킬이 있는지 궁금해할 때
+- 에이전트 기능을 확장하고 싶다고 할 때
+- 도구, 템플릿, 워크플로를 찾고 싶다고 할 때
+
+## Skills CLI
+
+Skills CLI는 공개 스킬 생태계를 위한 패키지 관리자입니다.
+
+주요 명령:
+
+- `npx skills find [query]` - 키워드로 스킬 검색
+- `npx skills add <package>` - GitHub 등에서 스킬 설치
+- `npx skills check` - 업데이트 확인
+- `npx skills update` - 설치된 스킬 업데이트
+
+브라우징 사이트:
+
+- `https://skills.sh/`
+
+## 추천 절차
+
+### 1. 요구사항 이해
+
+- 도메인이 무엇인지 파악합니다.
+- 실제로 하고 싶은 작업이 무엇인지 파악합니다.
+- 흔한 문제인지, 이미 스킬이 있을 가능성이 높은지 판단합니다.
+- 검색 전에 사용자가 원하는 것이 "기능", "워크플로", "템플릿", "도메인 지식" 중 무엇인지 구분합니다.
+
+### 2. 먼저 인기 스킬 확인
+
+- 검색 전에 leaderboard나 인기 목록에서 검증된 스킬이 있는지 먼저 봅니다.
+- 설치 수가 많고 널리 알려진 출처를 우선합니다.
+
+### 3. 검색
+
+필요하면 아래 명령으로 검색합니다.
+
+```bash
+npx skills find [query]
+```
+
+예:
+
+- React 성능 최적화 -> `npx skills find react performance`
+- PR 리뷰 -> `npx skills find pr review`
+- changelog 생성 -> `npx skills find changelog`
+
+### 4. 품질 검증
+
+검색 결과만 보고 바로 추천하지 않습니다. 아래를 반드시 확인합니다.
+
+- 설치 수
+- 출처 신뢰도
+- GitHub 저장소 평판
+
+가능하면 공식 또는 널리 알려진 조직의 스킬을 우선합니다.
+
+추가로 아래도 함께 봅니다.
+
+- 최근에도 관리되고 있는지
+- 설명이 실제 사용 시점을 명확히 말하는지
+- 사용자가 원하는 작업과 과하게 어긋나지 않는지
+
+### 5. 사용자에게 제시
+
+다음 정보를 함께 제공합니다.
+
+- 스킬 이름과 역할
+- 설치 수와 출처
+- 설치 명령
+- 더 알아볼 링크
+
+### 6. 설치 제안
+
+사용자가 원하면 설치까지 진행할 수 있습니다.
+
+```bash
+npx skills add <owner/repo@skill> -g -y
+```
+
+## 검색 절차 요약
+
+1. 사용자가 하려는 일을 짧게 재정의합니다.
+2. 인기 스킬에서 먼저 후보를 봅니다.
+3. 부족하면 `npx skills find`로 구체 검색을 합니다.
+4. 검색 결과를 설치 수와 출처 기준으로 걸러냅니다.
+5. 사용자에게 1~3개 정도의 실질적인 후보를 제시합니다.
+6. 원하면 설치까지 이어집니다.
+
+## 검색 팁
+
+- 너무 넓은 키워드보다 구체적인 키워드를 사용합니다.
+- 검색 결과가 약하면 동의어를 바꿔가며 다시 찾습니다.
+- 테스트, 디자인, 문서화, 배포, 코드리뷰, 생산성 같은 범주를 기준으로 접근합니다.
+
+## 추천 시 주의점
+
+- 검색 결과만 나왔다고 바로 추천하지 않습니다.
+- 설치 수가 지나치게 적고 출처가 불분명하면 주의 표시를 합니다.
+- 사용자가 당장 원하는 문제를 일반 역량으로 더 빨리 해결할 수 있다면 그 점도 함께 안내합니다.
+
+## 찾지 못했을 때
+
+적절한 스킬이 없다면 다음 원칙을 따릅니다.
+
+- 스킬을 찾지 못했다고 명확히 알립니다.
+- 일반 역량으로 직접 도와줄 수 있다고 제안합니다.
+- 반복 작업이라면 새 스킬을 직접 만들 수 있다고 안내합니다.
+
+## 기대 결과
+
+이 스킬의 결과물은 다음을 만족해야 합니다.
+
+- 사용자가 어떤 스킬을 왜 추천받았는지 이해할 수 있어야 합니다.
+- 추천 스킬은 최소한의 품질 검증을 통과해야 합니다.
+- 설치 명령과 더 알아볼 경로가 함께 제공되어야 합니다.
+- 적절한 스킬이 없을 경우에도 다음 행동이 제시되어야 합니다.

.trae/skills/frontend-design/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: "frontend-design"
+description: "개성 있고 완성도 높은 프론트엔드 UI를 설계하고 구현합니다. 웹 페이지, 컴포넌트, 대시보드, 랜딩페이지, 스타일 개선 요청이 있을 때 호출합니다."
+---
+
+# 개성 있는 프로덕션급 프론트엔드 디자인
+
+이 스킬은 흔한 "AI가 만든 티 나는" 결과물을 피하고, 높은 디자인 완성도를 가진 프론트엔드 인터페이스를 만들기 위한 가이드입니다. 미학적 디테일과 창의적 선택에 집중하면서 실제로 동작하는 코드를 구현합니다.
+
+사용자는 컴포넌트, 페이지, 애플리케이션, 포스터, 웹 인터페이스 등의 프론트엔드 요구사항을 제공합니다. 여기에는 목적, 대상 사용자, 기술 제약이 함께 포함될 수 있습니다.
+
+## 디자인 사고
+
+코드를 작성하기 전에 문맥을 이해하고, 분명하고 대담한 미학 방향을 먼저 정합니다.
+
+- **목적** - 이 인터페이스가 해결하는 문제는 무엇인지, 누가 사용하는지 파악합니다.
+- **톤** - 극단적인 방향성을 고릅니다. 예: 극단적 미니멀리즘, 맥시멀리즘, 레트로 퓨처리즘, 유기적/자연주의, 고급/정제, 장난감 같은 유쾌함, 에디토리얼/매거진, 브루탈리즘, 아르데코, 소프트/파스텔, 산업적/실용주의 등
+- **제약** - 프레임워크, 성능, 접근성 같은 기술 조건을 확인합니다.
+- **차별점** - 이 결과물을 잊히지 않게 만드는 핵심 한 가지가 무엇인지 정의합니다.
+
+**중요**: 개념적 방향을 명확히 정하고 정밀하게 실행해야 합니다. 대담한 맥시멀리즘이든 정제된 미니멀리즘이든 모두 가능하지만, 핵심은 강도가 아니라 의도성입니다.
+
+방향을 정할 때는 "멋있어 보이는 것"만이 아니라 "왜 이 제품과 맥락에 맞는가"까지 설명할 수 있어야 합니다.
+
+그 다음, HTML/CSS/JS, React, Vue 등 적절한 기술로 아래 기준을 만족하는 실제 동작 코드를 구현합니다.
+
+- 프로덕션 수준의 완성도와 기능성
+- 시각적으로 강렬하고 기억에 남는 결과
+- 일관된 미학 관점
+- 세부까지 정교하게 다듬어진 표현
+
+## 프론트엔드 미학 가이드라인
+
+다음 요소에 집중합니다.
+
+- **타이포그래피** - 아름답고, 독특하고, 흥미로운 폰트를 선택합니다. Arial, Inter 같은 너무 흔한 폰트는 피합니다. 개성 있는 디스플레이 폰트와 정제된 본문 폰트를 조합합니다.
+- **색상과 테마** - 일관된 미학 방향에 확실히 맞춥니다. CSS 변수로 일관성을 유지합니다. 소심하게 균등 분배된 색상보다, 지배적인 메인 컬러와 날카로운 포인트 컬러가 더 강한 인상을 줍니다.
+- **모션** - 애니메이션과 마이크로 인터랙션을 활용합니다. HTML에서는 가능하면 CSS 중심으로 해결하고, React에서는 Motion 계열 라이브러리를 활용할 수 있습니다. 페이지 로드 연출, 스태거드 리빌, 스크롤 트리거, 의외성 있는 호버 상태처럼 임팩트 있는 순간에 집중합니다.
+- **공간 구성** - 예상 가능한 배치보다 비대칭, 겹침, 대각선 흐름, 그리드를 깨는 요소, 넉넉한 여백 또는 의도된 밀도를 적극 활용합니다.
+- **배경과 시각 디테일** - 단색 배경으로 끝내지 말고 분위기와 깊이를 만듭니다. 그래디언트 메시, 노이즈 텍스처, 기하학 패턴, 레이어 투명도, 강한 그림자, 장식 테두리, 커스텀 커서, 그레인 오버레이 등 맥락에 맞는 효과를 활용합니다.
+- **맥락 적합성** - 금융, 의료, 패션, 교육처럼 도메인별 기대치를 반영합니다. 시각적으로 강하더라도 제품 신뢰를 해치면 실패입니다.
+- **디테일 완성도** - 버튼 상태, 입력 포커스, 빈 상태, 에러 상태, 로딩 상태까지 같은 미학 언어로 정리합니다.
+
+## 반드시 피할 것
+
+다음과 같은 흔한 AI 스타일은 사용하지 않습니다.
+
+- Inter, Roboto, Arial, 시스템 폰트에 과도하게 의존하는 구성
+- 흰 배경 위 보라색 그라데이션 같은 진부한 색 조합
+- 너무 예측 가능한 레이아웃과 컴포넌트 패턴
+- 맥락 고유성이 없는 쿠키커터식 디자인
+
+항상 맥락에 맞게 창의적으로 해석하고, 예상 밖이지만 설득력 있는 선택을 합니다. 모든 디자인은 서로 달라야 하며, 결과물마다 라이트/다크 테마, 폰트, 분위기, 스타일이 달라질 수 있어야 합니다. 여러 세대의 결과물이 공통된 안전한 선택으로 수렴해서는 안 됩니다.
+
+다음 같은 패턴도 피합니다.
+
+- 의미 없는 화려함만 있고 정보 위계가 약한 구성
+- 디자인 방향 없이 라이브러리 기본 스타일만 얹은 화면
+- 모든 요소에 같은 그림자, 같은 반경, 같은 간격을 기계적으로 적용한 화면
+- 제품 목적보다 Dribbble식 비주얼 과시에 치우친 화면
+
+## 구현 복잡도와 미학의 일치
+
+구현 복잡도는 미학 방향과 맞아야 합니다.
+
+- 맥시멀한 디자인이라면 풍부한 애니메이션, 시각 효과, 정교한 레이어링이 필요할 수 있습니다.
+- 미니멀하거나 정제된 디자인이라면 절제, 정밀한 간격, 타이포그래피, 미묘한 디테일에 집중해야 합니다.
+
+우아함은 단순함 자체가 아니라, 선택한 비전을 얼마나 정확하게 실행했는지에서 나옵니다.
+
+## 작업 절차
+
+이 스킬을 적용할 때는 보통 아래 순서를 따릅니다.
+
+1. 제품 맥락과 사용자층을 확인합니다.
+2. 대담한 미학 방향을 한 문장으로 정의합니다.
+3. 색상, 폰트, 레이아웃, 모션 원칙을 결정합니다.
+4. 그 방향에 맞는 실제 UI를 구현합니다.
+5. 상태 변화, 반응형, 접근성, 디테일 완성도를 점검합니다.
+
+## 산출물 기대치
+
+최종 결과물은 다음을 만족해야 합니다.
+
+- 실제로 동작하는 코드여야 합니다.
+- 디자인 방향이 한눈에 읽혀야 합니다.
+- 타이포그래피와 색상 시스템이 의도적으로 구성되어야 합니다.
+- 상태 변화와 미세 상호작용까지 마감되어야 합니다.
+- 흔한 AI 스타일이 아니라, 맥락에 맞는 인상적인 화면이어야 합니다.
+
+## 핵심 원칙
+
+- 프론트엔드 결과물은 항상 실제로 동작해야 합니다.
+- 미학 방향은 분명해야 하며, 애매한 절충안으로 흐르지 않습니다.
+- 흔한 AI 스타일 대신 맥락에 맞는 독창성을 우선합니다.
+- 디테일, 간격, 타이포그래피, 모션, 색상 일관성을 끝까지 다듬습니다.
+- 과감한 선택을 두려워하지 말고, 명확한 방향성을 완성도 있게 구현합니다.

.trae/skills/karpathy-guidelines/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: "karpathy-guidelines"
+description: "LLM 코딩 실수를 줄이는 행동 지침입니다. 코드 작성, 리뷰, 리팩터링 시 과설계와 과추정을 줄이고 검증 가능한 목표를 세워야 할 때 호출합니다."
+---
+
+# Karpathy 가이드라인
+
+이 스킬은 LLM이 코드 작업에서 자주 하는 실수를 줄이기 위한 행동 규칙입니다. 속도보다 신중함을 약간 더 우선합니다.
+
+사소한 작업에서는 판단의 여지가 있지만, 코드 작성, 리뷰, 리팩터링처럼 실수가 누적되기 쉬운 작업에서는 이 규칙을 기본 행동으로 삼습니다.
+
+## 1. 코딩 전에 먼저 생각하기
+
+- 추정하지 않습니다.
+- 헷갈리는 점을 숨기지 않습니다.
+- 가정을 명시적으로 드러냅니다.
+- 해석이 여러 가지면 조용히 하나를 고르지 말고 선택지를 보여줍니다.
+- 더 단순한 방법이 있으면 먼저 제안합니다.
+- 불명확하면 멈추고 무엇이 불명확한지 말합니다.
+
+핵심은 "모르는 상태에서 자신감 있게 진행하지 않는 것"입니다.
+
+## 2. 단순함 우선
+
+문제를 해결하는 최소한의 코드만 작성합니다.
+
+- 요청하지 않은 기능은 넣지 않습니다.
+- 한 번만 쓰는 코드에 추상화를 만들지 않습니다.
+- 요구되지 않은 유연성이나 설정 가능성은 추가하지 않습니다.
+- 실제로 불가능한 시나리오까지 과한 예외 처리를 만들지 않습니다.
+- 200줄이 50줄로 될 수 있다면 다시 단순화합니다.
+
+항상 스스로 묻습니다. "시니어 엔지니어가 이걸 과하다고 말하지 않을까?"
+
+단순함은 기능 부족이 아니라, 요구에 정확히 맞는 최소 해법을 의미합니다.
+
+## 3. 수술하듯 수정하기
+
+필요한 부분만 건드리고, 내 변경으로 생긴 부산물만 정리합니다.
+
+- 인접 코드, 주석, 포맷을 괜히 손보지 않습니다.
+- 고장 나지 않은 부분을 리팩터링하지 않습니다.
+- 기존 스타일을 따릅니다.
+- 내 변경 때문에 쓰이지 않게 된 import, 변수, 함수만 제거합니다.
+- 원래부터 있던 죽은 코드는 함부로 지우지 않고 필요하면 언급만 합니다.
+
+모든 변경 줄은 사용자 요청과 직접 연결되어야 합니다.
+
+관련 없는 개선 욕구는 분리해야 합니다. 지금 작업의 일부가 아니라면 메모만 하고 건드리지 않습니다.
+
+## 4. 목표 기반 실행
+
+작업은 검증 가능한 목표로 바꿉니다.
+
+- 유효성 검사 추가 -> 잘못된 입력 테스트를 쓰고 통과시킨다
+- 버그 수정 -> 재현 테스트를 만들고 통과시킨다
+- 리팩터링 -> 변경 전후 테스트가 모두 통과하는지 확인한다
+
+여러 단계 작업이라면 짧은 계획과 검증 기준을 함께 둡니다.
+
+예:
+
+1. 단계 수행 -> 어떤 체크로 검증할지 명시
+2. 다음 단계 수행 -> 어떤 체크로 검증할지 명시
+3. 최종 검증 -> 통과 조건 명시
+
+강한 성공 기준이 있을수록 중간 판단을 줄일 수 있고, 사용자의 재확인 없이도 정확하게 루프를 돌 수 있습니다.
+
+## 자주 막아야 할 실수
+
+- 애매한 요구를 임의로 해석해 구현해 버리는 것
+- 한 번만 쓸 로직에 구조를 과하게 씌우는 것
+- 요청과 직접 관련 없는 주변 코드까지 손대는 것
+- "작동하면 됐다" 수준으로 검증 없이 마무리하는 것
+
+## 기대 결과
+
+이 스킬을 적용한 결과는 다음을 만족해야 합니다.
+
+- 가정이 숨겨지지 않는다
+- 코드가 필요한 만큼만 단순하다
+- 변경 범위가 요청과 정확히 맞닿아 있다
+- 성공 기준이 검증 가능한 문장으로 바뀌어 있다
+
+## 핵심 요약
+
+- 먼저 생각하고, 모르면 묻습니다.
+- 최소 코드로 끝냅니다.
+- 꼭 필요한 줄만 바꿉니다.
+- 검증 가능한 성공 기준을 세웁니다.

.trae/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: "systematic-debugging"
+description: "버그, 테스트 실패, 예기치 않은 동작을 체계적으로 진단합니다. 수정안을 제시하기 전에 반드시 근본 원인을 먼저 찾아야 할 때 호출합니다."
+---
+
+# 체계적 디버깅
+
+무작위 수정은 시간을 낭비하고 새 버그를 만듭니다. 빠른 땜질은 증상만 가릴 뿐입니다. 이 스킬의 핵심은 **수정 전에 반드시 근본 원인을 찾는 것**입니다.
+
+## 철칙
+
+근본 원인 조사 없이 수정하지 않습니다.
+
+다시 말해, 1단계를 끝내지 않았다면 수정안 제시는 아직 허용되지 않습니다.
+
+## 언제 사용할지
+
+다음과 같은 모든 기술 문제에서 사용합니다.
+
+- 테스트 실패
+- 운영 중 버그
+- 예기치 않은 동작
+- 성능 문제
+- 빌드 실패
+- 통합 문제
+
+특히 아래 상황에서 반드시 사용합니다.
+
+- 시간이 촉박할 때
+- "일단 이것만 빨리 고치면 될 것 같을 때"
+- 이미 여러 수정안을 시도했을 때
+- 이전 수정이 실패했을 때
+- 문제를 완전히 이해하지 못한 상태일 때
+
+다음 상황에서도 생략하지 않습니다.
+
+- 문제가 너무 단순해 보일 때
+- 급하게 고쳐 달라는 압박이 있을 때
+- 지금 보이는 증상만 없애면 될 것처럼 느껴질 때
+
+## 4단계 프로세스
+
+### 1단계: 근본 원인 조사
+
+수정 전에 반드시 아래를 수행합니다.
+
+- 오류 메시지, 경고, 스택 트레이스를 끝까지 읽습니다.
+- 재현 절차를 명확히 만들고, 반복 재현 가능한지 확인합니다.
+- 최근 변경 사항, 설정 차이, 의존성 변경, 환경 차이를 확인합니다.
+- 다중 컴포넌트 시스템이라면 경계마다 로그와 계측을 추가해 어디서 깨지는지 증거를 모읍니다.
+- 호출 스택이 깊다면 잘못된 값이 어디서 시작됐는지 거꾸로 추적합니다.
+- 재현이 안정적이지 않다면, 추측 대신 로그와 관찰 지점을 늘립니다.
+- 레이어가 여러 개인 시스템이라면 각 경계에서 입력, 출력, 상태 전파를 확인합니다.
+
+### 2단계: 패턴 분석
+
+- 같은 코드베이스에서 정상 동작하는 유사 사례를 찾습니다.
+- 참조 구현이 있다면 끝까지 읽고 패턴을 정확히 이해합니다.
+- 정상 사례와 문제 사례의 차이를 작은 것까지 모두 나열합니다.
+- 필요한 설정, 환경, 전제 조건을 파악합니다.
+- "이 정도 차이는 중요하지 않겠지"라고 넘기지 않습니다.
+
+### 3단계: 가설과 검증
+
+- "원인은 X이며 이유는 Y다"라는 단일 가설을 명확히 적습니다.
+- 가설을 검증할 수 있는 최소 변경만 적용합니다.
+- 한 번에 변수 하나만 바꿉니다.
+- 실패하면 수정안을 겹쳐 쌓지 말고 새 가설로 돌아갑니다.
+- 모르는 것은 모른다고 인정하고 추가 조사 또는 도움 요청을 합니다.
+
+이 단계의 핵심은 과학적 방법입니다.
+
+- 한 번에 하나의 가설만 세웁니다.
+- 한 번에 하나의 변수만 바꿉니다.
+- 실패하면 더 많은 수정으로 덮지 않고, 얻은 새 증거를 바탕으로 다시 분석합니다.
+
+### 4단계: 구현
+
+- 먼저 실패하는 테스트나 최소 재현 케이스를 만듭니다.
+- 확인된 근본 원인만 겨냥해 한 번에 한 수정만 적용합니다.
+- 테스트가 통과하는지, 다른 것이 깨지지 않았는지 검증합니다.
+- 수정이 실패하면 즉시 멈추고 다시 1단계로 돌아갑니다.
+- 세 번 이상 실패했다면 개별 버그가 아니라 구조적 문제일 가능성을 의심합니다.
+
+세 번 이상 수정이 연속 실패했다면 아래를 질문합니다.
+
+- 우리가 증상을 계속 쫓고 있지는 않은가
+- 현재 구조 자체가 문제를 유발하고 있지는 않은가
+- 고칠 문제가 아니라 패턴을 바꿔야 하는 상황은 아닌가
+
+## 중단 신호
+
+다음 생각이 들면 멈추고 다시 1단계로 돌아갑니다.
+
+- 일단 빨리 고치고 나중에 조사하자
+- X를 바꿔보면 될 것 같다
+- 여러 개를 같이 바꾸면 빠를 것 같다
+- 테스트는 나중에 쓰자
+- 완전히 이해는 못 했지만 아마 맞을 것이다
+- 한 번만 더 고쳐보자
+- 여기 문제들은 대충 이런 것들이다
+- 로그 없이 감으로 수정 방향을 정하자
+- 여기저기 같이 바꾸면 하나쯤 맞을 것이다
+
+이 신호들은 대부분 조사보다 추측이 앞서고 있다는 뜻입니다.
+
+## 안티 패턴
+
+- 증상만 감추는 빠른 땜질
+- 여러 수정안을 한 번에 넣는 방식
+- 재현 없이 감으로 고치는 방식
+- 비교 대상 없이 현재 코드만 들여다보는 방식
+- 세 번 이상 실패했는데도 구조를 의심하지 않는 방식
+
+## 핵심 원칙
+
+- 증상이 아니라 원인을 수정합니다.
+- 계측과 증거 없이 추측하지 않습니다.
+- 한 번에 하나만 바꿉니다.
+- 재현, 비교, 검증이 없는 수정은 완료가 아닙니다.
+- 여러 번 실패하면 구조 자체를 의심합니다.
+
+## 기대 결과
+
+이 스킬을 적용한 결과는 다음을 만족해야 합니다.
+
+- 문제의 재현 절차가 설명 가능해야 합니다.
+- 근본 원인을 뒷받침하는 증거가 있어야 합니다.
+- 수정안은 하나의 원인에 대응해야 합니다.
+- 수정 후에는 재현 테스트 또는 검증 절차가 통과해야 합니다.

.trae/skills/ui-ux-pro-max/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: "ui-ux-pro-max"
+description: "웹과 모바일 전반의 UI/UX 설계 지능을 제공합니다. 새 페이지 설계, 컴포넌트 리팩터링, 디자인 시스템, 접근성, 상호작용 품질 점검이 필요할 때 호출합니다."
+---
+
+# UI/UX Pro Max
+
+웹과 모바일 애플리케이션을 위한 종합 UI/UX 설계 가이드입니다. 다양한 스타일, 색상 팔레트, 폰트 조합, 제품 유형별 추천, UX 가이드라인, 차트 유형 관점을 바탕으로 더 완성도 높은 인터페이스를 설계하도록 돕습니다.
+
+## 언제 적용할지
+
+다음과 같은 작업에서는 이 스킬을 우선 사용합니다.
+
+- 새 페이지를 설계할 때
+- 버튼, 모달, 폼, 테이블, 차트 같은 UI 컴포넌트를 만들거나 리팩터링할 때
+- 색상 체계, 타이포그래피, 간격, 레이아웃 시스템을 정할 때
+- UI 코드의 사용성, 접근성, 시각 일관성을 검토할 때
+- 내비게이션, 애니메이션, 반응형 동작을 설계할 때
+- 제품 수준의 스타일, 정보 위계, 브랜드 표현을 결정할 때
+- 인터페이스의 명확성, 품질감, 사용성을 개선할 때
+
+## 반드시 사용할 상황
+
+아래 상황에서는 이 스킬 사용을 기본값으로 둡니다.
+
+- 랜딩 페이지, 대시보드, 어드민, SaaS, 모바일 앱 등 새 화면 구조를 만들 때
+- 버튼, 모달, 폼, 테이블, 차트 같은 핵심 컴포넌트를 설계 또는 개편할 때
+- 색상 체계와 타이포그래피 시스템을 결정할 때
+- 접근성, 상호작용 품질, 시각 일관성 리뷰를 수행할 때
+- 반응형 레이아웃과 내비게이션 구조를 정할 때
+
+다음 경우에는 보조적으로 권장됩니다.
+
+- UI가 "어딘가 덜 프로페셔널해 보이는데 이유가 분명하지 않을 때"
+- 사용성 피드백을 받았을 때
+- 출시 전 UI 품질을 정리할 때
+- 웹, iOS, Android 간 디자인 정렬이 필요할 때
+- 디자인 시스템 또는 재사용 가능한 컴포넌트 라이브러리를 만들 때
+
+## 권장 상황
+
+- UI가 덜 프로페셔널해 보이지만 원인이 명확하지 않을 때
+- 제품 피드백에서 "불편하다", "헷갈린다"는 의견이 반복될 때
+- 출시 직전 품질 점검에서 디자인 완성도를 끌어올려야 할 때
+
+## 불필요한 상황
+
+아래 작업에서는 일반적으로 이 스킬이 우선순위가 아닙니다.
+
+- 순수 백엔드 로직만 다루는 작업
+- API 계약, DB 스키마 설계만 다루는 작업
+- UI와 무관한 인프라/DevOps 작업
+- 시각 요소가 없는 자동화 스크립트 작업
+
+다음 작업에는 일반적으로 필요하지 않습니다.
+
+- 순수 백엔드 로직 개발
+- API 또는 데이터베이스 설계만 하는 작업
+- 인터페이스와 무관한 성능 최적화
+- 인프라, DevOps, 비시각 자동화 작업
+
+판단 기준은 단순합니다. 작업이 기능이 **어떻게 보이고, 느껴지고, 움직이고, 상호작용되는지**를 바꾼다면 이 스킬을 사용합니다.
+
+## 핵심 원칙
+
+- 접근성을 최우선으로 봅니다. 대비, 키보드 탐색, 레이블, 상태 표현을 먼저 확인합니다.
+- 시각적 품질보다 정보 구조와 사용 흐름을 먼저 정리합니다.
+- 제품 맥락에 맞는 스타일을 선택하고, 유행하는 패턴을 무조건 복제하지 않습니다.
+- 타이포그래피, 색상, 간격, 그림자, 애니메이션, 반응형 규칙을 시스템으로 다룹니다.
+- 웹과 모바일을 포함한 여러 플랫폼 간 일관성을 유지하되, 플랫폼 고유 상호작용은 존중합니다.
+- 차트나 데이터 시각화는 미적인 취향보다 데이터 전달 목적에 맞게 선택합니다.
+
+## 우선순위별 검토 항목
+
+1. **접근성** - 대비, 포커스, 라벨, 키보드 접근성, 보조기기 친화성
+2. **상호작용 품질** - 클릭 영역, 터치 친화성, 상태 변화, 피드백
+3. **정보 위계** - 가장 중요한 내용이 첫눈에 보이는지 확인
+4. **레이아웃 시스템** - 그리드, 여백, 정렬, 반응형 구조
+5. **타이포그래피** - 역할이 명확한 글자 크기, 무게, 줄 간격, 폰트 조합
+6. **색상 시스템** - 브랜드 적합성, 상태 색, 강조 규칙, 다크/라이트 확장성
+7. **모션과 전환** - 의미 있는 움직임만 남기고 산만한 효과는 제거
+8. **시각 디테일** - 경계선, 그림자, 반경, 배경 질감, 컴포넌트 완성도
+
+## 워크플로
+
+1. 제품 유형과 목표 사용자, 핵심 과업을 정의합니다.
+2. 정보 위계와 화면 구조를 먼저 설계합니다.
+3. 스타일 방향, 색상 전략, 타이포그래피 전략을 정합니다.
+4. 컴포넌트와 페이지를 같은 시스템 규칙으로 맞춥니다.
+5. 접근성, 반응형, 상태 표현, 상호작용 완성도를 점검합니다.
+6. 필요한 경우 리뷰 결과를 우선순위별로 정리해 개선합니다.
+
+## 작업 방식
+
+- 먼저 제품 유형과 대상 사용자, 핵심 화면 목적을 확인합니다.
+- 그 다음 스타일 방향, 컬러 전략, 타이포그래피 방향, 레이아웃 전략을 제안합니다.
+- 필요한 경우 2~3개의 시각 방향을 비교하고 추천안을 제시합니다.
+- 구현에 들어갈 때는 컴포넌트 단위 규칙과 페이지 단위 위계를 함께 설계합니다.
+- 리뷰 작업이라면 문제를 단순 나열하지 말고, 우선순위와 수정 이유까지 설명합니다.
+
+## 안티 패턴
+
+- 정보 구조를 정하기 전에 시각 효과만 먼저 쌓는 방식
+- 모든 화면을 같은 템플릿으로 찍어내는 방식
+- 접근성 점검 없이 색상과 애니메이션만 조정하는 방식
+- 컴포넌트 규칙 없이 페이지별 임시 스타일을 누적하는 방식
+
+## 산출물 기준
+
+이 스킬을 사용한 결과물은 다음을 만족해야 합니다.
+
+- 보기 좋을 뿐 아니라 읽기 쉽고 사용하기 쉬워야 합니다.
+- 단일 화면이 아니라 전체 시스템 관점에서 일관성이 있어야 합니다.
+- 컴포넌트와 페이지의 관계가 명확해야 합니다.
+- 접근성, 반응형, 상태 표현을 빠뜨리지 않아야 합니다.
+- 색상, 폰트, 간격, 인터랙션이 의도적으로 선택되어야 합니다.

.trae/skills/using-superpowers/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: "using-superpowers"
+description: "응답 전에 관련 스킬을 먼저 확인하고 호출하는 운영 규칙입니다. 어떤 작업이든 적절한 스킬 적용 여부를 먼저 판단해야 할 때 호출합니다."
+---
+
+# 스킬 사용 운영 규칙
+
+이 스킬은 대화나 작업을 시작할 때, 어떤 스킬을 먼저 확인하고 어떻게 적용할지에 대한 기본 운영 원칙을 정의합니다.
+
+## 최우선 규칙
+
+관련 스킬이 조금이라도 적용될 가능성이 있다면, 응답이나 행동 전에 먼저 스킬을 호출합니다.
+
+질문에 답하기 전, 코드 읽기 전, 구현 시작 전, 명확화 질문을 하기 전에도 먼저 검토합니다.
+
+단 1%의 가능성이라도 있다면 먼저 확인하는 쪽이 기본값입니다.
+
+## 우선순위
+
+스킬 지시보다 사용자 지시가 항상 우선합니다.
+
+1. 사용자 명시 지시
+2. 스킬 지시
+3. 시스템 기본 동작
+
+즉, 스킬이 어떤 워크플로를 권장하더라도 사용자가 다른 방식을 명확히 요구하면 사용자 지시를 따릅니다.
+
+## 기본 흐름
+
+- 사용자 메시지를 받으면 먼저 관련 스킬 가능성을 판단합니다.
+- 관련 가능성이 있으면 즉시 스킬을 호출합니다.
+- 호출된 스킬에 체크리스트가 있으면 작업 목록을 만들고 순서대로 따릅니다.
+- 그 다음에야 응답, 질문, 구현, 조사 같은 행동을 합니다.
+
+중요한 점은, "먼저 조금만 확인하고 나서 스킬을 쓰자"가 아니라 "스킬을 먼저 확인하고 나서 어떻게 확인할지 결정한다"는 순서입니다.
+
+## 스킬 우선 적용 순서
+
+여러 스킬이 동시에 맞을 수 있다면 아래 순서를 기준으로 봅니다.
+
+1. **프로세스 스킬** - 작업 방식을 정하는 스킬
+2. **구현 스킬** - 실제 구현이나 산출물을 만드는 스킬
+
+예:
+
+- "무언가를 만들자" -> brainstorming 먼저, 그다음 구현 스킬
+- "버그를 고치자" -> debugging 먼저, 그다음 도메인 스킬
+
+즉, 프로세스를 정하는 스킬이 항상 구현 스킬보다 먼저입니다.
+
+## 흔한 자기합리화 경고
+
+다음 생각이 들면 흐름을 다시 점검합니다.
+
+- 이건 간단하니까 스킬이 필요 없겠다
+- 먼저 코드 좀 보고 나서 생각하자
+- 빠르게 확인만 하고 나중에 스킬을 쓰자
+- 이 정도는 기억으로 처리해도 되겠다
+- 질문이니까 작업이 아니다
+- 스킬이 너무 과한 것 같다
+- 이건 그냥 간단한 확인이다
+- 이전에 본 적 있는 스킬이라 다시 안 읽어도 된다
+
+이런 생각은 대부분 스킬 적용을 건너뛰려는 신호입니다.
+
+## 적용 절차
+
+실제 적용 절차는 아래와 같습니다.
+
+1. 사용자 메시지를 받습니다.
+2. 관련 스킬 가능성을 먼저 판단합니다.
+3. 조금이라도 관련 있다면 스킬을 호출합니다.
+4. 스킬의 체크리스트나 절차를 작업 흐름에 반영합니다.
+5. 그 다음 응답, 조사, 구현을 진행합니다.
+
+## 원칙
+
+- 스킬은 선택이 아니라 작업 방식의 일부로 본다
+- 단순한 작업일수록 오히려 프로세스를 지켜 과잉 추정을 줄인다
+- 기억에 의존하지 말고 현재 스킬 내용을 기준으로 판단한다
+- 관련성이 아주 낮아 보여도, 가능성이 있으면 먼저 확인한다
+
+## 기대 결과
+
+이 스킬의 목적은 다음 상태를 만드는 것입니다.
+
+- 관련 스킬이 빠지지 않는다
+- 작업 접근 순서가 일관된다
+- 응답 전에 방법론이 먼저 고정된다
+- 임의 판단과 과잉 추정이 줄어든다

.trae/skills/webapp-testing/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: "webapp-testing"
+description: "Playwright 기반으로 로컬 웹앱을 점검하고 테스트합니다. 프론트엔드 동작 검증, UI 디버깅, 스크린샷, 브라우저 로그 확인이 필요할 때 호출합니다."
+---
+
+# 웹앱 테스트
+
+이 스킬은 로컬 웹 애플리케이션을 브라우저에서 실제로 검증하기 위한 Playwright 기반 테스트 가이드입니다.
+
+## 기본 원칙
+
+- 동적 웹앱은 렌더링이 끝나기 전에 DOM을 섣불리 읽지 않습니다.
+- 브라우저 조작 전에 먼저 화면 상태를 관찰합니다.
+- 가능하면 기본 제공 스크립트를 블랙박스로 활용합니다.
+- 정적인 추측보다 브라우저에서 직접 확인한 셀렉터와 상태를 신뢰합니다.
+
+## 사용 가능한 보조 스크립트
+
+- `scripts/with_server.py` - 서버 실행과 종료를 관리합니다.
+
+이 스크립트는 먼저 `--help`로 사용법을 확인한 뒤 사용합니다. 소스를 먼저 읽기보다, 가능한 한 도구처럼 호출하는 방식을 우선합니다.
+
+## 언제 사용할지
+
+- 로컬 웹앱의 실제 동작을 확인해야 할 때
+- 버튼, 폼, 내비게이션, 모달 같은 UI 상호작용을 점검할 때
+- 스크린샷이나 브라우저 로그가 필요할 때
+- 동적 렌더링 이후의 DOM을 기준으로 문제를 확인해야 할 때
+
+## 접근 방식 결정
+
+### 정적 HTML인 경우
+
+- 파일을 직접 읽어 셀렉터를 먼저 확인합니다.
+- 그 셀렉터를 바탕으로 Playwright 스크립트를 작성합니다.
+- 직접 확인이 부족하면 동적 앱처럼 취급합니다.
+
+### 동적 웹앱인 경우
+
+- 서버가 안 떠 있다면 `with_server.py`로 서버 라이프사이클을 관리합니다.
+- 서버가 이미 떠 있다면 브라우저에서 먼저 정찰한 뒤 조작합니다.
+
+## 정찰 후 행동 패턴
+
+이 스킬의 기본 패턴은 "정찰 후 행동"입니다.
+
+1. 페이지에 접속합니다.
+2. `networkidle` 상태까지 기다립니다.
+3. 스크린샷을 찍거나 렌더링된 DOM을 확인합니다.
+4. 그 상태를 기준으로 셀렉터를 식별합니다.
+5. 그 다음 클릭, 입력, 검증 같은 행동을 수행합니다.
+
+정적 분석으로 셀렉터를 추측하는 대신, 실제 렌더링 결과를 기준으로 선택자를 확정합니다.
+
+## 서버 관리 예시
+
+단일 서버:
+
+```bash
+python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py
+```
+
+복수 서버:
+
+```bash
+python scripts/with_server.py --server "cd backend && python server.py" --port 3000 --server "cd frontend && npm run dev" --port 5173 -- python your_automation.py
+```
+
+## 자동화 스크립트 원칙
+
+- `sync_playwright()`를 기본으로 사용합니다.
+- Chromium은 headless 모드로 실행합니다.
+- 페이지 이동 후 `page.wait_for_load_state('networkidle')`를 호출합니다.
+- 작업이 끝나면 브라우저를 닫습니다.
+
+## with_server.py 사용 원칙
+
+- 먼저 `python scripts/with_server.py --help`로 옵션을 확인합니다.
+- 서버가 여러 개인 경우에도 이 스크립트로 생명주기를 한 번에 관리합니다.
+- Playwright 스크립트 안에는 서버 시작 로직을 넣지 않습니다.
+- 자동화 스크립트는 브라우저 조작에만 집중합니다.
+
+## 좋은 습관
+
+- 먼저 관찰하고 나중에 조작합니다.
+- `text=`, `role=`, CSS 선택자, ID 등 설명력 있는 셀렉터를 씁니다.
+- 필요한 경우 `wait_for_selector()` 같은 명시적 대기를 사용합니다.
+- 스크린샷과 콘솔 로그 수집을 적극 활용합니다.
+- 재현이 불안정하면 관찰 스텝을 늘리고, 행동 스텝은 줄여 원인을 좁힙니다.
+
+## 흔한 실수
+
+- JS가 끝나기 전에 DOM을 확인하는 것
+- 서버 실행과 테스트 로직을 뒤섞는 것
+- 셀렉터 확인 없이 곧바로 클릭부터 시도하는 것
+- 렌더링 전 HTML만 보고 동적 UI 동작을 단정하는 것
+
+## 기대 결과
+
+이 스킬을 적용한 결과물은 다음을 만족해야 합니다.
+
+- 서버 실행과 테스트 로직이 분리되어 있어야 합니다.
+- 브라우저에서 실제 보이는 상태를 기준으로 상호작용이 설계되어야 합니다.
+- 셀렉터와 검증 조건이 관찰 결과를 기반으로 정해져야 합니다.
+- 필요 시 스크린샷, 콘솔 로그, DOM 확인 결과를 남길 수 있어야 합니다.
+
+## 목표
+
+이 스킬의 목적은 브라우저에서 실제 사용자 흐름을 검증하고, 화면 기준으로 문제를 발견하며, 재현 가능한 자동화 스크립트를 만드는 것입니다.

.trae/skills/writing-plans/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: "writing-plans"
+description: "명세가 정해진 다단계 작업을 실행 계획으로 바꿉니다. 코드를 건드리기 전에 구체적인 구현 계획과 작업 순서를 작성해야 할 때 호출합니다."
+---
+
+# 구현 계획 작성
+
+이 스킬은 명세나 요구사항이 있는 작업을, 실제 엔지니어가 바로 수행할 수 있는 상세 구현 계획으로 바꾸기 위한 가이드입니다.
+
+## 개요
+
+계획은 코드베이스 맥락이 거의 없는 개발자도 이해할 수 있도록 충분히 구체적이어야 합니다. 어떤 파일을 수정할지, 어떤 테스트를 작성할지, 무엇을 어떤 순서로 검증할지까지 모두 포함해야 합니다.
+
+핵심 원칙은 다음과 같습니다.
+
+- DRY
+- YAGNI
+- TDD
+- 잦은 커밋
+- 작은 단계
+
+계획 문서는 기본적으로 `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md` 에 저장합니다.
+
+시작할 때는 현재 구현 계획 작성 단계에 들어왔음을 명확히 선언합니다.
+
+## 범위 점검
+
+- 명세가 여러 독립 하위 시스템을 포함한다면 계획도 분리합니다.
+- 하나의 계획은 자체적으로 구현, 테스트, 검증 가능한 범위를 가져야 합니다.
+- 하나의 계획만으로 독립적으로 완료 가능한 단위를 만드는 것이 목표입니다.
+
+## 파일 구조 먼저 정의
+
+작업을 나누기 전에 어떤 파일을 만들고 수정할지 먼저 정리합니다.
+
+- 각 파일은 하나의 명확한 책임만 가지게 설계합니다.
+- 함께 바뀌는 파일은 가까이 두고, 책임 기준으로 나눕니다.
+- 기존 코드베이스의 패턴을 따릅니다.
+- 지나치게 커진 파일을 다뤄야 한다면 계획 안에 분리 작업을 포함할 수 있습니다.
+- 분해 결정은 이 단계에서 고정하는 것이 좋습니다. 계획 후반에 파일 책임이 바뀌면 전체 작업이 흔들립니다.
+
+## 작업 단위 규칙
+
+각 단계는 2~5분 안에 수행 가능한 하나의 행동이어야 합니다.
+
+- 실패 테스트 작성
+- 테스트를 실행해 실패 확인
+- 최소 구현 작성
+- 테스트를 실행해 통과 확인
+- 커밋
+
+이처럼 한 단계에는 한 행동만 담습니다.
+
+좋은 계획은 "무엇을 할지"만 적지 않고, "어떻게 검증할지"까지 함께 적습니다.
+
+## 계획 문서 헤더
+
+모든 계획 문서는 다음 구조로 시작합니다.
+
+```markdown
+# [기능명] 구현 계획
+> **에이전트 작업자용:** 각 작업은 체크박스(`- [ ]`)로 추적합니다.
+**목표:** [이 기능이 무엇을 만드는지 한 문장]
+**아키텍처:** [접근 방식 2~3문장]
+**기술 스택:** [핵심 기술]
+---
+```
+
+## 작업 구조
+
+각 작업은 아래 내용을 포함해야 합니다.
+
+- 대상 파일 경로
+- 생성/수정/테스트 파일 구분
+- 실제 테스트 코드 예시
+- 실행 명령과 기대 결과
+- 최소 구현 코드 예시
+- 커밋 명령 예시
+
+가능하다면 각 작업은 독립적으로 읽혀야 합니다. 작업을 순서대로 읽지 않아도 필요한 정보가 빠지지 않아야 합니다.
+
+## 금지 사항
+
+다음과 같은 placeholder는 허용하지 않습니다.
+
+- TBD
+- TODO
+- 나중에 구현
+- 적절한 에러 처리 추가
+- 위 내용을 테스트 작성
+- Task N과 유사
+- 방법 설명만 있고 실제 코드나 명령이 없는 단계
+
+모든 단계는 실행에 필요한 실제 내용을 포함해야 합니다.
+
+다음 표현도 피합니다.
+
+- 적당히 구현
+- 필요하면 보완
+- 상황에 맞게 처리
+- 일반적인 에러 처리 추가
+- 위 단계 참고
+
+이런 표현은 실행 정보를 숨기기 때문에 계획 품질을 떨어뜨립니다.
+
+## 자체 검토
+
+계획 작성 후 아래를 스스로 점검합니다.
+
+1. 명세의 모든 요구사항이 작업에 반영됐는가
+2. placeholder나 빈칸이 남지 않았는가
+3. 함수명, 타입, 시그니처, 속성명이 작업 간 일관적인가
+
+빠진 요구사항이 있으면 즉시 작업을 추가합니다.
+
+추가로 아래도 확인합니다.
+
+- 각 작업이 실제로 끝나는 단위인지
+- 테스트나 검증 단계가 빠지지 않았는지
+- 파일 경로가 모호하지 않은지
+- 한 작업에 여러 행동이 뭉쳐 있지 않은지
+
+## 완료 후 인계
+
+계획 저장 후에는 실행 방식을 사용자에게 선택하게 합니다.
+
+- 서브에이전트 기반 실행
+- 현재 세션에서 인라인 실행
+
+핵심은, 구현 전에 계획이 먼저 완성되고 검토 가능해야 한다는 점입니다.
+
+## 기대 결과
+
+이 스킬의 결과물은 다음을 만족해야 합니다.
+
+- 구현자가 문맥 없이도 작업을 시작할 수 있어야 합니다.
+- 각 작업은 체크리스트처럼 따라갈 수 있어야 합니다.
+- 테스트와 검증 명령이 포함되어 있어야 합니다.
+- 문서 안에 실행 가능한 수준의 구체성이 있어야 합니다.