CLAUDE.md を最初から書き込むのをやめた話と、そのためのスキル
Hiroba による自動要約
Claude Code での開発時、事前に詳細な CLAUDE.md を書いても実際の運用に合わないため、実装後に観察された誤りから段階的にルール化する運用に切り替えた。この実践的な進め方を自動化する dev-docs-scaffold スキルの設計と使い方を解説。
読んで良かったら、シェアしてみてください。
同じタグの記事が他に 3818 件あります。
関連する記事
同じタグの記事
Claude Code の Plugin Marketplace 入門 ― スキル配布の仕組み・できること
ZennClaude Code で作成した Skill をチーム全体に効率的に配布する仕組みが Plugin Marketplace。GitHub リポジトリに marketplace.json を置くだけで自前マーケットプレイスを構築でき、メンバーは settings.json で必要な Plugin のみを選択インストール可能。Skill・Plugin・Marketplace の3層構造と、チーム運用時の重複排除・粒度整理が重要。
Claude のサービスラインナップを整理する — Chat / Code / Cowork の役割と機能差
QiitaAnthropic は Claude Chat / Code / Cowork など複数のサービスを提供しているが、本来は統一されたエンジン (Agent SDK) の上に異なる「性格」を持つインターフェースとして構築されている。各サービスの実際の機能差は曖昧で、簡単なタスクは3つのどれでも対応できるが、スコープ（Chat はファイル非参照、Code はリポジトリ全体、Cowork は外部サービス連携）と成果物の性質に違いがある。Skills / Projects / Memory / MCP などの補助機能も、実際には無理に学ぶ必要はなく、同じ指示の繰り返しが生じた場合に活用する程度で良い。
自作の AI チェックツールに、自分自身を審査させたら穴が見つかった話
Zenn複数の AI エージェント運用で見つかった「根拠のない主張」の 2 つの壊れ方——抽象と具体の極端さ、外部検証なしの自己完結——を「Gate 1」「Gate 2」の 2 つのチェック問い として Claude Code Skill に落とし込んだ著者が、公開直後にそのツール自体に Gate 2 を向けたところ、新規性主張が外部照合を経ていないことが判明。既存ツール (grounding-inspector など) との比較を経て、README を正直に書き直し、個人開発規模での自己参照的な設計思想の有効性を記録した。
Claude Code の共有コンテキストをチーム単位で集約する Cockpit
Zenn株式会社 estie のエンジニアが、Claude Code で使用する共有コンテキストと Skill をチーム単位で一元管理する「Cockpit」リポジトリの設計・運用方針を紹介。system-map.yaml を中心に、プロダクト・リポジトリ・ドメイン知識を体系化し、40 以上のリポジトリ管理コストを削減、ビジネスサイドからの質問をエンジニアに集中させず Claude に直接質問できる仕組みを実現した。