mcpField
S
simplify-layout

simplify-layout

github.com/dobroslavradosavljevic開発349 回インストール5 日前に更新
リポジトリ

simplify-layout について

コードツリーとファイル名の整理を計画・実行するスキルです。分類を明確にして名前を短くしたい開発者向けで、明示的な依頼がない限り読み取り専用の提案にとどまります。

主な機能

  1. 01フォルダー文脈に沿った短いファイル名
  2. 02関連コードの同一フォルダーへの集約
  3. 03命名と構成上の問題の特定
  4. 04変更前後のパス対応表の作成
  5. 05依頼に応じたパス変更の実施

活用シーン

  1. 01機能フォルダー再編の計画
  2. 02重複や長いファイル名の削減
  3. 03分散した関連モジュールの整理
  4. 04承認済みファイル移動案の適用

インストール

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

$npx skills add https://github.com/dobroslavradosavljevic/skills --skill simplify-layout

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

同梱ファイルagents/openai.yamlreferences/layout-model.md

詳細

レイアウトをシンプルにする

ファイルツリーは、名前を短くし、適切にグループ化してください。フォルダーで文脈を示し、末端のファイル名は短い動詞や観点にし、関連するコードをまとめます。

標準的な構成:references/layout-model.md。

対象範囲

  1. ユーザーが指定したパスを最優先します(パッケージ、機能、またはサブツリー)。
  2. パスが指定されておらず、差分がレイアウトに関するものなら、現在の Git 変更を対象にします。
  3. 境界が曖昧な場合は、一度だけ確認します。

デフォルトでは提案します(読み取り専用のリネーム/グループ化マップ)。ユーザーが apply / migrate / implement と指示した場合にのみ、パスを書き換えます。

最初の手順

  1. プロジェクトに命名規則やレイアウトのガイダンスがあれば読みます(AGENTS.md、CONTRIBUTING、ネストされた所有権に関するドキュメント、デザインシステムのドキュメント)。
  2. 対象のツリーを Glob し、現在のレイアウトを簡略化して図示します。
  3. レイアウトモデルを読み込みます:references/layout-model.md。
  4. 役割が似た近接フォルダーを1〜2個比較します(public/ / private/ のようなローカルな規則や信頼境界を確認する場合。任意)。

原則

1. ファイル名の接頭辞はパスの文脈で置き換える

親フォルダー(またはパッケージ)の名前を末端のファイル名で繰り返さないでください。

避ける推奨
queries/user-profile-query.tsqueries/users/profile.ts
auth/auth-token-helper.tsauth/token.ts
rows/events/event-row-mapper.tsrows/events/map.ts
packages/billing 配下の billing-invoice-summary.tsinvoices/summary.ts
2. フォルダーは名詞/ドメイン、ファイルは観点/操作
  • ドメインフォルダー:users/、billing/、auth/、orders/、seed/
  • 末端のファイル:card.ts、detail.ts、overview.ts、create.ts、sync.ts、map.ts
  • アーキタイプで必要な場合は、役割が明確なフォルダーを使います:queries/、services/、 components/、hooks/、errors/、utils/。これらも短く保ちます。
3. 関連するコードを同じ親の下にまとめる

一緒に変更される関連ファイルは、同じフォルダーに置きます。次のような構成を優先します。

queries/
  users/profile.ts
  users/list.ts
  orders/detail.ts
  orders/overview.ts
  billing/invoice.ts

users-profile.ts、orders-detail.ts、billing-invoice.ts を同じ階層に平坦に並べたり、関連モジュールを無関係なルートに分散させたりするのは避けます。

4. 名前は短くし、曖昧な場合だけ明示する
  • 明確なら1語を優先します:day、stamp、lookup、list、card
  • 必要な場合だけ、複数語をケバブケースにします:dimension-filters.ts、 currency-fraction-digits.ts
  • 用語集が必要になるような、難解な2〜3文字の略語は作りません。
  • サービスやパッケージのフォルダー名は、公開ドメイン名である場合は長いままでも構いません (analytics-traffic-read)。その配下のファイル名は短くします(service.ts、errors/…)。
5. 階層の深さはグループ化のために使い、形式のために増やさない
  • 複数のドメインが混在する場合や、名前に接頭辞が付き始めた場合は、平坦なフォルダーを分割します。
  • 「後で使うため」の空の足場フォルダーは追加しません。
  • utils/helpers/lib のような連鎖したネストは避けます。非公開ヘルパー用のフォルダーは1つで十分です。
  • 既存の信頼境界(public/ / private/ / internal/)を尊重します。その内部の名前は短くしますが、境界をなくすために平坦化してはいけません。
6. 1つのファイルにつき、主な関心事は1つ

無関係なエクスポート群が混在している場合や、継続的な増加が見込まれ、ファイルが約250〜400行を超える場合は分割します。分割後のファイル名には観点を使い、helpers / misc / shared2 は使いません。

ワークフロー

提案(デフォルト)
  1. 現在のツリーを簡略化して図示します。
  2. 問題点を指摘します。長い名前、繰り返されるパス要素、複数ドメインの混在、関連ファイルの分散、巨大なファイル、不要なネストなどです。
  3. アーキタイプ(パッケージ、機能、UIなど)に合わせてレイアウトモデルを適用し、目標ツリーを提案します。UIにデータレイヤー向けのフォルダー名を無理に適用しないでください。
  4. リネーム/移動するすべての項目について、変更前 → 変更後のパスを表にまとめます。
  5. ユーザーから明示的に依頼されない限り、リネームしてはいけないものを挙げます(ディスク上のマイグレーション、公開 SDK のパス、永続化されたリソース ID、API ルート)。
適用(依頼された場合のみ)
- [ ] Create/move/rename files per the map
- [ ] Update imports, package exports, and path aliases as needed
- [ ] Move colocated tests with their sources
- [ ] Update nearest ownership/layout docs if paths changed
- [ ] Delete emptied leftovers
- [ ] Run the project's targeted format/lint/typecheck/tests for touched areas

動作を維持します。サブツリー内ですでに使われていない限り、バレル(index.ts / index.js)は追加しません。適用済みのマイグレーションや外部との契約はリネームしません。

指摘すべき問題

  • 親フォルダー名を繰り返すリーフ名(…/events/event-*.ts)
  • 所有パッケージ内のパスでパッケージ名やブランド名を繰り返す (packages/acme 配下の acme-*)
  • 多数のファイル名をプレフィックスで区別しているフラットなディレクトリ(foo-bar-baz.ts の兄弟ファイル)
  • 共通の親を持たず、関連モジュールが離れたフォルダーに分かれている
  • utils/、helpers/、common/、misc/ などの寄せ集めディレクトリ
  • サービスフォルダーを something.service.ts に集約している(そのローカルなサービスの構成として something/service.ts が望ましい場合)
  • あいまいなレイヤー名のセグメントが続く深いツリー

修正ルール

  • ロジックを書き換えるより、名前変更や移動を優先する
  • 短い名前とグループ化のルールを適用しつつ、ローカルのアーキタイプ規約(機能ごとの信頼区分、UI プリミティブ)に合わせる
  • 無関係な作業ツリーの変更には手を加えない
  • ユーザーが実装を依頼しない限り、読み取り専用とする

検証

変更したファイルまたはパッケージだけに対して、プロジェクト既存の品質チェックコマンド(フォーマット、リント、型チェック、テスト)を使用します。名前変更が共有コントラクトにまたがる場合を除き、リポジトリ全体のチェックより対象を絞ったチェックを優先します。

スキーマ、マイグレーション、または生成パスの成果物を移動した場合は、その対象範囲に対するプロジェクト標準のマイグレーションまたはコード生成の手順を実行します。

レビュー出力

## Scope

[path]

## Current (abbrev)

[tree]

## Friction

1. …

## Target

[tree]

## Rename map

| Before | After |
| ------ | ----- |

## Do not rename

- …

## Apply?

Propose only / ready to apply when asked

関連スキル

スキル使用する場面
unsmell命名やグループ化以外の保守性(重複、複雑さ、型)を改善する場合

マルチエージェントによる検証

このスキルがマルチエージェントの実装または修正ワークフロー内で実行される場合、各サブエージェントは割り当てられたファイル/パッケージ/対象範囲に対して対象を絞ったチェックのみを実行し、より広範なチェックが必要かどうかを報告します。オーケストレーターがプロジェクト全体の品質チェックの手順を管理し、最終チェックで失敗した場合は、担当するサブエージェントに対応を振り分けます。 マルチエージェントの実行環境がない場合は、チャット内で同じ対象を絞ったチェックを実行します。

コメント