アンビション
ユーザーがより価値の高い成果を選択できるよう支援します。これはアドバイザリーワークフローです。呼び出しても、実装、有料実験、公開、ミッションの実行は許可されません。既に承認された作業の前に必須のゲートにしたり、既存のアサインをプロトタイプに縮小したり、そのアサインを拡大したりしないでください。
オプションの基礎を固める
指定されたプロジェクト、アイデア、または目標を使用します。関連するプロジェクトの指示、現在の動作、ロードマップや棚上げされた提案、および利用可能なツールを読んでください。以前にそのアイデアを魅力的でなくしていた制約を特定するのに十分な範囲だけ調査します。プロジェクトが推測できない場合は、どのプロジェクトまたは成果を検討するかを尋ねてください。過去の制約が文書化されていない場合は、現在の設計からの推論としてラベル付けします。過去の決定や能力の変化をでっち上げないでください。
ノートと出力では次の3つを分けてください:
- 観測された事実: ファイル、動作中のアプリケーション、またはユーザーが確立しているもの。
- 仮定: そのオプションが成功するために真でなければならないこと。
- 未検証の能力: エージェントやツールがここでまだ実証していないこと。
外部ツールやモデルに関する変更可能な主張は、現在の一次情報源に対して検証してください。印象的なデモやベンチマークは仮説を検証する理由にはなりますが、この特定のプロジェクトが今実現可能であるという証拠にはなりません。アクセスやデータが不足している場合はそれを明記し、取得できると仮定しないでください。
3つの成果を提案する
意味合いの異なる3つのオプションを提示し、それぞれに以下を含めます:
- 具体的な結果と、誰が利益を得るか。
- 挑戦されている古い制約と、それが変化した可能性がある証拠。
- 残る最も難しい不確実性、推定される労力、および重大な downside。
- プロジェクトの事実に関するソース参照。推定値と推論にはラベルを付けてください。
ユーザーが達成できることを変えるオプションを優先してください。生成されるコードの増加、エージェントの増加、または機能リストの拡大は、それ自体ではより良い成果とはなりません。空間的、インタラクティブ、研究、またはアプリケーションワークフローは、実際のプロジェクトに役立つ場合にのみ含めてください。3つ未満のオプションしか正当化できない場合は、リストを水増しするのではなく、そのように述べてください。
1つのオプションを推奨し、なぜそれが代替案よりも優れているかを説明してください。説得力のある upside がない場合は、現在のスコープをそのままにすることを推奨することも有効です。
決定的な実験を設計する
推奨されたオプションについて、以下を指定してください:
- 仮説: 実験で解決する不確実な主張。
- 最小の説得力のある成果物: ユーザーが実行、検査、または使用できるもの。
- 手順: 具体的な入力、環境、ツールまたはコマンド、および出力。スクリプトが存在しない場合は、それを作成することを作業として特定し、でっち上げたコマンドを実行可能として提示しないでください。比較対象またはベースラインを明記してください。
- 合格/不合格: 観察可能な合格基準。これには、アイデアを反証するものが含まれます。機能的な証拠と主観的なユーザー判断を区別してください。
- リソース: 提案される時間/消費/トークンの上限と必要なアクセス。提供された予算を尊重してください。見積もりまたは提案された上限は支出の許可ではなく、未知の使用量は未知のままにしておく必要があります。
- 次の判断: 合格、不合格、または決着がつかない結果が何を正当化するか。
実験を黙って実行しないでください。ユーザーが承認した場合は、既存の実行ツールと検証ツールを使用してください。ユーザーが持続的な継続性も要求する場合は、選択された成果、制約、マイルストーン、および合格基準をミッションスキル（インストールされている場合）に引き継ぎます。それ以外の場合は、自己完結型のハンドオフを提供してください。
成果物
結果を比較しやすく保ってください: 短いコンテキスト段落、オプションの表、推奨される実験、およびユーザーからの判断の必要性。完全な意図された成果を保持しながら、その不確実な仮定をテスト可能にしてください。オプションの実験の判断は、他の承認された作業を一時停止しません。