PR のレビューをセッションに伝える

プルリクエストの CI が落ちたり、レビューで変更を求められたりしたら、その PR を出したセッションに Agent Fleet が知らせて、修正と push を促します。あなたが気づくまで、セッションが止まったままになることがなくなります。

全体像

あなたがやること	エージェントがやること
設定で「PR へのフィードバックをセッションに伝える」をオンにする	PR の CI の失敗やレビューの指摘を受け取り、直して push する
マージのコンフリクトは、通知を見て自分で判断する	—
（設定は要らない）	気になる PR を自分で見張り、変わったら知らせてもらう

オンにする

⚙設定 →「エージェント」 の「セッション」で、「PR へのフィードバックをセッションに伝える」をオンにします。画面はセッションから子セッションを起動するにあります。

あなたが頼まなくてもターンを使い、停止中のセッションを起動するので、既定ではオフです。

伝える内容

出来事	伝え方
最新のコミットで CI が失敗した	そのコミットのチェックがすべて終わってから、失敗したチェックの名前をすべて並べて伝える。push したコミットごとに 1 回まで
レビューで変更を求められた、未解決のレビュースレッドが増えた	PR ごとに 3 回まで
マージのコンフリクト	セッションには伝えず、通知センターの「プルリクエスト」に届く。編集より先に、ベースをどうするかの判断が要ることが多いため
アーカイブ済みのセッション宛て	通知センターに届く

セッションには、[agent-fleet:notice kind=pr-feedback reply=none] で始まる行として届きます。会話には、あなたの指示ではなく Agent Fleet からのお知らせとして印が付きます
伝えた内容は Agent を再起動しても覚えているので、同じことを 2 回伝えることはありません

どのセッションに伝えるか

各セッションがいるブランチのプルリクエストを見ます
セッションが「起動のもとになった」「作った」「作業中」として持つ PR リンクも、最大 5 件まで見ます。GitHub と Bitbucket の両方が対象です
レビューや見守りのためだけに PR を持つセッションには伝えません
同じ PR を複数のセッションが持つときは、つながりの強いセッションに伝えます。起動のもと、作った、作業中の順で、同じ強さなら新しいほうです

いつ伝えるか

セッションが待機していて、入力を受け付けられるときだけ送ります
作業中のセッションや、あなたの返事（質問・プラン・許可）を待っているセッションには、手が空くまで送りません
停止中のセッションは、起動してから伝えます。 あなたが止めたセッションも同じです。起動は 1 つずつです

セッションが自分で PR を見張る

エージェントは、プルリクエストを繰り返し確かめに行く代わりに、変わったら知らせてもらうよう頼めます。設定は要らず、いつ使うかはエージェントが決めます。

af ツール	すること
`watch`	プルリクエスト（`owner/repo#45`、自分のリポジトリなら `#45`、または GitHub の URL）と、知りたい出来事を渡して見張る
`list_watches`	見張りを一覧する
`unwatch`	見張りを 1 つ終える

見張れる出来事は、チェックが終わった、マージのコンフリクトが起きた、マージできる状態になった、マージされた・クローズされた、レビューで変更を求められた、未解決のレビュースレッドが増えた、などです。プルリクエスト自体が削除された（リポジトリごと消えた、アクセスを失った）場合は、期限まで待ち続けず、その旨の知らせを送って見張りを終えます。一時的な GitHub のエラーやレート制限で終わることはありません。

GitHub と Bitbucket に対応しています。 プルリクエストはあなた自身の接続で読むので、見張れるのはあなたの接続で読めるものだけです
いつ伝えるかは PR へのフィードバックと同じです。頼んだ時点ですでに起きていることは、すぐに伝えます
フィードバックと二重にはなりません。 PR へのフィードバックがオンでも、自分の PR のチェックの失敗・変更の要求・未解決スレッドの増加を見張っているセッションには、それを見張りからだけ伝え、見張りが終わったあとも PR へのフィードバックから繰り返しません。見張っていないものは、これまでどおり PR へのフィードバックから届きます
セッションには [agent-fleet:notice kind=watch で始まる行として届きます。プルリクエストから来た文（チェックの名前、レビュアーの名前）は引用符で囲み、指示ではなくデータだと印を付けます

CI の実行（GitHub Actions と Bitbucket Pipelines）

プルリクエストに紐づかないワークフローの実行（夜間やリリースのワークフロー、エージェントが手で起動したもの）も見張れます。エージェントはプルリクエストの代わりに実行かワークフローを渡し、種類には ci.run.completed（終わった実行すべて）か ci.run.failed（失敗だけ）を指定します。この 2 つの種類は GitHub でも Bitbucket でも同じなので、1 つの指定で両方に使えます。従来の github.workflow_run.completed / github.workflow_run.failed も同じ意味で使え、両方の綴りを指定しても 1 つの実行は 1 回しか伝えません。これらにプルリクエスト用の種類は使えず、断られます。

GitHub Actions:

ref 知らせるとき

実行の URL（https://github.com/o/r/actions/runs/123、/attempts/2 を付けてもよい）または o/r:run/123 その実行が終わったとき。すでに終わっている実行はすぐに伝えます。見張りがまだ続いているあいだ（エージェントが期限まで続けるよう頼んだ場合）は、実行の再実行を新しい試行として改めて伝えます。試行を指定した見張りはその試行だけを伝え、既定の見張りは最初の知らせで終わります

o/r:cli-pin-bump.yml、ブランチを付けるなら o/r:cli-pin-bump.yml@main そのワークフローの次の実行が終わったとき。見張りを作ったあとに始まった実行だけが対象で、その時点で実行中だった実行や終わっていた実行では知らせません。ブランチを付けなければ、すべてのブランチ・イベントの実行が対象です。絞るには @main のように付けます。ブランチを指定できるのは o/r:file.yml@branch の形だけで、ワークフローの URL では指定できません。見張りより前からあった実行の再実行は知らせません。その実行を直接指定してください。ついさっき自分で起動した実行を追うときも、その実行を指定してください

`ref`	知らせるとき
実行の URL（`https://github.com/o/r/actions/runs/123`、`/attempts/2` を付けてもよい）または `o/r:run/123`	その実行が終わったとき。すでに終わっている実行はすぐに伝えます。見張りがまだ続いているあいだ（エージェントが期限まで続けるよう頼んだ場合）は、実行の再実行を新しい試行として改めて伝えます。試行を指定した見張りはその試行だけを伝え、既定の見張りは最初の知らせで終わります
`o/r:cli-pin-bump.yml`、ブランチを付けるなら `o/r:cli-pin-bump.yml@main`	そのワークフローの次の実行が終わったとき。見張りを作ったあとに始まった実行だけが対象で、その時点で実行中だった実行や終わっていた実行では知らせません。ブランチを付けなければ、すべてのブランチ・イベントの実行が対象です。絞るには `@main` のように付けます。ブランチを指定できるのは `o/r:file.yml@branch` の形だけで、ワークフローの URL では指定できません。見張りより前からあった実行の再実行は知らせません。その実行を直接指定してください。ついさっき自分で起動した実行を追うときも、その実行を指定してください

ワークフローはあなた自身の GitHub 接続で読みます。接続で読めないリポジトリや実行は、頼んだ時点で断ります。あとから実行が削除された場合（またはリポジトリへのアクセスを失った場合）は、待ち続けず、その旨の知らせを送って見張りを終えます
2 回の確認の間に多数の実行（最大 100）が始まるワークフローも全部読むので、新しい実行の陰で先に終わった実行も見逃しません。それを超えた分のうち古いものは次の確認まで待ちます
「あと」かどうかは、このワークスペースの時計ではなく、GitHub 自身の実行番号とタイムスタンプで決めます
知らせには、実行番号・試行・結果が入ります。ワークフローの名前と、失敗したジョブの名前・リンクは、チェック名と同じく引用符で囲んだデータとして渡します
読み取りは条件付き（変わっていなければリクエスト枠を使いません）で、実行が待機中・実行中のあいだは短い間隔で読み、上限はプルリクエストの見張りと同じものを数えます

Bitbucket Pipelines も同じ形で、source に bitbucket を指定します（bitbucket.org の実行 URL なら不要です）。

`ref`	知らせるとき
実行の URL（`https://bitbucket.org/w/r/pipelines/results/123`）または `w/r:run/123`	その実行が終わったとき。すでに終わっている実行はすぐに伝えます
`w/r:pipelines`、カスタムパイプラインなら `w/r:pipelines/nightly`、ブランチなら `w/r:pipelines@main`、両方なら `w/r:pipelines/nightly@main`	（そのカスタムパイプライン・ブランチの）次の実行が終わったとき。見張りを作ったあとに始まった実行だけが対象です

停止（キャンセル）または期限切れの実行は、GitHub Actions のキャンセルと同じく失敗として扱います。知らせには実行番号と結果が入り、ブランチと失敗したステップの名前は引用符付きのデータです
Bitbucket は 1 時間あたりのリクエスト数が少ないため、1 つのワークスペースで持てる Pipelines の見張りは最大 5 件で、実行中はおよそ 1 分に 1 回、次の実行を待つあいだは 5 分に 1 回確認します。Bitbucket 接続に Pipelines を読む権限が必要で、足りないときはエージェントに再接続を促します
新しい実行かどうかは Bitbucket 自身のビルド番号とタイムスタンプで決め、ブランチの探索はリポジトリの直近 250 件までです。非常に忙しい実行の陰にある静かなブランチは見逃すことがあります

親に知らせを届ける

ほかのセッションが起動した子は、知らせを親に届けるよう頼めます（notify: parent）。子のプルリクエストの知らせを、作業を配っている親のセッションが受けられます。

見張りは親のものになります。親が一覧して終わらせ、子ではなく親がアーカイブされたときに終わります
知らせには、どの子のためのものかが書かれます

タイマー

エージェントはタイマーも設定できます（watch の source: time）。「20 分後に知らせて」「15:00 JST に知らせて」のような使い方です。時刻は UTC で保持され、エージェントは、オフセット付きの時刻（2026-11-09T15:00:00+09:00）か、待ち時間（in 20m、3d）のどちらかを渡します。先は最長 30 日です。

ワークスペースが動いている間は、タイマーはワークスペース内で発火し、プルリクエストの場合と同じ方法でセッションに伝えます
wake を付けると、その時刻にワークスペースが止まっていれば Control Plane に起動してもらい、そのうえで伝えます。起動するだけで、プロンプトは送りません。起動後は、ふだんどおり再び止まることもあります。Control Plane のスケジューラ（定時実行の機能）が動いている必要があり、動いていない環境では、受け付けて発火しないままにせず、エージェントの依頼を断ります
wake なしで、ワークスペースが止まっている間に時刻になったタイマーは、次の起動のときに「遅れて」と印を付けて伝えます。それまでに見張りの期限が切れていれば捨てます（タイマーは、時刻の 1 日後まで生きます）
wake のために作る予約は、「定時実行」の一覧には出ず、そこから編集もできません。タイマーが発火したとき、エージェントが見張りを終えたとき、見張りを持つセッションが終わったときに消えます
list_watches には、各タイマーの時刻と、wake の有無が出ます

見張りの上限

決まり	値
見張りが終わるとき	最初の知らせで終わる（エージェントが続けるよう頼んだときを除く）。どの場合も 7 日（最長 30 日）か、持ち主のセッションがアーカイブされたとき
1 つのセッションが持てる数	20。親に届ける見張りは、親の 20 と、子が自分で持つ見張りと合わせた子の 20 の両方に数える（どの子が作ったかは `list_watches` に出る）
ワークスペース全体	200
`wake` 付きのタイマー	未実行の起動予約は、メンバーごとに 250 まで（そのメンバーの全ワークスペースで共有）
Bitbucket の見張り	ワークスペースで 10 まで。約 5 分ごとに読む（Bitbucket の 1 時間あたりのリクエスト上限に収めるため）
Bitbucket Pipelines の見張り	ワークスペースで 5 まで。上の PR の見張りとは別に数える

Bitbucket では、未解決のレビュースレッドの増加は見張れません。どのスレッドが解決済みかを Bitbucket が返さないためです
Bitbucket でマージできる状態とみなすのは、誰かが承認していて、変更を求める人がいないときです
見張りは Agent を再起動しても残ります

Webhook で早く知る

見張りは常に、あなた自身の接続によるポーリングで読む。管理者が Webhook を足すと、Control Plane が次の周期を待たずに「このプルリクエストを今読んで」と Workspace に伝える。 Webhook が Workspace に運ぶのは「このプルリクエストが変わった」という合図だけで、データは渡さず、停止中の Workspace を起こすこともない（停止中の Workspace は起動時に追いつく）。

公開リポジトリ: デプロイの GitHub App の Webhook を設定してあれば（AF_GITHUB_WEBHOOK_SECRET、設定リファレンス）、公開リポジトリの配信で見張りが早くなる。
プライベートリポジトリ: デプロイ共通の App は全テナントで共有なので、プライベートリポジトリの配信は無視する。プライベートリポジトリには、あなたのテナントの Webhook（リポジトリのフック、またはテナント自身の GitHub App。Bitbucket は常にこれ）が必要。なければ見張りはポーリングのまま（数分以内の遅れ）。Workspace からは af-watch-hook で作れる。

プライベートリポジトリにフックを足す

af-watch-hook add github owner/name      # Bitbucket は: af-watch-hook add bitbucket workspace/name
af-watch-hook list
af-watch-hook rm <id>

add は Control Plane にフックを作り、あなた自身の接続（設定 > 接続）でリポジトリに登録する。以後、プルリクエスト・レビュー・コメント・チェックの出来事が Workspace の見張りに合図を送る。フックの秘密は GitHub / Bitbucket にそのまま渡し、表示も保存もしない。rm はリポジトリ側と Agent Fleet 側の両方から消す。

リポジトリの管理者権限が要る。 GitHub は repo（または admin:repo_hook）スコープの classic トークン、または Webhooks: Read and write の fine-grained トークン。Bitbucket は Webhooks スコープとリポジトリ管理者。足りなければ add がそう伝え、何も残さない。リポジトリの管理者に頼むか、ポーリングのままにする
デプロイに公開 URL が要る。 なければ外部のサービスがフックに届かない
すでにフックのあるリポジトリに add しても何も変えない。 やり直すには rm してから add する
自分の GitHub App: App の設定に貼る Webhook の秘密は一度表示する必要があるが、af-watch-hook は秘密を表示しない。表示できるようになるまでは、App が要らない af-watch-hook add を使う
GitHub Enterprise Server と Bitbucket Data Center は対象外