AGENTS.mdとCLAUDE.mdの違い:同じリポジトリでClaudeとCodexに別々のルールを読ませる方法
CLAUDE.mdとAGENTS.mdの役割の違いと、共通ルールを重複なく管理するためにshared/を活用した設計を説明します。
CLAUDE.mdとAGENTS.mdの役割の違いと、共通ルールを重複なく管理するためにshared/を活用した設計を説明します。
AIが書いた記事をAIがチェックする仕組みを導入した経験から、自動チェックで検出できることと、人が確認する必要があることを整理します。
AIに別の作業を依頼していたところ、ナビゲーションのレイアウトが変更されていた経験から、UIを保護するルールをCLAUDE.mdに追加した経緯と効果を説明します。
AIに別の修正を依頼している流れで、本番デプロイコマンドが実行された経緯と、その後に導入した承認制ルールの記録です。
設定ファイルの整合性を手動でチェックし続けることには限界があります。AIと一緒にバリデーションスクリプトを作った過程と、自動検出が有効だった理由を整理します。
AIは会話をまたいで記憶を持たないため、修正済みの問題が繰り返されます。その対処として作成した「lessons.md」の設計と運用方法を説明します。
AIがプロジェクト開始時に最初に読む設定ファイル「CLAUDE.md」の書き方と、設定前後でAIの動作がどう変わるかを具体的に説明します。
AIに渡すルールファイルが増えてきたときの整理方法を説明します。rules・skills・workflowという3つの役割でファイルを分類したshared/ディレクトリの設計思想を紹介します。
AIに毎回同じ指示を繰り返すより、スキルファイルとして手順を定義しておく方が作業品質が安定します。このサイトで実際に作ったSKILL.mdの設計と、その効果を整理します。
AIへの実装依頼の前に仕様書を書くことで、意図と異なる実装や繰り返し修正が減ります。Spec Firstという考え方と、仕様書の書き方を説明します。
Vibe Codingでサイトを作った後、維持・運用のフェーズに入って初めて必要になったハーネス・テスト・バリデーションの実例を記録します。
AIに毎回同じ質問をしても答えが変わる、前回の作業を覚えていない——そうした課題への対処として「ハーネスエンジニアリング」という設計手法を整理します。
CLAUDE.mdやルールファイルを整備する時間は本当に必要なのか。ハーネス整備の前後で何が変わったかを、体験をもとに具体的に説明します。
設定ファイルとコードの実態が時間とともにずれていく「ドリフト」は、AIを使ったプロジェクトで発生しやすい問題です。その原因と防止策を整理します。
ファイルは存在しているのにリンクが壊れている、という状況がこのサイトで発生しました。内部リンクの検証をファイルパスではなく公開URLで行う必要があった理由を整理します。
AIは実在しないURLを参考文献として生成することがあります。このサイトで作ったURLチェックスクリプトの仕組みと、結果の分類方法を整理します。