org-retro: 委譲プロセスの振り返り

ワーカーへの委譲が完了した後、委譲プロセス自体を振り返り改善する。 加えて、完了タスクの作業パターンがwork-skillとして再利用可能か判断する。

注意: 実作業の技術的な知見（はまりポイント、API の癖等）はワーカーが CLAUDE.md の指示に従い 自動的に knowledge/raw/ に記録する。ここでは扱わない。

輸送層（transport）両系 — 既定 broker / opt-in renga: 本ファイル（および各スキル）の peer message・pane 操作は mcp__org-broker__* で書いてあり、ORG_TRANSPORT 無設定＝既定 broker ではそのまま従えばよい。ORG_TRANSPORT=renga（opt-in、切戻し可）では MCP サーバー名が renga-peers になり、完全修飾名が mcp__org-broker__* → mcp__renga-peers__* に機械置換される（引数形・セマンティクスは同一なので操作の論理は変わらない）。輸送依存で手順が変わる差は次の 3 点:

• 受信モデル（既定 = push 一次 = claude/channel / pull フォールバック）: 既定 broker は push 一次に設計されている（runtime push-first 0.1.24+、設計 SoT は transport-lab docs/design/broker-native-roles.md §9）: 各ペイン同居の channel sidecar（server:org-broker-channel）が broker キューを ~1 秒間隔で claim→push し、notifications/claude/channel で本文を idle セッションへ注入する（「受けたら即応答」契機が生まれる）。ワーカー ack（to_id="worker-{task_id}"）・retro gate ack（to_id="dispatcher"）・ディスパッチャー handover 経路の send_message / check_messages / send_keys / inspect_pane は同じツール名（mcp__org-broker__*）で動く。pull はフォールバック層: sidecar 不在 / unhealthy（heartbeat timeout で delivery_mode=PULL）/ channel 非対応ペイン（codex pull-peer）/ claude.ai login 不在時は、各役割が自身の cadence で能動的に check_messages する（役割別 cadence: worker=ターン境界 / 完了後 bounded /loop・dispatcher=/loop 3m・secretary=ターン冒頭。「ナッジを見たら check_messages」prose は撤回せずこの fallback cadence として読む）。ORG_TRANSPORT=renga（opt-in）では、ワーカー報告・ディスパッチャー応答が <channel source="renga-peers" …> として in-band で push される（renga の in-band push と broker push 一次は同じ即応契機）。契約面は Surface 8 + push-primary amendment で push 一次が ratified 済み（2026-06-15、S3。pull は fallback として retain・renga 不変）。
• spawn 儀式（既定 = folder-trust 承認 + dev-channel sidecar 承認の 2 段）: 子ペイン起動時、既定 broker は --mcp-config <broker> を注入し Claude Code の folder-trust プロンプトを画面判定で機械承認するのに加えて、push 一次のため channel sidecar を --dangerously-load-development-channels server:org-broker-channel で load し dev-channel 承認プロンプト（spawn-flow 3-3b）を画面判定で機械承認する（folder-trust + dev-channel の 2 段承認。詳細は .dispatcher/references/spawn-flow.md 3-2 / 3-3b、設計は broker-native-roles.md §9.5）。ORG_TRANSPORT=renga（opt-in）では --dangerously-load-development-channels server:renga-peers を注入し「Load development channel?」を画面判定で承認する 1 段。注: attention watcher は transport 非依存の CLI ペインであり、folder-trust / dev-channel いずれの 2 段承認の対象外（spawn 儀式の反転に巻き込まない）。 画面判定 = inspect_pane → claude-org-runtime dispatcher spawn-prompt-step が返した 1 手だけを send_keys する反復（runtime 0.1.43+）。盲目 Enter は禁止（folder-trust の初期カーソルは「No, exit」で、Enter 一発はワーカーを終了させる）。手順は spawn-flow 3-3b。
• エラー分岐（既定 = broker 拡張コード込み）: 既定 broker は shared codes（pane_not_found / last_pane / invalid-params、Surface 6）に加え broker 固有 [token_invalid] / [session_invalid] / [tool_not_authorized] / [no_backend]（= adapter_unavailable）/ [nudge_failed] / [peer_not_found] / [name_taken] / [unknown_tool] を返しうる（未知コードは default-branch で escalate）。ORG_TRANSPORT=renga 時は broker 固有コードは発生せず shared codes + renga 固有コードのみ。

契約面の正本は docs/contracts/backend-interface-contract.md Surface 8（broker auth & delivery、ratified 2026-06-14）+ 末尾「Ratified amendment (2026-06-15): push-primary delivery」（S3。broker push 一次が既定の契約、pull は structural fallback として retain）、設計 SoT は transport-lab docs/design/broker-native-roles.md §9（push 一次）/ docs/design/ja-migration-plan.md §5・§8。opt-in renga は削除せず常時有効な fallback として維持する（切戻しの安全装置）。broker 実走（dogfood）は Epic #6 Issue G スコープであり、本ファイルの既定運用経路ではない（既定の二フレーム注記（Refs #604）: ここでの「既定 broker」はコード既定フレーム — tools/transport.py: DEFAULT_TRANSPORT が runtime 0.1.28 (Epic #586) で broker にフリップ済みで、ja 生成器・transport.resolve() はこのコードフレームで render するため生成面はこう表示する。別に運用既定フレームがあり、broker 実走 dogfood が Epic #6 Issue G まで未活性のため運用上の既定経路は renga。両フレームは指す対象（コード定数 vs 運用経路）が異なり矛盾しない。総説は root CLAUDE.md「輸送層（transport）両系」節。）

Step 1: 委譲プロセスの振り返り

以下を整理する:

• タスク分解は適切だったか: 粒度が大きすぎ/小さすぎなかったか
• 指示は明確だったか: ワーカーが迷わず作業できたか、質問が多くなかったか
• プロジェクト選定は正しかったか: 正しいディレクトリで作業できたか
• 並列度は適切だったか: ワーカー数が多すぎ/少なすぎなかったか
• 完了報告は十分だったか: ワーカーからの報告で人間に説明するのに足りたか

Step 2: 改善すべき知見の判断

以下の基準で「記録すべきか」を判断する:

記録する:

• 同じ種類の委譲で再び遭遇しそうなパターン
• 指示テンプレートの改善につながる気づき
• プロジェクト固有の制約で次回も影響しそうなもの
• ワーカーの振り返り記録が不十分/過剰だった場合の改善点

記録しない:

• タスク固有の一度きりの問題
• ワーカーが既に技術的知見として記録済みのこと

Step 2.5: 失敗を止める検査（完了条件）

Step 1 で扱った失敗ごとに、次のいずれかを済ませる。どれも無い失敗が 1 つでもあれば、この振り返りは完了にしない。 記憶（knowledge/raw/ や memory）への追記は補助であり、検査の代わりにならない。

1. 検査を足す: hook・テスト・tools/ の検査のどれか 1 本。足す前に、その失敗をもう一度起こすと検査が落ちることを確かめる。
2. 足す Issue を起票する: 検査の内容と、落ちることを確かめる手順を書く。Issue 番号を振り返りの記録に残す。
3. 検査にできない場合: できない理由を 1 行書く（これも完了条件の一部）。

検査を足したときは、止める失敗を 1 行にして docs/operations/defense-register.md の表へ 1 行加える （一覧への追加も完了条件。hook は一覧に無いとテスト tools/test_defense_report.py が落ちる）。

Step 3: 記録

知見がある場合、以下のパスにファイルを作成する:

• パス: knowledge/raw/{YYYY-MM-DD}-delegation-{topic}.md
• {topic} は英語 kebab-case（例: delegation-task-granularity, delegation-frontend-instructions）
• プレフィックスに delegation- を付けて、ワーカーの技術的知見と区別する

ファイルフォーマット

.claude/skills/org-curate/references/knowledge-standards.md の「記録フォーマット」を参照すること。

Step 4: work-skill 化の判定

完了したタスクの作業パターンについて skill-eligibility-check を呼び出し、 work-skill として蓄積すべきか判定する。

判断基準の実体は .claude/skills/skill-eligibility-check/references/signals.md に集約されており、 org-retro と org-curate の両方が同じ基準を参照する（判定の乖離を防ぐため）。

Step 4.1: skill-eligibility-check を呼ぶ

以下の入力を組み立てて呼び出す:

context: post_retro
pattern_name: <推定される skill 名、kebab-case>
summary: <何を再利用できるかの 1-2 文>
task_ids: [<今回の task_id>]
raw_files: <ワーカーが記録した knowledge/raw/ のパス配列>
steps_outline:
  - <主要手順 1>
  - <主要手順 2>
  - ...
trigger_description: <このパターンが適用される状況>
decision_criteria: <判断基準や閾値>
output_format: <成果物の構造>

スキルは 5 シグナルで採点し、decision を返す:

• skill_recommend（3 点以上）
• candidate_queue（2 点）
• curated_only（1 点以下）

skill_recommend の場合は machine-local な knowledge/skill-candidates.local.md（実エントリ用）への追記もスキル側で実施される（公開 knowledge/skill-candidates.md は フォーマット定義のみでエントリ常に空）。

Step 4.2: decision に応じて分岐

decision == skill_recommend

キュー追記（knowledge/skill-candidates.local.md への追記はスキル側で実施済み）に留め、 人間への即時提案はせず黙って次に進む。人間への問い合わせは、候補キューの pending が 5 件以上（N=5）に達した時点で窓口が行うバッチ問い合わせ、または /skill-audit の発火時のみ。 一次参照は knowledge/skill-candidates.md 冒頭の 運用ルール。

以下 1〜3 は即時には実行しない。バッチ問い合わせ（または /skill-audit）で人間が各候補を 判断した時点で窓口が実行する処理フローとしてここに温存する:

1. 人間が承認した場合:
   • skill ファイルの作成・編集は窓口（secretary）が直接行わない。 skill-promotion は委譲タスクとして org-delegate 経由でワーカーに渡す。
   • 窓口は org-delegate を起動し、role claude-org-self-edit のワーカータスクを生成する。 指示には以下を含める:
     • 対象 skill 名 {skill-name} と書き込み先 .claude/skills/{skill-name}/SKILL.md
     • テンプレート参照: .claude/skills/org-retro/references/work-skill-template.md
     • 抽出元（ワーカーの成果物・raw 知見ファイルのパス）と、 タスク固有の値をプレースホルダーへ置換する旨
     • skill-promotion 委譲であること（ワーカーの書き込み範囲の例外に当たる）
   • ディスパッチャー / 窓口は .claude/skills/{skill-name}/ および knowledge/skill-candidates.local.md（実エントリ用）への 直接書き込みを行わない。.local.md エントリの status transition （approved への遷移と 決定日 の記入）も同じ委譲ワーカーの責務とし、指示にその旨を含める。
2. 人間が却下した場合:
   • 理由を knowledge/raw/ に記録し、次回の判断に活かす
   • knowledge/skill-candidates.local.md の status を rejected に更新し却下理由を追記する作業も ワーカーへの委譲（org-delegate）経由で行う。窓口・ディスパッチャーは直接編集しない。
3. 人間が「既存 skill に統合」を選択した場合（terminal status merged-into-{existing-skill}）:
   • 統合先となる既存 skill を特定し、org-delegate で skill-promotion ワーカーに以下を委譲する: 既存 .claude/skills/{existing-skill}/SKILL.md への取り込み編集、および knowledge/skill-candidates.local.md 該当エントリの status を merged-into-{existing-skill} に 更新（統合先 フィールドに既存 skill 名を記入）。
   • 新規 skill ファイルは作成しない。窓口・ディスパッチャーは直接編集しない。
4. 人間が「今は見送り（保留）」を選択した場合（status deferred）:
   • knowledge/skill-candidates.local.md 該当エントリの status を pending → deferred に更新する 作業をワーカーへの委譲（org-delegate）経由で行う（窓口・ディスパッチャーは直接編集しない）。
   • deferred は terminal ではないが閾値カウント対象外・再問い合わせ対象外。以後この候補を pending に戻さず、バッチ問い合わせ / /skill-audit で蒸し返さない（見送り済み候補が worker クローズのたびに curator を無駄起動する問題への対策）。人間が後日あらためて検討したい ときのみ新しい日付で別エントリを起こす。

decision == candidate_queue

候補止まり。次回同パターンが raw に再出現すれば raw_reappearance シグナルが立つため、 この段階では skill 化しない。knowledge/raw/ への技術的知見記録は通常どおり（ワーカー記録済みならスキップ）。

decision == curated_only

knowledge/raw/ への技術的知見記録で十分（ワーカーが既に記録している場合はスキップ）。 報告は不要。

Step 5: 報告

人間に簡潔に報告する:

• 知見を記録した場合: 「委譲プロセスについて{topic}の学びを記録しました」
• skill_recommend / candidate_queue / curated_only のいずれの場合も: 報告不要（黙って次に進む）

Step 6: 防御の見直し

振り返りのたびに、増えた防御の集計を添えて見直しの候補を挙げる。

python tools/defense_report.py

直近 30 日の「止めた回数」「一度も止めていないもの」「止めすぎの疑い」が出る。 止めすぎの判定は近似（止められた直後に同じ作業が言い換えで再試行された回数）なので、正しい回避かすり抜けかは人が見る。 出力を振り返りの記録に添え、30 日止めていないものと止めすぎの疑いが多いものを候補として人間に挙げる。 削るか残すかはオーナーが決める。窓口は削らない。 止めた記録がまだ無い間は全て「一度も止めていない」と出るため、その場合は記録が無いだけと添えて候補にしない。