プロダクト複数席のチーム · herdr-only を推奨 · intent-cli v0.32.0

ひとこと頼む。コーディングエージェントがバックグラウンドでオーケストレーションチームを作る。

このページは、複数のユニットを同時に進めたいときの複数席のチーム向けです。多くの作業は 1 スレッド + subagent で十分に回るので、まずそちらのページをご覧ください。製品の対話は今の会話に残すことも、設計専用の herdr ペインに置くこともできます。ガイドはセットアップと安全のコマンドを出し、コーディングエージェントまたは運用担当者が実行して配信構成を記録し、準備状態を検証します。判断や許可が必要なときは止まり、intent-cli は決定論的なコマンド出力と状態検証に留まります。

まずは 1 スレッド + subagent から最初のエージェントチームを作る→herdr-only のセットアップガイドを読む

収録済みのセットアップ記録 · herdr-only

ひとこと頼む。herdr-only チームが形になる。

この既存の収録は、空のワーカーペイン 3 つから始まります。コーディングエージェントが intent-cli のセットアップ契約に従い、約10分で動くオーケストレーションチームへ組み上げます。47秒・15倍速のセットアップ記録であり、v0.32.0 の架空の記録ではありません。

15×タイムラプス47s動画の長さ≈10m実作業3ワーカーの役割

イベントソーシングフレームワーク Sekiban の実際のチームセットアップを収録。設計の対話はワーカーの作業場所の外に残ります。

コーディングエージェントにこのまま頼む

<owner>/<repo> の作業を herdr-only の 4 スレッド team で始めてください。
intent-cli の bootstrap guide を使い、各 seat の CLI/model と application kind を私に確認し、command だけを出してください。
私が承認した後に herdr・provider・scheduler の command を実行します。topology を記録・検証し、最初の検証済み handoff を報告してください。

01
設計は今の会話にも herdr にも置ける
製品の意図を今の会話に残すことも、設計専用の herdr ペインを置くこともできます。
02
3 つのワーカーの役割が herdr に現れる
オーケストレーター / 実装 / レビューが専用ペイン・フォルダーで起動します。
03
構成と稼働状態を検証する
intent-cli が指定された対応関係を記録・検証し、エージェントが準備完了の引き継ぎを報告します。

役割分担: herdr を操作し、選んだ AI プロバイダーを起動するのはコーディングエージェントです。intent-cli は決定論的なワークフロー契約を提示・検証します。認証情報・信頼・権限の判断が必要なら処理は止まり、バックグラウンドで勝手に許可しません。

intent-cli がまだない場合は、ワンコマンドで導入してから上のプロンプトをコーディングエージェントに渡せます。導入して最初のチームを作る →

herdr-only 4 スレッドのチームv0.32.0 · RELEASED

1人間との対話側 · 外部のままでもよい

設計

意図・パケット・製品判断

herdr作業場所 · 役割ペイン · 起動 · 稼働状態 · 監督

オーケストレーター

状態を検証し、準備済みの 1 件を委譲

実装

ループなしの受信側: Issue を 1 件実装

レビュー

ループなしの受信側: 意図と照合

session transport · v0.32.0herdr-only範囲を限定した配信と完了報告

正本intent-cli + GitHub意図・キュー・Issue・PR・CI

同じ環境に集まるチームには依存の少ない herdr-only を推奨します。agmsg + herdr は非推奨ですが引き続き動作し、未記録時の既定値です。どちらのトランスポートも主経路ではありません。

インタラクティブ実演

1 つの意図スライスがチームを進む様子を見る

準備済みパケットから検証済みクローズアウトまで、運用契約を約 30 秒で追えます。

herdr workspace見える役割 · 稼働状態 · 監督

01設計意図 · パケット · 判断実行中

02オーケストレーター検証 · 委譲 · クローズアウト監督中

03実装1 Issue · 1 PR監督中

04レビュー意図 · 証拠 · 判定監督中

STEP 01

1 つの意図パケットを準備完了にする

正本の入力: Intent ツリー + 製品判断
チームの動作: 意味・優先順位・受け入れ境界を確定。
検証済みの出力: レビュー可能な準備済みパケット

intent-cli v0.32.0 では、依存の少ない herdr-only を同じ環境に集まるチームに推奨します。agmsg + herdr は非推奨ですが引き続き動作し、何も記録しない場合の既定値です。どちらのトランスポートも主経路ではありません。正本は引き続き intent-cli と GitHub です。

運用ステータス

見える 1 つのチーム。選ぶセッション層は 1 つ。

RECOMMENDED · v0.32.0 · RELEASED

herdr-only のセッショントランスポート

依存が少ないため、同じ環境に集まるチームに推奨します。herdr に配信・完了・監督が見えます。

TEAM SHAPE

4 スレッド、明確な境界

設計は人間との会話側にも専用ペインにも置け、herdr が見えるチームを監督します。

CANONICAL

intent-cli + GitHub

決定論的な案内、構成の検証、キュー、Issue、PR、CI、クローズアウトが引き続き正本です。

DEPRECATED

agmsg + herdr

v0.32.0 で非推奨になりました。引き続き動作し、トランスポート未記録時の既定値のままなので、移行時は herdr-only を明示的に記録してください。削除は利用者の確認後に予定されています。

v0.32.0 の現在機能

リリース済みの契約を一か所に

リリース済みの基準

intent-cli v0.32.0 が現在の安定版です。チームは 3 つのチームモードから 1 つを記録します。solo-conductor(1 スレッド + レビューごとに新しい subagent。おすすめの始め方)、delivery(複数のユニットを同時に進める複数席のチーム)、authoring-only です。3 スレッドのタイマーループも対応する代替手段として残ります。

導入経路

npm i -g intent-system で intent-cli コマンドを導入でき、.NET SDK は不要です。.NET のグローバルツールは JTechJapan.IntentSystem.Cli です。intent-cli update は実行ファイルのパスから更新チャネルを決めます。

別ランタイムによるレビュー

[[cross_runtime_review.teams]] で宣言したチームでは、宣言に並べたリポジトリで、PR の承認に別のランタイム(Codex・Claude・Cursor・Copilot・OpenCode)による判定が現在の head コミットに対して必要になり、publish-flow にはパケットへの設計レビューの判定が必要になります。intent-cli はプロンプトを出して判定を記録するだけで、レビュアーを起動しません。これらのゲートはセキュリティ境界ではありません。

受け入れと監督

ガイドを優先する出荷ルールにより、ガイドへの経路がない、または誤っている機能は出荷しません。監督はチームごとの宣言制([supervision] opt_in_teams)で、エスカレーション前に同じサイクル内で発見事項を照合します。

セッションの選択肢

同じ環境に集まる複数席のチームには、依存の少ない herdr-only を推奨します。agmsg + herdr は非推奨です。引き続き動作し、何も記録しない場合の既定値のままです。どちらのトランスポートも主経路ではありません。使っている Orca Run を、席または solo チームに結び付けて記録できます。

ファイル保存型の配信

delivery_method: file-backed を宣言すると、永続的で参照可能なタスク封筒を保存し、1 行のポインターを届けます。宣言しなければ、配信は本文埋め込みのままです。

名前付きブランチレーン

レーンは registry/default または明示的な packet draft --lane の選択から決まります。これはリリース済みの preview-through-1.x 機能であり、1.0 互換性保証ではありません。パケットは branch_lane と routing_snapshot を記録します。intent-cli はレーンを提案・記録しますが、ブランチの作成や管理はしません。

複数人で使う Git 連携の担当宣言

.intent-cli/claims/ の不変な Git 連携レコードを使い、claim acquire と claim verify を実行します。これはリリース済みの preview-through-1.x 機能であり、1.0 互換性保証ではありません。通常の push に成功した人だけが担当宣言を所有するため、ひな形作成の前に担当宣言を行い、作業前に所有権を検証します。

プロンプト分類と対象範囲

プロンプトポリシーはリテラルなプロンプト分類と対象を絞った承認を使い、answerable_by、上書きできないリスク下限、実行中の対話に対する比較交換（compare-and-swap）を含みます。これはリリース済みの preview-through-1.x 機能であり、1.0 互換性保証ではありません。未知または一致しないケースは推測せず、エスカレーションします。

authoring-only のチームモード

team_mode=authoring-only では、コードを書かずに意図を整理して Issue を公開できます。エージェントが意図を聞き取り、パケットを作成します。実装は別のチーム・人・ベンダーが担えます。このモードに配信構成や配信担当席はなく、既定の delivery mode のままです。authoring-only では配信監督は対象外です。これはリリース済みの preview-through-1.x 機能であり、1.0 互換性保証ではありません。

コマンド出力の境界: intent-cli は決定論的な案内を出し、ワークフローの状態を記録・検証します。承認後に herdr・プロバイダー・スケジューラーを実行するのは、コーディングエージェントまたは運用担当者です。intent-cli はそれらを起動せず、herdr を操作せず、スケジューラーを登録しません。

4 つの役割

設計が意味を持つ

人間と AI が意図、パケット、優先順位、リリース範囲、判断を要する決定を形にします。

オーケストレーターが流れを持つ

intent-cli と GitHub の正本状態を読み、準備済み作業を公開し、1 件を委譲し、返ってきた担当宣言を検証します。

実装とレビューを分離する

ループを持たない受信側は専用フォルダーで動きます。レビュアーは実装者の説明ではなく、パケットと意図に対して PR を照合します。

メッセージは起動を促すが、正本にはならない

herdr-only モードでは、コーディングエージェントまたは運用担当者が記録済みの構成と herdr を使って範囲を限定した作業を届け、完了を戻します。agmsg + herdr は非推奨ですが引き続き動作します。正本は GitHub と intent-cli です。

評価フレーム

エージェント・オーケストレーションを運用保証で評価する

エージェント数や並列実行は簡単に実演できます。実作業をセッションをまたいで安全に進められるかは、次の 8 軸で評価できます。

意図の永続性

Intent ツリーとパケットが、エージェントのセッションをまたいで作業の理由を保持します。

正本状態

ペイン・メッセージ・エージェントの担当宣言ではなく、intent-cli と GitHub がワークフローの状態を定義します。

役割の構造的分離

設計・オーケストレーション・実装・レビューの権限と作業場所を分離します。

稼働性の検証

ペイン・稼働中の接続・その時点の一連の往復を確認します。

成果物を先に確認する完了

完了メッセージではなく、PR・テスト・CI・実動作が完了を証明します。

不明時は安全側で停止

所有権・準備状態・結果が曖昧なら設計または運用担当者に戻します。

マージ後の書き戻し

次のスライスを選ぶ前に、クローズアウトが正本の意図の状態を更新します。

プロバイダーに依存しない

intent-cli は決定論的な案内を返し、AI プロバイダーの起動や選択は行いません。

セッション層

チーム全体が herdr にいるなら herdr-only を選ぶ

4 役割のモデルと権限境界はトランスポートが変わっても同じです。変わるのは、具体的な作業をどう届け、観測し、完了を返すかです。

経路	現在地	委譲・完了通知	向いている場面
herdr-only	v0.32.0 · リリース済み · 推奨	intent-cli が論理上の役割 → 記録済みの作業場所とペインを解決し、herdr が範囲を限定した作業と完了報告を運ぶ。	構成要素を減らし、見える監督と同一マシン上の複数チームの分離を求める場合。
herdr + agmsg	非推奨 · 動作継続 · 未記録時の既定値	herdr が作業場所を監督し、agmsg が委譲の信号と返信を運ぶ。	herdr-only へ移行するまでの既存の agmsg チーム。

どちらのトランスポートも主経路ではなく、複数席のチームだけが唯一の構成でもありません。1 席で solo-conductor を使うこともできます。v0.32.0 では、使っている Orca Run を席に記録すること(session-layer topology record-orca-run)、チームごとに別ランタイムでのレビューを必須にすること、監視役をチーム単位で宣言することもできます。ドメイン／リポジトリごとにトランスポートとドライバーモードを 1 つ選び、intent-cli のコマンド出力の境界を保ちます。 v0.32.0 のリリースノートを読む →

AI エージェントから始める

「herdr-only モードで作って」と頼む

ガイドは正規のセットアップ・安全ゲート・構成書き込み用コマンドを提供します。承認後に herdr と選んだプロバイダーを実行するのはコーディングエージェントまたは運用担当者で、intent-cli はプロバイダーを起動せず herdr も操作しません。設計の対話を続けながら、エージェントから検証済みの引き継ぎまたは判断依頼の報告を受け取れます。

<owner>/<repo> の作業を herdr-only の 4 スレッド team で始めてください。
intent-cli の bootstrap guide を使い、各 seat の CLI/model と application kind を私に確認し、command だけを出してください。
私が承認した後に herdr・provider・scheduler の command を実行します。topology を記録・検証し、最初の検証済み handoff を報告してください。

安全境界

複数席のチームでは、1 つのドメイン／リポジトリで使うドライバーモードは orchestrator-message かタイマーループという代替手段のどちらか 1 つです。混在させません。1 席の solo-conductor は、1 つの conductor 席がユニットの各手順を順に進める、別の team shape です。
オーケストレーターは準備済み作業を調停します。意図、製品の方向性、リリース範囲、意味に関わる判断を作りません。
受信側の起動報告は担当宣言であり、証明ではありません。ペインと稼働中の接続を確認し、その時点の一連の往復を要求します。
曖昧または読めない状態では安全側で停止し、推測せず設計または運用担当者に戻します。

現在のガイドにある監督・タイムアウト・一時停止ポリシーに従います。ポーリングは観測補助であり、記録済みの担当宣言や検証済みの引き継ぎの代わりにはなりません。

あなたのリポジトリで始める

このモデルを、検証済みの最初のチームにする

コーディングエージェントとセットアップチェックリストを生成し、アーキテクチャを確認できます。実地導入が必要なら、あなたのワークフローを J-Tech Japan にご相談ください。

最初のエージェントチームを作る→v0.32.0 のリリースノート導入を相談する