mutils-ideal-driven-design

name	mutils:ideal-driven-design
description	理想を絶対に忘れずに、手段にとらわれずに設計案が理想を満たしているかを徹底的に議論してから設計を確定するためのスキル。Use when the user says '理想から設計', '理想駆動', '理想を満たす設計', '手段にとらわれず設計', '本質から設計', 'ideal driven design', 'north star design', or wants to design something starting from the ideal state without being constrained by means.
allowed-tools	Read, Grep, Glob, AskUserQuestion, TodoRead, TodoWrite

Ideal-Driven Design: 理想から設計を導く

設計を始める前に「理想 (North Star)」を絶対に動かさないアンカーとして固定する。 そのうえで、生成した設計案が本当に理想を満たしているかを、手段・既存実装・実装難易度から完全に切り離した状態で議論する。

$ARGUMENTS

絶対原則

• MUST NOT: 設計都合で理想を書き換える（理想は議論の前提条件であり結果ではない。代わりに理想は据え置き、満たせない部分は未解決問題として記録する）
• IF: Phase 1〜3 にいる; THEN MUST NOT: 「実現可能性」「既存システム」「工数」を持ち込む（これらは Phase 4 以降でのみ扱う）
• IF: 「理想を満たしている」と主張する; THEN MUST: 成功判定基準ごとに根拠を提示する（設計案は理想に対する仮説にすぎない）
• IF: 理想を満たしていない部分がある; THEN MUST: 妥協ではなく未解決問題として記録する（「現実的にはここまで」で打ち切らない）
• IF: ユーザーが理想を曖昧にしたまま進めようとしている; THEN MUST: 作業を止めて理想を明確化する（曖昧な理想からは曖昧な設計しか生まれない）

禁則フレーズ

IF: Phase 1〜3 で下記フレーズが出現した; THEN MUST: 議論を巻き戻し、当該フレーズを取り除いた上で再開する

• 「現実的には」「実装難易度を考えると」「既存実装に合わせて」
• 「とりあえず」「一旦」「最低限」「MVP として」
• 「○○を使うので」「○○の制約上」「○○がサポートしていないので」
• 「後方互換性のため」「既存ユーザーのため」(ユーザー要件として明示されていない場合)

IF: Phase 4 (ギャップ分析) または Phase 5 (妥協の明示) にいる; THEN MAY: 上記フレーズを使用する

ワークフロー

Phase 1: 理想の明文化 (North Star Statement)

対象テーマについて、手段を一切含まない理想状態を明文化する。 ユーザー入力が抽象的な場合は AskUserQuestion で深掘りする。

書くべき項目:

• 解きたい本質的問題 — なぜこの設計が必要なのか。背景にある困りごと・痛み
• 理想の状態 — 制約を全て取り払った場合、利用者・システム・関係者から見えるべき姿
• 成功の判定基準 — 「理想が満たされた」と判定できる観測可能なシグナル (3〜5個)
• 理想の境界 — 理想に含まれないものを明示 (スコープ漏れ防止)
• 不変条件 (Invariants) — 設計がどう変わっても絶対に守られるべき性質

書き方のルール:

• MUST NOT: 手段に言及する（"○○を使って" "△△で実装して" は不可。代わりに達成される状態のみを書く）
• MUST: 計測可能に書く（"速い" ではなく "P95 で 100ms 未満" など）
• SHOULD: 理想の理想を書く（控えめにせず、現状達成不可能でもよい）
• MUST: ユーザー視点と内部品質視点の両方を含める

Phase 2: 手段汚染の検出 (Decontamination)

MUST: Phase 1 の文章を1行ずつスキャンし、手段に汚染された記述を炙り出す。汚染パターン:

• 既存の実装・ライブラリ・サービス名が含まれている

• 「〜のように」「〜と同じく」と既存事例に依存している

• 否定形 ("〜しない") で書かれている (理想は肯定形で書く)

• 量化されていない形容詞 ("良い" "速い" "使いやすい")

• 副作用や手段が紛れている ("ボタンを押すと" → 何が達成されるか)

• IF: 汚染が見つかった; THEN MUST: Phase 1 に戻って書き直す

• MUST NOT: 汚染を残したまま Phase 3 に進む（代わりに Phase 1 で汚染を除去してから進む）

Phase 3: 設計案の生成 (Hypotheses)

MUST: 理想を満たしうる設計案を最低 3 案生成する。各案について:

### 案 N: <短い名前>

- 概要: 1〜3行で構造を述べる
- 理想を満たす根拠: Phase 1 の各成功判定基準に対し、なぜ満たせるかを判定基準ごとに記述
- 不変条件への適合: 各 Invariant をどう保証するか
- 未解決な前提: この案が成立するために検証が必要な仮定

MUST NOT: 設計案を 1 案だけで終わらせる（比較がなければ「理想を満たす」議論ができない。代わりに最低 3 案を並べて比較する）

Phase 4: 徹底議論 (Adversarial Review)

MUST: 各案について以下を敵対的に検証する。IF: 1問でも No / 不明がある; THEN: その案は理想を満たしていないと判定する

• 充足性 — Phase 1 の成功判定基準を全て満たすか? 一部でも満たさない基準を列挙せよ
• 整合性 — 不変条件が破れる経路は存在しないか? 反例を 1 つ挙げよ
• 境界 — Phase 1 の「理想の境界」を侵していないか? 余計な責務を負っていないか
• 手段汚染 — 採択している手段は理想を満たすために最も適切か? それとも既知だから選ばれているだけか
• 代替不能性 — 同じ理想を満たすより素朴な案が存在しないか? 存在するならこの案を選ぶ理由は何か
• 崩壊点 — この案が「理想を満たさなくなる」具体的シナリオを 2 つ挙げよ

議論結果を以下にまとめる:

## ギャップ分析

- 案 — 充足する基準
  - 充足しない基準: 充足しない基準
  - 崩壊点: 崩壊点
  - 残課題: 残課題
- 案1 — 1, 3, 5
  - 充足しない基準: 2, 4
  - 崩壊点: 並行アクセス時に整合性損失
  - 残課題: 4 を満たす機構の追加

Phase 5: 妥協の明示 (Acknowledged Trade-offs)

MAY: ここで初めて「実装難易度」「既存制約」「工数」を持ち込む。 MUST NOT: 理想を書き換える（理想は据え置いたまま、案ごとに以下を記録する）:

## 妥協ログ

- 案 N で受け入れる妥協: <現実制約により今回満たせない理想の項目>
- 妥協の理由: <なぜ今回は許容するか>
- 妥協を解消する将来条件: <何が変われば理想に到達できるか>
- 再評価のトリガー: <いつ・何が起きたら再設計するか>

MUST NOT: 妥協を「やむを得ない」で済ませる（代わりに理想との差分・解消条件・再評価条件まで言語化する）。これにより設計が時間とともに理想に近づくレールが敷ける。

Phase 6: 採択と次のアクション

MUST: 最終案と理由を提示し、AskUserQuestion で確認を取る。出力フォーマット:

## 採択案

- 案 N: <名前>
- 理想充足率: M / Total 基準
- 未充足基準と理由: <Phase 5 の妥協ログから引用>
- 採択理由: なぜこの案を選ぶか (3〜5行)

## Next Actions

1. <未充足基準を埋めるための検証タスク>
2. <妥協の再評価トリガーを監視する仕組み>
3. <実装に進む前の確認事項>

アンチパターン

• 理想を 1 文で済ませて Phase 3 に飛ぶ — 議論の基準が無いので「徹底的に議論」が成立しない
• 設計案を 1 案だけ出す — 「他案より優れている根拠」を欠き、選択ではなく追認になる
• 「実現可能性」を Phase 1 で考慮する — 理想が現実に引きずられ、ゴールが沈下する
• 「現状はこうだから」を理想の根拠に使う — 既存実装の追認になり、理想駆動ではなく現状駆動になる
• 妥協を「仕方ない」と書く — 解消条件・再評価条件が不在なので恒久化する
• Phase 4 の崩壊点を「考えにくい」で済ませる — 反例を出すべきところで出さないのは敵対的レビューの放棄である
• 理想充足の根拠を「総合的に」で説明する — 判定基準ごとに対応付けないと議論が verifiable にならない

使い分け

• 概念や方向性が固まっていない: まず本スキルで理想を確定 → その後 mutils:multi-angle-perspectives で具体案を広げる
• 既に複数案がある: 本スキルの Phase 4〜5 のみ抜粋して、各案を理想に対し採点する
• 計画書が曖昧: mutils:dig で Q&A した上で本スキルに移行
• 過去の設計を振り返る: mutils:reflection の後、本スキルで「次回の理想」を再定義する

チェックリスト

IF: 完了したと判断する直前; THEN MUST: 以下を全て確認する:

• Phase 1 の理想に手段が紛れていない
• 成功判定基準が観測可能 (測れる) な形で書かれている
• 不変条件が明示されている
• 設計案を 3 案以上生成した
• 各案について Phase 4 の 6 観点を全て検証した
• 未充足基準が案ごとに列挙されている
• 妥協には解消条件と再評価トリガーが付いている
• 禁則フレーズが Phase 1〜3 のアウトプットに残っていない