tracer-to-spec

このスキルは、次のいずれかの確定済み入力から仕様書（PRD と呼ばれることもあります）を作成します。

• /tracer-interview-me の後の現在の会話。通常は同じコンテキストウィンドウ内にあります。または
• URL、課題番号、ローカルパスで渡された、クリア済みの /tracer-wayfinder マップ。

インタビューを再開しないでください。 決定はすでになされています。新しい決定をひそかに追加せず、内容をまとめてください。

公開先： docs/agents/issue-tracker.md でトラッカーが設定されている場合（/tracer-setup で設定）、ready-for-agent を付けずにそこへ公開してください。このラベルは、/tracer-to-tickets で作成される実行可能なチケット用です。そうでない場合は、仕様書を .tracer/<feature-slug>/spec.md に書き込みます。

プロセス

1. 確定済みの入力を集める

通常のインタビューの場合は、現在の会話をもとに作業します。

Wayfinder マップの場合は、作成前に分散した詳細情報を集めます。

1. マップの Destination、Notes、Decisions so far、Not yet specified、Out of scope を読みます。
2. 設定済みトラッカーの Wayfinding 操作を使って、すべての子チケットを確認します。子チケットが未解決、担当者割り当て済み、または進行中の場合、Not yet specified が空でない場合、あるいは解決済みの子チケットが Decisions so far と Out of scope のどちらにも記載されていない場合は、そこで中断して /tracer-wayfinder に戻ります。
3. Decisions so far に記載された、解決済みチケットすべてについて、本文全体と解決コメントまたは Answer セクションを取得します。必要に応じて、リンク先の調査メモ、プロトタイプの判定、ADR、その他の決定に関する資料を確認します。マップの一行要約は索引であり、信頼できる情報源ではありません。
4. マップで明示されたスコープ境界を維持します。範囲外チケットについて、一行の説明だけでは除外内容を正確に記述できない場合は、そのチケットを読みます。

2. テストの接点を調査して選ぶ

まだ確認していない場合は、リポジトリを調査してコードベースの現状を把握します。仕様書全体で、プロジェクトのドメイン用語集にある語彙を使い、変更対象領域の ADR に従ってください。

観測可能な受け入れ条件と重要な障害経路を確認するには、既存の高レベルなテストの接点と、対象を絞ったチェックを優先します。これまでの調査を再利用してください。テストの接点は、新たなフィクスチャーフレームワークの構築、あらゆる設定の列挙、またはすべてのプラットフォームでの全テスト実行を求めるものではありません。

予定する検証内容を簡潔に記載します。大がかりな仕組みを必要とする新たなテストの接点、高コストまたは外部依存の検証、あるいは未確定の受け入れ判断がある場合に限り、確認を求めてください。必須の証拠と任意の広範なチェックは分けて記載します。新たな製品上または安全上の決定が必要になった場合は、ここで独自に決めず、ユーザーまたは元の Wayfinder マップに判断を戻してください。

3. 作成して公開する

以下のテンプレートを使い、確定済みの動作と重要な制約を保ったうえで、最短の仕様書を作成し、公開します（上記を参照）。空の任意セクションは省略し、重複する基準はまとめます。入力が Wayfinder マップの場合は、トラッカー専用の管理情報を本文に転載せず、リンクされた決定事項を含めます。

その後、複数セッションで作業する場合は /tracer-to-tickets に進み、単一セッションで作業する場合は /tracer-implement に直接進みます。

問題の説明

ユーザーの視点から見た、ユーザーが直面している問題。

解決策

ユーザーの視点から見た、問題の解決策。

受け入れ条件

重要な障害時の動作とデータ／セキュリティ上の不変条件を含む、観測可能な結果を簡潔に番号付きで列挙します。各条件は、確定済みのユーザー要件に基づく必要があり、仮想的な利用者や計画者の好みに基づいてはなりません。関連するバリエーションはまとめます。条件の数を増やせば仕様書がよくなるとは限りません。

ユーザーの動機を明確にすることで、独立した要件が明らかになる場合に限り、ユーザーストーリーを使います。通常の実装手順を個別のストーリーにする必要はありません。

実装上の決定事項

ユーザーと明示的に合意したもの、またはリポジトリですでに必須となっている実装上の決定事項のみを記載します。これらの制約と任意の提案を区別してください。実装者は任意の提案を簡略化できます。明示的な決定がない限り、安全な再実行を並行実行やクラッシュリカバリーの保証に拡大したり、明確な権限エラーを独自の認可評価機能に置き換えたりしないでください。この任意のセクションには、次の内容を含められます。

• 作成または変更するモジュール
• 変更するモジュールのインターフェース
• 開発者による技術的な補足
• アーキテクチャ上の決定事項
• スキーマの変更
• API コントラクト
• 具体的な連携方法

長期的に保持する決定事項は、動作やインターフェースのレベルで記載してください。具体的な対象パスと検証コマンドは、/tracer-implement の短期的な計画に記載します。実装コードは実装に含めます。

例外：プロトタイプによって、文章よりも正確に決定事項を表すスニペット（ステートマシン、リデューサー、スキーマ、型の形状など）が作成された場合は、該当する決定事項にインラインで含め、プロトタイプ由来であることを簡潔に記してください。動作するデモ全体ではなく、決定事項を明確に表す部分に絞ってください。

テスト上の決定事項

受け入れ基準に対する、既存のテスト上の接点と焦点を絞った検証方法を記載します。考えられるすべてのパターンを要求することなく、重要な失敗ケースを網羅してください。実環境での確認は、合意済みの場合、またはリポジトリのポリシーで義務付けられている場合に限って必須とします。影響の大きさから必要でない限り、より広範なプラットフォームでの実行や全テストスイートの実行は任意であると明記してください。

新しいテストハーネスを指定したり、テストコードを重複させたりせず、参考になる既存のテストを挙げてください。

対象外

この変更を小規模に保つための対象外事項と制限を記載します。サポート対象の環境と、該当する並行実行やリカバリーの境界も含めてください。必須の安全対策は維持し、実際に安全性とのトレードオフがある場合は、暗黙に省略するのではなく明確にしてください。

補足

この機能に関するその他の補足事項を記載します。