ns-sdd-clarify-requirements

要件の明確化

事前計画ワークフロー：ns-sdd-requirements-generator を呼び出す前に、曖昧さを特定して解消します。

ハーネスの確認

../ns-harness/references/harness-discovery.md と ../ns-harness/references/artifact-layout.md を参照してください。

{product_root} を解決します： リポジトリのエントリにある AGENTS.md を読みます。文書化されたアンカーを優先してください。パスが存在しない場合、オープンワークスペースの外にある場合、または別のクローンを指している場合は、AGENTS.md を含むディレクトリを使用してください。

スタックとアーキテクチャに関する質問は、スタック検出の対象であり、このスキルの対象ではありません。

使用するタイミング

• ユーザーのスコープが曖昧または不完全な場合
• 用語が曖昧な場合（ダッシュボード、インテグレーション、通知システムなど）
• 既存のドキュメントがない新しいシステムの初回バージョンの場合
• オーケストレーターがスコープが薄すぎる（段落が 3 つ未満、または曖昧な用語がある）と判断した場合

ワークフロー

ステップ 0 — ブラウンフィールドゲート（分析前）

このステップが完了するまで、アプリケーションのソースコードを検索したり調べたりしないでください。

1. {product_root}/docs/context/brownfield-map.md を確認します。
2. {product_root} の下にあるブラウンフィールドの兆候を検出します：backend/、frontend/、src/、app/、または同等のアプリケーションコード（ドキュメントのみのリポジトリは除く）。
3. ブラウンフィールドの兆候があり、brownfield-map.md がない場合：
   • 停止します。まだ確認の質問をしてはいけません。
   • ns-harness-bootstrap-brownfield を呼び出し、{product_root}/docs/context/brownfield-map.md を作成します。
   • スコープを調整する前にブラウンフィールドのコンテキストが必要だったことを、ユーザーに簡潔に伝えます。
   • マップファイルが存在したら、このスキルのステップ 0.4（更新ゲート）から再開します。
4. グリーンフィールドの場合（アプリケーションコードがない場合）— ブートストラップを省略し、ステップ 1 に進みます。
5. brownfield-map.md がすでに存在する場合 — スコープを分析する前にステップ 0.4を実行します。

ステップ 0.4 — ブラウンフィールド更新ゲート（人間による確認が必須）

停止します。人間から返信があるまでステップ 1 に進まないでください。

1. {product_root}/docs/context/brownfield-map.md を読みます。
2. ファイルヘッダーの **Date:** 行からマップの日付を抽出します。行がない場合は date unknown と記載します。
3. 人間に対して、自然なチャット形式（会話の言語に合わせます。英語のテンプレートは以下を参照）でゲートを提示します。フェーズに関する専門用語、Reply:、または電文のような状況報告は使用しないでください。../ns-spec-driven/references/human-communication.md を参照してください。

There's already a codebase map at docs/context/brownfield-map.md
(last updated {date from file, or "date unknown"}).

Want me to re-scan the repo and update it, or keep this one and move on to scope questions?

- refresh — re-scan and update the map
- keep — use the map as-is

4. 明確な返信を待ちます。 有効な回答：refresh / keep（または自然な言葉での明確な同等表現）。
5. マップが新しそうだから、計画を急いでいるから、またはユーザーがすでに記述を貼り付けているからという理由で、keep と決めつけてはいけません。
6. refresh の場合： ns-harness-bootstrap-brownfield を呼び出して（既存ファイルを更新）、新しいマップを使用してステップ 1 に進みます。
7. keep の場合： 人間がマップの日付 {date} を承認したことをセッションコンテキストに記録し、既存のファイルを使用してステップ 1 に進みます。
8. 返信が曖昧な場合：もう一度だけ確認します。refresh または keep が明確になるまでステップ 1 を開始しないでください。

{product_root}/docs/context/system-reverse-spec.agent.md がある場合はそれも読みます（本文の説明より優先します）。ない場合は、ゲートの解決後に system-reverse-spec.md を読みます。

ステップ 1 より前に読み取りが許可されるもの（ブラウンフィールド）：ユーザーのスコープファイル、brownfield-map.md、system-reverse-spec.agent.md / system-reverse-spec.md、{harness_root}/rules/architecture-rules.md、アクティブバージョンの {product_root}/docs/versions/{version_san}/ 内のファイル。

ステップ 1 より前は禁止： 「曖昧さを減らす」ために backend/、frontend/、または src/ でアドホックな grep やコード検索を行うこと、マップがあるのにステップ 0.4 を省略すること。

Step 1 — 未整理のスコープを分析する

ユーザーの説明（および Step 0 が適用された場合は既存システムのコンテキスト）を読みます。曖昧な点に印を付けます。

カテゴリ	例
アクター	「ユーザーが X を行う」—どの役割ですか？
データの範囲	フィールド、ページネーション、フィルターの一覧は？
インテグレーション	REST、Webhook、認証方式は？
マルチテナント	会社間の分離は必要ですか？
ビジネスルール	具体的にどの検証が必要ですか？
状態のライフサイクル	許可される遷移は？
スコープの制限	このバージョンに含まれるもの／含まれないものは？
パフォーマンス	ボリューム、同時実行数、SLA は？
セキュリティ	認証は必要ですか？ロールの権限は？

既存システムのマップは現状の把握に使い、ユーザーにはこのバージョンで変更または追加する内容だけを尋ねます。

Step 2 — 質問する

• 1 回につき最大 5 問
• 正確な機能生成の妨げになる問題を優先する
• 可能であれば関連する質問をまとめる
• 平易な言葉で、番号を付け、各質問だけで意味が分かるようにする — Reply:、Premise:、スキル名などを使ったフォーム形式ではなく、会話形式にする
• 「Clarify/Specify の前に」とは決して言わず、次に作成する成果物を平易な言葉で示す

会話に合わせて調整して提示します。

A few open points before I draft the requirements document:

1. [actor question]
2. [data scope]
...

Answer in your own words — no special format needed.

Step 3 — 回答をまとめる

回答を受け取ったら：

1. 短い要約（箇条書き 3～5 項目）で理解した内容を確認する
2. 平易な言葉で「次に要件ドキュメントを作成しましょうか？」と尋ねる
   — 禁止: 「Specify に進む」「Specify を続ける」など、フェーズ名を使った指示
3. はい、または修正の回答を待つ
4. 確認のやり取りは最大 1 回 — それでも不明な場合は、妥当な前提を「前提事項」として記録する

Step 4 — ns-sdd-requirements-generator に引き継ぐ

拡充したコンテキストをまとめます。

## Original scope (user-provided):

[original text]

## Brownfield context (if applicable):

[Summary from brownfield-map.md — modules and constraints relevant to this version]
[Brownfield gate: human chose refresh | keep on {date shown in gate}]

## Clarifications obtained:

1. Question: [...]
   Answer: [...]

## Confirmed premises:

- [Premise 1]
- [Premise 2]

このドキュメントを入力として ns-sdd-requirements-generator に渡します。ここでは requirements.md を作成しないでください。

重要なルール

• 既存システムにマップがない場合: まず ns-harness-bootstrap-brownfield を実行します — 代わりにコードベースを grep して済ませることは決してしないでください
• 既存システムにマップがある場合: Step 0.4 の確認は必須です — マップの最終更新日を示し、明示的な refresh または keep の指示を待ちます。推測で決めてはいけません
• 人とのチャット: 自然な言葉を使い、フェーズ（「Specify」）ではなく成果物（「要件ドキュメント」）を示します。チャットの内容を不自然に切り詰めてはいけません
• 質問は 1 回のみ — その後は慎重に前提を置き、記録します
• このワークフローでは要件ドキュメントを作成しません
• 技術スタックやアーキテクチャに関する質問はしません — 技術スタックのプロファイル／プロジェクトルールと既存システムのマップに委ねます
• 重要な点についてユーザーが「分からない」と答えた場合：最小限かつ最も安全なスコープを前提とし、その旨を記録します

インテグレーション

planning start → [brownfield + no map?] → ns-harness-bootstrap-brownfield → [brownfield refresh gate] → ns-sdd-clarify-requirements → ns-sdd-requirements-generator → Gate 1

既存システムの更新確認：brownfield-map.md の日付を見せたうえで、人が refresh または keep を確認します。

関連スキル

• ns-harness-bootstrap-brownfield — コードが存在し、brownfield-map.md がない場合の必須の前提手順
• ns-sdd-requirements-generator — 確認後の次のステップ
• ns-harness-architecture-rules — architecture-rules.md がまだひな形の場合の設計原則（このスキルとは別）