Report issue

작업 흐름

1단계: 맥락 파악

현재 레포 확인:

gh repo view --json nameWithOwner
gh label list

사용자가 제공한 내용에서 다음을 추출:

• 무엇이 문제인가 / 무엇이 필요한가 (증상 또는 요구사항)
• 어떤 환경·범위인가 (플랫폼, 화면, 기능 영역)
• 완료 기준은 무엇인가 (언제 이슈를 닫을 수 있는가)

정보가 부족하면 한 번만 질문한다. 여러 번 묻지 않는다.

2단계: 이슈 타입 판단

사용자 말에서 타입을 추론한다:

표현 예시	타입
"안 돼요", "동작 안 해", "깨졌어", "오류"	fix
"추가해줘", "만들어줘", "기능이 필요해"	feat
"느려", "개선", "더 좋게"	perf / feat
"코드 정리", "리팩터링"	refactor
"설정", "패키지", "환경"	chore

3단계: 이슈 초안 작성 후 반드시 멈춤 [STOP]

아래 템플릿으로 초안을 작성해 사용자에게 보여준다:

제목: 타입: 한 줄 요약 (동사 원형으로 시작)

## 문제 (Problem)
<!-- 지금 무엇이 깨져 있거나 부족한가. 증상과 영향 범위를 1-3문장으로. -->

## 작업 범위 (Scope)
<!-- 이번 이슈에서 바꾸는 것. 바꾸지 않는 것도 명시하면 좋음. -->
-

## 완료 기준 (Done When)
<!-- 검증 가능한 형태로. -->
-

## 참고 (Notes)
<!-- 재현 환경, 관련 이슈·PR 링크. 없으면 섹션 생략. -->

작성 원칙:

• 개조식, 간결하게
• 구현 세부 사항(코드 라인 등)은 PR에 — 이슈에 넣지 않음
• 검증 시나리오 전체는 PR checklist에 — 이슈에는 완료 기준만
• 외부 협업자가 알 필요 없거나 이해할 수 없는 private·내부 전용 정보는 본문에 넣지 않음 — 개인 메모, 로컬 경로·내부 IP, 내부 임시 분석 등. 공유 가능한 형태로 요약하거나 제외

초안 작성 후 사용자 확인을 기다린다. 수정 요청이 오면 반영 후 다시 대기한다.

4단계: 이슈 생성 [사용자 명시적 승인 후에만]

"올려줘", "생성해줘", "만들어줘", "ok", "좋아" 등 명시적 지시 후 실행:

gh issue create \
  --title "<제목>" \
  --label "<타입>" \
  --assignee "@me" \
  --body "$(cat <<'EOF'
<본문>
EOF
)"

• 라벨은 gh label list로 확인한 것만 사용
• --assignee "@me" 기본 포함
• 생성 완료 후 이슈 URL 전달
• 이슈 번호를 브랜치명에 연결할 수 있음을 안내 (예: fix/19-ios-logout-confirm-button)