Stats
Actions
Tags
From github-issue-pr-flow
既に起票済みの GitHub Issue を、Issue 番号入りブランチ → 実装 → PR の順で進めるワークフロー。main へのマージはオーナーが行う。「#42 やって」「次の P1 やって」「○○を直して(Issue 番号付き)」「リファクタして(Issue あり)」「バックログから取って」など、Issue を消化する実装作業が絡む場合に必ずこのスキルを参照すること。Issue がまだ起票されていない場合は issue-intake を先に呼ぶ。読み取り・調査・質問のみの作業には適用しない。
How this skill is triggered — by the user, by Claude, or both
Slash command
/github-issue-pr-flow:github-issue-pr-flowThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
このスキルは、**既に存在する Issue を実装する** ためのワークフロー。Issue を読み込んでブランチを切り、実装して PR を出すまでを担当する。
このスキルは、既に存在する Issue を実装する ためのワークフロー。Issue を読み込んでブランチを切り、実装して PR を出すまでを担当する。
main への直接コミット・直接マージは禁止。マージ実行は必ずオーナーが行う。
issue-intake (As-Is/To-Be → Issue 起票)
↓
github-issue-pr-flow ← このスキル (Issue → ブランチ → 実装 → PR)
Issue がまだ起票されていない場合はこのスキルでは扱わない。issue-intake を呼んで Issue 起票を済ませてから戻ってくる。
✅ 使う:
❌ 使わない:
issue-intake へpdm-design-doc へ/tmp 等) の操作~/.claude/...) の更新git status
git branch --show-current
main 以外のブランチに居る場合は、その作業を続けるか新規ブランチを切るかユーザーに確認そのまま使う。gh issue view <番号> で読み込む。
候補を絞り込んで提示する:
# 優先度ラベルでソート
gh issue list --state open --label "P0" --limit 5
gh issue list --state open --label "P1" --limit 5
# 種別 + 直近作成順
gh issue list --state open --label "bug" --limit 10
# Assignee が自分のもの
gh issue list --state open --assignee @me --limit 10
候補を以下のフォーマットでユーザーに提示:
バックログから候補(open):
🔴 P0 (0 件)
🟠 P1 (2 件):
- #42 ログイン後の next パラメータ検証で Open Redirect を防止 (created: 2026-04-01)
- #38 課題提出ファイルの MIME 検証強化 (created: 2026-03-28)
🟡 P2 (5 件):
- #45 ...
どれを実装しますか? (番号で指定)
ユーザーが選ぶまで実装に入らない。
gh issue list --search "<キーワード>" --state open --limit 10 で既存 Issue を探す#X のことですか?」と確認issue-intake を呼んで先に起票するようユーザーに案内(このスキルでは起票しない)gh issue view <番号> --json title,body,labels,assignees,milestone,state
確認するポイント:
#X リンクや、近いブランチ名の存在を軽く確認スコープが Issue と乖離していたらユーザーに確認:
承認なしにスコープを広げない。
git checkout main
git pull
git checkout -b <番号>-<短い英語ケバブケース説明>
例: Issue #42 が「ログイン画面の文言修正」なら → 42-fix-login-copy
ルール:
-feature/ fix/ などプレフィックスを使う運用がある場合はそちらに合わせる(git branch -a で確認)注意: パターン B/C で複数 Issue を渡された場合、原則 1 Issue = 1 ブランチ = 1 PR。まとめたい場合はユーザーに確認。
git log --oneline -20 で確認)issue-intake で追加 Issue を起票)CLAUDE.md がある場合は必ず参照(型チェック・lint・ビルドの完了確認など)機能追加・画面追加・UI 変更・業務フロー変更を行った場合は、同じ PR 内で対応する E2E テストも追加する。テストを別 PR に分けない。
手順:
プロジェクトに E2E 環境があるか確認
package.json / playwright.config.* / cypress.config.* / e2e/ ディレクトリ等を確認既存テストで今回の変更がカバーされているか確認
*.spec.ts を grep / ファイル名検索で探す*.spec.ts を作成最低限カバーするケース
テスト方針
playwright-test 等のスキルがあれば必ず参照getByRole / getByLabel 優先。data-testid は最終手段テスト実行
E2E を追加しなくてよいケース(該当する場合のみ):
E2E を追加できないが追加すべきケース(時間・技術的制約等):
PR 本文に「E2E テスト未追加(理由: ...)」と必ず明記し、フォローアップ Issue を issue-intake で起票。ユーザーに口頭でも報告。サイレントに飛ばさない。
UI / ユーザーが触れる挙動の変更を行った場合、同じ PR 内で関連ドキュメントを更新する。後追い PR にしない。
手順:
プロジェクトに以下のいずれかが存在するか確認
app/manual/* / docs/manual/* / README の使い方節 等)app/release-notes/* / CHANGELOG.md 等)public/manual/images/* / docs/screenshots/* 等)CLAUDE.md に専用手順が書いてあればそれを最優先(該当ファイルパス・撮影解像度・テンプレート構造などプロジェクト固有のルール)更新する対象
feature / improvement / security / fix 等プロジェクト規約に合わせる)更新が不要なケース
更新不要と判断した場合は、PR 本文と完了報告で「マニュアル/リリースノート更新不要(理由: ...)」と必ず明記。サイレントに飛ばさない。
UI 変更にもかかわらずスクショ差し替えが間に合わない場合は「スクショ未差し替え(follow-up)」を PR 本文に明記し、follow-up は issue-intake で別 Issue として起票。
判断に迷うケース:
security カテゴリで追加、無ければ省略git push -u origin HEAD
gh pr create --title "<簡潔なタイトル>" --body "$(cat <<'EOF'
## Summary
- <1-3 行の変更概要>
## Changes
- <変更点1>
- <変更点2>
## Test plan
- [ ] <検証項目1>
- [ ] <検証項目2>
Closes #<Issue番号>
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
重要:
Closes #<Issue番号> を入れる(後述の自動クローズに必須)--draft を付けるかは状況次第。CI を回しつつ続きの作業がある場合はドラフトにするGitHub は PR 本文または各コミットメッセージに次のキーワードがあると、PR が デフォルトブランチ(= main)にマージされたタイミングで参照先 Issue を自動クローズ する。
Closes #<番号> / Close #<番号> / Closed #<番号>Fixes #<番号> / Fix #<番号> / Fixed #<番号>Resolves #<番号> / Resolve #<番号> / Resolved #<番号>ルール:
Closes #<番号> で統一する(英語動詞の揺れを作らない)Closes #12, Closes #34 のように 各 Issue に対してキーワードを繰り返す(Closes #12, #34 は動作しない)Closes owner/repo#番号 形式確認手順: PR 作成後に gh pr view <PR番号> で本文に Closes #<番号> が入っていることを目視で確認する。入っていなければ gh pr edit <PR番号> --body "..." で修正する。
ユーザーに以下を報告して 作業を止める:
やってはいけないこと:
🚫 gh pr merge を実行しない
🚫 git push origin main などで main に直接 push しない
🚫 --admin フラグで PR を強制マージしない
🚫 ユーザーに無断で main にリベース・force push しない
🚫 gh issue close を実行しない(後述)
ユーザーが「マージして」「merge して」と明示的に指示した場合のみマージを実行する。それ以外はマージしない。
Issue は PR が main にマージされた瞬間に、GitHub が Closes #N キーワードを検知して自動でクローズする。Claude が手動で閉じることは禁止。
🚫 禁止する操作:
gh issue close <番号> を実行する✅ 正しい挙動:
closedByPullRequestsReferences に PR が記録される)例外:
ユーザーが明示的に「Issue #N を閉じて」と指示した場合のみ gh issue close を実行してよい。「実装終わった」「PR 作った」「マージ済み」だけでは閉じる根拠にならない — その場合も自動クローズに任せる。
Issue を間違って実装外の理由でクローズしたい場合(例: 重複・仕様変更で不要になった): これも Claude からは閉じない。ユーザーに「この Issue は不要になったようです。閉じますか?」と確認し、明示の "閉じて" を待つ。
このスキルでは起票しない。ユーザーに 「issue-intake を先に呼んで Issue を起票してから戻ってきてください」 と案内する。Claude 側から勝手に gh issue create を叩かない。
ユーザーに「このリポジトリは Issue 運用していますか?」と確認する。否であれば Issue ステップを飛ばし、ブランチ + PR のみで進める(タイトル・本文には変更内容を直接書く)。
ユーザーから「直接 main に push して」「Issue 無しで PR だけ作って」など明示の指示があった場合のみ、その指示に従う。Claude 側から省略を提案しない。
途中のブランチがある場合は、続行か別ブランチを切るかをユーザーに確認。勝手に新規ブランチに切り替えない。
issue-intake で起票してから別ブランチで対応Closes #<番号> が入っている(gh pr view で目視確認済み)Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub hico-mrmgn/skills --plugin github-issue-pr-flow