discuss

ディスカッション

インタビューを始める前に、プロジェクトのルートを特定し、該当するリポジトリの指示を読みます。docs/wiki が存在する場合は、ルートインデックス、メンテナンスルール、ユビキタス言語、最も関連性の高いインデックス、および関連する概念を読み、現在受け入れられている状態をディスカッションに反映します。docs/backlog が存在する場合は、そのルートインデックスとトピックに関連する記録も読み取り専用で確認し、既存の提案作業、関連性、および優先順位を質問に反映します。また、引き継ぎ時に重複提案ではなく既存の記録を改善できるようにします。Wiki がない場合は、プロジェクトの事実を捏造せずに進め、ユーザーがプロジェクトの状態を永続化したい場合は $setup-project を推奨します。

ユーザーの現在のブランチにとどまり、ブランチの作成、切り替え、マージ、削除は決して行いません。

事前確認で独立した事実調査の懸念事項が2つ以上明らかになった場合は、リポジトリの証拠、プロジェクトの記録、外部の証拠を対象に、読み取り専用の調査を並列実行するため $parallel-execution を呼び出します。統合、用語の管理とADRの追跡、すべての質問、およびユーザーまたはオーナー代理のすべての決定は、このコンテキスト内で行います。

ユーザーが呼び出した場合のみ使用します。ただし、すべての質問にオーナー代理として自律実行の契約に従って回答する $to-product から呼び出された場合を除きます。その実行時に限り、各番号付き質問の直後に、その逐語的な回答を続けて、ディスカッションを1つの一括ブロックとして出力します。通常は1ターンに1つの質問をします。

共有理解に至るまで、あらゆる側面についてユーザーに徹底的に質問し、意思決定ツリーの各分岐をたどり、決定間の依存関係を1つずつ解決します。各質問には推奨回答を示します。

一度に質問するのは1つだけとし、回答を待ちます。すべての質問は、次の形式に正確に従います。

Question X / ~Y:
Question

X は1から始めて増やします。Y は現在の質問を含む推定総数で、ディスカッションの進行に応じて修正します。これ以外の数の形式は使用しません。

利用可能な場合は、複数選択式の回答を提示できる ask_user_question ツールを使用します。ただし、自律実行時は決して使用しません。利用可能な場合は、質問する前にウェブ検索を使って、対象となるツールやフレームワーク、およびそのベストプラクティスを調査します。

環境（ファイルシステム、ツール）から判明する事実は、質問せずに調べます。決定はユーザーに委ねます。各決定についてユーザーに提示して回答を待ちます（自律実行時は、オーナー代理がどの質問にも一括ブロックで回答します）。

プロジェクトの docs/wiki/maintenance.md にあるADR重要性判定基準に従って、アーキテクチャ上重要な決定を追跡します（Wiki がない場合は、構造の変更、横断的な品質、採用または廃止する技術、または取り消しにコストがかかり、かつ実際に却下した代替案がある場合が該当します）。該当する決定に至るたびに、決定、その却下した代替案と理由、および受け入れる影響を確認する番号付きの質問を提示し、ルーティング先のコマンドで記録できるようにします。事前確認では docs/wiki/architecture/decisions/index.md のADRインデックスを読み、トピックに関係するADRのみを開きます。結論が既存のものに取って代わる場合は、どのADRに取って代わるかを伝えます。

用語を追跡します。ユーザーがユビキタス言語にないドメイン用語、異なる意味を持つ既存用語、または同じ概念に対する複数の言葉を使った場合は、意味の確認、定義の提案、およびユビキタス言語に追加または修正するかどうかを尋ねる番号付きの質問を提示します。確認済みの用語を引き継ぎ用に集めます。Wiki がない場合は、$setup-project 向けに記録します。

Discuss は完全に助言のみを行います。読み取りと質問だけを行い、変更を伴うスキルを呼び出したり、プロジェクトの記録を編集したりすることはありません。ユーザーが共有理解を確認した後、各結論を分類し、ユーザーが呼び出す承認済みの標準コマンドとして該当するものを推奨します：

• Epicを構成すべき、調整された成果（1つの目標に貢献する、相互に一貫性があり、それぞれ独立した価値を持つ複数の作業項目）は、エンドツーエンドで計画する $to-epic に振り分けます。これには、Epicの受付、調査を行うかどうかの判断、子項目の受付、完了状態までの精緻化が含まれ、途中で追加承認を求めることはありません。
• それ以外の未実装の望ましい状態（新機能、動作変更、修正、移行）は $to-backlog に振り分けます。確認済みの単独項目を受け付け、それぞれを完了状態まで精緻化します。事前確認で見つかった既存の proposed レコードがある場合は、重複して提案するのではなく、それを精緻化します。対象仕様をWikiに公開するよう勧めてはいけません。
• すでに受け入れ済みの現在のプライマリブランチの状態を記述している訂正、明確化、または長期的に有効な結論は $to-wiki に振り分けます。提案の仕様が十分に明確である、または望ましいものとして合意されているという理由だけで振り分けてはいけません。
• 確認済みの新しい用語や訂正された用語も、未実装の提案から生じた場合を含め、$to-wiki に振り分けます。提案が採用されるかどうかにかかわらず、その意味はプロジェクトで長期的に使われる用語だからです。
• オーナーが採用を確認した技術や標準に関するルールは $to-guidance に振り分けます。調査のうえ、正式なガイダンスページとして公開します。
• すでに有効になっている、アーキテクチャ上重要な決定は $to-wiki に振り分け、ADRとして公開します。提案中の作業が実施された時点で初めて有効になる決定は、まだ受け入れ済みの状態ではありません。その作業とともに $to-epic または $to-backlog に振り分け、受け入れ時に公開できるようレコード上で草案を作成します。プロジェクトがまだ採用していない決定の公開を勧めてはいけません。
• 1つの会話に複数の内容が含まれる場合があります。望ましい変更は $to-epic または $to-backlog に振り分け、独立して現在も有効な長期的事実だけを $to-wiki に振り分けます。提案を重複させてはいけません。
• 未解決の決定は会話内または提案中のバックログレコードに残します。受け入れ済みのWiki知識や、すぐに着手できる作業として提示してはいけません。

最後に、同じ番号付き形式で引き継ぎに関する質問を1つします。その後、受け入れられた各コマンドを、処理対象の確認済みの結論に続けて、コピーしてそのまま使える完全なプロンプトとして記載してターンを終了します。コマンドはターンの最終行に記載し、それ以降には何も書きません。複数ある場合は、実行順に番号付きリストにします。コマンドを実行したり、自分で $backlog または $wiki を実行したりしてはいけません。このスキルは推奨のみを行います。自律実行時には、議論ブロックの後に $to-product が推奨されたコマンドを実行します。最終行に関するルールは、このスキル自身の出力にのみ適用されます。