Fermi Estimation

• Trigger examples: "用費米估計幫我算每天百萬請求大概要多少客服人力。", "幫我粗估這個 AI 服務需要多少 GPU。"
• Expected result: 將流量、轉換率、峰值、處理能力拆開估，輸出低中高三組結果與敏感因子。

3. 檢查敘述是否在量級上合理

• Trigger examples: "這個展覽一天會有 50 萬人流合理嗎？", "請用費米問題驗證這個市場規模說法。"
• Expected result: 先找上界、下界與關鍵限制，判斷該說法在量級上是否站得住腳。

Workflow overview

1. 先判斷題目是否真的適合費米估計，若不適合就明確拒答。
2. 定義估算目標、單位、地理範圍與時間範圍。
3. 把目標拆成多個可估的子問題或因子。
4. 為每個因子提供最可能值，並補樂觀估計與悲觀估計作為邊界。
5. 組合運算，算出中心值，以及由樂觀/悲觀情境形成的上下界。
6. 用替代路徑、已知常識或物理上限做 sanity check，必要時調整假設。
7. 以清楚結構回覆結果、敏感因子、限制與不確定性。

Communication notes

• User vocabulary: 粗估、大概多少、量級、費米問題、費米估計、拆解估算、back-of-the-envelope、order of magnitude。
• Avoid jargon: 把 sanity check 說成「合理性驗證」，把 order of magnitude 說成「數量級」，把 anchor 說成「錨點資料」。
• Least-surprise rule: 使用者期待看到的是可追溯的假設與計算，不是直接丟一個數字；若題目不適合費米估計，必須直接說明而不是硬算。

Routing boundaries

• Neighboring skills / workflows:
  • web-search-strategy: 任務核心是找最新官方數字、法規或精確事實時交棒。
  • knowledge-framework: 使用者是要套分析框架，而不是估算未知量時交棒。
  • spec-organizer: 已經得到粗估結果，接下來要整理成開發或執行規格時交棒。
• Negative triggers:
  • "幫我查 2025 年台灣出生人口官方數字。"
  • "解這題微積分。"
  • "直接告訴我這家公司最新市值。"
  • "我要投資決策用的精準財務預測。"
• Handoff rule: 一旦答案可以且應該透過直接查證得到，或任務對精度要求高於粗估可接受範圍，就停止費米估計並改用查證或其他更適合的工作流。

Language coverage

• Primary language(s): 繁體中文，次要支援英文方法名與中英混寫請求。
• Mixed-language trigger phrases: Fermi estimate、Fermi problem、rough estimate、back-of-the-envelope、order of magnitude、sanity check。
• Locale-specific wording risks:
  • 「估算」有時其實是在要精準預測，需先確認容許誤差。
  • 「大概」不代表可以隨便猜，仍需拆解與說明假設。
  • 使用者提到「費米」但題目若可直接查到官方值，仍要指出不該硬用費米估計。

Success criteria

Quantitative (targets)

• Trigger accuracy: 至少 90% 的明顯粗估 / 量級估算需求能命中。
• Output completeness: 100% 包含目標定義、因子拆解、假設、計算、範圍與驗證。
• Tool calls: 一般案例 0-4 次；只有在補最小必要錨點資料或驗證現實約束時才增加。
• Failures: 0 次把粗估包裝成精確事實；0 次在明顯不適用時硬做費米估計。

Qualitative

• 若某個因子無法合理估，就會繼續細分而不是直接亂猜。
• 會清楚標示哪些是已知錨點、哪些是推論假設、哪些是不確定範圍。
• 會提供最可能值，以及樂觀/悲觀兩端情境形成的區間。
• 能用第二條估算路徑或常識邊界檢查結果是否離譜。

Instructions

使用 references/output-template.md 的段落順序作為預設輸出骨架，交付前對照 references/quality_checklist.md 自檢。

Global rules

• 先判斷「這題是否真的該用費米估計」，不要因為使用者提到費米就無條件套用。
• 如果能查到且應該查到精確值，直接指出用費米估計是錯的方法，並婉拒用本 skill 作答。
• 可以補少量穩定錨點資料，但不把整題改成大量研究；此 skill 的核心仍是拆解與估算。
• 每個重要假設都要附上來源類型或理由，例如日常經驗、公開常識、場景上限、保守中性值。
• 如果某個參數無法提出合理值，先再拆一層；若仍無法合理化，就停止並說明此題不適用。

Step 0: Confirm inputs

• Read the existing conversation/files first; ask follow-up questions only when a wrong assumption would materially change the outcome.
• 至少確認以下資訊：
  • 要估算的目標值是什麼
  • 單位是什麼
  • 地理範圍與時間範圍是什麼
  • 使用者要的是粗估範圍、中心值，還是合理性檢查
• 若題目其實是最新官方數字、精確查詢或正式數學求解，直接回覆不適合費米估計並停止。

Step 1: Define the target clearly

• 用一句話重寫問題，寫清楚估算標的、單位與時間尺度。
• 先決定輸出要回答的是「總量」「速率」「容量」「家數」「人力」還是「是否合理」。
• 若地理或時間範圍模糊，先用最少必要假設補上，並明講是假設。

Step 2: Decompose into solvable factors

• 把大問題拆成 3-7 個可估因子，優先使用乘法鏈、加總、流量平衡或供需拆法。
• 每個子問題都必須與目標值有清楚邏輯關聯。
• 若拆完仍有模糊黑箱參數，繼續細分，直到每個因子都能被合理估。

Step 3: Assign assumptions and ranges

• 對每個因子給：
  • 最可能值
  • 樂觀估計
  • 悲觀估計
  • 理由
• 優先使用中性估計，不故意極端保守或極端樂觀。
• 先判斷該題的樂觀情境與悲觀情境分別對結果造成什麼方向的影響，再把兩者映射成結果的下界與上界；不要預設樂觀一定較大或較小。
• 若有少量穩定錨點資料可查，先做最小必要查核並明示哪些因子來自查核。

Step 4: Combine the numbers

• 清楚列出公式，不要只給最後答案。
• 至少算出一組中心值，並用樂觀/悲觀情境推得結果區間。
• 單位要在每一步都一致，避免人數、戶數、天數、次數混用。

Step 5: Validate and adjust

• 用至少一種方式做合理性驗證：
  • 換一條估算路徑
  • 用物理或營運上限檢查
  • 與常識量級比對
• 若中心值與驗證結果衝突，回頭調整最敏感的假設，並說明為什麼改。

Step 6: Final answer structure

• 最終回覆至少包含：
  • 題目是否適合費米估計
  • 問題定義與單位
  • 因子拆解
  • 假設表或條列
  • 計算過程
  • 最可能值，以及由樂觀/悲觀情境形成的上下界
  • 驗證與敏感因子
  • 侷限與注意事項
• 如果題目不適用，明確說明不適用原因，不要硬算。

Step 7: Finalization and QA

• 對照 references/output-template.md 檢查輸出是否完整。
• Validate outputs against the checklist in references/quality_checklist.md
• Run python ..\\skill-creator-advanced\\scripts\\format_check.py .
• Run python ..\\skill-creator-advanced\\scripts\\quick_validate.py .

Testing plan

Triggering tests

• Should trigger:
  • "請用費米估計估算台北市大概有多少家早餐店。"
  • "幫我粗估這個 AI 產品每天百萬請求需要多少客服人力。"
  • "用 Fermi estimate 幫我判斷這個市場規模說法合不合理。"
  • "不要查現成統計，請把這個問題拆成費米問題來估。"
• Should NOT trigger:
  • "幫我查台灣 2025 年出生人口官方數字。"
  • "幫我解這題線性代數。"
  • "直接查這家公司的最新年營收。"
  • "我要能拿去送審的工程精算。"
• Near-miss / confusing cases:
  • 使用者說「估算」但其實是要官方數字，此時必須拒絕用費米估計。
  • 使用者說「費米問題」但題目是純數學唯一解，不應誤觸發。
  • 題目雖是粗估，但若缺少地理或時間範圍，需先補最小必要假設。

Functional tests

• Test case: 城市早餐店數量估算

  • Given: 使用者要估某城市大概有多少家早餐店，且不要求精確統計
  • When: 啟動本 skill
  • Then:
    • 會先定義城市範圍與時間尺度
    • 會拆成人口、消費頻率、店家服務能力等因子
    • 會給出最可能值，以及樂觀/悲觀上下界

• Test case: 系統資源需求粗估

  • Given: 使用者要粗估高流量服務所需人力或機器資源
  • When: 啟動本 skill
  • Then:
    • 會拆出總流量、峰值、處理時長與單位產能
    • 會指出最敏感假設
    • 會用樂觀/悲觀情境與替代路徑做 sanity check

• Test case: 量級合理性檢查

  • Given: 使用者要驗證某個客流量、銷量或市場規模敘述是否合理
  • When: 啟動本 skill
  • Then:
    • 會優先找上界與限制條件
    • 會回覆「合理 / 偏高 / 偏低」及原因

• Test case: 不適用題型拒答

  • Given: 使用者要求最新官方統計或有唯一正解的數學題
  • When: 啟動本 skill
  • Then:
    • 會直接說明這不是費米估計適用題型
    • 不會硬湊估算流程

Performance comparison (optional)

• Baseline (no skill): 常見失敗是直接憑感覺丟單一數字、沒有拆解假設、沒有範圍，也沒有驗證。
• With skill: 會強制做適用性判斷、拆解、假設說明、範圍估算與合理性檢查，降低亂猜風險。

ROI guardrail

• Quality gain must justify extra:
  • Time: 只有在能明顯提升粗估可追溯性與可信度時，才值得多做拆解與驗證。
  • Tokens: 不把回覆寫成百科；只保留會影響結果的因子、假設與驗證。
  • Maintenance burden: 常用輸出結構與檢查規則放在 references/，避免主流程膨脹。

Regression gates

• Minimum pass-rate delta: +0.08
• Maximum allowed time increase: 25s
• Maximum allowed token increase: 4000
• Maximum under-trigger failures: 1 / eval batch
• Maximum over-trigger failures: 1 / eval batch

Feedback loop

• Common failure signals:
  • 直接報答案，沒有拆解與假設
  • 因子估值過度武斷，沒有理由
  • 不提供樂觀/悲觀上下界，只給單點值
  • 沒有 sanity check
  • 對明顯不適用題型沒有拒答
• Likely fix:
  • 收緊 description 中對粗估、量級、費米問題的 trigger wording
  • 補強 references/output-template.md 對樂觀/悲觀/最可能三組假設與驗證段落的要求
  • 在 assets/evals/evals.json 增加拒答與合理性檢查案例

Eval workflow

• Save approved prompts to assets/evals/evals.json
• Define release thresholds in assets/evals/regression_gates.json
• 若此 skill 與 skill-creator-advanced 工具鏈一起維護，可沿用共用 eval workspace 流程準備 paired runs。
• If the environment supports subagents or parallel workers, launch with-skill and baseline runs in the same batch
• After runs complete, aggregate results and generate a review viewer
• 若此 skill 與 skill-creator-advanced 工具鏈一起維護，可沿用共用 regression gates 檢查發版門檻。

Distribution notes

• Packaging: 由宿主或 registry 的標準 SKILL 發佈流程處理；若在本 repo 維護，再使用 repo 根目錄的打包腳本。
• Repo-level README belongs outside this skill folder.

Troubleshooting

• Symptom: 回答只有一個數字，看不出怎麼來的。

  • Cause: 沒有遵守拆解與假設揭露流程。
  • Fix: 回到 Step 2 與 Step 3，重新列出因子、假設與公式。

• Symptom: 估值很飄，無法判斷是否合理。

  • Cause: 關鍵因子拆得不夠細，或沒有提供上下界。
  • Fix: 再細分最敏感的因子，補低中高三組值與理由。

• Symptom: 明明能查到官方值，卻還在做費米估計。

  • Cause: 適用性判斷失敗，誤把查證題當成粗估題。
  • Fix: 依 Step 0 直接拒絕用本 skill 作答，改交棒給研究流程。

Resources

• references/output-template.md
• references/quality_checklist.md
• assets/evals/evals.json
• assets/evals/regression_gates.json