菜单
蒸留パイプライン文書（kickoff/episode/decision/discussion）の作成時にフォーマットを適用する。frontmatter付与、ULID生成、ファイル命名規則の案内を含む。ドキュメント新規作成、Episode→Decision昇格時に使用する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
親子 Claude Code セッション間の委譲操作を行う。delegate（子を起動してキック）、send（既存ペインへ1行/キックオフ送信・誤送信防止つき）、list（宛先確認）、report（子→親の申し送り）を自然言語の意図から判断して実行する。tmux 環境前提。
oe-* オーケストレーションツール群（engine 本体 / 親子委譲 / SO ゲート / 選択・観測）と駆動層規律の統合概観。複数エージェント委譲・設計SO/実装SO・read-only 観測・engine 1 サイクルを使うとき、ツール群の全体像をリポジトリ走査でなく一貫した形で把握したいときに使用する。
エラー/バグ調査で、入力→出力のコードパスに未読区間がある限り外部要因（インフラ差異等）の仮説に進まない。外部要因に飛ぼうとするとき、原因が再現しないと判断しそうなときに使用する。仮説を tmp/hypothesis-NNN.md に外部化し、コードパスの read-state を可視化する。
プランをKickoff Document形式に変換する。セカンドオピニオン投入・リポジトリアーカイブ・ピアレビュー共有時に使用する。命名規約・frontmatter・セクション構造をKickoff形式に整える。
設計判断を確定する前に、ゼロベースで未探索の代替案を最低1回引き出し、その証跡を確定前に残してから確定する。複数の選択肢を A/B 等で確定しかけたとき、ADR / Decision / kickoff の設計判断（DJ-N）を確定・記録するときに使用する。so-compare 選択肢拡張・探索木の外部化を含む。
so-compare.shでセカンドオピニオン（Codex/Claude/Cursor）を取得し、結果を比較する。ピアレビュー、修正方針の検証、設計判断の反証に使用する。**弱 SO**（1周可・partial=disclose・0はなし）。プロンプト設計原則、結果読み込み手順、合意判定基準を含む。
| name | spec-card |
| description | 蒸留パイプライン文書（kickoff/episode/decision/discussion）の作成時にフォーマットを適用する。frontmatter付与、ULID生成、ファイル命名規則の案内を含む。ドキュメント新規作成、Episode→Decision昇格時に使用する。 |
kickoff-to-plan / plan-to-kickoff の変換フロー自体（それらのスキルが優先）詳細な仕様は ai-development-hub リポジトリ内の docs/specs/document-format.md を参照。sync 後の ~/.claude/skills/ 等から読む場合は、hub ワークスペースを開いた状態でパスを解決すること。本スキルは定義へのルーティングとクイックリファレンスを提供する。
| フィールド | 型 | 説明 |
|---|---|---|
id | ULID (26文字) | 機械追跡用の一意識別子 |
title | string | 人間可読なタイトル |
date | YYYY-MM-DD | 作成日 |
type | enum | discussion / kickoff / plan / episode / decision |
status | enum | draft / in-development / stable / deprecated |
so モードを必須で宣言するkickoff / plan を作成するときは、frontmatter に so モードを必須で入れる（SO を設計段階で選択・記録する）:
so:
design: weak | strong # 設計 SO のモード
impl: weak | strong # 実装 SO のモード
reason: "<なぜそのモードか>"
peer-ai-review（全レーン返却＋合意まで iterate・partial=再試行・0=不可）。高難易度/高リスク/不可逆に。so-compare / oe-refute / oe-review（1 周可・partial=disclose して進む・0=SO 未実施扱いで再試行/escalate＝最低 1 レーン必須="0 はなし"）。低〜中難易度/可逆に。orchestration-toolkit）。定義の正本は docs/specs/document-format.md §3.1。| type | 用途 | フォーマット深度 |
|---|---|---|
discussion | 探索・ブレスト・調査メモ | 最小（frontmatter のみ） |
kickoff | スコープ確定・方針の言語化 | 重い（セクションテンプレートあり） |
plan | 実行可能な粒度まで分解 | 重い（kickoff-to-plan 出力と整合） |
episode | 実行記録・作業ログ | 中間（本文フリーフォーム + 性質ガイド）。closure 時は episode-retrospective skill を参照 |
decision | 意思決定の蒸留・ADR | 重い（コンテキスト / 決定 / 根拠 / 結果） |
YYYY-MM-DD-{type}-{topic}.md
例: 2026-04-05-decision-quality-gate-skip-prevention.md
python3 -c "
import time, random
t = int(time.time() * 1000)
c = '0123456789ABCDEFGHJKMNPQRSTVWXYZ'
ts = ''.join(c[(t >> (45 - 5*i)) & 31] for i in range(10))
rand = ''.join(random.choice(c) for _ in range(16))
print(ts + rand)
"
厳密に公式 ULID 仕様へ合わせる場合は docs/specs/document-format.md §4 のとおり ulid パッケージ利用を推奨。手書きスニペットは簡易実装のため厳密互換は保証しない。
kickoff-to-plan: KickOff → Plan の変換ロジック。本スキルのフォーマットと整合するが、変換フロー自体は kickoff-to-plan が担うplan-to-kickoff: Plan → KickOff の逆変換。同上adversarial-review: レビュー対象ドキュメントが本フォーマットに沿っていると、frontmatter の related[] から設計背景を自動参照できる本スキルはこれらを置き換えない。フォーマットの「入口案内」として機能する。