メニュー
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.