mcpField
A
anti-slop

anti-slop

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

anti-slop について

文章、コード、デザインに見られる汎用的なAI生成パターンを検出して整理するスキルです。文章向けの検出・修正スクリプトと、コードやビジュアルを手作業で確認する指針を備え、文脈に応じたレビューを重視します。

主な機能

  1. 01文章のスロップを採点してパターンを報告
  2. 02よくある文章表現を自動修正
  3. 03コードのアンチパターンに関する指針
  4. 04汎用的なデザインパターンに関する指針
  5. 05文脈に応じた手動レビュー

活用シーン

  1. 01納品前にAI生成文章を確認
  2. 02既存テキストの定型表現を整理
  3. 03コードの汎用的な命名やコメントを点検
  4. 04テンプレート的なレイアウトやビジュアルを監査

インストール

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

$npx skills add https://github.com/rand/cc-polymath --skill anti-slop

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

同梱ファイル

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

CLAUDE_MD_UPDATES.md
README.md
references/
code-patterns.md
design-patterns.md
text-patterns.md
scripts/
clean_slop.py
detect_slop.py

詳細

アンチスロップスキル

自然言語、コード、デザインに見られる、ありきたりな AI 生成パターン(「スロップ」)を検出し、取り除きます。

AI スロップとは?

AI スロップとは、品質の低い、ありきたりな AI 生成コンテンツを示す特徴的なパターンのことです。

  • テキスト:「掘り下げる」のような使い古されたフレーズ、過剰な流行語、メタコメント
  • コード:汎用的な変数名、明白なコメント、不要な抽象化
  • デザイン:型にはまったレイアウト、ありきたりなグラデーション、使い古されたビジュアルパターン

このスキルは、こうしたパターンを特定して取り除き、自然で質の高いコンテンツを作成するのに役立ちます。

このスキルを使う場面

以下の場合に、アンチスロップの手法を適用します。

  • 提出前に AI 生成コンテンツをレビューするとき
  • ありきたりなパターンを避けてオリジナルのコンテンツを作成したいとき
  • ありきたりに感じられる既存のコンテンツを整理するとき
  • プロジェクトの品質基準を定めるとき
  • ユーザーからスロップの検出や整理を明示的に依頼されたとき
  • コンテンツに、ありきたりな AI 生成の特徴が見られるとき

基本的なワークフロー

1. スロップを検出する

テキストファイルの場合:

python scripts/detect_slop.py <file> [--verbose]

次の項目を分析して提示します。

  • スロップスコア(0~100。数値が高いほど問題が深刻です)
  • 具体的なパターンの検出結果
  • 実行可能な改善案

手動で検出する場合: 該当するリファレンスファイルを読み、パターンの詳細を確認します。

  • references/text-patterns.md - 自然言語のスロップパターン
  • references/code-patterns.md - プログラミングのスロップパターン
  • references/design-patterns.md - ビジュアル/UX デザインのスロップパターン
2. スロップを取り除く

自動整理(テキストのみ):

# Preview changes
python scripts/clean_slop.py <file>

# Apply changes (creates backup)
python scripts/clean_slop.py <file> --save

# Aggressive mode (may slightly change meaning)
python scripts/clean_slop.py <file> --save --aggressive

手動で整理する場合: 検出されたパターンに応じて、リファレンスファイルに記載された手法を適用します。

テキストのスロップ検出と整理

優先度の高い対象

すぐに削除します。

  • 「掘り下げる」→ 削除するか「調べる」に置き換える
  • 「複雑さを乗り越える」→「対処する」に置き換えるか、削除する
  • 「今日のめまぐるしく変化する世界では」→ 削除する
  • 「それを心に留めておくことが重要です」→ 削除する
  • ドキュメント自体についてのメタコメント

冗長な表現を簡潔にします。

  • 「〜するために」→「〜する」
  • 「〜という事実により」→「〜なので」
  • 「〜する能力がある」→「〜できる」

流行語を置き換えます。

  • 「活用する」→「使う」
  • 「相乗効果のある」→「協力的な」
  • 「パラダイムシフト」→「大きな変化」
品質の原則

簡潔に伝える:

  • 前置きやメタコメントを省く
  • 要点から始める
  • 意味を加えない接続表現を削る

具体的に伝える:

  • ありきたりな語句を具体例に置き換える
  • 「項目」「もの」「データ」ではなく、具体的な対象を示す
  • 曖昧な動作語ではなく、正確な動詞を使う

自然に伝える:

  • 文の構造や長さに変化をつける
  • 主に能動態を使う
  • 企業的で無個性な文体ではなく、文脈に合った文体で書く

コードのスロップ検出と整理

優先度の高い対象

汎用的な変数名を変更します。

  • data → どのようなデータを表すのかが分かる名前にする
  • result → 結果の内容が分かる名前にする
  • temp → 一時的に保存するものが分かる名前にする
  • item → どの種類の項目なのかが分かる名前にする

明白なコメントを削除します。

# Bad
# Create a user
user = User()

# Better - let code speak
user = User()

過剰に設計されたコードを簡潔にします。

  • 不要な抽象化レイヤーを取り除く
  • 目的なく使われているデザインパターンを置き換える
  • 単純なタスクに対する複雑な実装を簡素化する

関数名を改善します。

  • handleData() → データに何をするのかを明確にする
  • processItems() → 具体的にどのような処理をするのかを明確にする
  • manageUsers() → どのような管理操作を行うのかを明確にする
品質の原則

巧妙さより分かりやすさを優先する:

  • 理解しやすいコードを書く
  • プロファイリングで必要性が確認された場合にのみ最適化する
  • 複雑な解決策より、単純な解決策を優先する

意味のある名前を付ける:

  • 変数名は内容を表すようにする
  • 関数名は動作と対象を表すようにする
  • クラス名は責務を表すようにする

適切にドキュメントを作成する:

  • 何をするかではなく、なぜそうするのかを記載する
  • 自明なコードには説明を付けない
  • 公開 API と複雑なロジックの説明に重点を置く

デザインのスロップ検出と整理

優先度の高い対象

ビジュアル面の粗雑さ:

  • 汎用的なグラデーション背景(紫/ピンク/シアン)
  • グラスモーフィズムやニューモーフィズムの過剰な使用
  • 意味なく浮遊する3D図形
  • すべての要素に同じデザイン手法を適用すること

レイアウト面の粗雑さ:

  • コンテンツのニーズを無視したテンプレート主導のレイアウト
  • コンテンツの種類にかかわらず、すべてをカードに収めること
  • 階層構造のない過剰な余白
  • すべての要素を中央揃えにすること

コピー面の粗雑さ:

  • 「ビジネスを後押しします」といった類の見出し
  • 文脈のない「今すぐ始める」のような汎用的なCTA
  • 流行語を多用した説明文
  • ストックフォトのような見た目
品質原則

コンテンツ優先のデザイン:

  • 実際のコンテンツのニーズに沿ってデザインします
  • 重要度に基づいて階層構造を作ります
  • テンプレートではなく、コンテンツにレイアウトを決めさせます

意図的な選択:

  • すべてのデザイン上の判断に、根拠を持たせます
  • 流行だからではなく、ユーザーの役に立つパターンを使います
  • 要素の重要度に応じて、視覚的な扱いを変えます

本物らしい語り口:

  • コピーにブランドの個性を反映させます
  • 汎用的なマーケティング表現は避けます
  • 提供価値を具体的に伝えます

参考ファイル

特定の領域に取り組む際は、次の包括的なガイドを参照してください。

  • text-patterns.md - 自然な文章を損なうパターンの完全な一覧、検出ルール、改善方法

  • code-patterns.md - 各言語におけるプログラミングのアンチパターンとリファクタリングのガイダンス

  • design-patterns.md - ビジュアルおよびUXデザインを損なうパターンと改善策

各参考資料には、以下が含まれます。

  • パターンの定義と例
  • 検出の手がかり(高/中の確信度)
  • パターンが許容される文脈
  • 具体的な改善方法

スクリプト

detect_slop.py

テキストファイルを分析し、AI による粗雑な文章のパターンを検出します。

使い方:

python scripts/detect_slop.py <file> [--verbose]

出力:

  • 全体的な粗雑さスコア(0〜100)
  • カテゴリ別の検出結果
  • 行番号と例
  • 具体的な改善案

スコア:

  • 0〜20:粗雑さが低い(自然な文章)
  • 20〜40:粗雑さが中程度(パターンがいくつか見られる)
  • 40〜60:粗雑さが高い(多くのパターンが見られる)
  • 60以上:粗雑さが非常に高い(汎用的な表現が多い)
clean_slop.py

テキストファイルから、よくある粗雑なパターンを自動的に取り除きます。

使い方:

# Preview changes
python scripts/clean_slop.py <file>

# Save changes (creates backup)
python scripts/clean_slop.py <file> --save

# Save to different file
python scripts/clean_slop.py <file> --output clean_file.txt

# Aggressive mode
python scripts/clean_slop.py <file> --save --aggressive

改善対象:

  • リスクの高い表現
  • 冗長な言い回し
  • メタ的な説明
  • 過剰な曖昧表現
  • 流行語
  • 不要な限定表現
  • 内容のない強調表現

安全性:

  • 上書き時は必ず .backup ファイルを作成します
  • プレビューモードでは、適用前に変更内容を表示します
  • 内容の意味を維持します(非積極的モード)

ベストプラクティス

修正より予防

コンテンツを作成するとき:

  1. 具体的な読者を想定して書きます
  2. 抽象的な説明より具体例を使います
  3. 前置きを省き、要点から始めます
  4. 印象ではなく、正確さを基準に言葉を選びます
  5. 完成と見なす前に見直します
文脈に応じた改善

すべてのパターンが常に粗雑とは限りません。

許容される文脈:

  • 学術的な文章では、より慎重な表現が必要な場合があります
  • 法的文書では、特定の言い回しが求められます
  • 内部向けドキュメントでは、簡略表現を使えます
  • 技術文書には、分野固有の慣習があります

必ず検討すること:

  • 読者は誰ですか?
  • 目的は何ですか?
  • このパターンには役割がありますか?
  • より良い代替表現はありますか?
段階的な改善
  1. 検出 - 検出スクリプトを実行するか、手動で確認します
  2. 分析 - どのパターンが実際に問題なのかを把握します
  3. 改善 - 安全な箇所に自動的な改善を適用します
  4. 確認 - 変更後も意味が保たれていることを手動で確認します
  5. 仕上げ - 残った問題を手作業で修正します
自動化より品質

スクリプトは判断の代わりではなく、補助ツールです。

  • 自動検出を使って、候補を見つけます
  • 明らかなパターンには自動改善を適用します
  • 意味が変わる可能性のある変更は、必ず手動で確認します
  • 文脈に応じて適切に判断します

統合パターン

コードレビュー
# Check files before committing
python scripts/detect_slop.py src/documentation.md --verbose

# Clean up automatically
python scripts/clean_slop.py src/documentation.md --save
コンテンツのパイプライン
  1. 初期コンテンツを作成します
  2. 粗雑さの検出を実行します
  3. 自動改善を適用します
  4. 手動で確認し、仕上げます
  5. 最終的な品質チェックを行います
標準の適用

プロジェクト固有のしきい値を設定します。

  • 許容可能な最大スロップスコア:30
  • スコアが 20 を超える場合は手動レビューが必須
  • スコアが 50 を超える提出物は自動却下

制限事項

スクリプトが扱うのはテキストのみです:

  • コードのスロップ検出は手動で行います(code-patterns.md を使用してください)
  • デザインのスロップ検出は手動で行います(design-patterns.md を使用してください)

コンテキストへの依存:

  • スクリプトはすべてのコンテキストを理解できるわけではありません
  • 特定の分野では、一部の「スロップ」が適切な場合があります
  • 自動変更は必ず確認してください

言語の対応範囲:

  • 検出パターンは英語向けに最適化されています
  • コードパターンは一般的な言語(Python、JS、Java)を対象としています
  • デザインパターンはプラットフォームに依存しません

よくあるシナリオ

シナリオ 1:AI 生成コンテンツをレビューする
# User asks: "Can you review this article for AI slop?"
1. Read references/text-patterns.md for patterns to watch
2. Run: python scripts/detect_slop.py article.txt --verbose
3. Review findings and apply manual cleanup
4. Optionally run: python scripts/clean_slop.py article.txt --save
5. Do final manual review of cleaned content
シナリオ 2:コードベースを整理する
# User asks: "Help me clean up generic AI patterns in my code"
1. Read references/code-patterns.md
2. Review code files manually for patterns
3. Create list of generic names to rename
4. Refactor following principles in code-patterns.md
5. Remove obvious comments and over-abstractions
シナリオ 3:デザインレビュー
# User asks: "Does this design look too generic?"
1. Read references/design-patterns.md
2. Check against high-confidence slop indicators
3. Identify specific issues (gradients, layouts, copy)
4. Provide specific recommendations from design-patterns.md
5. Suggest concrete alternatives
シナリオ 4:品質基準を確立する
# User asks: "Help me create quality standards for our team"
1. Review all three reference files
2. Identify patterns most relevant to user's domain
3. Create project-specific guidelines
4. Set up detection scripts in development pipeline
5. Document acceptable exceptions

成功のためのヒント

テキストの整理:

  • まず検出を実行して、対象範囲を把握します
  • 重要なコンテンツには非積極的モードを使用します
  • 自動変更は必ず確認してください
  • まずリスクの高いパターンに取り組みます

コードの整理:

  • 汎用的な変数の名前変更から始めます
  • 次に、明らかに不要なコメントを削除します
  • 過剰に設計されたコードのリファクタリングは最後に行います
  • 重要な変更を行うたびにテストします

デザインの整理:

  • 視覚要素をパターンに照らして監査します
  • 美的な問題よりも構造上の問題を優先します
  • 変更がユーザーのニーズに応えることを確認します
  • ブランドの一貫性を保ちます

一般原則:

  • 品質 > 均一性
  • コンテキスト > ルール
  • 明瞭さ > 巧妙さ
  • 具体性 > 一般性

コメント