Skip to content
Back to skills

Verify

ASecurity

코드 변경·버그 수정·리팩터 후 실제 실행으로 반영 상태, 변경한 분기, 기존 동작 보존을 확인한다. 완료 보고 전 검증과 배포·반영 확인 요청에 사용한다. 결함 분석은 code-review, 구동 확인은 이 스킬이 맡는다. 배포는 요청 범위에 있을 때만 한다.

  • 6 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 3, 2026
ai-agentsbashcode-reviewgit

Security analysis

A100/100

Scanned September 28, 2026

npx -y skills add tigu77/tiguclaw --skill verify --agent claude-code

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.

Security grade badge for Verify
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/tigu77-verify/badge)](https://www.skillsdirectory.com/skills/tigu77-verify)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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 는 배포·부팅·분기 실측을 하지 않는다.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.