sbom.yml 수동 실행이 실제로 필요한 경우를 문서화한다 (#55)

이번 세션에서 워크플로 수동 실행을 두 번 잘못 썼다: (1) 이미 연 PR에 대고
workflow_dispatch를 또 돌려 pull_request 자동 트리거와 완전히 중복시켰다,
(2) catalog-tag-update.yml이 GITHUB_TOKEN으로 force-push한 브랜치에서
--chart 스코프를 빠뜨려 카탈로그 전체(58차트)를 스캔했다.

sbom-cve-gate SKILL.md에 "gh workflow run은 언제 실제로 필요한가" 절을 추가해
정리했다 — PR이 이미 그 경로를 건드리면 pull_request 트리거가 자동으로 돈다
(gh pr checks로 먼저 확인). 수동 실행이 실제로 필요한 건 PR이 아직 없거나,
GITHUB_TOKEN이 force-push해 재귀 방지로 pull_request 이벤트가 안 뜨는 경우뿐이다.
수동 실행 시엔 -f chart=<차트명>으로 반드시 스코프를 좁힌다.

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

.claude/skills/sbom-cve-gate/SKILL.md

@@ -25,6 +25,24 @@ gh run watch --repo <org>/dip-catalog
 레지스트리 인증이 필요하다 — `TRIVY_USERNAME`/`TRIVY_PASSWORD`(단일) 또는 `DOCKER_CONFIG`(다중).
 빠른 검증은 generate 단계에 `LIMIT=3`.
 
+### `gh workflow run`은 언제 실제로 필요한가
+
+`sbom.yml`은 `pull_request`(경로 `manifests/helm/**`)로 이미 자동 트리거된다. **PR이
+이미 열려 있고 그 PR이 이 경로를 건드린다면 수동 실행은 중복이다** — 열자마자 자동으로
+이미 돌았을 가능성이 높다. `gh pr checks <번호>`로 먼저 확인한다.
+
+수동 실행(`workflow_dispatch`)이 실제로 필요한 경우는 둘뿐이다:
+
+1. **아직 PR이 없다** — 브랜치에 push만 했거나, PR을 열기 전에 미리 확인하고 싶을 때.
+2. **PR의 브랜치가 워크플로 자신의 `GITHUB_TOKEN`으로 force-push됐다** — 예:
+   `catalog-tag-update.yml`이 고정 브랜치에 매번 force-push하는 경우. GitHub은 기본
+   `GITHUB_TOKEN`으로 일어난 push에 대해 재귀 방지로 `pull_request` 이벤트를 발생시키지
+   않는다 — 이때는 `gh pr checks`가 빈 목록을 보여준다(실측: PR #50).
+
+**수동 실행할 땐 반드시 `-f chart=<차트명>`으로 스코프를 좁힌다.** 빠뜨리면 전체
+카탈로그(58차트·180+이미지)를 스캔해 SBOM 생성 단계에서만 10분 넘게 걸린다(실측).
+PR이 여러 차트를 건드리면 차트별로 나눠 여러 번 돌리거나, `limit`으로 상한을 둔다.
+
 ## 결과 해석 시 반드시 볼 것
 
 **`CoverageProbe`를 먼저 본다.** findings 0건이 "진짜 0건"인지 "스캐너가 그 배포판을 모르는