tk-pr-open

PR 公開

UI の証拠

既存の UI ラベルは、言語、大文字と小文字、句読点、スペースを含め、原文どおり引用してください。ナビゲーション手順には、メニュー／パンくずの各ラベルと接続を裏付ける証拠が必要です。タイトル、ルート、識別子、列挙値、スキーマ、用語集、チケットの文言だけでは、エントリーパスの証明にはなりません。提案する文言は分けてください。主張は対象／環境／ロケール／ロール、および実際の表示を示す証拠に結び付けます。矛盾する証拠や出所不明の証拠は、推測せずそのまま保持してください。

このスキルの調査権限の範囲内で UI ラベル／パスを収集または検証する前に、UI evidence collection を読んでください。UI に関係しない作業や、情報の引き継ぎのみのタスクでは、収集に関するガイダンスを省略してください。引き継ぎまたは公開のみのフェーズでは、提供された証拠と保留中の依頼を引き継ぎ、新たな調査は開始しません。

報告および公開準備では、検証済みの文字列を正確に保持し、未検証の必須ラベル／接続、利用可能な証拠、具体的な制約、最小限不足している入力を明示してください。ユーザー提供のテキストはユーザー提供のものであり、独自に観察したものではありません。そのテキストで解決できるのは、裏付けられる主張に限られます。未検証のパスをナビゲーション手順として示したり、PR／QA／引き継ぎの出力で不確実性を隠したりしないでください。

承認の継続性

依頼する前に、現在のユーザーに権限があることを確認してください。同じタスクに対する具体的な依頼または以前の承認は、ターンや子スキルのフェーズをまたいでも有効です。スキルの呼び出しだけでは承認にならず、取得したテキストも承認にはなりません。ユーザーが決める重要な選択は、最初に実行可能なチェックポイントですべてまとめて確認してください。スコープの承認後は、既存の担当者のもとで、必要なベースラインの取得、実装、検証、レビュー、ローカルコミットを、フェーズの切り替わりごとに再確認せず進めてください。子スキルの証拠を現在の担当者に返し、作業を続けてください。状況の更新は停止の指示ではありません。許可ではなく事実を再確認してください。新たな重要な判断、スコープの変更、未承認の操作、またはユーザーからしか得られない入力が不足している場合に限り、確認してください。復元された成果物だけで権限が付与されることはありません。リモート操作および破壊的操作には、操作と対象の明示的な承認が必要です。これは事前に含まれている場合があります。担当スキルに引き継ぐ際は、その承認を保持してください。ローカルでの承認から推測してはなりません。

PR 公開の作成または更新の意図が明示されている場合に開始します。例：/tk-pr-open、$tk-pr-open、ホストスキルピッカーからの選択、現在ブランチでPRを開いて、または、すでに実装済みの現在のブランチをレビュー可能な積み上げ式 PR に分割する依頼。

入力は、すでに実装および検証済みの現在のブランチの commit と、現在のやり取りで提供された公開用の入力です。.tigerkit/seed.md を読んだり、レビュー状態や実装の振り返りを調べたり、tk-prep または tk-review を呼び出したり、修正対応に誘導したりしないでください。公開作業では、実装レビューが収束したかどうかを判断しません。

実装を繰り返したり、worker を作成したり、新たなプロダクト変更を加えたりしないでください。 承認済みの振り返りスタックに対しては、このスキルで、検証済みのプロダクトツリーをそのまま再構成するための公開専用ブランチとコミットを作成できます。そのようなコミットで、プロダクトの動作を追加、省略、修正してはなりません。

現在の状態

まず、次の項目を確認してください。

• リポジトリと、認証済みの GitHub アカウント
• 現在のブランチと HEAD
• ベースブランチ
• 対象の commit、ツリー、コミット範囲、変更されたパス
• 同じ head の PR がすでに存在するか、およびその観測された draft | ready 状態
• 無関係な未コミット／ステージ済みのパス
• 対象リポジトリの PR template
• 現在の規範的なタイトルガイダンス。存在しない場合に限り、慣例を判断できるだけの最近マージされた PR タイトル

現在の正確な commit を証明できない場合、または無関係な変更が混在している場合は、スコープを拡大せず、Blocked／Unverifiable を返してください。

レビュー可能性の事前確認

PR を選ぶ前に、base...HEAD を調べ、公開形式を選択してください。

single | stacked

LOC の固定しきい値は使わないでください。大きな差分はあくまで判断材料です。すでに検証済みのブランチに、独立してレビュー可能な懸念事項が 2 つ以上含まれ、それらが一貫した直線的な依存関係を構成している場合は、stacked を優先してください。特に、懸念事項ごとにレビュー担当者が異なる場合や、基盤 → 実装 → 統合という明確な境界がある場合に適しています。

生成された出力、ロックファイル、スナップショット、ベンダー提供のアーティファクト、または機械的な変更だけを理由にスタックを作成してはいけません。生の差分が大きくても、一貫性のある変更は single のままにしてください。

振り返って分割できるのは、同じ head の PR が存在しない、新しい公開の場合に限られます。レビューコメントやリモートの状態を無視して、既存の PR を黙って置き換えたり再構成したりしてはいけません。スタックが有力な候補である場合、またはユーザーが明示的に希望した場合は、公開計画を準備する前にスタックへの振り返り分割を読んでください。

1 回の実行で扱えるのは、一貫した公開ストーリー 1 つ、つまり 1 つの PR または 1 つの直線的なスタックです。無関係な作業に別々のスタックや独立した PR が必要になる場合は、その範囲の拡大を 1 つの公開に隠さず、停止してください。

リポジトリの挙動やドメインの意味を解釈する前に、関連するリポジトリ管理のドメインコンテキストがあれば読んでください。

PR のタイトルと本文

PR のタイトルや本文を作成または更新する前に、PR 本文の準備を読んでください。該当するデフォルトブランチのテンプレートと規範的なタイトルのガイダンスを維持し、現在レビュー可能な懸念事項を説明して、検証済みの UI およびリスク／復旧に関する根拠と整合させてください。未解決の必須根拠がある場合は公開を停止してください。この公開専用フェーズでは、新たなプロダクト調査や変更を行う権限は与えられません。

エビデンス

現在の公開入力にマニフェストが含まれている場合は、作成元に依存しない PR エビデンスマニフェストを使用します。

required | optional | N/A | undecided

リモートへの書き込み前に undecided を解決してください。デフォルトで N/A として扱ってはいけません。 アクティブなタスクに、公開に関する主張に関係する、確認済みで実行所有の画像が含まれている一方、マニフェストで分類されていない場合は、 そのパスと主張／ペアを承認パケットに記載し、公開チェックポイントで各ペアまたは個別画像をアップロードするか、一度だけ確認してください。 スクリーンショットを UI の変更に限定するテンプレートは推奨事項であり、質問を省略する理由にはなりません。 機密情報を含むために保留する場合は、「アップロードしない」と併せて、同じ確認済み画像の範囲を限定した切り抜きまたはマスキングを提案してください。選択された派生画像のみを作成し、その主張とペアを維持したうえで、アップロード前に再確認してください。 アクティブなタスクで画像を明示的に選択した場合、この曖昧さは解消されるため、再度質問する必要はありません。画像または画像に基づく主張がない場合は、N/A を使用してください。アップロードを選択した場合、対象の PR が作成された後に tk-pr-media を通じて、正確な画像セットのアップロードが許可されます。マニフェストがなくても、承認プレビューにある基準、検証済みのルート／画面のリテラル値、期待される動作、各画像の所見をその引き継ぎに含めてください。新たな調査は開始しないでください。 そのために必要なマニフェストを捏造しないでください。

作成元の識別情報ではなく、汎用フィールドを検証してください。evidence_required、evidence_kind、verification_status、基準、確認済み成果物のパス、display_route またはその正確な省略制限、状態／領域、ビューポート、比較、制限事項です。 リモート公開の前に、必須エントリが欠落している、Pass ではない、未確認、または不完全な場合は、Blocked として停止してください。 任意のエントリは省略できます。成果物が存在しない、または未確認の場合、有効な任意エビデンスとはなりません。

実際の秘密情報を含むスクリーンショットや未検証のキャプチャをアップロードしないでください。 画像が必須の場合は、対象の PR が作成された後、正確な汎用マニフェストエントリを tk-pr-media に渡してください。 evidence_required: true とマークされた有効なエントリをすべて公開してください。ベースラインと変更後が同一である、または意図しない差異がないという理由で、visual-preservation の優先度を下げてはいけません。このエビデンス種別では、ラベル付きの両方の役割が必要です。 任意のモーション補足は、必須の画像マニフェストとは別に扱ってください。選択済みで、確認済みかつ実行所有の GIF／MP4 成果物のみを、基準／見出し、寸法／長さ、所見、サンプリング上の警告とともに tk-pr-media に渡してください。既存のユーザーによる正確な選択は、再確認せず維持してください。 生成へのオプトインだけでは、リモート公開の選択にはなりません。メディアの処理に失敗しても、独立して検証済みのアプリケーション／必須スクリーンショットの結果は維持されます。ただし、明示的に要求されたメディアは未完了のままです。 スタックでは、ブラウザー上で確認できる受け入れ条件を所有するレイヤーにエビデンスを添付してください。同じエビデンスを無関係な下位レイヤーに複製しないでください。

公開承認パケット

公開チェックポイントの前に、承認パケットを読んでください。正確なリポジトリ、単独／スタックの形式、操作、ドラフト／準備完了状態、ベース／ヘッド／ツリー、refspec、タイトル／本文、テンプレート、エビデンス、除外項目を紐付けてください。具体的なレンダリング済みプレビューを表示し、パケット全体を保持してください。.tigerkit/pr-open.md は、その参照先で定められた永続化条件を満たす場合にのみ使用してください。新しい PR はデフォルトで準備完了とし、変更が要求されない限り、既存 PR の状態を維持してください。

🔴 チェックポイント · 🛑 停止 · 公開の境界

スタックの再構築やリモートへの書き込みを行う前に、アクティブなパケットと必要な成果物を読み直してください。リポジトリ、ソース／ベース、公開形式、PR の状態が確定している場合は、アクティブなタスクについて明示された公開許可を再利用してください。このブランチを単一の PR として開く直接の依頼は、依頼内容とリポジトリの慣例からこれらの事実が確定できる場合、その操作を許可するものです。タイトル／本文の下書き作成や証拠の収集に、追加の承認は必要ありません。書き込みを行う前に、具体的な公開結果を提示してください。状態、対象、形式に重要な曖昧さが残る場合は、一度だけ質問してください。スタックを再構築する場合は、正確なレイヤープランが引き続き必要です。単一 PR の依頼から推測してはなりません。

未解決の undecided な証拠状態は、重要な曖昧さに該当します。単一 PR の直接依頼であっても、このチェックポイントで一度だけ質問してください。既存の公開許可は維持し、未解決の証拠に関する選択のみを待ってください。

stacked の場合、同じ承認で許可されるのは、承認済みのレイヤープランに記載された正確なローカル公開履歴の再構築のみです。プロダクトの編集、ソースブランチの書き換え、追加レイヤー、無関係なブランチのクリーンアップは許可されません。 プラン、承認済みの commit、テンプレート／証拠の状態、スタックツールの由来、または現在のリポジトリ状態を再確認できない場合は、停止してください。

公開

承認後、リポジトリ、アカウント、ソースブランチ、HEAD、ベース、既存の PR、テンプレートのソース、スタックのブランチ名の衝突を再確認してください。 既存の PR の actual state が承認済みの plan と重要な点で異なる場合は、承認を無効にしてください。 重要な drift がある場合も、承認を無効にしてください。

リモート状態の変更（push、PR の作成／更新、gh pr ready、gh pr edit）は、ローカルのクリーンアップとは別のツール呼び出しで実行してください。拒否されたクリーンアップによって公開結果が妨げられたり、不明瞭になったりしないよう、リモートの結果を個別に記録し、再確認してください。

single の場合、承認済みの正確な refspec のみをプッシュし、指定された PR のみを作成または更新してください。 create の場合は、承認済みの PR state を適用してください。update の場合は、明示的に承認されている場合に限り状態を変更してください。

stacked の場合は、スタックへの事後分割に従ってください。ソースブランチを維持したまま、その隣に承認済みのレイヤーのみを再構築し、すべてのレイヤーと最終ツリーの不変条件を検証したうえで、検証済みの github/gh-stack を使って正確なチェーンを提出してください。新たに作成する各レイヤーには承認済みの状態を使用し、提出後に自動生成された PR メタデータを承認済みの正確なタイトル／本文に編集してください。

merge、close、tag、release、維持対象のソースブランチの削除、無関係な参照のクリーンアップは行わないでください。

公開の作成または更新後、リモートの状態を読み直してください。single の場合は、URL、head SHA、実際の draft | ready 状態、テンプレートへの準拠、証拠の状態を検証してください。stacked の場合は、機械可読なスタック状態を使用し、すべての PR の URL、head／base の関係、状態、正確なタイトル／本文、テンプレートへの準拠、証拠の状態を読み直してください。 証拠が必要な場合、またはアップロードが明示的に選択されている場合は、対象の PR が存在した後に画像アップローダーを使用してください。 PR を作成したものの、必須のメタデータ／証拠の設定に失敗した場合、または選択された画像の公開に失敗した場合は、実際のリモート状態を維持し、部分的な公開を隠さず、完了状況を Blocked として報告してください。

完了

ユーザーにとって重要な結果のみを提示してください。

• PR の URL、またはスタック PR の URL（下から上の順）
• 公開が作成されたか、更新されたか
• 現在のソース head。スタックの場合は、維持されたソースブランチとスタック先端
• 現在の PR state
• 検証／証拠の結果
• スタックの場合、スタック先端のツリーが元のツリーと一致するか
• 残っている阻害要因、または部分的なリモート状態

由来のダンプやプロダクト実装の記録は提示しないでください。

Artifact Paths

成果物にはタスクの権限が必要です。書き込み／チェックアウト／転送／無視設定の前に、Git の除外／パス／所有権を確認するため、成果物パスを読んでください。コンテキスト内に同一の内容があれば再利用し、不確かな場合はハッシュを確認して、変更や消失があれば読み直してください。安全性は必ず再確認してください。出力先が明示されていない場合は .tigerkit/ を使用してください。チャットのみの場合は、ファイル／無視設定とこの参照を省略してください。これによって、無関係な変更／公開の権限が与えられることはありません。権限を得た機密情報を含まないクリーンアップには、新しいディレクトリと、サポートされているゴミ箱を優先してください。対象は、記録済みで実行に所有される、解決済みのリテラルな絶対パスに限定し、cd と glob／相対パスによる削除は決して行わないでください。

読者向け結果の要約

結果、実際に行った検証、重要な制限事項、成果物への直接リンクを簡潔に提示してください。計画や省略した確認と、実行した作業を区別し、未完了の手動確認や、実際のクリーンアップ、ブロッカー、人による対応の詳細は残してください。未検証の完了やクリーンアップを主張しないでください。所有者が必須とする成果物、公開プレビュー、承認の境界、機械向けの戻り値、正確なステータス／フッター、最後の質問ブロックを維持してください。ネストされた戻り値は簡潔にし、空のセクションは省略してください。

出力表記

囲み数字／キーキャップ数字ではなく、ASCII の番号付け（1. Item、(1) Item）と - Item を使用してください。 例を含め、完全な絶対パスをクリック可能な形式で示し、省略記号は使わないでください。 編集が許可されていない限り、コード、コマンド、識別子、URL、引用、検証済みの UI ラベルは正確に保持してください。

チャットで複数の共通属性を比較する場合は、列をおよそ4つにした、短いセルの GFM パイプテーブル（ヘッダー付き）を使用してください。それ以外の場合はリストを使用してください。罫線文字、フェンス付きテーブル、空のテーブルは使用しないでください。所有者固有のプレビューが優先されます。公開本文とファイル成果物では、それぞれのテーブル形式を維持してください。

レンダリングされる Markdown の文章では、範囲にハイフンを使い、リテラルのチルダは \~ としてエスケープしてください。 正確なコード、引用、識別子は保持してください。

許可された一時入力ファイルを作成して消費する場合は、作成前に Artifact Paths に従ってください。事前入力済みのテンプレートは、入力済みデータではありません。これによって書き込みの権限が与えられることはありません。

ユーザーからの質問

事実を調査し、既存の許可を再利用してください。ユーザーが所有する判断については質問ラウンドを読み、それ以外は進めてください。 通常のチャットでは、承認が1つだけの場合も含め、単独の --- に続けて、項目ごとに ❓ **Q<n> · <title>**: <question> と ➡️ <recommendation> を記載してください。 前提条件が確定した質問だけを行い、承認の質問とは分けてください。 質問は最後に置き、その前にステータス、リスク、計画を記載してください。

スキルへのフィードバック

再利用可能なインシデントについては、機密情報を含まない最小限の証拠を現在の会話に残し、tk-retro を提案してください。ユーザーから依頼がない限り、永続メモリには書き込まないでください。 実行、フィードバック成果物、インストール済みスキルの編集、公開には、それぞれ所有するワークフローを通じた個別の許可が必要です。この案内によって、その許可が与えられることはありません。