Revert "feat(code-action-docker): 重建為問答式五階段流程，詢問名稱／輸入輸出／目標後以 Node 實作並統一訊息格式，串接 doc-funcs"

This reverts commit 3a9819f6d8.

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "jsc",
-  "version": "0.0.4",
+  "version": "0.0.1",
   "description": "JSC 程式碼工作流 plugin（Claude Code / Codex / Antigravity / OpenCode），提供 RPG 攻防式 git diff review、裁決結果歸檔、Gitea AI review findings 修復/PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步，以及 action / Dockerfile 標準化流程；於 Claude Code 以 /jsc: 前綴呼叫。",
   "skills": "./skills",
   "author": {

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "jsc",
-  "version": "0.0.4",
+  "version": "0.0.1",
   "description": "JSC 程式碼工作流 plugin，提供 RPG 攻防式 git diff review、裁決結果歸檔、Gitea AI review findings 修復/PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步，以及 action / Dockerfile 標準化流程。",
   "skills": "./skills"
 }

README.md

@@ -44,7 +44,7 @@ code/
 │   ├── code-issues/         # 彙整議題 TODO（影響範圍小→大）+ 逐項實作 + 留言進度
 │   ├── code-nuget/          # C# / .NET NuGet 套件更新 + build 驗證
 │   ├── code-sync/           # 依擁有者批次 clone／更新 Gitea 專案
-│   ├── code-action-docker/  # 問答式打造 docker action（Node 主程式）+ 串接 doc-funcs
+│   ├── code-action-docker/  # action 容器化（Node 主程式）+ 串接 doc-funcs
 │   ├── code-action-composite/ # composite action 標準化 + 串接 doc-funcs
 │   ├── code-image/          # Dockerfile 整理成六步流程 + 串接 doc-funcs
 │   └── hello/               # 範例 skill：驗證安裝、新增 skill 的範本
@@ -205,7 +205,7 @@ rm -rf ~/.config/opencode/skills/{code-review,code-review-archive,code-review-re
 
 ### `code-issues`
 
-處理一或多個 Gitea 議題的實作流程，五階段：**(A 工具選擇)** 檢查 `tea` 與 `GITEA_TOKEN`，詢問要用 `tea` 或 Gitea REST API（**已選定則跳過**）；**(B 確認專案)** 詢問議題所在專案 owner/repo，可用目前 repo 的 origin 當預設（**已知則跳過**）；**(C 選擇議題)** 列出開啟中議題後詢問要處理的議題編號，**一個或多個**（**已提供則跳過**）；**(D 彙整 TODO)** 讀取議題描述與所有留言、彙整需求，盤點既有 checklist 後整理 TODO 列表並依**影響範圍由小到大**（XS→XL）排序，既有 TODO **不足以達成議題需求時補上新 TODO 並附加到議題描述**的 `## TODO` 區塊；**(E 逐項實作)** 依排序實作每項 TODO 並驗證，**每完成一項就勾選描述 checkbox 並留言進度到議題**，全部完成後留下總結留言；議題**有母議題**時，實作完成後把母議題 checklist 中**引用本議題的 TODO 項目一併勾選**並留言告知（無法明確對應的項目不硬勾）。議題若**屬於專案看板**且有「分析中／待處理／進行中／待測試／已完成」欄位可調整，依處理進度**同步移動議題欄位**（彙整需求「分析中」→ TODO 確定「待處理」→ 開始實作「進行中」→ 實作完成且驗證通過「待測試」；「已完成」僅在使用者確認時；不屬於專案、無可對應欄位或 API 不支援則回報並略過）。**全程不建立任何草稿檔**（中間成果一律保存到議題描述或留言），輸出與留言**盡量使用表格與 Mermaid 圖**；commit／push／PR 不在自動範圍，由使用者另行指示。
+處理一或多個 Gitea 議題的實作流程，五階段：**(A 工具選擇)** 檢查 `tea` 與 `GITEA_TOKEN`，詢問要用 `tea` 或 Gitea REST API（**已選定則跳過**）；**(B 確認專案)** 詢問議題所在專案 owner/repo，可用目前 repo 的 origin 當預設（**已知則跳過**）；**(C 選擇議題)** 列出開啟中議題後詢問要處理的議題編號，**一個或多個**（**已提供則跳過**）；**(D 彙整 TODO)** 讀取議題描述與所有留言、彙整需求，盤點既有 checklist 後整理 TODO 列表並依**影響範圍由小到大**（XS→XL）排序，既有 TODO **不足以達成議題需求時補上新 TODO 並附加到議題描述**的 `## TODO` 區塊；**(E 逐項實作)** 依排序實作每項 TODO 並驗證，**每完成一項就勾選描述 checkbox 並留言進度到議題**，全部完成後留下總結留言。**全程不建立任何草稿檔**（中間成果一律保存到議題描述或留言），輸出與留言**盡量使用表格與 Mermaid 圖**；commit／push／PR 不在自動範圍，由使用者另行指示。
 
 參數：`[--tool <tea|api>] [--repo <owner/repo>] [--issues <編號,以逗號分隔>] [--host <gitea 主機>] [--yes]`（帶 `--tool`／`--repo`／`--issues` 時跳過對應詢問；`--yes` 略過一般確認）。
 
@@ -235,13 +235,13 @@ rm -rf ~/.config/opencode/skills/{code-review,code-review-archive,code-review-re
 
 ### `code-action-docker`
 
-以**互動問答從零打造** Gitea／GitHub「Docker 容器 action」（Node 主程式），再串接文件化流程。五階段：(1) **詢問 action 名稱**（用於 `action.yml` 的 `name`）；(2) **詢問輸入與輸出參數**及其 description（盡量繁體中文、無亂碼；輸入含 required／default，實作對應 `INPUT_*` 環境變數與 `$GITHUB_OUTPUT`）；(3) **詢問執行此流程的目標**，追問到可實作為止，整理**濃縮成一句話**（用於 `action.yml` 的 `description`，盡量繁體中文、無亂碼）；(4) **依標準實作目標**——開發中需要新參數時**依序找 `${{ gitea.* }}` → `${{ secrets.* }}` → `${{ vars.* }}`，都沒有才詢問使用者是否加入 `inputs`**；盡量以 **Node.js** 開發、程式檔**一律放 `src/`**（入口 `src/index.js`、共用 `src/logger.js`），**盡量詳細輸出訊息**且格式統一為 doc-funcs 規範的 `[階段][等級][yyyy/MM/dd HH:mm:ss]: 訊息`（Asia/Taipei；階段選填、無階段則移除該 `[]`；等級 `INF`/`WRN`/`ERR`/`TRC`/`DBG`；一行一則），並產生 `action.yml`、啟動前先輸出名稱／用途／更新時間的 `entrypoint.sh`、**使用最新 node 版本**的多階段建置 `Dockerfile`（預設 build 基底 `node:latest`、runtime `node:slim`）；(5) **檢查是否有 doc-funcs 技能**：有則對整個專案**完整執行 `/jsc:doc-funcs`**（function 文件、`entrypoint.sh`／`Dockerfile` 逐行註解、重建 README），沒有則回報後結束。
+把 Gitea／GitHub「Docker 容器 action」專案標準化為 **Node 主程式＋容器化**，再串接文件化流程。五階段：(A) 找出 action 專案、讀 `action.yml`／`action.yaml` 的 `name`／`description`、判斷主程式語言；(B) 主程式**非 Node 則保守改寫為 Node**（高風險，先以 AskUserQuestion 確認，保留對外行為），並把所有 `.js` 集中到 **`src/`**、同步更新 `require`／`import` 路徑、`package.json` 與 `action.yml`；(C) 產生 `entrypoint.sh`，**啟動 node 前先輸出 action 名稱／用途／更新時間**（Asia/Taipei `yyyy/MM/dd HH:mm:ss`）再 `exec node`；(D) 依**六步流程**（參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口）產生**使用最新 node 版本**的 `Dockerfile`，**每步內容依主程式（`src/`）實作量身決定**（先盤點相依／是否需 build／OS 層相依／入口檔再填對應步驟，用不到的不硬塞），預設 build 基底 `node:latest`、runtime `node:slim`、**多階段建置縮小映像**，`ENTRYPOINT` 指向 `entrypoint.sh`；(E) 對整個專案**完整執行 `/jsc:doc-funcs`**（function 文件、`entrypoint.sh`／`Dockerfile` 逐行註解、重建 README）。
 
-參數：`[--action-dir <action 根目錄>] [--node-version <node tag>]`（根目錄預設目前工作目錄；node 版本預設最新；名稱／輸入輸出／目標以問答取得，呼叫時已口述者不再重問）。
+參數：`[--action-dir <action 根目錄>] [--node-version <node tag>] [--main <主程式檔>] [--yes]`（根目錄預設目前工作目錄；node 版本預設最新；主程式自動判斷；`--yes` 略過一般確認，但主程式改寫與 doc-funcs 的實作詢問仍會中斷）。
 
 - **Claude Code / Antigravity**：`/jsc:code-action-docker`，或 `/jsc:code-action-docker --action-dir ~/work/my-action --node-version 22`
 - **Codex**：`$code-action-docker`，或 `$code-action-docker --action-dir ~/work/my-action`，或用 `/skills` 選單
-- **OpenCode**：描述需求（如「幫我從零建一個 docker action：先問我名稱、輸入輸出參數與目標，用 node 實作放在 src/，訊息格式統一為 [時間][階段][等級]，最後跑 doc-funcs 補文件並重建 README」）自動觸發
+- **OpenCode**：描述需求（如「把這個 action 主程式改成 node、所有 js 收進 src/，產生會先輸出 action 名稱／用途／更新時間再啟動 node 的 entrypoint.sh、用最新 node 版本的 Dockerfile，最後跑 doc-funcs 補文件並重建 README」）自動觸發
 
 ### `code-action-composite`
 

plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "jsc",
-  "version": "0.0.4",
+  "version": "0.0.1",
   "description": "JSC 程式碼工作流 plugin，提供 RPG 攻防式 git diff review、裁決結果歸檔、Gitea AI review findings 修復/PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步，以及 action / Dockerfile 標準化流程；於 Antigravity 以 /jsc: 前綴呼叫。",
   "skills": "./skills/"
 }

skills/code-action-docker/SKILL.md

@@ -1,155 +1,168 @@
 ---
 name: code-action-docker
-description: 以互動問答從零打造 Gitea／GitHub「Docker 容器 action」：(1) 詢問 action 名稱（用於 action.yml 的 name）；(2) 詢問輸入與輸出參數及其 description（盡量繁體中文、無亂碼）；(3) 詢問執行此流程的目標，整理濃縮成一句話（用於 action.yml 的 description，盡量繁體中文、無亂碼）；(4) 依標準實作目標——開發中需要新參數時依 `${{ gitea.* }}` → `${{ secrets.* }}` → `${{ vars.* }}` 順序尋找、都沒有才詢問使用者是否加入 inputs；盡量以 Node.js 開發、程式檔一律放 `src/`、盡量詳細輸出訊息且格式統一為 doc-funcs 規範的 `[階段][等級][yyyy/MM/dd HH:mm:ss]: 訊息`（無階段則移除該 `[]`，等級為 INF/WRN/ERR/TRC/DBG），並產生 action.yml／entrypoint.sh／最新 node 版本的 Dockerfile；(5) 檢查是否有 doc-funcs 技能，有則完整執行 `/jsc:doc-funcs`，否則結束。當使用者說建立／產生一個 docker action、從零做一個容器 action、幫我問完需求後生出 action、把需求做成 node docker action，或提到 code-action-docker 時觸發。不適用於：composite action（用 code-action-composite）、只整理既有 Dockerfile（用 code-image）、非 action 專案。
+description: 將 Gitea／GitHub「Docker 容器 action」專案標準化為 Node 主程式＋容器化，並串接文件化流程：(1) 檢查 action 主程式是否為 Node，否則保守改寫為 Node，且所有 `.js` 檔一律集中到 `src/` 資料夾；(2) 產生 `entrypoint.sh`，啟動前先輸出 action 名稱／用途／更新時間，再執行 node 主程式；(3) 產生使用最新 node 版本的 `Dockerfile`；(4) 最後完整執行 `/jsc:doc-funcs` 處理流程（function 文件、指令檔逐行註解、重建 README）。當使用者說把 action 改成 docker／node、容器化 action、action 主程式 node 化、把 js 收進 src、產 entrypoint.sh／Dockerfile 給 action，或提到 code-action-docker 時觸發。不適用於：非 action 專案、純前端打包、或不需容器化的一般 repo。
-argument-hint: "[--action-dir <action 根目錄>] [--node-version <node tag>]"
+argument-hint: "[--action-dir <action 根目錄>] [--node-version <node tag>] [--main <主程式檔>] [--yes]"
 ---
 
-# code-action-docker — 問答式打造 Docker 容器 action（Node 主程式）＋文件化
+# code-action-docker — action 容器化（Node 主程式）＋文件化
 
-五階段 skill：先以問答收齊需求——**action 名稱**（階段 1）、**輸入與輸出參數**（階段 2）、**流程目標並濃縮成一句話**（階段 3）——再依標準**實作目標**（階段 4：Node.js、程式檔一律放 `src/`、統一訊息格式，並產生 `action.yml`／`entrypoint.sh`／最新 node 版本的 `Dockerfile`），最後**檢查是否有 doc-funcs 技能**（階段 5）：有則完整執行 `/jsc:doc-funcs`，否則結束。
+五階段 skill：先做**前置設定與偵測**（找出 action 專案、讀取名稱／用途、判斷主程式語言），再把**主程式 Node 化並將所有 `.js` 收進 `src/`**，接著產生**啟動前先輸出 action 名稱／用途／更新時間的 `entrypoint.sh`**，然後產生**使用最新 node 版本的 `Dockerfile`**（並對齊 `action.yml` 的 docker 設定），最後**完整執行 `/jsc:doc-funcs` 處理流程**替整個專案補文件並重建 README。
 
 | 階段 | 動作 |
 | --- | --- |
-| 1. 詢問 action 名稱 | 向使用者詢問 action 名稱 → 寫入 `action.yml` 的 `name` |
+| A. 前置設定與偵測 | 決定 action 根目錄 → 讀 `action.yml`／`action.yaml` 的 `name`／`description` → 判斷目前主程式與語言 |
-| 2. 詢問輸入與輸出參數 | 逐一收齊 `inputs`／`outputs`（名稱、description、required、default）→ description 盡量繁體中文、無亂碼 |
+| B. 主程式 Node 化 | 主程式非 Node 則**保守改寫**為 Node（高風險，先確認）→ 所有 `.js` 集中到 `src/`，更新所有引用、`package.json`、`action.yml` |
-| 3. 詢問流程目標 | 詢問此 action 要達成什麼 → 整理並**濃縮成一句話**，經使用者確認後寫入 `action.yml` 的 `description`（盡量繁體中文、無亂碼） |
+| C. entrypoint.sh | 產生 `entrypoint.sh`：先輸出 action **名稱／用途／更新時間**，再 `exec` node 主程式 |
-| 4. 實作目標 | 盡量以 **Node.js** 開發、程式檔**一律放 `src/`**；訊息詳細且格式統一為 `[階段][等級][時間]: 訊息`（doc-funcs 規範）；產生 `action.yml`／`entrypoint.sh`／最新 node 版本的 `Dockerfile` |
+| D. Dockerfile | 依六步流程（參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口）產生使用**最新 node 版本**的 `Dockerfile`，多階段建置縮小映像、`ENTRYPOINT` 指向 `entrypoint.sh` |
-| 5. 檢查 doc-funcs | 有 doc-funcs 技能 → 完整執行 `/jsc:doc-funcs`；沒有 → 回報後結束 |
+| E. 串接 doc-funcs | 對整個 action 專案完整執行 `/jsc:doc-funcs` 流程（function 文件、指令檔逐行註解、重建 README） |
 
 ---
 
 ## 輸出規範（務必遵守）
 
-- **語言**：所有面向使用者的輸出（問題、計畫、進度、總結）一律使用**繁體中文（台灣用語）**；僅識別字、檔名、git／docker 指令、API 路徑、程式碼等技術標識保留原文，**不可**使用簡體字。
+- **語言**：所有面向使用者的輸出（計畫、進度、總結、反問）一律使用**繁體中文（台灣用語）**；僅識別字、檔名、git／docker 指令、API 路徑、程式碼等技術標識保留原文，**不可**使用簡體字。
-- **編碼無亂碼**：凡輸出含繁體中文、全形標點、emoji，一律 **UTF-8（不含 BOM）**，不得出現問號方框或錯碼。產生的 `action.yml`、`src/*.js`、`entrypoint.sh`、`Dockerfile`、`README.md` 同樣需 UTF-8（不含 BOM）；`action.yml` 內的中文 `name`／`description`／參數說明必須能被 YAML 正確解析與顯示。
+- **編碼無亂碼**：凡輸出含繁體中文、全形標點、emoji，一律 **UTF-8（不含 BOM）**，不得出現問號方框或錯碼。產生／覆寫的 `entrypoint.sh`、`Dockerfile`、`action.yml`、`README.md` 同樣需 UTF-8（不含 BOM）。
-- **問答原則**：階段 1～3 是**必要輸入**，缺一不可；使用者已在呼叫時提供的答案不再重複詢問，未提供的必須以 `AskUserQuestion`（或明確反問）取得，**不得臆測代答**。階段 4 起除必要決策外直接執行到完成。
+- **自動執行原則**：除非使用者明確要求先確認，或遇到不可忽略的必要決策，否則各階段只需輸出簡短計畫／進度後直接執行到完成。**一定會中斷詢問的點**：階段 B 主程式「非 Node 需改寫」時（破壞性，須先確認），以及階段 E 由 `/jsc:doc-funcs` 自身的「如何實作」詢問。
-- **不破壞既有工作**：若 action 根目錄已存在 `action.yml`／`src/`／`entrypoint.sh`／`Dockerfile`，覆寫前先回報並確認；工作區有未提交變更時提醒使用者先 commit／備份；**絕不** `reset --hard`／`checkout -f`／`clean`，也不刪除使用者既有原始碼。
+- **不破壞既有工作**：移動 `.js`、改寫主程式、覆寫 `entrypoint.sh`／`Dockerfile`／`action.yml` 前，若工作區有未提交變更，先提醒使用者建議先 commit／備份；**絕不** `reset --hard`／`checkout -f`／`clean`，也不刪除使用者既有原始碼。移動檔案優先用 `git mv` 以保留歷史。
-- **不擴及無關檔案**：本 skill 只產生／修改 action 根目錄內的 `action.yml`、`src/`、`entrypoint.sh`、`Dockerfile`、`package.json`，以及階段 5 由 doc-funcs 流程處理的目標；排除 `node_modules`／`.git`／`.docs`／`bin`／`obj`／第三方依賴。
+- **保留行為**：Node 化只「翻譯」既有邏輯，不得擅自改變對外行為、輸入輸出契約或副作用；任何無法可靠等價推論的改動一律不做，並以註解或回報標註「需人工確認」。
+- **不擴及無關檔案**：本 skill 只動 action 專案根目錄內的：主程式、`.js`（搬移到 `src/`）、`package.json`、`action.yml`／`action.yaml`、`entrypoint.sh`、`Dockerfile`，以及階段 E 由 doc-funcs 流程處理的目標；排除 `node_modules`／`.git`／`.docs`／`bin`／`obj`／第三方依賴。
 
 ---
 
 ## 參數
 
-格式：`[--action-dir <action 根目錄>] [--node-version <node tag>]`
+格式：`[--action-dir <action 根目錄>] [--node-version <node tag>] [--main <主程式檔>] [--yes]`
 
-- `--action-dir <action 根目錄>`：action 專案根目錄。**省略時預設目前工作目錄**。
+- `--action-dir <action 根目錄>`：action 專案根目錄。**省略時預設目前工作目錄**（須含 `action.yml`／`action.yaml`，否則依 A1 詢問）。
-- `--node-version <node tag>`：`Dockerfile` 的 node base image tag（如 `22`、`22-alpine`、`lts`）。**省略時預設使用最新 node 版本**（`node:latest`，見階段 4）。
+- `--node-version <node tag>`：`Dockerfile` 的 node base image tag（如 `22`、`22-alpine`、`lts`）。**省略時預設使用最新 node 版本**（`node:latest`，見階段 D）。
-
+- `--main <主程式檔>`：指定主程式入口檔（相對 action 根目錄）。省略時依 A3 自動判斷。
-階段 1～3 的答案（名稱、輸入輸出參數、目標）不設 CLI 參數；使用者若已在呼叫訊息中口述，直接採用、不再重問。
+- `--yes`：盡量不中斷。即使帶此參數，「主程式非 Node 需改寫」與 doc-funcs 的「如何實作」仍會詢問。
 
 ---
 
-## 階段 1：詢問 action 名稱
+## 階段 A：前置設定與偵測
 
-向使用者詢問 **action 名稱**，用於 `action.yml` 的 `name`：
+### A1. 決定 action 根目錄
 
-- 使用者已在呼叫時提供 → 直接採用並回報。
+- 帶 `--action-dir` → 採用（展開 `~`）。
-- 未提供 → 以 `AskUserQuestion`（自由輸入為主，可依目錄名／repo 名給 2～3 個建議選項）詢問，**不得自行編造**。
+- 省略 → 用目前工作目錄。
-- 名稱不得為空；可為繁體中文或英文，原樣寫入 `name`，不擅自翻譯或改寫。
+- 根目錄須存在 `action.yml` 或 `action.yaml`（action manifest）。**找不到** action manifest → 回報「此目錄不是 action 專案（缺 action.yml／action.yaml）」並詢問正確路徑，**不臆測**、不在非 action 專案上動工。
 
-## 階段 2：詢問輸入與輸出參數
+### A2. 讀取 action 名稱與用途
 
-向使用者收齊 action 的**輸入（`inputs`）與輸出（`outputs`）參數**，逐項確認：
+從 action manifest 讀取：
 
-- **每個輸入**：參數名稱（建議 kebab-case）、`description`（**盡量繁體中文、無亂碼**）、是否必填（`required`）、預設值（`default`，選填）。
+- `name`：action 名稱（供 `entrypoint.sh` 輸出與 README 使用）。
-- **每個輸出**：參數名稱、`description`（**盡量繁體中文、無亂碼**）。
+- `description`：action 用途。
-- 使用者明確表示「無輸入」或「無輸出」→ 對應區塊留空（省略該區塊），不硬造參數。
+- `runs`：目前的執行設定（`using`、`main`、`image`、`entrypoint` 等）。
-- description 缺漏時**反問補齊**，不編造；使用者堅持留空則標示「（未提供）」。
-- 收齊後輸出整理表（名稱／必填／預設值／說明）讓使用者確認，再進入階段 3。
 
-實作對應（供階段 4 使用）：輸入在容器內以 `INPUT_<大寫參數名>` 環境變數取得（`-` 轉 `_`）；輸出以附加 `name=value` 到 `$GITHUB_OUTPUT` 檔案寫出。
+若 `name`／`description` 缺漏，回報並請使用者補；無法取得時於後續輸出以「（未提供）」保守標示，**不編造**。
 
-## 階段 3：詢問執行此流程的目標
+### A3. 判斷目前主程式與語言
 
-向使用者詢問**此 action 要達成什麼目標**（要處理什麼、產出什麼、成功／失敗準則）：
+依序判斷主程式入口（取第一個成立者）：
 
-- 追問到「可實作」為止：不清楚的環節（資料來源、外部指令、失敗時的行為）必須問清，**不得臆測**。
+1. 帶 `--main <主程式檔>` → 直接採用。
-- 將目標**整理並濃縮成一句話**（盡量繁體中文、無亂碼），向使用者確認後寫入 `action.yml` 的 `description`。
+2. `action.yml` 為 JS action（`runs.using: node*`）→ 取 `runs.main`。
-- 完整目標描述（含細節與邊界）保留於回報與階段 4 的實作依據，不因濃縮而遺失。
+3. `action.yml` 為 docker action（`runs.using: docker`）→ 看 `runs.entrypoint`／`Dockerfile` 的 `ENTRYPOINT`／`CMD` 推主程式。
+4. 以上皆無 → 依專案檔與副檔名分布推斷（`package.json` 的 `main`／`bin`、`index.js`、`*.sh`、`*.py` 等）。
 
-## 階段 4：實作目標（Node.js、src/、統一訊息格式）
+判定**主程式是否為 Node**：入口為 `.js`／`.mjs`／`.cjs` 且由 `node` 執行即視為 Node；入口為 shell／python／其他則視為非 Node。輸出偵測結果（action 名稱、用途、主程式檔、判定語言、是否為 Node），再進入階段 B。
 
-依階段 1～3 收齊的需求實作 action，遵守以下標準：
+---
 
-### 4.0 開發中需要參數時的來源優先序
+## 階段 B：主程式 Node 化，並將所有 `.js` 收進 `src/`
 
-實作過程中發現需要某個參數（例如 repo 資訊、token、環境設定）而階段 2 的 `inputs` 沒有時，**依下列順序尋找來源，前者可用就不往後找**：
+### B1. 主程式 Node 化
 
-1. **`${{ gitea.* }}` context**：runner 內建 context（如 `gitea.repository`、`gitea.ref`、`gitea.actor`、`gitea.token`）；docker action 執行期對應 runner 注入的 `GITHUB_*`／`GITEA_*` 環境變數（如 `GITHUB_REPOSITORY`、`GITHUB_REF`），主程式直接讀 `process.env` 即可。
+- **已是 Node** → 確認入口檔，不改寫邏輯，直接進 B2。
-2. **`${{ secrets.* }}`**：repo／org 的 secrets（機敏值：token、密碼、金鑰）。
+- **非 Node（shell／python／其他）** → 這是**破壞性高風險決策**：先以 `AskUserQuestion` 向使用者確認是否改寫為 Node，選項至少含「改寫為 Node」「維持原樣只做容器化（略過改寫）」「其他」。經確認後才改寫：
-3. **`${{ vars.* }}`**：repo／org 的 variables（非機敏設定值）。
+  - 逐段把原主程式邏輯**保守翻譯**為 Node（建議 `index.js`）；保留對外行為、輸入（環境變數／`INPUT_*`／args）與輸出（stdout／exit code／檔案副作用）契約。
-4. **以上都沒有** → 以 `AskUserQuestion` 詢問使用者**是否要把該參數加入 `inputs`**（加入則回到階段 2 規格補齊名稱／description／required／default，並同步 `action.yml`）；**不得臆測預設值或硬編碼**。
+  - 外部指令呼叫以 `child_process`（`execFileSync`／`spawnSync`）對應；檔案操作以 `fs`；環境變數以 `process.env`。
+  - 任何無法可靠等價翻譯處，**不臆測**：以 `// 需人工確認：...` 標註並回報。
+  - 改寫完成後，原非 Node 主程式於 B2 一併處理（移除或保留由使用者裁示；預設保留並在 README／回報標註已由 Node 取代）。
 
-注意：`secrets.*`／`vars.*` 無法在 `action.yml` 的 `inputs.default` 直接引用，須由呼叫端 workflow 以 `with:` 或 `env:` 傳入（如 `with: token: ${{ secrets.MY_TOKEN }}`）；採用這類來源時，在 README 使用範例中示範呼叫端如何帶入，機敏值一律不落地、不輸出明文（log 需遮蔽）。
+### B2. 所有 `.js` 集中到 `src/`
 
-### 4.1 盡量以 Node.js 開發，程式檔一律放 `src/`
+- 在 action 根目錄建立 `src/`（若不存在）。
+- 將專案內所有 `.js`／`.mjs`／`.cjs`（排除 `node_modules`／`.git`／`.docs`／`bin`／`obj`／第三方依賴）**移入 `src/`**，優先 `git mv` 保留歷史。主程式入口統一為 `src/index.js`（或 `src/<main>.js`）。
+- **移動後必須更新所有引用**，確保不破壞：
+  - 模組間的 `require`／`import` 相對路徑。
+  - `package.json` 的 `main`／`bin`／`scripts`／`exports`（指向 `src/...`）。
+  - `action.yml`／`Dockerfile`／`entrypoint.sh` 內對主程式路徑的引用。
+- 若 `src/` 下無 `package.json` 而專案需要相依，於 `src/` 建立或移入 `package.json`，`main` 指向入口檔；不擅自新增與功能無關的相依。
 
-- 主程式與所有模組**盡量以 Node.js 撰寫**；只有目標必須依賴外部工具時，才以 `child_process`（`execFileSync`／`spawnSync`）在 Node 內呼叫，不另寫 shell／python 主程式。
+### B3. action.yml 對齊 docker
-- 所有 `.js`／`.mjs`／`.cjs`**一律放在 `src/` 資料夾內**，主程式入口統一為 `src/index.js`；需要相依套件時於 `src/` 建立 `package.json`（`main` 指向入口檔），不擅自新增與目標無關的相依。
-- 輸入用 `process.env.INPUT_*` 讀取（必填缺漏 → 輸出 `ERR` 訊息並以非零 exit code 結束）；輸出寫入 `process.env.GITHUB_OUTPUT`。
 
-### 4.2 盡量詳細輸出訊息，格式統一
+將 manifest 的 `runs` 對齊為 docker 容器 action（保留既有 `inputs`／`outputs`／`name`／`description`）：
-
-- 執行過程**盡量詳細輸出**：開始／結束、讀到的輸入、每個關鍵步驟、外部指令與結果、寫出的輸出、警告與錯誤。
-- 每一則訊息格式固定為（與 doc-funcs 第 6 步的 `[{階段}?][{等級}][{時間}]: {訊息}` 規範一致）：
-
-  ```
-  [階段][等級][yyyy/MM/dd HH:mm:ss]: 訊息
-  ```
-
-  - **階段**：該訊息所屬的流程階段名稱（如 `讀取輸入`、`執行`、`寫出結果`），選填；**沒有階段時整個 `[階段]` 區塊移除**，即 `[等級][yyyy/MM/dd HH:mm:ss]: 訊息`。
-  - **等級**：必為 `INF`／`WRN`／`ERR`／`TRC`／`DBG` 其中之一（一般資訊 INF、警告 WRN、錯誤 ERR、細部追蹤 TRC、除錯 DBG）。
-  - **時間**：台灣時區（Asia/Taipei），固定 `yyyy/MM/dd HH:mm:ss`。
-- **一行一則訊息**：每則訊息獨立一行輸出，不得多則併成一坨。
-- 在 `src/logger.js` 實作共用 logger（產生時間戳、組合前綴、`INF`/`WRN`/`ERR`/`TRC`/`DBG` 各一個方法、可帶階段名稱），主程式一律經由它輸出；`ERR` 走 `console.error`，其餘走 `console.log`。
-- 錯誤處理：可預期錯誤輸出 `ERR` 訊息並 `process.exit(1)`；未捕捉例外亦須被攔截（`process.on('uncaughtException'/'unhandledRejection')`）以 `ERR` 格式輸出後非零結束。
-
-### 4.3 產生 action.yml
-
-以階段 1～2 的答案組出 `action.yml`（中文內容 UTF-8、無亂碼）：
 
 ```yaml
-name: <階段 1 的 action 名稱>
-description: <階段 3 濃縮的一句話>
-inputs:
-  <參數名>:
-    description: <階段 2 的說明（盡量繁體中文）>
-    required: true|false
-    default: <預設值（若有）>
-outputs:
-  <參數名>:
-    description: <階段 2 的說明（盡量繁體中文）>
 runs:
   using: docker
   image: Dockerfile
   entrypoint: entrypoint.sh
 ```
 
-無輸入／輸出時省略對應區塊。
+若原本是 JS action（`using: node*`），改為上述 docker 設定；若已是 docker action，確認 `image` 指向 `Dockerfile`、`entrypoint` 指向 `entrypoint.sh`。
 
-### 4.4 產生 entrypoint.sh
+---
 
-在 action 根目錄產生 `entrypoint.sh`：啟動 node 主程式前，先輸出 action **名稱／用途／更新時間**，且每則輸出同樣遵守 4.2 訊息格式（階段用 `啟動`）：
+## 階段 C：產生 entrypoint.sh（先輸出名稱／用途／更新時間，再啟動 node 主程式）
+
+在 action 根目錄產生（或覆寫）`entrypoint.sh`：**啟動 node 主程式前，先輸出 action 名稱、用途、更新時間**。
+
+- **更新時間**為產生此檔當下的時間戳，使用台灣時區（Asia/Taipei）並固定為 `yyyy/MM/dd HH:mm:ss`（可用 `TZ='Asia/Taipei' date +'%Y/%m/%d %H:%M:%S'` 取得），**寫成檔內固定字串**（非執行期動態時間）。
+- 名稱／用途取自階段 A2 的 `action.yml`。
+- 最後以 `exec node <主程式>`（如 `exec node /action/src/index.js "$@"`）啟動，讓 node 取代 shell 行程，正確傳遞訊號與 exit code；路徑須與階段 D 的 `Dockerfile` 落點一致。
+
+範例（實際路徑依階段 B 入口而定）：
 
 ```sh
 #!/bin/sh
 set -e
 
-# action 啟動訊息：名稱／用途／更新時間（此檔由 code-action-docker 產生）
+# action 啟動橫幅：輸出名稱／用途／更新時間（此檔由 code-action-docker 產生）
-echo "[啟動][INF][<產生當下 Asia/Taipei 時間>]: Action：<action 名稱>"
+echo "================================================"
-echo "[啟動][INF][<產生當下 Asia/Taipei 時間>]: 用途：<action.yml 的 description>"
+echo "Action  : <action name>"
-echo "[啟動][INF][<產生當下 Asia/Taipei 時間>]: 更新時間：<產生當下 Asia/Taipei 時間>"
+echo "用途    : <action description>"
+echo "更新時間: 2026/06/30 18:30:05"
+echo "================================================"
 
 # 啟動 node 主程式（以 exec 取代 shell，正確處理訊號與 exit code）
 exec node /action/src/index.js "$@"
 ```
 
-- 「更新時間」為產生此檔當下的時間戳（`TZ='Asia/Taipei' date +'%Y/%m/%d %H:%M:%S'`），**寫成檔內固定字串**；名稱／用途取自階段 1／3。
 - 賦予可執行權限：`chmod +x entrypoint.sh`（並於 git 標記為可執行）。
+- 此檔開頭的「用途／更新時間」與每行註解，最終會在階段 E 由 `/jsc:doc-funcs` 的指令檔流程統一補齊／覆寫為標準格式（用途與更新日期同一註解區塊、逐行註解）；本階段先確保**執行期輸出**正確即可。
 
-### 4.5 產生 Dockerfile（使用最新 node 版本）
+---
 
-在 action 根目錄產生 `Dockerfile`，**base image 使用最新 node 版本**，採**多階段建置**縮小最終映像，內容依 `src/` 實作量身決定（有相依才裝、需要 OS 工具才 `apt-get install`，用不到的不硬塞）：
+## 階段 D：產生 Dockerfile（使用最新 node 版本，六步流程依主程式實作量身產生）
+
+在 action 根目錄產生（或覆寫）`Dockerfile`，**base image 使用最新 node 版本**，採**多階段建置**以縮小最終映像檔。六步流程是**骨架**，但**每一步的實際內容必須依階段 B 的主程式（`src/`）實作決定**——不要套用與主程式無關的固定樣板，也不要硬塞主程式用不到的安裝或建置指令。
+
+### D0. 先盤點主程式實作需求
+
+產生 Dockerfile 前，先檢視 `src/` 主程式與 `package.json`，判斷各步該放什麼：
+
+- **相依套件**：`src/package.json` 的 `dependencies`／`devDependencies`、是否有 lockfile（`package-lock.json`／`npm-shrinkwrap.json`）。決定第 2 步用 `npm ci` 還是 `npm install`、是否需要 dev 相依來 build。
+- **是否需要 build／transpile**：有無 `scripts.build`、是否為 TypeScript／打包（產物落在 `dist/`／`build/` 等）。決定第 4 步是否要跑建置、第 5 步 runtime 該帶入哪個產物目錄。
+- **OS 層相依**：主程式是否以 `child_process` 呼叫外部執行檔（如 `git`、`bash`、`openssl`、`python3`、`ffmpeg`、`imagemagick`），或使用需編譯的原生模組（node-gyp／native addon）。決定第 2 步是否要 `apt-get install` 對應套件，以及第 5 步 runtime 基底是否需保留這些執行檔。
+- **執行期需求**：主程式讀取的環境變數、需存取的檔案路徑、是否寫入暫存目錄。決定 `WORKDIR`、需 `COPY` 的檔案範圍與必要的 `ENV`。
+- **入口檔**：階段 B 決定的主程式入口（如 `src/index.js`），決定第 6 步與 `entrypoint.sh` 內 `node` 路徑。
+
+### D1～D6：依盤點結果填入六步
+
+1. **參數處理**：以 `ARG` 注入 node 版本（預設最新）與主程式需要的 build-time 參數；可調參數集中在檔案開頭。
+2. **安裝套件**：依 D0 的相依結果安裝——有 lockfile 用 `npm ci`、否則 `npm install`；不需 build 時加 `--omit=dev`，需 build 時先裝完整相依（含 dev）供第 4 步使用。**只在主程式真的會用到時**才 `apt-get install` OS 套件，並於同一 `RUN` 清掉 apt 快取。先 `COPY` 相依描述（`package*.json`）再安裝，以利 layer 快取。
+3. **複製檔案**：`COPY` 主程式實際需要的檔案（`src/`、`entrypoint.sh`，及主程式會讀取的資源）；不需要的檔案不必帶入。
+4. **執行程序**：賦予 `entrypoint.sh` 執行權限；**僅當 D0 判定需要 build／transpile 時**才執行（如 `npm run build`），否則此步只做權限設定，不要硬加建置指令。
+5. **縮小映像檔**：多階段建置，runtime 改用 slim 基底，只 `COPY --from=build` 帶入主程式執行**真正需要**的產物——有 build 產物時帶入 `dist/` 與 production `node_modules`（`npm prune --omit=dev` 或重裝 production 相依），純 JS 無 build 時帶入 `src/` 與 production `node_modules`；若 D0 判定 runtime 需要某些 OS 執行檔，於 runtime 階段一併安裝（slim 基底可能不含）。不要把 build 階段的 dev 相依與快取帶進最終映像。
+6. **設定入口**：`ENTRYPOINT` 指向 `entrypoint.sh`，其內 `node` 路徑為 D0 的入口檔。
+
+base image 版本：預設 build 基底 `node:latest`、runtime 基底 `node:slim`（皆為最新版，slim 用於縮小）；帶 `--node-version <tag>`（如 `22`、`lts`）時改用 `node:<tag>` 與 `node:<tag>-slim`。若需確認當前最新穩定版號，可查詢 Docker Hub（`https://hub.docker.com/_/node`）後於 `FROM` 註記實際版本，但**預設行為是使用最新版**。
+
+下列為**最簡基準骨架**（純 JS、無 build、無 OS 相依的情況）；實際內容須依 D0 盤點調整，第 4 步建置、第 2／5 步 OS 套件等視主程式需要增刪：
 
 ```Dockerfile
 # syntax=docker/dockerfile:1
@@ -158,47 +171,50 @@ exec node /action/src/index.js "$@"
 ARG NODE_VERSION=latest
 ARG NODE_RUNTIME=slim
 
-# ---- build 階段：安裝相依 ----
+# ---- build 階段：安裝相依、準備產物 ----
 FROM node:${NODE_VERSION} AS build
 WORKDIR /action
 
-# 2. 安裝套件：先帶相依描述以利 layer 快取（有 lockfile 用 npm ci）
+# 2. 安裝套件：先帶相依描述以利 layer 快取，再裝 src/ 相依
+#    （需 build 時改裝完整相依；需 OS 套件時於此 apt-get install 並清快取）
 COPY src/package*.json /action/src/
 RUN if [ -f /action/src/package.json ]; then \
         cd /action/src && (npm ci --omit=dev || npm install --omit=dev); \
     fi
 
-# 3. 複製檔案：帶入主程式與入口
+# 3. 複製檔案：複製主程式實際需要的檔案
-COPY src/ /action/src/
+COPY . /action
-COPY entrypoint.sh /action/entrypoint.sh
 
-# 4. 執行程序：賦予 entrypoint 執行權限
+# 4. 執行程序：賦予 entrypoint 執行權限（D0 判定需要 build 時於此 npm run build）
 RUN chmod +x /action/entrypoint.sh
 
-# 5. 縮小映像檔：runtime 改用 slim 基底，只帶必要產物
+# 5. 縮小映像檔：多階段建置，runtime 改用 slim 基底、只帶必要產物
+#    （有 build 產物時改帶 dist/ 與 production node_modules；runtime 需要的 OS 執行檔於此安裝）
 FROM node:${NODE_RUNTIME} AS runtime
 WORKDIR /action
 COPY --from=build /action /action
 
-# 6. 設定入口：以 entrypoint.sh 啟動 node 主程式
+# 6. 設定入口：以 entrypoint.sh 啟動（其內 node 指向 D0 的入口檔）
 ENTRYPOINT ["/action/entrypoint.sh"]
 ```
 
-- **版號對齊**：預設 build 基底 `node:latest`、runtime 基底 `node:slim`（**沒有 `node:latest-slim` 這個 tag**，故以獨立 `NODE_RUNTIME` 參數帶入）；帶 `--node-version 22` 時設 `NODE_VERSION=22`、`NODE_RUNTIME=22-slim`。
+- **依主程式實作**：上面只是基準骨架。若主程式是 TypeScript／需打包，第 4 步要加 `npm run build`、第 5 步只帶 `dist/` 與 production 相依；若主程式會 spawn 外部執行檔或用原生模組，第 2／5 步要補對應 OS 套件；用不到的步驟內容不要硬塞。
-- 主程式以 `child_process` 呼叫外部執行檔（如 `git`、`openssl`）時，於 runtime 階段補 `apt-get install` 對應套件並清快取。
+- **版號對齊**：runtime 的 slim 基底版號需與 build 基底一致。預設 `node:latest` ↔ `node:slim`；帶 `--node-version 22` 時設 `NODE_VERSION=22`、`NODE_RUNTIME=22-slim`。注意**沒有 `node:latest-slim` 這個 tag**，最新版 slim 一律用 `node:slim`，故以獨立的 `NODE_RUNTIME` 參數帶入、不要用 `${NODE_VERSION}-slim` 組裝。
-- **自我檢查**：`entrypoint.sh` 的 `node /action/src/index.js` 路徑須與 `Dockerfile` 的 `WORKDIR`／`COPY` 落點一致。
+- **自我檢查**：`entrypoint.sh` 的 `node <主程式>` 路徑（如 `/action/src/index.js`）需與 `Dockerfile` 的 `WORKDIR`／`COPY` 落點一致，避免容器啟動時找不到主程式。
+- 此檔的用途／更新日期註解與逐行註解，同樣於階段 E 由 doc-funcs 指令檔流程統一補齊。
 
-### 4.6 驗證
+---
 
-- `node --check src/*.js` 驗證語法；有 `package.json` 時執行 `npm install`（或 `npm ci`）確認相依可解析。
+## 階段 E：完整執行 /jsc:doc-funcs 處理流程
-- 環境有 docker 時執行 `docker build .` 驗證映像可建置；無法執行時明確說明原因並標註風險。
 
-## 階段 5：檢查是否有 doc-funcs 技能
+容器化與 Node 化完成後，對**整個 action 專案**完整執行 `/jsc:doc-funcs` 流程，替程式碼與指令檔補文件並重建 README：
 
-實作完成後，檢查目前環境是否有 **doc-funcs** 技能（可用 skill 清單中是否存在 `doc-funcs`，含 `/jsc:doc-funcs` 等帶前綴形式）：
+- 以階段 A1 的 action 根目錄為目標，執行 `doc-funcs` skill 的完整流程（判斷語言 → 掃描 function 與指令檔 → 建立 `.docs/` 草稿 → 草稿品質檢查 → 詢問使用者如何實作 → 依選擇寫回 → 保守優化 → 重建 README → 錨點檢查 → 清理草稿 → 建置／語法驗證）。
+- doc-funcs 會涵蓋本次新增／變更的指令檔：`entrypoint.sh`（補齊「用途＋更新日期同一註解區塊」與逐行註解）、`Dockerfile`（逐行註解）；以及 `src/` 內 Node 主程式與各 function 的文件註解。
+- doc-funcs 的「如何實作」詢問（全部一起／逐個／其他）由使用者於該流程內裁示，本 skill 不代為決定。
+- 完成後依 doc-funcs 規範重建根目錄 `README.md`（含台灣時區更新時間、專案列表、功能列表、使用範例）。
 
-- **有** → 以階段 4 的 action 根目錄為目標，**完整執行 `/jsc:doc-funcs` 流程**（判斷語言 → 掃描 function 與指令檔 → 建立 `.docs/` 草稿 → 詢問使用者如何實作 → 寫回 → 保守優化 → 重建 README → 清理草稿 → 驗證）。doc-funcs 會涵蓋本次產出：`src/` 內各 function 的 JSDoc、`entrypoint.sh`／`Dockerfile` 逐行註解、重建 README；其「如何實作」詢問由使用者於該流程內裁示。本 skill 4.2 的訊息格式即 doc-funcs 第 6 步的 `[{階段}?][{等級}][{時間}]: {訊息}` 規範，兩者一致，doc-funcs 流程覆蓋指令檔時直接沿用。
+> 銜接方式：在本 skill 環境中以 `/jsc:doc-funcs`（或 Skill 工具）啟動 doc-funcs 流程；若該流程需參數，沿用本 skill 的 action 根目錄為目標專案。
-- **沒有** → 回報「未偵測到 doc-funcs 技能，略過文件化」後**結束**，不自行模擬 doc-funcs 流程。
 
 ---
 
@@ -206,19 +222,20 @@ ENTRYPOINT ["/action/entrypoint.sh"]
 
 各階段執行後輸出：
 
-- **階段 1～3**：action 名稱、輸入／輸出參數整理表、濃縮後的一句話 description。
+- **階段 A**：action 根目錄、action 名稱／用途、原主程式檔與語言、是否為 Node。
-- **階段 4**：產出檔案清單（`action.yml`、`src/index.js`、`src/logger.js`、`src/package.json`（若有）、`entrypoint.sh`、`Dockerfile`）與各自相對路徑、採用的 node 版本、驗證結果（語法檢查／npm／docker build）。
+- **階段 B**：是否改寫主程式（及改寫摘要與「需人工確認」清單）、搬入 `src/` 的 `.js` 清單、已更新的引用（`package.json`／`action.yml`／路徑）。
-- **階段 5**：是否偵測到 doc-funcs；有則附 doc-funcs 流程的處理結果（文件化的 function 與指令檔、重建的 README）。
+- **階段 C／D**：`entrypoint.sh` 的輸出內容（名稱／用途／更新時間）與啟動的 node 主程式、`Dockerfile` 採用的 node 版本與 `ENTRYPOINT`。
-- 提醒使用者於提交前確認 `entrypoint.sh` 有可執行權限、容器能正確啟動。
+- **階段 E**：doc-funcs 流程的處理結果（文件化的 function 與指令檔、重建的 README）。
+- 列出本次新增／變更的檔案與其相對路徑，並提醒使用者於提交前確認 `entrypoint.sh` 有可執行權限、容器能正確啟動。
 
 ---
 
 ## 呼叫方式
 
-格式：`[--action-dir <action 根目錄>] [--node-version <node tag>]` — 全部可省略（根目錄預設目前工作目錄；node 版本預設最新）。
+格式：`[--action-dir <action 根目錄>] [--node-version <node tag>] [--main <主程式檔>] [--yes]` — 全部可省略（根目錄預設目前工作目錄；node 版本預設最新；主程式自動判斷）。
 
 | 助理 | 呼叫 |
 | --- | --- |
 | Claude Code / Antigravity | `/jsc:code-action-docker`，或 `/jsc:code-action-docker --action-dir ~/work/my-action --node-version 22` |
 | Codex | `$code-action-docker`，或 `$code-action-docker --action-dir ~/work/my-action`，或用 `/skills` 選單 |
-| OpenCode | 描述需求（如「幫我從零建一個 docker action：先問我名稱、輸入輸出參數與目標，用 node 實作放在 src/，訊息格式統一，最後跑 doc-funcs 補文件」）自動觸發 |
+| OpenCode | 描述需求（如「把這個 action 主程式改成 node、所有 js 收進 src/，產生會先輸出 action 名稱／用途／更新時間再啟動 node 的 entrypoint.sh、用最新 node 版本的 Dockerfile，最後跑 doc-funcs 補文件並重建 README」）自動觸發 |

skills/code-issues/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: code-issues
-description: 處理一或多個 Gitea 議題的實作流程：先選擇使用 `tea` 或 Gitea REST API + `GITEA_TOKEN`（已選定則跳過），再確認議題所在專案（已知則跳過）與要處理的議題編號（一或多個）；接著讀取議題描述與留言、彙整需求，整理 TODO 列表並依影響範圍由小到大排序，既有 TODO 不足以達成議題需求時補上新 TODO 並附加到議題描述；最後逐項實作 TODO，每完成一項就到議題勾選該 TODO 的 checkbox 並把進度留言到議題；議題若有母議題，實作完成後母議題 checklist 中引用本議題的 TODO 項目也要一併勾選並留言告知。議題若屬於專案看板且有「分析中／待處理／進行中／待測試／已完成」欄位可調整，依處理進度同步把議題移到對應欄位（彙整需求時「分析中」、TODO 確定「待處理」、開始實作「進行中」、實作完成且驗證通過「待測試」，「已完成」僅在使用者確認時）。全程不建立任何草稿檔，中間成果一律用議題描述或留言保存，並盡量以表格與 Mermaid 圖呈現。當使用者說處理議題、實作議題、依議題 TODO 開工、把議題需求整理成 TODO 並逐項完成、議題進度留言、調整議題看板欄位進度，或提到 code-issues、issue 實作、Gitea 議題處理時觸發。不適用於：把需求拆分成多個新議題（用 doc-issues-analyze）、只同步議題狀態不實作（用 doc-issues-sync）、或與 Gitea 無關的本機 TODO 管理。
+description: 處理一或多個 Gitea 議題的實作流程：先選擇使用 `tea` 或 Gitea REST API + `GITEA_TOKEN`（已選定則跳過），再確認議題所在專案（已知則跳過）與要處理的議題編號（一或多個）；接著讀取議題描述與留言、彙整需求，整理 TODO 列表並依影響範圍由小到大排序，既有 TODO 不足以達成議題需求時補上新 TODO 並附加到議題描述；最後逐項實作 TODO，每完成一項就把進度留言到議題。全程不建立任何草稿檔，中間成果一律用議題描述或留言保存，並盡量以表格與 Mermaid 圖呈現。當使用者說處理議題、實作議題、依議題 TODO 開工、把議題需求整理成 TODO 並逐項完成、議題進度留言，或提到 code-issues、issue 實作、Gitea 議題處理時觸發。不適用於：把需求拆分成多個新議題（用 doc-issues-analyze）、只同步議題狀態不實作（用 doc-issues-sync）、或與 Gitea 無關的本機 TODO 管理。
 argument-hint: "[--tool <tea|api>] [--repo <owner/repo>] [--issues <編號,以逗號分隔>] [--host <gitea 主機>] [--yes]"
 ---
 
@@ -14,9 +14,7 @@ argument-hint: "[--tool <tea|api>] [--repo <owner/repo>] [--issues <編號,以
 | B. 確認專案 | 詢問議題所在專案（owner/repo），可用目前 repo 的 origin 當預設選項 | 已知專案（`--repo`、對話已提供、或使用者確認採用 origin）|
 | C. 選擇議題 | 詢問要處理的議題編號，**一個或多個** | 已提供（`--issues` 或對話中已列出）|
 | D. 彙整 TODO | 讀議題描述＋留言 → 彙整需求 → TODO 依**影響範圍小→大**排序 → 不足以達成需求的缺漏 TODO **附加到議題描述** | — |
-| E. 逐項實作 | 依排序實作每項 TODO → 每完成一項：勾選議題描述 checkbox ＋ **留言進度到議題** → 全部完成後**同步母議題 TODO 狀態**（若有母議題） | — |
+| E. 逐項實作 | 依排序實作每項 TODO → 每完成一項：勾選議題描述 checkbox ＋ **留言進度到議題** | — |
-
-議題若**屬於專案看板**且看板有「分析中／待處理／進行中／待測試／已完成」欄位可調整，階段 D／E 需依處理進度**同步調整議題所在欄位**（見「議題進度欄位調整」）。
 
 ---
 
@@ -98,25 +96,6 @@ argument-hint: "[--tool <tea|api>] [--repo <owner/repo>] [--issues <編號,以
   - `tea`：`tea issues <index> --repo <owner>/<repo> --comments`
   - `api`：`GET {base}/issues/{index}` 與 `GET {base}/issues/{index}/comments`
 - 留言中若有需求補充、變更或取消，必須納入需求彙整，並以最新留言為準。
-- 一併確認**議題是否屬於專案看板（project）**與看板有哪些欄位（column）：`tea` 不支援 project 操作，一律改走 API（需 `GITEA_TOKEN`）；project／column API 隨 Gitea 版本差異大，先探測可用性（如 `GET {base}/projects`、議題回應中的 project 資訊），**不可用時記錄並略過欄位調整**，不影響其餘流程。
-- 一併確認**議題是否有母議題**：檢查議題描述／留言中的「屬於 #n」「parent: #n」等引用、timeline 的 cross-reference（`GET {base}/issues/{index}/timeline`）、或依賴關係 API；找到候選母議題時讀取其描述，確認其 checklist 是否有引用本議題（如 `- [ ] #<本議題編號>`）或語意對應本議題的 TODO 項目，記錄母議題編號與對應項目。無法確定時可詢問使用者；找不到就記錄「無母議題」，不臆測。
-
-### 議題進度欄位調整（議題屬於專案看板時）
-
-議題屬於專案看板、且看板有「**分析中／待處理／進行中／待測試／已完成**」欄位可調整時，依處理進度把議題移到對應欄位；每次移動在輸出中回報「議題 #n：<原欄位> → <新欄位>」。
-
-| 時機 | 目標欄位 |
-| --- | --- |
-| 階段 D 開始彙整需求時 | 分析中 |
-| 階段 D 完成（TODO 列表確定）、尚未開始實作 | 待處理 |
-| 階段 E 開始實作第一項 TODO | 進行中 |
-| 階段 E 全部 TODO 實作完成且驗證通過 | 待測試 |
-| 議題需求全數達成且使用者確認無需再測試（或明確指示） | 已完成 |
-
-- **就近對應**：欄位名稱不完全相同時做語意對應（如「To Do」→ 待處理、「In Progress」→ 進行中、「Done」→ 已完成）；**無法明確對應的欄位不硬移**，回報並略過。
-- **保守推進**：預設最多推進到「待測試」（本 skill 不負責測試與關閉議題）；只有使用者明確指示或議題描述明定無需測試時才移到「已完成」。
-- **只依實際狀態移動**：欄位只反映真實進度，不得先移欄位再補工作；若實作中途停止（待人工處理），欄位停留在「進行中」並於留言註明原因。
-- 議題不屬於任何專案、看板缺少可對應欄位、或 API 不支援移動時 → 回報並略過欄位調整，其餘流程照常。
 
 ### D2. 彙整需求並盤點既有 TODO
 
@@ -151,15 +130,14 @@ argument-hint: "[--tool <tea|api>] [--repo <owner/repo>] [--issues <編號,以
 
 依 D3 排序（多議題時先完成一個議題的所有 TODO，再進入下一個議題；有跨議題依賴時先處理被依賴者）逐項執行：
 
-1. **實作**：在本機 repo 依 TODO 內容實作，只修改該 TODO 必要範圍；發現需要擴大範圍或牽動其他 TODO 時，先停止並詢問使用者。開始實作該議題第一項 TODO 前，若議題屬於專案看板，依「議題進度欄位調整」把議題移到「進行中」。
+1. **實作**：在本機 repo 依 TODO 內容實作，只修改該 TODO 必要範圍；發現需要擴大範圍或牽動其他 TODO 時，先停止並詢問使用者。
 2. **驗證**：執行適合專案的建置／測試／驗證；失敗時修正到通過，無法通過則記錄原因並在留言中標註「待人工處理」。
-3. **更新議題 TODO 狀態**：實作完成（驗證通過）後，把議題描述中該 TODO 的 checkbox 由 `- [ ]` 勾成 `- [x]`（同 D4 的更新方式）；未通過驗證的 TODO 不得勾選。若母議題的 checklist 有**對應到本項 TODO** 的項目，一併勾選。
+3. **更新議題描述**：把該 TODO 的 checkbox 由 `- [ ]` 勾成 `- [x]`（同 D4 的更新方式）。
 4. **留言進度到議題**（每完成一項就留言，不可累積到最後一次補）：
    - `tea`：`tea comment <index> --repo <owner>/<repo> <內容>`
    - `api`：`POST {base}/issues/{index}/comments`，body 以 UTF-8 JSON 檔帶入
    - 留言內容以表格呈現：本項 TODO、影響範圍、主要變更（檔案／模組）、驗證方式與結果、整體進度（`已完成 n/總數 m`）；有助理解時附 Mermaid 圖。
-5. 全部 TODO 完成後，對每個議題留下**總結留言**：TODO 完成統計表、變更檔案清單、驗證總結、待人工處理項目（若有）；若議題屬於專案看板且全部 TODO 實作完成並驗證通過，把議題移到「待測試」（有待人工處理項目時停留在「進行中」）。
+5. 全部 TODO 完成後，對每個議題留下**總結留言**：TODO 完成統計表、變更檔案清單、驗證總結、待人工處理項目（若有）。
-6. **同步母議題 TODO 狀態**（D1 有記錄母議題時）：本議題全部 TODO 實作完成且驗證通過後，更新母議題描述，把其 checklist 中**引用本議題的項目**（如 `- [ ] #<本議題編號>`）勾成 `- [x]`（同 D4 的更新方式，保留母議題其餘內容不動），並在母議題留言告知「子議題 #<編號> 已實作完成」與總結留言連結。母議題 checklist 以其他文字描述本議題時做就近語意對應；**無法明確對應的項目不硬勾**，回報並略過。本議題尚有待人工處理項目時不得勾選母議題對應項目。
 
 > 本 skill 範圍到「實作＋留言」為止；是否 commit、push、開 PR 或關閉議題**不在本 skill 自動範圍**，由使用者另行指示（可搭配 `code-review-resolve` 的分類提交與 PR 流程）。
 
@@ -174,8 +152,6 @@ argument-hint: "[--tool <tea|api>] [--repo <owner/repo>] [--issues <編號,以
 - **階段 C**：處理的議題編號清單（含標題），是否因已提供而跳過詢問。
 - **階段 D**：每個議題的需求彙整重點、TODO 列表（含影響範圍排序）、新增了幾項 TODO 並是否已附加到議題描述。
 - **階段 E**：每項 TODO 的完成狀態與留言連結（或編號）、驗證結果、待人工處理項目；提醒後續可自行決定 commit／PR／關閉議題。
-- **欄位調整**：議題是否屬於專案看板、各議題的欄位移動紀錄（`#n：<原欄位> → <新欄位>`），或略過欄位調整的原因（不屬於專案／無可對應欄位／API 不支援）。
-- **母議題同步**：各議題是否有母議題、母議題 checklist 勾選了哪些項目與留言連結，或略過同步的原因（無母議題／無法明確對應／尚有待人工處理項目）。
 
 ---