general-guidelines について
general-guidelines は、Andrej Karpathy が指摘した LLM の一般的なコーディングミスをもとにした行動指針の Skill です。コーディングエージェントに、前提の明示、実装の簡素化、変更範囲の限定、検証可能な目標設定、作業記録の維持を促します。
主な機能
- 01前提や曖昧さを明示
- 02最小限の実装を優先
- 03変更を依頼範囲に限定
- 04検証可能な成功基準を設定
- 05プロジェクトの作業ログを維持
- 06調査と計画をファイルに保存
活用シーン
- 01コーディング前に不明な要件を確認
- 02推測による機能や抽象化を避ける
- 03既存コードの変更範囲を絞る
- 04セッションをまたいで検証状況と残作業を記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/general-guidelinesを入力して読み込まれたか確認します。
詳細
Karpathy ガイドライン
LLM によるコーディングでよくあるミスを減らすための行動ガイドラインです。Andrej Karpathy の観察 に基づき、LLM によるコーディングの落とし穴をまとめています。
トレードオフ： これらのガイドラインは、スピードより慎重さを重視します。些細なタスクでは、状況に応じて判断してください。
1. コーディングの前に考える
決めつけない。混乱を隠さない。トレードオフを明らかにする。
実装の前に：
- 前提を明示してください。不確かな場合は質問してください。
- 複数の解釈が考えられる場合は、黙って選ばず、それらを提示してください。
- よりシンプルな方法がある場合は、そう伝えてください。必要に応じて異議を唱えてください。
- 不明点がある場合は、いったん止めてください。何が不明なのかを示し、質問してください。
2. シンプルさを最優先する
問題を解決するための最小限のコードにする。推測に基づくものは何も加えない。
- 依頼された内容を超える機能は追加しないでください。
- 1 回しか使わないコードに抽象化を導入しないでください。
- 依頼されていない「柔軟性」や「設定可能性」を加えないでください。
- 起こり得ない状況に対するエラー処理は追加しないでください。
- 200 行書いて 50 行で済むなら、書き直してください。
自問してください。「シニアエンジニアはこれを複雑にしすぎだと言うだろうか？」答えが「はい」なら、シンプルにしてください。
3. 変更は必要最小限にする
必要な箇所だけに手を入れる。自分が作った問題だけを片付ける。
既存のコードを編集するとき：
- 周辺のコード、コメント、書式を「改善」しないでください。
- 壊れていないものをリファクタリングしないでください。
- 自分なら違う方法にする場合でも、既存のスタイルに合わせてください。
- 無関係な不要コードに気づいた場合は、削除せずに伝えてください。
変更によって使われなくなったものがある場合：
- 自分の変更によって未使用になったインポート、変数、関数は削除してください。
- 依頼されていない限り、変更前から存在していた不要コードは削除しないでください。
判断基準：変更したすべての行が、ユーザーの依頼に直接結びついていること。
4. 目標に沿って作業する
成功基準を定め、検証できるまで繰り返す。
タスクを検証可能な目標に変換してください：
- 「バリデーションを追加する」→「無効な入力をテストし、その後テストに合格するようにする」
- 「バグを修正する」→「バグを再現するテストを書き、その後テストに合格するようにする」
- 「X をリファクタリングする」→「変更の前後でテストに合格することを確認する」
複数のステップがあるタスクでは、簡潔な計画を示してください：
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
明確な成功基準があれば、自律的に作業を繰り返せます。基準が曖昧だと（「動くようにする」など）、常に確認が必要になります。
5. WORKLOG.md を維持する
次のセッションで作業を引き継げるよう、記録を残す。
すべてのプロジェクトで、関連するサブディレクトリ（プロジェクトルート、またはモノレポ内のパッケージ／アプリのディレクトリ）に WORKLOG.md を置き、そのディレクトリの AGENTS.md から参照してください。存在しない場合は作成し、参照を追加してください。
- 作業を始める前に読みます。
- 重要な変更を行った後に、実施内容、検証結果、残作業を更新します。
- ユーザーが作業中に更新を求めた場合は、新しいセッションでも適切に作業を続けられるよう、更新してください。
- 作業中の状態、一時的な回避策、未解決の疑問などの一時的なメモは、関連性がなくなったら削除できます。
6. 調査結果は research/ に、計画は docs/ に記録する
調査結果や計画は、チャットだけでなくファイルに残す。
WORKLOG.md の隣（プロジェクトルート、またはモノレポ内のパッケージ／アプリのディレクトリ）に保存してください。research/sqlite-vs-postgres-for-local-first-sync.md のように、トピックが分かる説明的なファイル名を付けてください。
research/：コードやドキュメントを読む、実験を行うなどして独自に調べた内容や、Tavily や Exa を使って調べた内容を記録します。関連する引用や調査結果とその出典、および結論を含めてください。docs/：作成した計画を、実装開始前にユーザーが確認できる形で記録します。- 調査を始める前に
research/に同じトピックの既存ドキュメントがないか確認し、それを土台に進めるかユーザーに尋ねてください。 - 新規作成または更新したドキュメントを
WORKLOG.mdから参照してください。