| name | triz-scoping |
| description | TRIZ Step 0 問題定向。使用 5Why、KT Is/IsNot、CECA 從症狀挖掘到可操作的因果節點，確定子系統和 TC 假設。Use when a problem symptom needs root cause analysis before TRIZ contradiction resolution. |
TRIZ Step 0: 問題定向與邊界 (Problem Scoping)
Overview
本 skill 實作 Auto-TRIZ 閉環流程的 Step 0（Section 3 of docs/auto_triz_strategy.md）。
從問題症狀出發，透過三個子工具逐步收斂到可操作的因果節點，確定要分析的子系統和初步 TC 假設。
宣告： 「正在使用 triz-scoping skill — 執行 Step 0: 問題定向。」
輸入要求
| 必要輸入 | 定義 |
|---|
| 一個可描述的系統 | 至少能說出「誰對誰做了什麼」 |
| 至少一個「不滿意」 | 某指標不夠好 / 某副作用存在 / 某需求做不到 |
Phase 0a: 5 Why（必做 — 快速定向）
目的： 5 分鐘內從症狀挖到可操作的因果節點。
操作： 引導使用者逐層追問：
症狀：[使用者描述的問題]
Why 1: 為什麼 [症狀]？ → [原因 1]
Why 2: 為什麼 [原因 1]？ → [原因 2]
Why 3: 為什麼 [原因 2]？ → [原因 3]
Why 4: 為什麼 [原因 3]？ → [原因 4]
Why 5: 為什麼 [原因 4]？ → [根因假設]
停止條件：
- 到達可操作的因果節點（能改變的物理參數）
- 到達已知的物理限制
- 不需要一定問 5 次 — 3 次找到根因就停
限制： 5 Why 假設因果是線性的。TRIZ 矛盾往往是環狀因果，所以 5 Why 只能定向，不能定義矛盾。
產出：
- 要分析的子系統
- 初步根因假設
- 初步 TC 假設（如果已浮現）
Phase 0b: KT Is/Is Not（選配 — 有對照組時做）
前提： 需要對照組（好的 vs 壞的）。沒有對照組時跳過。
詢問使用者： 「是否有類似但不出問題的對照案例？（不同型號、不同產線、不同工況等）」
操作模板：
| 維度 | IS (有問題) | IS NOT (沒問題) | 獨特差異 |
|---|
| 什麼 (What) | 哪個產品/零件出問題？ | 哪個類似的沒問題？ | 差異 |
| 哪裡 (Where) | 問題在哪個位置？ | 哪些位置沒有？ | 位置條件 |
| 何時 (When) | 什麼時候開始？ | 什麼時候沒有？ | 時間變化 |
| 多嚴重 (Extent) | 問題的程度/頻率？ | 在什麼程度內正常？ | 閾值邊界 |
KT → OZ/OT 銜接：
Where IS vs IS NOT → OZ (操作空間)
When IS vs IS NOT → OT (操作時間)
獨特差異 → Px 候選清單
產出：
Phase 0c: CECA（根因仍模糊時啟用）
觸發條件： 5 Why + KT 後根因仍不明確。
CECA = Cause-Effect Chain Analysis：
- 列出所有已知的因果關係
- 畫因果鏈圖（允許分支和環路）
- 識別關鍵因果節點（多條鏈匯聚的節點）
- 對關鍵節點做 TC 假設
產出格式：
## CECA 因果鏈分析
### 因果關係清單
| # | 原因 | → | 結果 | 證據/來源 |
|:--|:-----|:--|:-----|:----------|
| 1 | {因} | → | {果} | {量測數據/觀察/推論} |
| 2 | {因} | → | {果} | {量測數據/觀察/推論} |
### 因果鏈圖
{原因 A} → {結果 B} → {結果 C}
↗
{原因 D} ─┘ ↘→ {最終症狀}
↗
{原因 E} → {結果 F} ─┘
（標記環路為 ⟳，標記匯聚節點為 ★）
### 關鍵節點識別
| 節點 | 匯入鏈數 | 匯出鏈數 | 可操作性 | TC 假設 |
|:-----|:---------|:---------|:---------|:--------|
| ★{節點名} | {N} | {M} | {高/中/低} | {改善 X vs 惡化 Y} |
### CECA 結論
- **關鍵因果節點**: {多條鏈匯聚的節點}
- **TC 假設**: {改善 X vs 惡化 Y}
- **路由建議**: {Step 1 / Step 2 / 喊停}
完成後 → 回到決策閘門重新判定路由
決策閘門
Phase 0a/0b/0c 完成後：
根因分析結果
│
├─ 根因已鎖定且是物理參數
│ └─ 跳至 Step 2 (TC 定義) — ⚠️ 跳步風險
│ 建議：解法產出後回補 Step 1 驗證完整性
│
├─ 根因涉及組件交互
│ └─ 進 Step 1 (功能建模) via /triz-model
│
├─ 根因仍模糊
│ ├─ 未做 CECA → 啟動 Phase 0c
│ └─ CECA 後仍無法收斂 → 建議喊停，重新定義問題
│
└─ 發現無矛盾（功能缺失）
└─ SF-only 快速通道 via /triz-solve --sf-only
完整產出
## Step 0 產出
### 5 Why 分析
- 症狀: [...]
- Why 1-N: [因果鏈]
- 根因假設: [...]
### KT Is/Is Not（如適用）
| 維度 | IS | IS NOT | 獨特差異 |
|------|-------|---------|---------|
| What | [...] | [...] | [...] |
| Where | [...] | [...] | [...] |
| When | [...] | [...] | [...] |
| Extent | [...] | [...] | [...] |
### 結論
- **子系統**: [識別的子系統]
- **根因假設**: [可操作的因果節點]
- **TC 假設**: [改善 X vs 惡化 Y]（如已浮現）
- **OZ 候選**: [位置]（如 KT 已做）
- **OT 候選**: [時間]（如 KT 已做）
- **路由**: Step 1 / Step 2 (跳步) / SF-only / CECA / 喊停
狀態更新
完成後執行兩件事：
1. 更新 state JSON
更新 .claude/context/triz/.triz-state.json 的 step0 區段：
{
"step0": {
"completed": true,
"root_causes": ["根因 1", "根因 2"],
"tc_hypothesis": "改善 X vs 惡化 Y",
"subsystem": "子系統名稱",
"oz_candidates": ["位置 1"],
"ot_candidates": ["時間 1"],
"routing": "step1 | step2-skip | sf-only | ceca | stop"
}
}
2. 追加寫入 session 報告檔
從 .triz-state.json 讀取 report_file 路徑，用 Read tool 讀取報告檔現有內容，再用 Write tool 將以下 Step 0 區段追加到報告檔末尾：
## Step 0: 問題定向
### 5 Why 分析
| 層級 | 問題 | 原因 |
|:-----|:-----|:-----|
| 症狀 | {使用者描述} | — |
| Why 1 | ... | {原因} |
| ... | ... | ... |
- **根因假設**: {根因}
### KT Is/Is Not（如適用）
| 維度 | IS | IS NOT | 獨特差異 |
|:-----|:---|:-------|:---------|
| ... | ... | ... | ... |
### CECA 因果鏈（如適用）
{因果鏈圖}
### Step 0 結論
- **子系統**: {子系統}
- **根因假設**: {根因}
- **TC 假設**: {改善 X vs 惡化 Y}
- **OZ 候選**: {位置}
- **OT 候選**: {時間}
- **路由**: {下一步}
---
下一步導引
Step 0 完成後，依路由結果提示使用者：
| 路由結果 | 提示 |
|---|
| step1 | 「Step 0 完成。根因涉及組件交互，建議進入功能建模。請執行 /triz-model 繼續。」 |
| step2-skip | 「Step 0 完成。根因已鎖定為物理參數，可跳至 TC 定義。請執行 /triz-solve 繼續。⚠️ 建議解法產出後回補 Step 1 驗證完整性。」 |
| sf-only | 「Step 0 完成。發現功能缺失無矛盾，進入 SF-only 快速通道。請執行 /triz-solve --sf-only 繼續。」 |
| ceca | 「5Why + KT 後根因仍不明確，啟動 CECA 因果鏈分析。」（自動執行 Phase 0c，不需使用者操作） |
| stop | 「根因無法收斂，建議暫停 TRIZ 流程，重新定義問題邊界。」 |
