mcpField
S
seam-ripper

seam-ripper

github.com/petekp開発4842 回インストール2 日前に更新
リポジトリ

seam-ripper について

コードベースの構造をマッピングし、不適切な境界、依存関係、抽象を特定する開発スキルです。依存関係図と根拠のある分析を作成し、具体的な再設計と移行手順を提示します。

主な機能

  1. 01モジュール、依存関係、インターフェースを整理
  2. 02契約と統合ポイントを追跡
  3. 03結合度と依存方向を評価
  4. 04よくあるアーキテクチャ上の問題を特定
  5. 05根拠と手順を伴う再設計を提案

活用シーン

  1. 01既存コードベースのモジュール境界をレビュー
  2. 02循環依存や過度な結合を発見
  3. 03移行手順を含む構造再設計を計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/petekp/claude-code-setup --skill seam-ripper

インストール後、Claude Code で/seam-ripperを入力して読み込まれたか確認します。

詳細

シームリッパー

コードベースの内部アーキテクチャを体系的に分解し、問題のある箇所を明らかにして、あるべき姿を提案します。

原則

聖域はありません。 既存のパターンは過去の判断の証拠であり、正しいことの証明ではありません。

継ぎ目が真実を明らかにします。 コンポーネントの接続方法から、ドキュメントに書かれている姿ではなく、システムの実態が見えてきます。

後方互換性は制約ではありません。 目標は正しいアーキテクチャです。移行は別の課題です。

複雑さは、無実が証明されるまで有罪です。 すべての抽象化、間接化、インターフェースは、その存在意義を示す必要があります。

実行

フェーズ 1：全体像を把握する

システムを評価する前に、内部構造の全体像を把握します。

  1. すべてのモジュール／パッケージ／名前空間を特定する - コードの境界づけられた単位をすべて列挙します
  2. インポート／依存関係のグラフをたどる - 何が何に、そしてなぜ依存しているのかを確認します
  3. 公開インターフェースを一覧にする - エクスポートされた関数、クラス、型、定数をすべて確認します
  4. データコントラクトを見つける - 境界をまたぐ共有型、DTO、スキーマを確認します
  5. 統合ポイントを特定する - モジュール同士が実際にやり取りする箇所を確認します

以下を示す依存関係マップを出力します。

  • モジュール → モジュールの依存関係と、その理由
  • 循環依存（明白な危険信号）
  • モジュールごとのファンイン／ファンアウト数
フェーズ 2：各継ぎ目を問いただす

特定した境界ごとに、次の質問に答えます。

インターフェースの明確さ

  • 公開インターフェースだけを見て、このモジュールの役割を理解できますか？
  • 「util」や「helper」のエクスポートがありますか？（問題の兆候：明確な責務がない）
  • インターフェースが実装の詳細を公開していませんか？

依存関係の方向

  • この依存関係は概念的に妥当ですか？
  • 「低レベル」のモジュールが「高レベル」のモジュールに依存していませんか？
  • この依存関係を逆転させることで、双方がシンプルになりませんか？

結合の評価

  • このインターフェースを変更すると、ほかにいくつのモジュールが壊れますか？
  • 結合はデータ、振る舞い、またはその両方を介していますか？
  • 直接呼び出す代わりに、イベント／メッセージにできませんか？

抽象化の整合性

  • このインターフェースから実装の詳細が漏れていませんか？
  • 呼び出し元が、モジュール内で行うべき処理をしていませんか？
  • 同じことを実現する方法が複数ありませんか？

コントラクトの安定性

  • このインターフェースは、過去にどのくらいの頻度で変更されましたか？
  • バージョン管理されたインターフェースや非推奨の警告はありますか？（問題の兆候：不安定なコントラクト）
  • テストでこのインターフェースをモックしていますか？（結合による問題の証拠）
フェーズ 3：失敗パターンを特定する

次のようなシステム上の問題を探します。

パターン症状実際の問題
ゴッドモジュールどこからでもインポートされ、公開 API が巨大ドメイン境界の欠如
ショットガン手術1 つの変更に、多数のモジュールの編集が必要責務の分散
機能への執着モジュール A がモジュール B のデータに頻繁にアクセスするデータ／振る舞いの所有者が不適切
不適切な親密さ2 つのモジュールが非公開の詳細を共有する1 つのモジュールにまとめるか、明示的なコントラクトを設けるべき
仲介者モジュールが別のモジュールに処理を委譲するだけ不要な間接化
並行階層X を追加すると、別のモジュールに Y の追加も必要になる抽象化の欠如
投機的な汎用性柔軟性のためのインターフェースが使われない時期尚早な抽象化
役割を失った抽象化実装が 1 つだけの状態が続くインターフェース目的のない抽象化
フェーズ 4：再設計を提案する

重大な問題ごとに、次の内容を提示してください。

1. 問題点の指摘 何が問題で、なぜ重要なのかを明確に述べてください。具体的に説明してください。

  • 「モジュール X には 47 個の公開エクスポートがあり、ほかの 23 個のモジュールからインポートされています」
  • 「User 型は core で定義されていますが、そのフィールドが使われているのは billing だけです」

2. 正しいアーキテクチャ あるべき構成を説明してください。

  • 責務を明示した明確なモジュール境界
  • 概念的な階層に沿った依存関係の方向
  • 実装ではなく意図を公開するインターフェイス

3. 変革の手順 問題のある状態から正しい状態に移行するための具体的な手順を示してください。

  • 何をどこに移すか
  • 何を分割または統合するか
  • どのインターフェイスを変更するか
  • どのような新しい抽象化が生まれるか

4. 根拠 なぜこれがより良いのかを説明してください。

  • 結合度の低減（数値で示す：N 件のインポート → M 件のインポート）
  • より明確な責務
  • テスト、拡張、置き換えの容易さ

出力形式

# Seam Analysis: [System/Area Name]

## Dependency Map
[Visual or textual representation of module dependencies]

## Critical Findings

### Finding 1: [Problem Name]
**Location:** [modules/files involved]
**Severity:** Critical | High | Medium
**Pattern:** [which failure pattern]

**Evidence:**
[Specific code/structure references]

**Indictment:**
[Clear statement of what's wrong]

**Redesign:**
[Proposed correct architecture]

**Transformation:**
1. [Step]
2. [Step]
...

### Finding 2: ...

## Recommended Architecture

[Overall vision for how the system should be structured]

## Transformation Sequence

[Ordered list of changes, grouped by logical phases]

守るべき原則

次のことは拒否してください。

  • 壊れたアーキテクチャを維持する「段階的な改善」の提案
  • 設計の悪さを正当化する「でも動いている」という主張
  • 問題を解決せずに隠すアダプターやファサードの推奨
  • 広く使われているというだけでインターフェイスを維持すること

常に次のことを実行してください。

  • 症状ではなく、実際の問題を明示する
  • 妥協案ではなく、正しい設計を提案する
  • 可能な限り、結合度と複雑さを数値化する
  • 再設計が正しいものとなる概念モデルを説明する

コメント

Markdown 対応