chief-of-staff
作成者 alirezarezvanichief-of-staff は、創業者の意思決定を支援する C-suite オーケストレーション skill です。質問を適切なエグゼクティブアドバイザー役に振り分け、複雑な判断では取締役会形式のレビューを招集し、トレードオフを整理します。さらに、ルーティングと統合のリファレンスを使って意思決定ログの作成も支援します。
この skill は 78/100 の評価で、単一のアドバイザープロンプトではなく C-suite のオーケストレーション層を求めるディレクトリ利用者にとって有力な掲載候補です。ルーティングルール、呼び出し構文、ループ防止の制約、統合ガイダンスが十分に用意されており、汎用プロンプトよりもエージェントが迷わず実行しやすい内容です。ただし、関連する advisor/context skills が利用可能かどうかは確認しておく必要があります。
- トリガー条件が明確です。frontmatter で、アドバイザーへのルーティングが必要な創業者の質問や、複数領域にまたがる取締役会レベルの意思決定に使うと示されており、資金調達と burn 削減の比較といった例もあります。
- 実務で使いやすいワークフローです。セッション手順には、会社コンテキストの読み込み、複雑度のスコアリング、ルーティング、統合、意思決定ログの作成が含まれています。
- 支援リファレンスによりエージェントが動かしやすい構成です。ルーティングマトリクスは一般的な C-suite の論点を primary/secondary roles とスコアに対応づけ、synthesis framework は複数ロールの出力を統合する具体的な手順を示しています。
- context-engine、CFO、CEO、COO、CRO、CPO、CTO、CHRO など、他の skills/roles に依存します。抜粋からは、それらが未インストールの場合のフォールバック動作は確認できません。
- この skill フォルダにはインストールコマンドや README がないため、導入時はリポジトリ全体の前提からインストール方法を推測する必要があります。
chief-of-staff skillの概要
chief-of-staffができること
chief-of-staffは、創業者の意思決定を支援するためのC-suiteオーケストレーションskillです。あらゆる質問に汎用的な視点で答えるのではなく、課題に応じて適切な経営アドバイザーの役割へ振り分け、複数ロールによるボードミーティングが必要かを判断し、競合する見解を統合し、意思決定に至った場合はその内容を記録します。
本質的な役割は「スタートアップの助言をすること」ではありません。「今資金調達すべきか、それともバーンを削るべきか？」のような曖昧な経営課題を、財務、成長、プロダクト、オペレーション、人材、テクノロジー、CEOレベルのトレードオフといった適切な観点を当てた、構造化された意思決定プロセスに変えることです。
向いているユーザーと意思決定
chief-of-staff skillは、再現性のある経営アドバイザリーワークフローを求める創業者、事業責任者、AI-agentビルダーに向いています。特に強いのは、価格設定、ランウェイ、採用ペース、プロダクト優先順位、組織再編、資金調達タイミング、リーダーシップ上の対立、模擬ボードディスカッションを開くべきかといった、部門横断の意思決定です。
一方で、コピーを書く、コードをデバッグする、事実確認の質問に答えるといった、狭い単一タスクにはあまり向きません。主なリスクが、誤ったアドバイザー視点を選んでしまうこと、重要なステークホルダーの観点を見落とすこと、複数ロールの出力が山積みになるだけで明確な推奨にまとまらないことにある場合に使うべきskillです。
このskillの違い
差別化のポイントは、ルーティングと統合のレイヤーです。このrepositoryには、質問タイプを経営ロールと複雑度スコアに対応づけるreferences/routing-matrix.mdと、複数ロールの回答を創業者が使える1つの回答へ統合する方法を説明するreferences/synthesis-framework.mdが含まれています。
そのため、Decision Support向けのchief-of-staffは、広い意味での「act as my COO」プロンプトよりも構造化されています。ループ防止ルール、最大呼び出し深度、ルーティング構文、高複雑度の意思決定に対応するボードミーティング経路が用意されています。
chief-of-staff skillの使い方
chief-of-staffのインストールと最初に確認するファイル
利用しているskill managerがGitHubからのskillインストールに対応している場合は、次のコマンドでインストールします。
npx skills add alirezarezvani/claude-skills --skill chief-of-staff
次にskillのパスを確認します。
c-level-advisor/skills/chief-of-staff
以下の順番でファイルを読みます。
SKILL.md— セッションプロトコル、呼び出し構文、ルーティング挙動、ループ防止。references/routing-matrix.md— どの意思決定をどの経営ロールが扱うべきか。references/synthesis-framework.md— 複数ロールの出力をどのように1つの推奨へまとめるか。
設定すべきスクリプトやリソースはありません。そのため導入の成否は、主にプロトコルを正しく使い、十分な会社コンテキストを与えられるかに左右されます。
skillがうまく機能するために必要な入力
このskillは、context-engine skillを通じて会社コンテキストを読み込む設計ですが、利用環境にその情報がまだ入っていない場合は、意思決定に必要な事実をプロンプト内で直接渡すべきです。良い入力には、次のような情報が含まれます。
- 会社のステージ、ビジネスモデル、市場、現在の目標。
- 関連する数値：ランウェイ、バーン、売上、成長率、マージン、セールスサイクル、従業員数。
- 意思決定の期限と、後戻りのしやすさ。
- すでに検討している選択肢。
- 制約条件：キャッシュ、チームの余力、投資家への約束、顧客へのコミットメント。
- 良い回答として何を得たいか：意思決定、選択肢、リスクマップ、ボード向け推奨、次のアクション。
弱いプロンプト例：「Should we hire a VP Sales?」
より良いプロンプト例：「We are a B2B SaaS company at $1.8M ARR, growing 6% MoM, 11 months runway, founder-led sales, 4 AEs, weak pipeline discipline. Should we hire a VP Sales now, promote internally, or wait until after Series A? Route this through chief-of-staff and synthesize CFO, CRO, and CEO tradeoffs.」
呼び出し構文と実務でのワークフロー
上流のskillでは、次の呼び出し形式を使います。
[INVOKE:role|question]
例：
[INVOKE:cfo|What's the right runway target given our growth rate?]
[INVOKE:board|Should we raise a bridge or cut to profitability?]
chief-of-staffを実務で使う場合のワークフローは次のとおりです。
- 創業者の問いと会社コンテキストから始める。
- skillに複雑度を評価させ、単一ロール、複数ロール、またはboardを選ばせる。
- 推奨を出す前に、前提条件を明示するよう依頼する。
- 複数ロールが関わる意思決定では、議事録ではなく統合された結論を求める。
- 最後に、1つの意思決定ポイント、未解決リスク、次のアクションで締める。
重要度の高い意思決定では、明示的にこう依頼します：“If this requires a board meeting, convene one; otherwise route to the minimum necessary roles.”
chief-of-staff skill FAQ
chief-of-staffは通常のプロンプトより優れていますか？
部門横断の問題であれば、有効です。通常のプロンプトは、どの観点が推奨を左右しているのかを説明しないまま、混ざった回答を返しがちです。chief-of-staff skillはルーティングの規律を加えます。資本政策とランウェイならCFO、人材課題ならCHRO、プロダクトと技術的トレードオフならCPO/CTO、売上ならCRO、複雑な複数領域の判断ならboard mode、という形です。
単純な助言であれば、通常のプロンプトのほうが速い場合があります。実際のトレードオフを伴う創業者の意思決定では、このskillが盲点を減らします。
このskillができないこと
法律、財務、人事、医療、投資の専門家の代替にはなりません。また、agent環境に会社コンテキストが読み込まれているか、プロンプトで提供しない限り、あなたの事業データを自動的に把握することもありません。
このskillはアドバイザリー推論を調整するものです。周辺のagent設定が対応していない限り、資金調達を実行したり、財務モデルを更新したり、ロードマップを変更したり、信頼できる意思決定ログを作成したりするわけではありません。
初心者にも使いやすいですか？
ある程度は使いやすいです。呼び出し構文はシンプルですが、ユーザーが「ロールごとの回答」と「統合された意思決定」の違いを理解しているほど、出力の品質は大きく向上します。初心者はまず、skillにルーティングの選択理由を説明させるところから始めるとよいでしょう。
“Use chief-of-staff. First state which role or roles you are routing to and why, then provide the synthesized recommendation.”
これにより、skillがすべての質問を過剰にボードミーティングへエスカレーションしていないかを確認できます。
このskillを避けるべき場面
単一の専門家による回答が必要な場合、短時間でコンテンツ草案がほしい場合、コーディングタスク、純粋な事実確認にはchief-of-staffを避けるべきです。また、意味のある判断に必要な事業コンテキストを十分に共有できない場合にも向きません。数値、制約、目標がなければ、このskillは洗練されてはいても一般論に近い経営アドバイスを返す可能性があります。
chief-of-staff skillを改善する方法
意思決定に耐えるコンテキストでchief-of-staffの出力を改善する
最も重要な改善は、skillに意思決定に耐える入力を与えることです。単なるテーマではなく、実際に選ぶべき選択肢を含めます。「Pricing strategy」は広すぎますが、「Should we move from seat-based to usage-based pricing before Series A?」であれば、routing matrixが分類できる具体的な意思決定になります。
現在の指標の基準値と、判断を誤った場合の影響も加えてください。ランウェイが6か月の場合と24か月の場合では、CFOの回答は変わります。解約の原因が機能不足なのかオンボーディングの弱さなのかによって、CPOの回答も変わります。
ルーティング、エスカレーション、統合品質をコントロールする
よくある失敗は、過剰なルーティング、不十分なルーティング、そして要約風の統合です。これを防ぐには、次のように依頼します。
- “Use the fewest roles needed.”
- “Escalate to board only if the decision affects multiple functions or has high downside.”
- “Name conflicts between roles instead of averaging them.”
- “End with a recommended path, not a list of equal options.”
これはrepositoryのsynthesis frameworkと整合します。最も価値の高い出力は、単なるまとめではなく、コンセンサス、対立点、ギャップ、優先アクション、そして明確な1つの意思決定ポイントを含む、統合された意思決定です。
最初の回答のあとに反復する
最初の出力のあとに、単に「もっと詳しく」と聞くのは避けましょう。狙いを絞ったフォローアップをします。
- “What assumption would change the recommendation?”
- “What would the CFO object to?”
- “What is the lowest-regret option if our growth forecast is wrong?”
- “What should we decide this week versus revisit in 30 days?”
- “Convert this into a decision log entry with owner, date, rationale, and review trigger.”
これにより、chief-of-staffは単発のアドバイザーではなく、創業者の意思決定支援を継続的に回すための運営リズムになります。