Installs into .claude/skills of the current project.
Are you the author of Verify?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/tigu77-verify)
---
name: verify
description: "코드 변경·버그 수정·리팩터 후 실제 실행으로 반영 상태, 변경한 분기, 기존 동작 보존을 확인한다. 완료 보고 전 검증과 배포·반영 확인 요청에 사용한다. 결함 분석은 code-review, 구동 확인은 이 스킬이 맡는다. 배포는 요청 범위에 있을 때만 한다."
---
# Verify — 변경이 실제로 배포·동작하는지 구동 확인
"고쳤다"·"커밋했다"가 아니라 **"신 코드가 라이브에서 실제로 도는가"** 를 grep·프로세스·실행으로 확정한다.
어댑터(claude/codex/openai) 무관 — 전부 Bash 명령 수준. SYSTEM.md §1 「완료」 정의의 실행 절차.
## A. 반영 실측 — 변경이 실제로 도는가
원칙: 네가 바꾼 *소스*와 지금 *실제로 도는 것*이 같은지 확인한다. 인터프리트 실행이면 리로드로,
컴파일·빌드 산출물이면 재빌드+재배포 후에야 반영된다 — 그 프로젝트의 배포·실행 방식을 따른다.
- **① 산출물–소스 일치**: 이번에 바꾼 *고유 마커*(새 함수명·새 문구)가 *실제로 도는 산출물*에도 있는지
grep. 없으면 빌드/배포 누락(소스만 바뀐 상태). **옛 마커가 산출물에 남았는지 역방향으로도 확인**하라
(신·구 공존 = 부분 빌드 신호).
- **② 시각 순서**: 소스 수정 ≤ 빌드/배포 ≤ 프로세스 기동 순서여야 신 코드가 로드된 것. mtime 은
`ls -la`, 프로세스 기동은 `ps -o lstart= -p <pid>`. **소스가 산출물보다 새로우면 빌드 후 재수정된 것
— 재빌드부터.**
- **③ 실동작 마커**: 바뀐 경로를 실제 1회 흘려 로그·출력·응답에서 신 동작을 관측한다.
- 불일치 → 그 런타임의 재빌드·재배포 → **재실측**. 소스 저장·커밋·typecheck 통과만 = 미완.
> **예 — 컴파일·빌드 후 배포되는 서비스:** 소스 수정 → 재빌드 → 재배포/프로세스 재시작 →
> 도는 산출물에서 마커 `grep`(①) + 산출물 mtime vs 프로세스 기동시각(②) + 런타임 로그·응답에서
> 신 동작 관측(③). 인터프리트·핫리로드 런타임이면 빌드 단계 없이 리로드 후 ①③. 정적 사이트·스크립트도
> 같은 골격: *바꾼 것*이 *실제로 서비스되는 것*에 반영됐는지 대조한다.
## B. 분기 커버리지 — 새 분기를 실제로 탔는가
- 이번 변경에서 **새로 만들거나 바꾼 조건분기를 나열**한다(diff 또는 확보한 원문과
대조해 `if`/삼항/switch/단락 연산/길이·개수 비교를 확인한다).
- 분기마다 **그 분기를 실제로 타는 입력 최소 1개**로 실측한다(단위 실행·수동 호출·실메시지).
예: `length > 4096` 분기를 새로 만들었으면 4096자 초과 입력을 반드시 하나 넣어본다.
- 기존 픽스처·테스트가 전부 같은 분기만 치면 새 경로는 **미검증**으로 명시하라 — "테스트 통과"가
그 분기의 검증이 아니다.
## C. 행동 보존 대조 — 기존 동작을 바꾸는 수정
- 교체·리팩터뿐 아니라 **기존 조건·기본값·변환을 바꾸는 버그 수정**에도 적용한다.
- 변경이 영향을 주는 입력 유형별로 수정 전 동작과 요구된 변경을 대조한다. 테스트에 없는 기존
분기도 포함해 대표 입력으로 확인한다. 수정 전 코드는 git show 등으로 읽고, 버전 관리가
없으면 편집 전에 원문을 확보한다. 신 코드만 보고 옛 동작을 추정하지 않는다.
- 신 구현과 항목별 대조: 각 옛 동작이 **보존 / 의도적 변경 / 회귀** 중 무엇인지 명시한다.
- 회귀를 '의도적 다운그레이드'로 합리화하지 마라 — 의도적 변경이면 그 근거와 사용자 영향을 적고,
근거가 없으면 복구한다.
## D. 완료 보고 전 체크리스트
보고 직전 아래를 확인하고, 미충족 항목은 **"미완/보류"로 명시**한다(조용한 '완료' 금지):
- [ ] 라이브 반영됨 — **단 배포가 요청 범위 안일 때만 실행한다.** 범위 밖이면 돌리지 말고
«반영했으나 미배포» 로 적어라. 헌법이 *"「고쳐줘」에 커밋·배포까지 하지 마라"* 고
못 박았고, 배포는 **돌고 있는 응답을 끊는다**. 미배포는 결함이 아니라 상태다.
- [ ] 산출물 마커 grep + 시각 순서(소스≤산출물≤기동) 통과 (§A①②)
- [ ] 새 분기마다 실입력 1개 실측 (§B)
- [ ] 기존 동작을 바꿨으면 수정 전후 대조 완료 (§C)
- [ ] 실동작 마커로 신 경로 1회 관측 (§A③)
## 경계 — code-review 와의 분업 (중복 구현 금지)
- **code-review** = 정적 결함 탐지("이 코드에 버그·더 나은 방법이 있나" — diff 를 *읽는다*). 반영 *전*.
- **verify** = 동적 구동 확인("이 변경이 *실제로 반영·동작하나*" — 산출물을 *돌린다*). 반영 *후*.
- verify 는 결함 분석을 재구현하지 않고, code-review 는 배포·부팅·분기 실측을 하지 않는다.