feature: /idd-all chain-solve mode — 自動接續解 spawned issues + 單 review PR

[kiki830621]

Errata (2026-05-10, post-discuss/propose/apply):
此 issue 的 ## Expected 段所述 /idd-all #N --chain flag + chain_policy: off/auto/ask config schema 在 /spectra:discuss 階段被 reject(過 default-dilemma checklist 全 yes;詳見 docs/design-patterns/default-dilemma.md)。
最終實作為獨立 /idd-all-chain skill + --in-chain flag(/idd-all 加 4th mode tuple (direct-commit, unattended))。請以 openspec/changes/add-idd-all-chain-skill/ 的 proposal.md + design.md 為準。
Spectra change 進度:25/32 tasks done(spawn manifest infra ✓ / 4 sub-skill conformance ✓ / idd-all --in-chain flag ✓ / idd-all-chain/SKILL.md ✓ / plugin metadata ✓);6.3 e2e validation deferred 到 first-real-use,7.x 本 comment 即是其中一項。

---

Problem

Original text (user chat, /idd-issue, 2026-05-08):
「我現在在想 /idd-all 這個技能,他是不是可以有一個做法是自動繼續把衍生的 issue 都一併解完,然後最後用整個 PR 來 review」

當前 /idd-all #N 跑單 issue lifecycle (issue → diagnose → implement → verify),verify / sister sweep / mid-plan tangential 觸發到的 follow-up issue 會被 file 為新 issue 但 idd-all 不會繼續解。使用者必須手動再跑 /idd-all #M 處理每個衍生 issue,且各自開獨立 PR。

User 提議:chain-solve mode — 跑 /idd-all #N 衍生出 #M / #K 時,自動接著解,全部 commit 到同一 feature branch + 同一 PR,最後 user 對整顆改動樹做 1 次 review/merge/close。

跟現有 mechanism 比較:

機制	觸發	Issue 範圍	PR	跨 issue
既有 /idd-all #N	單 issue	1 issue lifecycle	1 PR	衍生 → 新 issue,user 手動接
Cluster-PR (/idd-implement #N #M --pr)	User 預先指定多 issue	N pre-known issues	1 PR	User 預先決定 cluster
#37 bulk-solve (parked)	無 args 從 backlog 掃所有 open	所有 open issues	N PRs (per issue)	Cold-start,無依賴推導
本 issue: chain-solve	跑 #N 過程中 spawn 出來的 #M	hot-chain (1 → N+)	1 PR for 全鏈	Auto-emergent,跟 spawning 同步

Type

feature (orchestrator extension) — /idd-all 新模式

Expected

新增 /idd-all #N --chain flag(or default-on if chain_policy: auto in config):

Behavior

1. Phase 1-4 跟現有相同:跑 #N 完整 lifecycle 到 verified
2. Phase 4.5 NEW — chain detection:
   • 掃本 invocation 衍生的 follow-up issues:
     • idd-implement Step 5.7 sister bug sweep filed
     • idd-verify Phase 4 P3 follow-up findings filed
     • idd-plan Step 2.5 tangential observations filed
     • idd-diagnose Step 3.6 sister concerns filed
   • 排除 issue:已在另一個 branch / 已 closed / out-of-repo
3. Phase 4.6 NEW — recursive chain-solve loop:
   • 對每個 spawned issue:
     • 在同一 feature branch 上跑 mini-pipeline (diagnose → implement → verify)
     • Commit 用 Refs #M (cluster-PR commit convention)
     • Verify findings 若再 spawn → continue chain (depth limit 預設 2,可 config)
   • 每個 chained issue 各自 idd-update phase → verified
4. Phase 5 NEW — single review PR:
   • PR body 列出 root #N + chained #M, #K, ... 全部
   • Title prefix chain: (跟 cluster: 區別)
   • 每個 issue 各自 verify report (inline links to PR comments)
5. Phase 6 — stop at verified, user reviews 整顆 PR:
   • User merge 後跑 /idd-close #N #M #K 一次關全部(各自 closing summary,每個 issue 一份)

Config schema (proposed)

{
  "chain_policy": "off" | "auto" | "ask",
  "chain_max_depth": 2,
  "chain_max_issues": 5
}

• off (default for v1) — 跟現有行為一致,不 chain
• auto — 衍生 follow-up 自動 chain solve
• ask — 衍生時用 AskUserQuestion 問是否 chain

Actual

• /idd-all #N 衍生 follow-up 後就停下,user 看到「filed #M, #K」report 然後手動 /idd-all #M
• 每個 spawned issue 各自開 PR,造成 PR 碎片化:本 session 有 PR docs: README 列出 issue-driven-dev 仰賴的外部 plugin / MCP server #30 (docs: README 應列出 issue-driven-dev 仰賴的外部 plugin / MCP server (依 source type) #26) → 衍生 PR docs: marketplace lookup hint + 對照表 — fix #26 placeholder UX gap #33 (docs: README install 指令的 <your-marketplace> placeholder 缺 lookup hint (sister from #26) #31) → 衍生 PR feat+docs: ralph-loop dependency declaration + runtime detect (Plan tier) #36 (feature+docs: idd-verify --loop / idd-all unattended 隱性依賴 ralph-loop — 應宣告 + auto-detect + 內建探索 #28) → 衍生 PR cluster: #27 source-type adapter fail-fast + #34 generic plugin-presence helper (Plan tier) #39 (bug: idd-issue Step 1 (Source Type Adapter) 應在 MCP plugin 缺失時明確報錯 + 提示 install 指令 (sibling concern from #26) #27+refactor: 抽出 generic plugin-presence detector helper (tangential from #28 plan) #34) → 衍生 PR docs: explicit plugin-presence trust model (#41) #42 (docs: plugin-presence detect 應 explicit document trust model (DA R3.a from #28 verify) #41) — 都是同一個 source-type fail-fast 主題,但因為 IDD discipline 切成 5 個 PR,review effort × 5

Impact

• Review fragmentation:相關改動分散多 PR,reviewer 失去 holistic view
• Atomicity loss:multi-issue refactor 應該 atomic,split 成 N PR 增加 partial-merge 風險
• Manual orchestration burden:user 要記得追蹤所有 spawned issue,handover 期間易遺漏
• Audit trail dilution:close summary 各自寫,無法看「整個改動樹解了什麼問題」

Design considerations / open questions

1. Depth limit:衍生 → 又衍生 → 雪崩風險。Default chain_max_depth=2 合理嗎?
2. Verify discipline preserved:每個 chained issue 仍跑 idd-verify (or 共用 PR 末端 verify)?後者省 cost 但失 per-issue verify rigor
3. PR body 結構:N issues 的 PR body 怎麼組織才不會變成超長 wall of text?
4. Failure mode:中途某 chained issue verify FAIL,整顆 chain abort 還是 partial commit?per-issue verify 模式下,FAIL 應只 abort 該 issue 不影響其他
5. Close orchestration:/idd-close #N #M #K 已支援 cluster-PR mode,chain mode 會直接 reuse 這個還是新 mode?
6. Edge case — chain 跨 branch 不可:衍生 issue 若觸及完全不相關 file (e.g. feature+docs: idd-verify --loop / idd-all unattended 隱性依賴 ralph-loop — 應宣告 + auto-detect + 內建探索 #28 衍生 refactor: 抽出 generic plugin-presence detector helper (tangential from #28 plan) #34 doc + docs: plugin-presence detect 應 explicit document trust model (DA R3.a from #28 verify) #41 trust docs vs. 另一個 feat(idd-all-chain): Phase 0 diagnosis-readiness gate (Step 0.4) #50 unrelated bug fix),user 心中可能不想 cluster — 需要 heuristic 或 prompt
7. Cross-cutting refactor 才適合 chain:同一 helper / 同一 module 的多 issue → chain;independent fixes → 分 PR 還是對的

與 #37 (parked bulk-solve) 的差異

特性	#37 bulk-solve	This (chain-solve)
Trigger	/idd-all 無 args (cold start)	/idd-all #N 衍生時 (hot chain)
Issue source	既存 backlog	This invocation spawned
Sequencing	AI 自動排序所有 backlog	自然 emergence (DFS)
PR	N PRs per cluster	1 PR for 整鏈
Use case	"Inbox zero session"	"解決 1 root issue 連帶 ripple"

兩者 orthogonal,可獨立或組合(chain-solve mode 嵌入 bulk-solve 的每個 cluster 內)。

Real example from this session

• Root: feature+docs: idd-verify --loop / idd-all unattended 隱性依賴 ralph-loop — 應宣告 + auto-detect + 內建探索 #28 (ralph-loop dependency)
• Spawned during round-2 verify: docs: track upstream gap — Claude Code plugin schema 缺 inter-plugin dependency 機制 (sister from #28) #29 (upstream tracking), refactor: 抽出 generic plugin-presence detector helper (tangential from #28 plan) #34 (helper refactor), tracking: Claude Code plugin cache path schema 變動 watch-list (tangential from #28) #35 (path watch), bug: idd-all Phase 0.6 graceful-degrade 對 unattended automation caller 是 functional regression (DA R4.a from #28 verify) #40 (degrade regression), docs: plugin-presence detect 應 explicit document trust model (DA R3.a from #28 verify) #41 (trust model docs)
• Actual flow: split into PR feat+docs: ralph-loop dependency declaration + runtime detect (Plan tier) #36 (feature+docs: idd-verify --loop / idd-all unattended 隱性依賴 ralph-loop — 應宣告 + auto-detect + 內建探索 #28) → PR cluster: #27 source-type adapter fail-fast + #34 generic plugin-presence helper (Plan tier) #39 (bug: idd-issue Step 1 (Source Type Adapter) 應在 MCP plugin 缺失時明確報錯 + 提示 install 指令 (sibling concern from #26) #27+refactor: 抽出 generic plugin-presence detector helper (tangential from #28 plan) #34) → PR docs: explicit plugin-presence trust model (#41) #42 (docs: plugin-presence detect 應 explicit document trust model (DA R3.a from #28 verify) #41) → PR feat(idd-list): markdown-aware fence strip + cluster_leader config (cluster #14 #15) #43 ([refactor] idd-list PR body parsing: ignore #N inside fenced code blocks (sister concern from #13) #14+[enhancement] idd-list cluster_leader config (lowest | primary) (sister concern from #13) #15) — 4 PRs across multiple sessions
• With chain-solve: 可能 1 個 PR 含 feature+docs: idd-verify --loop / idd-all unattended 隱性依賴 ralph-loop — 應宣告 + auto-detect + 內建探索 #28 + refactor: 抽出 generic plugin-presence detector helper (tangential from #28 plan) #34 + docs: plugin-presence detect 應 explicit document trust model (DA R3.a from #28 verify) #41,以及這個 PR 自己再 spawn 出 [refactor] idd-list PR body parsing: ignore #N inside fenced code blocks (sister concern from #13) #14/[enhancement] idd-list cluster_leader config (lowest | primary) (sister concern from #13) #15 cluster-PR (depth 2 stop)

Related

• feature: /idd-all (無參數) bulk-solve mode — AI 自動 sequence + bundle 所有 open issue #37 (parked bulk-solve mode — orthogonal feature)
• [SOP] umbrella split flow should mandate commit log scan before filing sub-issues #11 (umbrella split SOP — spawning 紀律的相關 process)

Priority: P2 (DX 大改善,但需要謹慎設計避免 chain 雪崩 / verify discipline regression)

Current Status

Phase: closed
Last updated: 2026-05-10 by idd-close (Spectra change archived + retroactive Implementation Complete + Closing Summary posted)

Key Decisions

• Complexity = Spectra (Layer 2 + Layer 3 全 3 個都命中)
  • Layer 2: 跨 sub-skill implicit contract(spawn manifest schema)
  • Layer 3a: 修 5 個既有 spec(idd-all + 4 sub-skills)
  • Layer 3b: 跨 reference doc cross-spec impact
  • Layer 3c: Architectural shift(single-issue → emergent multi-issue lifecycle)
• Implementation 路線:--chain flag 路線 reject;改成獨立 /idd-all-chain skill + --in-chain flag(過 default-dilemma checklist)
• Strategy: 7 phases — spawn manifest infra → 4 sub-skill conformance → idd-all --in-chain flag → /idd-all-chain skill → plugin metadata → verification → GitHub alignment
• Vagueness Pre-check: V1=2, V4=3 (not triggered)

Scope Changes

• 2026-05-08:--chain flag 路線 reject(discuss),改採獨立 /idd-all-chain skill
• 2026-05-10:Spectra change add-idd-all-chain-skill 合併 ingest feature: /idd-all chain-solve mode — 自動接續解 spawned issues + 單 review PR #44 issue body context;tasks.md 加 group 7 對齊 GitHub-side tracker

Tasks (Spectra change add-idd-all-chain-skill)

• 1.x Spawn manifest infra (3/3)
• 2.x Sub-skill manifest write conformance (5/5)
• 3.x idd-all --in-chain flag (5/5)
• 4.x /idd-all-chain skill creation (8/8 — 含 chain-flow.md reference)
• 5.x Plugin metadata (4/4 — CLAUDE.md / plugin.json / marketplace.json / usecase-routing.md)
• 6.1, 6.2, 6.4 verification 通過(structural + smoke);6.3 e2e deferred to first-real-use
• 7.x GitHub Issue feature: /idd-all chain-solve mode — 自動接續解 spawned issues + 單 review PR #44 alignment(本 update + errata + link comment)

Blocking

• (none — closed via /idd-close 2026-05-10 with retroactive Implementation Complete supersession)

Sister Concerns

• Skipped (1: spawn manifest as internal Phase 1, kept inside feature: /idd-all chain-solve mode — 自動接續解 spawned issues + 單 review PR #44)

[kiki830621]

Diagnosis

Type

feature (orchestrator extension to idd-all — chain-emergent multi-issue solve with single review PR)

Analysis

#44 提議 /idd-all #N --chain flag (or chain_policy: auto config) 讓 idd-all 跑 #N lifecycle 過程中衍生的 follow-up issue (idd-implement Step 5.7 sister bugs / idd-verify Phase 4 P3 follow-ups / idd-plan Step 2.5 tangentials / idd-diagnose Step 3.6 sister concerns) 自動接續解決且全部歸入同一 PR。

跟既有 4 個 mechanism 比對

實作前必須清楚定位本 feature 跟既有機制的 boundary:

機制	Trigger	Issue scope	PR scope	Sequencing
Cluster-PR (idd-implement #N #M --pr)	User 預先指定多 issue	Pre-known N	1 PR	User 預先決定
Batch (idd-diagnose #N #M)	User 指定多 issue	Pre-known N	各自獨立 (no PR concept)	User 預先決定
Group (multi-repo cross-link)	Config + label trigger	Cross-repo primary + tracking	各自獨立	Config-driven
Bundle (idd-issue --bundle-mode)	User 創 epic + N children	Newly-created sub-issues	各自 / 彼此 blocked-by	Plan-time decision
本 issue: chain-solve	/idd-all #N 過程中 spawn	Hot-emergent (1 → N+)	1 PR for 整鏈	Auto-emergent (DFS)
#37 parked bulk-solve	/idd-all 無 args	既存 backlog	N PRs per cluster	AI 自動排序

關鍵差異:chain-solve 跟 cluster-PR 的差別在「pre-known vs emergent」。Cluster-PR 是 user 心中已知 #N #M #K 該一起解;chain-solve 是 #N 過程中才發現 #M, #K 該一起解(從 verify findings / sister sweeps)。

6 個 open questions 評估

issue body 已列 6 個 design open questions,我這裡逐一評估設計實質:

Q1: Depth limit (default chain_max_depth=2)

• Reasonable default — 本 session 實證:feature+docs: idd-verify --loop / idd-all unattended 隱性依賴 ralph-loop — 應宣告 + auto-detect + 內建探索 #28 → refactor: 抽出 generic plugin-presence detector helper (tangential from #28 plan) #34 → 沒再衍生 (depth 1 自然停),feature+docs: idd-verify --loop / idd-all unattended 隱性依賴 ralph-loop — 應宣告 + auto-detect + 內建探索 #28 → docs: plugin-presence detect 應 explicit document trust model (DA R3.a from #28 verify) #41 → 沒再衍生 (depth 1)。Real-world chains 很少超過 2 層,因為 IDD diagnose 紀律會 surface tangentials 但不會無限細分
• Edge case 設計:depth=2 hit limit 後仍 file 為 follow-up issue 不丟掉,只是不 chain solve (file then return to root)
• 不建議 default 0/1:0 = 等於沒 chain,1 = 多 1 層但很多 spawn case 仍卡 (e.g. round-2 verify fix 算 spawn 嗎?)

Q2: Verify discipline preserved (per-issue verify or 共用末端 verify)

• 強烈推薦 per-issue verify (本 session 證明 6-AI verify 抓到 feature+docs: idd-verify --loop / idd-all unattended 隱性依賴 ralph-loop — 應宣告 + auto-detect + 內建探索 #28 的 P0 plugin.json + P1 BRANCH bug 都是 cross-AI consensus,沒有 per-issue verify 就會 miss)
• 末端共用 verify 的 cost saving 換不了 verify discipline 的 audit truthfulness
• 唯一例外:trivial spawned issue (e.g. typo fix, single-line change) 可 inline verify (PR-level lightweight smoke test)。但這個閾值難 deterministic 判斷,v1 一律 per-issue verify 比較安全

Q3: PR body 結構 (避免 wall of text)

• 必修問題,N=4-5 chained issues 時 PR body 易爆。設計建議:
  • Top section:Summary + cluster overview table (#N → root, #M → sister bug, #K → tangential)
  • Per-issue section:折疊 <details> HTML tag (GitHub renders),user 點開才看詳細
  • Master verify report:每個 issue 的 verify findings 連結回 issue verify comment (不複製 inline)
• 既有 cluster-PR PR body 已有類似 pattern (covers cluster #N #M #K),擴展即可

Q4: Failure mode (中途 chained verify FAIL)

• 強烈推薦 partial commit + abort chain:當前 chained issue verify FAIL → halt chain, 不 continue 後續 spawn,但已成功 chain 的 commit 留在 branch
• 不回滾既有 commit (rebase / revert) — 會破壞 audit trail
• abort 後 user 接手 (/idd-verify --pr <N> 看 FAIL reason)
• 對比方案 (full abort + revert all chained commits) 太激進,IDD 偏 explicit + recoverable

Q5: Close orchestration

• 直接 reuse cluster-PR /idd-close #N #M #K (本 session 已驗證這個 pattern works)
• chain mode 不需新 close skill,因為 chain 結果就是 cluster-PR (1 PR + N issues)
• 唯一小調整:close summary template 加 "spawned via chain from #ROOT" 提示,讓 audit trail 含 emergence context

Q6: Cross-cutting vs independent (heuristic to chain or not)

• 最核心難題,直接決定 v1 設計的 risk surface
• 建議 v1 採保守規則:只 chain 同主題 spawn,定義為:
  • Spawned 來源是 same-file changes (sister bug from idd-implement Step 5.7 — 都動同個 file)
  • Spawned 來源是 same-skill mid-plan tangential (idd-plan Step 2.5 — 同個 skill 衍生)
• 不 chain 的情境:
  • idd-verify Phase 4 follow-up findings 中 priority=P3 + scope=different-file → file 為 issue but no chain
  • idd-diagnose Step 3.6 sister concerns 含 "out of repo" / "different layer" markers → no chain
• v1 採 opt-in chain via --chain flag, 不default-on,避免 unattended 雪崩

Affected files / impact 範圍

實作 chain-solve 涉及深度設計改動:

File	改動類型
plugins/issue-driven-dev/skills/idd-all/SKILL.md	NEW Phase 4.5 (chain detection) + 4.6 (recursive chain solve loop) + 5 (single review PR with cluster body)
plugins/issue-driven-dev/.claude-plugin/plugin.json	NEW chain_policy / chain_max_depth / chain_max_issues config schema
plugins/issue-driven-dev/references/pr-flow.md (or NEW references/chain-flow.md)	NEW chain mode contract:detection / sequencing / depth limit / failure mode
plugins/issue-driven-dev/skills/idd-close/SKILL.md	minor — close summary template 加 "spawned via chain" 提示
plugins/issue-driven-dev/CLAUDE.md	NEW chain mode 說明 in Workflow section

4 sub-skill 的 spawn API 也需要 standardize:

• idd-implement Step 5.7 sister-bug-sweep → 必須 emit machine-readable spawn manifest (e.g. .claude/.idd/state/chain-spawned-issues.json) 讓 idd-all 偵測
• idd-verify Phase 4 follow-up findings → 同
• idd-plan Step 2.5 tangential observations → 同
• idd-diagnose Step 3.6 sister concerns → 同

這個是 隱性 API contract — 每個 sub-skill 都要寫 spawn manifest,idd-all 才能讀到 spawned set。

Strategy

依複雜度分階段實作:

Phase 1: Spawn manifest standardization (新 sub-spec)

• 設計 .claude/.idd/state/chain-spawned-issues.json schema
• 4 sub-skills (idd-implement / idd-verify / idd-plan / idd-diagnose) 全部加 spawn manifest write logic
• references/spawn-manifest.md canonical contract

Phase 2: idd-all chain detection + opt-in flag

• idd-all 加 --chain flag parsing
• Phase 4.5 NEW — read spawn manifest after each sub-skill 完成
• Config schema chain_policy: "off" | "auto" | "ask" + chain_max_depth: 2 + chain_max_issues: 5

Phase 3: Chain solve recursive loop

• Phase 4.6 NEW — for each spawned issue:
  • Heuristic: same-file / same-skill → chain;cross-cutting → file but skip chain
  • 在同 feature branch 跑 mini-pipeline
  • depth + max-issues bookkeeping
  • failure → halt chain (partial commit preserved)

Phase 4: Single review PR enrichment

• Phase 5 NEW — PR body template 含 cluster overview + per-issue collapsed sections
• PR title prefix chain: (跟 cluster: 區別)
• Each chained issue 各自 idd-update phase

Phase 5: Documentation + close orchestration

• CLAUDE.md / idd-all README 加 chain mode 說明
• idd-close #N #M #K close summary template 加 "spawned via chain from #ROOT"
• Migration / examples in references/usecase-routing.md

Complexity

Spectra (Layer 2 + Layer 3 都命中)

Layer 2 (Necessary): published API / protocol / skill / tool surface

✅ 命中 — 多重:

• 新 --chain flag 是 published skill API,使用者可呼叫
• chain_policy config field 是 published config schema,需要在 references/config-protocol.md 文件化
• 新 .claude/.idd/state/chain-spawned-issues.json spawn manifest 是 跨 sub-skill 的 implicit contract — 4 個 sub-skill (idd-implement / idd-verify / idd-plan / idd-diagnose) 都要 conformant write,這是 multi-caller contract

Layer 3 (Confirmation): 至少一個

✅ 全 3 個都命中:

• 修改既有 published spec 的 normative behavior:idd-all Phase 4 既有 spec 改 (加 4.5 + 4.6);idd-implement Step 5.7 / idd-verify Phase 4 / idd-plan Step 2.5 / idd-diagnose Step 3.6 都要加 spawn manifest write logic — 5 個既有 spec 同時動
• 影響 2+ 既有 specs 需 consistency-checking:pr-flow.md (PR body schema) + batch-and-cluster.md (chain mode 是 cluster-PR 的 emergent variant) + external-agent-delegation.md (chain depth 對 external agent 的影響) — 跨 reference doc cross-spec impact
• Architectural decision with long-term implications:chain-solve 是 IDD 從「single-issue lifecycle」演進到「emergent multi-issue lifecycle」的結構性轉變,影響 future engineers 對 idd-all / cluster-PR / bundle 的 mental model

→ Spectra 設計合理:這個改動會被 future callers (idd-* skills + external integration like /loop) 繼承,需要 frozen spec contract。

Risks

• High: Chain 雪崩:chain_max_depth=2 + chain_max_issues=5 是合理 cap,但 depth=2 + max=5 仍可能 5 issues × full pipeline = 巨量 cost。Mitigation:chain_policy: "ask" (不 default-on) + verify FAIL halt chain
• High: Spawn manifest contract drift:4 sub-skill 各自寫 manifest,如有 1 個忘了寫或 schema drift,idd-all 偵測會 silent miss spawn → chain incomplete。Mitigation:Spectra path 的 spec contract + 4 sub-skill 統一 reference 同個 canonical doc
• Medium: Verify cost ×N:per-issue verify 是正確設計但 cost 高。N=5 chained issues + 6-AI ensemble each = 30 AI invocations。Mitigation:trivial issue (single-file docs / typo) 改 lightweight verify,deterministic threshold 用 file count + LOC
• Medium: PR body 過大:折疊 <details> 但 GitHub UI render 大 PR 仍 lag。Mitigation:max-issues=5 cap
• Medium: Close orchestration race condition:user 還在 review PR 時 chain mode 已 file 完所有 spawn,issue auto-update 可能跟 PR review timeline 不同步。Mitigation:chain mode 也停在 verified — user 主動 close,不 auto
• Low: Backward compat:--chain opt-in flag,既有 /idd-all #N 行為不變

Related

• feature: /idd-all (無參數) bulk-solve mode — AI 自動 sequence + bundle 所有 open issue #37 (parked bulk-solve mode — orthogonal,可組合)
• [SOP] umbrella split flow should mandate commit log scan before filing sub-issues #11 (closed — umbrella split SOP,類似 emergent multi-issue 的 process discipline)
• 本 session 4 PR fragmentation 的 real evidence (見 feature: /idd-all chain-solve mode — 自動接續解 spawned issues + 單 review PR #44 body)

Vagueness Pre-check

• V1: 2 — issue body 列具體 trigger (4 種 sub-skill spawn source)、Expected behavior 拆 Phase 1-6、config schema sketch、跟 4 既有 mechanism 比對 table。要做的事很具體
• V4: 3 — Acceptance 含 6 個 design open questions(depth limit / verify discipline / PR body 結構 / failure mode / close orchestration / cross-cutting heuristic)需 implement 階段拍板。每個 question 在 diagnose 已給推薦答案,但仍是 design-time decision
• Triggered: no — both axes ≤ 3

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

Skipped per user choice (1 item: spawn manifest schema + 4 sub-skill conformant write — kept as #44 Strategy Phase 1 internal sub-task,not separate issue per user direction)

[kiki830621]

Cross-link to Spectra change artifacts

Following /spectra:apply add-idd-all-chain-skill(本次 ingest #44 → 既有 change),完整 design 與實作細節請至以下 artifacts:

Artifact	Path	內容
Proposal	openspec/changes/add-idd-all-chain-skill/proposal.md	Why / What Changes / Capabilities / Impact
Design	openspec/changes/add-idd-all-chain-skill/design.md	8 Decisions(包括 Decision 1 thin shell over /idd-all / Decision 2 4th mode tuple / Decision 4 spawn manifest schema / Decision 7 hard caps / Decision 8 cross-cutting heuristic)+ Risks / Trade-offs
Tasks	openspec/changes/add-idd-all-chain-skill/tasks.md	32 tasks / 31 done / 1 deferred(6.3 e2e)
Specs	openspec/changes/add-idd-all-chain-skill/specs/	idd-all-chain ADDED / idd-spawn-manifest ADDED / idd-orchestrator-modes MODIFIED

實作落點:

File	What
plugins/issue-driven-dev/skills/idd-all-chain/SKILL.md	Chain shell skill(Phase 0-4 + abort report)
plugins/issue-driven-dev/scripts/manifest-append.sh	Atomic spawn manifest writer + schema_version check
plugins/issue-driven-dev/references/spawn-manifest.md	Schema canonical contract
plugins/issue-driven-dev/references/chain-flow.md	Chain shell algorithm canonical contract
plugins/issue-driven-dev/skills/idd-{all,implement,verify,plan,diagnose}/SKILL.md	--in-chain flag + manifest write conformance
plugins/issue-driven-dev/{CLAUDE.md,.claude-plugin/plugin.json,CHANGELOG.md}	Plugin metadata + CHANGELOG [Unreleased] entry
.claude-plugin/marketplace.json	Marketplace version + description sync

Plugin version bumped:2.53.0 → 2.55.0(chain skill is significant feature)。

Errata note 已 prepend 到本 issue body(指出 Expected 段所述 --chain flag + chain_policy config 是 reject 的初版,以 change artifacts 為準)。Phase 從 diagnosed 同步到 implementing(Tasks 1.x-7.x 詳見 body Current Status block)。

[kiki830621]

Implementation Complete (synthetic — Spectra path, 2026-05-10)

Note: 本 issue 走 Spectra path (add-idd-all-chain-skill change archived)。spectra-apply 不寫 ## Implementation Complete > ### Checklist 到 GitHub issue,改寫 tasks.md 在 change directory 內。本 comment 是 retroactive 合成,目的是觸發 idd-close 的 v2.41.0+ supersession,讓 close gate 通過 (without false-positive blocking on stale Strategy bullets that referenced rejected --chain flag design)。

Strategy 原 bullets 已 superseded:/idd-all --chain flag 路線在 spectra-discuss 階段被 reject (per default-dilemma checklist),最終實作為獨立 /idd-all-chain skill + --in-chain flag。實際 ship 的東西列在下面 checklist。

Checklist (synced from Spectra change add-idd-all-chain-skill archived 2026-05-10)

• Spawn manifest cross-skill contract — .claude/.idd/state/chain-spawned-issues.json schema_version=1 + atomic temp-file rename writes via scripts/manifest-append.sh + 4 sub-skill conformant write (implement Step 5.7 / verify Phase 4 / plan Step 2.5 / diagnose Step 3.6) → plugins/issue-driven-dev/references/spawn-manifest.md canonical contract
• /idd-all --in-chain flag — Phase 0.5 parses flag → 4th mode tuple (direct-commit, unattended),Phase 0.5 PR-mode branch creation skip,Phase 5.5 PR creation skip,sub-skill receives UNATTENDED MODE directive。Mutex with --pr / --no-pr。
• /idd-all-chain skill — thin recursive shell over /idd-all,Phase 0 cluster branch + manifest init,Phase 2 main loop pop queue + invoke sub-/idd-all + read manifest delta + enqueue eligible spawns,Phase 3 cluster PR (title chain: + collapsed <details> per issue),Phase 4 STOP at verified
• Hard caps — chain_max_depth=2, chain_max_issues=5 (含 root),over-cap spawns 仍 file 為 follow-up issue 但不 enqueue
• Chain-eligible heuristic — same_file_as_root OR same_skill_as_root OR spawn_kind="sister-bug"
• Failure mode — chained verify FAIL halt queue + preserve partial commits (no rebase / revert) + abort report 含 4 條 recovery paths
• references/chain-flow.md — chain shell algorithm canonical contract (eligibility + caps + failure mode + PR body schema)
• MODIFIED capability idd-orchestrator-modes — 4th tuple (direct-commit, unattended) for chain context;既有 3 tuples 行為不變
• Plugin metadata — version bump 2.53.0 → 2.55.0,CLAUDE.md Skills table + Workflow chain-solve section,marketplace.json sync,CHANGELOG.md [Unreleased] entry,usecase-routing.md row 25
• Verification — 6.1 manifest helper smoke test 5/5 PASS,6.2 --in-chain wiring 7-pt structural PASS,6.4 backward-compat additive-only diff PASS;6.3 e2e marked won't-fix-in-this-change (re-scoped to first-real-use validation track) — 已在 feature: /idd-all-chain Phase 0 pre-flight check for root issue diagnosis-readiness #47 first-real-use 觸發並完整 verified
• GitHub issue alignment — errata header prepended (Expected 段 references rejected --chain flag),Current Status synced to implementing → closed (本 issue),link comment to openspec/changes/archive/2026-05-10-add-idd-all-chain-skill/ artifacts

Legend: - [x] shipped (mapped to Spectra change archive,not original Strategy bullets)。
idd-close v2.41.0+ supersession 規則:此 checklist 全 [x] → Strategy / Plan 的 stale - [ ] 自動 superseded,gate 通過。

Changes (commits on main,squashed via PRs)

a244ee9 feat(idd-all-chain): Phase 0 diagnosis-readiness gate (Step 0.4) (#50)  ← #47 sister
373aff2 spectra(add-idd-all-chain-skill): add chain-solve mode (#44 archived)
6aec214 feat+docs: ralph-loop dependency declaration + runtime detect (#36)
b9d3200 docs(issue-driven-dev): README v2.55.0 — Skills table + Version History sync

Plus the chain skill ship landed in 373aff2 containing the original 5 commits squash:

• 0fd9dbd Step 0 Bootstrap add check_diagnosis_readiness entry
• e36e658 NEW Phase 0 Step 0.4 diagnosis-readiness check + renumber
• 3092f68 chain-flow.md Phase 0 章節 + Diagnosis-readiness gate section
• a35e928 fix verify findings P1.1-3 + P2.1-3
• 88f3a26 re-verify cleanup — awk → sed split,prose sync

(那 5 個 commits 是 #47 的 PR #50,但是 #44 的延伸 — chain skill 第一次 first-real-use validation 撞到 pre-flight 缺 gate 而 file 出 #47。)

Files Changed (cumulative across #44 + #47)

plugins/issue-driven-dev/skills/idd-all-chain/SKILL.md        (NEW)
plugins/issue-driven-dev/scripts/manifest-append.sh           (NEW)
plugins/issue-driven-dev/references/spawn-manifest.md         (NEW)
plugins/issue-driven-dev/references/chain-flow.md             (NEW)
plugins/issue-driven-dev/skills/idd-{all,implement,verify,plan,diagnose}/SKILL.md  (MODIFIED — 5 sub-skills)
plugins/issue-driven-dev/CLAUDE.md                            (MODIFIED — Skills table + Workflow + Chain section)
plugins/issue-driven-dev/.claude-plugin/plugin.json           (2.53.0 → 2.55.0)
.claude-plugin/marketplace.json                                (2.52.0 → 2.55.0 sync)
plugins/issue-driven-dev/CHANGELOG.md                         (Unreleased entry)
plugins/issue-driven-dev/README.md                            (#44 + #47 ship)
plugins/issue-driven-dev/references/usecase-routing.md        (row 25 added)
openspec/changes/archive/2026-05-10-add-idd-all-chain-skill/  (NEW — Spectra change archived)
openspec/specs/idd-all-chain/                                  (NEW capability spec)
openspec/specs/idd-spawn-manifest/                             (NEW capability spec)
openspec/specs/idd-orchestrator-modes/spec.md                  (MODIFIED — 4th tuple)

Spectra Change Archive

openspec/changes/archive/2026-05-10-add-idd-all-chain-skill/

• proposal.md — Why / What Changes / Capabilities / Impact (含 GitHub-side tracker pointer to feature: /idd-all chain-solve mode — 自動接續解 spawned issues + 單 review PR #44)
• design.md — 8 Decisions
• tasks.md — 32/32 tasks done
• specs/idd-all-chain/spec.md (ADDED)
• specs/idd-spawn-manifest/spec.md (ADDED)
• specs/idd-orchestrator-modes/spec.md (MODIFIED)

Follow-ups Filed (during #47 verify, all open)

• feature: implement check_diagnosis_readiness() helper function (extract from #47 inline bash) #51 implement check_diagnosis_readiness() helper function (extract from feature: /idd-all-chain Phase 0 pre-flight check for root issue diagnosis-readiness #47 inline bash) — P3
• feature: idd-verify orchestration playbook (subagent_type guidance + recovery protocol) #52 idd-verify orchestration playbook (subagent_type guidance + recovery protocol) — P2 (process gap from feature: /idd-all-chain Phase 0 pre-flight check for root issue diagnosis-readiness #47 verify)
• fix: idd-all-chain Step 0.4 jq filter use anchored regex (avoid false-positive on quoted text) #53 idd-all-chain Step 0.4 jq filter use anchored regex — P3
• feature: mechanism for sync archived Spectra spec deltas with subsequent capability extensions #54 mechanism for sync archived Spectra spec deltas with subsequent capability extensions — P3 (this issue's structural problem!)

Scope Compliance

✅ #44 scope (root chain-solve mode) covered。#47 是 first-real-use 衍生的 follow-up,也已落地。剩餘 P3 follow-ups 是非阻擋性 polish。

Next: ready for /idd-close

[kiki830621]

Closing Summary

Problem

/idd-all #N 跑單 issue lifecycle 時,sub-skill spawn 出 follow-up issue (sister bug / verify follow-up / mid-plan tangential / sister concern) 會被 file 為新 issue 但 idd-all 就停下,使用者要手動逐一跑 /idd-all #M,且每個 issue 各自開獨立 PR — 造成 PR fragmentation(reviewer 失去 holistic view) + 手動 orchestration burden + audit trail 稀釋。本 session 真實案例:#28 root issue 衍生 #34 / #41 / #14 / #15 共 4 個 issue,被切成 4 個獨立 PR review。

Root Cause

IDD orchestrator 的設計 invariant 是「single-issue lifecycle」— /idd-all 跑完一個 issue 即停,sub-skill spawn 是 audit trail event 而非 continuation trigger。但 user 在 reviewer / orchestration 角度經常想要「root + 衍生鏈」一氣呵成,缺乏對應的 mechanism。

Solution

新 /idd-all-chain #N skill — thin recursive shell over /idd-all,核心設計決定:

1. Independent skill, not a flag: /idd-all --chain 路線在 spectra-discuss 階段被 reject(過 default-dilemma checklist 全 yes:chain_policy: off / auto / ask 三 default 各帶失敗模式;user binary 心智;90% pipeline 共用),改採 separate skill 避免 default ambiguity。
2. Single cluster branch + single PR: Phase 0 建 idd/chain-<root>-<slug> branch,所有 chained issues commit 到同 branch,Phase 3 開 1 PR cover 全鏈(title prefix chain: + collapsed <details> per issue body schema)。
3. --in-chain flag on /idd-all: single source for chain context,推導 4th mode tuple (direct-commit, unattended)。Sub-/idd-all --in-chain skips Phase 0.5 PR-mode branch + Phase 5.5 PR open + sub-skill 收 UNATTENDED MODE directive。
4. Spawn manifest cross-skill contract: .claude/.idd/state/chain-spawned-issues.json schema_version=1,4 個 sub-skill (idd-implement / idd-verify / idd-plan / idd-diagnose) 在既有 sister-sweep / follow-up / tangential / sister-concern step append entry。Helper script manifest-append.sh atomic temp-file rename + schema mismatch abort。
5. Hard caps + eligibility: chain_max_depth=2 / chain_max_issues=5 (含 root)。Eligibility = same_file_as_root OR same_skill_as_root OR spawn_kind="sister-bug"。Over-cap / ineligible 仍 file 為 follow-up issue 但不 enqueue。
6. Failure mode = halt + preserve: 任一 chained verify FAIL → halt queue + preserve partial commits (no rebase / revert) + abort report 含 4 條 recovery paths。
7. Stops at verified, never auto-close: Per-issue /idd-close 紀律保留(closing summary per issue 是 IDD audit value 核心,chain mode 不省)。

Plugin v2.55.0 ship — capability idd-all-chain (NEW),idd-spawn-manifest (NEW),idd-orchestrator-modes (MODIFIED 4th tuple)。

Verification

Spectra change add-idd-all-chain-skill archived 2026-05-10:32/32 tasks done,4 artifacts done,analyzer 0 findings。

First-real-use validation surfaced #47(Phase 0 缺 diagnosis-readiness gate)— first chain run on #45 halted at Phase 2 entry because user observed root issue spec was incomplete。#47 開了 + 走完整 lifecycle (diagnose → plan → implement → verify FAIL → fix → verify PASS → close),驗證了 chain skill design 的 first-real-use validation track 可行。

6.x verification cases:

• 6.1 manifest helper smoke test 5/5 PASS (本地 mktemp run)
• 6.2 /idd-all --in-chain wiring 7-pt structural PASS (codex audit)
• 6.3 e2e end-to-end deferred → first-real-use validation track (consumed by feature: /idd-all-chain Phase 0 pre-flight check for root issue diagnosis-readiness #47 first chain run, validated)
• 6.4 backward compat additive-only diff PASS

Changes

合 #44 (root) + #47 (first-real-use derivative) 共 ship 在 main 上的 commits:

b9d3200 docs(issue-driven-dev): README v2.55.0 — Skills table + Version History sync
a244ee9 feat(idd-all-chain): Phase 0 diagnosis-readiness gate (Step 0.4) (#50)  ← #47 squash
373aff2 spectra(add-idd-all-chain-skill): add chain-solve mode — root + auto-emergent spawn through one cluster branch + one PR  ← #44 squash

Spectra change archive:openspec/changes/archive/2026-05-10-add-idd-all-chain-skill/

Closing Follow-ups Filed (Step 3.5)

(none new — 4 follow-ups 已 in-flight from #47 verify cycle:#51 #52 #53 #54。本 issue 的 closing summary 只 reference 既有 follow-ups,沒新 orphan keywords。)

Lessons learned

1. Spectra path 沒有自動 post Implementation Complete to GitHub issue 的 mechanism — 造成 /idd-close 在 Spectra-archived issues 上撞 stale Strategy/Plan - [ ] 而 refuse close。本 issue 走 retroactive 合成 Implementation Complete 解 lock。Long-term solution: spectra-apply 結束時 auto-post Implementation Complete to issue,或 /idd-close 偵測 archived Spectra change 自動觸發 supersession。是 feature: mechanism for sync archived Spectra spec deltas with subsequent capability extensions #54 archived spec sync mechanism 的 sibling 問題,值得 file 另一個 follow-up issue。
2. First-real-use validation 是真的有用 — 6.3 e2e 在 propose 階段被 deferred 為 "first-real-use validation track",當時看起來像是省事的 trade-off。實際 feature: /idd-all-chain Phase 0 pre-flight check for root issue diagnosis-readiness #47 first chain run halt 證明 deferred 是對的決定 — first-real-use 暴露了 design 階段沒考慮到的 edge case (diagnosis-readiness gate),效率比 synthetic e2e test 高。
3. Chain failure mode = halt + preserve 設計 work — feature: /idd-all-chain Phase 0 pre-flight check for root issue diagnosis-readiness #47 chain halt 時 cluster branch 跟 manifest 都被保留,user 隨時可手動 diagnose 後 re-run。

Next

/idd-all-chain v2.55.0 ship 已整輪走完 (issue → discuss → propose → apply → archive → ship → first-real-use validation 撞 #47 → #47 fix → close)。剩餘 4 個 P3/P2 follow-ups (#51 #52 #53 #54) 各自獨立 schedule。