菜单
GitHub 이슈를 일관된 양식으로 생성하는 스킬입니다. 사용자 요청을 분석하여 범위가 크면 여러 이슈로 분할을 제안하고, Parent-Sub Issue 관계를 설정합니다. 이 스킬은 사용자가 "이슈 생성", "이슈 등록", "/issue-create" 등을 요청할 때 사용됩니다.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | issue-create |
| description | GitHub 이슈를 일관된 양식으로 생성하는 스킬입니다. 사용자 요청을 분석하여 범위가 크면 여러 이슈로 분할을 제안하고, Parent-Sub Issue 관계를 설정합니다. 이 스킬은 사용자가 "이슈 생성", "이슈 등록", "/issue-create" 등을 요청할 때 사용됩니다. |
GitHub 이슈를 일관된 양식으로 생성한다. 범위가 큰 요청은 여러 이슈로 분할하여 Parent-Sub Issue 관계를 설정한다.
Repository: invigoworks/bitda-back
Labels:
- 유형: feature, bug, refactor, docs, test
- 우선순위: priority:high, priority:medium, priority:low
- 크기: size:small, size:medium, size:large
- 상태: in-progress, blocked, review-needed
- 계층: epic (Parent Issue에만)
- API 변경: api-change (API 인터페이스 변경 시 자동 부착)
사용자의 요청을 분석하여 다음을 파악한다:
요청 분석 후 다음 항목 중 불충분하거나 모호한 정보가 있으면 사용자에게 질문한다.
| 항목 | 충분한 경우 | 불충분한 경우 (질문 필요) |
|---|---|---|
| 기능 범위 | 구체적인 기능이 명시됨 | "개선해줘", "만들어줘" 등 추상적 표현 |
| 배경/목적 | 왜 필요한지 파악 가능 | 기능의 필요성이 불명확 |
| 요구사항 | 구체적 동작이 기술됨 | 세부 동작이 정의되지 않음 |
| 도메인 | 어떤 영역인지 명확 | 여러 도메인 후보가 있음 |
| 우선순위 | 긴급도가 명시되거나 추론 가능 | 우선순위 판단 불가 |
이슈 등록을 위해 다음 정보가 추가로 필요합니다:
1. **{불충분한 항목 1}**: {구체적 질문}
2. **{불충분한 항목 2}**: {구체적 질문}
또는 더 구체적인 요구사항을 설명해주세요.
기능 범위가 모호한 경우:
"로그인 기능을 개선해줘"라고 요청하셨는데,
구체적으로 어떤 부분을 개선하고 싶으신가요?
1. 로그인 속도 개선?
2. 새로운 로그인 방식 추가 (OAuth, 2FA 등)?
3. 로그인 UI 변경?
4. 기타 (직접 설명)
요구사항이 불충분한 경우:
"엑셀 내보내기 기능" 이슈를 등록하려면 다음 정보가 필요합니다:
1. 어떤 데이터를 내보내나요? (사용자 목록, 주문 내역 등)
2. 어떤 컬럼이 포함되어야 하나요?
3. 필터링/정렬 옵션이 필요한가요?
도메인이 불명확한 경우:
이 기능이 다음 중 어느 도메인에 속하나요?
1. user (사용자 관리)
2. subscription (구독 관리)
3. warehouse (창고 관리)
4. 새 도메인 생성
/issue-create --quick 옵션으로 빠른 생성 요청정보가 충분하면 Step 2로 진행한다.
다음 기준으로 이슈 분할 여부를 결정한다:
분할이 필요한 경우:
분할 제안 형식:
이 요청은 다음과 같이 분할하는 것을 제안합니다:
1. [Parent Issue] {전체 기능명} (epic)
├── [Sub-Issue 1] {하위 기능 1} (size:small)
├── [Sub-Issue 2] {하위 기능 2} (size:medium)
└── [Sub-Issue 3] {하위 기능 3} (size:small)
이대로 진행할까요? 또는 다른 분할 방식을 제안해주세요.
중요: 사용자 승인 후에만 이슈를 생성한다.
## 개요
{기능에 대한 간단한 설명}
## 배경
{왜 이 기능이 필요한지, 어떤 문제를 해결하는지}
## 상세 요구사항
- [ ] {요구사항 1}
- [ ] {요구사항 2}
- [ ] {요구사항 3}
## 기술적 고려사항
- {아키텍처 관련 참고사항}
- {의존성 또는 연관 컴포넌트}
## 완료 기준
- [ ] 기능 구현 완료
- [ ] 테스트 작성 완료
- [ ] 코드 리뷰 완료
## 참고자료
- {관련 문서 링크}
- {참고할 기존 구현}
| 조건 | 라벨 |
|---|---|
| 새 기능 | feature |
| 버그 수정 | bug |
| 리팩토링 | refactor |
| 문서 작업 | docs |
| 테스트 추가 | test |
| Parent Issue | epic |
| 1-2시간 작업 | size:small |
| 3-8시간 작업 | size:medium |
| 1-3일 작업 | size:large |
| API 변경 | api-change |
다음 조건 중 하나라도 해당되면 api-change 라벨을 자동으로 추가한다:
키워드 감지 (이슈 제목/본문):
/api/v1/... 패턴작업 유형 감지:
참고: api-change 라벨이 붙은 이슈의 PR 병합 시, /pr-merge 스킬이 Notion API 문서 동기화를 제안한다.
분할된 이슈의 경우:
Parent Issue 먼저 생성:
gh issue create --title "[Epic] {전체 기능명}" \
--body "{본문}" \
--label "epic,feature,size:large" \
-R invigoworks/bitda-back
Sub-Issue 생성 및 연결:
# Sub-Issue 생성
gh issue create --title "{하위 기능명}" \
--body "{본문}" \
--label "feature,size:small" \
-R invigoworks/bitda-back
Parent Issue 본문에 Sub-Issue 목록 추가:
# Parent Issue 본문 업데이트
gh issue edit {parent-number} --body "{updated-body-with-sub-issues}" \
-R invigoworks/bitda-back
본문에 추가할 형식:
## Sub-Issues
- [ ] #{sub-issue-1} {하위 기능 1}
- [ ] #{sub-issue-2} {하위 기능 2}
- [ ] #{sub-issue-3} {하위 기능 3}
이슈 생성 완료 후 사용자에게 보고한다:
✅ 이슈가 생성되었습니다.
| 유형 | 번호 | 제목 | 라벨 |
|------|------|------|------|
| Parent | #100 | [Epic] 사용자 인증 기능 | epic, feature |
| Sub | #101 | 로그인 API 구현 | feature, size:small |
| Sub | #102 | 회원가입 API 구현 | feature, size:medium |
다음 단계:
- `/issue-plan #101` 로 계획서 작성
| 유형 | 형식 | 예시 |
|---|---|---|
| Feature | [Feature] {기능명} | [Feature] 사용자 로그인 기능 구현 |
| Bug | [Bug] {버그 설명} | [Bug] 로그인 시 토큰 만료 처리 오류 |
| Refactor | [Refactor] {리팩토링 대상} | [Refactor] UserService 의존성 정리 |
| Test | [Test] {테스트 대상} | [Test] UserService 단위 테스트 추가 |
| Docs | [Docs] {문서 대상} | [Docs] API 문서 업데이트 |
| Epic | [Epic] {전체 기능명} | [Epic] 사용자 인증 시스템 |
# 이슈 생성
gh issue create --title "제목" --body "본문" --label "label1,label2" -R owner/repo
# 이슈 조회
gh issue view {number} -R owner/repo
# 이슈 본문 수정
gh issue edit {number} --body "새 본문" -R owner/repo
# 이슈에 라벨 추가
gh issue edit {number} --add-label "label" -R owner/repo
# 이슈 목록
gh issue list -R owner/repo --label "label"
jh_kim dev 계정(dev Keycloak)으로 E2E API 테스트를 수행하는 스킬입니다. 로컬 main 빌드 API + dev DB + dev Keycloak PKCE 토큰 조합으로, dev API 서버에 아직 배포되지 않은 머지 코드를 실데이터 환경에서 검증할 때 사용합니다. "/e2e-test-dev", "dev 계정으로 E2E", "jh_kim으로 API 테스트", "dev DB로 E2E 테스트" 등을 요청할 때 사용됩니다. (로컬 Docker Keycloak 기반 테스트는 e2e-test 스킬 사용)
plan-master(기획용 FE 코드 + docs/specs 기획서)와 bitda-back(구현된 BE 코드) 사이의 갭을 분석하여 누락된 기능·API·정책을 GitHub 이슈로 자동 생성하는 스킬입니다. 기획서→이슈 전달 과정에서 발생하는 누락을 방지하기 위해 FE 코드를 1차 소스로 사용합니다. "/gap-analyze", "/gap-analyze BOM", "/gap-analyze production" 등을 요청할 때 사용됩니다.
plan-master FE 코드만을 유일한 1차 소스로(기획서 .md 배제) 멀티팀 에이전트가 BE가 보장해야 할 비즈니스 로직과 FE 작업에 필요한 API 항목을 도출하고, 총괄 에이전트가 bitda-back BE 구현과 실측 대조하여 누락 갭을 발굴, 직렬 verifier로 확정한 뒤 GitHub 이슈로 생성하는 스킬입니다. gap-analyze의 변종으로, 기획서가 구현완료를 선언해 갭을 가리는 오염을 제거하기 위해 기획서를 의도적으로 보지 않습니다. /gap-fe-code 생산현황, 기획서 빼고 FE 코드로 갭 분석, FE 코드만 보고 누락 API 이슈 만들어 등을 요청할 때 사용됩니다.
실제 API 서버(8080 포트)를 실행하고 Keycloak OAuth 인증을 통해 E2E API 테스트를 수행하는 스킬입니다. 테스트 결과와 요청/응답을 docs/e2e-test/{test}/ 디렉토리에 markdown 형식으로 기록합니다. 이 스킬은 다음 상황에서 사용됩니다: - 특정 API의 실제 동작을 테스트하고 싶을 때 - API 변경 후 실제 환경에서 검증이 필요할 때 - 사용자가 "E2E 테스트", "API 테스트", "/e2e-test" 등을 요청할 때
Creates phase-based feature plans with quality gates and incremental delivery structure. Use when planning features, organizing work, breaking down tasks, creating roadmaps, or structuring development strategy. Keywords: plan, planning, phases, breakdown, strategy, roadmap, organize, structure, outline.
Swagger 스냅샷(api-docs.json)과 코드베이스를 기반으로 Notion API 맵핑 DB에 API 문서를 등록하고 상세 페이지를 작성하는 스킬입니다. (notion-api.py REST wrapper 사용 버전) 이 스킬은 다음 상황에서 사용됩니다: - 특정 API를 Notion에 문서화할 때 (MCP 비활성화 환경) - mcp__notion__* 도구 deprecated/불안정한 경우 - 사용자가 "api 노션 등록 (api 모드)", "/api-to-notion-api" 등을 요청할 때