report-issuelisted

## 작업 흐름 ### 1단계: 맥락 파악 현재 레포 확인 (이 스킬은 어느 레포에서든 실행되는 범용 스킬이다 — 지금 작업 중인 레포 기준으로 매번 새로 조회한다): ```bash gh repo view --json nameWithOwner,owner,visibility gh label list gh api "repos/{owner}/{repo}/milestones?state=open" gh api user -q .login ``` 레포 소유자가 `gh api user`로 확인한 **내 개인 계정**과 같고 visibility가 `PRIVATE`이면 "개인 private 레포"로 판단한다 — 3단계 STOP을 생략한다 (아래 3단계 참고). 그 외에는 기존대로 STOP을 지킨다. 사용자가 제공한 내용에서 다음을 추출: - **무엇이 문제인가 / 무엇이 필요��가** (증상 또는 요구사항) - **어떤 환경·범위인가** (플랫폼, 화면, 기능 영역) - **완료 기준은 무엇인가** (언제 이슈를 닫을 수 있는가) 정보가 부족하면 한 번만 질문한다. 여러 번 묻지 않는다. ### 2단계: 타입·우선순위·담당자·마일스톤 판단 **타입** — 사용자 말에서 추론한다: | 표현 예시 | 타입 | |-----------|------| | "안 돼요", "동작 안 해", "깨졌어", "오류" | `fix` | | "추가해줘", "만들어줘", "기능이 필요해" | `feat` | | "느려", "개선", "더 좋게" | `perf` / `feat` | | "코드 정리", "리팩터링" | `refactor` | | "설정", "패키지", "환경" | `chore` | **우선순위** — `priority: high/medium/low` 라벨이 레포에 있으면(`gh label list` 결과 기준), 완료 기준·영향 범위로 추론해 하나를 추천한다. 그런 라벨 체계가 없는 레포면 이 항목은 건너뛴다: | 신호 | 우선순위 | |------|---------| | 로그인·인증 실패, 데이터 유실·손상, 보안 취약점, 크래시, 핵심 플로우 완전 차단 | `high` | | 그 외 일반 버그, 기능 요청, UX 개선 | `medium` | | 코드 정리, 리팩터, 사소한 UI 오차, 테스트 보강 | `low` | **담당자** — 완료 기준이 **지금 작업 중인 레포 코드 변경만으로 달성 가능한지**로 판단한다: - 가능 → `@me` - 이 레포 밖(다른 레포·다른 팀 영역) 변경이 필요 → 미배정 + 본문 참고(Notes)에 "타 레포/팀 협의 필요"라고 명시. 다른 사람에게 자동으로 배정하지 않는다(다른 팀·다른 트래커에서 별도로 관리되는 작업일 수 있어서). **마일스톤** — 1단계에서 조회한 열린 마일스톤 목록과 이슈 내용을 비교해 가장 가까운 것 하나를 후보로 고른다. 열린 마일스톤이 없거나 뚜렷하게 맞는 게 없으면 배정하지 않는다("해당 없음"으로 표시). ### 3단계: 이슈 초안 작성 후 반드시 멈춤 [STOP] 아