ship-pr

PR を提出する

リポジトリの規約に従って、依頼された提出範囲を完了してください。実装の影響分析、現在のチェック結果、QA の証跡を再利用してください。依頼された場合、またはプロジェクトで必要とされる場合を除き、PR の準備をリリースや自動レビューの一連の作業に拡大しないでください。

1. ブランチとベース、ステージ済みおよび未ステージの変更、関連する指示、PR テンプレート、現在の検証状況を確認してください。すでにコミット済みの作業も有効な入力です。無関係な変更はステージングしないでください。
2. 変更された公開動作を、影響を受けるドキュメント、サンプル、設定、リリースノートまでたどってください。範囲を絞った差分はローカルで確認できます。範囲を限定した独立エージェントは、規模の大きい領域が個別に存在する場合に限り有用です。
3. 影響を受ける成果物を更新してください。リポジトリのリリースノート方針に従ってください。PATH 上にバイナリがあることだけでは、リポジトリで採用されているとは判断できません。箇条書きごとにノートを作成するのではなく、関連する変更をまとめてください。
4. 変更後の動作、重大なリスク、実際に行った検証を中心に PR の説明を作成してください。リポジトリのテンプレートを使用し、任意のセクションが空なら省略してください。変更内容の説明に役立つ場合に限り、既存の QA 成果物を含めてください。
5. コミット前に、プロジェクトの方針で認められる範囲で、必要な対象範囲のゲートを実行するか、有効な証跡を再利用してください。所有するパスを明示してステージングし、ステージ済みの差分を確認してください。commitlint とフックの要件に従ってください。モデルへの帰属を捏造したり、履歴を書き換えたり、フックを回避したりしないでください。
6. コミット、プッシュ、PR の作成がユーザーの依頼範囲に含まれる場合は、機能ブランチを公開し、本文ファイルを使って gh で PR を作成または更新してください。指定されたドラフト状態に従ってください。必須 CI が現在の HEAD で完了するまで確認し、失敗が発生したら状況を見極めてください。
7. 外部レビューの監視を開始するのは、依頼された場合、または承認済みの提出ワークフローにすでに含まれている場合に限ってください。インストール済みコマンドと設定済みプロバイダーを確認してください。自動修正、コミット、プッシュ、無制限のポーリングは、それぞれ独立した範囲の選択肢であり、ツールが検出されたことだけを理由に実行しないでください。

参考資料

詳細が必要なフェーズの資料を読み込んでください：references/explore-impact.md、references/release-notes.md、references/pr-description.md、references/qa-artifacts.md、references/commit-conventions.md、または references/coderabbit-watch.md。

読み取り専用の検出スクリプトは bash <ship-pr-dir>/scripts/detect-tooling.sh です。スキルを基準にパスを解決してください。PATH の検索結果が示すのは利用可能性であり、実行の許可やプロジェクトの設定ではありません。任意の連携機能が見つからなくても、通常の PR 作業は妨げられません。影響を受ける仕様成果物があり、リポジトリで設定されている場合に限り、Skeeper を同期してください。