どんなSkillか
リポジトリを取得して中身を確認したところ、核となるのはCLAUDE.mdまたはSKILL.md（skills/karpathy-guidelines/SKILL.md）に書かれた4つの振る舞いルールでした。「Think Before Coding（コーディング前に仮定を明示する）」「Simplicity First（要求された分だけ実装する）」「Surgical Changes（依頼に直接関係する行だけ変更する）」「Goal-Driven Execution（検証可能な成功基準を定義する）」の4つです。README上の由来説明によると、Karpathy氏は「モデルは仮定を誤って解釈したまま確認せずに突き進み、無駄に複雑なコードを書きたがる」という趣旨の観察をXで発信しており、それをChang氏がClaude Codeの振る舞い指示として定型化したものだとされています。
外部への通信や認証情報へのアクセスを行うコードは含まれておらず、Claude Codeが読み込む指示文（プレーンテキスト）だけで完結する構成であることをコードレベルで確認しました。この性質上、通常のSkill検証で行うような危険動作の切り分けは不要と判断し、実際に動かして効果を確認する検証に進みました。
実際に使ってみた
ガイドラインの効果を確かめるため、意図的に曖昧な依頼を1つ用意しました。
設定ファイル(dict)を読み込んで、
ユーザーの年齢が18歳以上かどうか判定する関数を書いて年齢キーの有無、値の型（文字列か数値か）、欠損時の扱いは何も指定していません。この依頼を、ガイドラインなしの通常運転と、ガイドライン適用の2パターンで実装し、結果を比較しました。
ガイドラインなしで実装すると、型変換用のヘルパー関数、カスタム例外、結果を格納するdataclass、ログ出力、strictモードの切り替えオプションまで自発的に追加し、96行のコードになりました。指定していない仕様（文字列の年齢を数値に変換する、負の年齢を弾く等）を先回りしてカバーしようとした結果です。
同じ依頼にガイドラインを適用すると、まず「config["age"]は整数として渡される前提とする」「欠損時は未成年扱いとする」という仮定をコメントで明示したうえで、要求どおり判定だけを行う関数を実装しました。return config.get("age", 0) >= 18の1行が本体で、コメントを含めても26行です。どちらも{"age": 20}→True、{"age": 17}→False、{}→Falseという同じ入出力で正しく動作することを実行して確認しました。
良かった点
- 同じ依頼・同じ検証者という条件をそろえた比較で、コード量が96行から26行へと約7割減るという具体的な差が出ました。曖昧な要求に対して先回りで機能を積み増す傾向を、ルール1つで大きく抑えられることが確認できました。
- 「仮定を明示する」というルールにより、欠損時の扱いのような未確定事項がコメントとして本文中に残ります。後から読む人が暗黙の判断を追いやすくなる副次効果がありました。
- 外部通信や実行環境への副作用が一切ないプレーンテキストのSkillなので、導入・撤去のコストが低く、試しに使ってみる際のハードルが低い点も実利です。
思ったようにならなかった点
- README自身が「速度より安全側に倒すトレードオフがある」と明記しているとおり、些細な作業でも一度仮定を書き出すひと手間が入るため、明らかに自明な依頼にまで機械的に適用すると冗長に感じる場面がありました。
- 4つのルールは振る舞いの方向性を示すだけで、個別のプロジェクト規約（本サイトでいえば/writing-normsのような文体規範）とは役割が異なります。導入すればコーディング規約が要らなくなる、というものではありません。
向いている使い方
今回の検証から、要件が曖昧になりがちな依頼を大量にこなす現場（プロトタイピング、社内ツールの小改修依頼など）で、実装が肥大化しやすい傾向を抑える用途に向いていると感じます。逆に、要件が最初から厳密に決まっているタスクでは、仮定を明示する手順自体が形骸化しやすく、効果を実感しにくいかもしれません。CLAUDE.mdへの追記だけで導入でき、プラグイン形式（/plugin marketplace add forrestchang/andrej-karpathy-skills）でも配布されているため、まずは小さいプロジェクトで試してから常用するかを判断するのが良さそうです。
検証環境: Claude Code。検証日2026-08-05