Issue Draft

Step 3 — Determine issue type

Step 4 — Extract structured content

From the input, identify:

• 무엇을: What needs to be built/fixed
• 왜: Business reason or user pain point
• 어떻게: Technical direction (if mentioned)
• 완료 조건: How we know it's done (acceptance criteria)
• 고려사항: Edge cases, dependencies, risks

Step 5 — Generate issue

Title format:

• feature: [feature] {명사형 기능 설명} (e.g., [feature] 옷장 공유 기능 개발)
• hotfix: [hotfix] {동사형 문제 설명} (e.g., [hotfix] 코디 저장 시 500 에러 수정)

Body:

## 개요
{한 문단으로: 무엇을, 왜 만드는지}

## 개발 방향
{구현 접근법, 영향받는 도메인/레이어, 주요 API 또는 DB 변경}

## 수용 조건 (Acceptance Criteria)
- [ ] {조건 1 — 구체적이고 테스트 가능한 것}
- [ ] {조건 2}
- [ ] {조건 3}

## 고려할 점
{엣지 케이스, 의존성, 성능/보안 고려사항, 불확실한 부분}

Step 6 — Preview and confirm

Show the draft and ask: "이슈를 GitHub에 생성할까요? (y/n/수정)"

On confirm:

gh issue create \
  --title "{title}" \
  --body "$(cat <<'EOF'
{body}
EOF
)"

Step 7 — Report

Return the issue URL.

Quality bar

A good issue passes this check:

• 개발자가 이슈만 보고 어떤 레이어를 건드려야 할지 알 수 있는가?
• QA가 수용 조건만 보고 테스트 시나리오를 작성할 수 있는가?
• PO가 읽었을 때 "이게 내가 원한 것"이라고 말할 수 있는가?