reducing-entropy
コード全体のサイズを最小限に抑えることを目指し、ユーザーからの明確な指示があった場合にのみ実行され、削除を優先して最終的なコード量で成果を測る、手動操作に特化した整理整頓するSkill。
📜 元の英語説明(参考)
Manual-only skill for minimizing total codebase size. Only activate when explicitly requested by user. Measures success by final code amount, not effort. Bias toward deletion.
🇯🇵 日本人クリエイター向け解説
コード全体のサイズを最小限に抑えることを目指し、ユーザーからの明確な指示があった場合にのみ実行され、削除を優先して最終的なコード量で成果を測る、手動操作に特化した整理整頓するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o reducing-entropy.zip https://jpskill.com/download/20866.zip && unzip -o reducing-entropy.zip && rm reducing-entropy.zip$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/20866.zip -OutFile "$d\reducing-entropy.zip"; Expand-Archive "$d\reducing-entropy.zip" -DestinationPath $d -Force; ri "$d\reducing-entropy.zip"完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
reducing-entropy.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
reducing-entropyフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 6
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
[スキル名] reducing-entropy
エントロピーの削減
コードが増えれば、さらにコードが増えます。エントロピーは蓄積されます。このスキルは、可能な限り最小のコードベースを目指します。
核心的な問い: 「その後、コードベースはどのようになっているか？」
始める前に
references/から少なくとも1つのマインドセットを読み込む
- リファレンスディレクトリ内のファイルをリストアップします。
- フロントマターの説明を読んで、どれが当てはまるかを選択します。
- 少なくとも1つを読み込みます。
- 読み込んだものと、その核心的な原則を述べます。
これを実行するまで、先に進まないでください。
目標
目標は、最終的なコードベースの総コード量を減らすことです。今書くコード量を減らすことではありません。
- 200行を削除するために50行書く = 純粋な勝利
- 2つの関数を書くのを避けるために14の関数を維持する = 純粋な損失
- 「チャーンなし」は目標ではありません。コードを減らすことが目標です。
努力ではなく、最終状態を測定してください。
3つの質問
1. これを解決する最小のコードベースは何か？
「最小の変更」ではなく、「最小の結果」とは何か、です。
- これは14の関数ではなく、2つの関数にできるか？
- これは0の関数にできるか（機能を削除するか）？
- これを行う場合、何を削除できるか？
2. 提案された変更は、総コード量を減らす結果になるか？
変更前と変更後の行数を数えます。変更後 > 変更前の場合、却下します。
- 「より整理されている」がコードが増える = エントロピーが増える
- 「より柔軟」だがコードが増える = エントロピーが増える
- 「よりクリーンな分離」だがコードが増える = エントロピーが増える
3. 何を削除できるか？
すべての変更は削除の機会です。問いかけてください。
- これによって何が陳腐化するか？
- 置き換えようとしているもののためにのみ必要だったものは何か？
- 最大でどれだけ削除できるか？
危険信号
- 「既存のものを維持する」 - 現状維持バイアスです。問題は総コード量であり、チャーンではありません。
- 「これは柔軟性を追加する」 - 何のための柔軟性ですか？YAGNIです。
- 「関心の分離がより良い」 - ファイル/関数が増える = コードが増える。分離は無料ではありません。
- 「型安全性」 - 何行分の価値がありますか？時には、少ないコードでのランタイムチェックが勝つこともあります。
- 「理解しやすい」 - 14のものが2つのものより簡単ということはありません。
これが適用されない場合
- コードベースが、その機能に対してすでに最小限である場合
- 強い規約を持つフレームワークを使用している場合（それに逆らわないでください）
- 規制/コンプライアンス要件が特定の構造を義務付けている場合
参照マインドセット
哲学的な根拠については、references/を参照してください。
新しいマインドセットを追加するには、adding-reference-mindsets.mdを参照してください。
削除を優先してください。最終状態を測定してください。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Reducing Entropy
More code begets more code. Entropy accumulates. This skill biases toward the smallest possible codebase.
Core question: "What does the codebase look like after?"
Before You Begin
Load at least one mindset from references/
- List the files in the reference directory
- Read frontmatter descriptions to pick which applies
- Load at least one
- State which you loaded and its core principle
Do not proceed until you've done this.
The Goal
The goal is less total code in the final codebase - not less code to write right now.
- Writing 50 lines that delete 200 lines = net win
- Keeping 14 functions to avoid writing 2 = net loss
- "No churn" is not a goal. Less code is the goal.
Measure the end state, not the effort.
Three Questions
1. What's the smallest codebase that solves this?
Not "what's the smallest change" - what's the smallest result.
- Could this be 2 functions instead of 14?
- Could this be 0 functions (delete the feature)?
- What would we delete if we did this?
2. Does the proposed change result in less total code?
Count lines before and after. If after > before, reject it.
- "Better organized" but more code = more entropy
- "More flexible" but more code = more entropy
- "Cleaner separation" but more code = more entropy
3. What can we delete?
Every change is an opportunity to delete. Ask:
- What does this make obsolete?
- What was only needed because of what we're replacing?
- What's the maximum we could remove?
Red Flags
- "Keep what exists" - Status quo bias. The question is total code, not churn.
- "This adds flexibility" - Flexibility for what? YAGNI.
- "Better separation of concerns" - More files/functions = more code. Separation isn't free.
- "Type safety" - Worth how many lines? Sometimes runtime checks in less code wins.
- "Easier to understand" - 14 things are not easier than 2 things.
When This Doesn't Apply
- The codebase is already minimal for what it does
- You're in a framework with strong conventions (don't fight it)
- Regulatory/compliance requirements mandate certain structures
Reference Mindsets
See references/ for philosophical grounding.
To add new mindsets, see adding-reference-mindsets.md.
Bias toward deletion. Measure the end state.
同梱ファイル
※ ZIPに含まれるファイル一覧。`SKILL.md` 本体に加え、参考資料・サンプル・スクリプトが入っている場合があります。
- 📄 SKILL.md (2,557 bytes)
- 📎 README.md (4,692 bytes)
- 📎 references/data-over-abstractions.md (1,894 bytes)
- 📎 references/design-is-taking-apart.md (2,265 bytes)
- 📎 references/expensive-to-add-later.md (2,497 bytes)
- 📎 references/simplicity-vs-easy.md (1,707 bytes)