AgentDock – 協調型要件発見スキル

AgentDock ブレインストーミング

非交渉の計画契約

「構築」「実装」「修正」「リファクタリング」「進めてください」といった依頼は、計画を終了する許可ではありません。タスク作成の同意も、実装の承認ではありません。

すべての非自明なタスクにおいて、最初のリクエストの後、ユーザーは実装開始前に少なくとも一度は応答しなければなりません。明確化が不要な場合、その応答は以下で説明する最終計画サマリーを承認するものでなければなりません。

ユーザーが所有する製品、スコープ、UX、互換性、リスク、または受け入れ判断のいずれかが未解決のままである場合、ターンを終了する際に最も価値の高い質問を一つだけ行ってください。製品コードの編集、実装のディスパッチ、task.py startの実行は行わないでください。

非交渉の証拠ルール

コードベースを調査することで回答できる質問がある場合は、代わりにコードベースを調査してください。

これは必須です。ユーザーに質問する前に、まずその回答がコード、テスト、設定、ドキュメント、既存の仕様、またはタスク履歴にすでに存在するかどうかを確認してください。

リポジトリが回答できる事実を確認するようユーザーに求めないでください。調査後も曖昧なままである、製品意図、好み、スコープ、リスク許容度、受け入れ動作、または判断についてのみ質問してください。

リポジトリの証拠は現在の動作と技術的な制約を明らかにします。ユーザーの意図する動作、機能スコープの境界、UXの好みは、リポジトリの証拠だけでは決して回答できません。既存のパターンがあったとしても、それらは選択肢と推奨の証拠であり、決定ではありません。

---

このスキルは、フェーズ1の計画中に、ユーザーのリクエストを明確な要件と計画成果物に変換するために使用します。

前提条件

このスキルは、タスク作成の同意が得られ、ユーザーがAgentDock計画に入る準備ができた後にのみ使用してください。

タスクがまだ存在しない場合は、作成します：

TASK_DIR=$(python3 ./.trellis/scripts/task.py create "<短いタスクタイトル>" --description "<一行の概要>" --slug <スラッグ>)

ユーザーのリクエストから簡潔なタイトルを使用してください。タイトルと--descriptionの両方が空であってはなりません。createは空文字を拒否し、どちらかが空のレコードはアーカイブ時に拒否されます。日付プレフィックスなしのスラッグを使用してください。task.py createは自動的にMM-DD-ディレクトリプレフィックスを追加します。

task.py createはデフォルトのprd.mdを作成します。フォローアップの質問をする前に、そのファイルを現在の理解で更新してください。

計画フロー

1. ユーザーのリクエストと初期の既知の事実をprd.mdに記録します。
2. 質問をする前に、利用可能な証拠を調査します：
   • コード、テスト、フィクスチャ、設定
   • READMEファイル、ドキュメント、既存の仕様、ドメインノート
   • 関連するAgentDockタスク、調査ファイル、およびセッション履歴（存在する場合）
3. 見つけたものを次のように分類します：
   • 確認済みの事実
   • ユーザーからまだ必要な製品意図
   • ユーザーからまだ必要なスコープまたはリスクの判断
   • スコープ外と思われる項目
4. ユーザーが所有する判断が残っている場合は、最も価値の高い質問を一つだけ行い、推奨事項とトレードオフを含めてから停止します。同じターンで実装作業を行わないでください。
5. 各ユーザーの回答後、prd.mdを更新し、判断インベントリを再計算して、ステップ2から繰り返します。
6. ユーザーが所有する判断がなくなったら、複雑なタスクのためにdesign.mdとimplement.mdを作成または更新します。
7. 要件収束ゲートを実行し、次にPRD収束パスを実行します。
8. 最終計画サマリーを提示して停止します。同じターンでtask.py startを実行したり、製品コードを編集したりしないでください。
9. その後のユーザーメッセージが最新の計画サマリーを明示的に承認した場合にのみ、task.py startと実装が許可されます。承認後に成果物が大幅に変更された場合は、最終レビューを繰り返します。

プロジェクト固有の製品/仕様階層を発明しないでください。リポジトリにすでに製品、ドメイン、または仕様ドキュメントがある場合は、それらを使用してください。ない場合は、存在する証拠に基づいて進めてください。

質問ルール

メッセージごとに質問は一つだけ行ってください。

各質問には以下を含める必要があります：

• 必要な判断
• その答えが重要な理由
• 推奨する回答
• ユーザーが異なる選択をした場合のトレードオフ

検索、ファイル調査、ブレインストーミングの継続などのプロセスに関する質問は行わないでください。証拠の作業は直接行ってください。残っている問題が製品決定、好み、スコープ境界、またはリスク許容度の選択である場合にのみユーザーに質問してください。

推奨事項はデフォルトの選択ではありません。ユーザーが実装を依頼したという理由だけで、ユーザーに代わって推奨される製品決定を選択しないでください。

リクエストとリポジトリの証拠ですでにすべての判断が解決されている場合は、明確化のための質問をでっち上げないでください。その場合は、直接最終計画サマリーに進んでください。これには、その後の明示的な承認が依然として必要です。

最終レビューは必須のフェーズ移行ゲートであり、禁止されたプロセス質問ではありません。タスク作成の同意、最初の実装リクエスト、および最新の最終サマリーの前に与えられた承認は、このゲートを満たしません。

思考フレームワーク：第一原理分析

要件が曖昧な場合、解決策が過剰にエンジニアリングされているように感じられる場合、または「みんながやっているから」という理由で複雑さを追加しようとしている場合に、基本的な真実に分解してから上向きに推論してください。

ステップ1：問題を言い換える

実装の詳細を取り除いて、一文にします。

悪い例：「ユーザープロファイルエンドポイントにRedisキャッシュを追加する必要がある」 良い例：「ユーザープロファイルデータの読み込みに時間がかかりすぎる」

ステップ2：基本的な真実をリストする

絶対に真実なことは何ですか？（意見や慣習ではありません）

カテゴリ	例
物理的制約	ネットワークレイテンシ ≥ 0、ディスクI/Oには限界がある
ビジネスルール	「ユーザーは自分のデータを見なければならない」
技術的不変条件	「データは一貫していなければならない」
ユーザーニーズ	「ユーザーはY秒以内にXを望んでいる」

ステップ3：前提を疑う

現在の計画の各構成要素について：

• 事実か慣習か？ 「私たちはいつもRESTを使っている」— なぜ？
• これを削除したらどうなるか？ 何も壊れなければ、不要である。
• 実際の問題を解決しているのか、それとも症状か？ 因果連鎖をたどる。
• この複雑さの恩恵を受けるのは誰か？ 「誰もいない」なら、簡素化する。

ステップ4：真実から構築する

1. すべての真実を満たす最小限の実行可能なメカニズムから始める
2. 特定の真実がそれを要求する場合にのみ複雑さを追加する
3. 各追加は「どの真実がこれを必要とするのか？」に答える必要がある

ステップ5：検証する

• 解決策は元の問題を解決するか？
• どの前提を検証する必要があるか？
• これをテストするための最も簡単な実験は何か？

要件収束ゲート

最終レビューの前に、以下がすべて満たされていることを確認します：

• ユーザーの成果と製品価値が明示されている
• スコープ内とスコープ外の動作が明示されている
• 受け入れ基準が観察可能な成果を記述している
• ユーザーが所有する製品、スコープ、UX、互換性、リスクの判断が解決されている
• ブロックしている未解決の質問がない
• 技術的な未知数が調査されているか、MVPの動作を変更せずに明示的に延期されている

軽量タスクはdesign.mdとimplement.mdを省略しても構いませんが、証拠調査、要件収束、最終レビュー、新たな実装承認をスキップしてはいけません。

最終計画サマリーには、目標、スコープ内、スコープ外、受け入れ基準、主要な決定、関連するリスクまたは延期項目、成果物ステータスを示す必要があります。

成果物ルール

prd.mdは要件と受け入れを記録します：

• 目標とユーザー価値
• 確認済みの事実
• 要件
• 受け入れ基準
• スコープ外
• 計画をまだブロックしている未解決の質問

design.mdは複雑なタスクの技術設計を記録します：

• アーキテクチャと境界
• データフローと契約
• 互換性と移行に関する注意事項
• 重要なトレードオフ
• 運用またはロールバックに関する考慮事項

implement.mdは複雑なタスクの実行計画を記録します：

• 順序付けられた実装チェックリスト
• 検証コマンド
• リスクのあるファイルまたはロールバックポイント
• task.py start前のフォローアップチェック

軽量タスクはprd.mdのみを持つことができます。複雑なタスクはtask.py startの前にprd.md、design.md、implement.mdを持たなければなりません。

implement.mdはimplement.jsonlの代わりにはなりません。サブエージェントディスパッチワークフローでは、task.py startの前にimplement.jsonlとcheck.jsonlの両方に少なくとも1つの実際の仕様/調査エントリが含まれている必要があります。空のマニフェスト、またはレガシーな_exampleプレースホルダ行のみを含むものはカウントされません。インラインワークフローは、フェーズ2がtrellis-before-devを通じてコンテキストをロードするため、このJSONLゲートをスキップします。

PRD収束パス

計画の準備ができたと宣言したり、task.py startを実行したりする前に、上記の成果物ルールで説明されている最終構造に対してprd.mdを一度書き直します。これはオプションのクリーンアップではなく、最終計画ゲートです。

パスはロスレスでなければなりません：

• 繰り返された事実を1つの信頼できるセクションにまとめる。
• 「既に知っていること」「前提」「解決済みの未解決の質問」などの一時的なブレインストーミングセクションを、目標、背景、要件、技術メモ、または受け入れ基準に折り込む。
• 解決済みの未解決の質問は、空のセクションや既に回答済みのセクションを残さずに削除する。
• 同じ作業を説明する並列のバグリストと要件リストをマージし、各欠陥の重大度、証拠、およびファイル:行アンカーを所有する要件に保持する。
• すべてのファイル:行アンカー、決定、制約、要件ID、および受け入れ基準マッピングを保持する。
• ブロックしている未解決の質問が残っている間は、最終レビューに進まない。

パスの後、prd.mdを上から下まで読み、新しい情報を追加しない限り、セクション間で事実が繰り返されていないことを確認します。

品質基準

計画の準備ができたと宣言する前に：

• prd.mdにテスト可能な受け入れ基準が含まれている。
• prd.mdがPRD収束パスを通過している：未解決の一時的なブレインストーミングセクション、セクション間の重複した事実、失われたアンカー、決定、受け入れマッピングがない。
• リポジトリで回答可能な質問は、すでに調査を通じて回答されている。
• ブロックしている未解決の質問がない。
• 複雑なタスクにはdesign.mdとimplement.mdがある。
• サブエージェントディスパッチタスクには、implement.jsonlとcheck.jsonlの両方に実際のキュレーションされたエントリがある。シードのみのマニフェストは準備できていない。
• 最新の最終計画サマリーがユーザーに提示されている。
• その後のメッセージで、ユーザーがそのサマリーを実装のために明示的に承認している。

ユーザーが最初に実装を依頼したという理由だけで実装を開始しないでください。