mcpField
D
dsa-codebase-audit

dsa-codebase-audit

github.com/scottwaterテスト・品質158 回インストール1 週間前に更新
リポジトリ

dsa-codebase-audit について

DSA Codebase Audit は、アプリケーション全体のデータ構造や構成モデルに関する実質的な簡素化案を探す、読み取り専用のスキルです。サブシステムごとに調査し、提案を個別に検証して優先順位付きレポートを作成します。監査中、リポジトリは変更しません。

主な機能

  1. 01サブシステムの網羅性一覧を作成
  2. 02実装・インターフェース・テストの読み取り専用調査
  3. 03一元管理された監査記録
  4. 04簡素化案の検証と重複排除
  5. 055 種類の独立した監査検証
  6. 06優先順位付き提案レポートの作成

活用シーン

  1. 01アプリケーション各サブシステムのデータ構造レビュー
  2. 02実装やテストの根拠に基づく提案の確認
  3. 03監査中にコードを変更せず後続のリファクタリングを計画

インストール

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

$npx skills add https://github.com/scottwater/skills --skill dsa-codebase-audit

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

同梱ファイルagents/openai.yamlREADME.md

詳細

DSA コードベース監査

アプリケーション全体を対象に、読み取り専用でデータ構造とアルゴリズムを監査します。見た目だけのリファクタリングではなく、表現や構成モデルを大幅に簡素化できる箇所を少数見つけてください。

監査範囲

レビュー対象のリポジトリは変更しないでください。読み取り専用コマンドのみで調査してください。ファイルの編集、パッチの生成、テストの実行、依存関係のインストール、フォーマッターやジェネレーターの実行、推奨事項の実装、コミット、プッシュは禁止です。既存のテストは、実行せずにソース上の根拠として確認してください。

実行環境で利用できる場合は、新しい読み取り専用サブエージェントを使用してください。各ワーカーには、重複しないサブシステムを1つ割り当ててください。並行作業は、積極的に調整できるレーン数以内に抑えてください。新しいエージェントを利用できない場合は、調整役のコンテキストでサブシステムを1つずつレビューし、その制約を明記してください。

調整役のコンテキストで、正規の監査台帳を1つ管理してください。台帳ではサブシステムの一覧、ステータス、採用した指摘、明示的な対象外、横断的なパターン、重複または置き換えられた指摘、優先度、依存関係、監査ログを管理します。ワーカーからの報告は台帳の根拠であり、台帳と並ぶ別の情報源ではありません。

すべての一覧項目が完了し、最終監査が独立した検証に合格するまで、監査を終了してはいけません。

1. 対象範囲の合意を確立する

リポジトリのルート、プロジェクトのガイダンス、ディレクトリ構造、マニフェスト、エントリーポイント、公開インターフェース、依存関係の境界、テストの構成を確認してください。レビューのレーンを開く前に、特定できるすべてのサブシステムを一覧化してください。

重要な関連箇所があれば、フロントエンド、バックエンド、共有インフラストラクチャ、プラットフォームブリッジ、生成されたコントラクトの管理元、テストまたはツールのインフラストラクチャを含めてください。各サブシステムには、以下を設定してください。

  • 安定した ID と説明的な名前
  • 正確で、他と重複しない所有範囲
  • 主要な実装ファイル
  • 関連する公開インターフェース、主要な呼び出し元、テスト
  • 次のいずれかのステータス:queued、in-review、recommend、skip

広範すぎる包括的な項目だけでは、対象範囲を網羅したことにはなりません。ワーカーが他の項目を担当せずに、担当する動作とその呼び出し元を調査できるよう、必要に応じて細分化してください。

関連するすべてのソース領域とテスト領域が、監査可能なサブシステムにそれぞれ正確に1つ割り当てられ、境界が重複せず、正規の台帳にすべての項目が記載された時点で、このステップは完了です。

2. 範囲を限定したサブシステムレビューを実施する

各 queued 項目を新しいワーカー1人に割り当て、ディスパッチ前にステータスを in-review に変更してください。1人のワーカーに複数のサブシステムを割り当ててはいけません。境界が明確に異なる独立した項目に限り、並行して実施してください。それ以外は順番に実施してください。各バッチでは統合された待機を1回行い、作業を進めているワーカーが完了するまで待ち、代わりのレーンを開く前に利用可能な結果をすべて回収してください。

割り当てた項目の情報を記入して、各ワーカーに次の指示を渡してください。

Review subsystem <stable ID and name> for at most two materially useful simplifications in its data structures, state representation, control flow, algorithms, or organizing model.

Boundary: <exact owned files and behavior>
Key files: <paths>
Interfaces, callers, and tests to inspect: <paths or symbols>

This is read-only. Inspect the implementation, public interfaces, major call sites, and existing tests. Stay inside the assigned ownership boundary. Name cross-subsystem concerns, but do not expand scope to solve them.

Look for:
- scattered booleans or nullable fields that permit invalid combinations and should become a state machine or discriminated union;
- repeated assumptions about object shape that need one shared typed model;
- duplicated branching that a small map, registry, reducer, transition table, or command model would remove;
- unclear state or behavior ownership that a small module boundary would clarify;
- repeated scans, transformations, or lookups where a more appropriate collection or index materially simplifies behavior;
- lifecycle, concurrency, or async representations that permit stale or contradictory state.

Prefer clear local code when it is already sufficient. A recommendation must remove material complexity rather than move existing branching behind a new type. Exclude changes justified only by stylistic consistency, hypothetical extensibility, or minor line-count reduction.

Return at most two opportunities. Return `skip` when none clears that threshold.

For each opportunity provide:
1. Verdict: `recommend` or `skip`.
2. Evidence with exact file and line references.
3. Current complexity or invalid states.
4. Proposed representation and why it is simpler.
5. Smallest credible implementation scope, including affected files and interfaces.
6. Regression risks and migration concerns.
7. Existing and additional validation required.
8. Confidence: `high`, `medium`, or `low`.

ワーカーが失敗した場合や報告が得られない場合、その項目は未完了のままです。対象外にはできません。その項目を新しいレーンで再実行するか、順次レビューしてください。

各項目について、スキーマを満たす候補が1件または2件、あるいは明示的な skip を含む利用可能な報告が得られた時点で、このステップは完了です。

3. 検証と統合

各候補について、採用する前に、現在の実装、呼び出し元、公開契約、テストを個別にたどって検証します。引用した各行と、主張されている無効な状態、重複、所有権の問題、またはアルゴリズム上のコストを確認します。

次のいずれかに該当する候補は、却下、範囲の限定、または優先度の引き下げを行います。

  • 曖昧である、またはソースコードによる根拠がない;
  • 別の指摘と重複している;
  • 意図されたセマンティクスを誤解している;
  • 複雑さを単に別の場所へ移している;
  • 実証された必要性を超える、より広範な抽象化を導入している;
  • 仮定上の規模や拡張性に依存している;
  • サブシステムの境界外にある。

根本原因に基づいて重複を統合します。採用する各推奨事項を、権威ある単一のサブシステムに割り当て、関連する行は指摘を繰り返さず、対象として記録します。検証済みの指摘なしという結果は、明示的なスキップとして記録します。コーディネーターによる検証後にのみ、各行を recommend または skip に更新します。

queued または in-review の行がなくなるまで、範囲を限定したバッチを開き続けます。

すべてのインベントリ行に検証済みの処置があり、採用するすべての指摘に必須の8項目がそろった時点で、このステップは完了です。

4. 監査を監査する

次の項目について、独立した新たな読み取り専用のレビューを実施します。可能な場合は別々のエージェントを使用します。

  1. リポジトリの網羅性と、欠落しているサブシステム境界;
  2. 指摘の重複と所有権の重複;
  3. 重要性と過剰な抽象化;
  4. 指摘スキーマの完全性;
  5. 依存関係を考慮した優先順位付け。

網羅性レビューで実際の見落としが見つかった場合は、新たなサブシステム行を明示的に追加し、監査します。既存の行の範囲を広げて見落としを隠すのではなく、完了済みの境界を維持します。報告する前に、その他の検証上の不備をすべて台帳で解決します。

具体的な影響度、確信度、実装工数、影響範囲、前提条件、順序の依存関係に基づいて、採用する推奨事項に優先順位を付けます。最初に実装すべき最適な単位を特定しますが、実装は行いません。

5つすべてのレビュー結果が記録され、見つかったすべての不備が解決または開示され、リポジトリが変更されていない時点で、このステップは完了です。

5. 報告

次のセクションを、以下の順序で含むレポートを1つ返します。

## Summary
<Scope, recommendation count, skip count, and strongest themes.>

## Coverage
| ID | Subsystem | Ownership boundary | Key files | Public interfaces and major call sites | Tests | Disposition |
| --- | --- | --- | --- | --- | --- | --- |

## Prioritized recommendations
### 1. <Concrete simplification> — <confidence>
- **Verdict:** `recommend`
- **Subsystem:** <ID and name>
- **Evidence:** `path:lines`, ...
- **Current complexity:** <complexity or invalid states>
- **Proposed representation:** <model and why it is simpler>
- **Smallest scope:** <affected files and interfaces>
- **Risks:** <regression and migration concerns>
- **Validation:** <existing and additional validation required>
- **Priority:** <impact, effort, blast radius, prerequisites, and dependencies>

## Cross-cutting patterns
<Patterns observed across authoritative subsystem findings.>

## Explicit skips
<Subsystems with a concise verified reason no recommendation cleared the bar.>

## Audit validation
<Results of the five independent passes, worker failures or limitations, and confirmation that the repository remained unchanged.>

Coverage に特定可能なすべてのサブシステムが含まれ、すべての行が推奨事項または明示的なスキップで終わり、すべての指摘に正確な根拠、範囲、リスク、検証方法があり、重複や根拠の弱い抽象化がなく、優先順位と依存関係に矛盾がなく、5つすべての検証レビューが記録され、レビュー対象のリポジトリが変更されていない場合にのみ、監査は完了です。

コメント