Synthèse automatique
Crée une pull request GitHub à partir des commits déjà présents sur la branche courante : vérification du push, génération du titre et du corps (en priorité selon le template de PR du dépôt), exécution de `gh pr create`, puis demande de revue Copilot avec surveillance en arrière-plan.
Points forts
- Recherche le template de pull request du dépôt (chemins .github/, docs/, racine) avant de se rabattre sur un modèle par défaut
- Détecte une PR déjà existante et propose de mettre à jour son titre et sa description au lieu d'en créer une seconde
- Enchaîne automatiquement sur la correction des remarques via la skill pr-review-fix quand la revue Copilot remonte des points
- Contrôles préalables explicites : commits présents, arbre de travail propre, authentification `gh`, upstream configuré
Limites
- Ne crée pas les commits : ils doivent avoir été préparés en amont par une autre skill
- Dépend d'un hook PreToolUse qui bloque `git push` et `gh pr create` sans la variable `CLAUDE_GIT_SKILL=pr-create`, donc d'un environnement Claude Code configuré
- Les titres et corps sont produits en japonais avec une liste fermée de sept préfixes (feat/fix/docs/refac/chore/style/test), sans scope ni variante
À utiliser quand une branche contient déjà un ou plusieurs commits et qu'il faut ouvrir ou actualiser une pull request GitHub avec demande de revue automatisée.
À éviter s'il reste des modifications non commitées à organiser ou si le travail de découpage et de rédaction des commits n'est pas terminé.
Analyse de sécurité
PrudenceThe skill instructs execution of powerful tools (git, gh, bash) for legitimate GitHub PR automation, including pushing code and invoking GitHub API mutations. No destructive or exfiltrating commands are present in the skill file itself, but it relies on unshown local scripts and performs remote actions, so caution is warranted.
- •Uses bash commands to run git push, gh pr create, gh api graphql, and local shell scripts.
- •Depends on external scripts located in ~/.claude/skills/pr-create/scripts without showing their contents; they could potentially contain unsafe actions.
- •Background monitoring scripts execute shell commands and may perform network operations.
Exemples
現在のブランチに積んだコミットから PR を作成してdraft で PR を作って、レビュアーに @tanaka を指定して既存の PR のタイトルと説明を今のコードベースの内容に合わせて更新してname: pr-create
description: "GitHub Pull Request を作成する時に使う。トリガー: 「PR 作って」「PR 作成」「プルリクエスト作って」「create PR」「open PR」「raise PR」等のユーザー指示、または pr-create スキル指定。コミット済みブランチから push 確認 → タイトル / 本文案の提示 → gh pr create 実行 → Copilot レビュー依頼 → 到着をバックグラウンド監視し、指摘があれば pr-review-fix へ自動接続するまでを一気通貫。コミット作成自体は担当せず、事前に commit スキル等で済ませておく前提。"
pr-create
現在のブランチに積まれたコミットから GitHub Pull Request を作成するスキル。 コミット作成は担当せず、push 確認 → タイトル / 本文生成 → PR 作成までを行う。 問題がない限り、ユーザー確認は挟まず全自動で進める。
前提
- 現ブランチに PR に載せるコミットが 1 件以上 積まれていること。無い場合は「PR に含めるコミットがありません」と伝えて終了
- 現ブランチに 既に PR が存在 する場合 (
gh pr viewで検出) は新規作成せず、既存 PR の タイトル・説明に現状コードベースを反映する - 作業ツリーが汚れている (未コミットの変更がある) 場合はユーザーに扱いを確認 (コミットするか stash するか)
- 依存:
ghCLI (authenticated)、git
ワークフロー (6 Phase)
Phase 1 — 事前チェック
git status --short # 未コミット変更の有無
git rev-parse --abbrev-ref HEAD # 現ブランチ名
gh pr view --json number,url 2>/dev/null # 既存 PR の検出
git log --oneline "$(git merge-base HEAD @{u} 2>/dev/null || git merge-base HEAD origin/HEAD)"..HEAD
# PR に載るコミット一覧
- 既存 PR あり → タイトル・説明の更新作業に
- コミットが 0 件 → 終了
- 作業ツリーが汚れている → ユーザーに確認
Phase 2 — push
git push は CLAUDE_GIT_SKILL=pr-create を前置して実行する (PreToolUse hook ~/.claude/hooks/enforce-git-skill.sh が本スキル経由かどうかをこのマーカーで判定し、無いと直接実行はブロックされる)。
# upstream 未設定の初回 push
CLAUDE_GIT_SKILL=pr-create git push -u origin HEAD
# upstream 設定済みでローカルが先行
CLAUDE_GIT_SKILL=pr-create git push
push 失敗時は gh auth status と git remote -v を確認してユーザーに報告。
Phase 3 — タイトル・本文の生成
コミットログを読み取ってタイトルと本文を生成する。
タイトル (日本語、50 文字程度):
- コミットメッセージの規約 (
feat:/fix:/docs:/refac:/chore:/style:/test:) を踏襲- タイトルのprefixは必ず上記7種類のどれかを用いる。 refactor(frontend): 等のprefix改変、スコープ記述は認められない
- 句点なし、曖昧語 (
いろいろ修正等) は避ける - 単一コミット: その件名をそのまま流用(英語or曖昧な場合は別途日本語のタイトルを考える)
- 複数コミット: ブランチ全体の目的を集約して 1 件に要約
本文の構成 (必ずこの順で判定する)
Step 3-A — リポジトリの PR テンプレートを必ず先に検出する。default テンプレートにフォールバックする前に 必ず 以下を実行する。スキップ禁止。
# GitHub が認識する標準パスを全て確認 (大小文字・場所違いを網羅)
for p in \
.github/pull_request_template.md \
.github/PULL_REQUEST_TEMPLATE.md \
docs/pull_request_template.md \
docs/PULL_REQUEST_TEMPLATE.md \
pull_request_template.md \
PULL_REQUEST_TEMPLATE.md; do
[ -f "$p" ] && echo "FOUND: $p" && break
done
# 複数テンプレート (`.github/PULL_REQUEST_TEMPLATE/*.md`) もありうる
ls .github/PULL_REQUEST_TEMPLATE/ 2>/dev/null
Step 3-B — Step 3-A でテンプレートが見つかった場合:
- テンプレートファイルを
Readツール等で 必ず内容を読む - 各セクション (
##見出し /<!-- コメント指示 -->/ チェックボックス) を そのまま維持 - テンプレートが要求する情報をコミットログから抽出して埋める
- テンプレート由来のセクションを削除・改名しない。コメント指示 (
<!-- ... -->) はそのまま残してよい - 不明 / 該当無しのセクションは
- 該当なし等で空欄を埋める (削除しない)
Step 3-C — Step 3-A で 何も見つからなかった場合のみ、default テンプレートを使う。詳細は references/default_template.md を参照 (本 SKILL.md にはあえて inline で載せない。フォールバックである旨を明示するため)。
本文の書き方
リポジトリテンプレートの有無にかかわらず、常に以下にしたがって本文を推敲する
- 概要: Why を 1行で書く。コードから読める What の冗長説明は書かない
- 変更点:
- コミット、ファイル単位ではなく、わかりやすい機能単位で分割する。
- コードを読めばわかる具体名は極力書かない。
- 悪い例: 旧
experiments/sim2real/utils/action_dr.pyを削除し、engine (LowFreqNoiseInjector/dagger_offset_approach_iter/sample_duration_scale/sample_ee_perturbation/taper_weight) をpolaris/dr/motion_noise.pyに移設 - 良い例: DR関連のutil関数を正しい場所へ移設
- 動作確認: 簡潔に 2〜3 項目程度まで。実行者が実際に確認する最低限に絞り、網羅リストにしない
Phase 4 — PR 作成
gh pr create を HEREDOC で呼び出す (改行・Markdown を安全に渡すため)。CLAUDE_GIT_SKILL=pr-create を前置しないと PreToolUse hook にブロックされる。
CLAUDE_GIT_SKILL=pr-create gh pr create --title "<承認済みタイトル>" --body "$(cat <<'EOF'
## 概要
...
## 変更点
- ...
## 動作確認
- [ ] ...
EOF
)"
オプション (ユーザー指示があった時のみ追加):
--draft— draft PR として作成--reviewer <user>[,<user>...]— レビュアー指定--base <branch>— base ブランチを明示 (省略時はリポジトリのデフォルトブランチ)--assignee <user>— アサイン指定
Phase 5 — Copilot レビュー依頼 + 監視起動 (必須・毎回)
PR 作成直後、まず CI チェック完了の監視を background で 起動する (run_in_background: true の Bash で実行し、セッションをブロックしない)。Copilot 依頼の成否に関わらず起動する:
bash ~/.claude/skills/pr-create/scripts/poll-ci-checks.sh <PR番号>
- pending が消えるまで待機し、
ci=pass|fail|noneを出力して終了する - push 直後のチェック未登録は grace 期間 (デフォルト 120s) 内なら登録待ちとして扱い、grace を過ぎても現れなければ
ci=none(CI なしリポジトリ) と判定する - CI 修正後の再 push 時も、このスクリプト単体を background で再起動して再監視する
続けて、付属スクリプトで GitHub Copilot を PR レビュアーに登録する。省略禁止。
bash "${CLAUDE_PROJECT_DIR:-$HOME}/.claude/skills/pr-create/scripts/request-copilot-review.sh" <PR番号>
スクリプト本体: ~/.claude/skills/pr-create/scripts/request-copilot-review.sh
- 内部で
gh api graphqlのrequestReviewsmutation をbotIds付きで呼び、Copilot PR Reviewer (固定 bot ノードBOT_kgDOCnlnWA) を依頼する - Copilot レビュー機能未有効・既に依頼済み・権限不足などで失敗する場合があるが、PR 作成自体は成功しているので終了コード 1 でも警告扱いとし、ユーザーには「Copilot 依頼に失敗 (理由)」と PR URL の両方を伝える
依頼に成功したら、続けてレビュー到着のポーリングも background で 起動する。依頼に失敗した場合はこちらは起動しない (CI 監視は起動済みのまま維持する):
bash ~/.claude/skills/pr-create/scripts/poll-copilot-review.sh <PR番号>
Phase 6 — 完了報告
作成された PR URL・Copilot 依頼結果・監視起動 (レビュー / CI の 2 本) を報告していったん終了。
✅ PR #<N> を作成しました: <URL>
✅ Copilot にレビューを依頼しました (レビュー到着 / CI 完了をバックグラウンドで監視中)
(Copilot 依頼が失敗した場合は ⚠️ で警告のみ表示し、PR 作成成功と CI 監視は維持する)
Phase 7 — 監視完了時の自動対応
監視は 2 本 (レビュー / CI) が独立して動くため、完了通知 (task-notification) も個別に届く。それぞれの出力に応じて自動で動く:
poll-ci-checks.sh の通知:
ci=fail→ CI の失敗原因を確認・修正して push し、poll-ci-checks.shを background で再起動する (レビュー指摘対応と重なる場合はまとめて対応してよい)。ship フローの最中は CI が fail のままだとship.sh done reviewが通らないci=pass|none→ 報告のみ (レビュー対応の進行はレビュー側の通知に従う)- exit 1 (タイムアウト) → その旨を報告し、
gh pr checksで現状を確認して再起動か手動確認を提案
poll-copilot-review.sh の通知:
copilot_review=arrivedかつunresolved_threads> 0 → pr-review-fix スキルを起動して対応を開始する (修正計画の承認は pr-review-fix 内のフローが担うため、起動自体に確認は不要)。ship フローの最中なら先にship.sh done reviewを打つ (CI が未完 / fail だと通らない点に注意)unresolved_threads= 0 → 「Copilot レビュー到着、未解決の指摘なし」と報告して終了unresolved_threads=?→ スレッド数の取得に失敗している。fetch_unresolved_threads.shを手動実行して確認してから判断する (0 件と誤認しない)- exit 1 (タイムアウト) → その旨を報告し、必要なら
poll-copilot-review.shを再起動するか手動確認を提案 (再起動時のレビュー待機は開始時点からの増分基準なので、到着済みレビューがある場合はgh pr view --json reviewsで直接確認する)
トラブルシューティング
- 既に PR が存在: 新規作成せず既存 PR URL を返す。タイトル / 本文の更新が必要なら
gh pr edit <N> --title/--body-fileで対応 - push 失敗 (403 等):
gh auth status/git remote -vで認証と remote を確認 - 作成後にタイトル / 本文を直したい:
gh pr edit <N> --title "..."またはgh pr edit <N> --body-file /tmp/body.md - draft ↔ ready の切り替え:
gh pr ready <N>/gh pr ready --undo <N>
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/automated-github-pull-request-creation-mtwgrszi/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/automated-github-pull-request-creation-mtwgrszi' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/automated-github-pull-request-creation-mtwgrszi/download' --output '.skill-downloads/automated-github-pull-request-creation-mtwgrszi/SKILL.md.part' && mv '.skill-downloads/automated-github-pull-request-creation-mtwgrszi/SKILL.md.part' '.skill-downloads/automated-github-pull-request-creation-mtwgrszi/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/automated-github-pull-request-creation-mtwgrszi/SKILL.md' && test -s '.skill-downloads/automated-github-pull-request-creation-mtwgrszi/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/pr-create' && cp -R '.skill-downloads/automated-github-pull-request-creation-mtwgrszi' '.claude/skills/pr-create'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/automated-github-pull-request-creation-mtwgrszi'openskills read 'automated-github-pull-request-creation-mtwgrszi'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/automated-github-pull-request-creation-mtwgrszi/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Bonnes pratiques React Hook Form
Developpement
Maîtrisez React Hook Form : évitez les anti-patterns, gérez les abonnements, et traitez correctement reset, dirty state et entrées contrôlées.
Migration Emotion vers Mantine
Developpement
Migrer les styled-components Emotion vers des composants Mantine avec style props et modules CSS. Pour convertir .styled.tsx ou supprimer les imports @emotion.
Détecteur de dérive de périmètre
Developpement
Analyse les diffs git par rapport à une intention pour détecter la dérive de périmètre, fichiers non liés et PR trop larges, puis suggère de garder, diviser ou justifier.