mcpField
D
deslop

deslop

github.com/overextended開発209 回インストール2 週間前に更新
リポジトリ

deslop について

deslopは、動作を変えずにブランチ内のAI生成コードを整理するコーディングスキルです。差分で追加された行だけを対象にし、信頼できない入力へのセキュリティチェックを保ちます。

主な機能

  1. 01リファクタリングせず変更コードを整理
  2. 02ブランチとデフォルトブランチを比較
  3. 03未コミットの変更も対象
  4. 04セキュリティと権限チェックを維持
  5. 05既存ファイルのスタイルに合わせる

活用シーン

  1. 01ブランチのデバッグログや未使用インポートを削除
  2. 02新しいコードの深いガード節を簡素化
  3. 03変更で追加された詰め込み行を整形

インストール

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

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

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

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

詳細

AI 生成の不要なコードを取り除く

このブランチで変更されたコードを見つけ、そこに追加された AI 生成の不要なコードを取り除いてください。動作はそのままにしてください。これはクリーンアップであり、リファクタリングではありません。

対象範囲

  • Git リポジトリ:デフォルトブランチ(git merge-base HEAD origin/HEAD、それがなければ main または master)とのマージベースとの差分と、未コミットの変更。
  • Git がない場合(サーバーフォルダーによくあります):このセッションで変更されたファイルを使います。変更されたファイルがない場合は、クリーンアップするリソースまたはファイルを尋ねてください。

差分で追加された行だけに手を加えてください。その周辺のコードはスタイルを示すものであり、対象ではありません。

注目する点

各候補が不要かどうかは、そのファイルとリソース全体を基準に判断してください。あるリソースでは不要なコードが、別のリソースでは慣例に沿っていることもあります。

すべての言語

  • コードの内容を説明するコメント(-- loop through players など)、関数名を言い換えただけのコメント、ファイル内のコメントの書き方にそぐわないコメント。
  • デバッグの残骸:余計な print や console.log、コメントアウトされたコード。
  • 早期の return で解消できる深いネスト。
  • 詰め込みすぎたコード。「レイアウト」を参照してください。
  • ブランチで追加されたものの、使われていないローカル変数、インポート、パラメーター。
  • ファイル内の命名規則に合わない名前(snake_case のファイルでの camelCase、その逆など)。

Lua

  • 信頼できる経路で nil になり得ない値に対する pcall ラッパーや nil チェック:マニフェストで依存関係として宣言されているリソースのエクスポート、同じ関数内で直前に設定した値など。
  • ファイル内で使われていない場合の true または false との比較(if isOpen == true then など)。
  • ファイル内で local を使っている箇所に追加されたグローバル変数。ローカル化する前に、リソース全体でほかに使われていないか検索してください。リソース内のすべての Lua ファイルは、サイドごとにグローバルスコープを共有しているため、別のファイルから参照されている可能性があります。
  • 同じファイル内での Citizen.CreateThread/Citizen.Wait と CreateThread/Wait の混在。これらは同じ関数です。ファイル内の書き方に合わせてください。
  • リソースが ox_lib の依存関係にあり、ox_lib にすでにあるヘルパーを独自に実装している場合。たとえば、lib.table.contains を使うコードの隣にある contains ループや、ほかの箇所で lib.requestModel を使っているリソースにある RequestModel/HasModelLoaded の待機ループなど。ただし、ox_lib の関数が同じ動作をする場合に限って置き換えてください。先にソースを確認し、タイムアウト、戻り値、エラーの違いを把握してください。

TypeScript/JavaScript

  • 型エラーを黙らせる目的だけで使われている any へのキャスト、as unknown as、@ts-ignore/@ts-expect-error。
  • 信頼できる呼び出しを try/catch で囲み、エラーをログに記録するだけで処理を続行するもの。

レイアウト

エージェントはコードを詰め込みがちです。複数の文を一行に並べたり、ガード節を空行なしで連ねたり、複数行に折り返した条件を一つの if にまとめたりします。レイアウトはデフォルトブランチのファイル、またはブランチで変更していないファイルと比較して判断してください。ブランチでファイルの大部分を書き換えている場合、そのブランチのレイアウト自体が不要なコードの特徴です。

  • 一行につき一つの文にします。
  • 手順の間には空行を入れます。ガード節、検索、処理、応答の間が該当します。
  • ガード節を一行にするのは、短く、本文が単独の return または return false の場合だけです。テーブルを返す場合や、それ以外の処理をする場合は複数行にします。
  • 一行に収まらない条件は、複数行に折り返した一つの if にするのではなく、複数のガード節にします。
  • 呼び出しやテーブルコンストラクターが約 120 文字を超える場合は、引数またはフィールドごとに一行にします。それより短いものは一行のままにします。

変更前:

if type(data) ~= 'table' or type(data.slot) ~= 'number' or type(data.count) ~= 'number'
    or data.count < 1 then return false end
local player = GetPlayer(source)
if not player or not player.shop then return false end
local item = player.shop.items[data.slot]
if not item then return false end
if item.license and not HasLicense(player, item.license) then return false, { type = 'error', description = 'missing_license' } end

変更後:

if type(data) ~= 'table' then return false end

if type(data.slot) ~= 'number' or type(data.count) ~= 'number' or data.count < 1 then
    return false
end

local player = GetPlayer(source)

if not player or not player.shop then return false end

local item = player.shop.items[data.slot]

if not item then return false end

if item.license and not HasLicense(player, item.license) then
    return false, { type = 'error', description = 'missing_license' }
end

削除しないでください

クライアントから何らかのデータを受け取るサーバーコードは、信頼できる経路ではありません。次のすべてのチェックを維持してください。

  • サーバー側のネットイベントハンドラー(RegisterNetEvent、ネットイベントに対するAddEventHandler)およびサーバー側のlib.callback.registerコールバックの引数。
  • sourceから導出される検索結果:プレイヤーが存在するか、アイテムを所有しているか、対象の近くにいるか、ジョブまたはグループを持っているか。
  • レート制限、距離チェック、権限チェック(IsPlayerAceAllowed、フレームワークのジョブまたはグループのチェック)。

一般的なクリーンアップでは、これらが防御上の不要な記述に見えることがありますが、エクスプロイトを防いでいるのはまさにこれらのチェックです。本当に冗長に見えるものがあっても削除せず、概要でその旨を記載してください。チェックを個別のガードに分けたり、独立した行に配置したりするのは問題ありません。すべてのチェックを維持してください。

また、データベースのデータ、NUIコールバック(RegisterNUICallback)に含まれるデータに対するチェックと、オプションのリソースに対するガード(GetResourceState(name) == 'started')も維持してください。

ガードレール

  • 明確なバグを修正する場合を除き、動作を変更しないでください。バグを修正した場合は、概要に記載してください。
  • 大規模な書き換えよりも、最小限で対象を絞った編集を優先してください。レイアウトは例外です。ブランチで追加された詰め込み行は、サンプルだけでなくすべて修正してください。変更していないコードの書式は変更しないでください。
  • 最終的な概要は簡潔にしてください(1~3文)。

コメント