incu-way-prepare-pr

PR の準備／変更のコミット

incu-way の作業を Git に永続化する唯一の場所です。このリポジトリ内の他のすべてのフローはファイルを書き込むだけで、適切なチェックポイントでこのスキルの実行を提案します。どのフローも独自にコミット、プッシュ、PR の作成を行うことはありません。このリストをここに列挙していないのは意図的です。現在または将来の incu-way のフローはすべて同じルールに従うため、スキルの追加、名称変更、削除のたびに同期する必要はありません。

**自分で呼び出すのを防ぐ本当のゲートは、この上にあるフロントマターの description です。**この段落ではありません。スキルのマッチングは本文を読む前にその説明に基づいて行われるため、「ユーザーが明示的に依頼した場合にのみ呼び出す」という条件を実際に機能させるには、そこに記載する必要があります。この本文は、このファイルを直接読むことになった人のための二重の防御線です。呼び出し元のスキルである場合は、このスキルを自分で呼び出さず、「このチェックポイントの準備ができました。コミットする場合は incu-way-prepare-pr を実行してください（または、実行するよう依頼してください）。」のように伝えて、そこで止めてください。

---

ステップ 1 — コンテキストを特定する

git branch --show-current

各フローと同じ方法で {slug} を導き出します（ブランチ名から feat/ | fix/ | fix/security- | chore/ | docs/ | assess/ のプレフィックスを除きます）。.ways/state.json が存在する場合は、それを読み込んで（まだ書き込まないでください）、このチェックポイントに対応する flow、phase、ゲートまたはドキュメントを確認します。存在しない場合（項目ファイルのない評価／ドキュメント作成フローや、単純なアドホックな「これをコミットして」という依頼など）は、ファイルなしで進めます。

ステップ 2 — コミットされる内容を正確に提示する

git status --short
git diff --stat
git diff --stat --staged

何かに触れる前に、これをユーザーに提示します。ステージ済みの変更も未ステージの変更もない場合は、その旨を伝えて終了します。コミットするものはありません。

ステップ 3 — コミットメッセージを提案する

すべてのコミットはConventional Commitsに従います。 例外はありません。

<type>(<scope>)<!>: <description>

<body>

<footer>

type — feat、fix、docs、style、refactor、perf、test、build、ci、 chore、revertのいずれかです。この正確なリストはIncu 組織のポリシーであり、Conventional Commits の仕様そのものではありません（仕様で意味が定義されているのはfeat／fixのみで、typeの集合は限定されていません）。 このポリシーは、すべてのincu-techリポジトリで履歴を検索しやすく、一貫性のあるものにするためのものです。このリストにない リポジトリ固有のtypeはありません。新しく作るのではなく、最も近いもの（通常はchore）を選んでください。推測してはいけません。呼び出し元のフロー自体の SKILL.mdに、そのフェーズのコミットメッセージ形式がすでに記載されています（ユーザーがいるチェックポイント付近にある「commit message format」／「suggested commit message」セクションを確認してください）。または、ブランチのプレフィックスから判断してください。

ブランチのプレフィックス	type	scope
feat/{slug}	feat	{slug}
fix/{slug}	fix	{slug}
fix/security-{slug}	fix	security
chore/{slug}	chore	{slug}（リポジトリ全体に関わる場合は省略します。たとえば、すべてのファイルに及ぶバージョン更新など）
docs/{slug}	docs	{slug}
assess/{slug}	docs	{slug}（評価／脅威モデル／セキュリティ検証レポートはドキュメントです。assess:のような標準外のtypeを決して作らないでください）

ブランチのプレフィックスからも、呼び出し元のフロー自体の形式セクションからもtypeが明らかでない場合は、 推測せずユーザーに尋ねてください。

description — 命令形（「added」／「adds」ではなく「add」）にし、コロンの直後は小文字で始め、末尾にピリオドを付けません。type(scope): descriptionの行全体が 約72桁以内に収まるよう、短くします。変更の内容を記述し、理由は本文に記載します。

! — このコミットで文書化された契約（スキーマ、公開CLIフラグ、ディスク上の形式など、下流の利用者が依存するもの）が破られる場合に限り、 scopeの直後（scopeがない場合はtypeの直後）に付けます。必ず、何が壊れ、どのように対応すればよいかを説明するBREAKING CHANGE:フッターと組み合わせてください。どちらか片方だけで使うことはありません。また、外部から観察できる変更を伴わない内部リファクタリングには使いません。

本文 — descriptionの後に空行を1行入れ、約72桁で折り返した文章を続けます。差分だけでは分からない理由を説明します。つまり、別の方法ではなくこの方法を選んだ理由、置き換えるもの、コードからは自明でないレビュー担当者向けの情報を記載します。差分を行ごとに言い換えるものではありません。また、descriptionだけで内容が伝わるほど小さな変更では省略できます（1行の誤字修正に本文は不要です）。

フッター — 本文の後に空行を1行入れ、解決する、または関連するIssueがある場合はCloses #123／Refs #123を記載します（このリポジトリに実際に存在する場合のみ。番号を捏造しないでください）。上記で!を使った場合は、必ずBREAKING CHANGE: <description>を記載します。

原子性。 1つのコミットにつき、論理的な変更は1つにします。それぞれ単独でビルドとテスト／評価に合格するようにし、将来のgit bisectやこのコミットだけの取り消しで、無関係な作業が巻き込まれないようにします。状態ファイル.ways/state.jsonが他のファイルと一緒に変更されている場合は、同じ変更に関するメタデータなので、それらと一緒に同じコミットに含めます。ただし、互いに無関係な論理単位の作業が複数ステージ済み／変更済みの場合（たとえば、無関係な2つのチェックポイントや、無関係な機能に便乗したついでのリファクタリングなど）は、黙ってまとめず、別々のコミットに分けることを提案してください。

ゲート — コミットの確認

次のように伝えてください：「コミットしようとしています：{file list}。メッセージ：{proposed message}。git add／git commitを実行する前に確認してください。」

停止してください。ユーザーが確認するまで、git addもgit commitも実行しないでください。

明示的な確認を得た後に限り、レビュー済みのファイルだけをステージし、コミットしてください。

ステップ 4 — プッシュと PR（ユーザーがこれも依頼した場合のみ）

コミットを依頼されたからといって、ユーザーがプッシュや PR の作成も希望していると決めつけないでください。次のように確認します。

{branch} をプッシュして、{base} に PR を作成しますか？

承認された場合は、呼び出し元のフローで PR フェーズ用に定義されている同じテンプレート（概要、関連ドキュメントへのリンク、検証チェックリストなど。正確な本文の形式は、フロー内の SKILL.md を参照）を使ってタイトルと本文の下書きを作成します。下書きのタイトルと本文をユーザーに提示します。

PR のタイトルは Conventional Commits 形式のヘッダーです（type(scope): description。ルールはステップ 3 と同じです）。ここにあるリポジトリの大半は squash merge するため、タイトルが恒久的なコミットメッセージになります。ブランチに種類の異なるコミットが複数ある場合は、最初のコミットではなく、レビュー担当者が PR の主題と見なす変更の種類（通常は最後の、最も重要な変更）を選んでください。

公開リポジトリの内容チェック（本文の下書き作成前）

gh repo view {owner}/{repo} --json isPrivate -q .isPrivate を実行して、{base} のリポジトリが公開されているか確認します。チェックで公開と判定された場合、またはチェックを実行できない場合は、公開リポジトリとして扱ってください。デフォルトで非公開だと決めつけてはいけません。

リポジトリが公開されている場合、タイトル、本文、ブランチ名、コミットメッセージに次の内容を含めてはいけません。

• 人名、ハンドル名、イニシャル（報告者、レビュー担当者、社内の会話で引用された人など、誰のものも含みます）。
• 社内チャンネル（Slack など）の名前、またはそのチャンネルに関連する日付。
• 社内の会話（Slack、会議、DM）の直接引用またはそれに近い言い換え。

情報源を示さない表現（例：「社内で報告された」「実際の利用中に検出された」）を使い、技術的な内容、つまり何が壊れたのか、なぜなのか、何を変更したのか、どのように検証したのかは維持してください。

このチェックの対象は、PR の本文だけでなく、これから公開される差分全体です。 git diff {base}...{branch} --name-only を実行し、この PR で実際に追加または変更されるファイルをすべて確認してください。PR の本文、ブランチ名、コミットメッセージだけでなく、すべてのファイルが対象です。この PR で新たに追加または変更するドキュメント（BUG.md の Context、PRD の受付メモなど）に誰かの名前や社内スレッドが記載されている場合、そのドキュメントは PR のマージと同時に公開リポジトリへ反映されます。「ドキュメント自体に書かれているだけ」でも、ドキュメントが公開差分に含まれれば何も保護されません。PR の本文でその内容に触れないだけでなく、PR を作成する前にドキュメントをサニタイズし（名前、チャンネル、引用を削除し、PR の本文と同じように情報源を示さない形で表現し直し）てください。

誰かの名前を記載したドキュメントが以前の PR／コミットですでにリポジトリにコミットされており、この PR の差分では変更されない場合、ここでの対象外です。このチェックの対象は、この PR 自体が公開する内容であり、リポジトリの履歴全体を遡って監査することではありません。

リポジトリが非公開の場合、これらのルールは適用されません。通常どおり PR を作成してください。

ゲート — プッシュ／PR の確認

次のように伝えます。「{branch} をプッシュして PR を作成する直前です。{base} ← {branch}、タイトルは {title} です。プッシュして PR を作成する前に確認してください。」

停止してください。ユーザーの確認を得るまで、git push も gh pr create も実行してはいけません。

明示的な確認を得てから実行します。

git push -u origin {branch}
gh pr create --base {base} --head {branch} --title "{title}" --body "{body}"

作成された PR の URL をユーザーに伝えます。

ステップ 5 — 状態を更新（状態ファイルがある場合）

.ways/state.json が存在し、PR を作成した場合は、ステップ 4 ですでに確認された作業の一環として、該当する gates[].url に PR のリンクを設定します。これは実行済みの操作に関するメタデータであり、事前に告知していない新たな操作ではないため、個別のゲートは必要ありません。PR ゲートの状態を passed にすべき場合（例：外部でマージされ、ユーザーがここでは記録のみ行う場合）は、status も更新します。

---

行ってはいけないこと

• 別のスキルのワークフロー内から自動的に自分を呼び出さないでください。現在のターンでユーザーが明示的に依頼した場合にのみ実行します。
• 上記の明示的な確認手順を経ずに、コミット、プッシュ、PR の作成を行わないでください。ユーザーが直接このスキルを呼び出した場合も同様です。このスキルの呼び出しは会話の開始にすぎず、それ自体が確認にはなりません。
• 関連のない変更を、事前に伝えずに1つのコミットにまとめないでください。
• PR をマージしないでください。PR の作成は対象範囲内ですが、マージは常にこのスキルの対象外であり、ユーザーが明示的に別途行う操作です。