まとめ — ハーネスを自分のものにする
/debug を 1 回実行する、たったそれだけの操作の裏で、skill・MCP・rule・hook・memory が順に発火し、1 つのワークフローを織りなしていました。最後に、ここまでの旅を振り返ります。
追ってきた流れ
各段で、Agent = Model + Harness の十字分類のどこかが働いていました。発話の誘導は Computational Guide、rule の自動ロードは Inferential Guide、.env ブロックや平文質問の検出は Computational な仕掛けです。そして /review の多視点は Inferential Sensor にあたります。
持ち帰ってほしい 3 つの芯
- Agent = Model + Harness：信頼性はモデルの賢さより、周りを固めるハーネスの設計で決まる
- Guide と Sensor のペア：文章で先回りして誘導し、すり抜けを機械で捕まえる。重要な規範ほど両構えにする
- Ratchet で育てる：一度の学びを rules / hook へ昇格させ、同じ失敗を繰り返さない状態に締めていく
自分のハーネスを小さく始める
最初から 34 個の rule や 17 個の hook を用意する必要はありません。むしろ逆で、1 つの失敗から 1 つのペアを作るのが現実的な始め方です。
- 直近で「また同じミスをした」と思った瞬間を 1 つ思い出す
- それを
rules/に 1 行の規範として書く（Inferential Guide） - 機械で検出できそうなら、
settings.jsonに hook を 1 つ足す（Computational Sensor） - 次に同じ失敗をしたら、Ratchet で規範を強める
この小さなループを回すうちに、ハーネスはあなたの作業の癖に合わせて育っていきます。settings.json の hook 設定は update-config のようなスキルでも調整できます。
ハーネスエンジニアリングという考え方そのものの概観は、ブログの ハーネスエンジニアリング入門 でも扱っています。このガイドが「1 コマンドの実装フロー」だったのに対し、ブログ側は「なぜこの設計に至るか」の視点を補ってくれます。
おわりに
冒頭の凡例を思い出してください。📦 のレールは誰の環境にもあります。🔧 の中身を、自分の失敗に合わせて 1 つずつ作っていくのがハーネスエンジニアリングです。
ハーネスは、賢いモデルを「信頼できる相棒」に変えるための車体です。そして車体は、一度組んで終わりではありません。走らせながら、一方向に回るラチェットのように少しずつ締め直していくものです。次に「また同じミスをした」と思ったら、それを rules に 1 行書きます。そこがあなたのハーネスの最初の一歩です。
要点は次のとおりです。
- 1 コマンドの裏で、skill → MCP → rule → hook → memory が連鎖して 1 つのワークフローになる
- 芯は「Agent = Model + Harness」「Guide+Sensor のペア」「Ratchet で育てる」の 3 つ
- 始め方は小さく：1 つの失敗から rule と hook のペアを 1 つ作り、Ratchet で育てる