idd-issue: 加入 multi-finding source 的 triage 機制（避免每筆 finding 手動分 create/update/comment/edit）

## Problem

> **Original (user, 2026-05-10 session)**:
> 「idd-issue 有沒有「不另外建立issue但就update」的可能性」
>
> 對話脈絡：
> 「我發現根據逐字稿其實可以放idd-issue 或idd-update」
> 「這個改動我覺得要納入idd的方法論」

讀 transcript / source document / 老師回饋之類的多 finding 來源時，**有些 findings 該開新 issue、有些該 update 既存 issue**。目前的 IDD 工具集要求使用者**事先 triage 每個 finding**：

- 對應到 existing #N 是新資訊／補充細節 → `/idd-comment #N`
- 對應到 existing #N 但要覆寫假設或 strategy → `/idd-edit #N`
- 對應到 existing #N 但只是進度推進 → `/idd-update #N`
- 是全新主題 → `/idd-issue`

問題：使用者必須**先讀完 source 並分類**才知道要呼叫哪個 skill；有時讀到一半才發現某 finding 其實對應到 #N 而非新主題；或是 finding 之間互相影響該 split / merge。

## Why it matters

實務情境（本 session 的 Lesley research project 就是案例）：

- 09:48 開始的 session 處理 04-14 transcript → 直接用 `/idd-issue` 建 #1-#11（all new）
- 10:05 處理 05-03 transcript → 接續建 #12-#22（mix of new + amendments to #6/#8 etc.）
- 15:32 amend session 用 `gh api PATCH` 手動 update #6 #8 #12 #14 #17（**因為 idd-issue 不支援 update**）
- 接下來 05-09 transcript 還有更多 findings 等處理

當 source 跨多個既存 issue + 新主題時，使用者需要在腦中維護「finding → 哪個 skill」的 dispatch table。**這個 cognitive overhead 讓 transcript-driven workflow 反覆中斷**。

## Type

enhancement (methodology-level)

## Suggested approaches

三個方向，從輕到重：

### 方向 A: 新增 `idd-triage` skill（推薦 first step）

新建 `/idd-triage <source-file-or-text>` skill，職責：

1. 讀 source（transcript / docx / pasted text）
2. `gh issue list --state all --limit 50` 抓 repo 既存 issues 摘要
3. AI 對每個 finding 提案分配：
   ```
   Finding 1 → /idd-comment #15 (Schultz 量表細節補充)
   Finding 2 → /idd-edit #14 (推翻原 hypothesis)
   Finding 3 → /idd-issue 新建 (transcript 提的 reputation 新概念)
   Finding 4 → /idd-update #17 (conjoint 進度推進)
   Finding 5 → ambiguous（list of options）
   ```
4. AskUserQuestion confirm 每個 finding 的 routing
5. 使用者 confirm 後**批次**執行對應 skill 呼叫

這個 skill 是 **orchestrator pattern**（同 `idd-all`），不取代 atomic skills，而是包它們。

### 方向 B: 在 idd-issue 加 `--or-update` flag

```bash
/idd-issue --or-update "...transcript chunk..."
```

行為：先掃 existing issues，若 finding 強匹配某 #N → AskUserQuestion 要新建還是 update（轉呼叫 idd-comment / idd-edit）。

**缺點**：把「create」skill 和「update」skill 的邊界模糊化，違反 single-purpose 設計（current working 哲學是「每個 skill 對應一個明確 audit footprint」）。

### 方向 C: 純文件化（references/ 新增 canonical pattern）

不加新 skill / flag，只在 `references/transcript-driven-workflow.md` 寫清楚：

> 處理 multi-finding source 時，先 read → triage（per-finding 分類）→ 用對應 skill。建議流程：...

**優點**：成本最低、不擴張 skill 表面。
**缺點**：使用者每次都要重新走一次 mental triage，沒解決 cognitive overhead。

## Recommendation

走 A → 比 C 更實用，比 B 更乾淨。先 ship `idd-triage` 試水溫，若使用者 retention 高再考慮 vs C 文件化的 dual delivery。

關鍵設計問題（diagnose 階段要決定）：

1. `idd-triage` 是否該自己寫 finding 出 issue，還是只 print「建議呼叫的 skill 序列」讓使用者 copy-paste？
2. AI 的 finding extraction 失準率（漏掉、重複、誤分類）容忍度？需要 vs `idd-issue` 的 attachments / sister sweep 機制等同的 audit trail？
3. 與 existing `idd-all` orchestrator 關係 — 是否合併？還是兩個 orchestrator 各管不同 trigger？
4. 跟 `idd-list`（v2.51.0 新加的 issue listing skill）的 reuse opportunity — 那個 skill 已有 PR/cluster detection 的 issue 摘要能力。

## Impact

| 沒這個 feature | 有這個 feature |
|--------------|--------------|
| Multi-finding source 必須手動分 N 次 triage + invoke | 一次 `/idd-triage` → batch routing |
| 使用者偶爾把該 update 的 finding 誤建為新 issue（後來才 close 重複）| AI 預先掃 existing issue 降低誤判 |
| 「我之前是不是已經建過類似 issue」這個問題 → 手動翻 GitHub | AI 自動匹配並提示 |

## Related

- 本 session 對話（2026-05-10 17:xx Lesley research）
- 2026-05-09 amend session 手動跑 `gh api PATCH` 5 次的 friction
- v2.51.0 新增的 `idd-list` skill（reuse 機會）
- `idd-all` orchestrator pattern（同類設計參考）


## Case study: Lesley project transcript-driven workflow（2026-05-09 / 05-10）

實際 friction trace：

| 時點 | Action | Skill 用對了嗎 | Notes |
|------|--------|---------------|-------|
| 2026-05-09 09:48 | 04-14 transcript → `/idd-issue` 建 #1-#11 | ✅ all-new — `idd-issue` 適用 | Greenfield issue creation |
| 2026-05-09 10:05 | 05-03 transcript → `/idd-issue` 建 epic #12 + children #13-#22 | ⚠️ partial — 其中部分 finding 應該是 amend #6/#8 而非新建 | 但當時手動分流 finding 太累，全部當新主題 |
| 2026-05-09 15:32 | Amend #12 #17 #6 #8 #14 — **手動跑 `gh api PATCH`** 5 次 | ❌ 沒有現成 skill 可用 | `idd-edit` 可以但要 5 次 invoke + 各自 audit；`gh api PATCH` 直接寫但失去 audit trail |
| 2026-05-09 17:00 | 0509 transcript 處理 → 此時 ask `idd-issue 有沒有 update 模式` | ❌ 已感受到 cognitive overhead | This issue 誕生 |
| 2026-05-10 ongoing | 0509 transcript 還沒處理 | TBD | 等本 enhancement 進 backlog |

**Concrete waste**：amend session 5 次 PATCH 各約 30 秒 = 2.5 分鐘 + 失去 idd-edit 的 audit trail（comment timeline 看不到 `## Implementation Plan` 結構化記錄）。隨 transcript 數量增加 amplify。

**為什麼不直接用 idd-edit 5 次？** 當時 invocation chain 已經很深（idd-all → idd-implement → idd-verify → idd-close），加 5 個 idd-edit 會破壞 IDD pipeline 的 single-issue focus。`idd-triage` 的設計值就在「pre-pipeline batch 處理 multi-finding source」這個 phase。

## Implementation sketch（/idd-triage SKILL.md outline）

非正式 spec — diagnose 階段再 firmup。

```
# /idd-triage — Multi-finding source triage

## 核心原則
> 多 finding source 的 routing decision 是 batch 工作，不該每筆 invoke 一次 atomic skill。

## Configuration
同既有 IDD plugins（target resolution, walked-up config）

## Execution

### Step 0: Bootstrap stage TaskList（強制）

### Step 0.5: Target repo resolution（reuse idd-issue Step 0.5）

### Step 1: Read source
- Source adapter（reuse idd-issue Step 1 source-type matrix）
- Output: list of "raw findings"（AI extract，每筆 1-3 句描述 + 對應原文 quote）

### Step 2: Fetch existing issues
- gh issue list --state open --limit 50
- gh issue list --state closed --limit 30 (recent 30 days, optional)
- Build issue summary index: { #N → {title, body[:300], labels, state, last_activity} }

### Step 3: AI per-finding triage
對每個 finding，AI 提案：

- match_type ∈ {NEW, COMMENT_TO #N, EDIT #N, UPDATE #N, AMBIGUOUS}
- target_issue: #N or null
- confidence: HIGH / MEDIUM / LOW
- reasoning: 為什麼匹配到 #N（keyword overlap / topic match / explicit reference）
- proposed_action: gh issue create / gh issue comment / gh issue edit / Skill(idd-update) call

Output: structured triage table

### Step 4: AskUserQuestion confirm（batch）
顯示完整 triage table，AskUserQuestion 4-option per finding：
1. apply as proposed
2. change routing（new sub-question per finding）
3. skip this finding
4. merge with another finding

支援 bulk apply（如「全部 confidence=HIGH 的照辦」）

### Step 5: Dispatch
- NEW → Skill(idd-issue) per finding
- COMMENT_TO #N → gh issue comment
- EDIT #N → gh issue edit (with PATCH-and-preserve semantics)
- UPDATE #N → Skill(idd-update)

### Step 6: Audit trail report
print 完整 dispatch result + 每個 action 的 URL + 預期下一步（idd-diagnose / idd-close 等）

## 與既有 skill 的關係
- 不取代 idd-issue / idd-comment / idd-edit / idd-update
- Orchestrator pattern（同 idd-all）
- 失敗時 fallback 是「列出 routing table 讓使用者手動 invoke」
```

**關鍵 design 決定（延到 diagnose 階段）**：

1. AI extract findings 的 granularity — 一段話 1 finding？還是 1 sentence 1 finding？太細 = 噪音，太粗 = 漏東西
2. Existing-issue match 的 confidence threshold — HIGH 自動 dispatch / MEDIUM 問 / LOW 改建新？
3. Audit trail 的 source-of-truth — triage report 寫到哪裡？建立一個「meta-issue」追蹤本次 triage？還是只在 dispatched 各 issue 加 comment？
4. 跟 `idd-list`（v2.51.0）的 reuse — 那個 skill 已能 fetch + format issue list with PR/cluster info，可以當 Step 2 的 building block



### Linked-Context Siblings Filed (v2.48.0+ #529)

(none — body draft + recent session conversation 無 orphan sibling markers; 4 design questions in body 已 explicit 列為 in-scope diagnose follow-ups)

---

## Current Status

**Phase**: diagnosed
**Last updated**: 2026-05-10 by idd-diagnose

### Key Decisions
- User selected Strategy A (新 /idd-triage skill) at idd-issue stage
- Complexity = Spectra (Layer 2 + Layer 3 三條全中)
- Vagueness V1=3 V4=3 not triggered
- Sister concern surfaced 1 candidate → filed #49 (close-reason archaeology for #37)
- Routing: spectra-discuss (default; 4 design questions 全未決)

### Blocking
- (none)

### Diagnosis
- https://github.com/PsychQuant/issue-driven-development/issues/48#issuecomment-4413850520

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

idd-issue: 加入 multi-finding source 的 triage 機制（避免每筆 finding 手動分 create/update/comment/edit） #48

Problem

Why it matters

Type

Suggested approaches

方向 A: 新增 `idd-triage` skill（推薦 first step）

方向 B: 在 idd-issue 加 `--or-update` flag

方向 C: 純文件化（references/ 新增 canonical pattern）

Recommendation

Impact

Related

Case study: Lesley project transcript-driven workflow（2026-05-09 / 05-10）

Implementation sketch（/idd-triage SKILL.md outline）

Linked-Context Siblings Filed (v2.48.0+ #529)

Current Status

Key Decisions

Blocking

Diagnosis

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

沒這個 feature	有這個 feature
Multi-finding source 必須手動分 N 次 triage + invoke	一次 `/idd-triage` → batch routing
使用者偶爾把該 update 的 finding 誤建為新 issue（後來才 close 重複）	AI 預先掃 existing issue 降低誤判
「我之前是不是已經建過類似 issue」這個問題 → 手動翻 GitHub	AI 自動匹配並提示

時點	Action	Skill 用對了嗎	Notes
2026-05-09 09:48	04-14 transcript → `/idd-issue` 建 #1-#11	✅ all-new — `idd-issue` 適用	Greenfield issue creation
2026-05-09 10:05	05-03 transcript → `/idd-issue` 建 epic #12 + children #13-#22	⚠️ partial — 其中部分 finding 應該是 amend #6/#8 而非新建	但當時手動分流 finding 太累，全部當新主題
2026-05-09 15:32	Amend #12 #17 #6 #8 #14 — 手動跑 `gh api PATCH` 5 次	❌ 沒有現成 skill 可用	`idd-edit` 可以但要 5 次 invoke + 各自 audit；`gh api PATCH` 直接寫但失去 audit trail
2026-05-09 17:00	0509 transcript 處理 → 此時 ask `idd-issue 有沒有 update 模式`	❌ 已感受到 cognitive overhead	This issue 誕生
2026-05-10 ongoing	0509 transcript 還沒處理	TBD	等本 enhancement 進 backlog

idd-issue: 加入 multi-finding source 的 triage 機制（避免每筆 finding 手動分 create/update/comment/edit） #48

Description

Problem

Why it matters

Type

Suggested approaches

方向 A: 新增 idd-triage skill（推薦 first step）

方向 B: 在 idd-issue 加 --or-update flag

方向 C: 純文件化（references/ 新增 canonical pattern）

Recommendation

Impact

Related

Case study: Lesley project transcript-driven workflow（2026-05-09 / 05-10）

Implementation sketch（/idd-triage SKILL.md outline）

Linked-Context Siblings Filed (v2.48.0+ #529)

Current Status

Key Decisions

Blocking

Diagnosis

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

方向 A: 新增 `idd-triage` skill（推薦 first step）

方向 B: 在 idd-issue 加 `--or-update` flag