What — なぜ書き方を縛るのか

• /goal はセッションに Stop フックを仕込むコマンド。 Claude が応答を終えるたびに「条件が満たされたか」を評価し、満たされるまで停止をブロックする
• 条件が機械的に判定できない文（激励・同意・「このまま進めて」）だと、フックは永久に「未充足」と判定し続ける。実測では全作業完了・ユーザーの終了承認後も解除されず、Claude が /goal clear を依頼するメッセージを繰り返す空転ループになった
• フックは条件文を毎回トランスクリプト全体と突き合わせて再評価するため、空転はトークンと時間も消費する

How — ルールとClaude側の振る舞い

• /goal の引数は「充足/未充足を機械的に判定できる条件」だけを書く
  • 良い例: tasklist.md の全タスクが [x] になり、go build ./... と go test ./... が全PASSした状態。PR作成とマージは含めない（別途指示する）
  • 悪い例: すばらしいです！なので、こちらはこのまま引き続き実行していってください！（判定不能→15回空転の実例）
• 継続の合図・激励は /goal ではなく通常メッセージで送る。それで十分 Claude は続行する
• 条件には「含めない範囲」（PR作成・マージなど承認が要る操作）も書くと、フックが承認待ちを「未完了」と誤判定しない

Claude側の振る舞い（CLAUDE.md には入れず、ここを正とする）：

• 同一の Stop フック条件で2回連続ブロックされ、かつ条件が判定不能（ユーザー入力でしか満たせない・文字列がもう出現しえない）と判断したら、作業を続けたり同じ完了報告を繰り返したりせず、即座に「この条件は判定できないので /goal clear してほしい」と1回だけ伝えて待つ
• ブロックのたびに微妙に違う「完了しました」メッセージを生成し直すのが空転の実体。気づいたら早期にユーザーへ返す

関連

• AIと働く
• 人もAIも「曖昧」でつまずく