mcpField
I
inspect-role-naming

inspect-role-naming

github.com/venhdevテスト・品質159 回インストール今日更新
リポジトリ

inspect-role-naming について

inspect-role-naming は、リポジトリの命名規則に照らしてコードの役割と名称を監査するスキルです。局所的な改名と構造的なリファクタリングを区別し、所見をまとめます。

主な機能

  1. 01規則に基づく命名監査
  2. 02改名とリファクタリングの分類
  3. 03表面的・低リスクな問題の除外
  4. 04構造化された監査レポートの作成

活用シーン

  1. 01アーキテクチャ関連の命名のずれの確認
  2. 02責務を誤認させるシンボルの特定
  3. 03局所修正と構造変更の切り分け

インストール

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

$npx skills add https://github.com/venhdev/skills --skill inspect-role-naming

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

同梱ファイルreferences/role-naming-rubric.md

詳細

inspect-role-naming — アーキテクチャ上の役割と命名規則の監査

ドメインの評価基準

1. 対象範囲と許容範囲のガードレール(無視するもの)
  • 重要なリスクに限定する:危険なアーキテクチャ上の誤表現、実行時の衝突、境界スキーマの漏出だけに焦点を絞ります。
  • 問題のないコードは許容する:小規模なローカルヘルパー(メソッドが 3 個未満)、内部変数名の簡潔さ、アクセサー内の無害なメトリクス/ログ出力、見た目だけのスタイルの違いは許容します。正常に動作し、一貫性のあるコードにリファクタリングを強制してはいけません。
  • 判断の根拠:命名と役割の整合性は、references/role-naming-rubric.md(またはホストリポジトリの正式な命名仕様。こちらが常に優先されます)に厳密に照らして評価します。
2. 判断の分岐:[RENAME] と [REFACTOR]
  • [RENAME](純粋な命名のずれ):根底にある責務は単一で妥当であり、識別子/接尾辞だけが references/role-naming-rubric.md からずれています。修正は局所的で、リスクも低いものです。
  • [REFACTOR](役割の不一致/責務の漏出):シンボル名が複数の異なる責務を隠していたり、誤った期待を抱かせたりしています(例:外部 API を呼び出すリポジトリ)。名前を変更する前に、構造を切り出す必要があります。

標準出力仕様

# Role & Naming Audit Dossier: <Target Scope>

## 1. Executive Summary
- **Target Inspected**: `<directory_or_file_path>`
- **Health Rating**: <PRISTINE | LOCALIZED_DRIFT | SYSTEMIC_DEBT>
- **Primary Bottleneck**: <Single-sentence summary of greatest role or boundary hazard>

## 2. Load-Bearing Defect Catalog
### [<CRITICAL | MAJOR>] [<RENAME | REFACTOR>] <Dimension>: `<Target Symbol>`
- **Offending Code**: [<file>#L<N>](file:///path/to/file#L<N>)
- **Violated Rubric**: [<spec_or_rubric>](references/role-naming-rubric.md#anchor)
- **Smell**: <Observable contract mismatch or dangerous collision>
- **Action**: <[RENAME] New Identifier OR [REFACTOR] Minimal Separation Path>

*(Emit 'No load-bearing role or naming defects observed' if clean)*
振り分け
  • 単一ファイル内の局所的なシンボル名変更または軽微なブール値の整理 →(/simplify-audit 経由)。
  • 複数ファイルにわたるシンボルの移行または構造的な役割の切り出し →(/changeset 経由)。

実行プロトコル

  1. 受付と参照基準の確認:

    • 対象パス(directory または files)を取り込みます。
    • ホストリポジトリに命名規則があれば、それを基準とします(プロジェクトの規則が優先されます)。なければ、references/role-naming-rubric.md を読み、適用します。
  2. ターン内での実践的な監査:

    • 評価基準に照らし、対象コードをそのターン内で直接監査します。
    • セクション 1 の許容範囲ガードレールを適用し、無害な慣用表現、ローカルな簡潔さ、正常に動作するヘルパーは厳密に無視します。
    • 各指摘について、修正方法を [RENAME] または [REFACTOR] のいずれかに明示的に分類します。
  3. 統合とターン終了ゲート:

    • 指摘を標準出力仕様に従ってまとめます。
    • 正式な健全性評価(PRISTINE、LOCALIZED_DRIFT、または SYSTEMIC_DEBT)を割り当てます。
    • 完成した報告書を会話ストリームに提示し、直ちにターンを終了します。

コメント