ユーザーストーリーのリファイン
Socrates式問答法を用いてユーザーストーリーをリファインします。決定フロンティアが空になるまで構造化ラウンドでPOにインタビューし、その後統合します。効果的なセッションは、40分のリファインメント議論を10分の確認に変えます。なぜなら、チームは決定事項が記録され、ギャップが明示的に特定された状態でプランニングに臨むからです。
ストーリーはPOのものです。あなたは監査、提案、質問を行います。すべての編集は元のビジネス目標を保持し、スコープの決定が必要な書き換えは一方的な選択ではなく質問になります。ここでの発明リスクは深刻です。既存のUSはしばしば「ほぼ準備完了」に見え、それを黙って完成させたくなる誘惑があります。ギャップが可視化されたUSは、POが決して書かなかったルールで「完成した」ストーリーよりもはるかに価値があります。
US: $ARGUMENTS
開始前
ワークスペースのdocs/agents/refinement.mdを読んでください。そこには動作モード（コードあり/なし）、言語 (en-US または pt-BR、デフォルト en-US)、スラッグ、公開パスが定義されています。ファイルがない場合は、ユーザーに /configure-refinement を実行するよう依頼し、停止してください。すべての質問対話、質問、および統合成果物は、設定されたワークスペース言語に従います。
ステップ
-
読み込み. US（ファイルパス、トラッカーID、または貼り付けられたテキスト）、
CONTEXT.md、ドメインADRを読み込み、requirements-rigor用のスキルツールを呼び出します。このUSに対して.scratch/<slug>/が既に存在する場合は、その内容を調べてください。以前のセッションで解決された質問があれば、それを繰り返してはいけません。スラッグはdocs/agents/refinement.mdの規則に従います。docs/adr/または.scratch/がない場合は、警告なしで進めてください。 完了条件: USを1行で分類できること: ANALYZABLE（ナラティブといくつかの基準があり、たとえ不完全でも）、SKELETON（タイトルのみ、または基準のないナラティブ）、またはNOT A US（偽装されたエピック、技術タスク、スタンドアロンの非機能要件）。 -
トリアージ. NOT A USの場合: それが実際にどのような種類の成果物かを述べ、2～3行の根拠を示し、適切な処理方法を推奨します。偽装エピックなら
/requirements-discoveryで分解、技術タスクならタスクとして再分類、スタンドアロンの非機能要件なら非機能要件リストに移動。アイテムがワークスペース内にある場合は、タイトルの下にStatus: not a US（またはStatus: não é US）と根拠を追加して証跡を残します。ここで停止します。SKELETONの場合: 進めて、最初の質問ラウンドでは、シナリオを発明する代わりに不足しているシナリオを尋ねます。 完了条件: 分類が1行で述べられ、NOT A USの場合は根拠と処理方法も提供されていること。 -
サイレント監査.
requirements-rigorのルールをナラティブと基準に適用します: INVEST、Gherkin、アンチパターン（ANTI-PATTERNS.mdを別途参照）、常に質問を引き起こす用語。各発見は、候補となる質問、または記述された正確な動作を保持する修正（散文をGherkinに変換、DoDを基準から移動、実装タスクをノートに移動）になります。 完了条件: すべての基準に宛先（保持、変換、移動、質問）があり、各曖昧な用語に候補質問があること。 -
質問する前に事実を検索. 事実はあなたの責任であり、POの責任ではありません。各候補質問について、ワークスペースのソース（用語集、
.scratch/内の過去のストーリー、POが添付したドキュメント）を検索します。コードモードでは、サブエージェントを派遣して、USが主張または想定している内容をコードベースで検索させます。ルールは存在するか？制限は実装されているか？統合機能は動作するか？見つかった事実は、ソースを引用した推奨回答になります。コードなしモードでは、検索はサブエージェントなしでワークスペースファイルに制限されます。何も見つからない場合は、ラウンド1の先頭に1行でその旨を記載します。 完了条件: 各候補質問が、ソースによって回答済み（引用付き）またはPO用に未解決としてマークされていること。 -
問答.
socratic-examination用のスキルツールを呼び出し、その規律に従います: ラウンド、フロンティア、引用または「推奨なし」付きの推奨回答、あなたのものは事実でPOのものは決定、用語集は即時更新。ラウンド1は1行のトリアージで始まり、評決をブロックする質問をマークし、質問なしで移動された基準とエンジニアリングチームにルーティングされた質問に関する注記で閉じます。アーキテクチャに関する質問はPOとのラウンドには入れず、エンジニアリングチームへの未解決質問に直接ルーティングします。POが回答できない質問には[TO CONFIRM: whom]（または[A CONFIRMAR: quem]）を付け、フロンティアから外します。 完了条件: フロンティアが空になるか、POが現在の情報で閉じることを要求した場合。 -
統合. TEMPLATE.md に従ってリファインされたUSを記述します。残ったギャップはマーカーとして可視化します。Gherkin自己監査を実行します。評決を提供します: READY、それをブロック解除する質問番号付きのREFINE、または根拠付きのBLOCKED。
[DECOMPOSE]が存在する場合は、分解提案を含めます: 各部分のナラティブと元の基準のマッピング。 完了条件:docs/agents/refinement.mdで定義されたパスにファイルが存在し、Status:が評決と一致し、最終的な免責事項が存在すること。 -
未解決項目のルーティング. セッション外の各受信者について、
[TO CONFIRM]を伴うものには、requirements-rigorのQUESTIONNAIRE.mdに従って質問票を作成し、リファインされたUSとともに配置し、未解決質問セクションからファイルをリンクします。 完了条件: 受信者または質問票なしの[TO CONFIRM]が残っていないこと。 -
報告. ユーザーに簡潔に報告します: 評決、USが公開された場所、どの質問がブロック解除するか、生成された質問票。
ラウンド例
「ユーザーとして、レポートをPDFにエクスポートして共有を容易にしたい。AC1: エクスポートボタンが正しく動作する必要がある。AC2: バックエンドにPDF生成サービスを作成する。AC3: PDFが速く開く必要がある。AC4: コードレビューとテストが合格する。」というUSについて、用語集に運用アナリストとアカウントマネージャーがレポート消費者としてリストされているコードなしワークスペースの場合、最初のラウンドは次のようになります:
❓ Q1. 誰がエクスポートするのか？ (ブロッキング) ナラティブは「ユーザー」と述べています。用語集には、レポートを消費するロールとして運用アナリストとアカウントマネージャーがリストされています。どのロールがエクスポートしますか、または両方ですか？ 推奨: 運用アナリスト [推論: ロールが用語集の「運用レポート」に関連付けられている]。これがないと、権限が未定義のままであり、ナラティブはINVESTを満たしません。
❓ Q2. 「速く開く」とはどういう意味か？ (ブロッキング)
AC3はテスト不可能であり、2つの読み方が可能です: エクスポートのトリガーからダウンロード開始までの時間、またはファイルがリーダーで開くまでの時間。どちらが意図されていますか？最大時間は何秒ですか？
推奨: 推奨なし: ソーステキストは解釈やSLA数値のベースラインを提供していません。期待値がない場合は、[TO CONFIRM: PO] を記録して進めてください。
❓ Q3. エッジケース ソースは空のレポートと大量レポートを示唆しています [推論: レポートはボリュームが異なる]。このデリバリーではどれが重要ですか？ 推奨: 両方をシナリオとして含める [推論: ソーステキストに従う]。それぞれの具体的な動作はあなたの決定です: 推奨なし。最大ボリュームはQ2に依存します。
AC2とAC4は質問を引き起こしません: AC2は実装タスクであり、その有効化された動作はAC1でカバーされているためノートに移動します。AC4はチームのDefinition of Doneであり、基準から削除されます。両方とも最終成果物の監査セクションに、削除ではなく移動として表示されます。
最終通知
公開されるすべての成果物は次の文言で締めくくられます:
⚠️ この出力はリファインメントの準備であり、代替ではありません。スコープ、価値、優先順位に関する決定は厳密にPOとチームに属します。