我的 AI 協作工作流程演進

我和 AI 協作的 issue 工作流程，每個版本記成一篇，標題前的 vN 就是版本。

v1：想利用單一專案進行驗證，想法先記成 issue，AI 補完、我 approve，再開 session 實作。依據 github issue 開工。
v2：把這套流程打磨得更完善，補上 workflow，然後放置公開的共用 skill，套到其他專案。
v3：加上 issue-orchestration，讓主 session 開子 session 平行跑，減少 token 與讓主 session 成為主控台。沒有單篇文章，做法寫在 v2 的〈可以平行處理嗎？〉。
v4：底層換成 Matt Pocock 的 skill，去蕪存菁，只納入自己需求的些微改動。

Claude Code 側欄：一個主 session 底下掛著九個 issue session

Engineer

kiwi-walkv1｜我發想、AI 完善 issue，平行處理，生產力暴增

部落格的想法先記成一句話的 GitHub issue，AI 確認過 codebase 再把它補完，我在 issue 留言裡跟 AI 來回，而且一定要有 mermaid 流程圖與 mockup。三個狀態 label 分工：ai-enhanced 是 AI 負責，approved 只有我能設，進入 approve 就代表我認可這份 plan，交給新的 Claude Code session 實作、發 PR 附上驗證。approved 的 issue 一次開三個 session、各自一個 worktree 平行做，做完再請同一個 session 把過程寫成文章。

2026-10-20 到 10-24 做過的所有決定排成一張全景，劃掉的是後來改掉的

Engineer

v2｜把 issue 工作流制式化成共用 skill，spec 放 issue、驗證放 PR，靠 GitHub 接住每次改方向。就算換 session 也接得上！

把 issue 審核流程做成公開 plugin 套到四個 repo，label、Grill、審查輪數、文章交棒、voice 都在實測後改過。

一張 issue 從頭到尾的流程：Matt 的 triage、to-spec、to-tickets、implement 之間，穿插 kiwi 的 issue-ship、article-request、post-write

Engineer

v4｜把 issue 工作流程的底層換成 Matt 的 skill，捨棄笨重的部分，只留 spec 與 implement

底層換成 Matt Pocock 的 skill、自己只留他沒有的，步驟越來越精鍊：權衡後拿掉白名單和所有自動 merge，再把文章 label 也退場。