批次功能

此工作流程的接收端。另一半是 work-issue。

你不是在傾倒一份待辦事項。你是要將粗略的想法轉變為代理人可以直接規劃的議題，而不需要重新進行你的探索。這意味著先逐一辯論每個項目，然後一次核准，最後再提交。

開始時宣布： 「我正在使用 batch-features 技能將此清單轉換為議題。」

設定

shared/ 是此技能旁邊的目錄 — 安裝時為 ~/.agents/skills/shared/，或是在檢出目錄中為 ../shared/。如果 shared/... 路徑無法解析，請使用另一個。

️讀取儲存庫：根目錄下的 AGENTS.md（或 CLAUDE.md）。其中的慣例具有約束力。
️讀取 .agent-skills/config.json（如果存在）；否則讀取 shared/config.md，詢問首次執行的問題，然後寫入檔案。
️讀取 shared/tracker-adapter.md、shared/labels.md 和 shared/issue-template.md。
️偵測追蹤器。查看現有標籤和議題，以便新建立的文件能夠相容。
️範本。 檢查專案是否已有議題範本（.gitlab/issue_templates/*.md、.github/ISSUE_TEMPLATE/*.md）。如果有的話，使用它並將其路徑記錄在配置中作為 issueTemplate。如果沒有，請注意你將在最後提議將 shared/issue-template.md 提交到專案中。

逐一處理清單中的項目。對於每個項目：

用自己的話重新陳述： 它是什麼、服務於誰、為什麼現在要做。在議題內文中的「意圖」下方保留原文作為逐字引用 — 即使其餘部分是英文。
提出具體的解釋。 不要問「你想在這裡做什麼？」，而是說「我認為這是 X，因為 Y。如果你指的是 Z，請說一聲。」
最多問兩個問題。 每個問題必須具體，並且每個問題都必須附帶一個使用者可以用一個單詞接受的預設答案。問最能改變建構內容方向的問題。如果使用者要求全面審查，可以多問；否則兩個為限。
確定兩件事： 驗收標準（每個都是可觀察且可檢查的）和類型（feature / fix / refactor / chore）。沒有其他事項 — 沒有規模、沒有領域、沒有依賴關係。

如果一個項目在辯論後仍無法確定，請將其標記為 status::blocked 並附上 needs spec 註記，而不是進行猜測。提交一個模糊的議題比不提交更糟糕。

在所有項目都經過辯論之前，不要進行提交。

在最後一個項目之後，為整批項目呈現一個表格：

| # | 標題 | 類型 |
|---|------|------|
| 1 | ...   | feature |

然後請求核准。使用者可以編輯標題、刪除項目或更改類型。在此之前，不會提交任何議題。

對於每個已核准的項目，按照使用者偏好的順序（預設為建立順序）：

使用追蹤器 CLI 建立議題，內文優先使用專案的範本（如果有），否則使用 shared/issue-template.md。標題和內文使用配置中的 language（預設為 en）。
套用標籤：status::ready 和 kind::<kind>。記錄議題編號。
回報議題的 URL。

如果使用者的清單暗示了順序（例如「X 然後 Y」），請在議題內文的「備註」下方註明 — 不要建立依賴關係或標籤。

如果專案沒有議題範本並且使用者接受了你的提議，請執行 shared/issue-template.md 提交到追蹤器預期的路徑（僅一次），然後再提交議題。不要無聲無息地建立它。

最後，列印：