prove-it-works

Files (1)

• SKILL.md

SKILL.md (first lines)

# prove-it-works

모든 작업 산출물은 실물을 직접 확인해서 검증한다. 프록시, 자기 보고, "컴파일 된다"로 추론하지 않는다.

검증되지 않은 작업의 정확성은 알 수 없는 상태다. 간접 검증(파일 mtime, 캐시된 스크린샷, 에이전트 자기 보고)은 싸 보이지만, 틀린 추론 위에 행동하는 비용이 직접 확인 비용보다 훨씬 크다.

## 패턴

작업을 마치면 스스로 묻는다: **"이게 실제로 동작한다는 걸 어떻게 증명하지?"**

프록시가 아니라 실물을 확인한다:

- 프로세스 생존은 파생 상태가 아니라 직접 확인한다.
- 캐시·파생 표현이 아니라 실제 저장된 값을 읽는다.
- 검증이 실패하면 시스템보다 **관찰 방법을 먼저 의심**한다. 너무 쉽게 통과해도 마찬가지다. 빈 스크린샷도 게으른 게이트는 통과한다.
- 검사 명령 뒤에 `; echo`, `| head`, `| sort`를 붙이면 원래 종료 상태가 사라진다. 성공 판정은 `cmd && echo OK`, 파이프는 `set -o pipefail` 또는 producer 출력을 파일에 받아 `$?`를 먼저 검사한 뒤 소비한다. 삭제·차단 결정의 입력을 만드는 조회는 실패 시 빈 결과가 아니라 중단으로 처리한다.

코드와 기능:

1. 빌드한다 (필요조건일 뿐 충분조건이 아니다)
2. 실행해서 실제 기능 경로를 태운다
3. 전체 체인을 확인한다: 입력에서 출력까지 데이터가 흐르는가
4. 연동 작업은 통신 경로를 end-to-end로 확인한다

변경 종류에 맞는 surface에서 검증한다:

| 변경 | 검증 |
|---|---|
| CLI 변경 | 실제 명령 실행 |
| UI 변경 | 바뀐 플로우를 직접 주행 |
| 마이그레이션 | 실제 입력 재생 |
| 성능 변경 | 전후 trace/측정치 비교 |
| 저장 변경 | 저장된 값을 다시 읽기 |

레포에 `verify` 또는 `verify-<app>` 계열 프로젝트 스킬이 있으면 (예: product 레포의 `.agents/skills/verify`) 그 하네스(Launch/Doctor/Drive/Evidence)로 검증한다. 없는데 같은 검증을 반복하게 될 레포라면 `create-verification-skill`로 만든다.

## 위임 검증: 요약이 아니라 아티팩트

서브에이전트·Pickle 작업물은 delegate의 요약이 아니라 실제 산출물(git diff, 파일 내용, 런타임 동작)을 검사한다. 에이전트는 실제 일어난 일이 아니라 **의도한 일을 보고**하는 경향이 있다.

## 스크립트가 최강의 증거

가장 강한 증거는 일회성 눈확인이 아니라 **같은 비교를 재실행하는 결정적 스크립트**다. 스크립트를 작성하고, 실행하고, 그 출력을 리뷰어가 재실행할 수 있는 아티팩트로 남긴다. 구/신 출력을 비교하는 스크립트는 눈으로 훑을 때 놓치는 것을 잡는다.

- 대부분의 작업: 아티팩트를 보이는 곳에 두면 충분하다. 커밋은 불필요.
- 대형 포팅·마이그레이션처럼 감사 가능한 트레일이 필요한 작업: `show-me-your-work` 스킬로 결정 로그와 함께 커밋한다.

## 판정 어휘

검증 결과는 VERIFIED / NOT VERIFIED / INCONCLUSIVE 중 하나다. **INCONCLUSIVE는 pass가 아니다.** 잘못된 surface에서의 통과도 pass가 아니다. 부정적 결과를 숨기지 않고 플래그한다.

From Jonghakseo/my-pi, MIT.

More from Jonghakseo/my-pi