tk-pr-image について
tk-pr-imageは、既存のGitHubプルリクエストにローカル画像の証拠をアップロードするスキルです。画像とアップロード経路を検証し、指定されたPR本文またはコメントを更新して、Markdownと画像オブジェクトを確認します。
主な機能
- 01ローカル画像の証拠を検証
- 02GitHub添付ファイルのアップロード経路
- 03指定されたPR本文またはコメントの更新
- 04画像トークンとアップロード資産の検証
- 05アップロードとクリーンアップ結果の記録
活用シーン
- 01既存PRへの検証済みスクリーンショット追加
- 02変更前後の画像ペアの添付
- 03アップロード画像リンクとデータの到達性確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ mtgvim/ tiger-kit --skill tk-pr-imageインストール後、Claude Code で/tk-pr-imageを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
LICENSE.txtagents/openai.yamlreferences/artifact-paths.mdauthentication.mdcdp-fallback.mdgh-attach.mdquestions.md詳細
GitHub PR 画像アップロード
既存の GitHub PR に対する明示的なローカル画像証拠のリクエスト、または evidence_required: true を含む厳密な tk-pr-open 汎用マニフェストの引き継ぎに対応します。自動トリガーとなるのは親からの引き継ぎのみです。
範囲
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 として停止します。
ワークフロー
- 通常のローカル画像ファイルまたは有効なプロデューサー証拠の引き継ぎから、
origin、現在の PR、実行中のリポジトリを確認します。既存の PR 本文を読みます。 - 既存の
## 스크린샷見出しを再利用します。ない場合は、AI フッターの前に挿入するか、末尾に追加します。関係のない本文の内容は保持します。マニフェストのアーティファクトでは、指定された基準、役割、正確なdisplay_route、状態/地域、ビューポート、比較結果をキャプションに使用します。ファイル名、OCR、未加工の URL、プロデューサーの識別情報から推測してはいけません。visual-preservationのベースラインと変更後は、1 組として明確にラベル付けします。マニフェストの有無にかかわらず、各ペアには、検証済みのルート/画面を示すタイトル、期待される動作についての文を 1 つ、수정 전/수정 후などの役割ヘッダー、画像行 1 つ、その下に各画像の観察内容を記載するキャプション行を追加します。提供された証拠を引き継ぎ、ルート/画面の証拠が不足している場合は、捏造せずにその旨を明記します。ステージングファイル名は、ヘッダー、キャプション、または十分な説明にはなりません。 - gh-attach を使用して適格なルートを選択し、実行するか、CDP を選択した後にのみ CDP fallback を読みます。リポジトリの公開状態は、ルート選択の根拠にはなりません。リモート状態を作成した可能性のあるルートから、もう一方のルートに黙って切り替えてはいけません。
- 選択したルートで人間のみが行えるホスト操作が必要な場合は、範囲を限定した引き継ぎを
tk-wizardに渡し、完了シグナルを受け取るまでアップロードを行いません。エージェントが承認したレビュー済みの拡張機能のインストールは、この手順で行います。ウィザードの完了後、同じリポジトリ、対象、画像セット、ルートで再開します。 - GitHub API または同等の手段を通じて、リクエストされた本文またはコメントのみを更新します。
Passにする前に、対象を再度読み込み、生成されたすべての画像トークンがバイト単位で完全に一致してちょうど 1 回ずつ出現すること、ペアの役割/キャプションの対応が維持されていること、認証済みの取得によるデコード可能なimage/*バイトデータがすべてのアセットにあること、アップロード参照からリンクされたすべてのアップロードオブジェクトに到達できることを確認します。ブラウザーセッションでのレンダリング確認は任意です。確認の有無を受領記録に記載しますが、Passの前提条件にはしません。 - すべての終了経路で、自分が所有するステージングファイルのみを削除します。削除対象の各パスには、この実行中にすでに記録した、自分が所有するステージングパスのリテラルな完全解決済み絶対パスを指定します。コマンド置換、読み戻したパスファイル、または
headやtailにパイプしたグロブから削除対象を導出してはいけません。正確なリテラルパスが不明な場合は、候補を列挙して停止し、削除してはいけません。
実行受領記録 · 単一の証拠記録
すべてのアップロード試行を、以下の単一の受領記録に記録します。これは別個のライフサイクル出力ではありません。「## GitHub image 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に、検証済みのペアからベースラインと変更後の両方のアーティファクトが含まれていること。
任意のスクリーンショット、パスの欠落、Pass 以外の結果、未検査のアーティファクト、不完全な保持ペア、現在の実行に紐付いていないアーティファクトは拒否します。必須の証拠が不足または無効な場合は、アップロード前に Blocked を返します。
禁止事項
- ユーザーがコメント先を明示的に選択していない限り、PR を作成またはマージしたり、レビュアーを変更したり、リリースを公開したり、コメントを追加したりしないでください。
tk-browser-verifyを迂回したり、自動的なブラウザーのフォールバックとして Orca や画面操作を使用したりしないでください。- 既存の下書きを上書きしたり、コメント、コメント付きで閉じる操作、その他の送信ボタンをクリックしたりしないでください。
- 公開/非公開の可視性に基づいて経路を選択したり、プレースホルダー、Markdown の存在、固定の待機時間、または未レンダリングの API レスポンスだけを根拠に成功を主張したりしないでください。
- 署名付き URL、JWT、またはシークレットを含むクエリ文字列をログに記録したり返したりしないでください。これは、検証済みの安全な、オリジンを含まない
display_routeを禁止するものではありません。そのパス名、クエリ、フラグメントは、マニフェストに記載されたとおり正確に保持してください。 - 表示出力では、シークレットを含む値(署名付きパラメーター、JWT、トークン)のみをマスキングし、
raw=trueなどのレンダリング用パラメーターは保持してください。生成した各画像の Markdown トークンは、alt テキスト、URL、レンダリング用パラメーターを含めてバイト単位で変更せず保持してください。画像の下にキャプションを配置する場合は、周囲の表レイアウトを組み直してもかまいません。マスキングまたは要約した出力からリンクを再構築しないでください。シークレットを含む元の内容を、ログ、受領記録、証跡成果物にコピーしないでください。
失敗時の処理
拡張機能がない場合や、上流の選択が未確認の場合の選択、または人間のみが行える tk-wizard の完了シグナルを待っている間は、Pending を返してください。プロベナンスが unknown の場合、下書きの場合、または CDP 経路を選択せずにインストールが拒否された場合は、Blocked を返してください。認証、画像バイトの検証、またはアップロード参照への到達性を検証できない場合は、Unverifiable を返してください。レンダリング済みページの証跡は任意です。アップロード、リモート参照の検証、またはクリーンアップでエラーが発生した場合は、Fail を返してください。選択した本文/コメントが変更されたかどうか、またアップロード参照が残る可能性があるかどうかを明記してください。
tk-pr-open の場合は、PR 操作の結果と証跡の状態を分けて保持し、証跡の状態を uploaded または blocked として返してください。必須の証跡がブロックされたままの場合、親プロセスは完全な完了を主張できません。
結果
ターミナル応答は ## GitHub image upload で始めてください。該当する場合は、## Uploaded、## Verification、## Cleanup を含めてください。結果を所有するセクションの最後には、Status: Pass|Fail|Pending|Blocked|Unverifiable の行を厳密に 1 つだけ記載してください。安全な場合に限りアセット URL を提示し、署名付きパラメーターはマスキングしてください。
成果物のパス
このスキルのタスクで許可されている場合に限り、成果物を作成してください。成果物の書き込み、一時的なチェックアウト/転送、または ignore 設定を行う前に、成果物のパス を読み、Git の除外、安全なパス、所有権に関するチェックを適用してください。このコンテキスト内にある同一内容を再利用し、不確かなコピーはハッシュを確認してください。内容が変更または失われている場合は、再読み込みしてください。安全性は必ず改めて確認してください。リポジトリが所有する出力先は、デフォルトで .tigerkit/ にしてください。明示された最終出力先がある場合はそれに従ってください。会話のみの作業では、この参照の確認を省略し、ファイルや ignore の設定を行わないでください。成果物の取り扱い許可は、無関係な変更や公開を許可するものではありません。
読者向けの結果の要約
結果、実際に行った検証、重要な制約、直接利用できる成果物へのリンクを含む、簡潔な要約を返してください。計画や省略したチェックと、実際に実行した作業を区別してください。未完了の手動チェック、実際のクリーンアップ、ブロッカー、人手による対応の詳細を残してください。検証できていない完了やクリーンアップを主張しないでください。所有者が必須とする成果物、公開プレビュー、承認境界、マシン向けの返却内容、正確なステータス/フッター、最後の質問ブロックを保持してください。ネストされた返却内容は簡潔にし、空のセクションは省略してください。
出力形式
ASCII 数字の番号(1. Item、(1) Item)と - Item を使用し、囲み数字やキーキャップ数字は使わないでください。
例を含め、完全な絶対パスをクリック可能な形で示し、省略記号は使わないでください。
編集が許可されている場合を除き、コード、コマンド、識別子、URL、引用、確認済みの UI ラベルを正確に保持してください。
共通する属性が複数あるチャットの比較には、列数を抑えた GFM パイプテーブル(4 列程度、ヘッダー付き、セルの内容は簡潔)を使い、それ以外の場合はリストを使ってください。ボックス描画文字、コードフェンス、空のテーブルは使わないでください。担当者固有のプレビューを優先し、公開用本文とファイル成果物にはそれぞれのテーブル形式を維持してください。
レンダリングされる Markdown の文章では、範囲の表記にハイフンを使用し、文字としてのチルダは \~ とエスケープしてください。コード、引用、識別子は正確に保持してください。
許可された一時入力ファイルについては、作成および使用前に「Artifact Paths」に従ってください。あらかじめ入力されたテンプレートは、入力済みのファイルではありません。これは書き込み権限を付与するものではありません。
ユーザーからの質問
調査可能な事実を確認し、一致する許可を再利用してから質問してください。前提条件が満たされていない場合や、ユーザーが所有する重要な判断が必要な場合は、question rounds and recovery を参照してください(同じコンテキスト内にあれば再利用してください)。回答可能な判断事項だけを、承認とは分けて、通常のチャット形式で質問してください。それ以外の場合は、確認を求めずに続行してください。
スキルへのフィードバック
再利用できる事例については、機密情報を含まない最小限の証拠を残し、tk-retro を提案してください。起動、フィードバック成果物、インストール済みスキルの編集、公開には、それぞれ担当ワークフローを通じた個別の許可が必要です。この案内は許可を付与するものではありません。