# TRAE 테스트 시나리오

이 문서는 현재 저장소에 포함된 10개 스킬을 실제 TRAE에서 바로 검증해 볼 수 있도록 만든 프롬프트형 시나리오 모음입니다.

## 공통 사용법

- 각 시나리오의 **입력 프롬프트**를 그대로 복사해서 TRAE에 넣습니다.
- 기대 동작은 "정답 문장"이 아니라 "어떤 종류의 흐름이 나와야 하는지"를 의미합니다.
- 결과가 다소 다르더라도, 핵심 스킬 호출과 절차가 맞으면 통과로 봅니다.

---

## 1. brainstorming

- **목적:** 구현 전에 설계 중심 흐름으로 들어가는지 확인
- **사전 조건:** 현재 프로젝트가 열려 있어야 함
- **입력 프롬프트:** `간단한 할일 관리 위젯을 추가하고 싶은데 바로 구현하지 말고 먼저 어떻게 설계할지 같이 정리해줘`
- **기대 동작:** 바로 코드 작성으로 들어가지 않고, 질문 또는 설계 흐름으로 진입해야 함
- **확인 포인트:** 한 번에 한 질문, 설계 승인 전 구현 금지, 이후 `writing-plans`로 이어질 여지가 보여야 함

## 2. frontend-design

- **목적:** 평범한 UI 생성이 아니라 강한 미학 방향을 먼저 잡는지 확인
- **사전 조건:** 프론트엔드 결과물을 요청할 수 있는 문맥
- **입력 프롬프트:** `패션 브랜드용 랜딩페이지 히어로 섹션을 만들어줘. 흔한 AI 스타일 말고 강한 개성이 있었으면 좋겠어`
- **기대 동작:** 톤, 타이포그래피, 색상, 레이아웃 같은 미학 방향을 언급해야 함
- **확인 포인트:** "AI 티 나는 화면" 회피, 대담한 스타일 방향, 실제 구현 코드 의도 설명

## 3. ui-ux-pro-max

- **목적:** UI 미감뿐 아니라 UX 품질 기준까지 함께 다루는지 확인
- **사전 조건:** UI 구조 개선 요청 가능
- **입력 프롬프트:** `관리자 대시보드가 뭔가 덜 프로페셔널해 보여. 정보 위계, 접근성, 상호작용 품질 관점에서 개선 방향을 제안해줘`
- **기대 동작:** 접근성, 위계, 상태 표현, 레이아웃, 상호작용 품질을 우선순위 있게 다뤄야 함
- **확인 포인트:** 단순 색상 추천이 아니라 시스템 수준의 개선 기준 제시

## 4. systematic-debugging

- **목적:** 버그 수정 전에 근본 원인 조사 흐름을 밟는지 확인
- **사전 조건:** 버그 상황을 설명할 수 있어야 함
- **입력 프롬프트:** `로그인 후 가끔 대시보드가 빈 화면으로 떠. 일단 추측하지 말고 체계적으로 원인부터 찾는 방식으로 진행해줘`
- **기대 동작:** 재현, 최근 변경, 로그/증거 수집, 가설 검증 순서를 제시해야 함
- **확인 포인트:** 즉시 수정안부터 제안하지 않는지, 원인 조사 단계가 분리되는지

## 5. writing-plans

- **목적:** 구현 전에 체크리스트형 계획을 만드는지 확인
- **사전 조건:** 간단한 요구사항 또는 명세가 있어야 함
- **입력 프롬프트:** `사용자 프로필 편집 기능을 추가해야 해. 코드는 아직 건드리지 말고 파일 단위와 테스트 단위까지 포함한 구현 계획만 작성해줘`
- **기대 동작:** 파일 경로, 작업 순서, 검증 기준, 테스트 단계가 포함된 계획을 작성해야 함
- **확인 포인트:** TODO 수준이 아니라 실행 가능한 단계인지, 작은 단계로 분해되는지

## 6. find-skills

- **목적:** 바로 구현보다 적절한 커뮤니티 스킬 탐색 흐름을 타는지 확인
- **사전 조건:** 특정 작업용 스킬을 찾는 상황
- **입력 프롬프트:** `PR 리뷰를 더 체계적으로 해주는 스킬이 있는지 찾아줘`
- **기대 동작:** 필요한 도메인을 파악하고, 인기/품질 기준을 거쳐 후보를 제시해야 함
- **확인 포인트:** 검색만이 아니라 설치 수, 출처, 설치 명령까지 제공하는지

## 7. using-superpowers

- **목적:** 응답 전에 관련 스킬을 먼저 확인하는 운영 규칙이 작동하는지 확인
- **사전 조건:** 다른 스킬이 분명히 필요한 작업 요청
- **입력 프롬프트:** `새로운 대시보드 페이지를 설계하고 구현해줘`
- **기대 동작:** 바로 구현하기보다 먼저 관련 스킬을 확인하고 적용해야 함
- **확인 포인트:** 프로세스 스킬 우선, 구현 스킬 후순위 원칙이 드러나는지

## 8. karpathy-guidelines

- **목적:** 과설계와 과추정을 줄이는 행동 원칙이 반영되는지 확인
- **사전 조건:** 코드 변경 또는 리팩터링 맥락
- **입력 프롬프트:** `이 기능 리팩터링하되 너무 크게 뜯어고치지 말고 필요한 최소 변경만으로 접근해줘`
- **기대 동작:** 가정 명시, 최소 변경, 검증 기준 중심으로 접근해야 함
- **확인 포인트:** 주변 코드까지 과하게 손대지 않는지, 목표 기반으로 설명하는지

## 9. webapp-testing

- **목적:** 로컬 웹앱 테스트에서 정찰 후 행동 패턴을 따르는지 확인
- **사전 조건:** 로컬 웹앱 또는 정적 HTML을 테스트할 수 있는 상황
- **입력 프롬프트:** `이 로컬 웹앱의 회원가입 폼을 Playwright 방식으로 점검해줘. 바로 클릭하지 말고 먼저 화면 상태부터 확인해줘`
- **기대 동작:** `networkidle` 대기, 스크린샷 또는 DOM 확인, 셀렉터 파악 후 행동 순서를 보여야 함
- **확인 포인트:** 먼저 관찰하고 나중에 상호작용하는지

## 10. agent-browser

- **목적:** 일반 브라우저 도구보다 agent-browser 흐름이 필요한 상황을 인식하는지 확인
- **사전 조건:** 브라우저 자동화 요청
- **입력 프롬프트:** `특정 사이트에 로그인해서 여러 페이지를 돌아다니며 상태를 확인하고 스크린샷도 남겨줘`
- **기대 동작:** `agent-browser skills get core` 같은 시작 절차를 우선 언급해야 함
- **확인 포인트:** 설치된 버전 기준 가이드를 먼저 확인하는지, 특수 가이드 가능성도 보는지

---

## 교차 시나리오 1: 설계 -> 계획

- **목적:** `brainstorming`에서 `writing-plans`로 자연스럽게 이어지는지 확인
- **입력 프롬프트:** `알림 센터 기능을 추가하고 싶어. 먼저 설계부터 하고, 내가 승인하면 계획까지 이어가자`
- **기대 동작:** 처음에는 설계 흐름, 승인 후에는 계획 문서 흐름으로 전환
- **확인 포인트:** 설계와 구현 계획 단계가 섞이지 않는지

## 교차 시나리오 2: 디버깅 -> 검증

- **목적:** 버그 분석 이후 실제 검증 단계로 이어질 수 있는지 확인
- **입력 프롬프트:** `폼 제출 버그를 먼저 근본 원인부터 찾고, 수정 전후 동작을 브라우저에서 검증할 수 있게 정리해줘`
- **기대 동작:** `systematic-debugging` 중심으로 조사하고, 필요 시 `webapp-testing` 또는 브라우저 검증 흐름으로 이어짐
- **확인 포인트:** 원인 분석과 검증이 분리되면서도 연결되는지

## 교차 시나리오 3: UI 설계 -> 품질 향상

- **목적:** `frontend-design`과 `ui-ux-pro-max`가 역할을 나눠 쓰이는지 확인
- **입력 프롬프트:** `이 SaaS 설정 페이지를 더 개성 있게 만들고 싶어. 동시에 접근성과 정보 위계도 챙겨줘`
- **기대 동작:** 미학 방향과 UX 품질 기준을 함께 다루되, 역할이 구분되어야 함
- **확인 포인트:** 스타일 강화와 UX 품질 점검이 모두 보이는지
