Menu
設計判断・ライブラリ選定・アーキ判断・実装アプローチが 2 つ以上ありえる場面で必ず発火させる、「複数案＋メリデメ＋推奨」を提示する横断スキル。「どっちがいい？」「これでいい？」「方針を相談したい」と聞かれたとき、ライブラリ選定・ディレクトリ構成・API 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | propose-options |
| description | 設計判断・ライブラリ選定・アーキ判断・実装アプローチが 2 つ以上ありえる場面で必ず発火させる、「複数案＋メリデメ＋推奨」を提示する横断スキル。「どっちがいい？」「これでいい？」「方針を相談したい」と聞かれたとき、ライブラリ選定・ディレクトリ構成・API 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。 |
技術判断や設計判断は、ほぼ必ず複数のアプローチがありえる。一案だけ提示すると、依頼者は「他に選択肢はないのか」「なぜこれを選んだのか」が分からないまま受け入れることになる。これは依頼者の判断を奪う行為で、結果としてエンドユーザーに不利益な設計が通りうる。
複数案を pros/cons 付きで並べ、あなたが責務適合性で推奨を 1 つ立てる、という形式に統一することで:
ALWAYS use this exact structure:
## 論点: [何についての判断か 1 行]
### 案 [短い名前]: [一言要約]
- pros: [このアプローチのメリット 2-4 行]
- cons: [このアプローチのデメリット・リスク 2-4 行]
### 案 [短い名前]: [一言要約]
- pros: ...
- cons: ...
### 案 [短い名前]: [一言要約]
- pros: ...
- cons: ...
### 推奨: 案 [短い名前]
[なぜこれを推すか、責務・制約・既存資産との整合性ベースで 2-4 行]
複数案を比較するとき、あなたが推奨を立てる根拠は「責務適合性」。具体的には:
「依頼者が好きそう」「短いコードで済む」「学習コスト低い」のような表面の比較だけで推さない。責務として正しい案を、根拠を示して推す。
悪い例（一案だけ）:
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 はプロジェクトの規模感では発生しにくい。
xp-harness の skill / subagent が意図どおり振る舞えているか (発火するか・あるべき振る舞いができているか) を transcript で事実確認する手順。skill / subagent を改修した後に sandbox で動作検証したいとき、または本番の実運用セッションを「あるべき振る舞い」に照らして分析したいとき、「検証したい」「発火するか確かめたい」「このセッションを分析したい」と言われたときに発火させる。核は発火・振る舞いができたかの事実確認で、本番セッションでは自走の良し悪し (止まり方・判断の質など) も見る。
要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。
新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。
依頼者と議論・対話を進める場面で必ず発火させる skill。共創を目指して、認識を小さく揃えながら、同じ抽象度・レイヤーで話すための対話の進め方を扱う。要件・設計フェーズの対話、実装中の設計判断の議論、レビュー結果の共有、複数の論点・選択肢を依頼者に渡す場面、依頼者からの指摘・反論に応答する場面、「確認したい」「議論したい」「相談したい」と問いかけたいとき、いずれも発火対象。「会話」ではなく「対話」を成立させたい全場面で効く。
Git 運用の規律 (branch / worktree 運用、commit / push / pull / rebase / conflict 解決、remote 同期、完了時の統合) を一元的に担う skill。コード変更を伴う依頼・セッション開始・Git 操作の話題のいずれかに該当したら、他より先に必ず最初に使う。ファイルを 1 行でも書き換える依頼なら Git に無関係に見えても発火し、セッション開始・作業再開 (「前回の続き」「何から始めよう」等) でも必ず発火する。発火しないのはコードを読むだけの質問、Git の概念学習質問、doc のサマリ依頼。project 固有ルールでの部分上書きに対応する。
エンジニアとして手を動かす作業全般で必ず発火させる: コードを書く / テストを書く / リファクタ / バグ修正 / E2E spec 追加 / 既存仕様への小さな修正など、コードに触る作業すべて。「実装して」「テスト書いて」「リファクタして」「バグ直して」のような依頼を受けたとき、または基本設計が済んで実装フェーズに入るときに発火。基本作業は TDD（テスト先書き → 最小実装 → リファクタ → コミット）で進め、要件が大きければ適切な小ささに分割しつつサイクルを回す。発火しないのは要件定義 / 基本設計の対話中（まだ手を動かしていない時）だけ。