「claude-code」タグのついた28記事

Claude Code のハーネスを構成する CLAUDE.md・rules・skills・agents・hooks・MCP・memory が、どこに置かれ、いつ働くかを一覧で押さえます。

AI エージェントの信頼性は、モデル本体ではなくその周りを固める「ハーネス」の設計品質で決まる、という中核の考え方を解説します。

LLM・Claude Code・RAG・AI エージェント開発に関するノートをまとめるドメイン。Claude Code ハーネスエンジニアリング入門ガイドを公開中。

autodev-smoke の anagram-check task を例に、autodev フロー (⓪'-⑤) の各 phase で何が起きるかを spec / plan / story / done / review の実物引用付きで walkthrough します。

Claude Code の skill・rule・memory・hooks・MCP がどう連携して動くかを、デバッグコマンド /debug の実行フローを 1 本追いながら学ぶガイド。ハーネスエンジニアリングのワークフローを実例ベースで理解します。

rules・skills・agents・hooks・output-contracts・knowledge の各 facet ファイルの責務と境界を、実コード引用付きで辞書的に並べる詳解章です。

nrslib/takt 由来の Faceted Prompting (5 関心分離) と orchestrator (takt 思想採用) を核に、数十ファイル規模で運用している Claude Code ハーネスを章別に解説する連載のトップページです。

プロンプトを Persona / Policy / Instruction / Knowledge / Output Contract の 5 関心に分離する Faceted Prompting の整理軸を、各 facet の責務と振り分けルートと併せて解説します。

規範を「文章で誘導する Guide」と「機械で取りこぼしを捕まえる Sensor」のペアで守る。十字分類の最も鮮明な例を、要件詰問スキル /grill-me を題材に見ます。

ハーネスの構成要素を「行動前/行動後」×「決定的/推論的」の 2 軸で分類し、なぜ片方だけでは不十分なのかを実例で示します。

hooks は settings.json でイベントに紐づけて登録するスクリプト。この環境で使う 8 イベントと、exit 2 による自己修正フィードバックの仕組みを整理します。

MCP は「スキーマの読み込み」と「サーバーの接続」の 2 段で制御される。ToolSearch による deferred tool の読み込みと、用途テーブルに基づく自律ロードを整理します。

セッションは終わると忘れる。learnings・プロジェクト memory・handoff の 3 層で、何をどこに、どの粒度で残すかを整理します。

一度踏んだ落とし穴を二度踏まないために、学びを rules / hook / fitness function へ昇格させる Ratchet の流れを /debug の再発防止判断から見ます。

rules は常時ロードと path-scoped の 2 種類。frontmatter の paths（glob）で「対象ファイルを開いたときだけ読み込む」仕組みを掘り下げます。

/debug の最初の一手は MCP の読み込み。なぜ MCP は最初から使えず ToolSearch で都度ロードするのか、なぜ sequential-thinking が強制なのかを解説します。

実装する人と評価する人を分ける Generator-Evaluator 分離と、複数の subagent を並列で走らせる multi-perspective-review を、/review への寄り道で見ます。

AI Agent Orchestration Framework である nrslib/takt の思想 (Faceted Prompting / Output Contracts / Worktree Isolation / 8 design principles) を、CLI を使わず Claude Code の skills + agents + handoff dir で独自移植した経緯と対応関係を解説します。

ハーネス再構築後の ~/.claude/ ディレクトリ構成と、criticality 3 段で配信方式を分ける合成規約を実例付きで解説します。

再構築前の Claude Code ハーネスで観測した 4 つの症状と、ゼロ再構築という判断に至った経緯を、設計判断 4 つと併せて整理します。

/debug 1 本の流れで追ってきたハーネスの全体像を振り返り、自分のハーネスを小さく始めて育てるための第一歩を示します。

本連載の 3 段要約 / 4 Quality metrics の現状 / これからの道筋を整理する最終章です。

/debug が答えを返す瞬間、Stop イベントで 7 つの hook が並列に走る。即ブロックする Sensor と、まず観測だけする log-only Sensor の違いを解説します。

ハーネス再肥大化を構造的に防ぐ 5 つの規律 (usage-driven 追加 / サイズ上限 / 1 ファイル 1 関心 / 逆 ratchet / hooks は実証後) と、反転承認による削除 default 化を実例付きで解説します。

bootstrap 後に表面化した silent drop / 二重 worktree / 文言ズレ等の実例を、問題発見 → 分析 → 修正 → 検証の 4 段で walkthrough する実例章です。

Investigate→Fix→Verify を最大 3 回反復し、テスト出力という証跡で「直った」を裏づける。ハーネスの中核「成功を主張せず証拠を示す」原則を /debug で体感します。

バグ報告の一言が UserPromptSubmit hook を通り、/debug skill を起動して SKILL.md が作業手順になるまでの最初の数百ミリ秒を追います。

ファイルを読むと path-scoped rule が自動ロードされ、書き換える瞬間には PreToolUse / PostToolUse hook が割り込む。「楽な修正」を構造的に塞ぐ仕掛けを見ます。