mcpField
A
adversarial-elixir

adversarial-elixir

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

adversarial-elixir について

Elixir/OTP/Ecto/Phoenixの変更を敵対的にレビューし、コードを修正せず合否を判定するスキルです。証拠に基づくルールで、BEAMにそぐわないプログラミングモデルの持ち込みを検出します。

主な機能

  1. 01PASS、FAIL、N/Aの判定
  2. 02証拠に基づくルールでのレビュー
  3. 03アーキテクチャ、プロセス、データモデリングの確認
  4. 04制御フロー、反復、メタプログラミングの評価
  5. 05不合格ルールへの具体的な修正案

活用シーン

  1. 01マージ前のElixir変更のゲート
  2. 02エージェント作成コードの監査
  3. 03他言語から移植したコードのレビュー
  4. 04リファクタリングが慣用的かの検証

インストール

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

$npx skills add https://github.com/pproenca/dot-skills --skill adversarial-elixir

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

gotchas.md
metadata.json
assets/templates/
verdict.md
references/
_sections.md
arch-context-over-service-objects.md
arch-delete-repository-over-ecto.md
arch-drop-di-behaviour-single-impl.md
arch-functional-core-imperative-shell.md
flow-assertive-over-defensive.md
flow-no-exceptions-for-control.md
flow-normalize-at-boundary.md
iter-named-combinator-over-manual-loop.md
meta-functions-not-macro-dsl.md
meta-no-compile-time-coupling.md
meta-use-is-not-import.md
proc-consolidate-interface.md
proc-no-process-as-variable.md
proc-no-singleton-manager.md
proc-not-objects.md
reviewer-prompt.md
type-protocol-over-type-dispatch.md
type-split-god-struct.md
type-struct-over-bare-map.md
type-tagged-state-over-flags.md

詳細

Adversarial Elixir Gate

Elixir/OTP/Ecto/Phoenix のレビュ―ゲートです。合否を判定します。単一のブラインドレビュアーサブエージェントが、敵対的な立場でこのゲートのルールに照らして作業を判定し、すべてのルールが PASS または N/A の場合にのみ合格となります。このスキルは判定結果を出すものであり、作業を修正することはありません。

ルールが対象とするのは、BEAM に誤ったメンタルモデルを持ち込んだコードという、ひとつの失敗パターンです。OO/エンタープライズ的なレイヤリング、プロセスをオブジェクトとして扱うこと、貧血データ、防御的な制御フロー、ループの逐語的な移植、不要なメタプログラミングなどが該当します。ルールは公式の Elixir アンチパターンカタログに基づいており、それぞれに違反の証拠を示す段落が付いているため、レビュアーは成果物の証拠だけをもとに PASS/FAIL/N/A を判断できます。判断を伴うリファクタリングのガイダンスは、アドバイザリー用途の姉妹スキル staff-level-elixir にあります。

適用する場面

  • Elixir の差分、機能、PR をマージする前に、助言的なフィードバックではなく、客観的な PASS/FAIL 判定が必要なとき。
  • エージェント(Claude、Codex)がコードを作成し、OO の慣習を再現していないか独立したチェックが必要なとき。たとえば、Ecto をラップするリポジトリー、*Service/*Manager 階層、エンティティごとの GenServer、単一実装の DI ビヘイビア、if の代わりに使われる raise/rescue などです。
  • Java/Ruby/Python から移植したコード(または BEAM に不慣れな開発者が書いたコード)が、定着する前にパラダイムへの適合性を監査する必要があるとき。
  • リファクタリングで「イディオマティックにした」と主張しており、その主張を前提にせず検証したいとき。

Elixir 以外のコードベースには適用しないでください(レビュアープロンプトの前提条件により「GATE NOT APPLICABLE」で中止されます)。また、ユーザーが判定ではなく説明やリファクタリングを求めている場合も適用しないでください。それは staff-level-elixir の役割です。対象に Ecto がない場合、arch-delete-repository-over-ecto は N/A になります。対象に外部入力の経路がない場合、flow-normalize-at-boundary は N/A になります。プロジェクトの Elixir バージョンより新しい改善策は、利用可能な最も近い改善策に照らして判定されます。レビュアープロンプトにはバージョンゲートの表が含まれています。

レビュープロトコル

次の手順を正確に実行してください。このゲートの価値は、毎回同じ方法でレビューを行うことにあります。

  1. 対象を特定します。 レビュー対象(差分、ファイル一式、PR)を正確に特定し、参照先とパスを記録して、曖昧さのない固定された対象に対してレビューを実行できるようにします。Elixir のバージョンと主要な依存関係(mix.exs の elixir: 要件、Phoenix/Ecto の有無)を記録します。対象の説明にはリポジトリのルートを含めてください。arch-drop-di-behaviour-single-impl、type-protocol-over-type-dispatch、proc-consolidate-interface、meta-use-is-not-import では、実装モジュール、重複したディスパッチ箇所、コールバックの所有元、__using__ 本体を調べるため、差分の範囲を超えて検索する必要があります。
  2. ルールを読み込みます。 references/_sections.md と、references/ 内のすべてのルールファイル(すべての arch-*.md、proc-*.md、type-*.md、flow-*.md、iter-*.md、meta-*.md ファイル)を読みます。
  3. レビュアー用プロンプトを作成します。 ルール、対象、スタックに関する情報を references/reviewer-prompt.md に記入します。作成したプロンプトは完全に自己完結していなければなりません。レビュアーには会話履歴が表示されないため、プロンプト外のコンテキストを参照してはなりません。
  4. ブラインドレビュアーを 1 名起動します。 入力全体が作成したプロンプトのみで構成される Task サブエージェントを 1 つ起動します。会話のコンテキストや補足説明を添えてはなりません。
  5. フェイルクローズで判定します。 レビュアーの構造化された出力を判定結果とします。マージのステップはありません。すべてのルールが PASS または N/A の場合に限り、全体の判定を PASS とします。1 つでも FAIL があれば、ゲートは失敗です。平均を取ったり、重要度で重み付けしたり、ルールの適用を免除したりしてはなりません。「軽微な」FAIL も FAIL です。レビュアーが「GATE NOT APPLICABLE」(Elixir の対象ではない場合)を返したら、判定結果を出さずに停止し、その旨を報告します。
  6. 判定結果を出力します。 assets/templates/verdict.md に記入します。FAIL の場合は、レビュアーの「PASS に必要な修正」の提案を修正リストに集約し、それぞれに場所を付け、カテゴリの重要度順に並べます。最終結果が FAIL のルールはすべて修正リストに含め、記載どおりに適用できる具体的な変更を示してください。レビュアーの提案が違反を言い換えただけの場合は、出力前にルールの Correct 例をもとに修正内容を導き出します。

変更のない対象を再レビューした際に、同じルールの判定が変わる場合や、人が証拠を読んで判定結果を覆す場合は、そのルールに判定可能性のバグがあります。その場合は gotchas.md に記録してルールを明確化してください。ゲートの判定を覆してはなりません。

判定形式

レビュアーはルールごとに、PASS | FAIL | N/A、証拠(file:line または引用。PASS と FAIL の両方で必須)を返します。また、FAIL ごとに、適用すればルールが PASS になる修正(名前を付けた変更とその場所。違反の言い換えではないもの)を示します。最終レポートは assets/templates/verdict.md に従います。

ルールカテゴリ

#カテゴリプレフィックスこれでゲートする異質なモデル
1エンタープライズ的な儀式とレイヤー化arch-Ecto のラッパーとなるリポジトリ/DAO、エンティティごとの *Service/*Manager モジュール、実装が1つしかない DI ビヘイビア、エフェクトを伴うコールバック内で計算されるドメイン上の判断
2オブジェクトとしてのプロセスproc-DB の行を模倣するエンティティごとの GenServer、可変変数としての Agent、所有モジュールの外部に漏れ出すメッセージタプル、分割可能な状態に対するグローバルに名前付けされたシングルトンマネージャー
3貧血データモデリングtype-エンティティとして渡される固定形状の素のマップ、複数のブール値や文字列に依存する状態、モジュール間で重複する型タグによるディスパッチ、32フィールドのランタイム上限に達する構造体
4防御的な制御フローflow-予期される結果を分岐に変換する raise/rescue、必須の値を黙って無視する nil ガード、コア層で再チェックされる未加工の外部入力
5不要な命令型反復iter-名前を付けられる Enum のコンビネータを再実装する reduce/再帰 — FAIL とするには、置き換え先を正確に指定する必要があります
6不要なメタプログラミングと結合meta-単なるデータを表現するファーストパーティのマクロ DSL、インポートしか行わない __using__ 本文、コンパイル時に他のモジュールを呼び出すモジュール属性

注意点

レビュアーに割り当てる前に、gotchas.md を読んでください。スコープ上の注意事項(レビュアーが持ち込みがちなスタイル上の慣習、置き換え先の指定が必要な2つのルール、数値で定めた巨大構造体の境界線)があらかじめ記載されており、レビュアーがルールの範囲外を判断しないようにします。

関連スキル

  • staff-level-elixir — 助言を行う姉妹スキルです。新規開発で「どのツールを、どの慣習で使うか」という指針や、このゲートが意図的に対象外とする判断を扱います。コードの作成や修正にはこちらを使い、判定にはこのゲートを使います。
  • elixir-meta-programming — マクロ/DSLが本当に必要な場合に、正しく構築する方法を扱います(このゲートの meta- ルールを補完します)。
  • adversarial-swift / adversarial-rust / adversarial-zod / adversarial-ts-patterns / adversarial-tanstack — 他のスタック向けの姉妹ゲートです。同じプロトコルを使い、ルールは異なります。

参考ファイル

ファイル説明
references/reviewer-prompt.md各ブラインドレビュアー用の自己完結型プロンプトテンプレート
assets/templates/verdict.md判定レポートのテンプレート
references/_sections.mdカテゴリの定義と順序
metadata.jsonバージョンとソースの参照情報

コメント