sdd-clarify

SDD Clarify — うまく質問して、一度で作る

最も安価なトークンは、作業のやり直しに使わずに済んだトークンです。曖昧な依頼を考えなしに実装すると、反復作業が無駄に発生します（実装 → 間違い → 再実装 → 再レビュー）。このスキルでは、あらかじめ曖昧さを解消します。短く的を絞った確認を行い、漠然とした依頼を範囲が明確な SDD の変更に落とし込むことで、実装とレビューのループを一度で済ませます。GitHub Spec-Kit の /speckit.clarify と Matt Pocock の grill-me スキル（共通認識が得られるまで聞き取り、推奨回答を各質問に添えて、判断ツリーの分岐を一つずつ解決する）を参考に、トークン消費を抑えるよう調整しています。

使用するタイミング

機能やバグの依頼を受けたら、仕様を提案したりコードに触れたりする前に必ず使います。これは、実際に要件が固まった目標を /opsx:propose（またはワークフローの仕様フェーズ）に渡すためのステップです。

確認の進め方

1. まず、手軽にコンテキストを集めます。 コードや仕様ですでに決まっていることを把握するのに必要な範囲だけ読みます。既存のモジュール、関連する仕様、規約を確認します。リポジトリを見ればわかることをユーザーに尋ねてはいけません。（深く掘り下げず、簡単に読み取る・場所を特定する程度にします。）
2. 次の観点で曖昧さを確認します（Spec-Kit の観点）。本当に未解決で、かつ実装内容が変わるものだけを残します。
   • 機能の範囲と境界（含めるもの／明示的に除外するもの）
   • データモデル／エンティティ／永続化
   • 統合と依存関係（連携するサービス／イベント／契約）
   • エッジケースと障害時の動作（フェイルオープンか、エラー、空の場合／上限など）
   • 非機能要件（レイテンシの予算、セキュリティ／認可、冪等性）
   • 用語／ドメイン（意味が複数ある用語を明確にする。例：bill と invoice）
3. 判断ツリーを意識しつつ、トークンを節約して質問します（grill-me）。判断ツリーの順に並べ、後続の判断を左右する範囲の決定を先に行います。互いに独立した質問は、1 回の AskUserQuestion 呼び出しにまとめます（選択肢は各 2～4 個とし、推奨する選択肢を先頭に置いて明示することで、文章を書かずにクリックで回答できるようにします）。これにより、やり取りの回数を減らせます。回答によって初めて生じる、真に新しい従属分岐（その回答があって初めて意味をなす追加質問）がある場合は、それについてもう 1 回だけ簡潔に確認します。各分岐を推測で済ませず、解決してください。互いに依存する質問をまとめてはいけません。コードですでに決まっていることや、明らかなデフォルトがあることは尋ねてはいけません（デフォルトを明示して先に進みます）。依頼が明確なら、何も尋ねずステップ 5 に進みます。確認全体は約 2 ラウンドまでにします。延々と質問を続けること自体が無駄です。
4. 回答を提案に反映します。 すべての回答を OpenSpec の提案／仕様に明記します（範囲、判断、エッジケース）。記録するのはチャットではなく仕様です。
5. SDD に引き継ぎます。
   • 小規模／単一ファイル／バグ修正 → /opsx:propose の後に /opsx:apply。
   • 大規模／複数領域にまたがる変更／チャットサーフェス → 明確化した目標を指定して sdd-feature-flow ワークフローを起動します（実行中にユーザーへ質問できないため、ここで明確にしておく必要があります）。
6. PR 時のレビューはこのスキルの役割ではありません。 それは pre-pr-greptile スキルの役割です。変更の実装後、PR を作成するときに greptile review を実行し、差分との一致を確認し、トリアージを行い、PR をゲートします。Clarify → spec → 実装 → greptile review → PR。

ガードレール

• 質問しすぎないでください。 質問過多も無駄です（ユーザーの時間とトークンの両方を浪費します）。鋭い質問は最大 3～4 個まで。依頼が明確なら質問はゼロです。推奨する選択肢を先頭に置き、ユーザーがワンクリックでデフォルトを選べるようにします。
• 不足を補うために事実を作り上げてはいけません。 不明で重要なことは質問します。不明でも些細なことなら、妥当なデフォルトを選び、仕様に明記します。
• ここで解決した曖昧さは、チャットに残したままにせず、必ず OpenSpec の成果物に書き込みます。
• SDD のゲートを守ってください。このプロセスで作成される有効な変更がなければ、本番ソースを編集してはいけません。