메뉴
Create GitHub pull requests using gh CLI with proper formatting for multi-line descriptions. Use when you want to create a pr, submit a pr, pull request, create a pull request, submit a pull request, open a pr, or new pr.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Orchestrate Birdhouse child agents to investigate PR review feedback in parallel, classify it as strengthened, weakened, or invalidated, then address approved items serially with fixes or threaded replies.
Create isolated working directories using git worktrees without affecting the main workspace. Use when you want to use worktree, git worktree, worktree workflow, isolated development, work in worktree, create worktree, or worktree best practices.
Reply to GitHub PR review comments as threaded responses using the GitHub API replies endpoint.
Generate release notes from git branch commit history and analyze changes. Use when you want to generate release notes, prepare release notes, prep for a PR, find what changed in this branch, or get branch change summary.
Core software development principles: code for readability and changeability, apply DRY wisely, test for confidence, and crash loudly on unexpected conditions.
Frame an agent as a junior engineer who looks things up, cites sources, and doesn't rely on potentially stale training knowledge. Use instead of "you are an expert in X" when you want fresh, grounded research over confident guessing.
| name | github-pull-request-creation |
| description | Create GitHub pull requests using gh CLI with proper formatting for multi-line descriptions. Use when you want to create a pr, submit a pr, pull request, create a pull request, submit a pull request, open a pr, or new pr. |
| trigger_phrases | ["create a PR","create pull request","submit a PR","open a PR"] |
| tags | ["github"] |
gh CLIUse heredoc syntax for multi-line PR descriptions.
If you already generated branch notes or release notes, use that material as the starting PR body instead of rewriting the description from scratch.
Simple PR that opens an interactive prompt for the body:
gh pr create --title "Add feature X"
With inline body for short descriptions:
gh pr create --title "Fix login redirect" --body "Fixes issue with OAuth callback URL"
gh pr create --title "Add rocket boosters to the login button" --body "$(cat <<'EOF'
## ✨ Features
- Added rocket boosters to the login button so authentication feels dramatically faster
## Testing
- Tested on production (yolo)
- My mouse caught fire but in a good way
EOF
)"
How it works:
cat <<'EOF' starts a heredoc and keeps the content literal.$(...) captures the heredoc output as a string.--body "..." receives the complete multi-line string.'EOF' prevent variable expansion.Draft PR:
gh pr create --draft --title "WIP: Experimental feature" --body "..."
Different base branch:
gh pr create --base develop --title "Feature X" --body "..."
Add reviewers:
gh pr create --title "Fix bug" --body "..." --reviewer alice,bob
From a file:
gh pr create --title "Feature: User preferences" --body "$(cat pr-description.md)"
This works especially well when another step already generated a branch summary or release notes document for the PR.
If release notes already exist, preserve their headings and bullets with only minimal reviewer-focused trimming.
# This breaks because the shell tries to interpret special characters and newlines
gh pr create --title "Add rocket boosters!" --body "Added cool stuff!\nReally fast now!"
Use heredoc instead.
Guides agents to use heredoc syntax when creating GitHub PRs with multi-line descriptions to avoid shell interpretation issues. Generated release notes should usually determine the PR body structure.