feat: auto-@mention when idd-issue/idd-comment poses open question to a person (diagnose excluded)

[kiki830621]

Problem

Original text:
「如果要問一個人問題，要在問題上自動tag他吧（diagonose除外，所以你要知道使用電腦的人是哪一個使用者）我不知道要不要另外設定一個idd，然後要有勾選清單可以給對方勾 或者是請對方回覆嗎？」
— Source: kiki830621 在 teaching/20260317_Liu/ 跑 /idd-comment workflow 後立即提出 (2026-05-21)

當 IDD lifecycle 的某個 step 本質上是向特定人提問時（典型例子：idd-comment --type=question 留 open question、idd-issue 收到 description 含「請 X 確認」、idd-close 把球丟給 collaborator 確認結果），skill 應該預設自動 @-tag 那個人，而不是等使用者每次手動下 --mention <login> flag。實戰案例：剛剛在 kiki830621/collaboration_liu-thesis-analysis#25 留了一則 type=note comment，body 含一段 ### Open question（需我這邊回覆確認） 直接問 HsuanYuLiuuu「Exp3 MS-as-covariate 是不是要等 #24 merge」，但 comment 沒 @-tag 她——她不會主動收到通知，這則 open question 就靜默躺在 issue 裡，跟 PR #23 卡 21 天沒 review 完全一樣的失敗模式（GitHub 沒 explicit ping 就不會通知人，工序漏斗在 IDD 流程上重演）。

唯一的例外是 idd-diagnose —— diagnose 是 AI 內部的 root cause analysis / 設計選項枚舉，產出對象是同一個操作者（kiki830621 自己），tag 自己沒意義也增加 inbox 雜訊。所以 auto-tag 規則不能無腦套用到所有 step，需要分流。

這引出一個 prerequisite：skill 必須知道「當前操作電腦的人是誰」（GitHub login），才能判斷「被問的人 ≠ 操作者」，避免自己 tag 自己。這部分已經有 #86 在處理 collaborator config schema，但「current operator」這個概念在 #86 也只是當作 role: maintainer 列在 collaborators 內，沒有獨立的 resolution mechanism（也許用 gh api user --jq .login 即時抓 + cache）。

Type

feature

Expected

A. Auto-mention 觸發規則

Lifecycle step	Auto-mention 行為	Whom to tag
idd-issue	若 body 含「請 X 確認」/「ask X」/「@x 你看」/ --ask <login> flag → auto-resolve + auto-tag X	被點名的人，不含 operator
idd-comment --type=question	永遠 auto-tag 該 issue 的相關 collaborator（assignee / requestor / 上一則 phase comment 的 author / 從 conversation 推斷的對象）	由 AI 選 1-2 個最相關，列在 confirmation prompt 讓 operator 確認
idd-comment --type=decision 含 follow-up question	把含 question 那段 quote 出來 + auto-tag	同上
idd-close	若 closing summary 提到「等 X 回」/「pending Y review」→ auto-tag	被等待的人
idd-implement complete comment	若 PR 需要 reviewer → auto-tag PR reviewer	reviewers 名單
idd-verify	若 verify FAIL 且需要 collaborator 補資料 → auto-tag	data owner
idd-diagnose	永不 auto-tag	n/a
idd-update / idd-edit / idd-list 等純 metadata sync	不 tag	n/a

B. Operator identification

• skill 啟動時抓 gh api user --jq '.login' 並 cache 到 session 變數 $IDD_OPERATOR_LOGIN
• 配合 feat: collaborator config in idd-config — record GitHub login, email, name, aliases for tagging accuracy #86 schema 的 collaborators array，AI 在挑 tag 對象時可以排除 github_login == $IDD_OPERATOR_LOGIN
• 若 feat: collaborator config in idd-config — record GitHub login, email, name, aliases for tagging accuracy #86 collaborators 沒設，fall back 到既有的 rules/tagging-collaborators.md 5-step protocol（gh api collaborators + fuzzy match + AskUserQuestion fallback），protocol 內加一條「skip $IDD_OPERATOR_LOGIN」

C. Response UX：checklist vs free-form reply（open design question）

User 在原文同時提出兩種交互 pattern：

1. 勾選清單：comment body 內嵌 GitHub task list 讓 collaborator 直接勾，例如：

   ## ❓ Open Question
   
   Exp3 中 MS 當 covariate 的分析是否要等 #24 merge?
   
   - [ ] (1) 等 #24 merge 後補 Exp3 列到既有 doc §3
   - [ ] (2) Exp3 不在 #25 scope，標示為 limitation
   - [ ] Other (請在底下 reply 補充)

   優點：collaborator 點兩下勾選即可，門檻最低、GitHub UI 渲染 checkbox 直接互動、選項收斂；缺點：選項要 AI 先抽出來才能放，open-ended 的問題沒法用 checklist。

2. Free-form reply：純文字 prompt 等 collaborator reply comment。優點：適合 open-ended；缺點：collaborator 可能拖 / 沒看到 / 沒回覆，且 reply 後 AI 要 detect「她回了什麼 = 對應哪個選項」的 NLP 成本不低。

初步設計建議（待討論）：

• 兩種並存而不二選一。idd-comment --type=question 加 --options "a; b; c" flag 觸發 checklist mode；不帶 --options → free-form mode。
• Checklist mode 的選項 AI 可以從 body prose 自動抽（題目 + 「兩種可能」/「三個選項」這類連接詞）。
• 兩種 mode 都強制 auto-@tag（這是本 issue 的核心）。
• 後續可考慮 idd-poll #N skill 來 detect collaborator 在 checklist 上的勾選結果 + 自動更新 issue body Current Status。

D. 例外與 escape hatch

• --no-auto-mention flag override（CI / unattended 場景）
• IDD_NO_AUTO_MENTION=true env var 全 session 關閉
• AI 推斷 tag 對象有歧義 → AskUserQuestion 列候選人讓 operator 選（不靜默亂 tag）

Actual

• 目前 idd-comment --mention <login> 是 opt-in，operator 沒寫 flag 就不 tag
• rules/tagging-collaborators.md 5-step protocol 處理「已決定要 tag」的後續驗證 + fuzzy match，但**沒回答「該不該 tag」**的判斷邏輯
• 結果：含 open question 的 comment 經常忘記 tag，collaborator 不知道有問題在等她（HsuanYuLiuuu 案例）
• IDD 沒有 「current operator」的 stable identity handle —— 每個 skill 各自處理 mention 時都需要 ad-hoc 抓 gh api user，沒 cache 也沒 cross-skill share
• feat: collaborator config in idd-config — record GitHub login, email, name, aliases for tagging accuracy #86 collaborator config 涵蓋「collaborator 是誰」但沒涵蓋「operator 是誰」

Impact

• 正面：消除 IDD comment / issue / close 階段的 silent question failure 模式（HsuanYuLiuuu reply 21 天 delay 那種等待）。Lifecycle-aware 規則避免無腦對所有 step 都 tag（diagnose 不擾人）。
• 負面：notification fatigue 風險 —— 跟 IDD comment 過多觸發 GitHub notification fatigue — human-only vs AI-only 分流? #116 的討論直接相關。若 auto-tag 規則設得太寬，每個 idd-comment 都 ping 對方，反而被忽略。所以 A 表的 step 分流非常重要：只在「真的需要對方回應」的 step 才 tag。
• 依賴：feat: collaborator config in idd-config — record GitHub login, email, name, aliases for tagging accuracy #86 collaborator config 是強 prerequisite，特別是 alias / role 欄位 —— 沒它就無法準確 resolve 「Hsu 老師」這類自然語言指涉到 @yungfonghsu-ui。
• 正交但相關：[bug] AI-generated comment 中的 @mention 可能繞過 tagging-collaborators 5-step protocol (sister concern from #116) #117 「AI mention 繞過 5-step protocol」是 sister bug，本 issue 的實作應該強化而非繞過 5-step protocol（auto-trigger 也要走完 5 步驗證）。

Related

• Prerequisite: feat: collaborator config in idd-config — record GitHub login, email, name, aliases for tagging accuracy #86 (collaborator config schema — 提供 GitHub login ↔ alias resolution)
• Sister bug: [bug] AI-generated comment 中的 @mention 可能繞過 tagging-collaborators 5-step protocol (sister concern from #116) #117 (AI @mention 繞過 5-step protocol — 本 feature 必須通過 protocol 而非繞過)
• Tradeoff context: IDD comment 過多觸發 GitHub notification fatigue — human-only vs AI-only 分流? #116 (notification fatigue — Step A 表的分流規則直接回應這個關切)
• Adjacent feature: feat: selective auto-tag at idd-issue baseline + idd-verify PASS milestones #85 (git tag automation at idd-issue baseline / verify PASS — 完全不同的「auto-tag」語意，命名衝突注意)
• Related skill: feature: /idd-ask skill — query GitHub issues knowledge base (mirror /spectra-ask) #72 (/idd-ask 是查 issue knowledge base，不是問人，命名 collision 警告：若這個 feature 變成 /idd-ask <login> skill，會跟 feature: /idd-ask skill — query GitHub issues knowledge base (mirror /spectra-ask) #72 撞名)

Open design questions（給 maintainer / community 討論）

1. Auto-tag 是 default-on 還是 opt-in？ 本 issue 主張 default-on（with --no-auto-mention escape），但 IDD comment 過多觸發 GitHub notification fatigue — human-only vs AI-only 分流? #116 fatigue 風險可能要求 opt-in。
2. 要不要另起 /idd-question 或 /idd-ask skill？ 還是塞進 idd-comment --type=question 的擴展？傾向後者（避免 skill 數量爆炸，per IDD anti-pattern），但 checklist mode 的複雜度可能值得獨立 skill。
3. Checklist 選項要 AI 自動抽，還是 operator 顯式提供？ 自動抽降低門檻但容易抽錯；顯式提供準確但 operator 要寫 flag。可能兩種並存。
4. Collaborator 在 checklist 上勾完後，IDD 怎麼知道？ Polling skill (/idd-poll)？webhook？還是 operator 下次跑 idd-list 時被提示「#N has new checkbox state」？
5. 多人對話：同一個 issue 上需要同時 ping A 和 B 不同問題，怎麼設計？兩個獨立 comment 各 tag 一人？還是一個 comment 內結構化 section + 各 section 分別 tag？
6. 「Current operator」識別：除了 gh api user，要不要支援 explicit override（例：IDD_OPERATOR=foo env var，給 service account / 自動化跑 IDD 的場景）？
7. Notification failure mode 在 idd-implement 開 PR 時的對應：同 session 觀察到 PR [Bundle test] Step 1: build schema #23 冷置 21 天的根因是「PR body 寫了 reviewer = HsuanYuLiuuu，但沒跑 gh pr edit --add-reviewer，她沒收到通知」。這是同一個 notification gap class，但 step 在 idd-implement 而非 idd-comment。要不要把 auto-trigger 規則擴到「idd-implement 開 PR 時自動 gh pr edit --add-reviewer <PR body 提到的 reviewer>」？Sister concern from 2026-05-21 PR [Bundle test] Step 1: build schema #23 incident（kiki830621/collaboration_liu-thesis-analysis#23）。

---

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

Skipped per user choice (kept inline as Open Design Question Q7):

• PR [Bundle test] Step 1: build schema #23 21-day cold review (same notification failure mode in idd-implement step)

Rationale: tightly coupled to this issue's core mechanism (auto-@-tag → notification reach); user opted to consolidate design discussion rather than split into separate triage.

---

Current Status

Phase: diagnosed
Last updated: 2026-07-06 by /idd-diagnose (via /idd-all batch drain)

Key Decisions

• Layer V 觸發（V4=4：回應協定未決）+ 使用者原話開放問題 → discussion list
• blocked-by feat: collaborator config in idd-config — record GitHub login, email, name, aliases for tagging accuracy #86；[bug] AI-generated comment 中的 @mention 可能繞過 tagging-collaborators 5-step protocol (sister concern from #116) #117 mention net 已備妥機械出口
• Blocked on: 回應協定三選一（checklist / 自由回覆 / 新 skill）

[kiki830621]

Diagnosis

Type

feature（auto-@mention 分流規則 — 含未決互動協定）

Root Cause / Analysis

失敗模式明確（open question 無 ping = 靜默沉沒，同 PR 卡 21 天 pattern）；auto-tag 觸發表已由 issue 給出（issue/comment-question/close 各行為，diagnose 排除）。但使用者原話本身留有未決設計軸：「我不知道要不要另外設定一個idd，然後要有勾選清單可以給對方勾 或者是請對方回覆嗎？」— 被 tag 者的回應協定（checklist 勾選 vs 自由回覆 vs 新 skill）是三選一的 UX 決策，屬使用者裁決。

依賴鏈：prerequisite = #86（collaborator 表 + operator 識別）與 #117 mention net（auto-tag 的機械出口 = --mention-attested）。#117 已 land 本 batch；#86 已 diagnosed 排程。

Impact

（依裁決）idd-issue / idd-comment / idd-close 的 auto-mention 分流段 + 可能的回應協定機制

Strategy

• 使用者裁決回應協定（checklist / 自由回覆 / 新 skill）— 連同觸發表確認
• 裁決後：feat: collaborator config in idd-config — record GitHub login, email, name, aliases for tagging accuracy #86 表 + operator 識別（gh api user + cache）+ 分流表實作 + confirmation prompt（unattended = 只 draft 不 auto-tag，attended 確認後 tag）

Conflict Class

D_diagnose_first → 決策型；blocked-by #86。

Complexity

Plan（觸發表）+ 未決 UX 軸 → 移入 discussion list（使用者原話即開放問題；unattended 不代答）

Risks

• auto-tag 誤判對象 → 5-step 協定 + confirmation prompt 是硬 gate，不可繞

Residue

「被 tag 者不在 repo collaborator 內（外部協作者）」場景 — email fallback 屬另案。

Vagueness Pre-check

• V1: 3 — 觸發表清楚、回應協定三選一未決（使用者自標）
• V4: 4 — 「對方有回應」的完成判準依協定而異 — Triggered: yes (max=4)
• User choice: [unattended] auto-apply proceed-anyway；實際處置 = 移入 discussion list 待使用者答 V4 軸（回應協定）

[Layer V: V1=3 V4=4, TRIGGERED, clarify-default skipped under unattended mode, defaulting to proceed → routed to discussion list]

Sister Concerns Filed (mid-diagnose, v2.47.0+ #528)

(none)

---

Source: /idd-all batch drain (unattended), 2026-07-06 — 移入 discussion list（回應協定三選一 + V4 觸發）

[kiki830621]

決策：回應協定採 free-reply（機制成本最低）。

被 auto-@mention 的人回應 open question 時，不強制 checklist 格式、不另開新 skill —— 直接在該 issue / comment thread 自由回覆即可。

理由：checklist 對「回答一個開放問題」是過度結構化；新 skill 是為尚不存在的問題造機制。free-reply 零新增機制、與現有 comment 流程一致（符合 deep-integration-over-hardcode 的反造機制傾向）。

實作依賴：本 issue 的 auto-mention 觸發側仍 blocked on #86（collaborator config in idd-config — @login / alias 對照，PR #247 verified 但尚未 merge）。#86 落地後，auto-mention helper 直接沿用其 @login 集，回應側走 free-reply、無額外機制。

G cluster 處置（20-issue consolidation triage）。