create-pr

プルリクエストの作成

適切な規約に従って PR を作成します。ローカルでの検証、Conventional Commits 形式のタイトル、テンプレートに沿った本文、任意で関連チケットを含めます。このスキルは言語やフレームワークに依存しません。例に示されているビルド、Lint、テスト、フォーマットのコマンドは、プロジェクトで実際に使用しているものに置き換えてください。

前提条件

開始する前に、以下を確認します。

1. 現在のブランチにベースブランチにはないコミットがあること（git log origin/<base-branch>..HEAD --oneline）
2. ブランチがリモートにプッシュされていること（まだの場合は git push -u origin HEAD）
3. 取り込むべき未コミットの変更がないこと（git status）

ワークフロー

1. 変更内容を把握する

並行して実行します。

git log origin/<base-branch>..HEAD --oneline
git diff origin/<base-branch>..HEAD --stat

以下を特定します。

• 変更内容：変更されたモジュール、パッケージ、サービス、ディレクトリ
• 変更の種類：feat、fix、docs、refactor、test、chore、perf、ci、build、revert
• スコープ：主に影響を受けるモジュール／パッケージ／サービス（ディレクトリ名を使うか、横断的な変更には monorepo／repo を使用）
• コード変更かどうか：PR がソースコードを変更する場合（ドキュメント、Markdown、設定ファイルのみの変更ではない場合）、PR を作成する前にステップ 2 のローカル検証チェックリストを実行します。

2. ローカルでの検証（コード変更の場合）

PR がドキュメント、Markdown ファイル、その他のコード以外のファイルのみを変更する場合は、このステップを省略します。ソースファイルに触れる変更の場合は、PR を作成する前に、プロジェクトの検証コマンドをローカルで実行してください。

リポジトリのルートを調べてコマンドを確認します（例：Makefile、package.json、pyproject.toml、Cargo.toml、go.mod、build.gradle、mix.exs、Gemfile、composer.json、justfile、Taskfile.yml、README.md、CI ワークフロー設定）。利用可能であれば、フィルター／ターゲットのフラグ（例：turbo --filter、nx --projects、pnpm --filter、bazel //path/...、cargo -p <crate>、pytest <path>、go test ./<pkg>/...）を使って、影響を受ける箇所だけを実行します。リポジトリ全体を実行するより高速です。

該当する場合、一般的な検証項目を実行します。

型チェック／コンパイル

プロジェクトに静的型チェックまたはコンパイルの手順がある場合は実行します。

エコシステム別の例（リポジトリで定義されているものを使用してください）。

• TypeScript：npm run typecheck、pnpm -r typecheck、tsc --noEmit
• Python（型付き）：mypy .、pyright、ty check
• Rust：cargo check
• Go：go build ./...、go vet ./...
• Java/Kotlin：./gradlew compileJava、./mvnw compile

Lint／フォーマット

プロジェクトのリンターとフォーマッターを実行します。自動修正用のターゲットがある場合は、そちらを優先します。

例：

• JS/TS：npm run fix、npm run lint、eslint .、prettier --check .
• Python：ruff check --fix .、ruff format .、black .、flake8
• Rust：cargo clippy --all-targets、cargo fmt --check
• Go：golangci-lint run、gofmt -l .
• Shell：shellcheck、shfmt -d .

テスト

影響を受けるパッケージの単体テスト／統合テストを実行します。

例：

• JS/TS：npm run test -- --filter=<workspace>、pnpm -r test、vitest run <path>、jest <path>
• Python：pytest <path>、tox -e <env>、python -m unittest
• Rust：cargo test -p <crate>
• Go：go test ./<pkg>/...
• Java/Kotlin：./gradlew test、./mvnw test
• Ruby：bundle exec rspec <path>、rake test

追加チェック（該当する場合に実行）

• 未使用のエクスポート／デッドコード：プロジェクトにデッドコードチェックがある場合は実行します（例：Python の knip、ts-prune、vulture、Go の deadcode／unused、Rust の cargo udeps）。
• 依存関係の健全性：プロジェクトに依存関係チェックがある場合は実行します（例：depcheck、pip check、cargo audit、bundle audit）。
• ロックファイルの同期：依存関係マニフェスト（package.json、requirements.txt、pyproject.toml、Cargo.toml、go.mod、Gemfile など）を変更した場合は、インストールコマンド（npm install、pnpm install、uv sync、poetry lock --no-update、cargo update -w、go mod tidy、bundle install）を実行し、ロックファイルの変更をコミットします。ロックファイルが最新でないと、CI で失敗することがよくあります。
• 生成コード／コード生成：リポジトリに OpenAPI 仕様、protobuf、GraphQL スキーマ、SQL マイグレーション、またはその他の生成された成果物がある場合は、再生成して変更をコミットします。
• スタイル／アセットのリンター：スタイルシートリンター（stylelint など）や、変更したファイルに対応するアセットリンターを実行します。
• セキュリティスキャン：リポジトリで設定されているセキュリティ／シークレットスキャナー（trivy、semgrep、gitleaks など）を実行します。

3. チケットへのリンク（任意）

組織で課題管理ツールを使用している場合は、ユーザーに次のいずれにするか尋ねます。

• 新しいチケットを作成する：適切なツール（Linear、Jira、GitHub Issues など）を使用します。
• 既存のチケットにリンクする：識別子（例：TEAM-1234、JIRA-567、#42）を尋ねます。
• スキップする：ユーザーがチケットは不要だと明示した場合に限ります。

多くの CI システムでは、PR 本文にチケット識別子を必須に設定できます。組織の規約に従ってください。

4. PR タイトルの形式

Conventional Commits に従います：type(scope): description

• type：feat、fix、docs、refactor、test、chore、perf、ci、build、revert
• scope：影響を受けるモジュール／パッケージ／サービス／ディレクトリの名前。横断的な変更の場合は monorepo／repo を指定します。複数のスコープはカンマ区切りで指定できます：fix(a, b, c): ...

例：

• feat(web): add dark mode toggle
• fix(cli, daemon): load shell env at entrypoint
• fix(api): handle nil response from upstream
• chore(repo): bump dependencies

5. PR 本文の作成

PR テンプレートのすべてのセクションに記入します。一般的なテンプレートには、次の 4 つのセクションがあります。

## Description

<concise summary of what changed and why>

## Related Issue

Closes TEAM-XXXX


## Potential Risk & Impact

<list risks, performance implications, technical debt>


## How Has This Been Tested?

<describe testing performed: unit tests, manual testing, typecheck, lint>

6. PR の作成

gh pr create \
  --base <base-branch> \
  --head <branch-name> \
  --title "<type>(<scope>): <description>" \
  --body "<generated body>"

本文が長い場合は、一時ファイルに書き込み、--body-file を使用します。

gh pr create --base <base-branch> --head <branch> --title "..." --body-file /tmp/pr-body.md

7. 結果の報告

PR の URL をユーザーに返します。

CI チェックのリファレンス（テンプレート）

以下は、すべての PR で実行される一般的なチェックのカテゴリです。このスキルを調整する際は、各カテゴリをリポジトリで実際に使用するコマンドに対応付けてください。

常に実行するチェック

カテゴリ	内容	ローカルのコマンドの確認方法
型チェック／コンパイル	プロジェクトがコンパイルできること、または静的型チェックに合格することを検証します	package.json、Makefile、pyproject.toml、Cargo.toml、go.mod、CI 設定を確認します
リンター	コードスタイル／正確性のルールを適用します	リポジトリのルートで lint、check、または同等のスクリプトを確認します
フォーマット	一貫したフォーマットを適用します	format、fmt、prettier、black、gofmt、rustfmt などを確認します
テスト	単体テストと統合テストを実行します	test スクリプト／ターゲットを確認します
デッドコード／未使用のエクスポート	未使用のコードを検出します	knip、ts-prune、vulture、cargo udeps などを確認します
依存関係チェック	未使用または脆弱な依存関係を検出します	depcheck、audit、cargo audit などを確認します
ロックファイルの同期	マニフェストに対してロックファイルが古い場合に失敗します	使用しているパッケージマネージャーのインストールコマンドを実行し、ロックファイルをコミットします
PR の規約	ブランチ名、意味に沿ったタイトル、チケットの有無を検証します	上記の書式ルールに従います

条件付きチェック（影響を受けるファイルが変更された場合のみ実行）

• API／スキーマの検証：API またはスキーマに変更があった場合に実行されます。ローカルで再生成してください。
• プラットフォーム固有のビルド：デスクトップ／モバイル／組み込み向けのターゲットに影響がある場合に実行されます。
• E2E テスト：コンシューマーアプリまたはトップレベルのバイナリに影響がある場合に実行されます。

CI で適用される一般的な PR の規約

• ブランチ名：最大長と使用可能な文字（例：[A-Za-z0-9/-]）。
• タイトル：有効なスコープを含む Conventional Commits 形式。
• チケット参照：PR の本文にチケット識別子を含める必要があります（chore: と revert: のタイプでは省略されることがよくあります）。

よくある回避すべきミス

• ベースブランチの誤り：組織で PR の送信先としているブランチ（例：dev、main、develop、trunk）を使用してください。
• スコープの記載漏れ：PR タイトルの CI チェックでは、有効なスコープが必要となることがよくあります。
• チケット参照の記載漏れ：CI を通過するには、説明にチケット ID を記載する必要があります（chore:／revert: を除く）。
• プッシュ忘れ：gh pr create を実行する前に、ブランチをリモートにプッシュしてください。
• ロックファイルの不整合：依存関係を変更した後は、必ずインストールコマンドを実行し、ロックファイルの変更をコミットしてください。
• コードの PR でローカルチェックを省略する：問題を早期に発見し、CI の再実行を避けるため、コード変更を送る前に型チェック／コンパイル、リンター、テストをローカルで実行してください。
• 生成された成果物のコミット漏れ：API／スキーマの変更後は再生成し、コミットしてください。