菜单
Cursor Composer 2.5 で壁打ち〜計画立案フェーズを実用化するためのお膳立てスキル。音声入力の断片を解釈し、暗黙の前提を読み、N≥3 案で多角展開し、必要に応じて question-driven-design / plan-to-kickoff / kickoff-to-plan / adversarial-review を呼び出す wrapper。壁打ち、設計、方針、ハーネス、canonical、sync 等のキーワードで発火。
用 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 | cursor-kickoff |
| description | Cursor Composer 2.5 で壁打ち〜計画立案フェーズを実用化するためのお膳立てスキル。音声入力の断片を解釈し、暗黙の前提を読み、N≥3 案で多角展開し、必要に応じて question-driven-design / plan-to-kickoff / kickoff-to-plan / adversarial-review を呼び出す wrapper。壁打ち、設計、方針、ハーネス、canonical、sync 等のキーワードで発火。 |
| depends | [{"skill":"question-driven-design"},{"skill":"plan-to-kickoff"},{"skill":"kickoff-to-plan"},{"skill":"adversarial-review"}] |
本スキルは新規実装ではなく wrapper / orchestrator。Composer 2.5 が拾いきれない暗黙のお膳立てを補い、既存の汎用スキル (question-driven-design, plan-to-kickoff, kickoff-to-plan, adversarial-review) へ橋渡しする。
「贅肉」（解釈能力の弱さを補う冗長性）は意図的なコスト。再実装はしない。
観測可能な protocol で構成する。抽象的な「反省せよ」「よく考えよ」は性能劣化を招く（arXiv:2503.00902 Instruct-of-Reflection）。
canonical/cursor/rules/cursor-first-turn.mdc が alwaysApply で常時注入される。本スキルはその rule が分類した WALL_BOUNCE / PLAN モード、あるいは Kickoff trigger キーワードを受けて発火する。
音声入力由来の可能性を前提に解釈する。
### 入力解釈
#### 主意図
<one paragraph>
#### 補完した前提
- <implicit assumption>
#### タスク種別
`FACT_CHECK` | `WALL_BOUNCE` | `PLAN` | `EXECUTE`
ルール:
「使えません」と宣言する前に必ず検証する。
README.md
canonical/
canonical/CATALOG.md
canonical/cursor/
canonical/rules/
canonical/skills/
docs/
scripts/
.cursor/
### 能力確認
#### 確認できたこと
- <fact + path>
#### 未確認のこと
- <unknown>
#### 次に確認すべきこと
- <next inspection>
ルール:
主要な主張を必ずラベル付けする。
| ラベル | 意味 |
|---|---|
確証 | inspected ファイル / 公式 docs / ログ / 直接観測した動作 |
推測 | 利用可能な context からの推論 |
未確認 | もっともらしいが検証していない |
ルール:
WALL_BOUNCE または PLAN モードでは N≥3 案を出す。
### 候補案
#### Option A: <name>
- 概要:
- 向く条件:
- 強み:
- 弱み:
- 検証方法:
#### Option B: <name>
- ...
#### Option C: <name>
- ...
ルール:
設計判断が多くて分岐の洗い出しが先に必要な場合、question-driven-design skill を呼び出す（質問駆動で前提を掘る）。
候補案の後に必ず推奨を出す。
### 推奨
第一候補: <Option>
理由:
- <reason>
採用しない案:
- <Option>: <why not now>
ルール:
PLAN モードに収束したら Kickoff Doc を生成する。
詳細フォーマットと変換ルールは plan-to-kickoff / kickoff-to-plan skill に従う。ここで再実装しない。
# Kickoff: <title>
## 1. Goal
## 2. Background
## 3. Confirmed facts
## 4. Assumptions
## 5. Constraints
## 6. Non-goals
## 7. Options
## 8. Recommendation
## 9. Implementation plan
## 10. Files to inspect or change
## 11. Validation
## 12. Risks
## 13. Open questions
Kickoff Doc を Plan に展開する場合は kickoff-to-plan skill を呼び出す。
Plan が成立したら adversarial-review skill で漏れ・矛盾・曖昧さを検出する。
実装フェーズに入る前のゲートとして使う。
最終応答は次の構造に圧縮する。
## 結論
<short recommendation>
## 確証 / 推測
<labeled facts and inferences>
## 候補
<options>
## 推奨
<recommendation>
## Kickoff Doc / 次の手
<doc if requested, or proposed next step>
避けるべき出力:
| スキル | 役割 | 呼び出すタイミング |
|---|---|---|
question-driven-design | 設計分岐の質問駆動掘り下げ | Phase 4 で分岐洗い出しが先に必要なとき |
plan-to-kickoff | Cursor Plan → Kickoff Doc 変換 | Phase 6 で Cursor Plan Mode 出力を文書化するとき |
kickoff-to-plan | Kickoff Doc → 実行可能 Plan 展開 | Phase 6 後、実装フェーズに入る前 |
adversarial-review | Plan / Spec の品質チェック | Phase 7（実装ゲート前） |
canonical/cursor/rules/cursor-first-turn.mdc — ターン1の自己能力宣言 / 即拒否禁止 / output mode 分類canonical/rules/input-style-rule.md — 音声入力解釈の汎用ルールcanonical/rules/decision-pacing-rule.md — 「やるかどうか」を先に決めるcanonical/rules/implementation-gate-rule.md — 実装前の計画フェーズ強制docs/issues/106/strategy.md