원클릭으로
issue-pr
GitHub 이슈와 연결된 형식화된 Pull Request를 생성하는 스킬입니다. 이슈 정보를 기반으로 PR 제목과 본문을 자동 생성하고, Closes
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
GitHub 이슈와 연결된 형식화된 Pull Request를 생성하는 스킬입니다. 이슈 정보를 기반으로 PR 제목과 본문을 자동 생성하고, Closes
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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" 등을 요청할 때
| name | issue-pr |
| description | GitHub 이슈와 연결된 형식화된 Pull Request를 생성하는 스킬입니다. 이슈 정보를 기반으로 PR 제목과 본문을 자동 생성하고, Closes |
GitHub 이슈와 연결된 형식화된 Pull Request를 생성한다.
이슈 정보를 기반으로 PR 제목과 본문을 자동 생성하고, Closes #{issue-number}로 이슈를 연결한다.
이슈 번호를 다음 우선순위로 결정한다:
/issue-pr #123 → #123issue/123-feature-name → #123../worktrees/issue/123-feature-name → #123# 이슈 정보 조회
gh issue view {issue-number} -R invigoworks/bitda-back --json title,body,labels
# 현재 브랜치 상태
git status
git log main..HEAD --oneline
git diff main...HEAD --stat
수집 항목:
형식: [{타입}] {간결한 설명} (#{issue-number})
| 이슈 라벨 | PR 타입 | 예시 |
|---|---|---|
| feature | 기능 | [기능] 사용자 로그인 API 구현 (#123) |
| bug | 수정 | [수정] 토큰 만료 처리 오류 해결 (#124) |
| refactor | 리팩토링 | [리팩토링] UserService 의존성 정리 (#125) |
| docs | 문서 | [문서] API 문서 업데이트 (#126) |
| test | 테스트 | [테스트] UserService 테스트 보강 (#127) |
제목 규칙:
PR 본문 템플릿:
## 개요
{이슈에서 요약한 핵심 변경 사항 1-2문장}
Closes #{issue-number}
## 변경 사항
### 주요 변경
- {주요 변경 1}
- {주요 변경 2}
- {주요 변경 3}
### 파일 변경 요약
- `{파일 경로}`: {변경 내용}
- `{파일 경로}`: {변경 내용}
## 테스트
- [ ] 단위 테스트 추가/수정
- [ ] 통합 테스트 추가/수정
- [ ] 수동 테스트 완료
### 테스트 커버리지
```bash
./gradlew test
{API 응답 예시, 로그 출력 등}
🤖 Generated with Claude Code
### Step 4: 브랜치 Push
로컬 브랜치가 리모트에 없으면 push한다:
```bash
# 현재 브랜치 확인
git branch --show-current
# 리모트 추적 확인
git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null || echo "no-upstream"
# Push (필요시)
git push -u origin {branch-name}
gh pr create \
--title "{PR 제목}" \
--body "$(cat <<'EOF'
{PR 본문}
EOF
)" \
--base main \
-R invigoworks/bitda-back
PR 생성 후 이슈에 연결 댓글을 추가한다:
gh issue comment {issue-number} --body "## 🔗 PR 생성됨
Pull Request: #{pr-number}
브랜치: \`{branch-name}\`
다음 단계:
- \`/pr-review #{pr-number}\` 로 리뷰 진행" -R invigoworks/bitda-back
✅ PR이 생성되었습니다.
| 항목 | 값 |
|------|-----|
| PR 번호 | #{pr-number} |
| 제목 | {PR 제목} |
| 브랜치 | {branch} → main |
| 연결 이슈 | #{issue-number} |
| URL | {pr-url} |
다음 단계:
- `/pr-review #{pr-number}` 로 코드 리뷰 진행
⛔ 로컬
./gradlew절대 금지. 로컬에서 Gradle을 실행하면 데몬이 잔존하여 시스템이 느려진다. 모든 Gradle 검증은 AI_server 원격에서만 수행한다.issue-full-cycle파이프라인에서는 직전issue-impl-remote단계가 이미 원격 전체 빌드를 통과시켰으므로, 이 검증은 건너뛴다 (중복).
단독 실행(/issue-pr만 호출) 시에만 원격 검증을 수행한다:
ISSUE={issue-number}
WORKTREE_PATH=$(git rev-parse --show-toplevel)
# 동기화 (tar over ssh — 한글 파일명 보존)
ssh AI_server "rm -rf ~/bitda-work-${ISSUE} && mkdir ~/bitda-work-${ISSUE}"
cd ${WORKTREE_PATH}
tar --exclude='.gradle' --exclude='build' --exclude='.idea' --exclude='.git' -cf - . \
| ssh AI_server "cd ~/bitda-work-${ISSUE} && tar -xf -"
ssh AI_server "cd ~/bitda-work-${ISSUE} && git init -q && git add -A \
&& git -c user.email=t@t -c user.name=t commit -q -m wip"
# 전체 빌드 (원격, --no-daemon, LC_ALL 필수) — run_in_background=true 권장
ssh AI_server "export LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 \
&& cd ~/bitda-work-${ISSUE} \
&& ./gradlew build --no-daemon -Dfile.encoding=UTF-8 2>&1 | tail -300"
검증 실패 시:
--force 옵션으로 강제 생성 가능 안내# 이슈 조회
gh issue view {number} -R owner/repo --json title,body,labels
# 이슈에 댓글 추가
gh issue comment {number} --body "댓글" -R owner/repo
# PR 생성
gh pr create --title "제목" --body "본문" --base main -R owner/repo
# PR 조회
gh pr view {number} -R owner/repo
# 브랜치 Push
git push -u origin {branch-name}