create-pr
GitHubでPull Request(PR)を作成します。PRのdescriptionには指定されたテンプレートを使用し、必要な情報を記載します。PR作成後、PRのURLを報告します。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
GitHubでPull Request(PR)を作成します。PRのdescriptionには指定されたテンプレートを使用し、必要な情報を記載します。PR作成後、PRのURLを報告します。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | create-pr |
| description | GitHubでPull Request(PR)を作成します。PRのdescriptionには指定されたテンプレートを使用し、必要な情報を記載します。PR作成後、PRのURLを報告します。 |
| argument-hint | [issue-number] |
| model | sonnet |
| effort | medium |
| context | fork |
GitHubでPull Request(PR)を作成するスキルです。呼び出された際には、Instructionsに従ってPRの作成を行ってください。
.github/PULL_REQUEST_TEMPLATE.mdを参照し、それに従うことCloses #$0と記載することgh api user --jq '.login'で取得したユーザーをAssigneesに追加することcc-triage-scopeラベルを付与することベースブランチは以下の優先順で決定する。必ず 1 → 2 → 3 の順に試すこと。
$0 が parent(Epic Issue)を持つ場合、cc-epic-<parent番号> をベースにする--track で分岐元を記録している)サブIssue(parentを持つIssue)の作業ブランチは cc-epic-<parent番号> から派生しているため、PRも同ブランチへ向ける。後述のmerge-base推定は、epicブランチ作成直後(デフォルトブランチと同一コミットを指す状態)に複数の候補ブランチが同点になり、アルファベット順のタイブレークで誤ったepicブランチを選ぶことがある。そのためparentからの確定的導出を必ず先に試す。
git fetch origin --prune
BASE_BRANCH=""
# Issue 番号が指定されている場合のみ実行
if [ -n "$0" ]; then
# gh issue view が失敗した場合はエラーを報告して中断
PARENT=$(gh issue view "$0" --json parent --jq '.parent.number // empty') || {
echo "Error: Failed to retrieve Issue #$0" >&2
exit 1
}
if [ -n "${PARENT}" ] && git rev-parse --verify --quiet "refs/remotes/origin/cc-epic-${PARENT}" >/dev/null; then
BASE_BRANCH="cc-epic-${PARENT}"
fi
fi
引数のIssue番号が渡されていない場合($0が空)は本ステップをスキップし、BASE_BRANCH を空のままステップ2へ進む。Issue番号が指定されているが gh issue view の実行に失敗した場合(ネットワークエラー・権限不足等)はエラーメッセージを出力して処理を中断する。
ワーカーは worktree 作成時に git worktree add --track で分岐元ブランチを upstream として記録している(例: デフォルトブランチ由来なら origin/main、epic 由来なら origin/cc-epic-<N>)。手動で git checkout -b <branch> origin/<base> した場合も既定で同じ upstream が付く。これは「どのブランチから派生したか」の確定情報なので、merge-base 推定より必ず先に使う。
if [ -z "${BASE_BRANCH}" ]; then
CURRENT=$(git rev-parse --abbrev-ref HEAD)
UPSTREAM=$(git rev-parse --abbrev-ref --symbolic-full-name '@{upstream}' 2>/dev/null || true)
UPSTREAM=${UPSTREAM#origin/}
# upstream が未設定・自分自身(push -u した作業ブランチ)・origin に実在しない場合は採用しない
if [ -n "${UPSTREAM}" ] && [ "${UPSTREAM}" != "${CURRENT}" ] \
&& git rev-parse --verify --quiet "refs/remotes/origin/${UPSTREAM}" >/dev/null; then
BASE_BRANCH="${UPSTREAM}"
fi
fi
「現在のブランチの分岐元ブランチ」は、リモートトラッキングブランチ(refs/remotes/origin/配下)のうち、現在のブランチ自身を除き、HEADから最も近い merge-base を持つものとして推定する。Epic ブランチや任意の中間ブランチから派生した作業ブランチでも、その派生元へPRを向けられるようにするための仕組み。
距離が同点の場合はデフォルトブランチを最優先すること。デフォルトブランチと同一コミットを指すブランチ(作成直後の epic ブランチや並行タスクのPRブランチ)が存在すると距離が同点になり、単純なアルファベット順タイブレークでは origin/cc-epic-* が origin/main より先に来て無関係な epic ブランチがベースに選ばれるため。
if [ -z "${BASE_BRANCH}" ]; then
DEFAULT_BRANCH=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')
CURRENT=$(git rev-parse --abbrev-ref HEAD)
BASE_BRANCH=$(
git for-each-ref --format='%(refname:short)' refs/remotes/origin/ |
grep '^origin/' | grep -v '^origin/HEAD$' |
while read b; do
[ "$b" = "origin/${CURRENT}" ] && continue
mb=$(git merge-base "$b" HEAD 2>/dev/null) || continue
[ -n "$mb" ] || continue
dist=$(git rev-list --count "${mb}..HEAD" 2>/dev/null) || continue
if [ "$b" = "origin/${DEFAULT_BRANCH}" ]; then pref=0; else pref=1; fi
echo "$dist $pref $b"
done | sort -k1,1n -k2,2n -k3,3 | head -1 | awk '{print $3}' | sed 's|^origin/||'
)
# 候補が見つからない場合(孤立ブランチ等)はデフォルトブランチに fallback する
if [ -z "${BASE_BRANCH}" ]; then
BASE_BRANCH="${DEFAULT_BRANCH}"
fi
fi
距離が同点の場合はデフォルトブランチ → refname のアルファベット順の優先度で採用する。期待しないブランチがベースに選ばれた場合は --base を明示的に指定して上書きする。
gh pr create \
--title "PRタイトル" \
--body "$(printf 'Closes #%s\n\nPRの本文' "$0")" \
--base "${BASE_BRANCH}" \
--assignee "$(gh api user --jq '.login')" \
--label "cc-triage-scope"
Re-analyze an existing GitHub Issue using its current title and body as input, refresh the implementation plan against the latest code state, and update the Issue in place. Use this when the user provides an Issue number (numeric, `#`-prefixed, or Issue URL) and wants to regenerate the code analysis via the explore-agent subagent. For reflecting comment-driven updates instead, use update-issue. For creating a brand-new Issue from a natural-language task description, use create-issue.
Create an implementation plan and a GitHub Issue based on the task description provided as an argument. Use this when the user supplies a natural-language task description (not an issue number) and wants a new implementation-ready Issue. If the input is an existing issue number, use create-issue-from-issue-number (re-analyze) or update-issue (reflect comments) instead.
GitHub Issueの確認事項に対して、コードベースやドキュメントを徹底的に調査し、根拠に基づいた回答を提供するスキル。Issueの最後のコメントに含まれる確認事項を調査・回答し、コメントに追記する。
ライブラリの情報を確認するためのスキル。Next.js、shadcn、その他のライブラリについて、適切なMCPサーバーを使用して最新のドキュメントと使用方法を取得します。
Create or update the Pencil (`.pen`) design for a UI implementation Issue before any code is written, then open a design-only PR. Takes the Issue number as argument, extracts the design requirements from the Issue description and comments, delegates `.pen` edits to the pencil-design-updater agent, exports snapshot PNGs, pushes them on the fixed `cc-ui-design-<Issue number>` branch, and opens a PR that references the Issue with `Refs #<N>` (never a closing keyword).
Execute tasks based on GitHub Issue content