hand-over-to-kiro

このスキルは、ファイルを変更する可能性のある外部 CLI（`kiro-cli`）を実行します。以下のルールは必ず守ってください。 1. `kiro-cli`を自動インストールしたり、リモートインストーラーをシェルにパイプしたりしないでください。見つからない場合は、公式インストール手順を案内して停止してください。インストールはユーザー自身が行います。 2. ユーザーの生の入力をシェルコマンドに直接埋め込まないでください。Write ツールを使ってプロンプトをファイルに書き込み（リテラルなバイト列で記述し、シェル、ヒアドキュメント、`mktemp`は使いません）、そのファイルを`helpers/run-kiro.sh`に渡してください。ユーザーの入力を言い換える（ルール3）ことで、これがインジェクション対策になります。プロンプトのテキストがシェルによって解析されることはありません。 3. ユーザーの依頼を、XML形式の境界タグ（``、``など）を使った構造化タスクの説明に言い換えてください。ユーザーの生の入力をそのまま渡さないでください。間接的なプロンプトインジェクションの対象範囲を減らせます。 4. 実際の作業には、信頼フラグが必須です（`--no-interactive`ではツールを承認するプロンプトが表示されません）。`helpers/run-kiro.sh`を使い、タスクに応じて適切な範囲に制限してください。`review`では読み取り専用（`fs_read,execute_bash`）、`implement`では最小権限での書き込み（`fs_read,fs_write,execute_bash`）を許可します。`--trust-all-tools`を既定で使用してはいけません。これは既定で安全ではなく、自動モード分類機能によって（読み取り専用タスクでは常に）ブロックされます。このオプションは`--mode autonomous`専用です。その場合はユーザーが事前に許可する必要があります（`kiro-cli`のBash許可ルール）。無人実行であることは、このオプションを使う理由にはなりません。`implement`ではすでに編集が行われるためです。 5. Kiroはこの会話を記憶していません。プロンプトは自己完結型にしてください。 6. 報告する前に、ディスク上で変更内容を確認してください。実行前のベースラインと`git diff --stat HEAD`および`git status --short`を比較してください（Kiroがコミットした場合は`git log ..HEAD`も確認します）。`git diff`単独では、ステージ済みまたはコミット済みの変更を検出できません。部分的な完了やエラーも含め、正直に報告してください。

Kiroに引き継ぐ

入力

• $request：Kiroに引き継ぐタスクまたは計画です。すでに計画が有効な場合（計画モードまたはユーザーが提示した計画）は、ダイレクトモードではなく計画モードを優先してください。

目標

kiro-cliに実装を適切に委任します。Kiroに必要なコンテキストを集め、自己完結型でインジェクション対策を施したプロンプトを作成し、Kiroを実行して結果を取得・検証し、変更内容を正確に報告します。

ステップ0：kiro-cliが利用可能か確認する

最初に確認します。

kiro-cli --version

kiro-cliがインストールされていない、または認証されていない場合は、そこで停止してユーザーに伝えてください（自分でインストールしてはいけません）。

• 公式ドキュメントからインストールしてください：https://kiro.dev/docs/cli
• 認証してください：kiro-cli login
• モデルを一覧表示します：kiro-cli chat --list-models。必要に応じて、kiro-cli settings chat.defaultModel <model>でモデルを設定できます（ユーザーが自分の設定を管理します）。

成功基準：kiro-cliがインストール済みかつ認証済みであること。または、セットアップ方法をユーザーに案内し、このスキルを停止すること。

ステップ1：モードを決定する

モード	条件	渡す内容
計画	有効な計画がある（計画モードまたはユーザー提供）	手順を含む計画全体
ダイレクト	計画がない	ユーザーの依頼と関連するコンテキスト

成功基準：モードが選択され、参照元の資料（計画または依頼）が特定されていること。

ステップ2：コンテキストを集める

Kiroは新しい状態で開始するため、必要な情報をすべて集めます。

• タスクの範囲 — 実行する内容（計画の手順または言い換えた依頼）
• 関連ファイル — Kiroが読み取りまたは変更するファイルのパスと、それぞれの簡単な理由
• 制約 — 会話で示されたフレームワーク、コーディングスタイル、テスト要件、プロジェクトのルール
• 現在の状態 — 作業ディレクトリ、ブランチ、進行中の変更

成功基準：この会話を知らない新しいエージェントでもタスクを実装できるだけのコンテキストが集まっていること。

Step 2.5: kiro が従うスキルを特定する

kiro には .kiro/skills/<name>/ に独自のスキルがありますが、それらを呼び出す Skill ツールはありません。また、--no-interactive による単発の実行では、自動有効化に頼ることもできません。そのため、タスクに必要なスキルを指定し、Step 4 でそれぞれをヘルパーに渡します。ヘルパーは .kiro/skills/<name>/SKILL.md を解決し、本文を kiro のプロンプトに決定的に挿入します（自分でインライン化する必要はありません）。

• タスクのスタックスキル：/nextjs / /laravel / /rust のリファレンス → --skill nextjs / --skill laravel / --skill rust（先頭の / を取り除きます）。
• そのほか、タスクに必要なスキル（例：--skill bugfix）。
• kiro にインストールされていない名前は警告のうえスキップされます。処理がブロックされることはありません。

（kiro のネイティブな仕組みについては references/kiro-cli.md → Skills を参照してください。）

成功条件：関連するスキル名が特定され、Step 4 で --skill <name> として渡せる状態になっていること。

Step 3: プロンプトを作成する（インジェクション対策）

指示とユーザー提供のコンテンツを分離する XML 形式の境界タグを使い、明確で自己完結したプロンプトを作成します。

Plan モード：

Implement the following plan in the current working directory.

<plan>
{full plan text with numbered steps}
</plan>

<key-files>
- {path}: {why this file matters}
</key-files>

<constraints>
- {constraint — e.g., "Use TypeScript strict mode"}
- {constraint — e.g., "All new functions need unit tests"}
</constraints>

<context>
- Working directory: {pwd}
- Branch: {branch if relevant}
</context>

Direct モード：

Execute the following task in the current working directory.

<task>
{user's task — rephrased for clarity, NOT raw user input}
</task>

<key-files>
- {path}: {why this file matters}
</key-files>

<constraints>
- {constraint}
</constraints>

<context>
- Working directory: {pwd}
</context>

ルール：ユーザーの入力を明確なタスクに言い換えます。境界タグを使います。要点を抽出し、会話全体をそのまま詰め込まず、焦点を絞ります。

成功条件：焦点が絞られ、自己完結し、タグで区切られたプロンプトであり、生のユーザー入力が含まれていないこと。

Step 4: 実行する

タスクに応じてモードを選びます。review（読み取り専用。「review / audit / analyze / explain」など。編集なし）または implement（kiro がファイルを作成または編集する必要がある場合）です。その後、ヘルパーに引き継ぎます。mktemp やヒアドキュメントを使って手動で処理したり、フラグを信頼したりしないでください（以前の問題の原因です）。

1. Write ツールでプロンプトをファイルに書き込みます（リテラルなバイト列を使用します。シェル、ヒアドキュメント、mktemp は使いません。エスケープの不具合や BSD-mktemp の .txt 接尾辞に関する落とし穴を避けるためです）。絶対パスを使い、例として /tmp/kiro-handover-prompt.txt のように指定し、実行のたびに新しいファイルを作成します。
2. ヘルパーを実行します。Step 2.5 の各スキルについて、--skill <name> を繰り返し指定します。ヘルパーはスキルを解決して挿入し、プロンプトが空でないことを検証し、モードに応じて信頼範囲を設定し、git のベースラインを記録してから kiro を起動します。

bash <skill-dir>/helpers/run-kiro.sh --mode implement --skill nextjs --prompt-file /tmp/kiro-handover-prompt.txt

複雑なタスクでは、Bash のタイムアウトを 600000 ms（10 分）に設定します。ヘルパーが "prompt file is EMPTY" というメッセージとともにゼロ以外で終了した場合は、Write の処理が反映されていません。プロンプトを書き直して再試行してください。空のプロンプトで kiro を再実行しないでください。

ツールの信頼ポリシー（ヘルパーが適用します。信頼フラグを手動で設定しないでください）。

モード	信頼	用途
review	--trust-tools=fs_read,execute_bash	読み取り専用：kiro はファイルを読み取り、grep / find / git を実行します。fs_write は使用しません。自動モードの分類器は、変更を伴わないタスクで --trust-all-tools をブロックするため、review では必ず読み取り専用に範囲を限定します。
implement	--trust-tools=fs_read,fs_write,execute_bash	ファイルを編集できる範囲で最小限の権限を付与します。
autonomous	--trust-all-tools	デフォルトでは安全ではなく、明示的なオプトインが必要です。ハーネスで kiro-cli の Bash 許可ルールが必要になる場合があります。実行が無人だからという理由だけで選択しないでください。implement でもファイルを編集できます。

特定のエージェントとして実行する場合（任意）。 --agent <name> を指定すると、kiro をカスタムエージェント（.kiro/agents/<name>.json）として実行できます。--model <name> はモデルを上書きします。エージェントの JSON は kiro ネイティブである必要があります。有効な model（references/kiro-cli.md → Models を参照）と、ネイティブの tools（fs_read / fs_write / execute_bash / @<mcp>）を指定してください。Claude の名前（Read / Write / Skill）を使うと、エージェントは機能するツールを持てず（検証済み：何も書き込みません）、動作しません。--model auto を指定すると、無効なモデルが固定されているエージェントを救済できます。エージェントにかかわらず、--skill は規約を挿入します。

成功条件：プロンプトファイルが空ではなく、適切に範囲を限定した信頼設定でヘルパーが kiro を起動し、kiro が実際のプロンプトに基づいて実行されたこと。

成功条件：kiro-cli が一時ファイル内のプロンプトを使って実行され、その出力が取得されていること。

ステップ 5：処理と報告

kiro-cli の処理が完了したら、次の手順を行います。

1. 出力を解析する — 作成・変更されたファイル、エラー、警告、完了状況を確認します。
2. 変更を検証する — 実行前にベースライン（git rev-parse HEAD、 git status --porcelain）を記録し、その後 git diff --stat HEAD（ステージ済み＋未ステージ）、 git status --short（未追跡ファイル）、kiro がコミットした場合は git log <baseline>..HEAD --stat で確認します。 git diff だけではステージ済み・コミット済みの作業を見落とします。kiro が最も多く作業したのは、まさにその場合です。
3. 報告する：変更されたファイルと実施内容、エラーや警告、Plan モードの場合は完了した手順と 残っている手順、未完了の場合は次に推奨する手順を報告します。

成功基準：ユーザーが、kiro が変更した内容、失敗した内容、残っている作業を、kiro の自己申告だけでなく、 実際の差分に照らして検証したうえで正確に確認できること。

エラー処理

エラー	対応
kiro-cli: command not found	https://kiro.dev/docs/cli からインストールするようユーザーに伝えます（自分ではインストールしないでください）
認証エラー	kiro-cli login を実行するようユーザーに伝えます
モデルを利用できない	kiro-cli chat --list-models で確認し、kiro-cli settings chat.defaultModel <model> でモデルを設定するようユーザーに伝えます
タイムアウト（10 分）	途中までの出力を表示し、どのように進めるかユーザーに尋ねます
終了コードが 0 以外	エラー出力を表示し、再試行する前に根本原因を診断します
MCP サーバーの起動失敗	MCP ツールが必要な場合は --require-mcp-startup を追加し、不要な場合はスキップします

ガードレール

• kiro-cli をインストールしたり、curl … | bash 形式のインストーラーを実行したりしないでください。インストールするのはユーザーだけです。
• ユーザーの入力をそのまま kiro-cli に渡さないでください。必ず言い換え、heredoc と境界タグのパターンを使用します。
• プロンプトの受け渡し、信頼設定、起動は helpers/run-kiro.sh に任せてください。--trust-all-tools、 mktemp、heredoc を手作業で組み立ててはいけません（それが失敗の原因でした）。タスクに必要な最小限の信頼レベルを既定で使用します（review は読み取り専用、implement は書き込み）。--trust-all-tools（autonomous）は、事前に許可されたオプトインの場合に限ります。
• Write ツールでプロンプトを書き込みます（実行ごとに新しいファイルを使用）。ヘルパーはプロンプトが空の場合、起動を拒否します。書き込み漏れがあれば、kiro を何も渡さずに実行するのではなく、明確に失敗します。
• kiro の申告だけで成功と報告しないでください。ベースラインとの差分（git diff --stat HEAD と git status --short、コミット済みの場合は git log <baseline>..HEAD）を照合して検証します。
• CLI の全リファレンスは、本文に記載せず references/kiro-cli.md に置きます。

リファレンスを読み込むタイミング

• references/kiro-cli.md Kiro CLI の全コマンドリファレンス（chat、settings、agent、mcp、auth、diagnostics、環境変数）。

出力の要件

次の内容を報告します。

1. 使用したモード（plan / direct）と kiro-cli が利用可能だったかどうか
2. kiro が変更したファイル（実行前のベースラインと照合して検証。git diff --stat HEAD と git status --short、コミット済みの場合は git log <baseline>..HEAD を使用）
3. kiro の出力に含まれるエラーや警告
4. 完了状況 — 完了、または残っている手順・作業
5. 未完了の場合に推奨する次の手順

クレジット

オリジナルのスキル hand-over-to-kiro は Sabeur Thabti（@thabti）によるものです — https://github.com/thabti/hand-over-to-kiro（MIT。LICENSE を参照）。謝意を表しつつ、@ulpi/skills の規約 （frontmatter、<EXTREMELY-IMPORTANT> ガードレール、段階的な手順、セキュリティルールとの整合性）に合わせて調整しました。