chief-of-staff
作者 alirezarezvanichief-of-staff 是一個面向創辦人決策支援的 C-suite 協調 skill。它會將問題分派給合適的高階主管顧問角色，針對複雜決策召開董事會式審查，彙整各項取捨，並透過分流與彙整參考支援決策紀錄。
此 skill 評分為 78/100。對於想要 C-suite 協調層，而不是單一顧問 prompt 的目錄使用者來說，是相當穩健的上架候選。它提供足夠的分流規則、呼叫語法、防止循環限制與彙整指引，讓 agent 執行時比一般 prompt 更少需要猜測；不過使用者仍應確認自己已具備相關的顧問／脈絡 skills。
- 觸發條件清楚：frontmatter 明確指出，當創辦人問題需要顧問分流，或涉及多領域董事會式決策時應使用此 skill，並提供如募資與降低 burn rate 之間取捨等範例。
- 工作流程具實務性：session protocol 涵蓋載入公司脈絡、評估複雜度、分流、彙整，以及決策紀錄。
- 能有效放大 agent 的執行力：routing matrix 將常見 C-suite 問題對應到主要／次要角色與分數，synthesis framework 則提供整合多角色輸出的具體步驟。
- 仰賴其他 skills／角色，例如 context-engine、CFO、CEO、COO、CRO、CPO、CTO 與 CHRO；摘錄內容未說明若未安裝這些項目時的備援行為。
- 此 skill 資料夾中沒有安裝指令或 README，因此採用時需要使用者從整體 repository 推斷安裝方式。
chief-of-staff skill 概覽
chief-of-staff 的用途
chief-of-staff 是一個面向 C-suite 的協調型 skill，用來支援創辦人的決策。它不是從單一、通用的角度回答所有問題，而是會把議題分派給合適的高階主管顧問角色，判斷何時需要召開多角色的模擬董事會議，整合彼此競合的觀點，並在達成決策時記錄下來。
它真正要做的事不是「提供新創建議」。它的工作，是協助創辦人把「現在該募資，還是先降低 burn？」這類模糊的營運問題，轉化為一套結構化的決策流程，並套用正確的判斷視角：財務、成長、產品、營運、人才、技術，以及 CEO 層級的取捨。
最適合的使用者與決策情境
chief-of-staff skill 適合想建立可重複高階顧問流程的創辦人、營運主管，以及 AI agent 建構者。它最擅長處理跨職能決策，例如定價、runway、招募速度、產品優先順序、組織重整、募資時機、領導團隊衝突，或是否需要召開一場模擬董事會討論。
它不太適合狹窄的單一任務，例如撰寫文案、debug 程式碼，或回答事實型問題。當主要風險在於選錯顧問視角、漏掉利害關係人的觀點，或收到一堆角色輸出卻沒有清楚建議時，才適合使用它。
這個 skill 的差異化之處
它的差異化重點在於路由與整合層。這個 repository 包含 references/routing-matrix.md，用來將問題類型對應到高階主管角色與複雜度分數；也包含 references/synthesis-framework.md，說明如何把多個角色的回應整合成一份創辦人可直接使用的答案。
因此，Decision Support 用的 chief-of-staff 比一般「act as my COO」提示更有結構。它包含防止迴圈的規則、最大 invocation depth、路由語法，以及針對高複雜度決策的 board-meeting 路徑。
如何使用 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— session protocol、invocation syntax、routing behavior、loop prevention。references/routing-matrix.md— 哪一種決策應由哪一個高階主管角色處理。references/synthesis-framework.md— 多角色輸出如何整合成一個建議。
這個 skill 沒有需要設定的 scripts 或 resources，因此導入成效主要取決於是否正確使用 protocol，以及是否提供足夠的公司脈絡。
讓 skill 發揮效果所需的輸入
這個 skill 設計上會透過 context-engine skill 載入公司脈絡，但如果你的環境尚未包含這些資料，仍應直接在提示中提供決策事實。好的輸入包括：
- 公司階段、商業模式、市場，以及目前目標。
- 相關數字：runway、burn、營收、成長率、毛利率、銷售週期、員工人數。
- 決策期限與可逆性。
- 目前已在考慮的選項。
- 限制條件：現金、團隊產能、對投資人的承諾、對客戶的承諾。
- 你希望答案產出什麼：決策、選項、風險地圖、董事會建議，或下一步行動。
較弱的提示：「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.」
Invocation syntax 與實務工作流程
上游 skill 使用以下 invocation format：
[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。
- 要求它先列出假設，再提出建議。
- 對於多角色決策，要求它產出整合結論，而不是逐字紀錄。
- 最後收斂成一個決策點、尚未解決的風險，以及下一步行動。
對高風險決策，請明確要求：「If this requires a board meeting, convene one; otherwise route to the minimum necessary roles.」
chief-of-staff skill 常見問題
chief-of-staff 會比一般 prompt 更好嗎？
會，特別是在問題牽涉跨職能時。一般 prompt 常會給出混合式答案，卻沒有說明是哪一種判斷視角在主導建議。chief-of-staff skill 加入了路由紀律：資本與 runway 交給 CFO，人才議題交給 CHRO，產品與技術取捨交給 CPO/CTO，營收交給 CRO，而複雜的多領域決策則進入 board mode。
如果只是簡單建議，一般 prompt 可能更快。但對於有實際取捨的創辦人決策，這個 skill 能降低盲點。
這個 skill 不會做什麼？
它不能取代法律、財務、人資、醫療或投資專業人士。它也不會神奇地知道你的營運資料，除非你的 agent 環境已經載入公司脈絡，或你在提示中自行提供。
這個 skill 負責協調顧問式推理；它不會實際執行募資、更新財務模型、修改 roadmap，或建立可靠的決策紀錄，除非你周邊的 agent 設定支援這些動作。
新手容易上手嗎？
算是中等容易。Invocation syntax 很簡單，但當使用者理解「角色回答」與「整合後決策」的差異時，輸出品質會好很多。新手可以先要求 skill 解釋它的路由選擇：
「Use chief-of-staff. First state which role or roles you are routing to and why, then provide the synthesized recommendation.」
這有助於確認 skill 沒有把每個問題都過度升級成董事會議。
什麼時候不該使用這個 skill？
當你需要的是單一專家的答案、快速內容草稿、coding task，或純事實查詢時，應避免使用 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 有真正的決策可以分類。
加入目前的指標基準，以及判斷錯誤會造成的後果。Runway 是 6 個月還是 24 個月，會改變 CFO 的回答。流失是因為缺功能，還是 onboarding 做得不好，也會改變 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 一致：最高價值的輸出應是一個整合後的決策，包含共識、衝突、缺口、優先行動，以及一個清楚的決策點。
在第一次回答後持續迭代
拿到第一次輸出後，不要只是要求「more detail」。請提出有針對性的追問：
- 「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 從一次性的顧問，變成支援創辦人決策的可重複營運節奏。