Github Task Ticket Generator

---
name: github-task-ticket-generator
description: 사용자의 작업 설명을 바탕으로 GitHub 작업 티켓을 자동으로 생성합니다. 프론트엔드[FE], 백엔드[BE], 인프라[INFRA] prefix에 따라 적절한 레포지토리에 티켓을 생성하고, 작업 항목, 완료 기준, 우선순위, 예상 소요 시간을 포함합니다. 기능 티켓이 아닌 개별 작업 단위의 티켓 생성 시 사용합니다.
---

# GitHub Task Ticket Generator

이 스킬은 사용자가 설명한 **작업**을 바탕으로 구조화된 GitHub 작업 티켓을 자동으로 생성합니다.

## 목적

개별 작업 단위의 티켓을 체계적으로 작성하여 작업 범위, 완료 기준, 소요 시간을 명확히 하고 팀의 작업 추적을 돕습니다.

## 사용 시점

사용자가 **개별 작업**에 대한 티켓 생성을 요청할 때 사용합니다:

- "작업 티켓 만들어줘"
- "[FE] 프로젝트 초기 세팅 티켓 만들어줘"
- "백엔드 API 구현 티켓 생성해줘"

**기능 티켓과의 차이:**

- 기능 티켓: 프론트/백엔드/공통 섹션으로 나뉜 큰 기능 단위
- 작업 티켓: 특정 영역(FE/BE/INFRA)의 개별 작업 단위

## 티켓 형식

### 제목 형식

```
[PREFIX] 작업 제목
```

**PREFIX 종류:**

- `[FE]` - 프론트엔드 작업
- `[BE]` - 백엔드 작업
- `[INFRA]` - 인프라 작업

### 본문 구조

```markdown
## 설명

[작업에 대한 상세 설명 - 왜 필요한지, 무엇을 하는지]

## 작업 항목

- [ ] **[작업 항목 1]**
  - 세부 내용 1
  - 세부 내용 2
- [ ] **[작업 항목 2]**
  - 세부 내용 1

## 완료 기준 (Definition of Done)

- [완료 조건 1]
- [완료 조건 2]
- [완료 조건 3]

## 우선순위

- [High / Medium / Low]

## 예상 소요 시간

- [N일 또는 N시간] (작업 내용 포함)
```

## 섹션 작성 가이드

### 설명 (Description)

- 작업의 목적과 배경을 2-3문장으로 설명
- 왜 이 작업이 필요한지 맥락 제공
- 관련된 기술이나 도구 언급

### 작업 항목 (Tasks)

- 체크박스 형태로 작성
- 각 항목은 **굵게** 표시
- 하위 세부 내용은 들여쓰기로 나열
- 논리적 순서로 배치

### 완료 기준 (Definition of Done)

- 작업이 완료되었다고 판단할 수 있는 객관적 기준
- 측정 가능하고 검증 가능한 조건
- 일반적으로 3-5개 항목

### 우선순위 (Priority)

- **High**: 즉시 처리 필요, 다른 작업에 블로커
- **Medium**: 중요하지만 급하지 않음
- **Low**: 시간 여유 있을 때 처리

### 예상 소요 시간 (Estimation)

작업 복잡도에 따른 자동 추정 기준:

| 작업 유형        | 예상 시간 |
| ---------------- | --------- |
| 간단한 설정/수정 | 2~4시간   |
| 단일 기능 구현   | 1~2일     |
| 복합 기능/세팅   | 3~5일     |
| 대규모 리팩터링  | 1~2주     |
| 신규 시스템 구축 | 2주 이상  |

추정 시 고려 사항:

- 작업 항목 개수
- 기술적 복잡도
- 외부 연동 여부
- 테스트/문서화 포함 여부

## 레포지토리 매핑

PREFIX에 따라 자동으로 레포지토리가 결정됩니다:

| PREFIX    | 레포지토리                     |
| --------- | ------------------------------ |
| `[FE]`    | `Mockly-Company/mockly-mobile` |
| `[BE]`    | `Mockly-Company/mockly-server` |
| `[INFRA]` | `Mockly-Company/mockly-server` |

## 티켓 생성 프로세스

### 1. 작업 분석

사용자 설명에서 파악:

- 작업 영역 (FE/BE/INFRA)
- 작업 목적과 범위
- 필요한 세부 작업들
- 기술적 복잡도

### 2. PREFIX 결정

작업 내용에 따라 적절한 PREFIX 선택:

- UI, 컴포넌트, 상태관리, RN → `[FE]`
- API, DB, 서버 로직 → `[BE]`
- 배포, CI/CD, 서버 구성, 모니터링 → `[INFRA]`

### 3. 작업 항목 세분화

- 논리적 순서로 작업 분할
- 각 항목에 세부 내용 추가
- 검증/테스트 항목 포함

### 4. 완료 기준 정의

- 객관적으로 확인 가능한 조건
- 작업 항목과 연계

### 5. 소요 시간 추정

- 작업 복잡도 기반 자동 추정
- 괄호 안에 포함 내용 명시

### 6. 사용자 확인

티켓 내용을 보여주고 확인 받기

### 7. GitHub Issue 생성

```bash
gh issue create --repo [레포지토리] --title "[PREFIX] 제목" --body "$(cat <<'EOF'
[티켓 내용]
EOF
)" --project "Mockly" --타입 "작업" --영역 "[영역]" --Status "Backlog"
```

**영역 매핑:**

- `[FE]` → `--영역 "프론트"`
- `[BE]` → `--영역 "백엔드"`
- `[INFRA]` → `--영역 "인프라"`

## 예시

### 예시 1: 프론트엔드 작업

**입력:**

```
RN 프로젝트 초기 세팅 작업 티켓 만들어줘. 라이브러리 선정, 모노레포 구성, 컨벤션 설정, Claude Code 리뷰 워크플로우 세팅해야 해.
```

**출력:**

**제목:** `[FE] RN 프로젝트 초기 세팅`

**레포:** `Mockly-Company/mockly-mobile`

**내용:**

```markdown
## 설명

React Native 프로젝트를 효율적이고 일관되게 개발하기 위해 초기 환경을 세팅합니다.
본 티켓에서는 프로젝트 구조, 라이브러리 선정, 코딩 컨벤션, Monorepo 구성, 그리고 Claude Code 기반 AI 코드 리뷰 워크플로우까지 포함합니다.

## 작업 항목

- [ ] **라이브러리 선정**
  - UI 컴포넌트, 상태 관리, 데이터 페칭 등 필수 라이브러리 결정
  - 프로젝트에 맞는 안정적이고 유지보수 용이한 라이브러리 선택
- [ ] **Monorepo 환경 구성**
  - 프론트엔드 패키지 분리
  - 공통 컴포넌트 및 유틸 패키지 관리
  - TurboRepo 또는 Nx 등 Monorepo 관리 도구 설정
- [ ] **코딩 컨벤션 및 개발 규칙 설정**
  - ESLint, Prettier, TypeScript 규칙 적용
  - Git/PR 규칙, 브랜치 전략 등 정의
- [ ] **Claude Code 기반 AI 코드 리뷰 워크플로우**
  - PR 자동 리뷰, 코드 품질 체크
  - 워크플로우 문서화 및 팀 적용

## 완료 기준 (Definition of Done)

- Monorepo 구조 및 패키지 구성 완료
- 필수 라이브러리 설치 및 초기 설정 완료
- ESLint, Prettier, TypeScript 컨벤션 적용
- Claude Code AI 리뷰 워크플로우 적용 및 테스트 완료
- 팀원 대상 초기 세팅 문서화 완료

## 우선순위

- High

## 예상 소요 시간

- 3~5일 (환경 세팅, 검증, 문서화 포함)
```

**생성 명령:**

```bash
gh issue create --repo Mockly-Company/mockly-mobile --title "[FE] RN 프로젝트 초기 세팅" --body "..."
```

---

### 예시 2: 백엔드 작업

**입력:**

```
사용자 인증 API 구현 티켓 만들어줘. JWT 기반으로 로그인, 회원가입, 토큰 갱신 API 만들어야 해.
```

**출력:**

**제목:** `[BE] 사용자 인증 API 구현`

**레포:** `Mockly-Company/mockly-server`

**내용:**

```markdown
## 설명

JWT 기반의 사용자 인증 시스템을 구축합니다.
로그인, 회원가입, 토큰 갱신 API를 구현하여 클라이언트의 인증 요청을 처리합니다.

## 작업 항목

- [ ] **회원가입 API 구현**
  - 이메일/비밀번호 검증 로직
  - 비밀번호 해싱 (bcrypt)
  - 중복 이메일 체크
- [ ] **로그인 API 구현**
  - 자격 증명 검증
  - JWT 액세스/리프레시 토큰 발급
  - 로그인 이력 기록
- [ ] **토큰 갱신 API 구현**
  - 리프레시 토큰 검증
  - 새 액세스 토큰 발급
  - 토큰 만료 처리
- [ ] **인증 미들웨어 구현**
  - JWT 토큰 검증
  - 요청에 사용자 정보 주입

## 완료 기준 (Definition of Done)

- 모든 인증 API 엔드포인트 구현 완료
- JWT 토큰 발급 및 검증 정상 동작
- 단위 테스트 및 통합 테스트 작성 완료
- API 문서 (Swagger) 작성 완료

## 우선순위

- High

## 예상 소요 시간

- 2~3일 (구현, 테스트, 문서화 포함)
```

---

### 예시 3: 인프라 작업

**입력:**

```
GitHub Actions CI/CD 파이프라인 구축 티켓 만들어줘
```

**출력:**

**제목:** `[INFRA] GitHub Actions CI/CD 파이프라인 구축`

**레포:** `Mockly-Company/mockly-server`

**내용:**

```markdown
## 설명

GitHub Actions를 활용하여 자동화된 CI/CD 파이프라인을 구축합니다.
코드 푸시 시 자동 빌드, 테스트, 배포가 이루어지도록 워크플로우를 설정합니다.

## 작업 항목

- [ ] **CI 워크플로우 구성**
  - PR 생성 시 자동 빌드 및 테스트 실행
  - 린트 및 타입 체크 자동화
  - 테스트 커버리지 리포트 생성
- [ ] **CD 워크플로우 구성**
  - main 브랜치 머지 시 자동 배포
  - 환경별 (dev/staging/prod) 배포 분리
  - 배포 알림 설정 (Slack)
- [ ] **시크릿 및 환경 변수 설정**
  - GitHub Secrets 설정
  - 환경별 변수 관리
- [ ] **캐싱 및 최적화**
  - 의존성 캐싱 설정
  - 빌드 시간 최적화

## 완료 기준 (Definition of Done)

- PR 생성 시 자동 빌드/테스트 실행
- main 머지 시 자동 배포 동작
- 환경별 배포 분리 완료
- 워크플로우 문서화 완료

## 우선순위

- Medium

## 예상 소요 시간

- 2~3일 (설정, 테스트, 문서화 포함)
```

## Mockly 프로젝트 속성

작업 티켓 생성 시 다음 속성을 설정합니다:

| 속성   | 값                 | 비고                                     |
| ------ | ------------------ | ---------------------------------------- |
| 타입   | `작업`             | 고정                                     |
| 영역   | PREFIX에 따라 결정 | [FE]=프론트, [BE]=백엔드, [INFRA]=인프라 |
| Status | `Backlog`          | 고정                                     |

## 주의사항

1. **레포지토리 자동 선택**: PREFIX에 따라 올바른 레포 사용
   - `[FE]` → `mockly-mobile`
   - `[BE]`, `[INFRA]` → `mockly-server`

2. **프로젝트 속성 필수**:
   - `--project "Mockly"` 옵션 필수
   - `--타입 "작업"` 옵션 필수
   - `--영역` 옵션 필수 (PREFIX에 따라 프론트/백엔드/인프라)
   - `--Status "Backlog"` 옵션 필수

3. **작업 항목 굵게**: 각 체크박스 항목은 `**굵게**` 표시

4. **소요 시간 자동 추정**: 작업 복잡도에 따라 적절히 추정

5. **사용자 확인**: GitHub 생성 전 반드시 확인 받기

6. **완료 기준 명확히**: 객관적으로 검증 가능한 조건 제시