omd:issue — 피드백 접수와 처리 루프

불만은 채팅에 남으면 사라진다. 이 스킬은 불만을 kwakseongjae/oh-my-design의 GitHub 이슈로 옮겨 처리 가능한 큐로 만들고, 그 큐를 비우는 배치 verb까지 제공한다.

Vercel의 design.md 루프가 좋은 선례다 — 그들은 매주 Slack·GitHub·Figma의 불평을 수집해 그룹화하고, 각 교정을 "일관되게 강제할 수 있는 가장 좁은 자리"에 배치한 뒤, 그 종류의 불평이 실제로 줄었는지 추적한다. 이 스킬의 process verb가 같은 루프다.

Verb 판별

발화	verb
"이슈 등록", "신고할래", "버그", "기능 요청", "이거 불편해"	file (기본)
"이슈 목록", "쌓인 피드백 보여줘"	list
"이슈 처리해줘", "피드백 정리", "process feedback"	process

verb: file — 접수

1. 수집 (부족한 것만 물어라 — 한 배치로)

• 대상: 어느 스킬/표면인가 (omd:apply, omd:harness, 카탈로그 레퍼런스, CLI, 웹 …)
• 실제로 일어난 일: 재현 가능한 서술. 실행한 명령·발화 원문이 있으면 그대로.
• 기대한 것: 무엇이 나왔어야 하나.
• 환경: omd --version 출력, 호스트 CLI(Claude Code / Codex / Cursor), OS.
• 증거: 산출물 경로·스크린샷·로그 조각. 있으면 붙이고 없으면 넘어간다.

2. 공개 레포 위생 (필수 — 건너뛰지 마라)

레포는 PUBLIC이다. 이슈 본문에 다음이 들어가면 안 된다:

• API 키·토큰·이메일 등 자격증명과 개인정보
• 사용자의 비공개 프로젝트 코드·상호·미공개 제품명 — 재현에 필요하면 일반화해라 ("우리 결제 페이지" → "3-state 결제 완료 화면")
• 봉인 해제 전 벤치마크 수치 (T3 등 진행 중 실험의 중간 수치)

수집 내용에 위 항목이 보이면 제거·일반화한 뒤, 사용자 모드에서는 최종 본문을 보여주고 승인받고 나서 올린다. 내부 모드는 바로 올리되 같은 위생 규칙을 지킨다.

3. 작성

제목: [<스킬/표면>] <한 줄 증상> — 예: [omd:apply] 톤 교정 후 preferences.md에 중복 기록됨

본문 템플릿:

## 무엇이 일어났나
<재현 서술 — 실행한 것 그대로>

## 기대한 것
<...>

## 환경
- omd: <버전> / 호스트: <Claude Code|Codex|Cursor> / OS: <...>

## 증거
<로그·경로·스크린샷. 없으면 "없음">

라벨: 항상 skill-feedback + 성격에 따라 bug 또는 enhancement. 내부 도그푸딩 접수는 dogfood를 추가한다.

4. 제출 경로

• gh 인증이 있으면: gh issue create -R kwakseongjae/oh-my-design --title "..." --body-file <tmp> --label skill-feedback,bug
• gh가 없거나 미인증이면 (일반 사용자 흔함): 사전 채움 URL을 만들어 건네라 — https://github.com/kwakseongjae/oh-my-design/issues/new?title=<urlencoded>&body=<urlencoded>&labels=skill-feedback,bug 클릭 한 번으로 접수되게. URL이 2,000자를 넘으면 본문을 요약하고 상세는 사용자가 붙여넣도록 안내한다.

내부 도그푸딩 모드

오케스트레이터·서브에이전트가 스킬을 돌리다 미흡함을 발견하면 채팅 보고로 끝내지 말고 이 verb로 접수해라. 판별 기준: 지금 세션에서 즉시 고칠 범위가 아니고, 다음에 또 만날 문제라면 이슈다. 접수 시 발견 맥락(어떤 작업 중이었나)을 본문 첫 줄에 적고 dogfood 라벨을 붙인다. 진행 중 작업을 멈추지 않는다 — 접수는 30초, 처리는 process verb의 일이다.

verb: list — 큐 확인

gh issue list -R kwakseongjae/oh-my-design --label skill-feedback --state open \
  --json number,title,labels,createdAt --limit 50

dogfood / 사용자 접수를 나눠 보여주고, 오래된 순으로 정렬해 방치를 드러낸다.

verb: process — 배치 처리 루프

돌고 있는 작업이 있으면 그것을 먼저 끝내고 시작한다. 이 verb는 유휴 시간·작업 단위 사이·사용자가 명시 요청했을 때 실행한다.

--dry-run이면 아래 2의 재현·분류까지만 하고 처리 계획표(이슈 번호·판정·예정 조치)를 낸다 — 코멘트·라벨·닫기·커밋 금지.

1. list로 열린 skill-feedback 이슈를 오래된 순으로 가져온다.
2. 이슈마다:
   • 재현 — 본문의 재현 서술을 실제로 실행한다. 재현 환경이 레포 전용(벤치·내부 도구)이라 설치본에서 원리적으로 불가하면 needs-repo-env 라벨로 분류하고 큐에 남긴다. 제보 내용이 부족해 재현이 안 되는 경우에만 그 사실과 시도한 것을 코멘트로 남기고 question 라벨 후 다음으로.
   • 분류 — 중복이면 원본에 링크 걸고 duplicate 닫기. 의도된 동작이면 근거 (스킬 문서·스펙 조항)를 코멘트로 남기고 wontfix 닫기.
   • 수정 — 고칠 수 있으면 고친다. 교정은 그것을 일관되게 강제할 수 있는 가장 좁은 자리에 넣는다: 판단 규칙이면 해당 SKILL.md, 기계 검증 가능하면 게이트나 검사기 스크립트, 반복 발화 문제면 스킬 description의 트리거.
   • 닫기 — 수정 커밋을 링크한 코멘트와 함께 닫는다.
3. 세션당 처리 상한 5건 — 재현이 각각 실작업이라 그 이상은 품질이 깨진다. 남은 것은 개수와 함께 보고한다.
4. 처리 후 같은 종류의 접수가 실제로 줄었는지는 다음 process 때 list의 라벨 분포로 확인한다. 안 줄었으면 교정이 좁은 자리에 안 들어간 것이다.

하드 룰

• 사용자 승인 없이 사용자 모드 이슈를 올리지 않는다 (내부 dogfood는 예외).
• 이슈 본문에 자격증명·비공개 코드·미봉인 벤치 수치를 넣지 않는다.
• process에서 재현 없이 닫지 않는다 — "아마 고쳐졌을 것"은 닫는 사유가 아니다.
• 이 스킬 자체의 미흡함도 이 스킬로 접수한다.