Pull Request 와 믿을 수 있는 머지 사이에 서 있는 스킬 5개 — 리뷰어를 한 턴에 펼치고, 손머지 직전을 감사하고, 머지된 코드가 정말 주장대로 도는지 증명합니다. 스킬마다 설명서 1건과 사용 예시 1건이 있습니다.
live 와 merged 는 검증을 시작하기 전에 무엇을 검증하고 있는지부터 단언합니다. 여기서 PR 을 승인하거나 머지하는 스킬은 하나도 없습니다.
/gh-verify:review-all <PR#> [remote] [--defer-reply M]
/simplify 자동수정 패스를 먼저 단독으로 돌려 push 한 뒤, agy · codex · opencode · hermes 를 한 턴에 모두 띄우고, 집계 판정을 review-blocked 머지 게이트 라벨로 남긴 뒤 답글 패스를 돈다. 판정을 제출하지 않으며, 같은 head 를 이미 리뷰한 레인은 다시 돌리지 않는다.
/gh-verify:live [<PR#>] [remote] [--url U] [--matrix full]
이미 띄워 둔 앱에 붙어 그 프로세스가 정말 이 PR 의 머지 커밋을 서빙하고 있는지부터 확인하고, 그 다음에야 PR 이 주장한 화면을 기계 판독 가능한 단언으로 몰아 본다. 자기 반증에서 살아남은 발견만 이슈가 된다.
/gh-verify:merged [<PR#>] [remote] [--matrix full]
띄울 앱이 없는 레포용. 머지 커밋을 임시 디렉터리에 클론하고 그 클론 안에서만 검사를 다시 돌린다. 클론과 작업 트리에서 실제로 실행되는 테스트 케이스를 대조해, 한쪽에만 있는 케이스를 발견으로 올린다.
/gh-verify:exception-merge-checklist [<PR#>] [--auto-fix]
CI 는 초록이지만 손으로 머지하는 예외 트랙 PR 을 위한 읽기 전용 10항목 점검 — 깨진 rebase 중간 커밋, lock drift, YAML 파손, 과범위 포매터 write, 새 프레임워크 호출의 mock 누락. --auto-fix 도 스테이징까지만 하고 커밋하지 않는다.
/gh-verify:post-merge-verify <PR#> [remote]
디스패치 전용. 구현하던 탭을 닫고 main 체크아웃을 최신으로 만든 뒤, 감시 레포 레지스트리가 지정한 live 또는 merged 를 새 세션으로 넘긴다. 스스로는 아무것도 검증하지 않고 GitHub 에 쓰지도 않는다.
고르는 기준은 취향이 아니라 PR 의 생애 중 어디에 서 있는가, 그리고 손에 무엇이 쥐어져 있는가입니다.
앱이 이미 떠 있을 때 쓴다. 코드를 서빙하는 모든 프로세스를 cwd → repo root → ancestry 로 거슬러 올라가 머지 커밋과 대조하고, 어긋나면 몇 커밋 뒤처졌는지 말하고 멈춘다. 막으려는 것은 화면은 멀쩡히 뜨는데 검증이 무효인 상태다.
띄울 것이 없는 shell 스크립트 · CLI · 라이브러리 레포용. 클론 실패 · HEAD 불일치 · 더럽지 않아야 할 git status 는 측정 전에 정지 사유다. 막으려는 것은 내 worktree 에서만 초록이고 다른 클론과 CI 에는 그 검사가 존재하지도 않는 상태다.
앞은 여러 리뷰어의 의견을 모아 게이트 라벨 하나로 수렴시키고, 뒤는 그 게이트를 거치지 않고 손으로 머지할 PR 을 마지막으로 훑는다. 둘 다 판정을 제출하지 않는다 — 승인은 이 플러그인의 일이 아니다.
브랜치에 쓰는 스킬은 review-all 하나뿐이고, 그것도 /simplify 자동수정 커밋에 한한다. post-merge-verify 는 실패를 전부 [WARN] 한 줄로 흘려보낸다 — 예외는 stale 한 main 체크아웃뿐으로, 낡은 코드를 검증하는 것은 아무것도 증명하지 않기 때문이다.