kiro-review

このスキルは外部レビュー担当者を連携させるため、規律を保つ必要があります。

譲れないルール：

1. Kiro のプロンプトを書く前に、実際の差分を読みます。
2. 変更箇所と想定されるリスクに合わせて、具体的なプロンプトを作成します。
3. プロンプトに秘密情報や認証情報を含めてはいけません。
4. 後続のラウンドでも除外リストを引き継ぎます。
5. 返された指摘は、対応する前に検証します。
6. レビューは読み取り専用です。helpers/run-kiro.sh --mode review（スコープ付き信頼設定 fs_read,execute_bash）で kiro を起動してください。--trust-all-tools / -a は絶対に使用しないでください。自動モードの分類器は、変更を伴わないタスクで無制限の信頼設定をブロックするため、すべてのツールを許可すると行き詰まります。

Kiro レビュー

入力

• $request：last commit、uncommitted、auth focus、round 2 などの任意のスコープヒント

目的

kiro-cli を使用し、次の条件を満たす外部レビューを受けます。

• 適切な差分スコープを使用する
• 実際の変更箇所に焦点を当てる
• 一般的なコメントではなく、構造化された指摘を返す

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

確認項目：

• which kiro-cli
• kiro-cli whoami、またはこの環境で必要な最小限の認証確認

CLI を利用できない場合、または認証されていない場合は、障害の内容を説明して終了します。

成功条件：現在のリポジトリから Kiro を正常に実行できること。

ステップ 1：レビュー範囲を決める

次のどれをレビューするかを判断します。

• ブランチ全体
• 未コミットの変更
• 特定のコミット

まず差分の概要と変更ファイル一覧を読みます。

レビュー対象がない場合は、終了してその旨を明確に伝えます。

成功条件：レビュー対象が明確で、実際の差分に基づいていること。

ステップ 2：焦点を絞った Kiro プロンプトを作成する

次の内容を含む、簡潔なプロンプトを作成します。

• 変更内容
• 主なリスク領域
• 後続のラウンドで除外する、以前に修正済みの問題
• 指摘を実際のコードと照らし合わせて検証するよう指示すること
• 簡潔で構造化された出力形式
• kiro 用のスタック／規約スキルがインストールされている場合（.kiro/skills/<name>/）、その規約に基づいて kiro にレビューさせるため、--skill <name> を指定してヘルパーに渡します。kiro にはスキルを読み込むための Skill ツールがなく、--no-interactive を使用したワンショット実行では自動有効化に頼れません。

一般的なプロンプトは避けてください。質の低い結果につながります。

成功条件：再利用可能な定型文ではなく、変更内容に特化したプロンプトであること。

ステップ 3：ヘルパーを使って読み取り専用で Kiro を実行する

kiro のコマンドを独自に組み立ててはいけません（mktemp／heredoc／信頼設定フラグは以前に問題を起こしています）。代わりに：

1. Write ツールでプロンプトをファイルに書き込みます（リテラルのバイト列。シェル、heredoc、mktemp は使用しません）。 /tmp/kiro-review-prompt.txt などの絶対パスを使用し、ラウンドごとに新しいファイルを書き込みます。
2. レビュー モードでヘルパーを実行します。

bash <skill-dir>/helpers/run-kiro.sh --mode review [--skill <name>]... [--agent <reviewer> --model auto] --prompt-file /tmp/kiro-review-prompt.txt 2>&1

任意：--agent <name> を指定すると、kiro を kiro ネイティブのレビュアーエージェントとして実行します（有効な model とネイティブの fs_read / execute_bash ツールを備えた .kiro/agents/<name>.json。モデル一覧は kiro-cli chat --list-models で確認できます）。エージェントに無効なモデルが固定されている場合は、--model auto で上書きします。

--mode review は、信頼設定を**--trust-tools=fs_read,execute_bashに制限します。kiro はファイルを読み取り、grep／find／git を実行して指摘をソースと照らし合わせて検証できますが、書き込み権限はありません**。--trust-all-tools / -a は使用しないでください。レビューは読み取り専用であり、自動モードの分類器は変更を伴わないタスクで無制限の信頼設定をブロックします。ヘルパーはプロンプトを kiro の標準入力に渡し、プロンプトが空の場合は起動を拒否して、git のベースラインを取得します。

モデル — --model <name> を指定します。有効な値：auto（デフォルト）、claude-opus-4.8 / 4.7 / 4.6、claude-sonnet-4.6 / 4.5 / 4、claude-haiku-4.5（最新の一覧を確認するには kiro-cli chat --list-models を実行します）。opus / sonnet などの Claude-Code 名は無効です。kiro は model 'opus' is not available というエラーを返します。

大規模なレビューでは、Bash のタイムアウトを 600000 ms に設定します。ヘルパーが "prompt file is EMPTY" で終了した場合は、プロンプトを書き直して再試行します。空のプロンプトで kiro を実行してはいけません。

成功条件：対象のスコープに対して Kiro が読み取り専用で実行され、解析可能な指摘を返すこと。

ステップ 4：調査結果を要約する

次の内容を報告します。

• レビューの対象範囲
• 優先度別の調査結果
• 可能な場合はファイルと行番号
• 重要な指摘がない場合は、問題がなかったことを明示

ユーザーが修正を希望する場合は、コードを変更する前に、各指摘をローカルで検証してください。

成功基準：生の CLI ログではなく、読みやすいレビュー要約をユーザーに提供します。

ステップ 5：除外対象を指定してのみ反復する

後続のラウンドでは、次のようにします。

• 以前に修正した指摘を除外ブロックに記載する
• 可能な場合は、新たに変更されたファイルに対象範囲を絞る
• コードが再び広範囲に変更されていない限り、ブランチ全体のレビューを繰り返さない

成功基準：後続のラウンドでは、以前の指摘を繰り返すのではなく、新たな問題を対象にします。

ガードレール

• このスキルを自発的に実行してはいけません。ユーザーが明示的に意図を示した場合（例： /kiro-review）、または明示的に呼び出されたワークフローが kiro をレビュアーとして組み込んでいる場合（例：kiro レビューの役割を含む /ship-playbook）に限り実行してください。これは disable-model-invocation ではなくなったため、ワークフローから呼び出すことはできますが、ユーザーに促されていないのに実行してよいという意味ではありません。
• シークレット、トークン、またはプライベート設定をプロンプトに含めないでください。
• 検証せずに調査結果をうのみにしないでください。
• プロンプトを作成する前に、差分を必ず確認してください。
• kiro の起動には helpers/run-kiro.sh --mode review のみを使用してください（スコープを限定した読み取り専用の信頼設定）。レビューで --trust-all-tools／-a を使用してはいけません。また、プロンプトを渡すために mktemp やヒアドキュメントを独自に使ってはいけません。

出力仕様

次の内容を報告してください。

1. レビューの対象範囲
2. Kiro に指定した主な重点領域
3. 可能な場合は場所を添えた、優先度別の調査結果
4. 重要な指摘がなかった場合は、その旨を明示
5. 次のラウンドで以前に修正した問題を除外すべきかどうか