Files

T

Leo 25cb4d1f63 feat: v1.2.0 — issue 處理指引 + pre-write-guard 定位釐清 + 開發 wiki 隔離

issue #1：新增 /issue-handle slash command，CC 處理 GitHub issue 的
普世指引——讀回自己 repo 直接做、跨 repo 發要先問人、禁掛 Actions/cron
自動輪詢（會觸發 GitHub 異常偵測）。屬共用指引，install/update 不分模組裝。

issue #2：pre-write-guard.sh 釐清定位為「按需手填的空插槽」，非裝上就
生效的警察。檔頭明講有 CC 在場時直接叫 CC 寫貼合的 guard 更好；install/
update 安裝時提示「預設不攔，要手填才生效」，消除安全錯覺。hook 執行維持
安靜不洗版。

另：repo 自己裝了一套開發用 wiki（內部記錄），與 template/ 成品範本實體
隔離，.gitignore 排除 .claude/wiki/、.claude/hooks/、.claude/VERSION，
不推 GitHub。

升版 1.2.0，CHANGELOG 記錄。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-23 12:20:23 +08:00

2.4 KiB

Raw Blame History

description

description
處理本 repo 的 GitHub issue（讀/回/結案），跨 repo 發要先問人

/issue-handle — GitHub issue 處理指引

你（CC）可以、也該主動用內建的 gh CLI 讀寫自己 repo 的 GitHub issue。很多人不知道這件事——gh 已內建認證，零開發、零外部依賴。issue 同源於 repo，比 Notion / Sheets 更適合做交辦與待辦，不必引入外部 SaaS。

這份指引分三層，界線要守住。

1. 讀 / 回 / 結案（普世基本功 — 直接做，不用問）

對自己這個 repo，主動處理 open issue：

gh issue list --state open          # 看有哪些待辦
gh issue view <n>                   # 讀完整內容
# …實作…
gh issue comment <n> --body "做了什麼、怎麼決定的、改了哪些檔"
gh issue close <n>                  # 確認解決後結案

回覆要有料：說清楚做了什麼、為什麼這樣決定、動了哪些檔，而不是只回「done」。 issue 作者（可能是另一個 repo 的 CC，或人類）要靠你的回覆判斷對不對。

2. 發 issue 給「別的 repo」（要先問人 — 不可擅自）

當你發現別的 repo 有值得修正的地方時：

❌ 不要擅自 gh issue create -R other/repo … ✅ 先問人類：「我發現 X repo 有 Y 問題，要我幫你去那邊發 issue 嗎？」得到同意才發。

理由：通用 template 不知道使用者對那個 repo 有沒有權限、想不想發。留一道人類確認最安全。（對自己 repo 開 issue 記待辦則可直接做——那是自己的 repo。）

3. flag 安全界線（最重要 — 絕不可越）

「有事才讀」，禁止自動輪詢。

✅ 想看 issue → 當下主動 gh issue list。
🚫 禁止掛 GitHub Actions / cron / webhook 去自動輪詢 issue。

為什麼這條是硬底線：自動輪詢 + 事件 fan-out 正是會觸發 GitHub 異常偵測、害你的 token 被 rate limit 砍掉的流量模式。template 給很多人用，這條界線必須守住，保護使用者不踩雷。需要「定期檢查」就由人類主動跑這個指令，不要自動化。

（可選）用 label 分來源

若想用同一套流程同時管「內部交辦」與「外部回報」，可建兩個 label： internal（協作/交辦）、user（外部使用者回報），靠 label 分流。這對通用 template 不預設——你的 repo 需要再建。

2.4 KiB Raw Blame History Unescape Escape