mcpField
D
deslop

deslop

github.com/mikecann開発22203 回インストール4 週間前に更新
リポジトリ

deslop について

Deslop は、最近書かれたコードを動作を変えずに読みやすく整えるスキルです。対象範囲の限定、style.md の確認、API の維持を含む編集手順を定めています。

主な機能

  1. 01最近編集したコードの整理
  2. 02動作と公開 API の維持
  3. 03関連ファイルだけを編集
  4. 04style.md のスタイル規則を適用
  5. 05生成物とベンダーコードを除外
  6. 06変更点と見送った作業の要約

活用シーン

  1. 01現在のセッションで書いたコードの簡素化
  2. 02動作を変えずに条件分岐を整理
  3. 03無関係な編集を避けたコード整理

インストール

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

$npx skills add https://github.com/mikecann/agent-skills --skill deslop

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

同梱ファイルstyle.md

詳細

Deslop

コードを書いた直後に、より簡潔で、シンプルで、意図が明確に伝わる形に整えます。

まず style.md を読んでください。このファイルがスタイルルールの基準です。

プロセス

  1. 対象ファイルを特定します。
    • このセッションで変更されたファイルから始めます。
    • 利用できる場合は git diff を使い、そうでなければ最近の編集内容やユーザーが明示したファイル一覧を使います。
    • 無関係なファイルには手を加えないでください。
  2. 編集する前に、対象ファイルをそれぞれ読みます。
  3. クリーンアップ作業には並列のサブエージェントを使います。
    • ファイルが複数ある場合は、サブエージェントごとに担当を分けます。
    • 大きなファイルが1つある場合も、分離した2回目の確認として1つのサブエージェントを使ってかまいません。
    • 各サブエージェントには、担当するファイルの一覧を正確に伝えます。
    • 対象が小さなファイル1〜3個だけなら、1回の作業でかまいません。ルールを機械的に満たすためだけにサブエージェントを追加しないでください。
  4. 各サブエージェントには次のように指示します。
    • skills/deslop/style.md を読む
    • 担当ファイルだけを簡潔にする
    • 動作を完全に維持する
    • 明確さが向上せず、変更の手間だけが増える変更はスキップする
    • 変更内容と意図的に見送った内容を簡潔に報告する
  5. サブエージェントの出力を確認して変更を適用し、自分で最終確認を行います。
  6. クリーンアップの内容を具体的に要約します。
    • 例:「ネストした条件分岐を3つフラット化し、ブール値の変数名を2つ変更し、非 null アサーションを1つ置き換えました」

制約

  • 動作は絶対に変更しないでください。これはスタイルの調整であり、リファクタリングではありません。
  • スタイルルールと動作の維持が両立しない場合は、動作の維持を優先してください。
  • 大規模な書き換えより、小さく局所的な編集を優先してください。
  • より深いアーキテクチャのリファクタリングをしないと十分に改善できない場合は、無理に範囲を超えて修正せず、その旨を伝えてください。
  • 生成ファイル、ベンダーコード、ビルド出力、ロックファイルは対象外にします。
  • ユーザーから依頼がない限り、テストは対象外にします。
  • 適用するとかえって読みづらくなるルールはスキップしてください。
  • ユーザーから API の変更を明示的に依頼されない限り、エクスポートされた API と公開 API は維持してください。
  • ユーザーから型や API の変更を明示的に依頼されない限り、エクスポートされた TypeScript のシグネチャは維持してください。
  • すでにコードが十分に整理されている場合は、無理に変更せず、その旨を伝えてください。

最初に確認すること

  • ネストした条件分岐をガード節に置き換える
  • else の代わりに if と早期リターンを使う
  • 再代入がない場合は let ではなく const を使う
  • ! による非 null アサーションではなく、型の絞り込みや直接の削除を使う
  • !!value ではなく、Boolean(value) や明示的な比較を使う
  • isOpen、hasItems、canRetry のように、より明確なブール値の名前を使う
  • 1つの明確な役割を持つ、より短い関数にする
  • 処理を分け、ヘルパーを抽出して、オーケストレーション関数を小さくする
  • クエリやデータの収集を、アクションや副作用から切り分ける
  • 副作用を正確に表す関数名を使う
  • 責務を抱え込みすぎたフックやコンポーネントは、小さな純粋ヘルパーに分割する
  • 長い位置引数リストの代わりにオブジェクト引数を使う
  • 判別共用体を網羅的に処理する
  • 早期リターンを使って、React のレンダー分岐をフラット化する
  • ロジックが1か所でしか使われない場合は、JSX のイベントハンドラーをインライン化する
  • 複数の場所で再利用されるハンドラーは、関数として外に定義しておく

悪い例と良い例

// Bad: nested control flow and unnecessary else
function getLabel(user?: User) {
  if (user) {
    if (user.name) {
      return user.name;
    } else {
      return "Anonymous";
    }
  } else {
    return "Anonymous";
  }
}

// Good: early returns, flat flow
function getLabel(user?: User) {
  if (!user?.name) return "Anonymous";
  return user.name;
}
// Bad: hoisted one-off handler and && render
const handleClick = () => doSave();
return hasError && <ErrorBanner onRetry={handleClick} />;

// Good: inline simple handler and explicit null branch
return hasError ? <ErrorBanner onRetry={() => doSave()} /> : null;

チェックリスト

  • 最初に style.md を読んだ
  • 関連するファイルだけを変更した
  • 有効な場合はサブエージェントを使ってクリーンアップした
  • 動作を維持した
  • 変更を見送った箇所には理由がある
  • 最終要約で変更内容を説明した

コメント