--- name: create-verification-skill description: "사용자가 하는 방식으로 앱을 구동하는 프로젝트 로컬 검증 스킬을 생성하세요 — 어떤 언어, 프레임워크 또는 플랫폼이든. /create-verification-skill, \"make a control skill for this repo\", 또는 프로젝트에 UI/CLI/서비스 동작을 증명하는 스크립트 방법이 없을 때 사용하세요." disable-model-invocation: true --- # Create a verification skill 모든 진지한 프로젝트는 실제 앱을 구동하고 동작을 증명하는 스크립트 방법이 필요합니다: 앱을 시작하고, 사용자가 하는 방식으로 기능을 실행하고, 증거를 캡처합니다. 이 스킬은 저장소에 맞춤화된 프로젝트 로컬 스킬 (`.cursor/skills/verify-/`)로 그것을 생성합니다. 당신은 인간이 아니라 다음 에이전트를 위해 생성기의 출력을 작성합니다: 앱을 본 적이 없는 에이전트가 작업 중에 차갑게 읽을 것입니다. ## 1. 사용자가 아니라 저장소를 인터뷰 코드베이스에서 이것들에 답하고 관찰할 수 없는 것만 사용자에게 물어보세요: - **Surface (표면):** 사용자가 실제로 무엇을 터치하나요? 웹 UI, CLI/TUI, 데스크톱 앱, API, 모바일 앱, 라이브러리? 저장소는 여러 개를 가질 수 있습니다; 주요 것을 선택하고 나머지를 기록하세요. - **Run (실행):** 앱이 로컬에서 어떻게 시작되나요? 저장소 자체의 문서화된 개발 명령 (패키지 스크립트, Makefile, README 퀵스타트)을 선호하세요. 포트, 환경 변수, 시드 데이터, 인증을 기록하세요. - **Drive (구동):** 에이전트가 프로그래밍 방식으로 어떻게 상호 작용할 수 있나요? 먼저 기존 하니스 — Playwright/Cypress 스펙, expect 스크립트, PTY 헬퍼, curl 가능한 엔드포인트, 디버그 포트. 그런 다음에만 일반 레시피를 선택하세요: 웹 및 Electron용 브라우저/CDP, CLI/TUI용 tmux/PTY 하니스, 서비스용 평범한 HTTP. - **Observe (관찰):** 어떤 증거를 캡처할 수 있나요? 스크린샷, 터미널 트랜스크립트, 응답 본문, 로그, 종료 코드, DB 상태. - **Isolate (격리):** 두 인스턴스가 나란히 실행될 수 있나요 (포트, 데이터 디렉토리, 프로필)? 그렇지 않다면 생성된 스킬에서 그렇게 말하세요: 공유 인스턴스를 이중으로 구동하는 것을 거부하는 것이 사용자의 세션을 손상시키는 것보다 낫습니다. 체크아웃이 그대로 빌드되거나 시작되지 않으면 생성하기 전에 먼저 그것을 수정하세요 (또는 정확하게 보고하세요); 깨진 베이스에 대해 작성된 스킬은 잘못된 단계를 가르칩니다. 관련 없는 누락된 에셋이 시작을 차단할 때 (API가 제공하지 않는 정적 디렉토리, 샘플 구성), 생성된 스킬은 검증 스캐폴딩으로 명확하게 표시하여 그것을 생성하고 정리 시 제거할 수 있습니다. ## 2. 스킬 생성 YAML 프론트매터 (`name: verify-` 및 앱, 표면, 언제 도달할지를 명명하는 `description` — 프론트매터가 없으면 스킬이 등록되지 않음)와 이러한 섹션으로 `.cursor/skills/verify-/SKILL.md`를 작성하세요. 각 섹션은 인터뷰가 실제로 발견한 것에 기반합니다 (자리 표시자가 남지 않음): - **Launch (시작):** 검증을 위해 앱을 시작하는 정확한 명령과 준비되었는지 어떻게 알 수 있는지 (로그 라인, 프롬프트). Launch는 마이그레이션과 시드 데이터를 포함하여 빈 데이터 디렉토리에서 사용 가능한 상태에 도달해야 합니다. Ready는 단지 프로세스가 응답하는 것이 아니라 사용 가능함을 의미합니다. 데이터베이스 헬스 체크는 초기화 스크립트가 아직 실행 중일 때 통과할 수 있습니다. 분해를 포함하세요. 수명이 짧은 CLI 또는 TUI의 경우 유지할 서버가 없습니다: launch는 바이너리를 한 번 빌드하고 (또는 종속성 설치), 그런 다음 각 drive를 자체 격리된 PTY 또는 tmux 세션에서 시작하는 것을 의미합니다. - **Doctor:** "이 인스턴스는 구동할 가치가 있는가?"에 답하는 하나의 읽기 전용 검사 — 프로세스 작동, 올바른 버전/빌드, 우리가 소유한 포트, 유효한 인증. 에이전트는 무언가가 이상해 보일 때마다 이것을 먼저 실행합니다. - **Drive (구동):** 예제가 아니라 이 저장소의 실제 선택자/명령이 있는 하니스 레시피. 좌표 및 탭 순서보다 안정적인 핸들 (ARIA 레이블, 데이터 속성, 프롬프트 문자열, 경로 경로)을 선호하세요. - **Evidence (증거):** 증거를 위해 무엇을 캡처하고 어디로 가는지. 증명 표준을 명시하세요: 내부 세터 또는 테스트 전용 엔드포인트가 아니라 실제 사용자 경로를 실행합니다; 최종 화면만이 아니라 액션과 결과 상태를 캡처합니다; 보이는 것 옆에 부작용 (작성된 파일, 삽입된 행, 전송된 메시지)을 검증합니다; 프로덕션 경계가 이미 외부 시스템을 격리하는 곳에서만 목. 안전한 경로가 드라이 런 또는 테스트 모드일 때, 이름을 신뢰하기보다는 관찰 (파일, 네트워크, git 참조)하여 실제로 건너뛰는 것을 검증하세요: 일부 드라이 런은 여전히 네트워크를 터치하거나 브라우저를 엽니다. - **Cleanup (정리):** 실행이 생성한 인스턴스를 분해하는 방법. 프로세스 이름으로 절대 죽이지 마세요; 시작한 것을 죽이세요. Cleanup은 증거를 제거하지 않고 인스턴스와 스크래치 상태를 제거합니다: 증명 아티팩트는 스킬이 명명한 위치에서 분해 후에도 살아남습니다. - **Helpers:** 스킬이 배송하는 모든 스크립트는 실행 가능하며 그 호출이 스킬 본문에 표시됩니다. 독자가 역공학해야 하는 헬퍼는 헬퍼가 아닙니다. ## 3. 기능 맵 시드 `.cursor/skills/verify-/features/README.md`와 식별할 수 있는 사용자 대면 기능당 하나의 파일을 생성하세요 (시작하려면 상위 3-5개를 목표로, 경로, 명령, 메뉴 또는 문서에서). [`references/feature-map-example/`](references/feature-map-example/)의 형태를 따르세요. README 인덱스와 기능당 하나의 파일. 각 파일은 사용자의 관점에서 답합니다: 기능이 무엇인지, 어떻게 도달하는지, 하니스로 어떻게 구동하는지, 어떤 관찰 가능한 최종 상태가 작동함을 증명하는지. 네 개의 H2는 `Sub-features`, `How to get to it (user POV)`, `Driving it with `, 그리고 `Gotchas`입니다. 시드 데이터가 여정이 필요로 하는 전제 조건이 부족하면 여정은 실패를 보고하고 이유는 해당 기능의 `Gotchas`로 갑니다. 통과하도록 여정을 약화시키지 마세요. 맵은 저장소의 유지 관리되는 검증 소스입니다; 하나의 편리한 진입점을 구동하는 증명은 맵이 다른 것을 나열할 때 불완전합니다. ## 4. 넘기기 전에 생성된 스킬 증명 자체 지침을 한 번 처음부터 끝까지 실행하세요: 시작, doctor, 하나의 매핑된 기능 구동 (하나면 충분합니다; 맵은 나중 실행이 나머지를 커버할 수 있도록 존재합니다), 증거 캡처, 정리. 정리 후, 증거가 여전히 명명된 위치에 존재하는지 확인하세요 — 증명을 먹는 정리는 이 단계에 실패합니다. 실패하는 것을 수정하고, 깨진 시도가 프로세스와 포트를 좌초시키지 않도록 모든 실패한 반복 후에도 생성된 정리를 실행하세요. 실행된 적이 없는 생성된 스킬은 초안이지 제공물이 아닙니다. 실제 대상 대신 대리자에서 증명했다면 (원격 대신 로컬 스택, 새 VM 대신 컨테이너), 대상이 하지 않을 대리자가 수행한 모든 설정 단계를 나열하세요. 해당 단계는 실제 대상에서 실행이 그것들을 커버할 때까지 검증되지 않은 상태로 남습니다. ## 5. 유지보수 루프 제공 앱이 변경됨에 따라 맵을 정직하게 유지하기 위해 `/maintain-verification-skill`을 사용자에게 가리키세요. 그들이 물어볼 때만 주기를 제안하세요.