mcpField
U
unconventional-simplification

unconventional-simplification

github.com/shokaiDevelopment3139 installsUpdated 5d ago
Repository

About unconventional-simplification

unconventional-simplification is a skill for developers reconsidering an existing implementation, approach, or design decision. It tests evidence-based assumptions one at a time, compares costs, and reports alternatives without applying code changes.

Key features

  1. 01Identify the solution to reconsider
  2. 02List evidence-based assumptions
  3. 03Test assumptions and develop alternatives
  4. 04Compare implementation and maintenance costs
  5. 05Classify options in a report

Use cases

  1. 01Reconsider recent code changes
  2. 02Find simpler alternatives to an established design
  3. 03Assess compatibility and migration costs of simplification

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/shokai/agent-skills --skill unconventional-simplification

After installing, type/unconventional-simplificationin Claude Code to confirm it loaded.

Details

From the project README

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

このスキルは、採用済みの解をレビューしたり機能を足したりするものではない。解の裏にある暗黙の前提を列挙し、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観点比較と前提解除に必要な別の仕組み**: {効くものだけ}
- **分類**: 今すぐ検討すべき / 将来の論点 / 現状の採用案で妥当

### 推奨アクション

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

Comments

Markdown supported