/pr 스킬이 화면 변경 PR 에 스크린샷을 자동 첨부하도록

[m-a-king]

왜

#712 가 계기다. 3열 보드 레이아웃이 작업의 본질인데 PR 본문에는 코드 이야기만 있다. 리뷰어는 화면이 어떻게 생겼는지 상상해야 한다. 화면을 바꾼 PR 은 스크린샷 한 장이 설명 열 줄보다 낫다.

무엇을

/pr 스킬이 화면을 바꾼 PR 을 감지해 스크린샷을 찍고 본문에 넣게 한다.

먼저 아래 셋을 조사하고 실측으로 검증한다. 검증 전에는 스킬을 고치지 않는다 — 추측으로 절차를 박으면 매번 실패하는 단계가 스킬에 영구히 남는다.

1. 이미지를 어디에 올리는가 (가장 큰 장벽)

GitHub 은 PR 본문 이미지 업로드에 공개 API 를 제공하지 않는 것으로 보인다. 웹 UI 에 드래그해야 user-attachments URL 이 발급된다. gh CLI 로는 마크다운에 URL 을 넣을 수만 있고 이미지 자체를 올릴 수 없다.

후보와 각각의 트레이드오프를 실측한다.

• 릴리스 에셋: gh release upload 후 공개 URL 참조. 릴리스를 이미지 저장소로 쓰는 것이 적절한지, URL 이 영속적인지.
• orphan 브랜치: 이미지 전용 브랜치에 커밋하고 raw.githubusercontent.com 참조. 정리 비용과 브랜치 오염.
• 레포에 직접 커밋: 히스토리에 바이너리가 누적된다. 선호하지 않는다.
• 사람이 웹 UI 로 드래그: 자동화를 포기하고 스킬은 "찍어서 경로만 알려준다" 까지만.

2. 스크린샷을 찍으려면 앱이 떠야 한다

#712 작업에서 실제로 겪은 것들이다.

• MySQL 과 Redis 컨테이너가 없으면 직접 띄워야 한다.
• application.yml 의 필수 env 가 시간이 지나며 늘어난다. Apple 과 Google OAuth 프로퍼티가 새로 필수가 되어 부팅에 두 번 실패했다. 메모리에 적어둔 로컬 기동 방법이 낡아 있었다.
• Claude in Chrome 자동화가 세션 내내 죽어 있었다. example.com 조차 에러 페이지였다.

헤드리스 Chrome 바이너리를 직접 부르는 것이 대안인지, 로컬 기동 env 를 재현 가능한 형태로 둘 수 있는지 확인한다.

3. "화면을 바꾼 PR" 을 어떻게 판정하는가

templates/ 나 static/ 아래 변경이 있으면 되는가. 그것만으로는 과잉(주석만 고쳐도 발동)과 누락(컨트롤러가 모델을 바꿔 화면이 달라짐)이 동시에 난다. 어느 URL 을, 어떤 데이터 상태에서, 전후 비교까지 찍을지는 사람 판단이 낀다.

CLAUDE.local.md 의 "층" 원칙대로, 기계가 오탐 없이 판정할 수 있는 부분과 판단이 필요한 부분의 경계를 먼저 정한다.

범위

• .claude/commands/pr.md
• 필요하면 스크린샷 촬영을 돕는 스크립트