| name | unconventional-simplification |
| description | 定石外発想で実装をシンプルにする。現状の発展型ではなく、実装の裏にある暗黙の前提条件を1つずつ外し、よりシンプルな別解がないか検討する。 ユーザーが「定石外発想で」「前提を疑って」「もっとシンプルにできないか」と言った時に使用する。 |
| argument-hint | [対象ファイル/モジュール — 省略可] |
定石外発想によるシンプル化手順書
このスキルは、採用済みの解をレビューしたり機能を足したりするものではない。解の裏にある暗黙の前提を列挙し、1つずつ外して、より少ない実装・説明で済む別解を探す。現状の発展型に流れず、要素の引き算で考える。
ゼロから案を作るのではなく、すでにある実装・方針・設計判断を再考対象にする。
手順1: 分析対象の特定
「いま再考すべき解（第一案）」を特定する。
- 引数がある場合: 指定されたファイル・モジュール・機能を対象とする
- 会話コンテキストがある場合: 直前に到達した方針・設計判断・実装アプローチを対象とする。これが主たる特定方法である
- コールドスタートの場合: 会話コンテキストが薄く引数も無いときは、直近の変更を自動検出して対象とし、何を対象と推定したかを一言で明示する
対象を特定したら、その解を実装しているコードを以下の順で確認する:
- 引数で対象ファイル・モジュールが指定されている場合は、まずそれを直接読む
- 未commitの変更を
git diff と git diff --staged で確認する
- 未commitの変更が無ければ、base branchとの差分や直近のcommitを確認する。base branchは
git symbolic-ref refs/remotes/origin/HEAD 等で判定し、例えば git diff origin/main...HEAD のように差分を取る。判定できなければ git log -p -3 を見る
手順2: 前提条件の列挙
採用された解が暗黙に置いている前提を、コードと会話コンテキストから列挙する。コードと会話コンテキストに根拠のある前提だけを扱い、空想上の要件は持ち込まない。
例:
- このAPI・データ構造・状態を維持する必要がある
- この処理をこのタイミング・UI・場所で提供する必要がある
- 問題はこの層で解く必要がある
実装そのものだけでなく、問題設定への前提も含める。「そもそもどういうユーザー・状況か」「もっと手前の段階で対処すべきではないか」まで戻る。これを外さないと、単なる実装差分のレビューに戻る。
手順3: 前提を1つずつ外して再考
列挙した前提を1つずつ取り上げ、「この前提が無ければどういう解になるか」を考える。一度に複数の前提を外さない。
- シンプルにならないものは、理由を軽く記録してスキップする
- シンプルになるものは、その別解を具体化する
手順4: コスト比較
シンプルになった別解を、第一案と次の5観点で比較する。
- 実装量: コードがどれだけ減るか
- 既存仕様との互換性: 既存の動作・APIとの互換が壊れないか
- 説明コスト: 概念や挙動の説明が難しくならないか
- 運用・移行コスト: 既存データや運用フローの移行が要るか
- 将来の保守性: 長期的に保守しやすくなるか
加えて、前提解除を成立させるために必要な別の仕組みを計上する。前提を外せた裏で追加実装・ドキュメント・教育などが要るなら、簡潔さの代わりにどこへコストが移ったかを正直に見積もる。
手順5: 分類
各別解を3つに分類する。
- 今すぐ検討すべき: シンプルさの利得が大きく、コストが見合う
- 将来の論点: いまは第一案で妥当だが、状況が変われば再考に値する
- 現状の採用案で妥当: 前提を外してもメリットが薄い、またはコストが上回る
手順6: 外部Agent相談（任意）
外部Agentへの相談は、ユーザーが明示的に求めた場合だけ行う。相談の進め方は codex-consultation / subagent-consultation の手順に任せ、このスキルは相談の中身だけを指定する。
外部Agentは放っておくと通常のレビューに流れるため、レビューではなく手順2〜5そのものを依頼すること。すなわち、外部Agent自身に根拠のある前提を列挙させ、各前提を「その前提が無い場合」に置き換えたとき、より少ない実装・説明で済む別解が出るかを検討させる。受け取った別解は鵜呑みにせず、自分でコードを読んで検証する。
手順7: 報告
結果を会話に出力する。ファイルには保存しない。提案・分類で停止し、コードの自動適用はしない。どの別解を採用するかは人間が判断する。
報告フォーマット:
## 定石外発想によるシンプル化検討
### 対象
{再考対象の解の要約。コールドスタート時は推定した対象も明記}
### 各前提の再考結果
列挙した前提ごとに:
- **前提**: {内容}
- **前提を外した場合の別解**: {具体的な別解。シンプルにならない場合はその旨と理由}
- **5観点比較と前提解除に必要な別の仕組み**: {効くものだけ}
- **分類**: 今すぐ検討すべき / 将来の論点 / 現状の採用案で妥当
### 推奨アクション
{「今すぐ検討すべき」があれば何を検討すべきか。無ければ「現状の採用案で妥当」と結論する}
