ゴール

ゴールは、宣言された条件が満たされるまで Qwen Code をターンを超えて稼働させ続けます。/goal <objective> で設定すると、セッションは自律的に稼働を続けます。各ターンは証拠として記録され、モデルが objective の完了またはブロックを提案すると、独立した検証ツールが証拠のみからその提案を判定します。セッションは検証ツールが受け入れた時点、またはゴールが一時停止、クリア、もしくは制限によって停止された時点で終了します。

コマンド

ゴールの作成、編集、または再開には信頼されたワークスペース（/trust）が必要です。ヘッドレスでの利用方法は ヘッドレスモード を参照してください。

ゴールがターンを請求した後、フッターのピルとすべてのステータスカードには、許可されたウィンドウに対して消費した量が 1.2k/30.0m の形式で表示されます。この数値はゴールが自身のターンで行ったモデル呼び出しをカウントします。サブエージェントと検証ツール自身のチェックは含まれません。ウィンドウは model.goalTokenBudget で設定されます。ウィンドウを使い切ったゴールを再開すると、すでに消費した分に加えて新しいウィンドウが付与されるため、数値はリセットされず 30.0m/60.0m のように表示されます。予算がないゴールは消費量のみを表示します。まだターンを請求していないゴールは数値を一切表示しません。

デフォルトでオフの2つのウィンドウが利用可能です。model.goalMaxTurns はゴールが完了できるターンの上限を設定します（ユーザー主導のゴールターンを含みます）。model.goalMaxActiveMinutes は実行中のプロセスでアクティブである間の経過時間上限を設定します（ターン間の待ち時間やアイドル時間を含みます）。ゴールが一時停止、ブロック、または停止されている間の時間は後者にはカウントされず、再起動をまたいだダウンタイムもカウントされません。単にサスペンドされているプロセスは引き続き課金されます。どちらのウィンドウが先に尽きても、ゴールは同じ1回の終了ターンで引き渡しを行い、その後再開されるまで停止します。再開すると、すでに使用済みの分に加えて別のウィンドウが許可されます。尽きたウィンドウのみが移動し、他のウィンドウはそのまま残り、-1 のオプトアウトもすでに消費した上限を取り除くだけです。時間ウィンドウはターンの間で読み取られ、タイマーによって強制されないため、ゴールは停止前によくそれを超えて実行できます。すでに実行中のターンが中断されることはなく、ターンが実行されていない間に尽きたウィンドウは次のターンが終了するまで気づかれません。アクティブ時間は記録された遷移の間でカウントされるため、再起動が中断したターンの時間は課金されません。いずれの設定への変更も再起動後に有効になります。両方のウィンドウは変更後に作成されたゴールにのみ適用されるため、すでに記録されているゴールを制限するには /goal set で置き換えます — リビジョン1の新しいゴールとして、ターン、トークン、アクティブ時間のメーターがリセットされ、証拠ウィンドウが置き換えから始まるため、古いゴールが記録した証拠は引用できなくなります — またはクリアしてやり直します。再開や編集は、作成時に設定されていなかった上限を追加することはありません。

セッションが自律的に実行する各ターンは、ゴールがこれまでに消費した量、背後に何ターンあるか、および（ゴールが無制限でない限り）許可されたウィンドウを報告します。最終的な終了ハンドオフを除くそのようなターンには、以前のターンの報告を信頼せずワークスペースを再確認すること、objective が求める終了状態に向けて作業すること、直前のターンが何も変更しなかった場合は別の方法を試すこと（2 ターン目以降、判断対象となる直前のターンがある場合）、およびゴールが完了したと提案する前に引用可能な証拠照合をすべての要件に対して行うこと、という指示が伴います。

長いゴールは、記録した証拠をサイドモデル呼び出しでチェックポイントの主張に定期的に圧縮し、後のターンと検証ツールがそれを引用できるようにします。この呼び出しは model.goalCheckpointTimeoutSeconds で制限され、デフォルトは 180 秒です。マークダウンフェンスで囲まれた応答はフェンスなしで読み取られます。主張が合計バイト予算を超えた場合、1 つの主張が主張ごとの文字数制限を超えた場合、1 つのチェックポイントが保持できる数を超えた場合、リクエストになかった id を引用した場合、または引用するソースの proof kind を変更した場合、何が間違っていたかを名指しする修正用のモデル呼び出しが 1 回行われ、両方の呼び出しがその上限を共有します。空でない claims 配列を保持する JSON オブジェクトでない応答には修正呼び出しは行われず、利用可能な主張の横であっても不正な形式の主張を含む応答にも行われません。いずれのレベルにも余分なキーがある場合、認識されない proofKind、空の主張、または空の sourceRefs リスト、非文字列または空の id を保持するもの、id を繰り返すもの、32 個を超える id を保持するものがこれに該当します。時間内に完了しないチェックは、結論の出ないものとして放棄されます。証拠ウィンドウがオーバーフローした場合にのみチェックポイントの停滞制限にカウントされ、オーバーフローしないチェックは連続を維持し、後のターンで再試行されます。この呼び出しはストリーミングされるため、リクエストごとのトランスポートタイムアウトは接続と最初の応答のみを制限し、上限自体はストリームガードの 15 分間のライフタイムキャップで停止します。それを過ぎると、設定ではなくガードが呼び出しを終了します。設定の 15 分制限は固定であり、ストリームガード自身のキャップを上げてもそれは上がりません。

失敗したチェックポイントはゴールが停止する前に表示されます。アクティブなゴールの停滞連続が続いている間、フッターのピルは自動的に checkpoint N/3 stalled に切り替わります。ゴールが一時停止または停止すると、ピルはそのステータスを代わりに表示します。Web Shell のゴールステータスストリップはステータスに関わらずカウントを表示します。/goal や一時停止、再開、検証ツールのカードなどで終端ゴールのステータスカードがレンダリングされるたびに、ゴールが許可する3回のうち何回連続でチェックが停滞したかと、記録されている場合は最後の失敗が一緒に表示されます。Web Shell のゴールダイアログとヘッドレスの /goal テキスト出力も同じ行を表示し、Web Shell のゴールイベントのトランスクリプトカードは停止理由のみを表示し、モデルはゴールを読み取るときに両方のフィールドを確認します。ウィンドウにまだ余裕がある間に失敗したチェックも表示されますが、停滞を消費せず、ゴールがアクティブな間、またはその失敗自体がゴールを停止させた場合（送信には大きすぎるチェックポイントリクエストなど）にのみ表示されます。他の理由によるチェックポイント停止は失敗をクリアし連続を保持し、完了したゴールはチェックポイント行を表示しません。失敗は制御文字を除去した単一行として保持されます。3回の停滞チェックポイントで停止したゴールは最後のチェックポイントが遭遇した問題を名指しします。チェックポイント主張の範囲内でウィンドウに収まらなかったチェック（証拠を残した完全な主張リスト、または主張数やサイズの予算を超えた主張）は、objective が1つのウィンドウが保持できる以上の証拠を生成することを意味するため、objective を狭めます。主張に折りたためなかった応答は、チェックポイントモデルが要求された構造化出力を返していないことを意味し、objective を狭めても修正できません。応答がなかったチェックは、到達できないまたはレート制限されたプロバイダー、model.goalCheckpointTimeoutSeconds 以内に完了しなかったチェック、またはチェック自体のエラーを意味する場合があります。記録された失敗がどれであるかを示します。3つのいずれかの後に再開すると、新しい証拠ウィンドウが始まります。

ゴールの中断

ゴールのターンをキャンセルすると、ゴールは一時停止します。モデルが応答中またはツールが実行中のときに Esc を押すと、ターンが停止し、ゴールは paused に移動し、カードと /goal の両方が停止理由を表示します。/goal resume を実行するまで何も継続しません。

ゴールがアクティブな間にメッセージを入力しても一時停止にはなりません。あなたのメッセージは次のゴールターンとして実行されるため、作業の方向付けに使用します。停止するには /goal pause または /goal clear を使用します。

すべての一時停止はその理由を示します。あなたが中断した、/goal pause を実行した、セッションのトークン制限が次のモデルリクエストをブロックした、ターンが失敗した、または 3 ターン連続で検証ツールが判定できる何も記録せず提案もなかった（get_goal、update_goal などのゴールの記録操作は進捗としてカウントされません）といった理由です。制限によって停止されたゴールは、その制限の理由をそのまま保持します。

ゴールの判定方法

検証ツールは独自にコマンドを実行したりファイルを読み取ったりすることはありません。トランスクリプトにすでに存在するもののみを確認します。

• 表示されたアシスタントの出力とツールの結果が証拠としてカウントされます。objective のテキスト、あなた自身のプロンプト、およびモデルの非表示の推論は証拠になりません。
• 出力されたテキストは、テキストが出力されたことのみを証明します。テストがパスした、ファイルが変更された、またはリモートが更新されたという主張には、トランスクリプトに対応するツールの結果が必要です。
• あなたが確認、選択、または承認したという主張には、あなたからの実際のメッセージが必要です。検証ツールはそれを想定する提案を拒否します。
• 証拠がない場合、判定は「完了」ではなく「まだ」になります。誰も証拠を示せない条件は、制限が停止するまでループを継続させます。

したがって、objective はエージェントに証拠を生成させるものでなければなりません。名前付きチェックを実行し、決定的な出力を表示させます。

良い objective の書き方

objective に以下の内容を、この順序で含めます。

1 つの objective に収めます。/goal set と /goal edit は任意の長さを受け付けますが、おおよそ 1,200 文字以内に留めてください。objective はゴールのターンごとに再送されます。propose_goal 経由でモデルが提案する objective は 1,500 文字に制限されます。どちらのコマンドも改行をスペースに折りたたむため、改行に頼らず項目を番号付けします。

Budget は、いつ停止してブロッカーを報告するかについてのモデルへの指示です。モデルがそれに従うとは限りません。ランタイム自体をターン数や時間で停止させるには、ここではなく設定で model.goalMaxTurns または model.goalMaxActiveMinutes を設定します。objective にいずれかを書いてもそれらは設定されず、ゴールのトークン予算も変更されません。

/goal-draft に書かせる

/goal-draft <what you want done> は、上記を代わりに行うバンドルされたスキルです。スコープと実際の検証コマンドを確立するためにワークスペースを必要最小限読み取りますが、テストの実行、ビルド、依存関係のインストール、サービスの起動は行いません。重要な選択が不明確な場合、最大 1 ラウンドの質問を行い、その後コンパクトな objective を書き、通常 3〜5 個の完了チェックを付けます（十分な場合はそれ以下）。明示的な要件は保持され、数に達するためにチェックが追加されることはありません。

監査の場合、完了とは合意されたシナリオをカバーし、確認された欠陥の再現手順を含めて証拠を報告することを意味します。欠陥が見つからないことは有効な結果です。ドラフトはシナリオ、証拠ファイル、探索ラウンド、または欠陥の最小数を発明すべきではありません。

成功基準、コマンド、入力パス、または重要な決定を確立できない場合、スキルは <TODO: …> 項目付きの「Needs clarification」とマークされたドラフトを返します。そのドラフトの承認を求めたり、実行可能な /goal set または /goal edit コマンドを出力したりすることはありません。重要でないデフォルトは [ASSUMPTION] とマークされ、欠落した成功基準の代わりにはなりません。

objective の準備ができると、インタラクティブターミナルまたは Web Shell のセッションでは後述の propose_goal 承認ダイアログを表示できます。ゴール提案サポートを持たないクライアント、ヘッドレス実行、ツールが無効なセッション、アクティブなゴールを持つセッションには、代わりに手動で実行するためのコマンドが返されます。引き渡し時には、ドラフトがまだ適用されていないことが伝えられます。スキル自身が作業を開始することはなく、あなたの承認なしに何も設定されません。

既存の objective を渡して絞り込むこともできます: /goal-draft all tests pass and the lint is clean。アクティブなゴールに対して、明示的に絞り込みを要求すると /goal edit が生成され、置き換えには /goal set が使用されます。意図した操作が不明確な場合、スキルは単一の質問ラウンドでその選択を含めます。

モデルが提案したゴールを承認する

インタラクティブターミナルまたはアタッチされたクライアントを持つ Web Shell のターンでは、モデルは propose_goal ツールを持ちます。/goal-draft が完了したとき、または複数のターンにまたがる成果を求めたときに、コピー用の /goal set … 行を出力する代わりに objective を提案できます。提案は完全な objective を表示する承認ダイアログとして現れます。承認すると、現在のターンが終了した時点で /goal set とまったく同じようにゴールが設定されます（モデルが acknowledge して停止し、最初のゴールターンが自動的に開始されます）。却下すると何も設定されません — モデルはツール呼び出しが許可されなかったことのみを確認し、理由を尋ねず、同じ objective を再度提案しないよう指示されます。承認はそれを要求したターンに紐付けられます: そのターンがキャンセルされるなどして終了に到達しなかった場合、承認は後のメッセージや自動ターンの下で適用されるのではなく破棄されます。権限ルールや承認モード（YOLO を含む）もこのダイアログをスキップすることはなく、別のゴールがアクティブな間、プランモード中、および信頼されていないフォルダ内ではツールが拒否します。サブエージェントには決して提供されません。Web Shell は既存の Allow/Reject 権限パネルを使用します。停止されたゴールは、承認用に表示されたバージョンと一致する場合にのみ置き換えできます。変更すると提案は無効になります。ヘッドレス実行、Web Shell のチャネル配信および自動ターン、および必要な承認とターンライフサイクルサポートを持たない ACP クライアントでは、出力された /goal set の引き渡しが保持されます。

ユーザー設定の goals.modelProposed: "disabled" でオフにできます。この設定はモデルが自律ループの開始をあなたに求められるかどうかを決定するため、ユーザースコープとシステムスコープからのみ適用されます。ワークスペースの .qwen/settings.json の値は警告とともに無視されます。

このスキルは読み取り専用として指示されており、非変更ツール（get_goal、read_file、glob、grep_search）のみが自動承認されます。ask_user_question は意図的に自動承認されないため、スキルがあなたの回答からドラフトする前に質問ダイアログが表示されます。他のバンドルスキルと同様に、goal-draft という名前のプロジェクトまたは個人スキルがこれをオーバーライドし、skills.disabled でオフにできます。バンドルスキルの検出方法については スキル を参照してください。