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 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（実エントリ用・ Issue #755）への追記もスキル側で実施される（公開 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 冒頭の 運用ルール（Issue #68 方針）。

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

1. 人間が承認した場合:
   • skill ファイルの作成・編集は窓口（secretary）が直接行わない。Set E §2.4 (Q7) の批准に従い、 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 委譲であること（Set A worker write-surface の carve-out 対象）
   • ディスパッチャー / 窓口は .claude/skills/{skill-name}/ および knowledge/skill-candidates.local.md（実エントリ用・Issue #755）への 直接書き込みを行わない。Set E §1.4 / §2.4 に従い、.local.md エントリの status transition （approved への遷移と 決定日 の記入）も同じ委譲ワーカーの責務とし、指示にその旨を含める。
2. 人間が却下した場合:
   • 理由を knowledge/raw/ に記録し、次回の判断に活かす
   • knowledge/skill-candidates.local.md の status を rejected に更新し却下理由を追記する作業も ワーカーへの委譲（org-delegate）経由で行う。窓口・ディスパッチャーは直接編集しない （Set E §1.4 の owner 定義に従う）。
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。Issue #753）:
   • knowledge/skill-candidates.local.md 該当エントリの status を pending → deferred に更新する 作業をワーカーへの委譲（org-delegate）経由で行う（窓口・ディスパッチャーは直接編集しない、 Set E §1.4 の owner 定義に従う）。
   • 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 のいずれの場合も: 報告不要（黙って次に進む）。 skill_recommend はキュー追記のみで完結し、人間への問い合わせは knowledge/skill-candidates.md 冒頭の運用ルールに従い pending ≥5 のバッチ問い合わせまたは /skill-audit 発火時に窓口が行う