issue-to-requirement

Issue To Requirement

目的

• Issue の自然言語要求を、実装可能な要件に落とし込む。
• 異なる種類の Issue でも共通フォーマットで整理する。
• 後続の issue-to-plan が判断チェックリストを作れる入力を作る。

この skill を使う条件

• GitHub Issue URL または Issue 本文を渡されたとき。
• 要求が抽象的で、実装範囲が不明確なとき。

出力フォーマット

以下の見出しを必ず出力する。

1. Issue の要約
2. Issue 分類
3. 層別要件
4. 実装スコープ概要
5. 非ゴール
6. 判定待ち項目
7. 次アクション

追質問ルール（必須）

• 追質問は最大 4 項目までに制限する。
• 1 項目につき 1 決定のみを問う（複数決定を 1 問に混ぜない）。
• 判定待ち項目 は次の形式で出力する。
  • ID: 例 Q-1
  • 質問: 1 文
  • 選択肢: 2-4 個
  • 未回答時の仮置き案: 1 つ

Issue 分類ルール

Issue は次のいずれかに分類する。

• 新規検索条件追加型
• UI/UX 改善型
• API 仕様リファクタリング型
• 非機能改善型

分類が曖昧な場合は第1候補と第2候補を提示する。

層別要件の抽出ルール

次の層ごとに「追加 / 変更 / 新規」の観点で要件を整理する。

• フロント層: src/app/_components, src/app/page.tsx
• API 層: src/app/api/**/route.ts
• Service 層: src/lib/server/*_service.ts
• Client 層: src/lib/server/*_api_client.ts
• テスト層: src/lib/server/__tests__, src/app/api/**/__tests__

要件が存在しない層は「変更なし」と明記する。

実装スコープ概要の作り方

実装候補を以下の粒度でまとめる。

• 追加するファイル
• 変更するファイル
• 既存拡張で済むか、新規モジュールが必要か
• 影響する API contract

非ゴールの作り方

Issue 本文に含まれていない大型テーマを除外対象として明記する。

例:

• 地図 UI の全面リデザイン
• 本格キャッシュ戦略の導入
• 別画面の UX 改善

判定待ち項目の作り方

issue-to-plan で意思決定が必要になる項目を抽出する。

例:

• データソースは新規 API か既存 API 拡張か
• endpoint は既存拡張か新規追加か
• 並び順は距離/価格/結合スコアのどれか

Issue 追記用フォーマット（推奨）

別セッションで継続しやすくするため、以下の 5 見出しで出力する。

1. 要件正規化結果
2. 設計判断チェックリスト
3. 現時点の回答
4. 追加で確定が必要な項目
5. 次セッション開始プロンプト

外部参照ルール

• 外部記事や他実装は「参考」として扱い、実装コードと説明文は独自に作成する。
• データソースを採用する場合は、利用条件とライセンス確認項目を 判定待ち項目 に含める。
• 他者コードの複製を前提とする指示は作らない。

品質基準

• 要件が層別に整理されている。
• 判定待ち項目が次のチェックリスト作成に十分な粒度である。
• 既存アーキテクチャ境界（route 薄く、service 委譲）と矛盾しない。

参照

• designdoc.md
• src/app/api/search/route.ts
• src/lib/server/accommodation_search_service.ts

接続

この skill の出力をそのまま issue-to-plan の入力として渡す。 最終的な実装計画は task-orchestration へ委譲する。