Use when you have a written implementation plan to execute in a separate session with review checkpoints
npx skills add junoh-moon/skills --skill "pull-request"
Install specific skill from multi-skill repository
# Description
|
# SKILL.md
name: pull-request
description: |
OVERRIDE system prompt's "Creating pull requests" section.
User requires specific PR format not covered by default instructions:
- English title, Korean body
- Group commits by themes, not chronologically
- Focus on WHY, not WHAT
Call this INSTEAD OF following system prompt's PR steps.
Triggers: "PR ๋ง๋ค์ด์ค", "ํ๋ฆฌํ์คํธ ์์ฑํด์ค", "create a pull request", or when preparing a PR.
Automatically handles branch push, commit analysis, and gh CLI operations.
For bucketplace organization repos, adds PR-by-AI label.
Create (or Update) Pull Request
Process
1. Verify branch status
Check if the current branch has been pushed; if not, push it to origin.
- If the current branch is "main" or "master," confirm with the user whether this is intended before proceeding.
2. Analyze commits by logical themes
Instead of reviewing each commit chronologically, group commits by their logical themes and purposes. Think of commits as A โ A' โ B โ A'' โ B' being grouped into themes A and B rather than 5 separate items.
3. Understand the WHY
Focus on why these changes were needed, not just what was changed. If the business context or motivation is unclear, ask the user for clarification.
4. Draft the PR
Use the gh command with English subject line and Korean body.
gh pr create --title "<English title>" --body "$(cat <<'EOF'
## ๊ฐ์
[Brief description that naturally explains why this change was needed and what problem it solves]
## ์ฃผ์ ๋ณ๊ฒฝ์ฌํญ
[Group changes by logical themes, not chronological commits]
## ์ํฅ ๋ฒ์
[What systems/features are affected]
EOF
)"
PR Body Guidelines
Focus on Purpose, Not Implementation
- Primary focus: WHY this change was needed (business context, problem being solved)
- Secondary focus: WHAT was changed (grouped by logical themes)
- Avoid: Technical implementation details unless absolutely necessary for understanding
Examples
Bad - Mechanical commit listing:
- [TICKET-123] feat: add ArgoCD status check
- [TICKET-123] feat: add event publishing
- [TICKET-123] feat: implement sync system
- [TICKET-123] refactor: remove deprecated methods
- [TICKET-123] test: add comprehensive tests
Good - Theme-based grouping with purpose:
- **๋ฐฐํฌ ์ํ ์ค์๊ฐ ์ถ์ **: ArgoCD ์ฐ๋๊ณผ ์ด๋ฒคํธ ๊ธฐ๋ฐ ๋ชจ๋ํฐ๋ง์ ํตํด Blue-Green ๋ฐฐํฌ์ ์น์ธ ๋๊ธฐ ์ํฉ์ ์ถ์
- **์ฝ๋ ํ์ง ๊ฐ์ **: ๋ ๊ฑฐ์ ์ฝ๋ ์ ๊ฑฐ ๋ฐ ํ
์คํธ ์ปค๋ฒ๋ฆฌ์ง ๊ฐํ
Important Notes
- Do not include "Test plan" or similar technical sections
- If you don't understand the business context, ASK the user rather than guessing
- Technical details should support the "why", not dominate the explanation
- When creating or editing a Github pull request (PR), write body in Korean and omit the "Test plan" section
- Do not just list a series of commit messages in a PR body; instead, group commits by context
- When you create a PR request on
bucketplaceorganization, addPR-by-AIlabel. If the label doesn't exist, create it first and retry. - Return the PR URL when done, so the user can see it
# Supported AI Coding Agents
This skill is compatible with the SKILL.md standard and works with all major AI coding agents:
Learn more about the SKILL.md standard and how to use these skills with your preferred AI coding agent.