tk-pr-media

GitHub PR メディアのアップロード

既存の GitHub PR に対する明示的なローカル画像／動画の証拠リクエスト、または evidence_required: true を含む正確な tk-pr-open 汎用マニフェスト引き継ぎに対応します。自動トリガーとなるのは、親からの引き継ぎのみです。

任意の動画補足

選択した MP4 については、ネイティブ動画添付を読みます。画像専用の拡張手順ではなく、固有のアップロード／バイト数／プレーヤーのチェックをそちらで行います。有効な任意の補足には、メディアタイプ、実行に紐づくパス、基準／ヘッド、再生時間／ビューポート、検査したフレーム、サンプリングに関する警告が含まれます。必須の画像マニフェストを装うよう求めてはいけません。publication_selected: true の場合、またはユーザーがその特定のアーティファクト／対象を明示的に選択した場合に限り、アップロードしてください。

選択した GIF のフレームを組み立てるには、レビュー済みの拡張機能を --gif、明示的な .gif 名、フレームシーケンスに一致する遅延時間とともに使用します。v0.7.0 では --json を使用せず、stderr を個別に取得してください。フレーム数上限／削減／サイズ超過に関するすべての警告を保持し、実際の image/gif バイト数と複数のデコード済みフレームを検証します。再生を主張する場合は、アニメーションを検査してください。5MiB は目標値であり、厳格な上限ではありません。サイズ超過とタイミングの変更を明示してください。既存の必須スクリーンショットの組み合わせは変更しません。

スコープ

範囲を限定したアップロードを 1 件処理します。ローカル画像を検証してステージングし、リポジトリに紐づく GitHub 添付ファイルをアップロードし、PR の本文または選択したコメントを最小限変更して、元の Markdown とアップロードした画像オブジェクトを検証します。既定の対象は PR の本文です。

tk-pr-open では、プロデューサーに依存しない証拠フィールドを検証し、生成元のスキル名で分岐したり、許可リストを作成したり、必須にしたりしてはいけません。必須の証拠が不足しているか無効な場合は、証拠の引き継ぎを Blocked とし、すでに作成済みの tk-pr-open PR を取り消してはいけません。

拡張機能経由のルートを分類して実行するには、references/gh-attach.md を使用します。references/cdp-fallback.md は、CDP が選択された後、または拡張機能経由のルートで対象への書き込み機能を使用できない場合に限り読みます。tk-wizard を呼び出すのは、人間による対応のみが必要なホストのセットアップ、認証、権限、再起動の手順が正確に特定されている場合に限ります。引き継ぎ後も、このスキルのアップロード対象とルートを維持してください。ブラウザー制御のランタイム検証には tk-browser-verify を使用します。

🔴 チェックポイント · 🛑 停止 · アップロード変更の境界

アップロードや PR 本文／コメントの更新を行う前に、明示的に選択された対象、有効なローカル証拠またはプロデューサーからの引き継ぎ、認証済みのルート、要求された書き込み範囲を再確認してください。これらの前提条件を確認できない場合は、Blocked または Unverifiable として停止してください。

ワークフロー

1. 通常のローカル画像ファイルまたは有効な作成者による証拠の引き継ぎを使って、origin、現在の PR、実行対象のリポジトリを確認します。既存の PR 本文を読みます。
2. 既存の ## 스크린샷 見出しを再利用します。ない場合は、AI フッターの前に挿入するか、末尾に追加します。関係のない本文は保持します。マニフェストのアーティファクトでは、キャプションに提供された基準、役割、正確な display_route、状態／地域、ビューポート、比較結果を使用します。ファイル名、OCR、未加工の URL、作成者の識別情報から推測してはいけません。visual-preservation の baseline と after は、1 組であることが明確にわかるようにラベルを付けます。すべての組について、マニフェストの有無にかかわらず、確認済みのルート／画面を示すタイトル、期待される動作を説明する文、수정 전／수정 후 のような役割ヘッダー、1 行の画像、各画像の観察結果を説明するキャプション行をその下に追加します。提供された証拠を引き継ぎます。ルート／画面の証拠が不足している場合は、作り上げずにその旨を明記します。ステージングファイル名は、ヘッダー、キャプション、または適切な説明の代わりにはなりません。
3. gh-attach を使って利用可能なルートを選択し、実行します。CDP が選択された場合に限り、CDP fallback を読みます。リポジトリの公開状態はルーティングの判断材料ではありません。また、リモートの状態を作成した可能性があるルートから、もう一方のルートへ黙って切り替えてはいけません。
4. 選択したルートで人間のみが実行できるホスト操作が必要な場合は、制約を明確にした引き継ぎを tk-wizard に渡し、完了シグナルを受け取るまでアップロードを行いません。エージェントが承認したレビュー済み拡張機能のインストールは、この工程で行います。ウィザードの完了後、同じリポジトリ、対象、画像セット、ルートで再開します。
5. GitHub API または同等の手段を使って、依頼された本文またはコメントのみを更新します。Pass とする前に対象を再読し、生成した各画像トークンがバイト単位で完全一致し、正確に 1 回ずつ出現すること、各組の役割とキャプションの対応が維持されていること、認証済みの取得で各アセットのデコード可能な image/* バイト列が得られること、アップロード参照からリンクされたすべてのアップロードオブジェクトに到達できることを確認します。ブラウザーセッションでのレンダリング確認は任意です。レシートには確認したかどうかを記録しますが、Pass の必須条件にはしません。
6. すべての終了経路で、自分が所有するステージングファイルのみを削除します。削除対象には、この実行中にすでに記録された、完全に解決済みの実行所有ステージングパスをリテラルで指定します。コマンド置換、読み戻したパスファイル、または head や tail にパイプした glob から削除対象を導出してはいけません。正確なリテラルパスが不明な場合は、候補を列挙して停止します。

実行レシート · 単一の証拠記録

すべてのアップロード試行を、以下の単一レシートに記録します。これは独立したライフサイクル出力ではなく、## GitHub media upload の結果と承認／検証の判断に使用する唯一の証拠記録です。値がない場合は none または unavailable を使用し、推測してはいけません。

Repository: <owner>/<repo>
PR / Target: <pr-number> / body | existing comment <comment-id>
Source images: <absolute path list>
Route: gh-attach | CDP
Entry: <exact reviewed command | browser route>
Generated Markdown: <asset refs | none>
Remote ref: <refs/uploads/issues/<pr-number> | none | unknown>
Verification: image-token byte match and single occurrence: <Pass | Fail | unavailable>; image bytes/type: <Pass | Fail | unavailable>; upload ref reachability: <Pass | Fail | unavailable>; rendering: <checked | not performed | unavailable>
Changed: <body/comment changed | unchanged | unknown>
Cleanup: <owned staging path removed | failed | not applicable>
Status: Pass | Fail | Pending | Blocked | Unverifiable

証拠マニフェストの引き継ぎ

evidence_required: true の場合、以下のすべてを必須とします。

• verification_status: Pass、空でない基準、証拠の種類、比較結果、制約事項。
• 各アーティファクトに、役割、空でない画像、絶対パス、実行所有の証拠ディレクトリ、状態／地域、ビューポートがあること。
• すべての画像が inspected: true としてマークされ、正確なオリジンなしの display_route、または明示的で安全な省略に関する制約事項があること。不足しているルートを再構成したり、マスクしたりしてはいけません。
• visual-preservation に、確認済みの組からの baseline アーティファクトと after アーティファクトの両方が含まれていること。

任意のスクリーンショット、パスの欠落、Pass 以外の結果、未確認のアーティファクト、不完全な preservation の組、現在の実行に紐付いていないアーティファクトは拒否します。必須の証拠が不足しているか無効な場合は、アップロード前に Blocked を返します。

禁止事項

• ユーザーがコメント先を明示的に選択していない限り、PR の作成や統合、レビュアーの変更、リリースの公開、コメントの投稿を行わないでください。
• tk-browser-verify を回避したり、自動的なブラウザーのフォールバックとして Orca や画面操作を使用したりしないでください。
• 既存の下書きを上書きしたり、コメント、コメント付きクローズ、その他の送信ボタンをクリックしたりしないでください。
• 公開／非公開の可視性に基づいて経路を選択したり、プレースホルダー、Markdown の存在、固定の待機時間、または未レンダリングの API レスポンスだけを根拠に成功を主張したりしないでください。
• 署名付き URL、JWT、生の秘密情報を含むクエリ文字列をログに記録したり返したりしないでください。これは、検証済みで安全な、オリジンを含まない display_route を禁止するものではありません。マニフェストで指定されたパス名、クエリ、フラグメントはそのまま保持してください。
• 表示する出力では、秘密情報を含む値（署名付きパラメーター、JWT、トークン）のみをマスキングし、raw=true などのレンダリングパラメーターは保持してください。生成された各画像 Markdown トークンは、代替テキスト、URL、レンダリングパラメーターを含め、バイト単位で完全にそのまま保持してください。画像の下にキャプションを配置する形で、周囲の表レイアウトを再構成してもかまいません。マスキングまたは要約した出力からリンクを再構築しないでください。秘密情報を含む元データをログ、受領記録、証跡アーティファクトにコピーしないでください。

失敗時の処理

拡張機能が存在しない場合、または上流の選択が未確認の場合の選択を待っている間、もしくは人間のみが完了できる tk-wizard の完了シグナルを待っている間は、Pending を返してください。来歴が unknown の場合、下書きの場合、または CDP 経路が選択されていないインストールが拒否された場合は、Blocked を返してください。認証、画像バイトの検証、またはアップロード参照への到達可能性を検証できない場合は、Unverifiable を返してください。アップロード、リモート参照の検証、またはクリーンアップでエラーが発生した場合は、Fail を返してください。選択された本文／コメントが変更されたかどうか、またアップロード参照が残っている可能性があるかどうかを明記してください。

tk-pr-open では、PR 操作の結果を個別に保持し、証跡の状態を uploaded または blocked として返してください。必須の証跡がブロックされたままの場合、親タスクは完了を全面的に主張できません。

結果

端末への応答は ## GitHub media upload で始めてください。該当する場合は ## Uploaded、## Verification、## Cleanup を含めてください。結果を確定するセクションの末尾は、Status: Pass|Fail|Pending|Blocked|Unverifiable の行ちょうど 1 行で終えてください。安全な場合に限りアセット URL を公開し、署名付きパラメーターはマスキングしてください。

アーティファクトのパス

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

読者向け結果の要約

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

出力表記

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

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

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

許可された一時入力ファイルについては、作成と使用の前に「成果物パス」に従ってください。あらかじめ入力済みのテンプレートは、完成した入力ではありません。これは書き込み権限を付与するものではありません。

ユーザーからの質問

事実を調査し、既存の許可を再利用してください。ユーザー自身の判断については 質問ラウンドを参照し、それ以外はそのまま進めてください。 チャットでの回答が1件だけの承認であっても、独立した --- の後に、 項目ごとに ❓ **Q<n> · <title>**: <question> と ➡️ <recommendation> を記載してください。 確定した前提に関する質問のみを行い、承認の確認とは分けてください。 質問は最後に記載し、その前にステータス、リスク、計画を記載してください。

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

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