report-issuelisted

## 작업 흐름 ### 1단계: 맥락 파악 현재 레포 확인: ```bash gh repo view --json nameWithOwner gh label list ``` 사용자가 제공한 내용에서 다음을 추출: - **무엇이 문제인가 / 무엇이 필요한가** (증상 또는 요구사항) - **어떤 환경·범위인가** (플랫폼, 화면, 기능 영역) - **완료 기준은 무엇인가** (언제 이슈를 닫을 수 있는가) 정보가 부족하면 한 번만 질문한다. 여러 번 묻지 않는다. ### 2단계: 이슈 타입 판단 사용자 말에서 타입을 추론한다: | 표현 예시 | 타입 | |-----------|------| | "안 돼요", "동작 안 해", "깨졌어", "오류" | `fix` | | "추가해줘", "만들어줘", "기능이 필요해" | `feat` | | "느려", "개선", "더 좋게" | `perf` / `feat` | | "코드 정리", "리팩터링" | `refactor` | | "설정", "패키지", "환경" | `chore` | ### 3단계: 이슈 초안 작성 후 반드시 멈춤 [STOP] 아래 템플릿으로 초안을 작성해 사용자에게 보여준다: **제목**: `타입: 한 줄 요약 (동사 원형으로 시작)` ```markdown ## 문제 (Problem) <!-- 지금 무엇이 깨져 있거나 부족한가. 증상과 영향 범위를 1-3문장으로. --> ## 작업 범위 (Scope) <!-- 이번 이슈에서 바꾸는 것. 바꾸지 않는 것도 명시하면 좋음. --> - ## 완료 기준 (Done When) <!-- 검증 가능한 형태로. --> - ## 참고 (Notes) <!-- 재현 환경, 관련 이슈·PR 링크. 없으면 섹션 생략. --> ``` 작성 원칙: - 개조식, 간결하게 - 구현 세부 사항(코드 라인 등)은 PR에 — 이슈에 넣지 않음 - 검증 시나리오 전체는 PR checklist에 — 이슈에는 완료 기준만 - **외부 협업자가 알 필요 없거나 이해할 수 없는 private·내부 전용 정보는 본문에 넣지 않음** — 개인 메모, 로컬 경로·내부 IP, 내부 임시 분석 등. 공유 가능한 형태로 요약하거나 제외 **초안 작성 후 사용자 확인을 기다린다. 수정 요청이 오면 반영 후 다시 대기한다.** ### 4단계: 이슈 생성 [사용자 명시적 승인 후에만] "올려줘", "생성해줘", "만들어줘", "ok", "좋아" 등 명시적 지시 후 실행: ```bash gh issue create \ --title "<제목>" \ --label "<타입>" \ --assignee "@me" \ --body "$(cat <<'EOF' <본문> EOF )" ``` - 라벨은 `gh label list`로 확인한 것만 사용 - `--assignee "@me"` 기본 포함 - 생성 완료 후 이슈 URL 전달 - 이슈 번호를 브랜치명에 연결할 수 있음을 안내 (예: `fix/19-ios-logout-confirm-button`)