unconventional-simplification

name	unconventional-simplification
description	定石外発想で実装をシンプルにする。現状の発展型ではなく、実装の裏にある暗黙の前提条件を1つずつ外し、よりシンプルな別解がないか検討する。 ユーザーが「定石外発想で」「前提を疑って」「もっとシンプルにできないか」と言った時に使用する。
argument-hint	[対象ファイル/モジュール — 省略可]

定石外発想によるシンプル化手順書

このスキルは、採用済みの解をレビューしたり機能を足したりするものではない。解の裏にある暗黙の前提を列挙し、1つずつ外して、より少ない実装・説明で済む別解を探す。現状の発展型に流れず、要素の引き算で考える。

ゼロから案を作るのではなく、すでにある実装・方針・設計判断を再考対象にする。

手順1: 分析対象の特定

「いま再考すべき解（第一案）」を特定する。

1. 引数がある場合: 指定されたファイル・モジュール・機能を対象とする
2. 会話コンテキストがある場合: 直前に到達した方針・設計判断・実装アプローチを対象とする。これが主たる特定方法である
3. コールドスタートの場合: 会話コンテキストが薄く引数も無いときは、直近の変更を自動検出して対象とし、何を対象と推定したかを一言で明示する

対象を特定したら、その解を実装しているコードを以下の順で確認する:

1. 引数で対象ファイル・モジュールが指定されている場合は、まずそれを直接読む
2. 未commitの変更を git diff と git diff --staged で確認する
3. 未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観点で比較する。

1. 実装量: コードがどれだけ減るか
2. 既存仕様との互換性: 既存の動作・APIとの互換が壊れないか
3. 説明コスト: 概念や挙動の説明が難しくならないか
4. 運用・移行コスト: 既存データや運用フローの移行が要るか
5. 将来の保守性: 長期的に保守しやすくなるか

加えて、前提解除を成立させるために必要な別の仕組みを計上する。前提を外せた裏で追加実装・ドキュメント・教育などが要るなら、簡潔さの代わりにどこへコストが移ったかを正直に見積もる。

手順5: 分類

各別解を3つに分類する。

• 今すぐ検討すべき: シンプルさの利得が大きく、コストが見合う
• 将来の論点: いまは第一案で妥当だが、状況が変われば再考に値する
• 現状の採用案で妥当: 前提を外してもメリットが薄い、またはコストが上回る

手順6: 外部Agent相談（任意）

外部Agentへの相談は、ユーザーが明示的に求めた場合だけ行う。相談の進め方は codex-consultation / subagent-consultation の手順に任せ、このスキルは相談の中身だけを指定する。

外部Agentは放っておくと通常のレビューに流れるため、レビューではなく手順2〜5そのものを依頼すること。すなわち、外部Agent自身に根拠のある前提を列挙させ、各前提を「その前提が無い場合」に置き換えたとき、より少ない実装・説明で済む別解が出るかを検討させる。受け取った別解は鵜呑みにせず、自分でコードを読んで検証する。

手順7: 報告

結果を会話に出力する。ファイルには保存しない。提案・分類で停止し、コードの自動適用はしない。どの別解を採用するかは人間が判断する。

報告フォーマット:

## 定石外発想によるシンプル化検討

### 対象

{再考対象の解の要約。コールドスタート時は推定した対象も明記}

### 各前提の再考結果

列挙した前提ごとに:

- **前提**: {内容}
- **前提を外した場合の別解**: {具体的な別解。シンプルにならない場合はその旨と理由}
- **5観点比較と前提解除に必要な別の仕組み**: {効くものだけ}
- **分類**: 今すぐ検討すべき / 将来の論点 / 現状の採用案で妥当

### 推奨アクション

{「今すぐ検討すべき」があれば何を検討すべきか。無ければ「現状の採用案で妥当」と結論する}