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

今天要解的問題

我之前在部落格 repo 測試了一套 issue 流程：想法先記成一句話的 issue，AI 補完 issue 上的 spec，我 approve 之後再開 session 實作、PR 附驗證（細節在〈我發想、AI 完善 issue，平行處理，生產力暴增〉）。想說這次成功後，想要開始將這個做成通用的工作流設計。

借鏡 mattpocock/skills（mattpocock-skills），我想知道 to-spec／to-tickets 能借什麼、我的 workflow 怎麼套到其他專案。想清楚之後要的是三件事：像 mattpocock 那樣放在 sean2249/skills 裡；對象以其他專案為主；而且要是完整的工作流，包含 issues、pull request、label。

skill 統一在公開的 sean2249/skills，要套用的對象是 coffee-review、art-tracking、food-picker、daily-tracking、commute-tracking，還有部落格 repo。

但公開 repo 有個限制：不能寫私人 repo 的名稱。所以部落格 repo 的名字只能寫在各專案 CLAUDE.md 的 Article target，skill 裡只放 placeholder。這也自然變成兩層：

• 通用 skill：流程本身，放在公開 repo。
• 每個 repo 一份設定：寫在各自的 CLAUDE.md。

而從 2026-10-20 到 10-24 這幾天，幾乎每個部分都是先加上去、實測之後再收斂或拿掉。

技術背景

幾個 GitHub 和 Claude Code 的限制，後面的取捨都跟它們有關：

• 私人 repo、免費方案：沒有 branch protection，API 回 Upgrade to GitHub Pro，所以原生 auto-merge 不能用。
• 公開 repo、免費方案：有 branch protection，有原生 auto-merge。
• 用 Action 的 GITHUB_TOKEN 合併：這種合併不會觸發 push 到 main 的部署 workflow。
• third-party plugin marketplace：預設不自動更新；這台 Mac 沒有 GitHub SSH，要設 CLAUDE_CODE_PLUGIN_PREFER_HTTPS=1 才裝得起來。

想法與取捨

每一格是一個決定，劃掉的是後來改掉的。

元件

工作流有兩個元件，分別是指示 claude 的 skill 與協助輪轉的 github workflow。

1. skill: 將發想、製作的 skill 作為通用性的 skill
2. workflow: 轉換 issue label 與設定相對應的 hook/pull-request 硬限制

如同 sean2249/skills 內的圖片，基本上功能的 context 會是依附在 github 裡面，spec 在 issue，實作驗證在 pull request 裡面。這樣的設計可以方便切換不同的 session，不仰賴 session context 的延續，意思是可以將 spec/implement 分開，甚至是可以做到平行化去同時完成不同的 issues。就算 spec 尚未完善，他的 decision 在 github issue 上，我也可以用手機或不同電腦拉下來繼續去跑。

更新與版本

• skill 的部分：將 sean2249/skills 做成 plugin marketplace，每台機器裝一次；plugin.json 不寫 version，每個 commit 都是更新。
• workflow 的部分： issue-status、risk-guard 這些改成 reusable workflow，各 repo 只留幾行 caller，一開始是指向 main，後來是指向 tag。

到了 2026-10-23，公開 repo 做安全審查時，審查者又提出 @main 的風險：一次合錯或帳號被盜，所有 repo 會同時跑新的、有寫入權限的 workflow。所以後來改成釘 tag（例如 @v1），每次升版手動 bump

升版時先看比對，再到各 repo 開 PR bump caller。這是指 workflow，而 plugin 本身仍跟著 main。

其他 GitHub 功能：

• 採用：原生 sub-issues 與 blocked-by，取代本文手寫的 Blocked by #N、## Slices，為此把 gh 升級到 2.102。
• 不採用：GitHub Project 看板。我說「TODO.md 是指 vault 的，與其他 project 無關」。
• GitHub 預設 label（bug、wontfix、good first issue…）：我說「都刪掉，而且之後如果也有 GitHub 預設 label 的話，也幫我刪掉」。dependabot 用的 label 保留。

Issue 上的審閱

因為 AI 用的是我的 gh 帳號，作者欄分不出誰寫的。所以在採用 patch 的做法：

• 本文上半是我的原文，下半是 AI 段，每次整段刷新覆寫。
• AI 每改一次就會留一則 🤖 AI <日期> 開頭的留言。
• 我的留言不加前綴。

捨棄的設計：

• 全部改用留言（計畫會散在好幾則留言裡）
• 另開 bot 帳號（要多管 token）。

決策在哪裡回答。

待決事項一律寫在 issue 本文的 ## Pending decisions，每題 A／B／其他的勾選框，我在 GitHub 上點；每題都勾完，workflow 自動把 status: needs-info 換回 status: raw。用留言回答也行。needs-info 的自動切換本來只看留言（我選的方案 A），之後加上「我編輯本文時」也會觸發。

同時也比較過 obie/skills 的 decision-docket（一個網頁集中所有待決事項，每題附推薦答案與「不回答會怎樣」），最後沒有採用，因為它把決策搬離了 GitHub。

所以除了決策外，會包含 UI 選項同一輪並排 2～3 版。

Grill issue 中的追問

我想過要不要直接裝 mattpocock 的 grill-me，最後選借方法、自己寫，目標是：剖析細節，詢問專業，找出可能風險與淺在優勢

接著針對下面我自己的反思：

我希望這個 agent 的話是一個 sub agent，然後全新的 context，然後去看這個 plan

這個 sub agent 回傳的東西理論上是要跟 main agent 互相去 negotiation……然後再請我去做最後的決策

決策的話，必須要明確定義說 A 說什麼，B 說什麼……我這樣去判斷它的好壞的話，我可能會更容易

如果可以的話，可能用表格呈現會比較好看懂

結果是：審查 subagent（全新 context、平行、每個專業角度一個）→ 和寫計畫的主 agent 協商（同意改／撤回／交給我）→ 交給我的用 A／B 並排表格（主張、理由、證據、選這方的後果）。表格不附主 agent 的建議，因為它就是 B 方，不中立。

Grill 的規模。 規模評估的 subagent 判斷整套「偏重，接近過度」，估計一張中型 issue 要 15～40 次 agent 呼叫。實測下來，coffee-review 一次 Grill（4 個審查角度＋協商）約 38 萬 token；部落格兩張文章卡開了 6 個角度，而且角度之間還互相矛盾。

因為真的太久，不論短或長，所以改成預設不跑 Grill，補完計畫就給我審；只有我加 grill label，或砍到動脈/單向門，如改到 auth、資料、workflow、secrets、計費時才跑。Risks／Opportunities 也只在跑 Grill 時寫。

最後還有分級（L0 直接做）：不做了。在 Grill 改成選用之後，剩下的 L0 會和「只動白名單路徑就自動合併」重疊。

PR 審查

完成了 spec，跑完開發後，就是 PR 審查了。PR 必需要有 review，所以第一步就想直接用 claude 內建的 code-review, security-review，由 issue-implement 開 PR 後自己跑，最多 3 輪；有沒修掉的資安問題，不能設定成 risk: low。

第一次實測在 coffee-review，第 3 輪留下 2 個 medium，照當時的規則「達上限，交給作者」。一開始針對這個，是想說超過三輪就停止，修完這次就不再送審，避免無限累積的輪迴。

但後來對照 Claude Code 團隊的做法（anthropic-code-review）裡〈收斂〉那段：發現他們三輪後是「作者重新考慮做法」，另外還有「只審新的 diff」、「標出 bug 類別、同類一次修完」。所以我前面所提到的不再送審，可能會掩埋重要的做法問題，假使是做法問題，導致修完不完的 bug，那直接合併，可能會導致未來的技術債，所以就要打掉目前設計，回去重審做法的另一個方向。

最後的規則：

1. 第 2 輪起只審新的 diff。
2. 每項 finding 標類別，同類一次修完。
3. 第 3 輪只有 low → 全修、不再送審。
4. 第 3 輪有 medium 以上 → 不修補，PR 轉 draft，整理三輪 findings 和可能的替代做法，issue 回 status: needs-info，由我決定要不要打掉重來。

再回頭看那張 PR：第 3 輪那兩個 medium 已經照舊規則修掉了（修正本身沒審過）。我決定照新規則處理：「先轉成 draft，issue 回到 needs info，重新再跑一次討論」。

2026-10-23 做了一次實測回顧。那張卡的確認框文字，到 PR 才看到，我才發現整個提示都不需要。

在實作後發現功能上的確認框文字不符合我的需求，再修改完成後，提到後續，claude 提出可在 draft PR 同步給我看，但我覺得這問題需在實作前解決。需要在 issue-enhance 的 mockup 盡量畫出所有 UI 的變化，縱使我實際操作後，會有其他想法，我也覺得是必要的。這包含了使用者看得到的實際文字與觸發時機，Acceptance criteria 皆需滿足。計畫沒定到、又會影響使用者看到的東西時，才在對話中問我，算例外，需要盡量減少。

同步在這次 coffee-review PR 一起改的還有：

• 作者改範圍時，審查輪數歸零（只有作者改範圍才算）。避免修改完後，直接被省略
• 母 issue 寫明要 approve 哪一張子 issue。避免關錯檔案
• article-request 交棒時，連關聯 issue 的 label 一起換。

額外納入的計畫查核。 因為實作有發生兩次抓到的問題，其實是來自於計劃不完善的情況：一張計畫取時間字串前 7 個字當月份，忽略了 UTC 時區；另一張沒注意到讀取 API 要帶旗標才回風味欄位（實作時被審成 high）。

其實很像有兩派做法：動工前對齊與動工後證明。我很貪心，我全都要。

所以我在 issue-enhance 加了「計畫查核」（Step 5d），和 Grill 分開：

• 時機：每張都跑，在所有決定都定案、計畫寫完、標 ai-enhanced 之前。
• 誰查：1 個全新 context 的 subagent，只拿到 issue 網址和 repo，查計畫和程式碼對不對得上（file:line、漏掉的呼叫點或欄位、時區、驗收條件能不能驗、有沒有違背已定的決定）。
• 查到之後：事實問題 AI 直接改；要選做法時，選最符合已定決定的那個，記成「AI 預設（計畫查核）」附理由，我 approve 時可以推翻。每張只查一輪。
• 唯一例外：計畫和我已經做的決定互相矛盾，AI 不能推翻我，才回 needs-info。

上線後的前幾次（2026-10-23～24），四張卡分別查出 10、8、4、1 處，全部由 AI 直接修掉，沒有一張因此多出要我勾的題目。

另外從〈從來來回回到共同語言〉借來一件事：PR 附「行為摘要」（執行輸出、做了什麼、刻意沒做什麼），我先看摘要決定放不放行，不先讀 diff。

合併

想要參照 Anthropic 的想法，將 PR 設計成低風險的可以直接 auto-mergeable，對應列出來的選項：

但如同上面提到的，私人 repo 在免費方案沒有 branch protection，且原生 auto-merge 不能用。所以只好改成 session 需等 CI 全綠之後自己合併（merge mode: session）。

也沒用 Action＋GITHUB_TOKEN 自動合併，因為那種合併不會觸發 push 到 main 的部署 workflow。

文章交棒

部落格原本就有「做完一件事寫成文章」的習慣，但其他 repo 的工作要怎麼變成部落格的文章？要如何交棒給不同 repo 的部落格？

關鍵是「文章素材」要在開發 session 內就寫進 PR，因為之後寫文章的新 session 看不到當時的對話。所以就想說繼續徹底的依附在 github 內部。

這套也要取代我原本用在 kiwi-daily 的兩支 skill，daily-devlog 和 daily-wiki-post。daily-devlog 是針對開發，而 daily-wiki-post 則是「不是只針對 vault 頁，……用介紹文章的角度來撰寫」。

其整體順序如下：

1. (專案 REPO) 為了不忘記交棒，帶 article-status: request 的 PR 一合併，workflow 就自動換成 pending，並留言提醒我（「幫我加上自動標記」）。
2. (專案 REPO) 因為丟出文章整理素材的 skill 不會在部落格內，而是透過 article-request（提出文章需求）。此 skill 會詢問使用者要以那種架構來整理素材
3. (–AI–) 協助將文章素材整理後，丟入到部落格 repo 開 issue，並且打上 status: raw & post-type: {POST_TYPE}，然後將原本在專案 repo 的 issue 的 article-status: pending 改成 article-status: handoff，代表已經轉交出去。
4. (部落格 REPO) 針對 status: raw & post-type: {POST_TYPE} 執行 post-write 來將此文章寫出來。

文章類型 (post-type) 一開始只有 devlog、intro 兩種，書評、藝評、主題研究的差異放在部落格規則裡。後來為了增加文章的差異，改成四種 devlog、intro、review、research。來源是筆記時一律忠實轉寫，並附「來源對照表」：來源每一段寫進文章哪裡，沒寫的附理由。

試寫時改文章類型。 此外，在實際運行這過程時，一開始是我自行選的，但後來發現這四種文章類型，我還沒有很好的做判斷。像是杯測表比較那篇（〈整理五張咖啡杯測表的差異〉）原本選 research，但第二輪 Grill 後卡在「標題寫評分哲學，但講評分哲學的那節被我刪了」。因此改成 post-type: intro。來源是並列比較頁，沒有探索過程；去掉設計哲學與延伸觀察後，剩下的其實比較貼近事實，適合「介紹這幾張表是什麼、差在哪」。

同時還有另個案件，儀式那篇（〈儀式開頭調頻〉）從 intro 改成 post-type: research。來源有明確的核心問題、每條研究附但書、有「未查到」與想試的實驗，這些用 intro 寫會被當雜訊刪掉；改成 research 之後，這些探討都有地方可收納，並且都有答案。

基於這些狀況，我想說在開文章卡時，就請 AI 依來源特徵建議類型：

• 決策過程 → devlog
• 核心問題＋推論＋待解問題 → research
• 對作品的評價 → review
• 事實與比較 → intro

附上來源原句當理由和次佳選項，我勾選確認。這裡可以附建議，因為選類型時還沒有計畫方。

Label 的不斷調整 基於辨認方便，針對 label 改了三次，上面是最後結果，過程如下：

1. article（意圖）＋article: pending／requested（進度）＋article: devlog 等（類型）。但這樣進度和類型共用前綴，很容易混淆。
2. 換前綴：article-status:／article-type:。
3. 我說「article-status -> request, pending, handoff；handoff 代表已經交出去，算結束；request 代表這個是需要處理」，以及「article-type -> post-type」、「post-type 這個 label 只能出現在部落格裡面」。將 article 視為動作，post 看作靜態的類型。

寫文章與 voice

寫文章流程：

1. post issue 會包含專案的 issue 與 PR
2. 在 issue 裡面一樣是走 issue-enhance 跑過 status: raw -> status: ai-enhanced -> status: approved
3. 而在實作上不走 issue-implement，而是走 post-write 這個 skill，這個特別為文章特化的 skill
4. AI 推上去之前，會先給我在 session 檢查
5. 我會全部修改一遍。完成後會跟 AI 說
6. AI 會協助幫我上圖到 CDN，並且記錄我的 voice。這個 voice 會記錄我寫作上的個人喜好

針對人工編修&voice

article-write 寫完草稿先不開 PR，讓我在編輯器裡改；我改完，AI 依我的刪改同步更新來源對照表，我的修改單獨 commit。

接著比對 AI 草稿和我的修改，只挑可以通用的寫作習慣，寫成「規則＋改前改後例子」，我確認後才加進部落格的 docs/voice.md。

舉儀式那篇走完編修流程（2026-10-23 合併）為例：我改了標題、刪了但書、開場不再是問句，還要了一張 cover。整理出的修正清單我確認後，改了這些：

• 改名：只把 article-write 改成 post-write，article-request 不改。用名字分開「從外部 repo 交棒」和「在部落格寫貼文」。
• 編修方式：不用 open_in_editor，給可點的檔案連結，用內建編輯器就好；我說「改好了」，由 AI 代我 commit edit: 作者編修，AI 之後的修改另外 commit，然後才開 PR。
• 作者編修與驗收條件：我的編修蓋過驗收條件，照我的版本，PR 的對應項不打勾並註明「作者決定」，不改回去。
• 來源對照表對兩次：voice 套用後一次、我編修後一次，標「作者編修刪除／改寫／新增」。
• 每篇至少一張 cover：來源沒圖，就用文章已有的內容畫示意圖。部落格 conventions 原本寫「沒合適的圖就不放」，已經改掉。
• 標題：草稿只排一個，我改完再依定稿推薦三個。
• wiki: 連結：寫之前由 post-write 搜部落格，連到已發布文章裡的某一節（例如《FUN 的力量》的「真正的樂趣」）；issue-enhance 不搜。
• kiwi-voice：改成 skills repo 的共用 skill，只放流程（套用／收納）；規則放各 repo 自己的 voice 檔，CLAUDE.md 用 Voice file: 指過去。收納的草案分「新增規則／補例子／只屬這篇不收」，我勾過的和文章同一個 PR、另一個 commit。轉寫我筆記的文章，套用 voice 時可以改措辭，不能刪我的句子（這次 voice 就刪掉了「不靠神性」那句）。
• 貼文 PR：標 risk: low（部落格把 content/blogs/ 加進白名單），但 AI 仍然不合併，由我按。
• 審查：改由全新 context 的 subagent 做。貼文 PR 一個文字審查者（事實對來源、連結、格式）；issue-implement 的 code review 與 security review 固定是兩個平行 subagent，只給 PR 網址，不留言、不推 commit，由實作 session 判斷與修，每輪換新的審查者。

但 voice 檔也開始膨脹

當時部落格的 docs/voice.md 收納約 9 篇後，已經 21KB、23 條規則、66 個範例，「語氣」一條就有 14 個範例；套用時每次都整份讀進來。膨脹主要來自範例，不是規則。

所以調整以規則為主，範例是協助：

• 分檔：規則檔只放規則，每條最多 2～3 個代表性範例，套用只讀這份；其他範例放 docs/voice-examples/，一條規則一個檔，只在收納和整併時讀。
• 範例上限：同一件事再出現時不加範例，在規則後記「再次確認 N 次」；新範例只在展現新面向時才加，並取代最弱的舊範例。
• 收納紀錄交給 git：commit 訊息 voice: 收納 <post>，拿掉表格。理由和 log 月檔退場一樣。
• 大小上限：預設 8KB／25 條，repo 可以用 Voice limits: 覆寫。超過就要先整併，才能加新規則。整併是 kiwi-voice 的第三個分支：合併重疊的規則、細節收斂成原則、連續 10 次收納都沒被確認的規則提議退場，每項都由我勾選。
• 矛盾處理：優先順序是我寫的句子 > 規則 > 範例。範例和規則矛盾，算範例的瑕疵，留到整併時列給我決定；收納時新的編修和既有規則衝突，不能直接加規則，要做成選項（縮小規則範圍／加例外／舊規則退場／只算這篇的特例）。AI 只負責找出矛盾、整理成選項，不自己判斷要怎麼解決。

第一次整併：21KB／23 條 → 13.9KB／15 條，例子一個都沒少（搬到 7 個例子檔）。上限設成 14KB，只比現況大一點：讓收納很快就提醒整併，每次要我看的提案才不會太長。

公開 repo 的安全

若是因為 context 在 public repo，會不會容易導致程式或系統被攻擊？盤點的結果：程式碼本來就公開，issue 裡的 file:line 和做法多給的資訊很少。可能的真正風險有三個：

1. 外人開的 issue 會被自動標成 raw，issue-enhance 用我的 gh 帳號照著讀（prompt injection），然後就扔上去 issue。
2. 第 3 輪退回時公開整理 findings，等於提早公開還沒修的漏洞。
3. 公開 repo 的 issue-assets 截圖和執行輸出，可能帶到個資。

基於上面三點，及目前沒有與他人協作的可能，所以最後決定的六項：

1. Action 只把 owner 開的 issue 標成 raw，bot 開的直接跳過。
2. skill 只處理 owner 的 issue 與留言，外人的內容一律當資料。
3. setup 在各 repo 的 .claude/settings.json 加 deny 規則，擋讀取機密檔。
4. 公開 repo 的資安細節只在對話中說。
5. 截圖用假資料。
6. risk-guard 把 .claude/、CLAUDE.md 也列為不能是 low。

plugin 不附 PreToolUse hook，因為誤擋的代價比效益大。

三個 repo 都用 setup 的修復模式升級到 v1。deny 規則只放 deny，不放 hooks 或 allow；個人用的 allow 放在不進 git 的 settings.local.json。vault 的 skill 本來就要讀 .env.local 拿 API key：deny 規則照樣擋 Read，skill 改用 Bash export 進 shell，CLAUDE.md 寫明不能印出 key。

部落格也把 content/series/ 加進低風險白名單。

導入順序

1. coffee-review：setup → issue-enhance 實測 → Grill 實測 → issue-implement 實測。
2. 部落格 repo：setup → 試寫儀式那篇（research）→ 杯測表那篇（intro，測 post-write 新版）。
3. llm-wiki vault：setup（2026-10-23）→ 杯測表那篇（〈整理五張咖啡杯測表的差異〉，vault 頁 → 文章）→ log.md 那篇（〈llm-wiki 從 log.md 到 git commit 的實作〉，vault issue → 實作 → 文章，走過 risk: high）。
4. skills repo 本身（2026-10-24）。
5. 其他 4 個專案。

vault 因為他是屬於 llm-wiki，我的第二大腦，與其他專案不是單純的程式碼而已，因此 setup 是我在 session 裡用選擇題回答：

• merge：選「放寬」。hook 新增規則 0d：gh pr merge 只在 PR 恰好標 risk: low、不是 draft、檢查全綠、帶 --merge 時放行，查不到 PR 就擋；推 main 仍然擋。「main 只來自 obsidian-git 與我」改寫成「session 只合併 risk: low」。沒選：全部由我按（risk 只當標示），以及把白名單留空。
• 白名單：逐域列出 raw/、wiki/、logs/、index.md，加上 hubs/、log/。
• 私人路徑：我決定把 finance/ 裡私人的部分搬到 personal/，finance/ 改成財經領域。personal/ 不列白名單，CLAUDE.md 規定動到就 risk: high，issue／PR 只寫路徑、不引用內容。
• TODO.md 分工：## Coding／## Mods 的 34 項搬成 34 張 raw issue（不設母 issue），TODO.md 刪掉這兩區。之後 issue＝建造型工作，TODO.md 只收內容管線。
• Article target：接部落格。
• 盤點時發現：CLAUDE.md 原本說 hook 規則 0c 擋 gh pr merge，實際只擋 push。

skills repo 本身，一開始沒想要納入，但後來想說一起好了，只是也因 repo 的特性，所以有調整。

• 白名單：只放 README.md；skills/**、.claude-plugin/ 永遠不能是 low，因為 SKILL.md 會用我的帳號在所有 repo 執行。
• merge mode：選 auto（公開 repo 在免費方案也有 branch protection 與原生 auto-merge）。Article target 選 none。
• 自己的 caller：取名 self-*，釘 tag（@v2），不用 ./ 呼叫 repo 內的版本。用 ./ 的話，PR 就能改掉檢查自己的 risk-guard。
• 發版流程：CLAUDE.md 加上「打 tag → 各 repo（含自己的 self-*）bump caller」。也釐清了 tag 只管 4 支 reusable workflow；SKILL.md 改了，各機器 /plugin 更新就生效，跟 tag 無關。v2（v1.0.1）只改了 skill 和 README，其他 repo 停在 @v1 沒有影響。
• 第一張 issue（中文 README）：另開 README.zh-TW.md，英文仍是首頁；翻說明和表格，發版段落連回英文；流程圖只翻 alt 與 mermaid 文字版；同步用 CLAUDE.md 規則＋Action 強制檢查；專有名詞保留英文；中文檔進白名單。拆成兩張子 issue。

可以平行處理嗎？

我想做成平行處理、可以交接，列了一套操作步驟：

1. 每張 raw issue 開一個 child session 補計畫。
2. main session 告訴我哪些要複查。
3. 我 approve，並標出要寫文章的。
4. 新 session 找 approved 的，開 child session 實作。
5. 我看圖合併。
6. 交棒寫文章。

平行處理是在 main session 裡請 Claude 開 child session，交接只靠 GitHub issue（label＋本文），child session 之間不互相溝通。

再來是平行處理的量，是我個人的問題，若是一次產太多，堆在我面前，我只會放棄，所以有控制批量的規則

• 每批只派我一兩天審得完的量（約 3 張）
• 實作時跳過被 blocked-by 擋住的，同一個 repo 一次 1～2 個。

10-23 一整天都用這個方式跑：一個協調用的 main session，同時開好幾個 child session，分散在 coffee-review、部落格、llm-wiki、skills 四個 repo。

實際的分工：

• child session：各自在自己 repo 的 worktree 裡跑 skill，做完一輪就回報。
• main session：收到回報後，先看過 PR 或 issue 本身再轉述給我，然後決定下一步：轉交我的回答（SendMessage）、開下一個 child session、封存做完的 session。
• 我：只在一個視窗裡下決定。需要我勾選的事，一律寫在 GitHub issue 的勾選框；需要在對話中回答的（例如 deny 規則的確認），才到那個 child session 裡回。

一天下來，同時在跑的 child session 大約 3～7 個。規模受三件事限制：

1. 我審閱的速度。
2. 磁碟空間：每個 worktree 要 5.4GB 以上的可用空間才開得起來。
3. main session 自己的 context。

實作

label

article-status: 只出現在工作卡，post-type: 只出現在文章卡，同一張卡兩個都有就代表卡有問題。

等待中的卡

gh search issues --owner sean2249 --label "status: ai-enhanced"

一行列出所有 repo 裡等我審的卡，所以不用另寫一支 skill。

deny 規則

vault 升級到 skills v1 時，讀機密檔的 deny 規則我選精簡的 9 條：

• .env、.env.*、.envrc
• SSH key、.netrc、.git-credentials
• gh auth token、printenv

沒用完整的 25 條，因為 vault 根本沒有 .pem、.tfvars 這類檔案。.env.local 也擋：Claude 不能用 Read 打開它，skill 要 key 時照舊用 Bash 讀進 shell（deny 規則不擋 shell 指令，所以這只是防手滑）。

四種路徑

我想確認文章流程的每條路都走過：

理論上應該會有 coffee-review 的一種情況，跟 blog repo 的一種情況，還有 LLM wiki 的兩種情況，所以總共會有四種情況。

2026-10-23 開始，10-24 全部走完：

• coffee-review：raw issue → 實作 → 部落格文章。 一張母 issue 的三個子 issue 都上線。我說「希望將 sub-issue 跟這個 main issue 一起合併成一個 article」，原本分開的兩張文章卡關閉，三刀合成一張，寫成〈將用咖啡 app 紀錄的痕跡都完整統計出來〉。
• 部落格自己的功能：raw issue → 實作 → 文章。 我指定部落格的 issue-enhance 拿那張「表格在桌機太窄」的卡來測，卡上加 article-status: request，實作合併後交棒成文章卡，寫成〈文章表格拉滿欄寬〉。
• vault wiki 頁 → 部落格文章。 杯測表、儀式兩篇走舊流程，log 月檔退場那篇（〈上 git 一個月後，停掉照抄過來的 log 月檔〉）走新流程。
• vault raw issue → 實作 → 文章。 停寫 log 月檔那張卡跑了 8 個決策、兩輪 Grill、計畫查核後 approved；第一張 PR 合併，第二張退回兩次、多了決策 9～11 後合併，寫成〈llm-wiki 從 log.md 到 git commit 的實作〉，是 log 月檔那篇的續集（前一篇寫決定，這篇寫實作）。

走的過程中我問了「這個為什麼沒有自動合併」。不是出錯：貼文 PR 標 risk: low 只代表不用細看 diff，照儀式那篇之後的決定，由我按合併（文章用我的名字公開）；而且部落格是私人 repo、免費方案，本來就沒有原生 auto-merge。規則沒改。

我也想把 docs/voice-examples/ 和 voice.md 加進部落格的 risk low：兩者都在 docs/ 底下，本來就在白名單。voice 的 PR 會變 medium，只會是因為同時改到 CLAUDE.md（risk-guard 寫死不能是 low）。

還開著的

• 個人專案工作流的設計頁停在 10-20 的版本。等 coffee-review、部落格、vault 三個主要 repo 都導入並驗證後再一次重寫，定位成進階版：v1 已經是〈我發想、AI 完善 issue，平行處理，生產力暴增〉（單一 repo、三個狀態 label、平行開 session），v2 寫跨 repo skill 化之後新增的部分（2026-10-23 決定）。vault 這邊也還沒回寫。
• 兩篇試寫都已發，docs/voice.md 與本地 kiwi-voice 也處理了。剩我到 claude.ai 停用 daily-devlog、daily-wiki-post，並更新各機器的 kiwi-skills plugin。
• 杯測表那篇實測時，發現部落格表格在桌機太窄（PaperMod 的 table { display: block }），另開了一張卡，就是上面的表格那篇。
• coffee-review 的 security advisory 草稿還沒處理。
• 本機 skills repo 有 2 個沒推的 commit（匯入 22 支 vault skill），推上公開 repo 前要先檢查私人內容。

踩到的坑

main／child session。 實際跑起來碰到三件：

• child session 的筆記預設寫到「開它的那個 session」的資料夾，結果筆記分散在兩處。
• child 回報「已寫」不代表真的寫了，封存前要核對。
• 這台 Mac 的 plugin cache 停在舊版，child 跑到舊規則。

試寫來源。 我推薦的試寫來源，兩篇都已經發過文（〈從來來回回到共同語言〉和〈我發想、AI 完善 issue〉），session 開工前才發現。推薦來源前，應該先查部落格。

追加修改。 skills repo 的第一張 PR，我在追加修改前就 merge 了，追加的 commit 只能另開一張。

修復模式跑過才知道的：

• 必過檢查改名，要在合併升級 PR 之前。
• gh label create --force 會把我寫的中文說明蓋成英文。
• macOS 內建的 git 2.41 不支援 worktree add --orphan。

Copilot 額度。 Copilot 的 review 額度用完，每個 PR 都多一則「無法審查」的留言，不用處理。

確認框。 issue-implement 第一次實測時，計畫經過 Grill、我也 approve 了，看到 PR 裡確認框的字，才發現整個離開提示不需要：

不用確認框，默認會儲存，使用者開起來被洗掉，應該是可以理解的

重開表單時，改照前一張卡的草稿橫幅。在 issue 階段，計畫裡的確認框文字只是一行描述；到 PR 才看得到實際內容。這也是〈從來來回回到共同語言〉的例子：issue 階段的 mockup 沒有畫確認框。

只信 owner。 我要求再用 security review 和 code review 檢查安全那批修改有沒有漏掉的問題。兩個全新 context 的審查者抓到兩個 high，都是那批修改本身沒擋到的：

• post-write 會照「留言有決定就照留言」寫文章，卻不檢查留言是誰寫的。
• 外人可以偽造 🤖 AI … Already done 留言，把我的 issue 從批次裡排掉。

教訓是：「只信 owner」要落到每一個讀留言的地方，而且要用 jq 過濾，不能只靠一句說明。

文章素材裡的漏洞。 第一次用上安全規則時，coffee-review 一張 PR 的「文章素材」寫出了一支 API 沒驗證輸入、可以直接灌假資料，等於在公開 repo 說明一個還沒修的漏洞。我說「開」issue 處理，但公開 issue 又會公開漏洞，所以改開私密的 security advisory 草稿，並把那句從 PR 本文和部落格的文章卡拿掉。PR 本文的編輯紀錄 GitHub 會保留，要我手動刪。

中途的調整。 coffee-review 的 Grill 實測卡退回後，我說先放著，改拿另一張母 issue 的子 issue 實測；那張母 issue 第一刀時，我 approve 了母 issue，真正要做的是子 issue，後來就把「母 issue 寫明要 approve 哪一張」寫進 skill。

小結

這套工作流現在跑在 coffee-review、部落格、llm-wiki、skills 四個 repo，文章流程的四條路都走過一次。四條路走下來的觀察：

• 每條路至少都有一次中途改方向：coffee-review 三個子 issue 合成一篇、表格那張原本只是 bug 卻拿來測文章流程、停寫 log 月檔的第二張 PR 退回兩次。流程撐得住改方向，靠的是決定都寫在 issue 上，換 session 也接得上。
• 文章卡的大綱都跑了計畫查核，四篇都沒有因為查核多出要我勾的題目。
• 「第 3 輪有 medium 就退回」在停寫 log 月檔的第二張 PR 觸發兩次，兩次我都選擇砍規則、降低攔截率，而不是加防護：「攔截率可以最弱，但我會希望我的電腦是安全的。」細節在〈上 git 一個月後，停掉照抄過來的 log 月檔〉。
• 決策 8 也被我推翻：原本為了能單獨 revert，把 hook 拆成獨立 PR，實作到一半改成「合在一起一次痛完」，之後同類工作預設一張 PR（實作經過在〈llm-wiki 從 log.md 到 git commit 的實作〉）。

其實上面的內容在我撰寫的同時，在精進 workflow 中又參考了 Matt 的 skill，可能會將 issue/pr 的資訊從 github 移除，還是回歸到 session。主因即是外洩我的設計或是我做到一半的功能，雖然透過 AI 都可以查出來並且破解，但增加複雜度或麻煩，始終有效。

所以以後可能就不會有這篇工作流所提到的 checkpoint，就是一個 session 從 issue 到 PR，可以隨時 Archive&re-pick 的模式。但仍可能會透過 local 端的檔案系統同步來達到原本的 issue/PR 溝通的目的，即創建 html 來滿足這個勾選，即上面提到的 decision-docket 可能會借鏡來使用看看。不過這個版本目前還在研究，還沒想到個好方法。