conductor の会話を工程の切れ目で切ることを hook で強制する

[takemi-ohama]

親: #827

何をするか

conductor の会話を、工程の切れ目で切ることを強制する。 references/context-window.md は「1 工程あたり 10 万、遅くとも 20 万で切る」と定めているが、実際には守られていない。規定を書くだけでは足りないので、仕組みで切らせる。

例: carmo-system-console の会話 622d229f は、委譲せずに 1 つの会話で工程を進め、最大文脈が 583,675 トークンになった。fix の工程は平均 52 万トークンの文脈の中で動いていた。そこまでに読んだ設計や実装の内容を、呼び出しのたびに読み直している。

なぜ

#827 の実測:

• 2026-09-20 以降では、conductor の最大文脈が会話 7 件中 4 件で 20 万を超え、最大は 68 万だった
• ai-plugins の 30 日間では、45 件中 37 件が 20 万を、20 件が 50 万を超えていた。平均文脈は 41 万だった
• 工程の開始ごとに切っていたと仮定すると、conductor の再読込量は 58% 減る（30 日間では 62%）

方針（案）

• 工程の Skill を起動するとき（PreToolUse:Skill）に、会話の記録から現在の文脈量を読む。20 万を超えていたら、hook が「次の工程は新しい会話で /ndf:<工程> #<issue> から始める」と指示する。文脈量の読み方は skill-stats --agents と同じにする
• development-workflow は、工程を 1 つ終えるたびに引き継ぎの 1 行（次に打つコマンド）を出して止まる
• 切る位置は context-window.md の 4 つの切れ目を初期値にする

受け入れ条件

• 文脈が上限を超えた状態で工程 Skill を起動すると、hook が新しい会話へ移るよう案内する（テストがある）
• 工程の終わりで出す引き継ぎの 1 行だけで、新しい会話から工程を再開できる（課題・PR・控えから状態を戻せる）
• context-window.md の「前提: 実測ではない」を、development-workflow: トークン消費の実測と削減（supervisor をスクリプトで駆動し、判断は最小構成の claude -p に任せる） #827 の実測値に書き換えている
• development-workflow: トークン消費の実測と削減（supervisor をスクリプトで駆動し、判断は最小構成の claude -p に任せる） #827 の計測スクリプトで、変更後の版を同じ条件で回すと、conductor の最大文脈と再読込量が下がっている（数値を本 issue に残す）

注意

• 切るたびに固定費（約 4 万）を書き直す費用がかかる
• 引き継ぎの材料が会話の外に残っていないと、判断の質が落ちる

実機の確認（AC20、2026-09-23、Claude Code 2.1.280）

手順: 実装の途中（実装をコミットし、Pull Request を出す前）で、作業ツリーから新しい会話を claude -p "/ndf:development-workflow #829 #830 …" で始めた。工程 Skill を起動せず外部へ書かないよう添え、context-window.md の「新しい会話で戻す」の手順 1〜4 だけを実行させた。

結果: 新しい会話は次を戻した。

• モード standard、作業ツリー .worktrees/feature/issue-829-830-token-waits、計画ファイル issues/issue-829-830-implementation-plan.md（課題の本文の ## 進行 から）
• 設計 Pull Request 設計: 待つ間の問い合わせを hook で止め、conductor の会話を工程の切れ目で切る（#829 #830） #843（MERGED。ブランチ名 design/issue-829-830-token-waits で引いた）と、実装の Pull Request がまだ無いこと
• 次の工程として構造改善（cross-refactoring）を挙げ、その前に Pull Request を出す必要があると指摘した

見つかった不備を直した: 手順 2 の stage-check.sh の場所がプラグインの scripts/ と読めたため、development-workflow の scripts/ にあると書き直した。stage-check.sh report は新しい会話からは「進行の記録がありません」を返し、本文の記録で代わりに戻した。

残り: 配布前の版で確かめたため、起動した Skill は配布済みの版（10.16.0）で、手順は作業ツリーの文書を読ませた。配布後の版での確認は release-verification で行う。

進行

モード: standard / 作業ツリー: .worktrees/feature/issue-829-830-token-waits / 計画: issues/issue-829-830-implementation-plan.md

• 要求と受け入れ条件 — 2026-09-23 00:14
• 作業場所の用意 — 2026-09-23 00:14
• 設計 — 2026-09-23 00:18
• 素材の収集と出典の確定
• ドキュメント再構成 — 2026-09-23 00:23
• ドキュメントレビュー — 2026-09-23 00:24
• 計画 — 2026-09-23 01:59
• 実装 — 2026-09-23 02:01
• 構造改善 — 2026-09-23 02:12 / 打ち切り（利用者の指示・現状固定テスト10件のみ・構造改善0件・cross-refactoring: 変更範囲が狭くても 1 項目ごとに --baseline-test の全体テストを回し、1 項目あたりの待ちが全体テストの時間になる #880）
• 実装レビュー — 2026-09-23 03:56
• 完了判定 — 2026-09-23 04:34
• Pull Request — 2026-09-23 04:37
• 確定仕様化 — 2026-09-23 04:39
• 後片付け — 2026-09-23 01:58
• 配布 — 2026-09-23 04:51
• 体裁レビュー
• リリース後テスト — 2026-09-23 05:24
• 振り返り

[takemi-ohama]

構造改善の工程を利用者の指示で打ち切った（2026-09-23 03:50 UTC ごろ）。PR #844 に残したのは現状固定テスト 10 件（9f12b341〜15385c27）だけで、構造改善の項目は 0 件。1 項目ごとに全体テスト（約 8 分）を回す進め方のため、90 分で構造改善の提案に入れなかった。この件は #880 で扱う。記録: #844 (comment) 。次は実装レビューへ進む。

[takemi-ohama]

ndf v10.17.0 を本番へ配布した（#886 → #887、タグ ndf--v10.17.0、2026-09-23T05:24Z）。リリース後テストの記録: #886 (comment)

AC20 は合格。 利用者の環境を正式版チャネルから 10.17.0 へ更新し、claude -p "/ndf:development-workflow #830 …"（読むだけと添えた）で新しい会話を始めた。読んだ手順は ~/.claude/plugins/cache/ai-plugins/ndf/10.17.0/skills/development-workflow/references/context-window.md。モード standard・作業ツリー（後片付け済みでディスクに無いことも指摘）・計画ファイル・PR #843 / #844（MERGED）・次の工程「振り返り」を戻した（exit=0、session 30c0a964-74f9-4b5e-ab4b-4f4a16edb243）。

AC26 は測定待ち（保留）。

• いつ: 10.17.0 を入れた後に development-workflow を発動した conductor の会話が 7 件以上たまった時点。遅くともマイルストーン 26 の振り返りの前
• 何を: development-workflow: トークン消費の実測と削減（supervisor をスクリプトで駆動し、判断は最小構成の claude -p に任せる） #827 の「再現の手順」の measure.py / report.py / extra.py。python3 measure.py 2026-09-24 > raw.json
• 比べる値: conductor の最大文脈（変更前 683k）と再読込量（切った場合の見込み 58% 減）

この課題は AC26 を測るまで開けておく。