home-karpathy-guidelines

name	home-karpathy-guidelines
description	LLM特有のコーディング失敗（黙って推測する・過剰実装・スコープ滑落・成功基準が曖昧）を抑えるための事前規律。曖昧/大きい/不確実なタスクを受けた直後に明示起動して、実装前に前提と検証可能ゴールを言語化する。
license	MIT

Andrej Karpathy の LLM コーディング観察に基づく 4 原則。主な追加価値は実装"前"のゲート（home-self-review / home-fix-review-comments は事後レビュー、本 skill はその前段）。

出典: https://x.com/karpathy/status/2015883857489522876 / 適応元: https://github.com/multica-ai/andrej-karpathy-skills

トレードオフ: 速度より慎重さに振っている。自明な変更（typo 修正、明白な one-liner）には適用しない。

いつ使うか

• 要件が曖昧（"X を直して" / "Y を改善して" など）
• 影響範囲が読みにくい変更（複数ファイル / 共通基盤 / 既存挙動への上書き）
• 結果や変更範囲を左右する前提を仮定したと気づいたとき
• 「とりあえず書いてみる」とコードを打ち始めそうになったとき

手順（コード生成前に実行）

1. Think Before Coding — 前提を surface する

• 結果を変える前提だけを 1〜3 個 示す。リポジトリやツールで確認できる事実は先に調べる
• 複数解釈のうち、実装や成果物が変わるものだけを提示する
• 情報が十分なら、妥当な解釈を明示して進む。既に決まった事実を再検討しない
• ユーザーだけが答えられる入力、実質的なスコープ変更、破壊的な操作でのみ止まる
• より簡素な方法で要求を満たせるなら、選択肢を網羅せず推奨案として示す

2. Goal-Driven Execution — 検証可能ゴールに変換

曖昧タスクを次のいずれかの形に書き換えてから着手:

入力	検証可能ゴール
"バグを直して"	再現するテストを書く → 通す
"バリデーション追加"	不正入力のテストを書く → 通す
"リファクタ"	変更前後でテスト green を確認
"機能追加"