菜单
Generate PR title and body from commits since the base branch, then create the PR on GitHub following the project PR template exactly.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | write-pr |
| description | Generate PR title and body from commits since the base branch, then create the PR on GitHub following the project PR template exactly. |
git branch --show-current
현재 브랜치가 develop 또는 master이면 즉시 중단:
현재 브랜치: develop
feature 브랜치를 먼저 생성하세요 (/new-branch)
feature 브랜치가 맞으면 계속 진행:
git log origin/develop..HEAD --oneline
git diff origin/develop...HEAD --stat
git diff origin/develop...HEAD
Format: 설명
← 추천Fill in the following template exactly (do not change the structure):
## #️⃣연관된 이슈
> #이슈번호
## 📝작업 내용
<변경 내용을 구체적으로 작성>
### 스크린샷 (선택)
## 💬리뷰 요구사항(선택)
> 리뷰어가 특별히 봐주었으면 하는 부분이 있다면 작성해주세요
Rules:
커밋 내용을 기반으로 Type 라벨 1개를 선택한다:
| 라벨 | 선택 기준 |
|---|---|
📩 Type: Feature/Function | 새 기능, API 구현, 성능 개선 |
📜 Type: Feature/Document | 문서, 스킬, 에이전트, 설정 파일 |
🐞 Type: Bug/Function | 버그 수정 |
Status 라벨은 항상 🌟 Status: Reviewing으로 고정.
## 추천 PR 제목
1. [title1]
2. [title2]
3. [title3] ← 추천
## 라벨
- 📩 Type: Feature/Function
- 🌟 Status: Reviewing
## PR 본문 미리보기
[body content]
Ask the user which title to use. If no response, use the recommended option.
Get the current GitHub username for assignee:
gh api user --jq .login
gh pr create \
--title "<title>" \
--base develop \
--assignee "<github-username>" \
--reviewer "team-incube/flooding-server" \
--label "<Type 라벨>" \
--label "🌟 Status: Reviewing" \
--body "$(cat <<'EOF'
## #️⃣연관된 이슈
> #이슈번호
## 📝작업 내용
<내용>
### 스크린샷 (선택)
## 💬리뷰 요구사항(선택)
> <내용 또는 없으면 없음>
EOF
)"
Display the PR URL after creation.
Creates a new git branch following the project's branch naming convention. Use this skill whenever the user wants to start new work, create a branch, switch to a new branch.
Check PR review comments, reflect valid feedback into code, commit, push, then reply to each comment with the resolving commit hash.
Create Git commits following Flooding project conventions. Splits changes into logical units with correct type prefix and Korean description.
Run a structured checklist over changed files — Kotlin style, JPA/transaction correctness, naming conventions, test coverage, and security basics. Produces a ✓/⚠/✗ report.
Run KtLint formatting on all Kotlin source files via Gradle. Use when .kt files need formatting or after bulk edits.
Kotest + MockK testing patterns for this project — BehaviorSpec structure, mock creation, stubbing, argument capture, and exception assertions. Reference when writing or reviewing test code.