メニュー
設計判断・ライブラリ選定・アーキ判断・実装アプローチが 2 つ以上ありえる場面で必ず発火させる、「複数案＋メリデメ＋推奨」を提示する横断スキル。「どっちがいい？」「これでいい？」「方針を相談したい」と聞かれたとき、ライブラリ選定・ディレクトリ構成・API 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| 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（テスト先書き → 最小実装 → リファクタ → コミット）で進め、要件が大きければ適切な小ささに分割しつつサイクルを回す。発火しないのは要件定義 / 基本設計の対話中（まだ手を動かしていない時）だけ。