submit-pr

プルリクエスト提出ワークフロー

プロジェクトのトランクベース開発ワークフローと PR テンプレートに従って、現在のフィーチャーブランチから適切にドキュメント化されたプルリクエストを作成します。

注意

適用範囲：このスキルでは、コードのプッシュ、プルリクエストの作成、CI の監視、CI の修正のコミット（ユーザーの承認を得た場合）を行います。新機能の実装や正式なコードレビューは行いません。PR が作成され、CI が通過したら、そこで停止してください。ワークフローは完了です。

警告

チェックポイントの手順。 このワークフローで ### CHECKPOINT に到達した場合、ユーザーに判断を求めるプロンプトを必ず明示的に表示してください。情報を提示しただけで続行してはいけません。エージェントの対話型プロンプト機能（Claude Code の AskUserQuestion など）を使い、続行前に明示的な応答を求めてください。これにより、キューに入っているメッセージや処理中のメッセージを誤って承認と解釈することを防ぎます。エージェントに対話型プロンプト機能がない場合は、チェックポイントの内容を出力し、ユーザーから明示的な応答があるまですべての作業を停止してください。

ステップ 1：提出前のチェック

ブランチがプルリクエストを作成できる状態か確認します。

1. フィーチャーブランチにいることを確認します（main ではありません）。main にいる場合は停止し、先にフィーチャーブランチを作成するようユーザーに依頼します。

2. main と同期します。

   git fetch origin
   git rebase origin/main
   

   競合がある場合は停止し、続行する前にユーザーが競合を解決できるよう支援します。

3. プロジェクトの品質チェックを実行します。

   # Adapt to your project's toolchain
   type-check      # TypeScript tsc, mypy, etc.
   lint            # ESLint, Ruff, golangci-lint, etc.
   format:check    # Prettier, Black, gofmt, etc.
   test            # Vitest, Jest, pytest, etc.
   build           # If a build step exists
   

   フォーマットチェックに失敗した場合は、報告されたファイルにフォーマッターを実行して自動修正し、変更をステージングします。

4. 変更したファイルに対して最終的なセキュリティスキャンを実施します。

   • 差分にハードコードされたシークレット、API キー、認証情報が含まれていませんか？
   • すべてのユーザー入力が検証およびサニタイズされていますか？
   • 新しいエンドポイントに認証と認可のチェックがありますか？
   • エラーレスポンスは安全ですか？（内部情報が漏れていないか）
   • 依存関係に既知の CVE はありませんか？

   Claude Code の最適化：/security-scanning:security-sast スキルが利用可能な場合は、より高度な自動スキャンに使用します。利用できない場合は、上記の手動チェックリストに従います。

チェックに失敗した場合は、失敗内容を明確に報告し、今すぐ修正するか、そのまま続行するかをユーザーに尋ねます。

ステップ 2：変更内容の分析

この PR に含まれる内容を把握します。

1. git log origin/main..HEAD --oneline を実行し、このブランチ上のすべてのコミットを確認します。
2. git diff origin/main...HEAD --stat を実行し、ファイル変更の概要を確認します。
3. git diff origin/main...HEAD を実行し、実際の変更内容を読みます。

以下を確認します。

• 変更の種類：feature、fix、docs、refactor、test、chore（コミットのプレフィックスから判断）
• 対象範囲：フロントエンド、バックエンド、フルスタック、インフラストラクチャ
• データベースのマイグレーションを含むか？（マイグレーションファイルまたはスキーマの変更を確認）
• インフラストラクチャの変更を含むか？（コンテナ、CI/CD、環境ファイル）
• セキュリティ上重要な変更を含むか？（認証、認可、API セキュリティ、シークレット）
• 関連するイシュー：コミットメッセージから抽出します（Closes #NNN、Fixes #NNN）

ステップ 3：デプロイメント協議会によるレビュー（条件付き）

以下のいずれかに該当する場合は、スキルの councils/deployment-council.md からデプロイメント協議会を起動します。

• データベースのマイグレーションが含まれる
• コンテナまたはインフラストラクチャのファイルが変更された
• 環境変数が追加または変更された
• 認証または認可のコードが変更された
• CI/CD パイプラインのファイルが変更された

起動した場合は、協議会のテンプレートを読み、デプロイメントチェックリスト全体に沿って確認します。各協議会メンバーについて、スキルの agents/ ディレクトリからエージェント定義を読み、指定された複雑さのレベルに応じてレビューの深さを調整します。チェックリストはデプロイメントインフラストラクチャに合わせて調整します。

プラットフォームエンジニア（リード）

• アプリケーションはデプロイ向けに正常にビルドおよびパッケージ化されますか？
• 環境変数は設定されていますか？
• ヘルスチェックのエンドポイントは動作していますか？
• リソース制限（CPU、メモリ）は設定されていますか？
• ロギングとモニタリングは設定されていますか？
• ロールバック戦略は定義されていますか？

セキュリティエンジニア

• シークレットは安全に管理されていますか（コード内に含まれていませんか）？
• HTTPS/TLS は設定されていますか？
• API 認証は機能していますか？
• CORS は正しく設定されていますか？
• セキュリティヘッダー（Content-Security-Policy、X-Frame-Options、HSTS など）は設定されていますか？
• 重大度の高い脆弱性はありませんか？

QA リード

• E2E テストは合格していますか？
• 重要なユーザーフローは検証されていますか？
• パフォーマンステストは完了していますか？
• 既知の P0/P1 バグはありませんか？
• 回帰テストは合格していますか？
• デプロイ後に実行するスモークテストは定義されていますか？

デプロイの判断

• ステータス：承認済み／準備未完了／ブロック中
• デプロイ戦略：ローリング／ブルーグリーン／カナリア
• ロールバック計画：問題が発生した場合のロールバック方法

チェックポイント（デプロイ審議会が有効化された場合のみ）：デプロイ準備状況の評価をユーザーに提示してください。次に進む前に確認を待ってください。

ステップ 4：PR の説明を作成する

プロジェクトに PR テンプレート（例：.github/PULL_REQUEST_TEMPLATE.md）がある場合は、それを使用してください。ない場合は、次のセクションを含む完全な PR を作成してください。

タイトル

• 形式：conventional commits に準拠した <type>(<scope>): <short description>
• 70 文字未満にしてください
• 主なコミットの種類とスコープを使用してください

本文

説明：コミットメッセージと変更されたファイルから内容をまとめてください。変更内容だけでなく、その理由も説明してください。

変更の種類：コミットのプレフィックスから自動判定し、該当するチェックボックスにチェックを入れてください。

関連する Issue：コミットメッセージから抽出してください（Closes #NNN）。

変更内容：主な変更を、領域（フロントエンド、バックエンド、データベースなど）ごとに整理して箇条書きにしてください。

テスト：追加・更新したテストと、手動テストの方法を記載してください。

チェックリスト：実際の状況に基づいて事前に記入してください。

• 実際に完了している項目（テスト合格、lint 合格など）にチェックを入れてください
• 対応が必要な項目は未チェックのままにしてください

破壊的変更：API コントラクト、データベーススキーマ、または公開インターフェースに変更がある場合は明記してください。

デプロイに関する注意事項：マイグレーション手順、新しい環境変数、インフラストラクチャの変更を記載してください。デプロイ審議会が有効化されている場合は、その調査結果を参照してください。

変更履歴の項目

PR にユーザー向けの変更が含まれる場合は、変更履歴の項目を作成してください。

• カテゴリを決定してください：追加／変更／修正／削除
• ユーザーの視点から一行で説明してください
• PR 番号を記載してください

チェックポイント：PR のタイトルと本文全体をユーザーに提示してください。送信前に確認し、修正を依頼できるようにしてください。

ステップ 5：プッシュして PR を作成する

1. ブランチをリモートにプッシュします。

   git push origin <branch-name> -u
   

2. PR を作成します。GitHub CLI を使う場合の例：

   gh pr create --title "<title>" --body "<body>" --base main
   

   GitHub を使用していない場合は、プロジェクトのバージョン管理プラットフォームに合わせてください。

3. PR テンプレートにラベルが含まれている場合は、適切なラベルを追加してください。

ステップ 6：CI パイプラインを監視する

PR の作成後、CI パイプラインが完了するまで監視してください。

1. ブランチの最新の CI 実行を確認します。

2. 実行が完了するまで監視します。GitHub CLI を使う場合の例：

   gh run list --branch <branch-name> --limit 1 --json databaseId,status
   gh run watch <run-id> --exit-status
   

3. CI が失敗した場合は、失敗したジョブのログを取得して原因を診断します。

   • フォーマットの失敗：フォーマッターで自動修正し、コミット、プッシュしてから再度監視します。チェックポイントは不要です。
   • その他すべての失敗：チェックポイント — 診断結果と提案する修正をユーザーに提示してください。コミットする前に承認を待ってください。承認後、修正、コミット、プッシュを行い、再度監視してください。

4. CI が合格した場合は、ステップ 7 に進みます。

ステップ 7：PR の概要

ユーザーに以下を提示します。

• PR の URL（クリック可能なリンク）
• 提出した内容の概要
• CI のステータス（すべてのチェックに合格）
• 変更履歴のエントリー（生成されている場合）
• ブランチのライフサイクルに関するリマインダー：マージ後にブランチを削除する

Deployment Council が有効になっている場合は、マージ後に必要なデプロイ固有の手順をユーザーに知らせます。

ヒント

ワークフローが完了しました。 PR は提出され、CI はすべて成功しています。PR がマージされ、ブランチが削除されたら、機能のライフサイクルは完了です。

パイプライン：/plan-feature → /build-feature または /build-api → /review-code → /submit-pr（現在のステップ）

ユーザーが次の機能に取りかかりたい場合は、「/plan-feature を実行して、次の機能の計画を始めましょう。」と提案してください。