---
name: maintain-verification-skill
description: "프로젝트의 검증 스킬과 기능 맵을 정직하게 유지하는 주기적 패스: 기능당 병렬 소스 리더, 모든 기능을 구동하는 하나의 라이브 세션, 최대 하나의 증명된 수정 PR. /maintain-verification-skill 또는 \"audit the verify skill\"에 사용하세요."
disable-model-invocation: true
---

# Maintain a verification skill

기능 맵은 앱이 변경되는 순간 썩습니다. 이 스킬은 `/create-verification-skill`이 생성한 스킬 (또는 기능 맵이 있는 모든 프로젝트 로컬 검증 스킬)의 유지보수 루프입니다. 엄격성의 단위는 모든 문장이 아니라 기능입니다: 모든 글머리 기호를 터미널화하지 않고 소스에서 모든 기능 파일을 커버하고 모든 기능을 라이브로 실행하세요.

## 결과

하나를 선택하고, 어느 것인지 말하세요:

- **clean (깨끗함)** — 모든 기능이 소스 및 라이브 커버리지를 얻었습니다; 배송할 가치가 있는 것이 없습니다. 브랜치 없음, PR 없음.
- **changed (변경됨)** — 하나의 PR이 증명된 문서, 하니스 또는 맵 수정을 배송합니다.
- **blocked (차단됨)** — 커버리지를 완료할 수 없거나 증명된 수정을 안전하게 배송할 수 없었습니다. 정확히 무엇이 차단했는지 말하세요.

## 편집 범위

검증 스킬 자체의 디렉토리만 편집하세요 (SKILL.md, features/, 그리고 소유한 모든 하니스 스크립트). 실행 중 제품 코드를 절대 편집하지 마세요: 맵이 설명하는 동작을 앱이 더 이상 하지 않으면 문서 드리프트 (맵 수정) 또는 제품 회귀 (보고, 문서에서 덮지 마세요)입니다.

## 패스

0. **대상 찾기.** 유지할 검증 스킬을 찾으세요: 본문에 launch/drive 섹션과 기능 맵이 있는 프로젝트 로컬 스킬 (일반적으로 `.cursor/skills/verify-*/`). 여러 후보 → 어느 것인지 물어보세요; 없음 → 멈추고 대상을 발명하는 대신 `/create-verification-skill`을 가리키세요.

1. **인덱스 위생.** 기능 맵 README를 읽고 형제 파일을 glob하세요. 누락, 추가, 중복 또는 죽은 항목을 수정하세요. 경량; 생성된 인벤토리 없음.

2. **소스 웨이브.** 기능 파일당 하나의 읽기 전용 서브에이전트, 동시에 시작됨. 각각은 소스에서 "이 사용자 대면 기능은 어떻게 작동하는가?"를 설명하고, 인용으로 가능성 있는 문서 드리프트를 플래그하고, 하나의 간결한 라이브 검증 레시피를 반환합니다. 자식은 앱을 절대 구동하지 않고 파일을 절대 편집하지 않습니다. 반환 형태: 기능 요약 / 소스 진입점 / 가능성 있는 드리프트 또는 없음 / 하나의 레시피.

3. **조정.** 모든 기능 파일에 반환된 요약이 있습니다. 겹치는 레시피를 가능한 한 적은 앱 상태로 병합하세요. 인용된 드리프트를 스팟 체크하세요; 깨끗한 주장을 재증명하지 마세요. 맵에서 누락된 사용자 대면 표면에 대한 최근 변동을 스윕하세요 — 하나를 누락이라고 부르기 전에 구체적인 소스 경로가 필요합니다.

4. **라이브 패스.** 소스가 깨끗해 보여도 필요합니다. 조정자는 모든 구동을 소유합니다; 검증 스킬 자체의 시작 모델을 따르세요 — 서버 및 UI에 대해 직렬로 구동되는 하나의 오래 살아있는 인스턴스, 또는 수명이 짧은 CLI에 대해 drive당 새로운 격리된 세션 (스킬의 Launch 섹션이 결정하지, 이것이 아닙니다). 최소 한 번 모든 기능을 실행하고, 실패가 무엇이든 전체 패스 동안 세 가지 불변성을 유지하세요: (1) 마지막으로 놀라운 일을 한 이후 헬스 체크하지 않은 인스턴스를 절대 구동하지 마세요 — 첫 구동 전 doctor, 세션이 단위인 각 새 세션에 doctor, 실패한 구동 후 다시 doctor, 그리고 doctor가 실패를 볼 수 없는 곳 (건강한 프로세스에서 쐐기 모양 UI 상태)에서는 희망하기보다는 알려진 상태로 재설정하거나 다시 시작; (2) 지금까지 캡처된 증거는 모든 정리에서 살아남으며, 명명된 위치에서 확인되고, 가정되지 않음; (3) drive가 시작한 것은 해당 drive의 유용성보다 오래 살아남지 않음 — 실패한 반복 잔류물은 세션이 막히거나 종료되거나 공유되었는지 (공유 인스턴스의 경우 인스턴스가 아니라 잔류물을 정리) 여부에 관계없이 정리됩니다. 스킬 드리프트로 인한 doctor 실패는 드리프트입니다: 편집 범위 아래에서 수정하고 한 번 재시도 — 수정이 무효화한 것만 다시 시작, 그 이상은 아님 — `blocked`라고 부르기 전에. 도달할 수 없는 기능은 구체적인 전제 조건 (인증, 권한, OS, 외부 상태)과 시도된 경로가 있을 때만 `verified-unreachable`입니다; 맵이 해당 전제 조건을 생략하면 그것은 드리프트입니다. 트리아지의 모든 하니스 수정은 배송 전에 라이브로 다시 구동됩니다. 최종 분해는 실행의 마지막 drive — 재증명 포함 — 후에 발생하므로 아무것도 실행보다 오래 살아남지 않습니다 (증거는 스킬에 따라 유지됩니다).

5. **트리아지.** 잘못되거나 누락된 사용자 POV 설명 → 문서 드리프트, 수정하세요. 하니스가 구동할 수 없는 작동 동작 → 하니스 갭, 수정하세요; 하니스 수정은 생성과 동일한 헬퍼 규칙을 따릅니다 (스크립트 실행 가능, 스킬 본문에 문서화된 호출). 실제로 깨진 앱 동작 → 제품 갭; 사용자를 위해 기록하고, 이 PR에서 빼세요.

6. **배송 또는 중지.** changed의 경우: 증명된 수정의 하나의 PR, 먼저 모든 변경된 파일을 다시 읽으세요. clean 또는 blocked의 경우: PR 없음, 결과와 커버리지를 정직하게 보고하세요.

간결한 실행 노트 (커버된 기능, 도달할 수 없는 전제 조건, 확인된 드리프트, 결과)를 스크래치 위치에 유지하세요; 커밋하지 마세요.