kickoff

kickoff skill の概要

kickoff ができること

kickoff は、ラフなアイデアや受信箱メモを、Project Management 向けの構造化された Project Note に変換する skill です。最初から最後までを一度に長文で書き出すのではなく、kickoff は「まず計画」「レビュー後に実行」という 2 段階フローで進みます。引き継ぎをきれいにしたいときや、途中で文脈がぶれにくい進め方を重視するなら、汎用的な「このプロジェクトを計画して」プロンプトより実用的です。

kickoff が向いている人

この kickoff skill は、すでにアイデアメモを残す習慣があり、特に 00_Inbox/ のような inbox 型フォルダで管理しているユーザーに向いています。そこにあるメモを、実行可能なプロジェクト文書へ一定の手順で昇格させたい場合に相性が良いです。フル機能の PM ツールを導入するほどではないものの、軽量なプロジェクト開始の型を持ちたいオペレーター、創業者、個人開発者に特に役立ちます。

なぜ kickoff が選ばれるのか

kickoff の主な差別化ポイントは、オーケストレーションにあります。単に一度だけノートを下書きするのではなく、計画フェーズと実行フェーズを明確に分離し、その間に確認を挟むよう設計されています。このレビュー用のゲートは、最終的な Project Note を作る前に、スコープ、命名、構成、言語をきちんと整えたい場合に大きな価値があります。

kickoff をインストールする前に知っておきたいこと

このリポジトリでは、確認できる実体は SKILL.md 1 ファイルのみで、補助スクリプト、ルールパック、リソースファイルはありません。そのぶん kickoff は中身を確認しやすい一方、出力品質は入力内容と、skill 内で説明されているマルチエージェントの流れを実行環境がサポートしているかに強く左右されます。レビューなしの一発生成を求めるなら、kickoff は必要以上に手順があると感じるかもしれません。

kickoff skill の使い方

インストール時の前提と最初に読むべきファイル

kickoff を導入する際は、リポジトリから skill を追加したうえで、まず EN/.agents/skills/kickoff/SKILL.md を読むのがおすすめです。このファイルに、ワークフロー全体、役割定義、言語ルールがまとまっています。この skill のパスには README.md、metadata.json、補助フォルダが存在しないため、挙動のほぼすべてがその 1 ファイルで定義されています。本格的に使う前に、利用中のエージェント環境が task-style のツール経由で subagent を呼び出せるかを確認してください。

kickoff に必要な入力

kickoff の使い方では、開始方法が 3 つあります。

• 00_Inbox/MyIdea.md のようなファイルパス
• “Build a habit tracker app” のようなインラインテキスト
• 入力なし。この場合、skill は 00_Inbox/ を一覧表示し、選択を促す想定です

より良い結果を出しやすいのは、課題、対象ユーザー、目指す成果、制約、締切や納品形式まで含んだ入力です。弱い入力例は「make this into a project.」。より強い入力例は「/kickoff Build a habit tracker app for iOS freelancers; MVP in 3 weeks; needs reminders, streaks, and CSV export; keep scope solo-developer friendly.」です。

実務で使いやすい kickoff ワークフロー

信頼しやすい kickoff の進め方は次の通りです。

1. ノートのパス、または簡潔なブリーフ付きで /kickoff を実行する。
2. planning agent に plan file を作らせる。
3. 承認前にその plan をレビューする。
4. スコープ、命名、前提、抜けている制約を直してから確認する。
5. execution agent に、plan file のみをもとに最終的な Project Note を作成させる。

この「plan file only」で引き渡す設計こそが重要なポイントです。元の長いやり取りから不要な文脈が紛れ込むのを防げる一方で、plan に抜けがあればそのまま出力にも抜けが残ります。だからこそレビューが重要です。

出力品質を上げる kickoff のプロンプト設計

Project Management 向けに kickoff を使うなら、単なる発想出しではなく、プロジェクトノートの形を決められる程度に具体的なプロンプトを書くのが効果的です。良いパターンは以下です。

• source: アイデアの出所
• objective: 成功の定義
• scope: 必須範囲と後回しにする範囲
• constraints: 時間、ツール、予算、チーム規模
• deliverable: 期待する文書やプロジェクト成果物

例:
/kickoff 00_Inbox/ClientPortal.md

その後のレビュー時には、次のような修正を加えます。

• “Use English for the project note.”
• “Scope MVP to authentication, dashboard, and billing history only.”
• “Target a 2-person team and a 6-week timeline.”

あわせて、組み込みの言語ルールにも注意が必要です。kickoff は、ユーザー入力または inbox ファイルの内容の言語に合わせて出力する想定になっています。

kickoff skill の FAQ

kickoff は通常の planning prompt より優れている？

レビュー付きの段階的なワークフローが欲しいなら、たいていは Yes です。通常の prompt のほうがプロジェクト計画を素早く生成できる場面はありますが、kickoff には planning と最終ノート作成の間に意図的なチェックポイントがあります。後工程でスコープや構成のミスが高くつくケースでは、この違いが効きます。

kickoff は初心者にも使いやすい？

アイデアを自分で説明できる程度に整理できているなら、Yes です。kickoff skill は、すべてが 1 つの SKILL.md にまとまっているので確認しやすく、構造もシンプルです。初心者にとって難しいのはインストールではなく、planning agent がしっかりした plan file を作れるだけの文脈を渡すことです。

kickoff が向かないのはどんなケース？

高度なタスク自動化、外部連携、スクリプトで強制される厳密なテンプレートが必要なら、kickoff は見送ったほうがよいです。このリポジトリには helper code、validation logic、外部リソースが含まれていません。また、レビュー工程を挟みたくなく、短時間で 1 回だけノートを作れればよい用途にもあまり向きません。

kickoff は OrbitOS のフォルダ構成に依存する？

一部は依存します。入力がない場合、この skill は明示的に 00_Inbox/ を参照するため、同様の慣例でノートを管理している環境との相性が最も良いです。とはいえ、インラインテキストや直接のファイルパスでも kickoff は使えます。デフォルトの探索フローが、その inbox 構成の存在を前提にしているという理解が正確です。

kickoff skill を改善するには

kickoff に、より厚みのあるプロジェクト入力を渡す

kickoff の結果を手早く良くする一番の方法は、判断材料になる文脈を最初から十分に入れることです。たとえば以下を含めてください。

• target user
• problem statement
• constraints
• timeline
• success criteria
• known dependencies

これにより planning agent は、execution agent が安定して展開できる plan file を作りやすくなります。最初の prompt にこれらが欠けていると、汎用的な Project Note になりやすいです。

plan を引き継ぎ文書としてレビューする

plan review を任意の工程だと考えないでください。execution agent は plan file しか読まないため、前提の抜け、曖昧なマイルストーン、スコープ境界の不明瞭さを必ず確認する必要があります。人間のチームメイトに渡しても実行できない plan なら、第 2 フェーズもうまく進まない可能性が高いです。

kickoff で起こりやすい失敗パターンに注意する

kickoff の使い方でよくある失敗は、ある程度パターン化されています。

• アイデアが曖昧すぎる
• inbox note がノイジーで構造化されていない
• 制約条件が抜けている
• 言語の期待値が不明確
• ユーザーが plan を早く承認しすぎる

実用的な対策としては、kickoff の前に雑多なメモを軽く整形することです。タイトル、1 文の objective、想定読者、短い “must include” リストを足すだけでも改善します。

最初の出力後は plan から改善する

最終的な Project Note が「惜しいけれどそのままでは使えない」状態なら、最終ノートだけを編集するのではなく、plan を見直して kickoff を改善してください。たとえば、より狭いスコープ、より明確なマイルストーン、別のプロジェクト構成を求めて、planning 段階からやり直します。この skill では、最初の prompt を長くすること以上に、中間構造を良くすることのほうが効く場面が多いです。