追加指示とやり直し

ずれの指摘テンプレ

『なんか違う』ではなく、気づいたことを具体的に返しましょう。『料金ページの見出しが意図より大きい。元サイズに戻し、文言変更だけ残して』のように、残すもの / 戻すものを分けると伝わりやすいです。

Desktop の手元 Agent なら、会話を消さずにファイルだけ戻す Checkpoints もあります（when-desktop）。Cloud Agent では、このレッスンのとおり『残す / 戻す』を追記するか、PR を閉じる方が本線です。

PR コメントでもやり直しできる

Agent 画面に戻らなくても、GitHub の PR に `@cursor 見出しだけ元に戻して、文言変更は残して` とコメントすれば、同じ系統の修正ループに入れます。Slack のスレッドで `@Cursor` に追記するのも同じ考え方です。

『自分が作った PR』でも、『同僚の PR の CI を直して』でも使えます。誰の変更かを確認してから頼みましょう。

レビューコメントの解決を Agent に頼む

同僚や Bugbot から diff 上にレビューコメント（インライン指摘）が付いたときも、Pull Request への `@cursor` コメントや、Cursor for iOS の PR レビュー画面から Agent に解決を頼めます。公式のモバイルガイドでも、レビューコメントの解決と失敗した Check の修正が、同じレビュー画面からできると説明されています。

自分の PR なら、Agent 画面に戻らなくても PR 上で完結できます。同僚の PR をレビューしながら『この指摘を直して』と頼むときは、誰の変更かを確認してからにしましょう。

Agent に『待って続けて』と頼む（Subscriptions）

Cloud Agent の仕事は、コミットや PR 作成で終わりではありません。レビューが付く、CI が走る、Slack で返事が来る、長いジョブが終わる——こうしたあとに、毎回『続けて』と書き直す代わりに、Agent にイベントを待たせて同じ会話の文脈で自動再開させる仕組みがあります（公式の Subscriptions）。

購読（subscription）は1つの Agent 会話に紐づきます。イベントが来ると follow-up として同じ会話に届き、Agent は PR・スレッド・Issue を読み直してから動きます。複数のイベントが続けて来たときは、1回にまとめられて起動することもあります（公式の coalesce）。購読は最大180日続き、条件が満たされたら Agent 自身が解除することもあります。

ダッシュボードで『待っているのに再開しない』ときは、Cursor Cloud MCP の get-message-queue で未処理のフォローアップがキューに残っていないか確認できます（いま実行中のメッセージは含まれません）。詳しくは実行環境レッスンの MCP 節（/learn/environments-and-secrets#environments-and-secrets-s19）を参照してください。

切り分けの目安: ① 条件がまだ満たされていない（CI が赤い、Checks が黄色（pending）のまま、レビュー未承認など）② 購読が180日で切れた、または Agent が自分で解除した ③ フォローアップがキューに残っている（get-message-queue で確認）。①なら待つか条件を見直し、②なら新しい Agent を起動、③ならキューが空になるまで待つか詳しい人に相談、という流れで十分です。

GitHub の CI 待ちは、そのコミットの Checks が全部終わるまで1つの結果（成功、または失敗した Check 名）を待ちます。テスト自体は緑でも、人が承認するまで黄色（pending）のままの Check が1つあると、全体の結果が届かず Agent は起きません。公式の対処は、その Check を pending のままにせず、GitHub の action_required（要対応）で完了させることです。要対応でも必須 Check ならマージは止まるので、待ちは進みつつ、反映の安全は保てます（公式 Cloud Agent capabilities）。

待てる主なきっかけは、GitHub（1つの PR だけ・保管庫全体・特定の作者の PR、およびブランチ単位の CI 結果）、Slack（スレッド返信・チャンネルメッセージ・新しい公開チャンネル）、Linear（Issue の作成・状態変更・新しいコメント）、タイマー（一定時間後や cron 形式の定期）です。

開いた PR を見守って直してほしいだけのときは、Subscriptions を自分で組み立てるより `/autopilot` が短いです（review-and-merge のマージまで任せるレシピ。公式 Agent Skills）。Subscriptions は Slack 返信や Linear、タイマーなど、PR 以外の待ちにも使います。

• PR を開いて、レビューコメントと CI が通るまで緑を保ち続ける
• Slack で質問し、返信が来たら同じ会話で続ける
• 長いジョブのあと、30分後に再確認させる
• 定期ループなら `/loop` スキル（ビルトイン）も使える
• 開いた PR を見守るだけなら `/autopilot` が短い（Subscriptions は PR 以外の待ちにも使う）
• Linear: Issue の作成・状態変更・新しいコメントを待つ（コピペ例は下の callout）

GitHub の待ち範囲（1 PR / 保管庫全体 / 特定作者）

GitHub の Subscriptions では、待ちの幅を3段階で選べます（公式 capabilities）。マージまで任せるときは1 PR だけに絞るのが安全です。保管庫全体は要約や通知向け、特定作者は Automation PR（cursor 名義）の追従向けに使い分けます。

• この PR だけ（マージ任せ向け）: 『この PR のレビューと CI を待って続けて。マージできる状態になったら要約だけ返して』
• 保管庫全体（要約・通知向け）: 『このリポジトリで新しい PR やレビューが付いたら短い要約を Slack に。コード変更はまだしない』
• 特定作者の PR: 『cursor が開いた PR だけ待って続けて』。範囲が広いほど wake が増えるので、マージ任せでは1 PR 指定が安全

Slack スレッドでのやり直し

Slack では、議論のあとで `@Cursor このスレッドの結論どおりに直して` と頼む使い方がよくあります。Agent はスレッド全体を文脈として読めます。

すでにそのスレッドに自分の Agent がいるときは、同じ `@Cursor …` が追記指示になります。別件を始めたいときは `@Cursor agent …`。複数の Agent がいるときは、返信の ⋯ から Add follow-up で相手を選べます。

Microsoft Teams でも、チャンネルのスレッドでは `@Cursor` 追記が使えます。個人チャットやグループチャットの続きは、カードの Open in Web / Open in Desktop です（公式 Microsoft Teams。first-cloud-agent の Microsoft Teams 節）。

止め時とエスカレーション

同じ点で3回以上すれ違う、権限や本番データが絡む、課金や個人情報に触れる。こうしたときは一人で押し切らず、詳しい人に相談しましょう。

Agent は速いですが、組織の最終責任は人側に残ります。迷ったら立ち止まるのも立派な判断です。

作業中の追加指示は、途中で切らない

Agent が動いているときに送る追加指示には、公式に2通りあります。① いまの仕事が終わってから読む（キュー）② 次の道具呼び出しのタイミングで方向を変える（steering）。

cursor.com/agents では、入力して Send now、または Enter を2回押すと、いまの一手を途中で止めずに次の道具呼び出しで届きます。ターンのあとまで待たせたいときは Tab でキューに入れます（公式 Agent overview。Agents Window にも順次公開）。Desktop のエディタ側では、Enter はキュー、Cmd+Enter（Windows は Ctrl+Enter）がすぐ送る、という公式の案内もあります。すぐ送ると、直前の自分のメッセージに追記されます。画面によってキーが違うので、『途中で止めずに舵を切る』か『あとで読む』か、目的で選んでください。

慌てて『違う！』と送っても、ファイルの途中保存が壊れにくい、というのがポイントです。すぐに全部止めたいときだけ、もう一度 Enter（CLI）や明示的な停止を使います。CLI では作業中の Enter が安全な区切りで舵を切り、もう一度 Enter でそのターンを止めます（Desktop の Enter＝キューとは逆なので注意）。