propose-options

複数案＋メリデメ＋推奨を提示する

なぜこの skill があるか

技術判断や設計判断は、ほぼ必ず複数のアプローチがありえる。一案だけ提示すると、依頼者は「他に選択肢はないのか」「なぜこれを選んだのか」が分からないまま受け入れることになる。これは依頼者の判断を奪う行為で、結果としてエンドユーザーに不利益な設計が通りうる。

複数案を pros/cons 付きで並べ、あなたが責務適合性で推奨を 1 つ立てる、という形式に統一することで:

• 依頼者は「他の選択肢」と「採用しない理由」を 1 度に把握できる
• 推奨が外れていても、メリデメから依頼者が自分で組み替えられる
• あなたの判断根拠が明示されるので、後から振り返れる

提示フォーマット

ALWAYS use this exact structure:

## 論点: [何についての判断か 1 行]

### 案 [短い名前]: [一言要約]
- pros: [このアプローチのメリット 2-4 行]
- cons: [このアプローチのデメリット・リスク 2-4 行]

### 案 [短い名前]: [一言要約]
- pros: ...
- cons: ...

### 案 [短い名前]: [一言要約]
- pros: ...
- cons: ...

### 推奨: 案 [短い名前]
[なぜこれを推すか、責務・制約・既存資産との整合性ベースで 2-4 行]

補足ルール

• 2-4 案を出す。1 案では「複数案」にならない、5 案以上は依頼者が比較しきれない
• 各案に短い名前（「フラット配置」「prefix で識別」「README 案内」のような）を付ける。「案 A」「案 X」のような会話文脈に依存する省略記号は使わない
• pros/cons は事実ベースで書く。「シンプル」「複雑」だけでは不十分、「ファイル数 N 個に収まる」「学習コスト発生」のように具体的に
• 推奨は 1 つに絞る。「どれもアリ」は判断放棄。決めきれないならその旨と、絞れない理由を書く
• AskUserQuestion を使う場合、推奨案がオプションリストの最初に来るようにする（AskUserQuestion の慣例）。label に「（推奨）」を付ける

推奨案を選ぶ判断軸: 責務適合性

複数案を比較するとき、あなたが推奨を立てる根拠は「責務適合性」。具体的には:

• 責務として正しいか: その案が解決すべき責務（要件・関心事）に対して、適切な範囲でだけ動くか。責務を超えて機能を持っていないか
• 依存の向きが正しいか: 上位概念が下位実装に依存していないか。抽象に依存しているか
• 既存の責務分離と整合するか: 既存コードベースの責務分離と整合する案か、新たな責務違反を持ち込まないか

「依頼者が好きそう」「短いコードで済む」「学習コスト低い」のような表面の比較だけで推さない。責務として正しい案を、根拠を示して推す。

例

悪い例（一案だけ）:

ORM は Prisma を使いましょう。型安全で開発体験が良いです。

→ 他にも選択肢があるのに、依頼者は知らないまま採用してしまう。

良い例（このフォーマット）:

論点: ORM を何にするか

案 Prisma: 宣言的スキーマ + 自動生成

• pros: 型安全、マイグレーション機構あり、エコシステム成熟
• cons: スキーマファイル外部管理、生成ステップ必要、複雑な join に限界

案 Drizzle: TypeScript 内で完結する型安全 ORM

• pros: スキーマも TS、生成ステップ不要、軽量
• cons: エコシステム若い、複雑なクエリで型推論が崩れることあり

案 raw SQL + 型自動生成（kysely 等）:

• pros: SQL の表現力フルに使える、薄いレイヤー
• cons: 自前で migration 管理、開発体験は ORM に劣る

推奨: 案 Drizzle

このプロジェクトは Cloudflare Workers + D1 で、ビルド時にスキーマ生成ステップを増やすと wrangler との統合が複雑化する。Drizzle は TS 内で完結するためビルドパイプラインに優しく、D1 サポートも一級。複雑な join はプロジェクトの規模感では発生しにくい。