ce-strategy

產品策略（Product Strategy）

注意：目前年份為 2026 年。 在策略文件上記述日期時請使用此年份。

ce-strategy 用於建立與維護 repo 根目錄下的 STRATEGY.md——這是一份簡潔且能長期指引方向的核心文件（與 README.md 並列於同級目錄），用來記錄產品是什麼、服務對象是誰、如何取得成功，以及團隊目前的資源投入方向。當上游存在這份文件時，下游 Skill（ce-ideate、ce-brainstorm、ce-plan）會將其作為定位基準與背景依據。

本文件特意設計得簡短且結構化。比起冗長的文字，針對少數幾個犀利問題做出優質解答，更能產出卓越的策略。本 Skill 會提出這些問題、挑戰不夠具體的回答，並負責撰寫這份文件。

互動方式（Interaction Method）

預設優先使用平台提供的阻塞式提問工具（blocking question tool）：Claude Code 中的 AskUserQuestion（若未載入 schema，先呼叫 ToolSearch 並帶入 select:AskUserQuestion）、Codex 中的 request_user_input、Antigravity CLI (agy) 中的 ask_question，或 Pi 中的 ask_user（需安裝 pi-ask-user 擴充套件）。僅有在環境中完全沒有阻塞式工具，或呼叫發生錯誤（例如 Codex 的編輯模式）時，才退回到在聊天中顯示編號選項——切勿只因為需要載入 schema 就直接退回。絕對不能默默跳過提問。

每次只問一個問題。對於實質內容章節（問題、方法、使用者畫像/Persona），優先採用開放式回答；單選題（single-select）僅留給流程路由決策（例如要重新檢視哪個章節）。每個選項標籤都必須語意完整且獨立。

焦點提示（Focus Hint）

焦點提示（focus hint） 指的是呼叫本 Skill 時傳入的任何選填引數——包含在當前提示詞或對話中，無論是使用者直接提供，或是由呼叫端 Skill 轉交（若未提供則為空值）。

請將任何引數解讀為選填的焦點：要重新檢視的章節名稱（metrics、approach、tracks）或範圍提示。若無傳入引數，則以開放方式進行，由現有檔案狀態來決定執行路徑。

核心原則（Core Principles）

1. 定錨而非規劃（Anchor, not plan）。 策略的核心是「產品是什麼」以及「為什麼要做」。具體功能應歸入 ce-brainstorm；時程安排則屬於 issue 追蹤系統。切勿讓這兩者混入策略文件中。
2. 嚴謹在於提問，而非標題（Rigor in the questions, not the headings）。 章節標題使用通俗平實的英文。而訪談提問才是貫徹策略嚴謹度的關鍵。
3. 精簡即是優勢（Short is a feature）。 範本受到嚴格限制。隨意新增章節所帶來的隱形成本比表面看起來更高。請抵制盲目擴充檔案內容的要求。
4. 跨執行週期持久有效（Durable across runs）。 本 Skill 支援多次執行。在第二次及後續執行時，會進行就地更新（update in place），保留現有有效內容，僅對看起來過時或軟弱無力的章節提出挑戰。

執行流程（Execution Flow）

階段 0：依檔案狀態路由（Route by File State）

使用原生的檔案讀取工具讀取 STRATEGY.md。

• 檔案不存在 -> 首次執行。前往階段 1。
• 檔案存在且引數指定了特定章節 -> 定向更新。前往階段 2。
• 檔案存在但未提供引數 -> 詢問使用者要重新檢視哪些章節，然後前往階段 2。

用一行文字宣告執行的路徑："Strategy doc not found - let's write it." 或 "Found existing strategy - let's review and update."

階段 1：首次執行訪談（First-Run Interview）

讀取 references/interview.md。此載入步驟為必選——挑戰規則（pushback rules）、反面模式範例（anti-pattern examples）以及各章節的品質標準均定義於該檔案中。憑記憶即興發揮只會產出被動的逐字紀錄，而非真正的策略文件。

按照最終文件的章節順序進行訪談：

1. 目標問題（Target problem）
2. 我們的切入方法（Our approach）
3. 服務對象（Who it's for）
4. 關鍵指標（Key metrics）
5. 發展主線（Tracks）
6. 里程碑（Milestones，選填）
7. 暫不處理的事項（Not working on，選填）
8. 行銷策略（Marketing，選填）

針對每個章節，提出引導問題、套用挑戰規則（pushback rules），並用使用者自己的語言記錄最終答案。切勿跳過挑戰步驟——這是本 Skill 的核心精髓。每個章節最多進行兩輪追問挑戰；之後若使用者仍未調整，即記錄使用者現有的回答，並註記該章節值得在下次執行時重新審視。

當所有必要章節（1-5）都記錄完成後，讀取 references/strategy-template.md，填入內容，並在寫入檔案前於對話中展示完整草稿。提供一輪修改機會。最後寫入 STRATEGY.md。

階段 2：更新執行（Update Run）

仔細讀取現有的 STRATEGY.md。用 3-5 行摘要目前狀態，讓使用者清楚瞭解現有檔案內容。

若引數指定了特定章節，直接跳至 references/interview.md 中的該章節。精確保留所有其他章節。比照首次執行的標準進行挑戰——絕不能只因為內容已經寫在檔案裡就盲目背書弱勢內容。

若未指定特定目標，使用阻塞式提問工具詢問使用者要重新檢視哪個章節。選項如下：

• "Target problem"
• "Our approach"
• "Who it's for"
• "Metrics, tracks, or other"

針對每個重新檢視的章節，進行完整帶有追問挑戰的重新訪談。對於使用者確認依然準確的章節，保持原封不動。將 YAML frontmatter 中的 last_updated 數值更新為今天的 ISO 日期。

將更新後的內容寫回 STRATEGY.md。

階段 3：下游交接（Downstream Handoff）

寫入完成後，用一行文字說明檔案儲存位置，並告知 ce-ideate、ce-brainstorm 與 ce-plan 將在下次執行時將其作為定位基準與背景依據。

若此 repo 尚未執行過任何下游 Skill，可建議使用者將 ce-ideate 或 ce-brainstorm 作為下一步。

本 Skill 不會做的事（What This Skill Does Not Do）

• 不會更新 issue 追蹤系統或比對進行中的工作。策略是文件；執行屬於其他流程。
• 不會排定 Backlog 優先順序。優先順序編排屬於獨立的工作流程。
• 不會撰寫產品需求文件（PRD）或實作計畫——這些是 ce-brainstorm 與 ce-plan 的職責。
• 不會計算指標數值。本 Skill 只記錄哪些指標重要以及其資料來源，不記錄當前的具體數值。

延伸學習（Learn More）

「目標問題 / 我們的切入方法 / 發展主線」的結構受 Richard Rumelt 的著作《好策略・壞策略》（Good Strategy Bad Strategy）所啟發——特別是他提出的精髓三要素：診斷（diagnosis）、指導方針（guiding policy）與協調一致的行動（coherent action）。references/interview.md 中的訪談提問旨在突破他所定義的「壞策略」陷阱：空洞的口號、包裝成策略的目標，以及用功能清單取代指導性抉擇。若您對「口號」與「策略」之間的差異尚不夠清晰，強烈推薦閱讀本書。