一键导入
issue
작업 내용을 받아 팀 GitHub Issue 컨벤션에 맞춘 제목·본문·라벨을 텍스트로 생성합니다. Use when the user asks for an issue draft, like "이슈 작성해줘", "/issue [FEATURE] xxx", "버그 이슈 만들어줘".
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
작업 내용을 받아 팀 GitHub Issue 컨벤션에 맞춘 제목·본문·라벨을 텍스트로 생성합니다. Use when the user asks for an issue draft, like "이슈 작성해줘", "/issue [FEATURE] xxx", "버그 이슈 만들어줘".
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Controller에 대응하는 Swagger {Domain}ControllerDoc 인터페이스를 신규 생성합니다. Controller가 implements해서 사용. Use when the user asks like "/api-doc BookingController", "회원 API Swagger 문서 만들어줘".
이슈 설명을 받아서 팀의 브랜치 네이밍 컨벤션에 맞춰 브랜치명을 자동으로 생성합니다.
현재 브랜치의 작업 내용을 읽고 브랜치명에서 이슈번호를 파악하여 자동으로 커밋 메시지를 작성합니다.
현재 브랜치의 변경사항을 분석하고 관련 이슈를 기반으로 PR을 자동 생성합니다.
테스트 대상 코드를 분석하고 프로젝트 테스트 컨벤션에 맞는 테스트 코드를 작성하거나 수정한다. Use when the user asks for tests for a domain entity, service, facade, validator, or calculator, including requests like `/test BookingService.cancel`, `/test Booking 엔티티`, `SeatConflictValidator 테스트 작성`, or similar natural-language asks.
도메인 ErrorCode를 사용하는 {Domain}Validator 클래스를 application/validator/ 아래에 생성하거나 메서드를 추가합니다. Use when the user asks like "/validator BookingValidator", "Payment 도메인에 validator 만들어줘", "PaymentValidator에 검증 메서드 추가".
| name | issue |
| description | 작업 내용을 받아 팀 GitHub Issue 컨벤션에 맞춘 제목·본문·라벨을 텍스트로 생성합니다. Use when the user asks for an issue draft, like "이슈 작성해줘", "/issue [FEATURE] xxx", "버그 이슈 만들어줘". |
작업 내용을 받아 팀 컨벤션에 맞춘 Issue 텍스트를 생성한다. gh CLI는 사용하지 않는다 — 출력 텍스트를 사용자가 직접 GitHub UI에 붙여넣는다.
[CATEGORY] 설명 (반드시 대괄호 + 공백)📄, 📈, 🖥️, 👍🏻)| CATEGORY | 라벨 | 용도 |
|---|---|---|
| FEATURE | feature | 새 기능 |
| BUG | bug | 버그 |
| REFACTOR | refactor | 리팩터링 |
| CHORE | chore | 빌드/설정/의존성 |
| TEST | test | 테스트 작성/수정 |
| DOCS | docs | 문서 |
### 📄 작업 설명
{1~3 문장으로 무엇을 왜 하는지 명확히}
### 📈 진행 체크리스트
- [ ] {작업 항목 1}
- [ ] {작업 항목 2}
- [ ] {작업 항목 3}
### 👍🏻 추가 정보
{관련 이슈/PR 링크 또는 _No response_}
### 🖥️ 발생 환경
- {예: Spring Boot 3.5.0}
- {예: dev 프로필, 로컬 환경}
### 📄 버그 설명
{현상 + 기대 동작과의 차이}
### 📈 재현 절차
1. {단계 1}
2. {단계 2}
3. {기대 결과 vs 실제 결과}
### 👍🏻 추가 정보
{관련 이슈/PR 링크 또는 _No response_}
[CATEGORY] {짧은 한국어 설명} 형식으로 생성✅ Issue 초안
📌 제목:
[FEATURE] 통합 열차 조회 API 캐시 적용
🏷️ 라벨: feature
📝 본문:
---
### 📄 작업 설명
통합 열차 조회 API에 Redis 캐싱을 적용해 DB 부하를 줄이고 응답 속도를 개선한다.
### 📈 진행 체크리스트
- [ ] 캐시 키 설계 (열차번호 + 운행일)
- [ ] TrainSearchService에 캐시 어노테이션 적용
- [ ] 캐시 무효화 정책 결정 (TTL/이벤트)
- [ ] 캐시 hit/miss 메트릭 추가
### 👍🏻 추가 정보
_No response_
---
💡 위 내용을 GitHub Issue 작성 페이지에 복사·붙여넣기 하세요.
입력:
/issue FEATURE 열차 조회 캐시 적용. 작업: 캐시 키 설계, 어노테이션 적용, 무효화 정책
→ 위 출력 형식대로 생성. 체크리스트는 입력 그대로.
입력:
/issue BUG PendingBooking이 출발 시간 이후까지 유효함. 환경: dev. 재현: 출발 2분 전 예약 → 출발 후 8분까지 노출
출력 (본문만):
### 🖥️ 발생 환경
- Spring Boot 3.5.0
- dev 프로필, 로컬 환경
### 📄 버그 설명
PendingBooking TTL이 10분 고정이라 출발 시간이 지나도 사용자 화면에 노출된다.
### 📈 재현 절차
1. 출발 2분 전 예약 생성
2. 출발 시간 도달
3. 기대: PendingBooking이 사라짐 / 실제: 출발 후 8분까지 "내 예약"에 노출
### 👍🏻 추가 정보
_No response_
⚠️ CATEGORY를 명시해주세요.
사용 가능: FEATURE, BUG, REFACTOR, CHORE, TEST, DOCS
예시: /issue FEATURE 사용자 로그인
체크리스트 항목이나 버그 재현 단계가 추출 불가능하면 placeholder를 채워 출력하고 사용자에게 보완 안내:
💡 placeholder({1}, {2})는 GitHub UI에 붙여넣기 전에 채워주세요.