deepen について
deepenは、テストが通り時間に余裕があるときにモジュール設計を改善する開発スキルです。一度に浅いモジュールを1つ選び、動作を変えずにインターフェースを縮小します。
主な機能
- 01最も浅いモジュールの選定
- 02設計上の欠陥の診断
- 03より深いインターフェースパターンの調査
- 04仕様変更とテストの提案
- 05動作不変の確認
活用シーン
- 01複数ファイルにまたがる変更の削減
- 02呼び出し側に漏れる設定判断の隠蔽
- 03テスト通過後のモジュール設計改善
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/deepenを入力して読み込まれたか確認します。
詳細
deepen — モジュールを深くする
振る舞いを最優先します。変更の前後でテストがすべて成功していること。すべての変更はインターフェースを縮小するか、判断を隠すものです。深くし、変更を繰り返すだけにしないでください。
深いモジュールは小さなインターフェースの背後に多くのものを隠します。浅いモジュールは、そのインターフェースを使うコストが、自分でコードを書くコストと同じくらいかかります。複雑さ ＝ 依存関係 ＋ わかりにくさであり、複雑さは積み重なります。deepen は、複雑さが §B になる前に、それを減らすための余裕を使います。ビルドが成功し、減らすための予算があるときに実行してください。締め切りに追われているときには実行しないでください。
DEEPEN を実行するタイミング
- ビルドが成功し、テストも通っていて、トークンに余裕があるとき。
- モジュールのインターフェースが実装と同じくらい複雑に感じられるとき（浅い兆候）。
- 同じ変更のたびに多くのファイルに手を入れているとき（変更の波及）。
- ユーザーが設計品質の改善を明示的に依頼したとき。
⊥ 機能の実装途中や、プレッシャーのかかる状況では実行しないでください。deepen は計画的に行う作業であり、反射的に行うものではありません。
5 つのステップ
1. 浅いモジュールを選ぶ
仕様が触れるモジュールを調べ、浅さ（インターフェースの広さに対する作業量）で順位付けします。最も問題の大きい1 つを選びます。兆候：
- 別のメソッドに処理を渡すだけのメソッド（浅い層）。
- 使う側が正しく使うために 5 つのフラグを設定しなければならない（設定の漏出）。
- 同じ抽象化が 2 つの層で繰り返されている（情報隠蔽ができていない）。
?や §B が、わかりにくいインターフェースにたどり着く。
1 回のパスにつきモジュールは 1 つだけです。深くする作業は外科手術のように行い、⊥ コードベース全体を一掃すること。
2. 診断する
設計上の欠陥を簡潔に名付け、file:line を示します。
src/auth/token.go: 6 引数のコンストラクターがローテーション方針をすべての呼び出し元に漏らしています。浅い設計です。 複雑さが実在するのは、変更の波及、認知負荷の高さ、または未知の未知（呼び出し元が正しく呼び出すために、隠れた事実を知る必要があること）として現れる場合だけです。
3. 深くする方法を調べる
より深い形とはどのようなものかを考えます。既知のパターンを取り入れる（外部事例なら research に渡す → §R）か、コードベース内のより優れたモジュールから導きます。深くするための変更：
- 複雑さを内側に引き込む — 難しい部分を内部に隠し、呼び出し元には簡単な使い方を提供します。
- エラーが起きないように設計する — その問題が発生し得ないインターフェースを設計します。
- 情報隠蔽 — 1 つの判断を 1 つのモジュールに閉じ込め、呼び出し元にそれを学ばせないようにします。
- 個別対応のメソッドの寄せ集めより、汎用インターフェースを選びます。
4. 提案する
黙って書き換えるのではなく、仕様の編集として変更案を作成します。
- モジュールの新しい、よりシンプルな §I の形。
- 今後のビルドで再び浅くならないよう、不変条件を固定する §V。
- 対応する §V/§I をそれぞれ示した §T のリファクタリング行。 作成は spec に依頼します。変更前後のインターフェースを示し、ユーザーが縮小を確認できるようにします。
5. 振る舞いが保たれていることを検証する
リファクタリング ≠ 書き換えです。作業の開始前と完了後に、すべてのテストが成功していることを確認します。振る舞いを変える深掘りは、実態としては隠れた機能追加です。そこで止めて、/spec + /build を通してください。新しいインターフェースには、以前の呼び出し元が引き続き動作することを証明するテストを追加します。
終了するタイミング
選んだモジュールのインターフェースが明確に小さくなり、隠れていた判断が漏れなくなり、テストが成功し、新しい形が §I/§V に記録されたら完了です。5 つのモジュールをかき回すより、1 つのモジュールを深くするほうが有益です。予算が残っていれば、次に浅いモジュールを選び、新しいパスを始めます。
境界
- ⊥ 振る舞いを変えること。変更前も変更後もテストが成功していること。構造だけを変えます。
- ⊥ SPEC.md を書くこと。§I/§V/§T を提案し、仕様の作成は spec が行います。
- ⊥ 1 回のパスで複数のモジュールを深くすること。
- ⊥ 締め切りに追われているときや、機能の実装途中に実行すること。これは余裕のある予算を使うパスです。
- ⊥ 1 回しか使わないコードに抽象化を追加すること。深いモジュールは、その内部を隠すだけの価値があります。先走った抽象化は、単に表面を広げるだけです。