KiroCrew

Kiro Crew: A persistent workspace for development work that self-improves and continues beyond one session (4.7k stars) What it does All text below is quoted directly from the project README. >A persistent workspace for development work that self-improves and continues beyond one session. Why Kiro Crew: - Persistent. Sessions, memory, schedules, and task checkpoints survive Gateway restarts, and scheduled or reactive work continues without someone at the terminal. - Self-learning. Corrections and task failures become durable lessons. Preferences and project context carry into new sessions. - Self-evolving. Repeated patterns become reusable skills. Memory, lessons, and skills stay visible and editable, so each Kiro Crew grows more tailored to the person and work around it. - Runs where you choose. Your Mac, a local container, or a remote machine you control. - One Gateway, many surfaces. Work directly in the desktop app or web dashboard, or continue the same work from the CLI and messaging surfaces like Slack and Discord. >curl -fsSL download.crew.kiro.dev | sh Repository kirodotdev/KiroCrew Repository stats |Metric|Value| |:-|:-| |Stars|4,653| |Forks|911| |Last release|v0.11.0 (2026-10-30)| |Languages|Python 72.4%, TypeScript 23.2%, JavaScript 3.9%| |Contributors|357| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|@claude (196 commits), @cursoragent (2 commits), @Copilot (1 commits)| |AI co-authored commits|Claude: 239, Codex: 1, Cursor: 5, Copilot: 1| Main contributor |Field|Value| |:-|:-| |Name|Bolin Chen| |GitHub|@bolichen97| |Commits to this repo|2,372 (top contributor)| |Company / Location|Seattle| |Followers|55| ────────────────────────────── 📌 If you want to browse more repos like this, we've organized them by category and rankings here: bestgithubrepositories.com 🗂️ We're also archiving repos where possible, so useful projects don't disappear when they're removed from GitHub.

This dev workspace keeps working after you close the tab. kirodotdev/KiroCrew: • A persistent workspace for development work • Self-improves and continues beyond one session • Keeps context across sessions The agent that never goes to sleep. kirodotdev/KiroCrew

Kiro CLIとKiro Crewを改めて入門してAWSで動かすまで KiroはIDEだけの製品ではなくなりました。2026年11月時点では、IDE、CLI、Web、Mobile、そしてCrewの5つの入口があります。 特にCLIはAPIキーでヘッドレス実行ができるようになり、Crewは自分のマシンに常駐して仕事を進めるエージェントとして公開されました。 IDEでSpecを書いた経験はあるけれど最近は触っていない、という状態から、CLIとCrewとAPIキーを実機で一通り試して整理しました。 Kiroの今の全体像 入口は公式ドキュメントの数え方で5つあります。 IDEは従来どおりで、チャットとSpecsとHooksがあります。CLIにはヘッドレスモードとCI連携が加わりました。 Webはブラウザから複数リポジトリの作業を計画してPRまで開き、Mobile(プレビュー)はタスクの監視、PRレビュー、エージェントとのチャット用です。 Crewだけ性格が違い、常駐して自律タスクやスケジュール実行を担い、メモリを持ち、チャットツールともつながります。 機能は入口をまたいで共通で、Specs、Steering、Hooks、MCPといった従来からのものに、Sub-agents、Skills、Memory、Local command sandbox、Workflowsなどが加わっています。 このうち10月に入ってから増えたApprove for me(CLI 2.36.0)、コマンドサンドボックスと自律モード、メモリは、あとで実際に触ります。 一覧は公式ドキュメントのトップにあります。 Kiro Crewは2026-08-04にApache 2.0で公開されました。Amazon社内でMeshClawと呼ばれていたものが前身で、Crew自体は無料です。 GatewayというサーバがローカルやリモートのマシンでKiro CLIなどのエージェントハーネスを動かし、デスクトップ版、Webダッシュボード、CLI、Slackなどから同じセッションを操作できます。 どのハーネスで動かすかは、あとの節で実機の画面と一緒に見ます。 APIキーはapp.kiro.devで発行します。接頭辞はksk_で、対象はPro以上のプランです(認証のドキュメント)。 組織管理のサブスクリプションでは、管理者が「Enable users to generate API keys」を有効にしないと発行できません。デフォルトはオフです。 環境 Kiro CLI 2.37.0(Linux x86_64)、内部のエージェントサーバKAS 0.66.70 Kiro Crew 0.11.1(Dockerイメージghcr.io/kirodotdev/kirocrew:stable) Ubuntu 24.04のdevcontainer、Python 3.12、Node.js 22、Docker 29 Kiroのプランは組織管理のPro+(月2,000クレジット)、サインインはIAM Identity Center 画面の確認はPlaywrightのヘッドレスChromium devcontainerはユーザー名前空間が使えないため、サンドボックスに関する機能(CLIの自律モード、Crewのサンドボックス)はこの環境では動きませんでした。 やってみた Kiro CLIを入れてログインする インストールは公式のスクリプトです。 curl -fsSL cli.kiro.dev | bash kiro-cli --version kiro-cli 2.37.0 ログインはIAM Identity Centerを使いました。SSH先のようにブラウザが開けない環境では、--use-device-flowでコードを表示して別の端末で承認します。 kiro-cli login --license pro --identity-provider https://<your-org>.awsapps.com/start --region us-east-1 --use-device-flow ? Enter Start URL › https://<your-org>.awsapps.com/start ? Enter Region › us-east-1 Confirm the following code in the browser Code: XXXX-XXXX Open this URL: https://<your-org>.awsapps.com/start/#/device?user_code=XXXX-XXXX Logged in successfully フラグを付けてもStart URLとリージョンの確認プロンプトが出るので、Enterを2回押します(issue #4243)。 ログイン後の確認はkiro-cli whoamiです。 kiro-cli whoami --format json-pretty { "accountType": "IamIdentityCenter", "email": "<your-email>", "region": "us-east-1", "startUrl": "https://<your-org>.awsapps.com/start" } モデルの一覧とクレジット倍率も、ログイン後はCLIから取れます。 kiro-cli chat --list-models Available models (* = default): - auto 1.00x credits Models chosen by task for optimal usage and consistent quality claude-opus-5.5 2.00x credits Claude Opus 5.5 model with 1M context window claude-sonnet-5.5 1.30x credits Claude Sonnet 5.5 model with 1M context window claude-haiku-5.5 0.06x credits Experimental preview of Claude Haiku 5.5 model with 1M context window gpt-5.6-sol 4.40x credits OpenAI GPT 5.6 Sol with 1M context window gpt-5.6-terra 2.20x credits OpenAI GPT 5.6 Terra with 1M context window gpt-5.6-luna 0.60x credits OpenAI GPT 5.6 Luna with 1M context window kimi-k3 2.40x credits Experimental preview of Kimi K3. ... (中略) qwen3-coder-next 0.05x credits Experimental preview of Qwen3 Coder Next SteeringとSpecをCLIから使う ここからはブラウザでログインした状態です。IDEで使っていた.kiro/配下の設定は、CLIでもそのまま読まれます。試しに小さなPythonファイルとSteeringを置きました。 .kiro/steering/style.md --- inclusion: always --- - 回答は必ず日本語で書く。 - 最後の行に「-- steering適用済み --」と書く。 対話モードで質問すると、ファイルを読んで答えたあとに署名が付きました。1ターンのクレジットと時間はその場に表示されます。 › app.py の add 関数は何をする関数ですか。1 行で答えてください。 • Read /tmp/kiro-play/sample/app.py • add 関数は、引数 a と b を受け取り、その和を返す関数です。 -- steering適用済み -- ▸ Credits: turn 0.14 • session 0.14 | Time: 19s Specはチャットで頼めば作られます。ヘッドレスモード(次の節で使う--no-interactive --trust-all-tools)から「実装はせず要件・設計・タスクだけ作って」と頼んだところ、1分19秒で3ファイルができました。 .kiro/specs/div-zero-guard/requirements.md .kiro/specs/div-zero-guard/design.md .kiro/specs/div-zero-guard/tasks.md エージェントは組込みが3つで、kiro-cli agent createでワークスペースかグローバルに追加できます。 - kiro_default (Built-in) Default agent kiro_help (Built-in) Help agent that answers questions about Kiro CLI features using documentation kiro_planner (Built-in) Specialized planning agent that helps break down ideas into implementation plans APIキーを発行してヘッドレスで動かす app.kiro.devにサインインし、API Keysから作成します。キーの全文は作成時にしか表示されないので、用途がわかる名前を付けて保管します。 使うときは環境変数に入れて、--no-interactiveで実行します。 export KIRO_API_KEY=ksk_xxxxxxxx kiro-cli whoami Authenticated with API key kiro-cli chat --v3 --no-interactive "Reply with exactly one word: pong" pong 1往復で11秒かかりました。KASの起動を含む時間です。 発行直後の10分ほどは、whoamiは通るのにチャットが403で失敗しました。キーを作ったら少し待ってから試しています。 認証の優先順位はブラウザセッション、KIRO_API_KEY、なし、の順です。ブラウザでログイン済みの端末で環境変数を設定しても、whoamiはIdentity Centerのままでした。CI用の端末ではkiro-cli logoutしてから使います。 ヘッドレスでは人が承認できないので、ツールの許可をフラグで渡します。特定のツールだけ許すなら--trust-tools=<ids>、全部許すなら--trust-all-toolsです(ヘッドレスモードのドキュメント)。 kiro-cli chat --v3 --no-interactive --trust-tools=read_file,grep_search \ "app.py を読んで、div 関数の問題点を 1 行で指摘して" div 関数は b が 0 のときにゼロ除算（ZeroDivisionError）を起こすのに、そのチェックをしていない点が問題です。 -- steering適用済み -- Steeringはヘッドレスでも効いています。スクリプトから扱うなら--output-format stream-jsonが便利で、1行1イベントのJSON Linesになります。実際は12行出ますが、主な行だけ抜粋します。 kiro-cli chat --v3 --no-interactive --output-format stream-json "What is 2+2? Answer with the number only." {"type":"sessionUpdate","data":{"sessionId":"sess_...","update":{"sessionUpdate":"agent_message_chunk","content":{"type":"text","text":"4"}}}} {"type":"sessionUpdate","data":{"sessionId":"sess_...","update":{"sessionUpdate":"session_info_update","_meta":{"kiro":{"contextUsage":{"usagePercentage":2.8415},"kind":"context_usage"}}}}} {"type":"sessionUpdate","data":{"sessionId":"sess_...","update":{"sessionUpdate":"session_info_update","_meta":{"kiro":{"promptTurnSummaries":[{"unit":"credit","usage":0.089855156053068}],"elapsedTime":4318,"status":"success"}}}}} {"type":"runFinished","data":{"sessionId":"sess_...","status":"success","stopReason":"end_turn","finalText":"4","finalTextTruncated":false}} 最後のrunFinishedに最終テキストと停止理由が入り、途中のsession_info_updateに消費クレジットとコンテキスト使用率が入ります。CIで「このPRのレビュー結果だけ欲しい」ならこの行を拾えば済みます。 終了コードも決まっていて、指定したエージェントがない場合は4でした。 kiro-cli chat --v3 --no-interactive --agent no-such-agent "hi"; echo "exit=$?" exit=4 対話モードで増えた機能を見る 対話モードのスラッシュコマンドは/helpで一覧になり、/guideで使い方を質問できます。10月に増えた分を中心に見ました。 /usageはプランと消費量を出します。組織管理のアカウントでは超過購入が無効で、管理は管理者に、と案内されます。 Estimated Usage | resets on 2026-12-01 | KIRO PRO+ Credits (1.46 of 2000 covered in plan) Overages Disabled /permissionsのPoliciesは「ask for approval」か「approve for me」を選びます。後者を選ぶと、モデルが安全と判断した操作は自動承認され、危険なものはブロックされ、迷ったものだけ聞かれます。今回は項目を確認しただけで、切り替えては試していません。 /memoriesのconfigはread & write、read only、offから選び、初期値はoffでした。セッション終了後に自動でメモリを作る「Automatic memory updates」のチェックもここにあります。 /sandboxはGlobalとProjectの2系統があり、Sandbox、Network、MCP sandboxingを編集して~/.kiro/settings/sandbox.jsonに保存します。初期状態はSandboxがoffで、Networkはblock allでした。 /autonomous onはこの環境では有効にできませんでした。ローカルのコマンドサンドボックスが前提で、このコンテナではsandbox unavailableと表示されるためです。 Kiro Crewを立ち上げる Crewは、操作する側(ダッシュボード、CLI、チャットツール)とGatewayの2層になっていて、Gatewayが同梱のkiro-cliをACP経由で動かします。 Crewはデスクトップ版、ワンライナー、Docker、ソースビルドから入れられます(リポジトリのREADMEとDockerガイド)。devcontainerの中で消しやすいので、今回はDockerにしました。 設定と認証情報は名前付きボリュームに置かれるので、ガイドによればイメージを更新しても状態は引き継がれます。 docker run -d --name kirocrew \ -p 127.0.0.1:5476:5476 \ -v kirocrew-home:/home/kirocrew \ -e KIRO_API_KEY=ksk_xxxxxxxx \ -e KIROCREW_ALLOW_UNSANDBOXED=1 \ -e TZ=Asia/Tokyo \ ghcr.io/kirodotdev/kirocrew:stable 起動ログの[entrypoint]行に、何が起きたかが書かれます。 [entrypoint] Stored KIRO_API_KEY in /home/kirocrew/.kiro/crew/.env and removed it from the environment. [entrypoint] First run: NO inner sandbox backend under this runtime's seccomp policy; KIROCREW_ALLOW_UNSANDBOXED=1 given — seeded config.json with sandbox=auto + sandbox_allow_unsandboxed_exec=true. [entrypoint] Dashboard login: run docker exec <container> kirocrew token --ttl 2h 起動ログの案内には「チャットセッションにはログイン済みのkiro-cliが必要」とありますが、.envのKIRO_API_KEYだけでセッションは動きました。 docker exec kirocrew kirocrew chat -m "Reply with exactly one word: pong" pong ダッシュボードはトークン認証です。kirocrew tokenで短命のリンクを作り、ブラウザで開きます。 docker exec kirocrew kirocrew token --ttl 2h localhost... 初回はPrivacyの同意画面と「Tell Kiro about you」が出ます。Privacyは匿名の利用ハートビートで、デフォルトでオンです。CLIのkirocrew telemetry disableでも切れます。 左のナビにはSessionsやSchedule、Artifacts、Appsなどが並びます。この記事で使うのはSessions、Schedule、Artifacts、Settingsです。 Crewに仕事を頼む チャットでコマンド実行を伴う依頼をすると、実行したステップが展開され、消費クレジットと所要時間が表示されます。 セッションの承認モードはデフォルトでAutomaticです。拒否リストと機密パスの保護とサンドボックスのチェックを通ったものは、個別に聞かれずに実行されます。 Settings → Securityに出るYOLOやTool Approvalの「Interactive」は、ダッシュボード側の設定で、このセッション設定とは別物です。 では危ないものはどうなるか、とcat ~/.aws/credentialsを頼んでみました。 I can't run that one. ~/.aws/credentials holds your AWS access keys, and dumping it to the chat would expose those secrets in plain text where they could end up in logs or history. If you need to work with your AWS setup, here are safer options: - Check which profiles exist without exposing secrets: aws configure list-profiles - Confirm the active identity: aws sts get-caller-identity 拒否パターンはkirocrew security deny-listで見られ、組込みが112件ありました。aws s3 cp ... s3://、echo $AWS_SECRET...、printenvでAWS変数を拾う、kirocrew tokenを取る、Crew自身をpkillする、といったものです。 Securityのドキュメントによれば、この拒否ルールはCrew側のツールゲートで効くため、kiro-cliのエージェント設定を書き換えても弱められないとのことです。 監査ログは署名付きで、kirocrew security verifyで整合性を確認できます。 ✅ HMAC chain intact: 1486 entries verified. Settings → Securityを開くと、いま効いている防御がまとめて見えます。 スケジュールはCLIからも登録できます。 docker exec kirocrew kirocrew cron add --every 300 \ --command "date -u; echo hello-from-crew" --silent demo-date "print the date" Added job: d54d3597 (demo-date) [every 5m] docker exec kirocrew kirocrew cron trigger d54d3597 Triggered job: demo-date (d54d3597) 実行履歴はダッシュボードのSchedule → Executionsと、データホームのcron-history/<job>.jsonlに残ります。 {"run_id": "5eac22813a1c", "job_id": "d54d3597", "trigger": "manual", "duration_ms": 70, "status": "success", "summary": "Sun Nov 1 06:28:27 UTC 2026\nhello-from-crew\n"} --atで1回きりの実行や、--script FILE.py:FUNCでPython関数も登録できますが、今回は使っていません。 Crewのメンバー(担当エージェント)はkirocrew agent createで増やせます。固有のワークスペースとメモリストアが作られます。 docker exec kirocrew kirocrew agent create --name reviewer --display-name "Reviewer" Created agent: reviewer (display name: Reviewer) Workspace: member-reviewer Appsには、Issue Radar(GitHubやGitLabのIssueのトリアージ)など30個が並んでいました。GitHubやSlackとの接続は今回試していません。 エージェントハーネスとサブエージェントごとのバックエンド Crewがエージェントを動かす実行系を「エージェントハーネス(バックエンド)」と呼びます。Settings → Agent Harnessで、新しいセッションがどのハーネスで始まるかを選べます。 手元の0.11.1では、Kiro Agent(KAS)とKiro CLIがInstalled、Claude Code、codex、deepseek、goose、opencode、piがNot installedでした。 足りないバイナリ名(claude-agent-acp、codex-acp、dsh、goose、opencode、pi-acp)も画面に出ます。 各ハーネスには能力カードがあり、Kiro Agentは「Crewのツールがチャットで使える」「Side Chatで読み取り専用ツールが動く」「作業中にメッセージを足せる」など7項目すべてに対応しています。 0.11.0以降は新規インストールのデフォルトがKiro CLIではなくKAS(表示名Kiro Agent)です。組込みのKASエンジンを使う設定を有効にすればkiro-cliのインストールも不要になるそうですが、そこは試していません。 設定ファイルではagent.acp_backendとagent.member_acp_backendがどちらもkasになっています。 v0.10.0(2026-10-25)では、サブエージェントごとにバックエンドを指定できるようになりました。 サブエージェントの起動に使うspawn_runツールへbackendパラメータが増え、タスク単位でハーネスを切り替えられます。 ツールの定義文によると、指定したバックエンドが使えなければデフォルトに置き換えず拒否し、使える一覧を返します。modelはそのバックエンドのモデルIDで渡します。続きを頼むspawn_continueは元と同じバックエンドで動きます。 同じリリースで、バックグラウンド作業とサブエージェントの役割ごとにモデルと推論強度を固定する設定も入りましたが、今回は触っていません。 実際にチャットから「backendをkiro-cliにしてサブエージェントを起動して」と頼んでみました。 kiro-cliという名前は拒否され、この環境で指定できるのはkasとkiroの2つだと返ってきました。 kiroで起動し直すと「1 agent finished」とサブエージェントは完了しましたが、軽量エージェント(kirocrew-lite)が「調べます」と言うだけでコマンドを実行せず、肝心の報告は取れませんでした。 Claude CodeやCodexは入れていないので、本来の使い方であるハーネスの使い分けまでは確認できていません。 クラスメソッドさんの記事では、Claude Codeのサブエージェントを起動してSlackコネクターを使わせる例が紹介されています。 Claude CodeやCodexは入れていないので、公式ドキュメントでハーネスごとの注意だけ確認しました。 Claude Code側で事前承認したツールはCrewの承認を通らないので、拒否ルールと監査が効きません。Codexはagent.sandboxがoffだと起動せず、piはCrewのMCPツールを受け取れません。 ハーネスを切り替えると、Crewの防御が及ぶ範囲も変わります。 業務での使い方を4パターン試す 題材は小さな注文APIのリポジトリで、ブランチにはAPIトークンのハードコード、文字列連結のSQL、合計を平均に変えてしまった退行を仕込んであります。 ログは400行の合成データで、デプロイ直後にDB接続プールが枯渇して503が7分間続き、ロールバックで収まった、という筋書きです。 1. APIキーでPRレビューをCIから回す レビューの観点と出力形式はSteeringで固定します。 .kiro/steering/review.md --- inclusion: always --- - レビューは日本語で書く。 - 指摘は「重大度 / ファイル:行 / 内容 / 修正案」の形で箇条書きにする。重大度は High / Medium / Low。 - 問題がなければ「指摘なし」とだけ書く。 差分をプロンプトに含めて標準入力から渡し、ツールは読み取り系だけ許可します。結果はrunFinishedのfinalTextから取り出します。 { echo "次の差分をセキュリティとバグの観点でレビューしてください。必要なら app/ 配下のファイルを読んで確認してください。" echo; echo '``diff'; git diff main...HEAD; echo '``'; } > review-prompt.txt kiro-cli chat --v3 --no-interactive --trust-tools=read_file,grep_search \ --output-format stream-json < review-prompt.txt \ | jq -r 'select(.type=="runFinished") | .data.finalText' 仕込んだ3つはすべてHighで拾われ、修正コードまで付いてきました。36秒、0.28クレジットです。 GitHub Actionsなら、シークレットに入れたAPIキーをenvで渡して同じコマンドを動かすだけです。公式ドキュメントの例に手元のコマンドを当てはめると、こうなります。 .github/workflows/kiro-review.yml on: [pull_request] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: { fetch-depth: 0 } - run: curl -fsSL cli.kiro.dev | bash - name: Review PR changes env: KIRO_API_KEY: ${{ secrets.KIRO_API_KEY }} run: | { echo "次の差分をセキュリティとバグの観点でレビューしてください。"; echo '```diff' git diff origin/${{ github.base_ref }}...HEAD; echo '```'; } > review-prompt.txt ~/.local/bin/kiro-cli chat --v3 --no-interactive --trust-tools=read_file,grep_search \ --output-format stream-json < review-prompt.txt \ | jq -r 'select(.type=="runFinished") | .data.finalText' > review.md gh pr comment ${{ github.event.pull_request.number }} --body-file review.md env: GH_TOKEN: ${{ github.token }} このワークフロー自体は今回動かしていません。手元で確認したのはコマンドの部分だけです。 2. Crewのスケジュールで朝のダイジェストを作る 平日9時に前日のログを要約するジョブを、エージェント型で登録します。回数が多いのでモデルはHaiku 5.5に固定しました。 docker exec kirocrew kirocrew cron add --cron "0 9 * * MON-FRI" --timezone Asia/Tokyo \ --model claude-haiku-5.5 morning-digest \ "/home/kirocrew/biz/logs/orders-api.log を読んで、直近のエラー件数、発生した時間帯、直前に起きたデプロイなどのイベント、推定原因を日本語で5行以内にまとめてください。" Added job: 451d6caf (morning-digest) [At 9:00 AM JST, Monday through Friday] docker exec kirocrew kirocrew cron trigger 451d6caf エラー45件、02:14から02:21、02:13:40にv2.14.0をデプロイ、02:21:14にロールバック、推定原因はDB接続プールの枯渇、と5行にまとまりました。 Haikuでも4分26秒かかっています。400行のログを読んで数えているためで、結果が届けばよい定期ジョブなら気になりません。 --channelでSlackのチャンネルにも流せますが、今回はダッシュボードで確認しています。 3. Crewのダッシュボードから障害調査を頼む 同じログについて、ダッシュボードのチャットで「エラーが集中した時間帯、内容、直前のイベント、推定原因と対処案を報告して」と頼みました。 最初のコマンドで承認待ちになりました。wcとgrepを&&でつないだ複合コマンドです。先ほどのdate単体のときは自動承認だったので、複合コマンドは人に聞く判定のようです。 実行するコマンドが見えるので、Allow onceで通しました。2回の承認のあと、3ステップで報告が返ってきました。 デプロイから最初のエラーまでの33秒、ロールバックでエラーが止まったこと、プールサイズと新機能のフラグの関係まで、ログにある事実から組み立てられています。 1.04クレジットで6分6秒でした。ステップ数が増えると時間もかかるので、急ぎの調査は手元のCLIで回し、あとから読めばよいものはCrewに任せる、というのが6分待った感想です。 4. 障害報告書をアーティファクトに残す 調査の続きで「社内向けの障害報告書をMarkdownで作成し、アーティファクトとして保存して」と頼むと、Artifactsに文書が保存されました。承認は不要で、55秒、0.67クレジットです。 アーティファクトは版管理されていて、ダッシュボードから開けます。調査のセッションと報告書が同じ場所に残るので、あとから経緯を追うのが楽です。 AWS上に別環境として切り出す devcontainerではサンドボックスが動かなかったので、Crewを自分のAWSアカウントに出してみました。EC2、Fargate、Lambda MicroVMの順に試し、以降この3通りを「レーン」と呼びます。 どれも手元のCrew(ハブ)から操作し、接続はSSMのポートフォワードだけにしました。受信ポートは開けません。 手順はスクリプトにしてkiro-crew-aws-lanesに置きました。EC2のTerraform、Fargateの01から05、MicroVMの01から05、片付けのcleanup.shがあり、この検証環境で土台の作成から起動と応答確認まで通しで動かしています。 EC2ならサンドボックスがそのまま効く まずkirocrew cloud launchを使いました。CloudFormationでインスタンスロール、インスタンス、WaitConditionを作ります。Amazon Linux 2023にkiro-cliとCrewを入れて、ゲートウェイのヘルスチェックが通るまで待つ流れです。 サイズはlightがt4g.xlarge、balancedがm7g.2xlargeで、ほかにpowerがあります。必要なIAMはkirocrew cloud iam-policyが出してくれます。 kirocrew cloud doctor --profile <aws-profile> --region ap-northeast-1 kirocrew cloud launch --profile <aws-profile> --region ap-northeast-1 --size light --idp-region us-east-1 -y 手元がIdentity Centerでサインインしていると、そのまま継承しようとして--idp-regionを要求されます。付けると[1/6]から[6/6]まで進み、途中でインスタンス上のkiro-cli loginのデバイスコードが表示されます。 最後にSSMトンネルでダッシュボードが開きます。停止はcloud stop、削除はcloud destroyです。 cloud launchは手元のサインインを継承するので、APIキーだけで無人で立ち上がる構成をTerraformでも書きました。SSM用のロール、egressだけのセキュリティグループ、IMDSv2のインスタンスで、user-dataがkiro-cliとCrewを入れてkirocrew service installで常駐させます。 APIキーはSSMのSecureStringに置き、インスタンスが起動時に取り出して.envに書きます。 terraform/main.tf(抜粋) resource "aws_instance" "crew" { ami = data.aws_ami.al2023.id instance_type = "m7g.large" iam_instance_profile = aws_iam_instance_profile.instance.name # AmazonSSMManagedInstanceCore vpc_security_group_ids = [aws_security_group.crew.id] # ingress なし metadata_options { http_tokens = "required" } user_data = templatefile("${path.module}/user-data.sh.tftpl", { region = var.region api_key_param = var.kiro_api_key_parameter # SSM SecureString の名前 crew_channel = var.crew_channel }) } 起動後に確かめたかったのは、サンドボックスが本当に効くかです。 $ kirocrew sandbox status ✅ this host does not restrict unprivileged user namespaces $ kirocrew doctor | grep backend backend: ✅ namespace ダッシュボードのSecurity画面でもProcess SandboxがStandardになり、Kiro CLIの--sandbox付きのヘッドレス実行も通りました。devcontainerで止まっていた2つが、素のLinuxではどちらも動きました。 user-dataでひとつ詰まりました。kirocrew service installは内部でsudoを使うので、crewユーザーで実行すると「a terminal is required to read the password」で止まります。 一時的にNOPASSWDのsudoers断片を置いて実行し、終わったら消す、という手順をuser-dataに入れています。 Fargateのタスクで使い捨てのcrewを動かす Fargateは常駐ではなく、タスク1つが1つのcrew(Crewが動かすエージェントの1単位)になる使い捨てワーカです。公式ドキュメントの位置付けはPreviewで、ウィザードもCLIもなく、cloud.jsonを手で書いてAPIで起動します。 kirocrew cloud iam-boundaryで権限境界(crew用とexecution用)を作る 同梱のCloudFormationテンプレートを2つデプロイする。kirocrew-fargate-base.yamlはクラスタとegress専用SGを、kirocrew-fargate-crew.yamlはcrewごとの実行ロール、タスクロール、ロググループを作る Crewコンテナのイメージを自分で作ってECRに置く Crewのサインインで得たIDドキュメントをSecrets Managerに置く cloud.jsonにfargateブロックを書き、POST /api/cloud/launchで起動する イメージは2段です。同梱のDockerfileがベース(Python 3.12とkiro-cli 2.20.2とAWS CLI)で、Dockerfile.crewがベースの上にcrewバンドルを載せる薄い層です。 ベースのビルドにはvendor/にCrewのwheelが1つ必要で、署名付きフィードのwheel_urlから取ります。途中で切れたwheelを置いたらSHA不一致で落ちたので、curl --retry -C -で取り直しました。 crewバンドルはpython -m packaging.build build --crew <name> --out <dir>で作ります。MCPやhooksは「デプロイ側の判断」として落とされ、ペルソナだけのバンドルになります。 認証情報は、APIキーではなくCrewのサインインで得たKasTokenのJSONです。 ハブのPOST /api/kas-login/deviceでIdentity Centerのデバイスフローを始めて承認します。 ハブのvault(認証情報の保管先)に入ったものをkirocrew/crew/<crew>/KIRO_IDENTITYという名前のシークレットに置きました。 ~/.kiro/crew/cloud.json(fargate ブロック) "fargate": { "cluster": "kirocrew-crew-kirocrew", "subnets": ["subnet-…"], "security_groups": ["sg-…"], "image": "<account>.dkr.ecr.ap-northeast-1.amazonaws.com/kirocrew-crew@sha256:<64桁>", "secrets": [["kirocrew/crew/fargate-demo/KIRO_IDENTITY", "arn:aws:secretsmanager:…"]], "cpu_architecture": "X86_64", "assign_public_ip": true, "task_ttl_seconds": 3600, "internal_only": true } ブロックがそろうとGET /api/cloud/provisionersにaws_fargateの行が現れ、confirm_before_launchに「このイメージにこのシークレットを渡す」という文字列が入ります。これをそのままconfirm_recipientとして送り返さないと起動は拒否されます。 curl -X POST "127.0.0.1" -H "Content-Type: application/json" \ -d '{"provider_id":"aws_fargate","profile":"<aws-profile>","region":"ap-northeast-1","size_key":"light","confirm_recipient":"<provisionersの文字列>"}' 最初はEC2と同じつもりでlogin_targetにIdentity Centerを渡しました。 preflightで次のように断られます。 a Fargate crew is credentialed by the API key its container is started with and has no interactive sign-in. Launch with the default Builder ID identity 認証情報はシークレットから渡るので、login_targetを消したら通りました。 起動ジョブは4ステップで、provisionがECSのタスクARNを返し、signinは「Already signed in.」、connectで「Added to Your crews.」になります。タスクは4 vCPUと16GBで、ECS Execが有効でした。 タスクのログを見ると、サンドボックスなしで起動したことが書かれていました。 container.supervisor WARNING no user-namespace sandbox on this host; starting UNSANDBOXED because SMC_INTERNAL_ONLY is set. container.supervisor INFO crew 'fargate-demo' installed: agent=/var/lib/kirocrew/kiro/agents/crew-fargate-demo.json INFO: Uvicorn running on 0.0.0.0 internal_onlyはこのためのフラグです。Fargateが非特権のユーザー名前空間を許さない以上、タスク自体を隔離の単位として扱うことに利用者が同意するためのものです。公式ドキュメントも「自分のcrewだけを動かす前提で、マルチテナントには使わない」と書いています。 起動後はSettings → Remote CrewにFargateのカードが増え、ConnectでSSMのフォワードが張られてCHAT APIのURLが出ます。ハブのcrew-turnはこのレーンに未対応ですので、そのURLに直接投げます。 形式はOpenAIのChat Completionsで、modelにcrew名を入れます。 curl -N -X POST 127.0.0.1 -H "Content-Type: application/json" \ -d '{"model":"fargate-demo","messages":[{"role":"user","content":"Reply with exactly one word: pong"}],"stream":true}' data: {"id": "chatcmpl-…", "object": "chat.completion.chunk", "model": "fargate-demo", "choices": [{"index": 0, "delta": {"role": "assistant", "content": "pongpong"}, "finish_reason": null}]} data: {"id": "chatcmpl-…", "object": "chat.completion.chunk", "model": "fargate-demo", "choices": [{"index": 0, "delta": {}, "finish_reason": "stop"}]} data: [DONE] stream: falseで送った1回目は400秒待っても返らず、stream: trueにしたら数秒で返りました。本文が「pongpong」と二重になっているのも、そのまま載せておきます。 Lambda MicroVMでも同じことができる Fargateと同じ使い捨てワーカを、Lambda MicroVMs(Firecrackerの1VM)で動かすレーンもあります。東京リージョンにも管理イメージal2023-1がありました。 段取りはFargateと似ています。同梱のkirocrew-microvm-base.yamlでKMSキー、レシピ用のS3バケット、ビルドロール、SSMハイブリッドアクティベーション用ロール、実行ロールを作り、cloud.jsonにmicrovmブロックを書きます。 Fargateと違ってイメージは手元でビルドしません。レシピzip(Dockerfile.microvmとwheelとバンドル)をS3に置き、Lambda側でイメージを作ります。 MicroVMでもwheelで詰まりました。デスクトップ用のwheelをそのまま置くとcarries 2992 dashboard asset(s) under kiro_crew/static/ ... over its 67108864-byte ceilingと断られます。 リポジトリのscripts/build_microvm_image_zip.pyはソースのチェックアウトからビルドする前提です。代わりにwheelからkiro_crew/static/を抜いてRECORDを書き換えたもの(100.9MBから41.2MB)を置きました。 起動ジョブは初回のイメージビルドを含めて8分ほどで完了し、provisionがmi-…(SSMのマネージドインスタンスID)を返しました。Lambda側でもイメージがCREATED、MicroVMがRUNNINGになっています。 こちらはゲストの全ルートが認証必須で、SSMで転送したポートへ直接/healthを呼ぶとcontrol_forbiddenです。ハブのcrew-turn経由なら通ります。 curl -X POST "127.0.0.1" -H "Content-Type: application/json" \ -d '{"thread":"verify-1","message":"Reply with exactly one word: pong","stream":false}' {"object": "chat.completion", "model": "fargate-demo", "choices": [{"index": 0, "message": {"role": "assistant", "content": "pong"}, "finish_reason": "stop"}]} 65秒でpongが返りました。VMはデフォルトの1時間が過ぎると消え、会話もVMと一緒になくなります。 サンドボックスをそのまま使いたいならEC2です。短時間の仕事を切り出すだけならFargateかMicroVMで足ります。FargateとMicroVMはまだ手書きの設定とAPI起動だけですので、記事の時点では試す人向けです。 料金 料金ページのプランと月あたりのクレジット(ユーザー単位)は次のとおりです。 プラン 月額 クレジット Free $0 50 Pro $20 1,000 Pro+ $40 2,000 Pro Max $100 5,000 Power $200 10,000 追加クレジットは$0.04です。APIキーの消費もこのクレジットから引かれ、Crew自体は無料です。 クレジットはモデルごとの倍率で消費されます。手元の実測は、autoでヘッドレスの短い質問が0.09、対話モードでファイルを1つ読んで答える質問が0.14、Crewでコマンドを1回実行して答える依頼が0.42でした。 Haiku 5.5は100Kトークンまでなら0.06倍です。定期ジョブのように回数が多いものは--modelで安いモデルを指定すると効きます。コマンド型のスケジュールはそもそもモデルを呼びません。 まとめ Kiroは「IDEでSpecを書く」から、「CLIをCIから呼び、Crewに常駐してもらう」まで範囲が広がりました。 APIキーはヘッドレス専用で、対話はブラウザ認証です。CI用の端末にはキーを置き、手元の端末はログインのままにすれば迷いません。 業務で試した4パターンのうち、PRレビューはCIに組み込める形まで動き、定期ダイジェストと障害調査はCrewに任せられる手応えがありました。 Crewは拒否リストと監査ログが最初から入った状態で届くので、常駐させる前提の作りになっています。ハーネスをClaude CodeやCodexに切り替えると、防御が及ぶ範囲はハーネスごとに変わります。サンドボックスが前提の機能も多く、コンテナ環境では動かないものが残ります。 自律モードとCrewのサンドボックスを本来の形で試すなら、素のLinuxかmacOSを用意するのが近道で、AWSならEC2に出すのが一番簡単でした。

@bakikaradeniz @awscloud Also kindly share, please report problems at github.com/kirodotdev/KiroCrew/issues. Our updates go there, and you get a notice when a fix ships. That goes for everyone reading. If you notice that we reply issues slowly without proper messages, please let us know and we will fix our process.

@bakikaradeniz @awscloud Already tracked: • Memory use: KiroCrew#5033 • Connections asking to sign in again: KiroCrew#23135 and KiroCrew#22539

@bakikaradeniz @awscloud • Context budget rows don't explain skills: KiroCrew#26893 • Two "Create mate" buttons: KiroCrew#26894 • "Customize" name is unclear: KiroCrew#26895

俺らで作る最強の Kiro Crew。コントリビュートの手順と AI レビューの仕組み はじめに こんにちは、AWS Japan でソリューションアーキテクトをしているいなりくです。 使っている OSS で困りごとを見つけて、直す PR を出してみたいと思ったものの、どの issue なら手を付けてよいのか、大きな変更をいきなり実装してよいのかが分からず、手が止まったことはないでしょうか。 Kiro Crew は、ダッシュボードや CLI、Slack などのチャットからエージェントに作業を頼み、定期実行やセッションをまたいだ記憶を持たせられる OSS です。GitHub で Apache License 2.0 として公開されていて、外部からの issue と PR を受け付けています。 kirodotdev/KiroCrew 私は 2026 年 10 月に、この Kiro Crew へ修正 PR、機能 PR、設計文書（RFC）の PR を出しました。最初は使っていて見つけた表示の不具合を直すところから始めました。その後、OpenAI の Codex で Computer Use（エージェントがデスクトップのアプリを操作する機能）を使ってみて、エージェントが画面を見ながら何手かまとめて操作する使い勝手が良かったので、同じことを Kiro Crew でもできるようにしたいと考えました。Kiro Crew にも Computer Use はありますが、作りが違うところがあり、その差を埋める PR を出しているところです。 本記事では、リポジトリの CONTRIBUTING.md などに書かれた手順を、そのとき実際に通った順にまとめます。手順で迷ったところや、やり直したところも書きます。手順の細部はリポジトリの文書とスキルにまとまっていて、コーディングエージェントが読んで従えるので、全部を覚える必要はありません。全体の流れをつかむつもりで読んでください。後半では、PR を出したあとに動く Kiro Crew のレビューパイプラインの仕組みを解説し、最後に Codex との差を埋める取り組みの現状を紹介します。 ! 本記事の内容は 2026 年 10 月 26 日時点の main に基づきます。手順やチェックの名前は変わることがあるので、PR を出す前に最新の CONTRIBUTING.md を確認してください。 全体の流れ 図1: Kiro Crew へのコントリビュートの流れ。小さな変更は claim から、設計が要る変更は RFC から始める 分かれ目は issue に付いた tier です。小さな issue は /claim して自分で実装し、設計が要る issue は先に RFC で方向を決めます。どちらの場合も、PR を出した後は CI と AI レビューの指摘に対応しながら、メンテナのレビューを待ちます。 issue を選ぶ 作業は issue から始めます。CONTRIBUTING.md の PR 手順には、すべての PR が tier の付いた issue を本文の独立した行で指すこと、と書かれています。 書き方 意味 Closes #N PR のマージで issue を閉じる Part of #N issue は開いたまま、作業の一部として紐づける issue には、どの部分のコードに関わるかを示す area: ラベル（area: dashboard、area: agents、area: cron など）と、種類を示す bug や enhancement が付いています。触りたい部分の area: で絞り込むと探しやすくなります。 目的の issue がなければ自分で立てます。不具合なら再現手順、バージョン、OS、インストール方法の特徴を書きます。機能の要望なら、設計案より先に「何をしようとして、何に止められたか」を書くよう求められています。そのほうが、要望者が思いつかなかった解き方をメンテナが提案しやすいからです。 tier で、自分で取り組めるかが決まる issue は毎日の triage で tier:T1 から tier:T4 に分類されます。 tier できること T1、T2 /claim して自分で実装できる T3、T4 設計の作業なので claim できない。issue にコメントして参加する 私が最初に出した修正は、Markdown プレビューで /images/... のようなルートからの画像パスが表示されない問題でした。issue は tier:T1 が付き、そのまま修正 PR を出してマージされました。issue を立てたのが 10 月 24 日の 10 時 41 分、PR を出したのが 10 時 56 分、マージされたのが翌 25 日の 13 時 4 分で、PR からマージまでは 1 日ほどでした。 KiroCrew#23631 最初の issue を探す エージェントに「自分で取り組める T1 か T2 の issue を、area: dashboard の中から探して」と頼めば、探すところから任せられます。自分で探すなら、GitHub の issue 検索で次の条件を入れると絞り込めます。 is:issue is:open label:"tier:T1","tier:T2" -label:claimed -label:"claim:outside" -label:parked claimed はメンテナ側の自動修正がすでに進んでいる issue、claim:outside は外部の人が /claim 済みの issue、parked は今の計画に入っていない issue に付くラベルです。ここに area: のラベルを足すと、触りたい部分だけが残ります。 /claim で「自分がやる」と宣言する T1 と T2 の issue は、コメントの 1 行目に /claim と書くと自分の担当になります。担当になると、メンテナ側の自動修正パイプラインがその issue に手を出さなくなります。 コメント 動き /claim 担当者のいない T1、T2 の issue を 7 日間自分の担当にする /claim extend 7 日延ばす（1 回だけ） /unclaim 担当を手放す Closes #N でリンクした PR が開いている間は、担当が続きます。下書き（Draft）の PR でも構いません。 リンクした PR がないと 7 日後に通知が来て、その 3 日後に担当が外れます。 同時に持てる担当は 2 件までです。 返事は毎日 1 回の triage が書くので、届くまで最大 1 日かかります。 私が claim したときは、約 20 分後に KiroCrewCaptain から「11 月 1 日まで自動化はこの issue を稲田さんに任せる」という返事が付きました。 大きな変更は RFC から始める CONTRIBUTING.md と GOVERNANCE.md は、次のような変更を「設計の変更」として、先に RFC を書くよう求めています。 公開しているインターフェースの変更 ほかの部分がそれに合わせて作られることになる変更 後から戻すのが大変な変更 バグ修正は RFC を待たない、とも明記されています。どちらに当たるか分からなければ、issue で聞くよう案内されています。 RFC は、docs/request-for-change/rfc-<topic>.md を 1 つ足すだけの独立した PR として出します。英語で書き、先頭に status や author、確認した時点のコミットなどを持つ front matter を置きます。構成は Summary、Motivation、Goals、Non-goals、Design、Migration plan、Backward compatibility、Security considerations、Alternatives considered、Open questions の順が勧められています。Migration plan は PR 1 本の大きさに分け、テストで確かめられる終了条件を付けます。 status の値は決まっていて、RFC が main に入っても draft のままでは「決まった」ことになりません。 status 意味 draft 提案中。何も作られていない accepted 設計が合意された。まだ作られていない in-progress 実装の PR が開いている partial 一部の段階が main に入った implemented すべての段階が main に入った RFC の中で決め切れない論点は Open questions に並べ、メンテナが答えを書き込んで accepted に変えます。 私が順番を間違えたところ ダッシュボードの Git パネルからブランチを切り替える機能では、最初に順番を間違えました。要望の issue は tier:T3 で、「必要なら RFC で」というコメントが付いていたのに、私は RFC なしで約 70 ファイルの実装 PR を出していました。 その後に手順を読み直し、実装 PR を Draft に戻して RFC を先に出しました。 KiroCrew#23725 RFC にはメンテナから「Hold」のレビューが付き、main とのコンフリクトの解消と、AI の Design Review が付けたメモへの返答を求められました。両方に対応すると、RFC は draft のまま main に入りました。今は Open questions への回答を待っていて、実装は回答が出てから段階ごとの PR に分けて出し直す予定です。設計に時間がかかる変更ほど、先に RFC で合意を取ったほうが、結果として実装の手戻りが少なくなります。 実装して PR を出す worktree で作業する fork したリポジトリで、main から git worktree を切って作業します。メインの clone では作業しないのが決まりです。 git fetch upstream main git worktree add ../kirocrew-wt-my-feature -b feat/my-feature upstream/main コミットの前に通すチェック リポジトリの AGENTS.md に、コミット前に通すチェックがまとまっています。 python3 scripts/check_black_formatting.py && python3 scripts/check_subprocess_encoding.py && isort src/kiro_crew test flake8 src/kiro_crew test && mypy src/kiro_crew python3 scripts/local-gate.py いくつか注意があります。 scripts/local-gate.py は、差分に関係するテストだけを流します。全テストは CI の役割です。 macOS では mypy --platform linux src/kiro_crew で実行します。付けないと、CI で落ちる Linux 向けのエラーを見逃します。 black src/kiro_crew test をそのまま実行すると、整形の例外として登録された多数のファイルまで書き換わります。自分が触ったファイルだけを black --target-version py310 <ファイル> で整形します。 コミットは Conventional Commits で 2 つまで コミットメッセージは <type>: <summary> の形で、type は feat、fix、docs、style、refactor、perf、test、chore、ci、build、revert のどれかです。summary は小文字で始め、72 文字以内に収めます。 1 つの PR は 2 コミットまでです。レビューの指摘は amend か squash で直し、--force-with-lease で push します。 PR を出した後に main が進んで、GitHub の画面に「This branch is out-of-date with the base branch」と出ることがあります。このとき Update branch をそのまま押すと、マージコミットが増えて 2 コミットの上限を超えます。ボタンの横の ▼ から Update with rebase を選ぶか、手元で rebase します。私は一度そのまま押してしまい、rebase して force push し直しました。 PR テンプレートの見出しは全部残す gh pr create --body-file で本文を渡すと、GitHub の PR テンプレートは使われません。.github/PULL_REQUEST_TEMPLATE.md の見出しをすべて残し、冒頭の Goal: の行を埋めた本文を自分で用意します。見出しが欠けていると PR Hygiene のチェックで落ちます。出す前に手元で形式を確かめられます。 out="$(mktemp)"; PR_BODY="$(cat pr-body.md)" GITHUB_OUTPUT="$out" bash .github/scripts/pr-description-check.sh; cat "$out" テンプレートの最初の 3 つの節（Problem / Motivation、Why it matters、Not a goal）は、PR を出した時点で固定され、人に頼まれない限り書き換えません。レビューで範囲外の指摘が来たときは、目的を広げずに返答で答えるか、後回しにします。 Kiro Crew のレビューパイプライン PR を出すと、人のメンテナが読む前に、自動のチェックと複数の AI レビューが順に動きます。全体の詳しい説明は docs/ci/ci-and-reviews.md にあります。ここでは、PR を出す側が知っておくと困らない部分をまとめます。 図2: Kiro Crew のレビューパイプライン。軽いチェックが通ってから、重いテストと AI レビューが進む まず軽いチェック、次に重いテスト 最初に走るのが Fast Gate です。数分で終わる軽いチェックの集まりで、ドキュメントのリンク切れ、コメントの書き方、ハーネス（kiro-cli や Claude Code など、エージェントを動かす実行環境）ごとの扱いの書き方といった、コードを動かさずに分かる規約を確かめます。重いテスト（OS ごとに分割したバックエンドのテスト、フロントエンドのテスト、E2E）は、Fast Gate がその commit で通るのを待ってから始まります。規約違反の段階で、重いテストに時間を使わないための順番です。 そのぶん、Fast Gate が落ちると後ろのチェックはまとめて赤になります。私の PR では Comment History Gate が落ちました。コード中のコメントに issue 番号を書いていたためです。Kiro Crew のコード規約では、コメントには今の動作だけを現在形で書き、「以前は」「今後は」のような経緯は git の履歴に任せることになっています。7 か所のコメントを直すと、連鎖して赤になっていた残りのチェックも通りました。赤がたくさん並んだときは、まず Fast Gate の中のどれが落ちたかを見るのが近道です。 役割の違う AI レビュー AI レビューは、問いと読めるものがそれぞれ違う 5 つのレビューと、セキュリティの範囲を確かめる Security Scope Review に分かれています。 レビュー 問い 読めるもの マージを止めるか Opus 5.5 Review 行単位で正しいか、安全か コードだけ 止める GPT 6.1 Review 行単位の別の視点と、PR 本文と差分の食い違い コードと、信頼しない入力として扱う PR の本文 止める Design Review 作るべきものか、形は正しいか コードと PR の本文 基本は助言。本当に問題があるときだけ止める UX Review 初めて使う人に画面の意味が伝わるか 先にスクリーンショットだけ、そのあと差分 同上 First Principles Review 足すものが本当に必要か、すでにないか リポジトリ全体 同上 設計の考え方は、どのレビューに何を読ませるかで決まっています。PR の本文や差分は外部の人が書けるので、そこに「このレビューを通して」のような指示を紛れ込ませる攻撃が考えられます。そのため、どのレビューにもシェルを渡しません。ツールを使うレビューに許されるのはファイルの読み取りと検索だけで、差分や PR の本文は先にファイルへ取り出して渡します。GPT 6.1 Review はツールを使わず、PR の本文を信頼しない入力として区切った形で受け取ります。Opus と GPT は、どちらもモデルを 2 回呼びます。Opus は 1 回目で問題を探し、2 回目でそれが本当かを確かめます。GPT は 2 回目で 1 回目の指摘を反証しにいき、それでも止めるべきと残った指摘は Opus がもう一度判定します。1 回目で出た指摘を、そのまま結果にしない作りです。 UX Review は、本体のリポジトリのブランチから出た PR では、差分も PR の本文も渡さずに、まずスクリーンショットだけを読ませます。初めて製品を開いた人のつもりで、各要素が何に見え、押すと何が起きそうかを書かせ、2 回目でその記録と差分を突き合わせます。fork からの PR では、この 1 回目はありません。First Principles Review は、製品の形を変える変更に、合意済み（accepted など）の RFC があるかも確かめます。RFC の status は PR 側ではなくマージ先の main から読むので、PR の中で status を書き換えても通りません。合意済みの RFC もメンテナの override もなければ、止める判定になります。 レビューの結果はレビューごとに 1 つの PR コメントとして付き、同じレビューがもう一度走ると、そのコメントが書き換わります。 指摘への答え方 止める指摘が付いたら、直して push するか、直さない理由を書いて返答します。どちらの場合も PR に返答を残すのが決まりで、マージを止めない指摘にも答える必要があります。RFC の PR では、Design Review のメモに返答していなかったことも、メンテナの Hold の理由になりました。 図3: Design Review のコメント。判定は PASS でも、Notes にメモが付くことがある。このメモにも返答する 指摘は、私が書いた範囲の本当の問題を何度も見つけてくれました。ウィンドウを選べるようにする PR では、一覧にオペレーターの拒否設定がかかっていないこと、期限切れの状態で別のウィンドウを案内してしまうことを Opus が指摘しました。RFC の PR では、まとめて実行する案が名前で禁止したツールをすり抜ける設計になっていたことを指摘されています。どれも再現テストを足して直しました。画像の修正 PR では止める指摘が 4 回続き、そのうち 1 回は前の修正で私が持ち込んだ問題でした。 ウィンドウを選べるようにする PR は、直して push するたびに次の指摘が付き、3 回続きました。2 回目には、テストが時計をワーカー全体で差し替えていることを GPT が指摘し、同じ箇所を SAST (Semgrep) のチェックも赤にしていました。3 回目には、Opus と GPT の両方が、モデルに渡す注記のアプリ名に伏せ字の処理がかかっていないことを見つけています。毎回範囲は狭まっていき、指摘の中身もはっきりしていたので、1 つずつ直しました。 一方で、直さなかった指摘もあります。GPT の指摘は、Opus がもう一度「止めるほどの問題か」を判定し、その結果も PR に書かれます。スクロールの扱いについての指摘は 2 回とも重大度が下がっていたので、直さない理由を書いて返答しました。判定の理由がそのまま返答の根拠になります。 図4: GPT 6.1 Review の指摘を Opus 5.5 が判定した部分。F2 は LOW として止めない扱いに下がり、F3 は修正が小さいので止めるのが妥当とされている AI だけでなく、人のレビュアーからもコメントが付きます。RFC の PR には、メンテナではない参加者の方から、設定名を置き換えたときに崩れた文や、索引の行が古いままになっていることの指摘が付きました。AI のレビューと同じように直して、スレッドごとに英語で返答しました。 AI の判定が明らかな誤りのときは、書き込み権限を持つ人が /ai-review override <レビュー名> <commit>: <理由> とコメントすると、その commit に限ってそのレビューを通せます。fork から出している外部の作者には権限がないので、理由を書いたうえでメンテナに頼みます。 fork からの PR fork からの PR には、リポジトリの秘密情報が渡りません。それでも AI レビューを受けられるように、Fast Gate が終わったのをきっかけに、本体の main にあるワークフローが fork の PR をレビューし、同じ名前の結果を付けます。PR 側がレビューの手順を書き換えても、動くのは main の手順です。fork からでも、すべて通れば同じように合格になります。 fork からの PR では、push のたびにメンテナが CI の実行を承認するまで、チェックが動きません。チェックがなかなか始まらないのはそのためで、PR が壊れているわけではありません。直しを小分けに push すると、そのたびに承認を待つことになります。手元で関係するテストとリントを通し、直しは 1 回の push にまとめて出すのがおすすめです。 サンドボックスやコマンドの拒否リスト、秘密情報のマスキングなど、セキュリティに関わる一部のファイルは「sensitive path」として扱われます。fork からの PR がここを触ると、承認があっても通りません。その場合はメンテナが本体のリポジトリのブランチで引き取り、元の作者を Co-authored-by: で記録し、Supersedes #<n> を付けた PR として進めます。触る予定のファイルが sensitive path に当たるかは、.github/scripts/sensitive_change_review.py の一覧で確認できます。 最後に 1 つにまとめて、承認されたらマージ ここまでの結果は PR Readiness という 1 つのチェックにまとめられ、すべて通ると PR に readiness: passed のラベルが付きます。マージの条件は、この PR Readiness と、main に必須のレビューの承認です。AI のレビューが通っただけではマージされず、承認が別に要ります。 私の最初の修正 PR では、readiness: passed が付いたあと、KiroCrewCaptain が承認して自動マージを有効にし、そのままマージされました。承認のコメントには「Tier 1 auto-approve」とあり、コンフリクトがないこと、変更の要求がないこと、セキュリティに関わるパスに触れていないこと、レビューの指摘がないことなど、確かめた条件が並んでいます。T1 の小さな修正は、こうした条件がそろえば早く入ります。 図5: 最初の修正 PR が readiness: passed から承認を経てマージされるまで（GitHub の PR のタイムラインを上から順に 3 か所切り出したもの） AI エージェントと一緒にコントリビュートする 生成 AI やコーディングエージェントは、使ってかまいません。CONTRIBUTING.md の「Using AI Tools」の節には、関わっている人の多くがコーディングエージェントで開発していて、このプロジェクト自体がそうした開発から生まれた、と書かれています。 ! ただし、エージェントに書かせても、PR の作者はあくまで自分です。CONTRIBUTING.md は、PR を出す前に、なぜ動くのかを説明でき、設計を守れて、あとで壊れたときに自分で直せるくらい変更を理解しておくことを求めています。レビュアーに 1 行ずつ説明できないなら、その PR はまだ出す段階ではない、とも書かれています。 そのうえで、エージェントに手伝ってもらう PR がマージされやすくなる点として、次の 3 つが挙がっています。 変更を小さく、1 つのことに絞る 大きな変更は、先に issue で方向を合わせる 送る前に全行を読み、不要な部分を削る 開発の手順そのものは、src/kiro_crew/builtin_skills/kirocrew-dev/ にエージェントが読めるスキルとしてまとまっています。worktree での作業は kirocrew-worktree-dev、PR を出してから CI とレビューに対応するまでは kirocrew-prepare-pr です。エージェントに頼むときは、手順を自分で説明するより、このスキルを読ませるよう案内されています。issue の探し方や切り分け、PR テンプレートの埋め方、コミットの数、CI と AI レビューへの対応といった細部は、エージェントに任せて大丈夫です。任せられないのは、何を作るかを決めることと、出来上がった変更を自分で説明できるようにしておくことの 2 つです。 私は Kiro Crew 自身にこの作業を任せました。実装と PR の作成に加えて、CI と AI レビューを 30 分ごとに確かめる監視ループも Kiro Crew に持たせ、指摘が付いたら直して push し、設計の判断が要るものだけ私に聞くようにしました。それでも、RFC の Open questions のように、メンテナに聞かれたら私が自分の言葉で答える必要がある部分は残ります。そのため RFC の author には inariku, with Kiro Crew と書き、内容は私が説明できる状態にしてから出しました。 英語でのやり取り RFC、PR の本文、レビューへの返答は、どれも英語で書きます。私は英語の下書きをエージェントに書かせ、何を直したか、なぜ直さないかが自分の理解と合っているかを読んで確かめてから投稿しました。返答に書くのは、直した commit、直した内容、足したテストの名前、手元で通したチェックくらいで、長い文章は要りません。英語が得意でなくても、内容を自分で説明できれば十分にやり取りできます。 メンテナとのやり取りは GitHub で MAINTAINERS.md には、プロジェクトについての相談はメンテナに直接連絡せず、GitHub の issue か PR で聞くよう書かれています。同じ疑問を持った次の人が答えを見つけられるようにするためです。PR でメンテナ全員をメンションするのは構わないとされています。GOVERNANCE.md も、変更を受け入れるときも断るときも、その issue や PR の上で理由を書いて決めるとしています。 私は RFC の Open questions への回答を、元の issue でメンテナ 3 人にメンションしてお願いしました。 Codex の Computer Use に近づける はじめにで書いたとおり、私が Computer Use の PR を出し始めたのは、Codex の Computer Use が使いやすかったからです。公開されている資料（OpenAI の Computer Use の API ガイド と Codex のユースケースのページ）と比べると、使い勝手に効く差は画面の見え方と、1 回の呼び出しでできる操作の数でした。 Codex Kiro Crew（2026 年 10 月 26 日時点の main） 画面の見え方 アクセシビリティツリーとスクリーンショット。画像がそのままモデルに渡る アクセシビリティツリー。スクリーンショットはファイルのパスとして渡る 1 回の呼び出しでできる操作 複数。コードを実行する形で、繰り返しや分岐も 1 回で書ける 1 つ Kiro Crew がツリーを主にしているのは、ボタンを番号で指定でき、座標を測らずに確実に押せるからです。この強みは残したまま、画像とまとめての実行を足す設計を RFC #24210 で提案しています。モデルに渡す情報やツールの形が変わるので、実装の前に RFC で合意を取る変更です。これとは別に、同じアプリの複数のウィンドウから操作するものを選べるようにする小さな変更は、issue を claim して #24203 で実装しました。 RFC はまだ合意されていませんが、議論の材料として、スクリーンショットをモデルに渡す部分の試作を Draft PR #24316 で出しました。オペレーターが設定で有効にしたときだけ、computer_get_state の応答にスクリーンショットを画像として添えます。 試作では、モデルが本当に画像を見ているかを確かめました。Preview でランダムな色と形の図形を表示し、ブランチのコードで撮ったスクリーンショットを kiro-cli に渡して、色と形を答えさせました。答えの単語がテキスト側に含まれないことも確かめています。KAS（kiro-cli の v3 エンジンで動くハーネス）では毎回正しい答えが返り、画像を添えないと「NONE」と返りました。v2 エンジンでは、今回の条件では同じ結果を確認できませんでした。そこで試作では、確認できた KAS だけを画像を渡す対象にし、ほかのハーネスは同じ確認を通してから加える形にしています。RFC の記述も、この結果に合わせて直しました。 RFC を追う issue #24212 には、triage で tier:T3 と parked のラベルが付きました。同時に付いたコメントは、「今の計画には入っていないが、ほかの人が見つけられるように開いておく。必要なら 👍 のリアクションを付けてほしい。多く求められているものから見る。設計を提案するなら RFC の手順で」という内容です。この扱いでは、issue は閉じられずに残り、要望の多さを見て優先順位が決まります。設計は RFC の PR で進められるので、私はそのまま RFC の議論を続けています。 出した PR の一覧 2026 年 10 月 26 日 16 時時点で、私が出した PR は次のとおりです。 PR 種類 内容 状態 #23631 fix Markdown プレビューで /images/... の画像が表示されない問題の修正 マージ済み #23725 RFC Git パネルのブランチ切り替え マージ済み（status は draft） #23102 feat ブランチ切り替えの実装 Draft。RFC の決定待ち #24203 feat Computer Use で、アプリのウィンドウを一覧して選べるようにする AI レビューの指摘を直し、再レビュー待ち #24210 RFC Computer Use のスクリーンショットをモデルに渡し、複数の操作を 1 回で実行する 人のレビューの指摘を直し、メンテナの判断待ち #24316 feat #24210 のうち、スクリーンショットをモデルに渡す部分の試作 Draft。RFC の決定待ち #24210 の進み具合は issue #24212 で追っています（tier:T3、parked）。 おわりに Kiro Crew へのコントリビュートは、issue の tier を見るところから始まります。T1、T2 なら /claim して実装し、T3、T4 や公開インターフェースが変わる変更なら RFC で先に設計を合意します。PR を出した後は、Fast Gate と AI レビューの指摘に対応しながらメンテナを待ちます。 手順は細かいですが、ほとんどが CONTRIBUTING.md と AGENTS.md、PR テンプレートに書かれていて、エージェントに読ませればそのとおりに進めてくれます。自分で押さえておくのは、何を作りたいかと、出来上がった変更を自分の言葉で説明できることです。私が手戻りしたのは、どれも書かれていることを読む前に動いた場面でした。エージェントに作業を頼むときは、最初にこの 3 つを読ませてください。 Kiro Crew は外部からの PR を受け付けていて、私のように使ってみて欲しくなった機能を、自分で足していくことができます。ほかのツールで便利だった機能があれば、それが Kiro Crew にあるかを確かめ、なければ issue を立てるか、tier の低い issue を claim するところから始めてみてください。コードを書く時間がなくても、欲しい機能の issue に 👍 のリアクションを付けるだけで、メンテナが優先順位を決める材料になります。大きな機能でも、RFC で設計から相談できます。レビューパイプラインが多くの問題をメンテナより先に見つけてくれるので、初めてでも出しやすいと感じました。 記事の内容に誤りがあれば、コメントで教えてください。

Kiro Crew を Windows にインストールして IAM Identity Center でサインインする はじめに こんにちは！AWS でソリューションアーキテクトをしている町田です。 Kiro Crew は、自分の PC やリモートのマシンで動き続ける、オープンソースの AI エージェントのワークスペースです。セッションをまたいで文脈を覚え、スケジュールしたジョブやバックグラウンドのタスクを、利用者が席を外している間も実行します。私は Slack から Kiro Crew とやり取りすることが非常に多くなりました。 本記事では、Windows に Kiro Crew のデスクトップアプリをインストールし、組織の IAM Identity Center でサインインして、最初のチャットを送るまで を画面つきでまとめます。 ! 個人の見解であり、所属する組織の公式見解ではありません。 本記事の内容は 2026-10-22 時点 の公式ドキュメントと、KiroCrew 0.9.0（Windows 版）の実機の画面に基づきます。Kiro Crew は更新が速いため、最新の公式ドキュメントもあわせて確認してください。 先に結論 ダウンロードは kiro.dev の Crew から。 Windows 版は KiroCrew-Setup.exe（約 560 MB）です インストーラーは既定で「現在のユーザーのみ」にインストールします。 管理者権限（UAC）は不要です 既定のエージェントは Kiro CLI で動くので、サインインが必須です。 デスクトップアプリには Kiro CLI が同梱されていて、初回起動の画面にサインイン用のコマンドが表示されます。インストーラー自体はサインインまでは行いません 組織の SSO（IAM Identity Center）なら --use-device-flow 付きのコマンドを使います。 Start URL とリージョンを入力し、ブラウザでコードを確認して許可します サインイン後は「既存のセットアップのインポート」と「カスタマイズ」を経て、メイン画面が開きます。 どちらもスキップでき、後から変更できます 全体の流れ 手順 やること 画面 1 Kiro Crew をダウンロードする ブラウザ 2 インストーラーを実行する KiroCrew セットアップ 3 Kiro CLI にサインインする Kiro Crew の初回画面、PowerShell、ブラウザ 4 既存のセットアップをインポートする（任意） Kiro Crew 5 外観と自分の役割を設定する（任意） Kiro Crew 6 チャットを送って動作を確認する Kiro Crew 前提 Kiro セットアップ完全ガイド 〜 管理者設定からエンドユーザーの利用開始まで 〜 で事前に IAM Identity Center 作成や Kiro サブスクリプションは作成済み 組織の SSO でサインインする場合は、Kiro のサブスクリプションが割り当てられた IAM Identity Center のユーザーと、次の 2 つの値 IAM Identity Center の Start URL（d-xxxxxxxxxx.awsapps.com の形式） IAM Identity Center の リージョン（本記事では ap-northeast-1） Start URL とリージョンは、Kiro の管理者に確認してください。個人の Builder ID・Google・GitHub でサインインする場合は不要です。 1. Kiro Crew をダウンロードする kiro.dev を開き、Crew の Download Kiro Crew をクリックします。 KiroCrew-Setup.exe（約 560 MB）がダウンロードされます。ダウンロードが終わったら実行します。 ! GitHub の README には、Stable・Insider・Nightly の 3 つのチャネルのダウンロードリンクがあります。特に理由がなければ Stable を選びます。アプリは、インストールしたチャネルのまま自動で更新されます（README > App downloads）。 2. インストーラーを実行する セットアップウィザードが開きます。次へ をクリックします。 インストール先のユーザーを選びます。既定の 現在のユーザーのみにインストールする のまま インストール をクリックします。 選択肢 動き 現在のユーザーのみにインストールする（既定） ユーザーのフォルダにインストールする。管理者権限（UAC）は不要 このコンピューターを使用しているすべてのユーザー用にインストールする Program Files にインストールする。管理者権限が必要 出典：Installing & Testing Kiro Crew on Windows インストールが進みます。 完了画面には、既定の Kiro エージェントには Kiro CLI のインストールと kiro-cli login の実行が必要 と表示されます。KiroCrew を実行 にチェックが入ったまま 完了 をクリックします。 3. Kiro CLI にサインインする Kiro Crew が起動すると、Kiro をセットアップする の画面が開きます。デスクトップアプリに同梱された Kiro CLI はインストール済みなので、残りはサインインだけです。 画面には、サインイン方式ごとに 2 つのコマンドが表示されます。長いパスは、同梱された kiro-cli.exe の場所です。 サインイン方式 コマンドの末尾 個人アカウント（Builder ID・Google・GitHub） login 組織の SSO（IAM Identity Center） login --use-device-flow --license pro 組織の SSO の場合は、下のコマンドの右にあるコピーボタンでコピーし、PowerShell に貼り付けて実行します。パスは環境ごとに違うので、自分の画面に表示されたコマンドをそのまま使います。 powershell.exe -NoProfile -Command "Set-Item Env:KIRO_NO_AUTO_UPDATE 1; & '<インストール先>\KiroCrew\resources\backend-dist\kiro-cli\kiro-cli.exe' login --use-device-flow --license pro" ! 画面の説明にあるとおり、サインインページでは個人用の Builder ID が組織の SSO と並んで表示されます。Builder ID でサインインすると、使えるモデルが少なくなります。 組織で契約している場合は、組織の SSO を選んでください。 Start URL とリージョンを入力する Enter Start URL と表示されたら、IAM Identity Center の Start URL を入力します。 続けて Enter Region にリージョン（本記事では ap-northeast-1）を入力します。ブラウザが開き、ターミナルには確認用のコード（Code: XXXX-XXXX）が表示されます。 ブラウザでサインインして許可する ブラウザで IAM Identity Center のサインイン画面が開きます。ユーザー名を入力して 次へ をクリックします。 パスワードを入力して サインイン をクリックします。MFA を設定している場合は、続けて MFA の画面が出ます。 認証がリクエストされました の画面で、表示されたコードが ターミナルに表示されたコードと一致すること を確認し、確認して続行 をクリックします。一致しない場合や、自分で始めたサインインでない場合は キャンセル します。 Kiro CLI がデータにアクセスすることを許可しますか？ の画面で アクセスを許可 をクリックします。 リクエストが承認されました と表示されたら、ブラウザのタブは閉じて構いません。 ターミナルに Logged in と表示されれば、サインインは完了です。 Kiro Crew の画面に戻り、サインインを再確認 をクリックします。サインインが確認されると、次の画面に進みます。 4. 既存のセットアップをインポートする（任意） Kiro Crew は、同じ PC にある他のエージェントのセットアップを探して、取り込めるものを表示します。取り込める対象は、手順・メモリ・ワークスペース・MCP サーバー・スキル・スケジュール・安全設定です。画面の説明にあるとおり、取り込みはマージのみで、認証情報はそのまま です。 本記事の環境では、Claude Code のセットアップが 51 件見つかりました。取り込むソースにチェックを入れて 続行 をクリックします。取り込まない場合は インポートをスキップ をクリックします。今回は インポートをスキップ をクリックしました。 5. 外観と自分の役割を設定する（任意） 外観を選択 の画面で、モード（System・Light・Dark）と配色テーマを選び、続行 をクリックします。 Kiro について教えてください の画面で、自分の役割と技術的な習熟度を選び、続行 をクリックします。ここで選んだ内容によって、Kiro の説明の仕方（平易な言葉か、技術的な詳細か）が変わります。設定はこの PC に保存され、設定 → チャット からいつでも変更できます。 どちらの画面も、右上の すべてをスキップ で飛ばせます。 6. チャットを送って動作を確認する メイン画面が開きます。下の入力欄にメッセージを入力して送信し、応答が返ってくることを確認します。 入力欄では、次の書き方が使えます（入力欄のプレースホルダーの表示より）。 書き方 用途 /command コマンドを実行する @file ファイルを参照する $skill スキルを呼び出す ! シェルコマンドを実行する 応答の下には、その応答で使ったクレジットと時間が表示されます。左のメニューからは、セッション・スケジュール・アーティファクト・アプリ（発見・ライブラリ・Task Runner）・ターミナル・スマホとの接続・設定を開けます。 つまずきやすい点 インストールしただけではエージェントは動きません。 完了画面の案内どおり、Kiro CLI へのサインインが必要です。初回画面のコマンドを実行した後、サインインを再確認 を押し忘れないようにします コマンドは画面からコピーします。 同梱の kiro-cli.exe のパスは、インストール先やユーザー名で変わります Builder ID と組織の SSO を取り違えない。 サインインページには両方が並びます。組織の契約で使うなら、Start URL を入力する --use-device-flow のコマンドを使います ダウンロード直後に SmartScreen の確認が出ることがあります。 インストーラーは署名されていますが、新しいビルドは SmartScreen の評価が貯まるまで確認が出ることがあります（Windows install guide） アンインストールしてもデータは残ります。 セッション・メモリ・設定がある ~/.kiro/crew は消えません。データも消したい場合は手で削除します（同上） まとめ Kiro Crew の Windows 版は、KiroCrew-Setup.exe を実行するだけでインストールできる。既定は現在のユーザーのみで、管理者権限は不要 既定のエージェントは Kiro CLI で動く。CLI はアプリに同梱されているので、初回画面のコマンドでサインインするだけでよい 組織の SSO は login --use-device-flow --license pro。Start URL とリージョンを入力し、ブラウザでコードを確認して許可する インポートとカスタマイズは任意。後から設定で変えられる

オープンソースで使えます kirodotdev/KiroCrew #jawsug_tokyo

Is This How Frontend Developers Work Now? My 2026 Coding Setup Software development is moving fast! The same setup I had six weeks ago, is not the same I have now. In fact, I've been doing software development on my phone! Just last week I was on vacation at Yellowstone, and I built an app from my phone. I chatted with an agent, it pushed the code to GitHub, and I reviewed the PRs. It was wild! !My game This post walks through the setup that makes that work. It runs on a server in my house, and I can reach it from anywhere. {% embed youtube.com %} Full disclosure, I'm a developer advocate at AWS, and a couple of the tools here are Kiro tools. The box: a TrueNAS home lab Years ago I bought an old Intel Xeon server and loaded it with hard drives. It's been my home lab ever since, running TrueNAS. For this setup I created a new Ubuntu VM on it called Kiro Crew and do all my coding there. I went with Ubuntu 24.04 for the long-term support. 26 was an option, but 24 does everything I need. You don't need a TrueNAS server for this. I've seen people buy a Mac mini or reuse an old machine, and an EC2 instance or any cloud VM works too. I like keeping it local so everything sits on my own network. What I installed After the VM was up, I SSH'd in and installed four things. - Kiro CLI. Any coding harness that runs on a remote server and lets you authenticate there will work. Most of them do now. - Kiro Crew. This is the agent I actually talk to. It works like a personal assistant for developers, with sessions, artifacts, memories, skills, and scheduled tasks. OpenClaw, Pi, and OpenCode are other options people run on remote servers. - The GitHub CLI, so the agent can push code and open PRs. - Tailscale, so I can reach the server from anywhere. Connecting from my phone with Tailscale Tailscale puts the server, my laptop, and my phone on the same private network. Wherever I am, I open Tailscale on my phone, SSH into the box with a mobile SSH app, and port forward the Kiro Crew dashboard. I use port 5477 for mine. The Kiro Crew docs cover remote setup, and the remote and mobile guide goes through SSH tunnels and phone access step by step. You could use something like CloudFlare tunnels for this as well. Connecting from my laptop with SSH port forwarding From my laptop it's a single SSH command with local port forwarding: ssh -L 5477:localhost:5477 YOUR_USER@YOUR_SERVER Then I open a new connection window and point it at that port. (I also installed Kiro Crew locally on my Mac Laptop, so I can connect to Kiro Crew locally or to a remote instance) For security, Kiro Crew wants a token before it lets you in. On the server, run: kirocrew token It prints a link with a token in it. Open that, and you're talking to your Crew instance. Working in Kiro Crew !Kiro Crew Dashboard Sessions live along the side of the dashboard. When I start a new one, I usually turn on trust mode so the agent stops asking for approval after every step. That isn't a good idea for everything. For the personal projects I'm building, I'm comfortable with it. !Trust mode Then I tell it what to do. In the video I had it pull down a repo I already had. As we go back and forth, it sends me screenshots of what it's building, and it can spin up a dev server so I can look at the running app. By default it put that project in a scratch folder. Normally I pick the working folder I want before I start. The artifacts tab collects the screenshots and files from all my other projects too, so I can check on things I'm not actively working on. Memories and skills Memories are new in Kiro Crew. I told it to always use Vue.js, because I'm a huge Vue fan. I also installed a set of skills, so every new project starts with the same defaults. Reviewing stacked PRs on GitHub I always tell the agent to push to GitHub. When I want to be careful, I ask for a stacked PR. GitHub's stacked PR interface works well with coding agents. It breaks a large update into smaller layers, and you review each one on its own. !Image description For a fun project I'll accept the whole stack. For anything else I go through it layer by layer, make changes, and go back to Kiro Crew with something like "please update the PR, this code isn't what I want." Then we go back and forth until it's right. The next thing I'd add is CodeRabbit, which reviews PRs automatically before you merge. I don't have it on this project yet. Building from my phone on vacation When I was at Yellowstone National Park last week, I wanted to try an ASCII library I'd seen on Hacker News. I asked Kiro Crew to build an app with it, and it created everything. I did all of it from my phone. Tailscale got me onto my network, I chatted with the agent, it pushed to GitHub, and I checked the PRs. It worked really well. I can also give it one prompt, turn on trust mode, walk away, and come back half an hour later to see everything it's done. Models and effort levels I switch between Claude Opus 5.5 and GPT 5.6 Sol. Opus 5.5 works better for me and what I'm building, so that's my default. !Models I've also been testing different effort levels, including high. I don't have a clear answer there yet, so your mileage may vary. Specs and parallel sessions When I want to be very specific, I use spec-driven development mode. Kiro Crew has a spec builder built in. (You can enable it in the "Discover" apps section) !Spec Builder Most of the time, though, I open three or four sessions and let them run in the background while I do other things. Scheduled tasks and Discord I'm trying to do more speaking, so I set up a weekly CFP finder. It runs on a schedule and sends me a message with what it found. !Scheduled tasks Kiro Crew is also connected to my own Discord channel and posts there. So I can either use Tailscale and port forwarding to open Crew on my phone, or I just open Discord and read the messages as they come in. What does your setup look like? This is how I'm building apps right now. A server at home runs the agent, my phone and laptop connect to it, and code reaches me as stacked PRs I can review. Is this what your future looks like? Have you been running agents remotely, or is everything still happening in your editor? Let me know in the comments.