Omd:issue

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

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

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

Verb 판별

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에서 재현 없이 닫지 않는다 — "아마 고쳐졌을 것"은 닫는 사유가 아니다.
• 이 스킬 자체의 미흡함도 이 스킬로 접수한다.