القائمة
Create GitHub Pull Request with project's PR template. Use when user asks to create PR, says "create PR", "/pr-create", or after completing implementation when asked to open a pull request.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| id | git-pr-workflow.skill.pr-create |
| kind | skill |
| name | pr-create |
| description | Create GitHub Pull Request with project's PR template. Use when user asks to create PR, says "create PR", "/pr-create", or after completing implementation when asked to open a pull request. |
| tags | ["git-pr-workflow","github","pull-request"] |
Create PRs following project's template with clear explanations.
git diff and git loggh pr createCRITICAL: Always check the current branch first. Never create a PR from the default branch.
git branch --show-current
Format: feature/<microservice-or-component>/<descriptive-name>
feature/contract/add-coupon-transfer)feature/update-ci-config)# 1. Stash uncommitted changes with a descriptive name
git stash save "pr-create: uncommitted changes before branch switch"
# 2. Verify the stash was saved
git stash list
# Confirm the stash entry appears at the top (stash@{0})
# 3. Update the default branch to latest remote
DEFAULT_BRANCH=$(git remote show origin | grep 'HEAD branch' | cut -d ':' -f 2 | xargs)
git fetch origin "$DEFAULT_BRANCH"
git merge origin/"$DEFAULT_BRANCH"
# 4. Create and switch to feature branch
git checkout -b feature/<appropriate-branch-name>
# 5. Restore stashed changes by specifying the exact stash entry
git stash apply stash@{0}
# 6. Verify changes are restored, then drop the stash
git status
git stash drop stash@{0}
Check if a PR already exists for the current branch:
gh pr view --json number,title,url,state 2>/dev/null
Run git diff --stat and git status to assess uncommitted changes.
Suggest splitting when:
If changes are small and focused, proceed as a single PR.
If splitting is needed, propose logical boundaries to the user and get explicit confirmation before proceeding with any splitting or further actions:
This change is large (~800 lines). Consider splitting into separate PRs:
1. PR1: Database schema changes
2. PR2: API endpoint implementation
3. PR3: Frontend integration
Which files should be included in this PR?
After agreement, only stage and commit the files relevant to this PR.
Delegate to the git-commit skill. Do NOT run git commit yourself:
Skill tool: skill="git-commit"
If all changes are already committed, skip this step.
IMPORTANT: When using Glob tool, always specify the repository root as the path. If working in a subdirectory, searching from current directory will miss templates.
# First, find the repository root
git rev-parse --show-toplevel
# Then use Glob tool with repository root as path parameter
Search patterns:
.github/pull_request_template.md (lowercase, most common).github/PULL_REQUEST_TEMPLATE.md (uppercase).github/PULL_REQUEST_TEMPLATE/*.md (directory)If no template found, use the default format below.
Run gh pr list --state merged --limit 10 to see recent PR titles.
Observe and match:
feat:, [Add], etc.)feat(api): vs feat/api:)Write both the PR title and the PR body in the repository's standard language (the one used in recent PRs and the template). Do not default to English when the repository's PRs are written in another language.
If a project PR template was found in Step 5, always follow that template's structure. The structure and example below are only used when no project template exists.
concat", which line was edited. State what changed and why, in the reader's terms, not how it was coded. The reviewer reads the diff for the how.Follow the project's template. For each section, write only what a reviewer cannot get from reading the diff:
This example is written in Japanese to illustrate the rule above: write the PR body in the repository's standard language. Match your own repository's language instead of copying Japanese.
## 対応したこと
検証環境のエンドポイントのIP許可リストに、社内IPなどのCIDRの範囲を追加
## この対応を行なった背景・経緯・理由
社内から検証環境の動作確認ができるようにするため
## スコープ外
- 本番への影響なし（対象設定は検証環境のみ有効）
Note what is absent: no mention of how it was coded (which variable was reused, concat, the edited line). The diff already shows that. Sections with nothing real to say are omitted entirely.
Always create PRs as draft by default.
# Push to remote
git push -u origin <branch-name>
# Create draft PR
gh pr create --draft --title "[title matching project style]" --body "$(cat <<'EOF'
[PR description following template]
EOF
)"
## Overview
[1-2 sentence summary understandable by someone with no domain knowledge]
## Background
[Current problem or business motivation — why this change is needed]
## Changes
[Prose explanation of changes grouped by concern, with design rationale]
## Testing
[How this was tested]
Author or update tool-neutral knowledge packs in ai-knowledge-base.
A workflow for authoring Go tests. Starting from the table-driven test scaffold generated by gotests, it runs the cycle of test design -> adding test cases -> running -> fixing defects. Use when: (1) invoked via /go-test-authoring, (2) asked to "write tests" or "add tests" for Go, (3) asked to implement tests for a Go function or method.
Git commit with Conventional Commits format. Use when user asks to commit changes, says "commit", "/commit", or after completing code changes when explicitly asked to commit.
Address PR review feedback. Collect both unresolved inline comments and review-body comments on a GitHub PR, build a fix plan and turn it into tasks, then work through them one by one (assess -> fix -> commit -> push -> reply). Use when invoked as /pr-review-fix, when asked to "address the review comments" or "respond to PR feedback", or for follow-up work after a PR review.
Internal Structure-Behavior Design skill for conceptual modeling and structure design. Use only as part of the Structure-Behavior Design workflow.
Internal Structure-Behavior Design skill for interface, signature, and contract design. Use only as part of the Structure-Behavior Design workflow.