kickoff-doc について
kickoff-docは、キックオフの文字起こしをビルダー向けの参照ドキュメントにまとめるスキルです。会話の順序ではなくシステム領域ごとに整理し、戦略的背景とシステムの形を分けて記録します。
主な機能
- 01FrameとShapeの文書構成
- 02時系列ではなく領域ごとに整理
- 03領域に沿って設計判断を記録
- 04境界条件と例外ケースを記録
- 05文字起こしと主張を照合
活用シーン
- 01キックオフ内容を実装リファレンス化
- 02散在するシステム領域の議論を統合
- 03判断事項と仮置き内容を記録
- 04曖昧な点を判断する背景をビルダーに提供
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/kickoff-docを入力して読み込まれたか確認します。
詳細
Transcript からのキックオフドキュメント
キックオフ通話の transcript を、形作られたプロジェクト向けのビルダー用リファレンスドキュメントに変換します。
作成を始める前に
ユーザーに次のことを尋ねます。
- 主な読者は誰ですか？（通常は、作業を実装するビルダーです。）
- ほかにどのような資料がありますか？（ビジュアル、スクリーンショット、モックアップ、セッションで作成したブレッドボードなど。）
transcript が資料となります。このドキュメントは通話の要約ではなく、形作られた領域の地図です。
構成の原則：時系列ではなく、領域ごとに整理する
キックオフ transcript は逐次的です。参加者は話題に上がった順に話し、前の話題に戻り、脱線し、ブラウザーの問題に気を取られます。あなたの仕事は、会話を再現することではなく、彼らが説明していた領域を再構成することです。
作るものごとに整理します。 各セクションではシステムの1つの領域を詳しく説明します。これにより、ビルダーは「Criteria タブはどのように動作するのか？」を調べるときに、必要な情報を一か所で見つけられます。
実装の順序で整理してはいけません。 チームがスライス（順番に実装する一連の垂直スライス）を特定した場合、それらは別途管理します。このドキュメントには含めません。
構成
ドキュメントには、トップレベルのセクションが2つあります。Frame と Shape です。どちらも ## 見出しで、その下位セクションは ### 見出しです。
1. Frame（## Frame）
戦略的な背景と境界条件です。これは単なる飾りではありません。曖昧な状況に直面したとき、判断を下すためにビルダーが必要とする情報です。
### Problem— このプロジェクトが必要な理由と、今取り組む理由。何が壊れているのか、または不足しているのか。### Outcome— 期待される具体的な成果。成功とはどのような状態か。
2. Shape（## Shape）
システムの領域ごとに ### セクションを1つ作成します。各領域について、次のことを説明します。
- それが何か、画面に何が表示されるか（操作できる要素、コンポーネント、表示データ）
- ほかの領域とどのように関係するか
- その領域に関する設計上の決定事項 — 別セクションに分けず、その場に記載します
- 指摘されたエッジケースや注意事項
- 一時的なもの／プレースホルダーと、正式に決定したもの
Build Sequence セクションは含めないでください。 スライスはこのドキュメントとは別に管理します。
文体：参加者の言葉を使う
このドキュメントは、キックオフ通話で共有された認識を記録するものです。
すること
- 通話で実際に使われた言葉や表現を使います
- 複数のやり取りに散らばった内容を、明確な形にまとめます
- 決定に至った理由を記録します（「Y だから X にする」）
しないこと
- 新しいアイデアや結論を、参加者が述べたことのように書かないでください
- 参加者が表明していない動機づけを加えないでください（「それぞれの要素は使い捨てではなく、土台となるものです」など）
- 発言されていない重要性や品質について、評価や意見を加えないでください
判断基準
各文について、transcript の中で誰かがそう述べた、または明確に意図した箇所を示せる必要があります。それができない場合は、その文を削除するか、独自の統合であることを明記してください。
例外： 発言内容を明確にしたり、まとめたりするための見解の追加は問題ありません。「criteria 画面は、新しい世界でのフィルタリングの表現方法です」という文は、そのままの表現で誰も述べていません。しかし、複数のやり取りで示された要点を正確に表しています。話を明確にするために、散らばった議論を読み解きやすくするのが役割です。独自の結論を加えてはいけません。
設計上の決定事項：横断的ではなく、領域ごとに記載する
雑多な項目をまとめた「Design Decisions」セクションは作らないでください。代わりに、それぞれの決定事項を関係するセクションに記載します。
- 「マッチング結果は Redis ではなく DB に保存する」→ マッチングに関するセクション
- 「候補は添付する前に実体化する必要がある」→ 添付に関するセクション
- 「ICP ごとのマッチングデータは値オブジェクトとして扱う」→ マッチング結果に関するセクション
ある決定事項が特定の領域の実装にだけ関わる場合は、その領域のセクションに記載します。特定の画面を作業するときに、別の決定事項一覧を参照する必要がないようにします。
プロセス
- トランスクリプト全体を読みます。 一部を読んだだけで書き始めないでください。
- 話し合われたシステムの領域を特定します。これらを
## Shapeの下の###セクションにします。 - フレーミングと成果についての議論（通常は通話の冒頭付近）をもとに、Frame（
## Frameの下に### Problemと### Outcome）を作成します。 - トランスクリプトの該当領域について話し合われた箇所を参照しながら、各 Shape セクション（
### ...）を作成します。1つのセクションで、通話全体に散らばった複数の発言を参照してもかまいません。 - デザイン上の決定事項は、それに該当するセクション内に記載します。
- トランスクリプトと照らし合わせて確認します。各主張について、発言された箇所を示せますか？