Merge pull request 'feat(target): 新增 TARGET.md 每日排程執行 skill' (#18 ) from develop into master

Reviewed-on: #18 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
chore(plugin 版本): 三家 manifest 升版 0.0.3
2026-08-03 05:34:16 +00:00 · 2026-08-03 12:42:12 +08:00 · 2026-08-03 12:42:12 +08:00 · 2026-08-03 12:42:12 +08:00 · 2026-07-31 17:38:25 +00:00 · 2026-07-31 17:36:08 +00:00
28 changed files with 1468 additions and 1344 deletions
@@ -2,7 +2,7 @@
  "name": "code",
  "plugins": [
    {
-      "name": "jsc",
+      "name": "jsc-code",
      "source": {
        "source": "url",
        "url": "https://gitea.jsc.idv.tw/plugins/code.git"
@@ -1,14 +1,14 @@
 {
  "name": "code",
-  "description": "JSC 程式碼工作流 skills 的 Claude Code marketplace，涵蓋 git diff review、裁決歸檔、Gitea findings 修復/PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步與 action / Dockerfile 標準化。",
+  "description": "JSC 程式碼工作流 skills 的 Claude Code marketplace，涵蓋 Gitea findings 修復/PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步與 action / Dockerfile 標準化。",
  "owner": {
    "name": "JSC"
  },
  "plugins": [
    {
-      "name": "jsc",
+      "name": "jsc-code",
      "source": "./",
-      "description": "JSC 程式碼工作流 skills：RPG 攻防式 git diff review、裁決歸檔、Gitea AI review findings 修復與 PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步、action / Dockerfile 標準化。"
+      "description": "JSC 程式碼工作流 skills：Gitea AI review findings 修復與 PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步、action / Dockerfile 標準化。"
    }
  ]
 }
@@ -1,7 +1,7 @@
 {
-  "name": "jsc",
-  "version": "0.0.4",
-  "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: 前綴呼叫。",
+  "name": "jsc-code",
+  "version": "0.0.3",
+  "description": "JSC 程式碼工作流 plugin（Claude Code / Codex / Antigravity / OpenCode），提供 Gitea AI review findings 修復/PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步，以及 action / Dockerfile 標準化流程；於 Claude Code 以 /jsc-code: 前綴呼叫。",
  "skills": "./skills",
  "author": {
    "name": "JSC"
@@ -1,6 +1,6 @@
 {
-  "name": "jsc",
-  "version": "0.0.4",
-  "description": "JSC 程式碼工作流 plugin，提供 RPG 攻防式 git diff review、裁決結果歸檔、Gitea AI review findings 修復/PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步，以及 action / Dockerfile 標準化流程。",
+  "name": "jsc-code",
+  "version": "0.0.3",
+  "description": "JSC 程式碼工作流 plugin，提供 Gitea AI review findings 修復/PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步，以及 action / Dockerfile 標準化流程。",
  "skills": "./skills"
 }
@@ -1,4 +1,4 @@
-# jsc — 共用 Skills（跨 AI 助理）
+# jsc-code — 共用 Skills（跨 AI 助理）

 本 repo 是一組以 **Agent Skills（`SKILL.md`）** 標準撰寫的共用 skills，可同時被 Claude Code、Codex、Antigravity、OpenCode 使用。

@@ -6,7 +6,7 @@

 - 所有可用的 skills 位於本 repo 的 `skills/<name>/SKILL.md`。
 - 在處理任務前，先比對使用者需求與各 skill `SKILL.md` frontmatter 的 `description`，若相符請載入並依其步驟執行。
- **呼叫慣例**：在 Claude Code 與 Antigravity 中，這些 skill 以 `/jsc:<name>` 呼叫；Codex 以 `$<name>`、OpenCode 由模型依描述自動觸發 — 兩者沒有 `/jsc:` 前綴，不需強制加。
+- **呼叫慣例**：在 Claude Code 與 Antigravity 中，這些 skill 以 `/jsc-code:<name>` 呼叫；Codex 以 `$<name>`、OpenCode 由模型依描述自動觸發 — 兩者沒有 `/jsc-code:` 前綴，不需強制加。
 - 完整清單與每個 skill 的用途，請見 `README.md` 的「Skills 目錄」。

 ## 慣例
@@ -1,60 +1,58 @@
-# code — 跨 AI 助理 Plugin
+# jsc-code — 跨 AI 助理程式碼工作流 Plugin

-一個可同時被 **Claude Code、Codex、Antigravity、OpenCode** 安裝的 plugin，提供一組以 **程式碼工作流** 為核心的 skills：
-**RPG 攻防對決式 `git diff` review**、**裁決結果歸檔**、**Gitea AI review findings 修復、分類提交、push 與 PR 建立流程**、**Gitea 議題 TODO 彙整與逐項實作流程**、**C# / .NET NuGet 套件更新流程**、**Gitea 專案批次同步**，以及 **action / Dockerfile 標準化流程**。
+一個可同時被 **Claude Code、Codex、Antigravity、OpenCode、GitHub Copilot** 使用的 plugin，提供一組以 **程式碼工作流** 為核心的 skills：
+**Gitea AI review findings 修復、分類提交、push 與 PR 建立流程**、**Gitea 議題 TODO 彙整與逐項實作流程**、**C# / .NET NuGet 套件更新流程**、**Gitea 專案批次同步**、**`TARGET.md` 每日排程執行與 PR 流程**，以及 **action / Dockerfile 標準化流程**。
 核心是以 [Agent Skills（`SKILL.md`）](https://agentskills.io) 標準撰寫的共用 skills（唯一真實來源放在 `skills/`），
 搭配各助理各自的 plugin manifest，讓**同一個 repo** 可用各家**原生 plugin CLI** 安裝。
-plugin 名為 `jsc`，在 Claude Code 與 Antigravity 中 skill 以 **`/jsc:` 前綴**呼叫（例如 `/jsc:code-review`）。
+plugin 名為 `jsc-code`，在 Claude Code 與 Antigravity 中 skill 以 **`/jsc-code:` 前綴**呼叫（例如 `/jsc-code:issues`）。

 ---

 ## 前綴與呼叫方式

-| 助理 | 安裝方式 | 呼叫 | `/jsc:` 前綴 |
+| 助理 | 安裝方式 | 呼叫 | `/jsc-code:` 前綴 |
 | --- | --- | --- | --- |
-| Claude Code | `claude plugin`（marketplace） | `/jsc:<name>` 或自動觸發 | ✅ |
+| Claude Code | `claude plugin`（marketplace） | `/jsc-code:<name>` 或自動觸發 | ✅ |
 | Codex | `codex plugin`（marketplace） | `$<name>` 或 `/skills` 選單 | ❌（用 `$name`） |
-| Antigravity | `agy plugin install` | `/jsc:<name>` 或自動觸發 | ✅ |
+| Antigravity | `agy plugin install` | `/jsc-code:<name>` 或自動觸發 | ✅ |
 | OpenCode | skills 目錄（複製/clone） | 描述需求自動觸發 | ❌（依名稱） |
+| GitHub Copilot CLI | `copilot plugin`（marketplace） | 自然語言或 plugin skills | ❌（無 `/jsc-code:` 前綴） |

-> Codex 不支援自訂前綴（skill 以 `$name` 呼叫）；OpenCode 由模型依描述自動呼叫。兩者皆**不強制**前綴。
+> Codex 不支援自訂前綴（skill 以 `$name` 呼叫）；OpenCode 由模型依描述自動呼叫；Copilot CLI 透過原生 plugin 安裝後以自然語言或 plugin skills 使用。三者皆**不強制**前綴。

 ---

 ## 目錄結構

-同一個 repo 同時帶四種 manifest，彼此以路徑隔離、互不干擾；四家都讀同一份 `skills/`。
+同一個 repo 同時帶四種 manifest，彼此以路徑隔離、互不干擾；各助理都讀同一份 `skills/`。

 ```
 code/
 ├── .claude-plugin/
-│   ├── plugin.json          # Claude 外掛定義（name: "jsc"）
+│   ├── plugin.json          # Claude 外掛定義（name: "jsc-code"）
 │   └── marketplace.json     # Claude marketplace（name: "code"，source 指向本 repo）
 ├── .codex-plugin/
-│   └── plugin.json          # Codex 外掛定義（name: "jsc"，skills: "./skills"）
+│   └── plugin.json          # Codex 外掛定義（name: "jsc-code"，skills: "./skills"）
 ├── .agents/plugins/
 │   └── marketplace.json     # Codex marketplace（name: "code"，url source 指向本 repo）
-├── plugin.json              # Antigravity 外掛定義（name: "jsc"，skills: "./skills/"）
+├── plugin.json              # Antigravity 外掛定義（name: "jsc-code"，skills: "./skills/"）
 ├── skills/                  # ★ 唯一真實來源：所有 skills
-│   ├── code-review/
-│   │   ├── SKILL.md         # 主 skill：取 diff → 選角 → 攻擊 → 裁決 → 總結
-│   │   └── roles/           # 一角色一檔（bard/mage/rogue/assassin/paladin）
-│   ├── code-review-archive/ # 保存裁決：成立→已知問題、誤判→排除事項
-│   ├── code-review-resolve/ # 解決 findings.json + 分類提交 + push + 發 PR
-│   ├── code-issues/         # 彙整議題 TODO（影響範圍小→大）+ 逐項實作 + 留言進度
-│   ├── code-nuget/          # C# / .NET NuGet 套件更新 + build 驗證
-│   ├── code-sync/           # 依擁有者批次 clone／更新 Gitea 專案
-│   ├── code-action-docker/  # 問答式打造 docker action（Node 主程式）+ 串接 doc-funcs
-│   ├── code-action-composite/ # composite action 標準化 + 串接 doc-funcs
-│   ├── code-image/          # Dockerfile 整理成六步流程 + 串接 doc-funcs
-│   └── hello/               # 範例 skill：驗證安裝、新增 skill 的範本
+│   ├── review-resolve/ # 解決 findings.json + 分類提交 + push + 發 PR
+│   ├── issues/         # 彙整議題 TODO（影響範圍小→大）+ 逐項實作 + 留言進度
+│   ├── nuget/          # C# / .NET NuGet 套件更新 + build 驗證
+│   ├── sync/           # 依擁有者批次 clone／更新 Gitea 專案
+│   ├── action-docker/  # action 容器化（Node 主程式）+ 串接 funcs
+│   ├── action-composite/ # composite action 標準化 + 串接 funcs
+│   ├── action-node/    # Node（JS）action 標準化（ncc 打包）+ 串接 funcs
+│   ├── image/          # Dockerfile 整理成六步流程 + 串接 funcs
+│   └── target/         # TARGET.md 每日 00:00 排程執行 + 分類提交 + push develop + PR
 ├── AGENTS.md                # 跨助理共用指引
 └── README.md
 ```

 ---

-## 安裝 / 更新 / 移除（各家原生 plugin CLI）
+## 安裝 / 更新 / 移除（各助理）

 > 指令中的 repo 網址換成你的：`https://gitea.jsc.idv.tw/plugins/code.git`
 >
@@ -67,39 +65,39 @@ code/
 ```bash
 # 安裝
 claude plugin marketplace add https://gitea.jsc.idv.tw/plugins/code.git
-claude plugin install jsc@code
+claude plugin install jsc-code@code

 # 更新
 claude plugin marketplace update code
-claude plugin update jsc@code
+claude plugin update jsc-code@code

 # 移除
-claude plugin uninstall jsc@code
+claude plugin uninstall jsc-code@code
 claude plugin marketplace remove code
 ```

 - 工作階段內 slash 版（等價）：把 `claude plugin` 換成 `/plugin`。
 - 本機開發（免 push）：`claude plugin marketplace add C:\Users\h3285\source\repos.plugins\code`（本地路徑）後再 install。
- **呼叫**：`/jsc:<name>`（例 `/jsc:code-review`）。
+- **呼叫**：`/jsc-code:<name>`（例 `/jsc-code:issues`）。

 ### Codex

 ```bash
 # 安裝
 codex plugin marketplace add https://gitea.jsc.idv.tw/plugins/code.git
-codex plugin add jsc@code
+codex plugin add jsc-code@code

 # 更新（重新抓取 marketplace 的 git 快照）
 codex plugin marketplace upgrade code

 # 移除
-codex plugin remove jsc@code
+codex plugin remove jsc-code@code
 codex plugin marketplace remove code
 ```

- 安裝 token `jsc@code` = plugin 名（`.codex-plugin/plugin.json` 的 `name`）@ marketplace 名（`.agents/plugins/marketplace.json` 的 `name`）。
+- 安裝 token `jsc-code@code` = plugin 名（`.codex-plugin/plugin.json` 的 `name`）@ marketplace 名（`.agents/plugins/marketplace.json` 的 `name`）。
 - 本 repo 的 Codex marketplace 以 `url` 來源指向自己，故 Codex **一律從 gitea 安裝**（需先 push）；安裝後重啟 Codex。
- **呼叫**：`$<name>`（例 `$code-review`），或用 `/skills` 選單。
+- **呼叫**：`$<name>`（例 `$issues`），或用 `/skills` 選單。

 ### Antigravity（`agy`）

@@ -112,16 +110,16 @@ agy plugin install ~/plugins/code

 # 更新（agy 無 update 子指令 → git pull 後重裝）
 git -C ~/plugins/code pull
-agy plugin uninstall jsc
+agy plugin uninstall jsc-code
 agy plugin install ~/plugins/code

 # 移除
-agy plugin uninstall jsc
+agy plugin uninstall jsc-code
 ```

 - 若把 skills 放到 GitHub，則可直接 `agy plugin install https://github.com/<owner>/<repo>`。
- 其他：`agy plugin list`、`agy plugin enable jsc` / `disable jsc`、`agy plugin validate <path>`。安裝後重啟工作階段。
- **呼叫**：`/jsc:<name>`（例 `/jsc:code-review`）或依描述自動觸發。
+- 其他：`agy plugin list`、`agy plugin enable jsc-code` / `disable jsc-code`、`agy plugin validate <path>`。安裝後重啟工作階段。
+- **呼叫**：`/jsc-code:<name>`（例 `/jsc-code:issues`）或依描述自動觸發。

 ### OpenCode

@@ -130,39 +128,62 @@ OpenCode 會讀 `~/.config/opencode/skills/`（也會讀 `~/.claude/skills/`、`

 ```bash
 # 安裝
-git clone https://gitea.jsc.idv.tw/plugins/code.git ~/jsc-plugin
+git clone https://gitea.jsc.idv.tw/plugins/code.git ~/plugins/code
 mkdir -p ~/.config/opencode/skills
-cp -r ~/jsc-plugin/skills/* ~/.config/opencode/skills/
+cp -r ~/plugins/code/skills/* ~/.config/opencode/skills/

 # 更新
-git -C ~/jsc-plugin pull
-cp -r ~/jsc-plugin/skills/* ~/.config/opencode/skills/
+git -C ~/plugins/code pull
+cp -r ~/plugins/code/skills/* ~/.config/opencode/skills/

 # 移除
-rm -rf ~/.config/opencode/skills/{code-review,code-review-archive,code-review-resolve,code-issues,code-nuget,code-sync,code-action-docker,code-action-composite,code-image,hello}
+rm -rf ~/.config/opencode/skills/{review-resolve,issues,nuget,sync,action-docker,action-composite,action-node,image,target}
 ```

 > **Windows PowerShell**：`cp -r A B` → `Copy-Item A B -Recurse -Force`、`rm -rf X` → `Remove-Item X -Recurse -Force`、`~` → `$HOME`。

 - **呼叫**：直接描述需求，模型會依 skill 描述自動透過 skill 工具呼叫。

+### GitHub Copilot CLI
+
+Copilot CLI 支援與 Claude Code 類似的原生 plugin / marketplace 指令，可直接從 marketplace 安裝、更新與移除本 plugin。
+
+```bash
+# 安裝
+copilot plugin marketplace add https://gitea.jsc.idv.tw/plugins/code.git
+copilot plugin install jsc-code@code
+
+# 更新
+copilot plugin marketplace update code
+copilot plugin update jsc-code@code
+
+# 移除
+copilot plugin uninstall jsc-code@code
+copilot plugin marketplace remove code
+```
+
+- 安裝 token `jsc-code@code` = plugin 名（plugin manifest 的 `name`）@ marketplace 名。
+- `copilot plugin marketplace add` 支援 GitHub `owner/repo`、git URL 與本地路徑；Gitea repo 可用上方 HTTPS URL。
+- **呼叫**：在 Copilot CLI 中用自然語言描述需求，例如 `copilot -i "請使用 issues 處理 plugins/code 的 12、15 號議題"`。
+
 ---

 ## 用 CLI 直接執行 skill（headless / 一次性）

 安裝好之後，不必進互動介面，一行指令就能叫某個 skill 跑完並印出結果：

-| 助理 | headless 指令 | 執行 `code-review` skill |
+| 助理 | headless 指令 | 執行 `issues` skill |
 | --- | --- | --- |
-| Claude Code | `claude -p "<prompt>"` | `claude -p "/jsc:code-review main feature/login all --exclusions exclusions.md --known-issues known-issues.md"` |
-| Codex | `codex exec "<prompt>"` | `codex exec '$code-review main feature/login all --exclusions exclusions.md --known-issues known-issues.md'` |
-| Antigravity | `agy -p "<prompt>"` | `agy -p "/jsc:code-review main feature/login all --exclusions exclusions.md --known-issues known-issues.md"` |
-| OpenCode | `opencode run "<message>"` | `opencode run "用攻防角色 review main 與 feature/login 的差異"` |
+| Claude Code | `claude -p "<prompt>"` | `claude -p "/jsc-code:issues --tool api --repo plugins/code --issues 12,15 --yes"` |
+| Codex | `codex exec "<prompt>"` | `codex exec '$issues --tool api --repo plugins/code --issues 12,15 --yes'` |
+| Antigravity | `agy -p "<prompt>"` | `agy -p "/jsc-code:issues --tool api --repo plugins/code --issues 12,15 --yes"` |
+| OpenCode | `opencode run "<message>"` | `opencode run "讀 plugins/code 的 12、15 號議題，整理 TODO 並逐項實作、留言進度"` |
+| GitHub Copilot CLI | `copilot -p "<message>"` | `copilot -p "讀 plugins/code 的 12、15 號議題，整理 TODO 並逐項實作、留言進度"` |

- Claude / Antigravity 支援 `/jsc:` 前綴，直接 `-p "/jsc:<name>"` 即可。
- Codex 以 `$<name>` 觸發；在 shell 請用**單引號**避免 `$` 被展開：`codex exec '$code-review …'`。
- OpenCode 沒有前綴，用自然語言描述需求，模型會自動透過 skill 工具呼叫。
- 帶引數就接在後面，例如 `claude -p "/jsc:code-review main feature/login mage"`、`codex exec '$code-review main feature/login mage'`。
+- Claude / Antigravity 支援 `/jsc-code:` 前綴，直接 `-p "/jsc-code:<name>"` 即可。
+- Codex 以 `$<name>` 觸發；在 shell 請用**單引號**避免 `$` 被展開：`codex exec '$issues …'`。
+- OpenCode 與 Copilot 沒有前綴，用自然語言描述需求；Copilot CLI 會讀取已安裝 plugin 提供的 skills。
+- 帶引數就接在後面，例如 `claude -p "/jsc-code:issues --issues 12"`、`codex exec '$issues --issues 12'`。

 ---

@@ -173,103 +194,95 @@ rm -rf ~/.config/opencode/skills/{code-review,code-review-archive,code-review-re

 <!-- JSC-SKILLS:START -->

-### `code-review`
-
-以 RPG 攻防對決方式審查 `git diff` 的程式碼審查 skill。審查範圍是兩個分支的差異，**來源分支與目標分支缺一不可**（缺漏會反問補齊）。角色分**攻擊方**（吟遊詩人=風格 🎼／法師=邏輯 🔮／盜賊=效率 ⚡／刺客=安全性 🗡️）與**防守方**（聖騎士=裁決 🛡️），每個角色定義在 `skills/code-review/roles/<role>.md`（含英文名稱／專案／個性／徽章／代表色）。攻擊方分析 diff 找出問題（問題／等級／描述／建議／檔案位置／所在行數，審查前自動排除 `.` 開頭資料夾內的內容、以及排除事項檔與前次審查紀錄檔本身）；防守方依專案根目錄排除事項設定檔、**前次審查紀錄（已知問題＝前次發現但未解決的問題）**與原始碼脈絡裁決每條問題（🚫 略過／🔁 已知問題／❌ 誤判／✅ 成立）。使用者可選擇單一角色、整個攻擊方、整個防守方或全部；複選時以 sub agent 並行執行。
-
-參數格式：`<target> <source> [角色...] [--exclusions <排除事項檔案路徑>] [--known-issues <前次審查紀錄路徑>]`（目標在前、來源在後；角色可省略，會詢問；`--exclusions`、`--known-issues` 指定對應檔案路徑，省略時若選到防守方會反問）。
-
- **Claude Code / Antigravity**：`/jsc:code-review`（反問分支與角色），或帶參數 `/jsc:code-review main feature/login mage`、`/jsc:code-review main feature/login all --exclusions exclusions.md --known-issues known-issues.md`
- **Codex**：`$code-review main feature/login attack`，或 `$code-review main feature/login all --exclusions docs/review-rules.md --known-issues docs/known-issues.md`，或用 `/skills` 選單
- **OpenCode**：描述需求（如「用攻防角色 review main 與 feature/login 的差異，排除事項看 docs/review-rules.md、已知問題看 docs/known-issues.md」）自動觸發
-
-### `code-review-archive`
-
-將 `/jsc:code-review` 已裁決的問題保存到專案：**✅ 成立** 附加到前次審查紀錄（已知問題）檔、**❌ 誤判** 附加到排除事項檔，讓防守方下次自動標 🔁 已知問題 / 🚫 略過；🔁／🚫 已存在者僅計數不重複寫入。只吃既有裁決結果（合併攻擊方問題表＋防守方裁決表），不自己跑 review、不改程式碼，且寫檔前先取得同意。檔案格式依副檔名（`.md` / `.json`）決定。
-
-參數：`--known-issues <前次審查紀錄路徑> --exclusions <排除事項檔案路徑>`（與 code-review 同名旗標，沿用同一組路徑；缺漏會反問）。
-
- **Claude Code / Antigravity**：`/jsc:code-review-archive --known-issues known-issues.md --exclusions exclusions.md`
- **Codex**：`$code-review-archive --known-issues docs/known-issues.md --exclusions docs/review-rules.md`，或用 `/skills` 選單
- **OpenCode**：描述需求（如「把剛剛 code-review 成立的問題存到 known-issues.md、誤判存到 exclusions.md」）自動觸發
-
-### `code-review-resolve`
+### `review-resolve`

 五階段：**(A Git 同步)** 先 `fetch`，務必檢查目前分支的線上分支是否存在；存在則留在目前分支更新到最新，不存在則依序切換到遠端 `develop`／`master` 並更新到最新，找不到後備分支則停止；pull 發生衝突時告知並嘗試安全解衝突；只有來源分支與 PR 目標分支相同時，才必須從該分支建立新的工作分支，後續修復、commit、push 與 PR `head` 都使用新分支。**(B 解決)** 讀工作目錄 `.gitea/ai-review/findings.json`（Gitea AI review 產出的問題清單），依嚴重等級 **🔴 嚴重 → 🟠 高 → 🟡 中 → 🔵 低** 由高到低**逐條修復**程式碼問題或登記誤報（無法安全自動修復者標「待人工處理」不硬改），已解決或已登記誤報者才自 `findings.json` 移除。**(C 提交)** 分析工作區**所有**變更，依異動內容歸類為 `feat`/`fix`/`docs`/`style`/`refactor`/`perf`/`test`/`chore`/`revert`，**每個 type 各自一個 commit**，訊息為「`type(範圍): 一句總結`」格式，**括號內的範圍須對應實際異動的功能／模組**（例 `feat(使用者登入): 新增帳密登入流程`、`perf(物件查詢): 改用批次查詢降低 DB 往返`，而非 `feat(新增功能)` 這類重述 type 的詞）。**(D 推送)** push 當前分支：先用**認證管理器**、失敗改用 **token**、再失敗**詢問使用者**。**(E 開 PR)** 用 token 透過 **Gitea API** 對目標分支發 PR（**目標分支不明必須詢問、不可猜測**），PR 描述可選**完整版**（重新分析 `git diff` 總結）／**簡單版**（逐條列 commit 訊息）／**使用者輸入**；完成後因內文可能含 gitea token，**提醒並清除 AI 助理對話內文**。除非遇到必要決策，否則依自動執行原則直接處理；token 一律由環境變數（如 `GITEA_TOKEN`）提供，全程不明文輸出。

 參數：`[--findings <findings.json 路徑>] [--target <目標分支>] [--pr-desc <full|simple|自訂文字>] [--no-commit] [--no-pr] [--yes]`（findings 省略時預設 `.gitea/ai-review/findings.json`；`--target` 省略且需要開 PR 時必問；`--no-commit` 只修復不提交；`--no-pr` 推送但不開 PR；`--yes` 略過確認）。

- **Claude Code / Antigravity**：`/jsc:code-review-resolve`，或 `/jsc:code-review-resolve --target develop --pr-desc full --yes`、`/jsc:code-review-resolve --no-pr`、`/jsc:code-review-resolve --no-commit`
- **Codex**：`$code-review-resolve`，或 `$code-review-resolve --target develop --pr-desc simple --yes`，或用 `/skills` 選單
+- **Claude Code / Antigravity**：`/jsc-code:review-resolve`，或 `/jsc-code:review-resolve --target develop --pr-desc full --yes`、`/jsc-code:review-resolve --no-pr`、`/jsc-code:review-resolve --no-commit`
+- **Codex**：`$review-resolve`，或 `$review-resolve --target develop --pr-desc simple --yes`，或用 `/skills` 選單
 - **OpenCode**：描述需求（如「讀 .gitea/ai-review/findings.json 依嚴重度逐條修好、清空該檔，把工作區變更依 conventional commit 分類提交，push 後對 develop 發 PR（完整版描述）」）自動觸發

-### `code-issues`
+### `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 並留言進度到議題**，全部完成後留下總結留言。議題若**屬於專案看板**且有「分析中／待處理／進行中／待測試／已完成」欄位可調整，依處理進度**同步移動議題欄位**（彙整需求「分析中」→ 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` 略過一般確認）。

- **Claude Code / Antigravity**：`/jsc:code-issues`，或 `/jsc:code-issues --tool api --repo plugins/code --issues 12,15 --yes`
- **Codex**：`$code-issues`，或 `$code-issues --tool tea --repo plugins/code --issues 12`，或用 `/skills` 選單
+- **Claude Code / Antigravity**：`/jsc-code:issues`，或 `/jsc-code:issues --tool api --repo plugins/code --issues 12,15 --yes`
+- **Codex**：`$issues`，或 `$issues --tool tea --repo plugins/code --issues 12`，或用 `/skills` 選單
 - **OpenCode**：描述需求（如「讀 plugins/code 的 12、15 號議題，整理需求成 TODO 依影響範圍小到大排序、缺的補進議題描述，逐項實作、每完成一項留言進度」）自動觸發

-### `code-nuget`
+### `nuget`

 將 C# / .NET 專案的 NuGet 套件更新到最新可用版本。流程會先探測 `.sln` / `.slnx` / `.csproj` 與 `dotnet` 工具，執行 baseline `restore` / `build`，再**依專案分組列出所有 direct / transitive 套件**與目前版本、最新版本、參考來源。接著建立 `ProjectReference` graph：若當前專案所參考的上層專案已 direct reference 相同 NuGet 套件，且該套件會透過專案參考安全傳遞，便逐一移除重複 `PackageReference`；每移除一筆都立刻 `restore` / `build` 驗證，失敗即回復。最後逐一更新 direct 套件版本（支援 Central Package Management / `Directory.Packages.props`），**每更新一個套件就 restore/build 確認專案可正常編譯**；若最新版本編譯失敗，改從目前版本之後的最小可用版本逐版升級，直到遇到第一個編譯失敗版本，保留最後一個可編譯版本並記錄失敗點。

 參數：`[<solution-or-project>] [--include-prerelease] [--no-dedupe] [--build <command>] [--yes]`（目標可為 `.sln`、`.slnx` 或 `.csproj`；`--include-prerelease` 允許 prerelease；`--no-dedupe` 略過重複參考清理；`--build` 覆寫驗證指令；`--yes` 略過一般確認但不略過必要決策）。

- **Claude Code / Antigravity**：`/jsc:code-nuget`，或 `/jsc:code-nuget MySolution.sln --include-prerelease`
- **Codex**：`$code-nuget`，或 `$code-nuget src/App/App.csproj --build "dotnet build App.sln -c Release"`，或用 `/skills` 選單
+- **Claude Code / Antigravity**：`/jsc-code:nuget`，或 `/jsc-code:nuget MySolution.sln --include-prerelease`
+- **Codex**：`$nuget`，或 `$nuget src/App/App.csproj --build "dotnet build App.sln -c Release"`，或用 `/skills` 選單
 - **OpenCode**：描述需求（如「把這個 .NET solution 的 NuGet 都更新到最新，先清掉 ProjectReference 已提供的重複套件，每更新一包就 build」）自動觸發

-### `code-sync`
+### `sync`

 透過 `GITEA_TOKEN` 把使用者有讀取權限的 Gitea 專案批次 clone 到本機並依擁有者分類。流程會先確認 token、決定 gitea 主機與目標根目錄（預設家目錄），再以 token 分頁呼叫 `GET /api/v1/user/repos` 取回**所有有讀取權限**的專案、依 `owner` 分組（預設排除 fork）；接著列出所有擁有者讓使用者**多選**（帶 `--owner` 則跳過詢問），列出選定擁有者底下的專案後，於 `<根目錄>/<擁有者>/<專案名>` 逐一處理：**不存在則 clone**（HTTPS＋token，clone 後還原乾淨 origin；或 `--ssh`），**已存在則 `fetch` → 切到 develop（再退而 master）→ `pull --ff-only` 更新到最新**。全程唯讀（不 push、不改遠端），工作區有未提交變更的專案會略過而非強制覆蓋；token 一律由環境變數提供、不寫死也不印出。

 參數：`[--target-dir <根目錄>] [--owner <擁有者,以逗號分隔>] [--host <gitea 主機>] [--include-forks] [--ssh] [--yes]`（根目錄預設家目錄；`--owner` 預先指定擁有者並跳過多選；`--host` 指定 gitea 主機；`--include-forks` 納入 fork；`--ssh` 改用 SSH clone；`--yes` 略過一般確認但不略過擁有者多選）。

- **Claude Code / Antigravity**：`/jsc:code-sync`，或 `/jsc:code-sync --owner plugins --target-dir ~/work`、`/jsc:code-sync --include-forks --ssh`
- **Codex**：`$code-sync`，或 `$code-sync --owner plugins --target-dir ~/work`，或用 `/skills` 選單
+- **Claude Code / Antigravity**：`/jsc-code:sync`，或 `/jsc-code:sync --owner plugins --target-dir ~/work`、`/jsc-code:sync --include-forks --ssh`
+- **Codex**：`$sync`，或 `$sync --owner plugins --target-dir ~/work`，或用 `/skills` 選單
 - **OpenCode**：描述需求（如「用 GITEA_TOKEN 取得我有讀取權限的所有 Gitea 專案，依擁有者分組讓我多選，把選定擁有者的專案 clone 到家目錄；已存在的切到 develop／master 更新到最新」）自動觸發

-### `code-action-docker`
+### `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`），**盡量詳細輸出訊息**且格式統一為 `[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`（`runs` 只設 `using: docker`＋`image: Dockerfile`，**不設相對路徑的 `entrypoint`**，入口由 Dockerfile 的絕對路徑 `ENTRYPOINT` 決定）；(C) 產生 `entrypoint.sh`，**啟動 node 前先輸出 action 名稱／用途／更新時間**（Asia/Taipei `yyyy/MM/dd HH:mm:ss`）再 `exec node`；(D) 依**六步流程**（參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口）產生**使用最新 LTS node 版本（固定 major tag）**的 `Dockerfile`，**每步內容依主程式（`src/`）實作量身決定**（先盤點相依／是否需 build／OS 層相依／入口檔並產生 `.dockerignore`，再填對應步驟，用不到的不硬塞），預設 build 基底為當前 LTS（如 `node:22`）、runtime 對應 `-slim`（如 `node:22-slim`），**多階段建置逐項明列必要產物**（不整包 COPY）縮小映像，`ENTRYPOINT` 指向 `entrypoint.sh`（絕對路徑）；(E) 對整個專案**完整執行 `/jsc-doc:funcs`**（function 文件、`entrypoint.sh`／`Dockerfile` 逐行註解、重建 README）。開發中需要新參數時依**參數來源優先序**處理：優先取用 runner 注入容器的 `GITHUB_*`／`GITEA_*` 執行期環境變數（即 `gitea.*`／`github.*` context 的同源資訊；docker action 的 `action.yml` 幾乎只有 `inputs`／`env` context 可用），無法取得才經使用者同意**新增 `inputs`**（容器內讀 `INPUT_*`）；`secrets`／`vars` context 在 docker action 內**一律視為不可用**（GitHub 官方文件僅記載 `inputs` context、runner 不注入 secrets；Gitea 行為無保證），需要時宣告為 `inputs` 由呼叫端 workflow 以 `with:` 傳入，未經同意不擅改 `inputs`／`outputs` 契約。目錄沒有 `action.yml` 時可走**問答式從零建立**（收集名稱／輸入輸出／執行目標後產生 docker `action.yml` 與 `src/index.js` 骨架，再接後續階段）。skill 各檔的「更新時間」於最終階段（funcs 完成後）**統一同步為同一時間戳**。

-參數：`[--action-dir <action 根目錄>] [--node-version <node tag>]`（根目錄預設目前工作目錄；node 版本預設最新；名稱／輸入輸出／目標以問答取得，呼叫時已口述者不再重問）。
+參數：`[--action-dir <action 根目錄>] [--node-version <node tag>] [--main <主程式檔>]`（根目錄預設目前工作目錄；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 補文件並重建 README」）自動觸發
+- **Claude Code / Antigravity**：`/jsc-code:action-docker`，或 `/jsc-code:action-docker --action-dir ~/work/my-action --node-version 22`
+- **Codex**：`$action-docker`，或 `$action-docker --action-dir ~/work/my-action`，或用 `/skills` 選單
+- **OpenCode**：描述需求（如「把這個 action 主程式改成 node、主程式相關 js 收進 src/，產生會先輸出 action 名稱／用途／更新時間再啟動 node 的 entrypoint.sh、用最新 LTS node 版本的 Dockerfile，最後跑 funcs 補文件並重建 README」）自動觸發

-### `code-action-composite`
+### `action-composite`

-把 Gitea／GitHub「composite action」專案標準化，再串接文件化流程。四階段：(A) 找出 action 專案、讀 `action.yml`／`action.yaml` 的 `name`／`description`／`runs`、判斷是否為 composite；(B) **已是 composite 則保留既有 `steps`**，非 composite（JS／Docker）則**保守確認後對齊**為 composite（高風險先以 AskUserQuestion 確認，保留 `inputs`／`outputs` 契約；Docker 行為無法等價塞入時標「需人工確認」並建議改用 `code-action-docker`）；(C) 在 `runs.steps` **最前面注入啟動橫幅 step**，輸出 action **名稱／用途／更新時間**（Asia/Taipei `yyyy/MM/dd HH:mm:ss`，固定字串），並於 `action.yml` 開頭補用途／更新時間註解區塊（既有橫幅 step 則更新而非重插）；(D) 對整個專案**完整執行 `/jsc:doc-funcs`**（`action.yml` 與被引用腳本逐行註解、function 文件、重建 README）。
+把 Gitea／GitHub「composite action」專案標準化，再串接文件化流程。四階段：(A) 找出 action 專案、讀 `action.yml`／`action.yaml` 的 `name`／`description`／`runs`、判斷是否為 composite；(B) **已是 composite 則保留既有 `steps`**，非 composite（JS／Docker）則**保守確認後對齊**為 composite（高風險先以 AskUserQuestion 確認；JS action 轉換須補 `INPUT_*` env 映射與 `outputs.value` 轉接以保留 `inputs`／`outputs` 契約；Docker 行為無法等價塞入時標「需人工確認」並建議改用 `action-docker`）；(C) 在 `runs.steps` **最前面注入啟動橫幅 step**，輸出 action **名稱／用途／更新時間**（Asia/Taipei `yyyy/MM/dd HH:mm:ss`，固定字串），並於 `action.yml` 開頭補用途／更新時間註解區塊（既有橫幅 step 則更新而非重插）；(D) 對整個專案**完整執行 `/jsc-doc:funcs`**（`action.yml` 與被引用腳本逐行註解、function 文件、重建 README）。開發中需要新參數時依**參數來源優先序**處理：優先取用 `${{ gitea.* }}`／`${{ github.* }}` context（Gitea 中兩者互為別名，composite step 內可直接使用、`run` 腳本內可讀同源 `$GITHUB_*` 環境變數），無法取得才經使用者同意**新增 `inputs`**；`secrets`／`vars` context 在 composite action 內**一律視為不可用**（GitHub 官方明文限制；Gitea act_runner 未嚴格檢查 context 可用性、行為無保證），需要時宣告為 `inputs` 由呼叫端 workflow 以 `with:` 傳入，未經同意不擅改 `inputs`／`outputs` 契約。目錄沒有 `action.yml` 時可走**問答式從零建立**（收集名稱／輸入輸出／執行目標後產生 composite `action.yml` 並實作 steps，再接後續階段）。skill 各檔的「更新時間」於最終階段（funcs 完成後）**統一同步為同一時間戳**。

-參數：`[--action-dir <action 根目錄>] [--manifest <action.yml 路徑>] [--yes]`（根目錄預設目前工作目錄；manifest 自動尋找 `action.yml`／`action.yaml`；`--yes` 略過一般確認，但「非 composite 需對齊」與 doc-funcs 的實作詢問仍會中斷）。
+參數：`[--action-dir <action 根目錄>] [--manifest <action.yml 路徑>]`（根目錄預設目前工作目錄；manifest 自動尋找 `action.yml`／`action.yaml`）。

- **Claude Code / Antigravity**：`/jsc:code-action-composite`，或 `/jsc:code-action-composite --action-dir ~/work/my-action`
- **Codex**：`$code-action-composite`，或 `$code-action-composite --action-dir ~/work/my-action`，或用 `/skills` 選單
- **OpenCode**：描述需求（如「把這個 composite action 標準化，在 steps 最前面加一個會輸出 action 名稱／用途／更新時間的 step，最後跑 doc-funcs 補文件並重建 README」）自動觸發
+- **Claude Code / Antigravity**：`/jsc-code:action-composite`，或 `/jsc-code:action-composite --action-dir ~/work/my-action`
+- **Codex**：`$action-composite`，或 `$action-composite --action-dir ~/work/my-action`，或用 `/skills` 選單
+- **OpenCode**：描述需求（如「把這個 composite action 標準化，在 steps 最前面加一個會輸出 action 名稱／用途／更新時間的 step，最後跑 funcs 補文件並重建 README」）自動觸發

-### `code-image`
+### `action-node`

-把專案既有的 `Dockerfile` **整理成固定六步流程**，再串接文件化流程。三階段：(A) 找出專案根目錄、定位目標 `Dockerfile`（找不到則詢問、**不臆造**；要產生全新 action 容器請改用 `code-action-docker`），讀現有指令、判斷語言／生態與既有 base image／建置流程；(B) 在**保留建置行為**前提下，把指令重整／歸位為**六步流程**（參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口）：可調參數集中於檔首 `ARG`、相依描述先 `COPY` 以利 layer 快取、**多階段建置**讓 runtime 改用較小基底（`*-slim`／`*-alpine`／`distroless` 等）只帶執行所需產物；`ENTRYPOINT`／`CMD`／`EXPOSE`／`ENV` 等對外契約不動，**無法保證等價的重整先以 AskUserQuestion 確認**（可選最小重排或只補註解）；(C) 對整個專案**完整執行 `/jsc:doc-funcs`**（`Dockerfile` 等指令檔逐行註解、function 文件、重建 README）。
+把 Gitea／GitHub「Node（JavaScript）action」專案標準化，再串接文件化流程。node action 由 **runner 內建 Node 直接執行 `runs.main`**（不需 Docker、啟動比 docker action 快），但 **runner 不會自動 `npm install`**——這是與 docker／composite 最大的差異。五階段：(A) 找出 action 專案、讀 `action.yml`／`action.yaml` 的 `name`／`description`、判斷主程式語言（無 manifest 可**問答式從零建立**）；(B) 主程式**非 Node 則保守改寫為 Node**（高風險，先以 AskUserQuestion 確認，保留對外行為），並把**主程式依賴鏈**的 `.js` 集中到 **`src/`**（工具設定檔與測試目錄不搬）、同步更新 `require`／`import` 路徑、`package.json` 與 `action.yml`；(C) 對齊 `runs` 為 node action（`using: node24` + `main`，`--node-version` 可覆寫、runner 太舊退 `node20`），**`outputs` 去除 `value`**（node 只需 `description`，值於執行時寫入 `$GITHUB_OUTPUT`）、**`inputs` 由 runner 自動注入 `INPUT_*`**（不像 composite 需手動映射），並在**主程式入口最前面**以 `console.log` 輸出 action 名稱／用途／更新時間（Asia/Taipei `yyyy/MM/dd HH:mm:ss`；node action 無 `entrypoint.sh`，橫幅改在 JS 輸出）；(D) 相依處理——**零相依**則 `main` 直接指 `src/index.js`，**有相依**則以 [`@vercel/ncc`](https://github.com/vercel/ncc) 打包成 `dist/index.js`、`main` 改指 `dist/index.js` 並**把 `dist/` commit 進 repo**（確認 `.gitignore` 未忽略）；(E) 對整個專案**完整執行 `/jsc-doc:funcs`**（function 文件、`src/` 主程式與 `action.yml` 註解、重建 README）。開發中需要新參數時依**參數來源優先序**處理：主程式優先取 runner 注入的 `GITHUB_*`／`GITEA_*` 執行期環境變數，既有 `inputs` 以 `process.env.INPUT_*`（或 `core.getInput`）取用，無法取得才經使用者同意**新增 `inputs`**；`secrets`／`vars` **一律視為不可用**，需要時宣告為 `inputs` 由呼叫端 workflow 以 `with:` 傳入，未經同意不擅改 `inputs`／`outputs` 契約。skill 各檔的「更新時間」於最終階段（funcs 完成後）**統一同步為同一時間戳**。

-參數：`[--project-dir <專案根目錄>] [--dockerfile <Dockerfile 路徑>] [--yes]`（專案根目錄預設目前工作目錄；Dockerfile 自動定位、多個時詢問；`--yes` 略過一般確認，但「重整無法保證行為等價」與 doc-funcs 的實作詢問仍會中斷）。
+參數：`[--action-dir <action 根目錄>] [--node-version <node runtime>] [--main <主程式檔>]`（根目錄預設目前工作目錄；node 版本預設 `node24`；主程式自動判斷）。

- **Claude Code / Antigravity**：`/jsc:code-image`，或 `/jsc:code-image --project-dir ~/work/my-app --dockerfile build/Dockerfile`
- **Codex**：`$code-image`，或 `$code-image --dockerfile docker/Dockerfile`，或用 `/skills` 選單
- **OpenCode**：描述需求（如「把這個專案的 Dockerfile 整理成參數處理→安裝套件→複製檔案→執行程序→縮小映像檔→設定入口六步、用多階段建置縮小映像，最後跑 doc-funcs 補文件並重建 README」）自動觸發
+- **Claude Code / Antigravity**：`/jsc-code:action-node`，或 `/jsc-code:action-node --action-dir ~/work/my-action --node-version node24`
+- **Codex**：`$action-node`，或 `$action-node --action-dir ~/work/my-action`，或用 `/skills` 選單
+- **OpenCode**：描述需求（如「把這個 action 主程式改成 node、主程式相關 js 收進 src/，對齊 action.yml 為 node action、在主程式最前面輸出 action 名稱／用途／更新時間，有相依就用 ncc 打包成 dist 並 commit，最後跑 funcs 補文件並重建 README」）自動觸發

-### `hello`
+### `image`

-範例 skill，用來驗證 `jsc` plugin 是否安裝成功，也是新增 skill 的範本。觸發時回覆問候並簡述 plugin 用途。
+把專案既有的 `Dockerfile` **整理成固定六步流程**，再串接文件化流程。三階段：(A) 找出專案根目錄、定位目標 `Dockerfile`（找不到則詢問、**不臆造**；要產生全新 action 容器請改用 `action-docker`），讀現有指令、判斷語言／生態與既有 base image／建置流程；(B) 在**保留建置行為**前提下，把指令重整／歸位為**六步流程**（參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口）：可調參數集中於檔首 `ARG`、相依描述先 `COPY` 以利 layer 快取、**多階段建置**讓 runtime 改用較小基底（`*-slim`／`*-alpine`／`distroless` 等）只帶執行所需產物；`ENTRYPOINT`／`CMD`／`EXPOSE`／`ENV` 等對外契約不動，**無法保證等價的重整先以 AskUserQuestion 確認**（可選最小重排或只補註解）；(C) 對整個專案**完整執行 `/jsc-doc:funcs`**（`Dockerfile` 等指令檔逐行註解、function 文件、重建 README）。

- **Claude Code / Antigravity**：`/jsc:hello`
- **Codex**：`$hello`，或用 `/skills` 選單
- **OpenCode**：描述需求（如「hello、測試 plugin 有沒有裝好」）自動觸發
+參數：`[--project-dir <專案根目錄>] [--dockerfile <Dockerfile 路徑>] [--yes]`（專案根目錄預設目前工作目錄；Dockerfile 自動定位、多個時詢問；`--yes` 略過一般確認，但「重整無法保證行為等價」與 funcs 的實作詢問仍會中斷）。
+
+- **Claude Code / Antigravity**：`/jsc-code:image`，或 `/jsc-code:image --project-dir ~/work/my-app --dockerfile build/Dockerfile`
+- **Codex**：`$image`，或 `$image --dockerfile docker/Dockerfile`，或用 `/skills` 選單
+- **OpenCode**：描述需求（如「把這個專案的 Dockerfile 整理成參數處理→安裝套件→複製檔案→執行程序→縮小映像檔→設定入口六步、用多階段建置縮小映像，最後跑 funcs 補文件並重建 README」）自動觸發
+
+### `target`
+
+把**專案根目錄的 `TARGET.md`** 當每日待辦清單，並用**系統排程**（Linux／WSL／macOS 用 `crontab`、Windows 用 `schtasks`）在**每天 00:00** 自動跑完它。三種用法：**`--schedule on`** 建立或更新排程（同一專案只留一筆，以 `# jsc-code:target <專案路徑>` 標記比對，**絕不覆寫整份 crontab 或刪掉其他人的排程**；安裝後會檢查排程服務是否真的在跑，**WSL 預設不啟動 cron 會明確提醒**；log 刻意寫到 `~/.jsc/` 而非專案內，避免污染變更盤點）、**`--schedule off`** 只移除自己那一筆、**`--run`** 立即（或由排程）執行一次。`--run` 走六階段：**(A Git 同步)** 工作區有未提交變更就停止（不 stash／不 reset），`fetch` 後切到 `develop`，**遠端沒有 `develop` 就從遠端預設分支建立一條**；**(B 盤點)** 讀 `TARGET.md` 的 `- [ ]` 未勾選項目（含子項目從屬關係）依檔案順序排定，檔案不存在或全部完成則正常結束；**(C 逐項實作)** 一次做一項、做完就地把該行改成 `- [x]` 並補上 `（yyyy/MM/dd HH:mm:ss 完成）`，語意不明或驗證失敗者**不硬做**、保持未勾選並補 `> ⏭️ 待人工處理：<原因>`；**(D 分類提交)** 依 conventional commit 類型分組，每型一個 commit、範圍寫實際模組名；**(E push)** 推 `develop`（認證管理器 → token → 失敗停止）；**(F 發 PR)** 透過 Gitea API 對**遠端預設分支**開 PR，**已有相同 `develop` → 預設分支的 open PR 就沿用不重開**（每天執行不會灌一堆 PR）。不帶參數時只回報現況（排程裝了沒、下次執行時間、剩幾項未完成）。排程是非互動環境，建立前會提醒**先在該專案預先授權**助理所需工具，但不代為加上略過權限的旗標。
+
+參數：`[--schedule on|off] [--run] [--project-dir <專案根目錄>] [--cli <claude|codex|agy|opencode|copilot>] [--base <PR 目標分支>] [--no-pr] [--yes]`（專案根目錄預設目前工作目錄；`--cli` 預設為目前執行的助理，判斷不出來才問；`--base` 省略時自動取遠端預設分支；執行時間固定每天 00:00）。
+
+- **Claude Code / Antigravity**：`/jsc-code:target --schedule on`、`/jsc-code:target --schedule off`、`/jsc-code:target --run --yes`、`/jsc-code:target --schedule on --run --project-dir ~/work/app`
+- **Codex**：`$target --schedule on`，或 `$target --run --yes`，或用 `/skills` 選單
+- **OpenCode**：描述需求（如「幫我把這個專案的 TARGET.md 排成每天 00:00 自動執行，做完分類提交、push develop 並對預設分支發 PR」）自動觸發

 <!-- JSC-SKILLS:END -->

@@ -277,15 +290,16 @@ rm -rf ~/.config/opencode/skills/{code-review,code-review-archive,code-review-re

 ## 新增一個 skill

-1. 複製既有 skill 作範本：`cp -r skills/code-review skills/<your-skill-name>`
+1. 複製既有 skill 作範本：`cp -r skills/issues skills/<your-skill-name>`
 2. 編輯 `skills/<your-skill-name>/SKILL.md` 的 frontmatter：
-   - `name`：小寫、數字、連字號（`-`），最長 64 字元。**這就是 Claude Code / Antigravity 的 `/jsc:<name>`**。
+   - `name`：小寫、數字、連字號（`-`），最長 64 字元。**這就是 Claude Code / Antigravity 的 `/jsc-code:<name>`**。
   - `description`：第三人稱，寫清楚「何時用、何時不用」與觸發關鍵字 — 這是各助理自動載入的唯一依據。
 3. 在內文寫下 skill 的具體步驟。
 4. 手動把這個 skill 補進上方「Skills 目錄」區塊。
-5. **bump 版本並 push**：四家都以 git 內容/版本判斷更新，請把 `.claude-plugin/plugin.json`、`.codex-plugin/plugin.json`、`plugin.json` 三個 manifest 的 `version` 一起 bump，commit 後 push 到 gitea。
+5. **bump 版本並 push**：各助理都以 git 內容/版本判斷更新，請把 `.claude-plugin/plugin.json`、`.codex-plugin/plugin.json`、`plugin.json` 三個 manifest 的 `version` 一起 bump，commit 後 push 到 gitea。
 6. 讓各助理更新：
-   - Claude：`claude plugin update jsc@code`
+   - Claude：`claude plugin update jsc-code@code`
   - Codex：`codex plugin marketplace upgrade code`
-   - Antigravity：`git -C ~/jsc-plugin pull && agy plugin uninstall jsc && agy plugin install ~/jsc-plugin`
+   - Antigravity：`git -C ~/plugins/code pull && agy plugin uninstall jsc-code && agy plugin install ~/plugins/code`
   - OpenCode：`git pull` 後重新複製 `skills/`
+   - Copilot：`copilot plugin marketplace update code && copilot plugin update jsc-code@code`
@@ -1,6 +1,6 @@
 {
-  "name": "jsc",
-  "version": "0.0.4",
-  "description": "JSC 程式碼工作流 plugin，提供 RPG 攻防式 git diff review、裁決結果歸檔、Gitea AI review findings 修復/PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步，以及 action / Dockerfile 標準化流程；於 Antigravity 以 /jsc: 前綴呼叫。",
+  "name": "jsc-code",
+  "version": "0.0.3",
+  "description": "JSC 程式碼工作流 plugin，提供 Gitea AI review findings 修復/PR 流程、Gitea 議題 TODO 彙整與逐項實作、C# / .NET NuGet 套件更新、Gitea 專案批次同步，以及 action / Dockerfile 標準化流程；於 Antigravity 以 /jsc-code: 前綴呼叫。",
  "skills": "./skills/"
 }
@@ -0,0 +1,205 @@
+---
+name: action-composite
+description: 將 Gitea／GitHub「composite action」專案標準化（目錄沒有 action manifest 時可問答式從零建立）並串接文件化流程：(1) 確認 action 為 composite（`runs.using: composite`），非 composite 則保守確認後對齊；(2) 在 `runs.steps` 最前面注入啟動橫幅 step，輸出 action 名稱／用途／更新時間（Asia/Taipei `yyyy/MM/dd HH:mm:ss`），並於 `action.yml` 開頭補用途／更新時間註解區塊；(3) 開發中需要新參數時優先取用 `${{ gitea.* }}`／`${{ github.* }}` context，無法取得才詢問使用者是否新增 `inputs`（`secrets`／`vars` context 在 composite action 內一律視為不可用，需要時宣告為 `inputs` 由呼叫端 workflow 傳入）；(4) 最後完整執行 `/jsc-doc:funcs` 處理流程（function 文件、指令檔逐行註解、重建 README）。當使用者說整理 composite action、從零建立／產生一個 composite action、把 action 標準化為 composite、讓 composite action 啟動時印名稱／用途／更新時間、處理 composite action 參數來源、對 composite action 補文件，或提到 action-composite 時觸發。不適用於：Docker 容器 action（用 action-docker）、或不需 action 化／文件化的一般 repo。
+argument-hint: "[--action-dir <action 根目錄>] [--manifest <action.yml 路徑>]"
+---
+
+# action-composite — composite action 標準化＋文件化
+
+四階段 skill：先做**前置設定與偵測**（找出 action 專案、讀取名稱／用途、判斷是否為 composite），再**確認／對齊為 composite action**，接著在 `runs.steps` 最前面**注入會輸出 action 名稱／用途／更新時間的啟動橫幅 step**，最後**完整執行 `/jsc-doc:funcs` 處理流程**替整個專案補文件並重建 README。各階段開發中需要新參數時，一律套用下方「**參數來源優先序**」規則。目錄沒有 action manifest 時，先走 A1a 問答式「**從零建立**」分支產生 composite `action.yml`，再進入後續階段。
+
+| 階段 | 動作 |
+| --- | --- |
+| A. 前置設定與偵測 | 決定 action 根目錄 → 讀 `action.yml`／`action.yaml` 的 `name`／`description`／`runs` → 判斷是否為 composite（無 manifest 可走 A1a 從零建立） |
+| B. 對齊為 composite | 已是 composite 則保留既有 `steps`；非 composite 則**保守確認後對齊**（高風險，先確認），整理被引用的腳本路徑 |
+| C. 注入啟動橫幅 step | 在 `runs.steps` 最前面插入一個 shell step，輸出 action **名稱／用途／更新時間**；並於 `action.yml` 開頭補用途／更新時間註解區塊 |
+| D. 串接 funcs | 對整個 action 專案完整執行 `/jsc-doc:funcs` 流程（function 文件、指令檔逐行註解、重建 README） |
+
+---
+
+## 共用規範（shared plugin，必要前置）
+
+執行本 skill 前，先以 Skill 工具載入下列共用規範並全程遵守；**任一載入不到（shared plugin 未安裝）時，先詢問使用者是否安裝 shared plugin（`https://gitea.jsc.idv.tw/plugins/shared.git`），使用者不安裝則直接中斷本 skill**，不得只憑下方一行摘要繼續執行：
+
+- `/jsc-shared:spec-output`：繁體中文（台灣用語）、UTF-8（不含 BOM）無亂碼。
+- `/jsc-shared:spec-execution`：自動執行原則（必要決策才中斷）、不臆測／需人工確認、不擴及無關檔案。
+- `/jsc-shared:spec-git-safety`：不破壞既有工作（絕不 `reset --hard`／`clean`）、`git mv` 保留歷史。
+- `/jsc-shared:spec-action-params`：action 參數來源優先序（context → 經同意新增 `inputs`）、`secrets`／`vars` 一律視為不可用。
+- `/jsc-shared:spec-time-log`：更新時間 Asia/Taipei `yyyy/MM/dd HH:mm:ss`、完成後統一同步時間戳。
+- `/jsc-shared:spec-doc-funcs-handoff`：最終階段完整執行 `/jsc-doc:funcs` 的標準流程。
+
+本 skill 特有補充：
+
+- **一定會中斷詢問的點**：階段 B 主 action「非 composite 需對齊」時（破壞性，須先確認），以及階段 D 由 `/jsc-doc:funcs` 自身的「如何實作」詢問。
+- **保留行為**：對齊 composite 與注入橫幅 step 只「補強」既有流程，不得擅自改變既有 `steps` 的執行順序、輸入（`inputs`）／輸出（`outputs`）契約或副作用；任何無法可靠等價推論的改動一律不做，並以註解或回報標註「需人工確認」。新增 `input` 僅限依 `/jsc-shared:spec-action-params` 經使用者同意後為之。
+- **本 skill 只動**：action 專案根目錄內的 `action.yml`／`action.yaml`、其 `steps` 直接引用的內嵌腳本（如 `*.sh`／`*.ps1`），以及階段 D 由 funcs 流程處理的目標。
+
+---
+
+## 參數來源優先序（開發中需要新參數時）
+
+從零建立（A1a）、對齊 composite（階段 B）、注入橫幅 step（階段 C）或補強被引用腳本的過程中，若需要新的參數值，一律依 `/jsc-shared:spec-action-params` 的優先序處理：composite 的 `runs.steps` 內優先取 `${{ gitea.* }}`／`${{ github.* }}` context（建議寫 `github.*` 以相容兩邊；`run` 腳本內可改讀 `$GITHUB_*` 環境變數），取不到才以 `AskUserQuestion` 經使用者同意新增 `inputs`；`secrets`／`vars` 一律視為不可用，需要時宣告為 `input` 由呼叫端 workflow 傳入（範例見該 spec）。
+
+---
+
+## 參數
+
+格式：`[--action-dir <action 根目錄>] [--manifest <action.yml 路徑>]`
+
+- `--action-dir <action 根目錄>`：action 專案根目錄。**省略時預設目前工作目錄**（須含 `action.yml`／`action.yaml`，否則依 A1 詢問）。
+- `--manifest <action.yml 路徑>`：指定 action manifest 檔（相對 action 根目錄）。省略時依 A1 自動尋找 `action.yml`／`action.yaml`。
+
+---
+
+## 階段 A：前置設定與偵測
+
+### A1. 決定 action 根目錄與 manifest
+
+- 帶 `--action-dir` → 採用（展開 `~`）；省略 → 用目前工作目錄。
+- manifest：帶 `--manifest` → 採用；否則於根目錄找 `action.yml`，再退而 `action.yaml`。
+- **找不到** action manifest → **不臆測**、不逕自動工；以 `AskUserQuestion` 詢問使用者要「**從零建立**新的 composite action」還是「提供正確的 action 路徑」：選「從零建立」→ 進入 A1a；選「提供路徑」→ 依新路徑重跑 A1。
+
+### A1a. 從零建立 composite action（問答式）
+
+依序以問答收集需求，再產生 manifest：
+
+1. **action 名稱**：用於 `action.yml` 的 `name`。
+2. **輸入與輸出參數**：逐一收集 `inputs`／`outputs` 的名稱與 `description`（description 盡量繁體中文、無亂碼）、`required`／`default`；沒有可留空。
+3. **執行目標**：詢問此 action 要達成什麼，整理濃縮成一句話作為 `action.yml` 的 `description`（盡量繁體中文、無亂碼）。
+
+收集完成後，於 action 根目錄產生 `action.yml`（`runs.using: composite`，含收集到的 `name`／`description`／`inputs`／`outputs`），並依執行目標以 composite steps 實作（開發中需要新參數時套用「參數來源優先序」）；完成後接續 A2 往後流程（A3 必為 composite，階段 B 走「已是 composite」分支）。
+
+### A2. 讀取 action 名稱與用途
+
+從 action manifest 讀取：
+
+- `name`：action 名稱（供啟動橫幅與 README 使用）。
+- `description`：action 用途。
+- `runs`：目前的執行設定（`using`、`steps`、`main`、`image`、`entrypoint` 等）。
+- `inputs`／`outputs`：對外契約（後續不得破壞）。
+
+若 `name`／`description` 缺漏，回報缺漏並**詢問一次**；使用者跳過或無法提供時，於後續輸出以「（未提供）」標示續行，**不編造**。
+
+### A3. 判斷是否為 composite
+
+依 `runs.using` 判定：
+
+- `composite` → 即為目標型態，記下既有 `runs.steps`，直接進入階段 B 的「已是 composite」分支。
+- `node*`（JS action）／`docker`（Docker 容器 action）／其他 → 視為**非 composite**。
+
+輸出偵測結果（action 名稱、用途、`runs.using`、是否為 composite、既有 step 數量），再進入階段 B。
+
+> 若偵測為 **Docker 容器 action**，此處**僅輸出偵測結果**並提醒可改用 `/jsc-code:action-docker`，**不詢問**；是否對齊／維持原樣／改用 action-docker 的決策，統一由階段 B2 的一次 `AskUserQuestion` 收斂。
+
+---
+
+## 階段 B：確認／對齊為 composite action
+
+### B1. 已是 composite
+
+- 確認 `runs.using: composite` 與既有 `runs.steps`，**不更動既有 steps 的順序與邏輯**，直接進入階段 C。
+- 順手檢查 step 的必要欄位：`run` step 缺 `shell` 屬**原檔錯誤**（GitHub／Gitea 都會拒跑），**允許補上 `shell: bash`** 並在回報中列出；其他疑慮（如 `uses` step 的引用是否存在）以回報標註、不擅改。
+
+### B2. 非 composite（需對齊）
+
+這是**破壞性高風險決策**：先以 `AskUserQuestion` 向使用者確認，選項至少含「對齊為 composite」「維持原樣只做文件化（略過對齊）」「改用 action-docker」「其他」。經確認「對齊為 composite」後才改寫：
+
+- 將 `runs` 保守對齊為 composite，把原執行入口轉為 composite step：
+  - 原 JS action（`runs.using: node*`，`runs.main: <x>.js`）→ 轉為一個 `run` step，於 step 內以 `node <x>.js` 執行（`shell: bash`）。composite step **不會自動注入 `INPUT_*` 環境變數、也不會自動轉接 outputs**，必須手動補齊兩段映射（見下方範例）：
+    - **inputs 映射**：step 加 `env:`，逐一宣告 `INPUT_<大寫名稱>: ${{ inputs.<name> }}`——主程式的 `getInput()`／`process.env.INPUT_*` 才拿得到值。
+    - **outputs 轉接**：step 設 `id`，action 層 `outputs` 逐一宣告 `value: ${{ steps.<id>.outputs.<name> }}`（主程式寫入 `$GITHUB_OUTPUT` 的值由此轉出）。
+    - **硬條件**：無法完成上述兩項映射（inputs／outputs 無法逐一對應）時**不對齊**，以 `# 需人工確認` 標註並回報。
+  - 原 Docker action（`runs.using: docker`）→ Docker 行為通常無法可靠等價地塞進 composite；**不臆測改寫**，以回報＋`# 需人工確認` 標註，並建議改用 `/jsc-code:action-docker`。
+- 任何無法可靠等價對齊處，**不臆測**：以 `# 需人工確認：...` 標註並回報，保留原檔行為。
+- 對齊過程需要新的參數值（如 token、repo 資訊、外部設定）時，依「參數來源優先序」處理，不逕自新增 `inputs`。
+
+對齊後（含 inputs 映射與 outputs 轉接）形如：
+
+```yaml
+inputs:
+  foo:
+    description: <沿用原 input 宣告>
+outputs:
+  bar:
+    description: <沿用原 output 宣告>
+    value: ${{ steps.main.outputs.bar }}   # outputs 轉接：由 step outputs 轉出
+
+runs:
+  using: composite
+  steps:
+    # （階段 C 會在此處最前面插入啟動橫幅 step）
+    - name: <原執行入口轉成的 step>
+      id: main
+      shell: bash
+      env:
+        INPUT_FOO: ${{ inputs.foo }}       # inputs 映射：composite 不會自動注入 INPUT_*
+      run: node ./index.js
+```
+
+---
+
+## 階段 C：注入啟動橫幅 step（輸出名稱／用途／更新時間）
+
+在 `runs.steps` **最前面**插入（或更新）一個輸出橫幅的 step，讓 composite action 一啟動就**輸出 action 名稱、用途、更新時間**；並於 `action.yml` 開頭補用途／更新時間註解區塊。
+
+- **更新時間**依 `/jsc-shared:spec-time-log`（Asia/Taipei、固定 `yyyy/MM/dd HH:mm:ss`、寫成檔內固定字串）。本階段先寫入暫定時間戳，**階段 D 完成後會統一同步各處時間戳**（見階段 D）。
+- 名稱／用途取自階段 A2 的 `action.yml`（缺漏時以「（未提供）」標示）。
+- 橫幅 step 須有可辨識的 `name`（如 `顯示 action 資訊`）與 `shell: bash`；其後緊接既有／對齊後的 steps，**不更動既有 steps**。
+- 若已存在本 skill 先前插入的橫幅 step（依 `name` 辨識），則**更新**其內容與更新時間，不重複插入。
+
+範例（既有 steps 接在橫幅 step 之後）：
+
+```yaml
+name: <action name>
+description: <action description>
+
+runs:
+  using: composite
+  steps:
+    # 啟動橫幅：輸出名稱／用途／更新時間（此 step 由 action-composite 產生）
+    - name: 顯示 action 資訊
+      shell: bash
+      run: |
+        echo "================================================"
+        echo "Action  : <action name>"
+        echo "用途    : <action description>"
+        echo "更新時間: 2026/06/30 18:30:05"
+        echo "================================================"
+    # === 以下為既有／對齊後的 steps（保持原順序與邏輯）===
+    - name: <既有 step>
+      shell: bash
+      run: node ./index.js
+```
+
+- `action.yml` 開頭的「用途／更新時間」註解區塊與每行註解，最終會在階段 D 由 `/jsc-doc:funcs` 的指令檔流程統一補齊／覆寫為標準格式（用途與更新日期同一註解區塊、逐行註解）；本階段先確保**執行期橫幅輸出**正確即可。
+- 自我檢查：插入橫幅 step 後 YAML 仍可解析（縮排、`steps` 為 list、每個 `run` step 都有 `shell`），且 `inputs`／`outputs` 未被更動。
+
+---
+
+## 階段 D：完整執行 /jsc-doc:funcs 處理流程
+
+標準化完成後，以階段 A1 的 action 根目錄為目標，依 `/jsc-shared:spec-doc-funcs-handoff` 對**整個 action 專案**完整執行 `/jsc-doc:funcs` 流程（前置可用性檢查、完整流程、由使用者裁示實作方式、重建 README）。完成後依該 spec **統一時間戳**：回頭同步橫幅 step 內文、`action.yml` 開頭註解區塊與 README 的更新時間，確保各處一致。
+
+---
+
+## 總結
+
+各階段執行後輸出：
+
+- **階段 A**：action 根目錄、manifest 路徑、action 名稱／用途、`runs.using`、是否為 composite、既有 step 數量；若走 A1a 從零建立，列出問答收集結果（名稱／輸入輸出／目標）。
+- **階段 B**：是否對齊為 composite（及對齊摘要與「需人工確認」清單），或維持原樣的理由；依「參數來源優先序」新增的 `inputs` 清單與呼叫端傳入寫法（若有）。
+- **階段 C**：橫幅 step 的輸出內容（名稱／用途／更新時間）與插入位置，並確認既有 steps、`inputs`／`outputs` 未被破壞。
+- **階段 D**：funcs 流程的處理結果（文件化的 function 與指令檔、重建的 README）。
+- 列出本次新增／變更的檔案與其相對路徑，並提醒使用者於提交前確認 `action.yml` 可正常解析、composite action 能正確啟動並輸出橫幅。
+
+---
+
+## 呼叫方式
+
+格式：`[--action-dir <action 根目錄>] [--manifest <action.yml 路徑>]` — 全部可省略（根目錄預設目前工作目錄；manifest 自動尋找）。
+
+| 助理 | 呼叫 |
+| --- | --- |
+| Claude Code / Antigravity | `/jsc-code:action-composite`，或 `/jsc-code:action-composite --action-dir ~/work/my-action` |
+| Codex | `$action-composite`，或 `$action-composite --action-dir ~/work/my-action`，或用 `/skills` 選單 |
+| OpenCode | 描述需求（如「把這個 composite action 標準化，在 steps 最前面加一個會輸出 action 名稱／用途／更新時間的 step，最後跑 funcs 補文件並重建 README」）自動觸發 |
@@ -0,0 +1,266 @@
+---
+name: action-docker
+description: 將 Gitea／GitHub「Docker 容器 action」專案標準化為 Node 主程式＋容器化（目錄沒有 action manifest 時可問答式從零建立），並串接文件化流程：(1) 檢查 action 主程式是否為 Node，否則保守改寫為 Node，且主程式及其依賴鏈的 `.js` 檔集中到 `src/` 資料夾（工具設定檔與測試目錄不搬）；(2) 產生 `entrypoint.sh`，啟動前先輸出 action 名稱／用途／更新時間，再執行 node 主程式；(3) 產生使用最新 LTS node 版本的 `Dockerfile`；(4) 開發中需要新參數時優先取用 runner 注入的 `GITHUB_*`（Gitea 亦有 `GITEA_*`）執行期環境變數（即 `gitea.*`／`github.*` context 的同源資訊），無法取得才詢問使用者是否新增 `inputs`（`secrets`／`vars` context 在 docker action 內一律視為不可用，需要時宣告為 `inputs` 由呼叫端 workflow 傳入）；(5) 最後完整執行 `/jsc-doc:funcs` 處理流程（function 文件、指令檔逐行註解、重建 README）。當使用者說把 action 改成 docker／node、從零建立／產生一個 docker action、容器化 action、action 主程式 node 化、把 js 收進 src、產 entrypoint.sh／Dockerfile 給 action、處理 docker action 參數來源，或提到 action-docker 時觸發。不適用於：composite action（用 action-composite）、純前端打包、或不需容器化的一般 repo。
+argument-hint: "[--action-dir <action 根目錄>] [--node-version <node tag>] [--main <主程式檔>]"
+---
+
+# action-docker — action 容器化（Node 主程式）＋文件化
+
+五階段 skill：先做**前置設定與偵測**（找出 action 專案、讀取名稱／用途、判斷主程式語言），再把**主程式 Node 化並將主程式依賴鏈的 `.js` 收進 `src/`**，接著產生**啟動前先輸出 action 名稱／用途／更新時間的 `entrypoint.sh`**，然後產生**使用最新 LTS node 版本的 `Dockerfile`**（並對齊 `action.yml` 的 docker 設定），最後**完整執行 `/jsc-doc:funcs` 處理流程**替整個專案補文件並重建 README。產出的 docker action 需在**具 Docker 能力的 runner（docker 模式）**上執行。各階段開發中需要新參數時，一律套用下方「**參數來源優先序**」規則。目錄沒有 action manifest 時，先走 A1a 問答式「**從零建立**」分支產生 `action.yml` 與 Node 主程式骨架，再進入後續階段。
+
+| 階段 | 動作 |
+| --- | --- |
+| A. 前置設定與偵測 | 決定 action 根目錄 → 讀 `action.yml`／`action.yaml` 的 `name`／`description` → 判斷目前主程式與語言（無 manifest 可走 A1a 從零建立） |
+| B. 主程式 Node 化 | 主程式非 Node 則**保守改寫**為 Node（高風險，先確認）→ 主程式依賴鏈的 `.js` 集中到 `src/`，更新所有引用、`package.json`、`action.yml` |
+| C. entrypoint.sh | 產生 `entrypoint.sh`：先輸出 action **名稱／用途／更新時間**，再 `exec` node 主程式 |
+| D. Dockerfile | 依六步流程（參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口）產生使用**最新 LTS node 版本**的 `Dockerfile`，多階段建置縮小映像、`ENTRYPOINT` 指向 `entrypoint.sh` |
+| E. 串接 funcs | 對整個 action 專案完整執行 `/jsc-doc:funcs` 流程（function 文件、指令檔逐行註解、重建 README） |
+
+---
+
+## 共用規範（shared plugin，必要前置）
+
+執行本 skill 前，先以 Skill 工具載入下列共用規範並全程遵守；**任一載入不到（shared plugin 未安裝）時，先詢問使用者是否安裝 shared plugin（`https://gitea.jsc.idv.tw/plugins/shared.git`），使用者不安裝則直接中斷本 skill**，不得只憑下方一行摘要繼續執行：
+
+- `/jsc-shared:spec-output`：繁體中文（台灣用語）、UTF-8（不含 BOM）無亂碼。
+- `/jsc-shared:spec-execution`：自動執行原則（必要決策才中斷）、不臆測／需人工確認、不擴及無關檔案。
+- `/jsc-shared:spec-git-safety`：不破壞既有工作（絕不 `reset --hard`／`clean`）、`git mv` 保留歷史。
+- `/jsc-shared:spec-action-params`：action 參數來源優先序（環境變數 → 經同意新增 `inputs`）、`secrets`／`vars` 一律視為不可用。
+- `/jsc-shared:spec-time-log`：更新時間 Asia/Taipei `yyyy/MM/dd HH:mm:ss`、完成後統一同步時間戳。
+- `/jsc-shared:spec-dockerfile`：Dockerfile 六步流程、多階段建置、固定版號、自我檢查。
+- `/jsc-shared:spec-doc-funcs-handoff`：最終階段完整執行 `/jsc-doc:funcs` 的標準流程。
+
+本 skill 特有補充：
+
+- **一定會中斷詢問的點**：階段 B 主程式「非 Node 需改寫」時（破壞性，須先確認），以及階段 E 由 `/jsc-doc:funcs` 自身的「如何實作」詢問。
+- **保留行為**：Node 化只「翻譯」既有邏輯，不得擅自改變對外行為、輸入輸出契約或副作用；任何無法可靠等價推論的改動一律不做，並以註解或回報標註「需人工確認」。新增 `input` 僅限依 `/jsc-shared:spec-action-params` 經使用者同意後為之。
+- **本 skill 只動**：action 專案根目錄內的主程式、主程式依賴鏈的 `.js`（搬移到 `src/`）、`package.json`、`action.yml`／`action.yaml`、`entrypoint.sh`、`Dockerfile`、`.dockerignore`，以及階段 E 由 funcs 流程處理的目標。
+
+---
+
+## 參數來源優先序（開發中需要新參數時）
+
+從零建立（A1a）、主程式 Node 化（階段 B）、產生 `entrypoint.sh`（階段 C）或產生 `Dockerfile`（階段 D）的過程中，若需要新的參數值，一律依 `/jsc-shared:spec-action-params` 的優先序處理：Docker 容器 action 優先取 runner 注入的執行期環境變數（Node 主程式讀 `process.env.GITHUB_*`、`entrypoint.sh` 讀 `$GITHUB_*`；Gitea 亦提供 `GITEA_*` 同義變數，建議讀 `GITHUB_*` 以相容兩邊），取不到才以 `AskUserQuestion` 經使用者同意新增 `inputs`（容器內以 `INPUT_<大寫名稱>` 取用）；`secrets`／`vars` 一律視為不可用，需要時宣告為 `input` 由呼叫端 workflow 傳入（範例見該 spec）。
+
+---
+
+## 參數
+
+格式：`[--action-dir <action 根目錄>] [--node-version <node tag>] [--main <主程式檔>]`
+
+- `--action-dir <action 根目錄>`：action 專案根目錄。**省略時預設目前工作目錄**（須含 `action.yml`／`action.yaml`，否則依 A1 詢問）。
+- `--node-version <node tag>`：`Dockerfile` 的 node base image tag（如 `22`、`22-alpine`、`lts`）。**省略時預設使用當前最新 LTS major**（如 `node:22`，見階段 D）。tag 已是 `-alpine`／`-slim` 變體時，build 與 runtime **直接沿用同一 tag**、不再另組 `-slim`。
+- `--main <主程式檔>`：指定主程式入口檔（相對 action 根目錄）。省略時依 A3 自動判斷。
+
+---
+
+## 階段 A：前置設定與偵測
+
+### A1. 決定 action 根目錄
+
+- 帶 `--action-dir` → 採用（展開 `~`）。
+- 省略 → 用目前工作目錄。
+- 根目錄須存在 `action.yml` 或 `action.yaml`（action manifest）。**找不到** action manifest → **不臆測**、不逕自動工；以 `AskUserQuestion` 詢問使用者要「**從零建立**新的 Docker 容器 action」還是「提供正確的 action 路徑」：選「從零建立」→ 進入 A1a；選「提供路徑」→ 依新路徑重跑 A1。
+
+### A1a. 從零建立 Docker 容器 action（問答式）
+
+依序以問答收集需求，再產生 manifest 與主程式骨架：
+
+1. **action 名稱**：用於 `action.yml` 的 `name`。
+2. **輸入與輸出參數**：逐一收集 `inputs`／`outputs` 的名稱與 `description`（description 盡量繁體中文、無亂碼）、`required`／`default`；沒有可留空。
+3. **執行目標**：詢問此 action 要達成什麼，整理濃縮成一句話作為 `action.yml` 的 `description`（盡量繁體中文、無亂碼）。
+
+收集完成後，於 action 根目錄產生：`action.yml`（`runs.using: docker`、`image: Dockerfile`，含收集到的 `name`／`description`／`inputs`／`outputs`）與 `src/index.js` 主程式（依執行目標以 Node 實作，輸入以 `process.env.INPUT_<NAME>` 讀取，開發中需要新參數時套用「參數來源優先序」）；完成後接續 A2 往後流程（A3 判定為 Node，階段 B 走「已是 Node」分支，階段 C／D 照常產生 `entrypoint.sh` 與 `Dockerfile`）。
+
+### A2. 讀取 action 名稱與用途
+
+從 action manifest 讀取：
+
+- `name`：action 名稱（供 `entrypoint.sh` 輸出與 README 使用）。
+- `description`：action 用途。
+- `runs`：目前的執行設定（`using`、`main`、`image`、`entrypoint` 等）。
+
+若 `name`／`description` 缺漏，回報並請使用者補；無法取得時於後續輸出以「（未提供）」保守標示，**不編造**。
+
+### A3. 判斷目前主程式與語言
+
+依序判斷主程式入口（取第一個成立者）：
+
+1. 帶 `--main <主程式檔>` → 直接採用。
+2. `action.yml` 為 JS action（`runs.using: node*`）→ 取 `runs.main`。
+3. `action.yml` 為 docker action（`runs.using: docker`）→ 看 `runs.entrypoint`／`Dockerfile` 的 `ENTRYPOINT`／`CMD` 推主程式。
+4. 以上皆無 → 依專案檔與副檔名分布推斷（`package.json` 的 `main`／`bin`、`index.js`、`*.sh`、`*.py` 等）。
+
+判定**主程式是否為 Node**：入口為 `.js`／`.mjs`／`.cjs` 且由 `node` 執行即視為 Node；入口為 shell／python／其他則視為非 Node。輸出偵測結果（action 名稱、用途、主程式檔、判定語言、是否為 Node），再進入階段 B。
+
+---
+
+## 階段 B：主程式 Node 化，並將主程式依賴鏈的 `.js` 收進 `src/`
+
+### B1. 主程式 Node 化
+
+- **已是 Node** → 確認入口檔，不改寫邏輯，直接進 B2。
+- **非 Node（shell／python／其他）** → 這是**破壞性高風險決策**：先以 `AskUserQuestion` 向使用者確認是否改寫為 Node，選項至少含「改寫為 Node」「維持原樣只做容器化（略過改寫）」「其他」。經確認後才改寫：
+  - 逐段把原主程式邏輯**保守翻譯**為 Node（建議 `index.js`）；保留對外行為、輸入（環境變數／`INPUT_*`／args）與輸出（stdout／exit code／檔案副作用）契約。
+  - 外部指令呼叫以 `child_process`（`execFileSync`／`spawnSync`）對應；檔案操作以 `fs`；環境變數以 `process.env`。
+  - 任何無法可靠等價翻譯處，**不臆測**：以 `// 需人工確認：...` 標註並回報。
+  - 改寫完成後，原非 Node 主程式於 B2 一併處理（移除或保留由使用者裁示；預設保留並在 README／回報標註已由 Node 取代）。
+
+### B2. 主程式依賴鏈的 `.js` 集中到 `src/`
+
+- 在 action 根目錄建立 `src/`（若不存在）。
+- 將**主程式入口及其 `require`／`import` 依賴鏈**的 `.js`／`.mjs`／`.cjs`（排除 `node_modules`／`.git`／`.docs`／`bin`／`obj`／第三方依賴）**移入 `src/`**，優先 `git mv` 保留歷史。主程式入口統一為 `src/index.js`（或 `src/<main>.js`）。
+- **明文排除、不搬**：外部工具依慣例路徑尋找的檔案——`*.config.js`（`eslint.config.js`／`jest.config.js`／`webpack.config.js` 等）、`.*rc.js`、husky／commitlint 等工具設定，以及 `test/`／`tests/`／`scripts/` 目錄；搬走會弄壞 lint／test／build 流程。
+- **移動後必須更新所有引用**，確保不破壞：
+  - 模組間的 `require`／`import` 相對路徑。
+  - `package.json` 的 `main`／`bin`／`scripts`／`exports`（指向 `src/...`）。
+  - `action.yml`／`Dockerfile`／`entrypoint.sh` 內對主程式路徑的引用。
+- 若 `src/` 下無 `package.json` 而專案需要相依，於 `src/` 建立或移入 `package.json`，`main` 指向入口檔；不擅自新增與功能無關的相依。
+
+### B3. action.yml 對齊 docker
+
+將 manifest 的 `runs` 對齊為 docker 容器 action（保留既有 `inputs`／`outputs`／`name`／`description`）：
+
+```yaml
+runs:
+  using: docker
+  image: Dockerfile
+```
+
+- **不設 `runs.entrypoint`**：執行入口由 `Dockerfile` 的 `ENTRYPOINT ["/action/entrypoint.sh"]`（絕對路徑）決定。`runs.entrypoint` 會**覆蓋** Dockerfile 的 `ENTRYPOINT`，且 runner 執行 docker action 時容器工作目錄是使用者 repo 的 workspace（不是 `/action`），相對路徑會找不到檔案。若原 manifest 已有 `entrypoint`，改為絕對路徑（`/action/entrypoint.sh`）或直接移除。
+- 若原本是 JS action（`using: node*`），改為上述 docker 設定；若已是 docker action，確認 `image` 指向 `Dockerfile`，並依上一點處理 `entrypoint`。
+- **docker 化代價揭示**（回報即可，不中斷詢問）：轉為 docker action 後**僅能在 Linux runner 執行**、每次 workflow 執行多一段 image build 時間、host 模式的 act_runner 無法執行（runner 需具 Docker 能力）。
+
+改寫主程式或對齊 `action.yml` 過程需要新的參數值（如 token、repo 資訊、外部設定）時，依「參數來源優先序」處理，不逕自新增 `inputs`。
+
+---
+
+## 階段 C：產生 entrypoint.sh（先輸出名稱／用途／更新時間，再啟動 node 主程式）
+
+在 action 根目錄產生（或覆寫）`entrypoint.sh`：**啟動 node 主程式前，先輸出 action 名稱、用途、更新時間**。
+
+- **更新時間**依 `/jsc-shared:spec-time-log`（Asia/Taipei、固定 `yyyy/MM/dd HH:mm:ss`、寫成檔內固定字串）。本階段先寫入暫定時間戳，**階段 E 完成後會統一同步各處時間戳**（見階段 E）。
+- 名稱／用途取自階段 A2 的 `action.yml`。
+- 最後以 `exec node <主程式>`（如 `exec node /action/src/index.js "$@"`）啟動，讓 node 取代 shell 行程，正確傳遞訊號與 exit code；路徑須與階段 D 的 `Dockerfile` 落點一致。
+- **若階段 B 裁示「維持非 Node」**：橫幅照常輸出，最後改以 `exec <原直譯器> <主程式>` 啟動（如 `exec python3 /action/src/main.py "$@"`、`exec sh /action/src/main.sh "$@"`）。
+
+範例（實際路徑依階段 B 入口而定）：
+
+```sh
+#!/bin/sh
+set -e
+
+# action 啟動橫幅：輸出名稱／用途／更新時間（此檔由 action-docker 產生）
+echo "================================================"
+echo "Action  : <action name>"
+echo "用途    : <action description>"
+echo "更新時間: 2026/06/30 18:30:05"
+echo "================================================"
+
+# 啟動 node 主程式（以 exec 取代 shell，正確處理訊號與 exit code）
+exec node /action/src/index.js "$@"
+```
+
+- 賦予可執行權限：`chmod +x entrypoint.sh`（並於 git 標記為可執行）。
+- 此檔開頭的「用途／更新時間」與每行註解，最終會在階段 E 由 `/jsc-doc:funcs` 的指令檔流程統一補齊／覆寫為標準格式（用途與更新日期同一註解區塊、逐行註解）；本階段先確保**執行期輸出**正確即可。
+
+---
+
+## 階段 D：產生 Dockerfile（使用最新 LTS node 版本，六步流程依主程式實作量身產生）
+
+在 action 根目錄產生（或覆寫）`Dockerfile`，**base image 使用最新 LTS node 版本（固定 major tag）**，採**多階段建置**以縮小最終映像檔。六步流程是**骨架**，但**每一步的實際內容必須依階段 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` 路徑。
+- **產生 `.dockerignore`**：於 action 根目錄產生（或補齊）`.dockerignore`，至少排除 `.git`、`.docs`、`node_modules`（宿主端，可能含平台不符的原生模組）與其他非執行必需檔案，避免帶進 build context。
+
+### D1～D6：依盤點結果填入六步
+
+1. **參數處理**：以 `ARG` 注入 node 版本（預設最新）與主程式需要的 build-time 參數；可調參數集中在檔案開頭。
+2. **安裝套件**：依 D0 的相依結果安裝——有 lockfile 用 `npm ci`、否則 `npm install`，**二擇一寫死於 Dockerfile**（不得以 `npm ci || npm install` 之類 fallback 串接，避免靜默吞錯、破壞 lockfile 的可重現性）；不需 build 時加 `--omit=dev`，需 build 時先裝完整相依（含 dev）供第 4 步使用。**只在主程式真的會用到時**才 `apt-get install` OS 套件，並於同一 `RUN` 清掉 apt 快取。先 `COPY` 相依描述（`package*.json`）再安裝，以利 layer 快取。
+3. **複製檔案**：`COPY` 主程式實際需要的檔案（`src/`、`entrypoint.sh`，及主程式會讀取的資源），**明列路徑、不整包 `COPY .`**，並配合 `.dockerignore` 排除非必要檔案。
+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 相依與快取帶進最終映像；**`COPY --from=build` 必須逐項明列路徑，不得整包 `COPY --from=build /action /action`**（整包搬等於沒有縮小）。
+6. **設定入口**：`ENTRYPOINT` 指向 `entrypoint.sh`，其內 `node` 路徑為 D0 的入口檔。
+
+base image 版本依 `/jsc-shared:spec-dockerfile`（固定 major tag、不用 `latest`）：**預設使用產生當下的最新 LTS major 固定 tag**（如 build 基底 `node:22`、runtime 基底 `node:22-slim`），可查詢 Docker Hub（`https://hub.docker.com/_/node`）確認當前 LTS 版號；帶 `--node-version <tag>` 時改用 `node:<tag>` 與 `node:<tag>-slim`。
+
+下列為**最簡基準骨架**（純 JS、無 build、無 OS 相依的情況）；實際內容須依 D0 盤點調整，第 4 步建置、第 2／5 步 OS 套件等視主程式需要增刪：
+
+```Dockerfile
+# 1. 參數處理：node 版本以 ARG 注入（預設當前最新 LTS major，範例為 22；--node-version 可覆寫）
+ARG NODE_VERSION=22
+ARG NODE_RUNTIME=22-slim
+
+# ---- build 階段：安裝相依、準備產物 ----
+FROM node:${NODE_VERSION} AS build
+WORKDIR /action
+
+# 2. 安裝套件：先帶相依描述以利 layer 快取，再裝 src/ 相依
+#    （依 D0 盤點二擇一寫死：有 lockfile 用 npm ci、否則 npm install，不用 || 串接；
+#      需 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; \
+    fi
+
+# 3. 複製檔案：明列主程式實際需要的檔案（配合 .dockerignore，不整包 COPY .）
+COPY src/ /action/src/
+COPY entrypoint.sh /action/entrypoint.sh
+
+# 4. 執行程序：賦予 entrypoint 執行權限（D0 判定需要 build 時於此 npm run build）
+RUN chmod +x /action/entrypoint.sh
+
+# 5. 縮小映像檔：多階段建置，runtime 改用 slim 基底，逐項明列只帶執行真正需要的產物
+#    （有 build 產物時改帶 dist/ 與 production node_modules；runtime 需要的 OS 執行檔於此安裝）
+FROM node:${NODE_RUNTIME} AS runtime
+WORKDIR /action
+COPY --from=build /action/src /action/src
+COPY --from=build /action/entrypoint.sh /action/entrypoint.sh
+
+# 6. 設定入口：以 entrypoint.sh 啟動（其內 node 指向 D0 的入口檔）
+ENTRYPOINT ["/action/entrypoint.sh"]
+```
+
+- **依主程式實作**：上面只是基準骨架。若主程式是 TypeScript／需打包，第 4 步要加 `npm run build`、第 5 步只帶 `dist/` 與 production 相依；若主程式會 spawn 外部執行檔或用原生模組，第 2／5 步要補對應 OS 套件；用不到的步驟內容不要硬塞。
+- **若階段 B 裁示「維持非 Node」**：base image 改用對應語言官方映像（如 `python:3-slim`），第 2 步改安裝該生態相依（如 `pip install -r requirements.txt`），其餘六步結構不變；`ENTRYPOINT` 仍指向 `entrypoint.sh`（其內 `exec` 原直譯器，見階段 C）。
+- **版號對齊**：依 `/jsc-shared:spec-dockerfile`（runtime 與 build 版號一致、以獨立 runtime ARG 帶入不用 `${VERSION}-slim` 組裝、`-alpine`／`-slim` 變體沿用同一 tag、使用者要求 `latest` 時 runtime 用 `node:slim`）。
+- **自我檢查**：`entrypoint.sh` 的 `node <主程式>` 路徑（如 `/action/src/index.js`）需與 `Dockerfile` 的 `WORKDIR`／`COPY` 落點一致，避免容器啟動時找不到主程式；`action.yml` 的 `runs.entrypoint` 若存在，必須是**絕對路徑**且與 `Dockerfile` 落點一致（預設不設，讓 Dockerfile 的 `ENTRYPOINT` 生效）。
+- 此檔的用途／更新日期註解與逐行註解，同樣於階段 E 由 funcs 指令檔流程統一補齊。
+
+---
+
+## 階段 E：完整執行 /jsc-doc:funcs 處理流程
+
+容器化與 Node 化完成後，以階段 A1 的 action 根目錄為目標，依 `/jsc-shared:spec-doc-funcs-handoff` 對**整個 action 專案**完整執行 `/jsc-doc:funcs` 流程（前置可用性檢查、完整流程、由使用者裁示實作方式、重建 README；本次新增／變更的 `entrypoint.sh`、`Dockerfile` 與 `src/` 內 Node 主程式都會被涵蓋）。完成後依該 spec **統一時間戳**：回頭同步 `entrypoint.sh` 橫幅輸出與註解區塊、`Dockerfile` 註解區塊與 README 的更新時間，確保各處一致。
+
+---
+
+## 總結
+
+各階段執行後輸出：
+
+- **階段 A**：action 根目錄、action 名稱／用途、原主程式檔與語言、是否為 Node；若走 A1a 從零建立，列出問答收集結果（名稱／輸入輸出／目標）。
+- **階段 B**：是否改寫主程式（及改寫摘要與「需人工確認」清單）、搬入 `src/` 的 `.js` 清單、已更新的引用（`package.json`／`action.yml`／路徑）；依「參數來源優先序」新增的 `inputs` 清單與呼叫端傳入寫法（若有）。
+- **階段 C／D**：`entrypoint.sh` 的輸出內容（名稱／用途／更新時間）與啟動的 node 主程式、`Dockerfile` 採用的 node 版本與 `ENTRYPOINT`。
+- **階段 E**：funcs 流程的處理結果（文件化的 function 與指令檔、重建的 README）。
+- 列出本次新增／變更的檔案與其相對路徑，並提醒使用者於提交前確認 `entrypoint.sh` 有可執行權限、容器能正確啟動。
+
+---
+
+## 呼叫方式
+
+格式：`[--action-dir <action 根目錄>] [--node-version <node tag>] [--main <主程式檔>]` — 全部可省略（根目錄預設目前工作目錄；node 版本預設最新 LTS；主程式自動判斷）。
+
+| 助理 | 呼叫 |
+| --- | --- |
+| Claude Code / Antigravity | `/jsc-code:action-docker`，或 `/jsc-code:action-docker --action-dir ~/work/my-action --node-version 22` |
+| Codex | `$action-docker`，或 `$action-docker --action-dir ~/work/my-action`，或用 `/skills` 選單 |
+| OpenCode | 描述需求（如「把這個 action 主程式改成 node、主程式相關 js 收進 src/，產生會先輸出 action 名稱／用途／更新時間再啟動 node 的 entrypoint.sh、用最新 LTS node 版本的 Dockerfile，最後跑 funcs 補文件並重建 README」）自動觸發 |
@@ -0,0 +1,251 @@
+---
+name: action-node
+description: 將 Gitea／GitHub「Node（JavaScript）action」專案標準化（目錄沒有 action manifest 時可問答式從零建立），並串接文件化流程：(1) 檢查 action 主程式是否為 Node，否則保守改寫為 Node，且主程式及其依賴鏈的 `.js` 檔集中到 `src/` 資料夾（工具設定檔與測試目錄不搬）；(2) 對齊 `action.yml` 為 node action（`runs.using` 設為 `node24`、指定 `runs.main`，`outputs` 只留 `description` 不設 `value`，`inputs` 由 runner 自動注入 `INPUT_*`），並在主程式入口最前面輸出 action 名稱／用途／更新時間橫幅；(3) 處理相依打包——零相依則 `main` 直接指向 `src/index.js`，有相依則以 `@vercel/ncc` 打包成 `dist/index.js`、`main` 改指 `dist/index.js` 並將 `dist/` commit 進 repo（runner 不會自動 `npm install`）；(4) 開發中需要新參數時優先取用 runner 注入的 `GITHUB_*`（Gitea 亦有 `GITEA_*`）執行期環境變數，無法取得才詢問使用者是否新增 `inputs`（`secrets`／`vars` 一律視為不可用，需要時宣告為 `inputs` 由呼叫端 workflow 傳入）；(5) 最後完整執行 `/jsc-doc:funcs` 處理流程（function 文件、指令檔逐行註解、重建 README）。當使用者說把 action 改成 node／JavaScript action、從零建立／產生一個 node action、action 主程式 node 化、把 js 收進 src、用 ncc 打包 action、處理 node action 相依或參數來源，或提到 action-node 時觸發。不適用於：Docker 容器 action（用 action-docker）、composite action（用 action-composite）、只整理既有 Dockerfile（用 image）、或不需 action 化／文件化的一般 repo。
+argument-hint: "[--action-dir <action 根目錄>] [--node-version <node runtime，如 node24>] [--main <主程式檔>]"
+---
+
+# action-node — Node（JavaScript）action 標準化＋文件化
+
+五階段 skill：先做**前置設定與偵測**（找出 action 專案、讀取名稱／用途、判斷主程式語言），再把**主程式 Node 化並將主程式依賴鏈的 `.js` 收進 `src/`**，接著**對齊 `action.yml` 為 node action 並在主程式入口最前面注入輸出名稱／用途／更新時間的啟動橫幅**，然後**處理相依打包**（零相依直接跑 `src/`，有相依以 `@vercel/ncc` 打包成 `dist/` 並 commit），最後**完整執行 `/jsc-doc:funcs` 處理流程**替整個專案補文件並重建 README。產出的 node action 由 **runner 內建的 Node runtime 直接執行 `runs.main`**（不需 Docker、啟動比 docker action 快）。各階段開發中需要新參數時，一律套用下方「**參數來源優先序**」規則。目錄沒有 action manifest 時，先走 A1a 問答式「**從零建立**」分支產生 `action.yml` 與 Node 主程式骨架，再進入後續階段。
+
+| 階段 | 動作 |
+| --- | --- |
+| A. 前置設定與偵測 | 決定 action 根目錄 → 讀 `action.yml`／`action.yaml` 的 `name`／`description` → 判斷目前主程式與語言（無 manifest 可走 A1a 從零建立） |
+| B. 主程式 Node 化 | 主程式非 Node 則**保守改寫**為 Node（高風險，先確認）→ 主程式依賴鏈的 `.js` 集中到 `src/`，更新所有引用、`package.json`、`action.yml` |
+| C. 對齊 action.yml + 啟動橫幅 | `runs` 對齊 node action（`using: node24` + `main`）、`outputs` 去除 `value`、`inputs` 契約保留；在主程式入口最前面輸出 action **名稱／用途／更新時間** |
+| D. 相依處理與打包 | 零相依 → `main` 指 `src/index.js`；有相依 → `ncc build` 成 `dist/index.js`、`main` 改指 `dist/index.js`、`dist/` commit 進 repo（runner 不會 `npm install`） |
+| E. 串接 funcs | 對整個 action 專案完整執行 `/jsc-doc:funcs` 流程（function 文件、指令檔逐行註解、重建 README） |
+
+---
+
+## 共用規範（shared plugin，必要前置）
+
+執行本 skill 前，先以 Skill 工具載入下列共用規範並全程遵守；**任一載入不到（shared plugin 未安裝）時，先詢問使用者是否安裝 shared plugin（`https://gitea.jsc.idv.tw/plugins/shared.git`），使用者不安裝則直接中斷本 skill**，不得只憑下方一行摘要繼續執行：
+
+- `/jsc-shared:spec-output`：繁體中文（台灣用語）、UTF-8（不含 BOM）無亂碼。
+- `/jsc-shared:spec-execution`：自動執行原則（必要決策才中斷）、不臆測／需人工確認、不擴及無關檔案。
+- `/jsc-shared:spec-git-safety`：不破壞既有工作（絕不 `reset --hard`／`clean`）、`git mv` 保留歷史。
+- `/jsc-shared:spec-action-params`：action 參數來源優先序（環境變數 → 經同意新增 `inputs`）、`secrets`／`vars` 一律視為不可用。
+- `/jsc-shared:spec-time-log`：更新時間 Asia/Taipei `yyyy/MM/dd HH:mm:ss`、完成後統一同步時間戳。
+- `/jsc-shared:spec-doc-funcs-handoff`：最終階段完整執行 `/jsc-doc:funcs` 的標準流程。
+
+本 skill 特有補充：
+
+- **一定會中斷詢問的點**：階段 B 主程式「非 Node 需改寫」時（破壞性，須先確認），階段 D「新增 `@vercel/ncc` 等 build 相依」時（依 `/jsc-shared:spec-action-params` 經同意），以及階段 E 由 `/jsc-doc:funcs` 自身的「如何實作」詢問。
+- **保留行為**：Node 化只「翻譯」既有邏輯，不得擅自改變對外行為、輸入輸出契約或副作用；任何無法可靠等價推論的改動一律不做，並以註解或回報標註「需人工確認」。新增 `input` 僅限依 `/jsc-shared:spec-action-params` 經使用者同意後為之。
+- **本 skill 只動**：action 專案根目錄內的主程式、主程式依賴鏈的 `.js`（搬移到 `src/`）、`package.json`（含 `scripts.build`）、`action.yml`／`action.yaml`、打包產物 `dist/`、`.gitignore`（確保 `dist/` 不被忽略），以及階段 E 由 funcs 流程處理的目標。**不產生** `Dockerfile`／`entrypoint.sh`（那是 action-docker 的範疇）。
+
+---
+
+## 三種 action 的分工（先確認選對 skill）
+
+| 型態 | `runs.using` | 執行方式 | 對應 skill |
+| --- | --- | --- | --- |
+| **node（本 skill）** | `node24`／`node20`… | runner 內建 Node 直接跑 `main` 指定的 `.js`；**不會 `npm install`** | `action-node` |
+| composite | `composite` | 依序執行 `steps`（純 YAML 組合） | `action-composite` |
+| docker | `docker` | 建 image、於容器內執行（可 `npm ci`） | `action-docker` |
+
+node action 相對 docker／composite 的**關鍵差異**（全程據此處理）：
+
+1. **相依不會自動安裝**：runner 不在 action repo 內跑 `npm install`。要嘛**零相依**，要嘛把相依**打包／commit 進 repo**（見階段 D）。
+2. **無 `entrypoint.sh`／`Dockerfile`**：啟動橫幅改由**主程式（JS）最前面 `console.log` 輸出**，不另外產生 shell 入口。
+3. **`inputs` 自動注入**：runner 會把每個 input 轉成 `INPUT_<NAME>` 環境變數（名稱轉大寫、空白換底線），JS 內以 `process.env.INPUT_<NAME>` 或 `core.getInput('<name>')` 取值；composite 需手動映射，node **不用**。
+4. **`outputs` 只需 `description`**：實際值在執行時由程式寫入 `$GITHUB_OUTPUT`（或 `core.setOutput`），`action.yml` 的 `outputs` **不設也不該有 `value`**（那是 composite 的寫法）。
+5. **`required: true` 不會自動擋、input 一律字串**：必填檢查與型別轉換都要在程式裡自己做。
+6. **`main` 路徑相對 action 根目錄**：讀 action 自帶檔案用 `__dirname` 或 `process.env.GITHUB_ACTION_PATH` 定位，不要用相對呼叫端工作目錄的路徑。
+7. **node 專屬的 `pre`／`post`**：可用 `runs.pre`／`runs.post`（`pre` 不支援 `uses: ./` 的 local action）；composite／docker 沒有。
+
+---
+
+## 參數來源優先序（開發中需要新參數時）
+
+從零建立（A1a）、主程式 Node 化（階段 B）、對齊 `action.yml`（階段 C）或打包（階段 D）的過程中，若需要新的參數值，一律依 `/jsc-shared:spec-action-params` 的優先序處理：node action 主程式優先取 runner 注入的執行期環境變數（`process.env.GITHUB_*`；Gitea 亦提供 `GITEA_*` 同義變數，建議讀 `GITHUB_*` 以相容兩邊），既有 `inputs` 以 `process.env.INPUT_<大寫名稱>`（或 `core.getInput`）取用，取不到才以 `AskUserQuestion` 經使用者同意新增 `inputs`（由呼叫端 workflow 以 `with:` 傳入）；`secrets`／`vars` 一律視為不可用，需要時宣告為 `input` 由呼叫端傳入（範例見該 spec）。
+
+---
+
+## 參數
+
+格式：`[--action-dir <action 根目錄>] [--node-version <node runtime>] [--main <主程式檔>]`
+
+- `--action-dir <action 根目錄>`：action 專案根目錄。**省略時預設目前工作目錄**（須含 `action.yml`／`action.yaml`，否則依 A1 詢問）。
+- `--node-version <node runtime>`：`action.yml` 的 `runs.using` node runtime（如 `node24`、`node20`）。**省略時預設 `node24`**（現行最新，本生態範本採用）；`node24` 需較新的 act runner，runner 太舊會報 `The runs.using key ... got node24`，此時升級 act runner 或退回 `node20`（見階段 C）。
+- `--main <主程式檔>`：指定主程式入口檔（相對 action 根目錄）。省略時依 A3 自動判斷。
+
+---
+
+## 階段 A：前置設定與偵測
+
+### A1. 決定 action 根目錄
+
+- 帶 `--action-dir` → 採用（展開 `~`）。
+- 省略 → 用目前工作目錄。
+- 根目錄須存在 `action.yml` 或 `action.yaml`（action manifest）。**找不到** action manifest → **不臆測**、不逕自動工；以 `AskUserQuestion` 詢問使用者要「**從零建立**新的 Node action」還是「提供正確的 action 路徑」：選「從零建立」→ 進入 A1a；選「提供路徑」→ 依新路徑重跑 A1。
+
+### A1a. 從零建立 Node action（問答式）
+
+依序以問答收集需求，再產生 manifest 與主程式骨架：
+
+1. **action 名稱**：用於 `action.yml` 的 `name`。
+2. **輸入與輸出參數**：逐一收集 `inputs`（名稱、`description`、`required`、`default`）與 `outputs`（名稱、`description`；**不收集 `value`**）；description 盡量繁體中文、無亂碼；沒有可留空。
+3. **執行目標**：詢問此 action 要達成什麼，整理濃縮成一句話作為 `action.yml` 的 `description`（盡量繁體中文、無亂碼）。
+
+收集完成後，於 action 根目錄產生：`action.yml`（`runs.using: node24`、`runs.main: src/index.js`，含收集到的 `name`／`description`／`inputs`／`outputs`）與 `src/index.js` 主程式（依執行目標以 Node 實作，輸入以 `process.env.INPUT_<NAME>` 讀取、輸出以附加寫入 `process.env.GITHUB_OUTPUT`，開發中需要新參數時套用「參數來源優先序」）；預設走**零相依**路線。完成後接續 A2 往後流程（A3 判定為 Node，階段 B 走「已是 Node」分支，階段 C／D 照常對齊 manifest 與處理相依）。
+
+### A2. 讀取 action 名稱與用途
+
+從 action manifest 讀取：
+
+- `name`：action 名稱（供啟動橫幅與 README 使用）。
+- `description`：action 用途。
+- `runs`：目前的執行設定（`using`、`main`、`image`、`entrypoint`、`steps` 等）。
+- `inputs`／`outputs`：對外契約（後續不得破壞）。
+
+若 `name`／`description` 缺漏，回報並請使用者補；無法取得時於後續輸出以「（未提供）」保守標示，**不編造**。
+
+### A3. 判斷目前主程式與語言
+
+依序判斷主程式入口（取第一個成立者）：
+
+1. 帶 `--main <主程式檔>` → 直接採用。
+2. `action.yml` 為 JS action（`runs.using: node*`）→ 取 `runs.main`。
+3. `action.yml` 為 docker action（`runs.using: docker`）→ 看 `runs.entrypoint`／`Dockerfile` 的 `ENTRYPOINT`／`CMD` 推主程式（並提醒：轉為 node action 會**移除容器化**，若原本刻意用 docker，宜改用 `action-docker`）。
+4. `action.yml` 為 composite（`runs.using: composite`）→ 從 `steps` 內實際執行的指令推主程式（提醒：composite 轉 node 屬破壞性改寫）。
+5. 以上皆無 → 依專案檔與副檔名分布推斷（`package.json` 的 `main`／`bin`、`index.js`、`*.sh`、`*.py` 等）。
+
+判定**主程式是否為 Node**：入口為 `.js`／`.mjs`／`.cjs` 且由 `node` 執行即視為 Node；入口為 shell／python／其他則視為非 Node。輸出偵測結果（action 名稱、用途、主程式檔、判定語言、是否為 Node、目前 `runs.using`），再進入階段 B。
+
+---
+
+## 階段 B：主程式 Node 化，並將主程式依賴鏈的 `.js` 收進 `src/`
+
+### B1. 主程式 Node 化
+
+- **已是 Node** → 確認入口檔，不改寫邏輯，直接進 B2。
+- **非 Node（shell／python／其他）** → 這是**破壞性高風險決策**：先以 `AskUserQuestion` 向使用者確認是否改寫為 Node，選項至少含「改寫為 Node」「改用 action-docker（維持原語言容器化）」「其他」。經確認後才改寫：
+  - 逐段把原主程式邏輯**保守翻譯**為 Node（建議 `src/index.js`）；保留對外行為、輸入（環境變數／`INPUT_*`／args）與輸出（`$GITHUB_OUTPUT`／stdout／exit code／檔案副作用）契約。
+  - 外部指令呼叫以 `child_process`（`execFileSync`／`spawnSync`）對應；檔案操作以 `fs`；環境變數以 `process.env`。
+  - 任何無法可靠等價翻譯處，**不臆測**：以 `// 需人工確認：...` 標註並回報。
+  - 改寫完成後，原非 Node 主程式於 B2 一併處理（移除或保留由使用者裁示；預設保留並在 README／回報標註已由 Node 取代）。
+
+### B2. 主程式依賴鏈的 `.js` 集中到 `src/`
+
+- 在 action 根目錄建立 `src/`（若不存在）。
+- 將**主程式入口及其 `require`／`import` 依賴鏈**的 `.js`／`.mjs`／`.cjs`（排除 `node_modules`／`.git`／`.docs`／`dist`／第三方依賴）**移入 `src/`**，優先 `git mv` 保留歷史。主程式入口統一為 `src/index.js`（或 `src/<main>.js`）。
+- **明文排除、不搬**：外部工具依慣例路徑尋找的檔案——`*.config.js`（`eslint.config.js`／`jest.config.js`／`ncc` 等工具設定）、`.*rc.js`、husky／commitlint 等工具設定，以及 `test/`／`tests/`／`scripts/` 目錄；搬走會弄壞 lint／test／build 流程。
+- **移動後必須更新所有引用**，確保不破壞：
+  - 模組間的 `require`／`import` 相對路徑。
+  - `package.json` 的 `main`／`bin`／`scripts`／`exports`（指向 `src/...`；`scripts.build` 的 ncc 入口指向 `src/index.js`）。
+  - `action.yml` 的 `runs.main`（先指向 `src/index.js`；若階段 D 判定需打包，再改指 `dist/index.js`）。
+- 若 `src/` 需要的相依尚未宣告，於 `package.json` 補上；不擅自新增與功能無關的相依（`@vercel/ncc` 屬階段 D 的 build 相依，經同意後才加）。
+
+---
+
+## 階段 C：對齊 action.yml 為 node action，並注入啟動橫幅
+
+### C1. 對齊 `runs` 為 node action
+
+將 manifest 的 `runs` 對齊為 node（JavaScript）action，**保留既有 `inputs`／`outputs`／`name`／`description`**：
+
+```yaml
+runs:
+  using: 'node24'        # 見版本說明；--node-version 可覆寫、runner 太舊退 node20
+  main: 'src/index.js'   # 有相依打包後於階段 D 改為 'dist/index.js'
+```
+
+- **`using` 版本**依 `/jsc-shared:spec-time-log` 之外另遵循版本規則：**預設 `node24`**（現行最新、本生態範本採用），帶 `--node-version` 時改用指定值。`node24` 需較新的 act runner；runner 太舊會報 `The runs.using key in action.yml must be one of: [composite docker node12 node16 node20 go], got node24`——此時**升級 act runner**，或（回報後）暫時退回 `node20`。**不用**沒有意義的 `latest`。
+- **`outputs` 去 `value`**：node action 的 `outputs.<name>` 只保留 `description`，**移除**任何 `value: ${{ steps.* }}`（那是 composite 寫法）；實際值於執行時由程式寫入 `$GITHUB_OUTPUT`。
+- **`inputs` 契約保留**：不更動既有 `inputs` 名稱／`required`／`default`；主程式以 `process.env.INPUT_<大寫名稱>`（或 `core.getInput`）取用，runner 會自動注入，**不需**像 composite 手動映射 `env:`。
+- 原本是 **docker／composite** action 改為 node 時，一併移除只服務原型態的欄位（`image`／`entrypoint`／`steps`），並在回報標示型態已變更；無法可靠等價轉換處以 `# 需人工確認` 標註、不臆測。
+- 選填的 `runs.pre`／`runs.post`（node 專屬）僅在原本已有、或使用者明確要求時才設定；`pre` 不支援 `uses: ./` 的 local action。
+
+### C2. 注入啟動橫幅（主程式入口最前面輸出名稱／用途／更新時間）
+
+node action 沒有 `entrypoint.sh`，橫幅改由**主程式 JS 最前面輸出**。在 `src/index.js`（或階段 B 決定的入口）最上方，於任何其他邏輯**之前**插入（或更新）橫幅輸出：
+
+- **更新時間**依 `/jsc-shared:spec-time-log`（Asia/Taipei、固定 `yyyy/MM/dd HH:mm:ss`、寫成檔內固定字串）。本階段先寫入暫定時間戳，**階段 E 完成後會統一同步各處時間戳**（見階段 E）。
+- 名稱／用途取自階段 A2 的 `action.yml`（缺漏時以「（未提供）」標示）。
+- 若已存在本 skill 先前插入的橫幅（依可辨識註解標記），則**更新**其內容與時間戳，不重複插入。
+
+範例（純 `console.log`、零相依；用 `@actions/core` 時可改 `core.info`）：
+
+```js
+// action 啟動橫幅：輸出名稱／用途／更新時間（此區塊由 action-node 維護）
+console.log('================================================');
+console.log('Action  : <action name>');
+console.log('用途    : <action description>');
+console.log('更新時間: 2026/07/17 12:00:00');
+console.log('================================================');
+```
+
+- 橫幅只做輸出，**不得**改變既有主邏輯的執行順序或副作用。
+- 此區塊的「用途／更新時間」與檔內註解，最終會在階段 E 由 `/jsc-doc:funcs` 的指令檔／function 流程統一補齊／覆寫為標準格式；本階段先確保**執行期輸出**正確即可。
+
+---
+
+## 階段 D：相依處理與打包（零相依直接跑 src/，有相依用 ncc 打包成 dist/）
+
+node action 的 runner **不會自動 `npm install`**，因此相依必須隨 repo 提供。先盤點主程式相依，再二擇一：
+
+### D0. 盤點相依
+
+檢視 `src/` 主程式與 `package.json` 的 `dependencies`：
+
+- **完全零相依**（只用 Node 內建模組，如 `fs`／`os`／`path`／`child_process`）→ 走 D1。
+- **有第三方相依**（如 `@actions/core`／`@actions/github` 或其他 npm 套件）→ 走 D2 打包。
+
+### D1. 零相依：main 直接指 src/index.js
+
+- 確認 `action.yml` 的 `runs.main: src/index.js`，**不需** build 步驟、**不需** `dist/`。
+- `package.json` 可保留（或補上）`scripts.build`（`ncc build src/index.js -o dist`）備用，但零相依情況不必執行。
+
+### D2. 有相依：以 @vercel/ncc 打包成 dist/ 並 commit
+
+打包能把原始碼與相依編成單一檔，避免 commit 龐大的 `node_modules`：
+
+1. 新增 build 相依（依 `/jsc-shared:spec-action-params`／本 skill「一定會中斷詢問的點」，屬新增相依，先向使用者確認）：`npm i -D @vercel/ncc`，並確保 `package.json` 有：
+   ```json
+   "scripts": { "build": "ncc build src/index.js -o dist" }
+   ```
+2. 執行打包產生 `dist/index.js`：`npx ncc build src/index.js -o dist`。
+3. 將 `action.yml` 的 `runs.main` 改為 `dist/index.js`。
+4. **把 `dist/` commit 進 repo**：確認 `.gitignore` **沒有**忽略 `dist/`（若有，移除該規則或加 `!dist/`），並 `git add dist/`。
+5. 於回報提醒：**每次改 `src/` 都要重新 `ncc build` 並提交 `dist/`**，否則 action 執行的是舊版打包產物。
+
+> 另一可行但不建議的做法：直接 commit `node_modules`（體積大、跨平台原生模組易出問題）。預設採用 ncc 打包。
+
+### D3. 版本與自我檢查
+
+- `runs.main` 指向的檔案（`src/index.js` 或 `dist/index.js`）必須**確實存在於 repo**、且為 runner 可直接執行的 JS。
+- `runs.using` 的 node 版本需與目標 runner 相容（見階段 C）。
+- 橫幅輸出、`INPUT_*` 讀取、`$GITHUB_OUTPUT` 寫入在打包後仍正確（ncc 打包不改執行語意，但入口路徑改變，確認 `main` 已同步更新）。
+
+---
+
+## 階段 E：完整執行 /jsc-doc:funcs 處理流程
+
+標準化與打包完成後，以階段 A1 的 action 根目錄為目標，依 `/jsc-shared:spec-doc-funcs-handoff` 對**整個 action 專案**完整執行 `/jsc-doc:funcs` 流程（前置可用性檢查、完整流程、由使用者裁示實作方式、重建 README；本次新增／變更的 `src/` 內 Node 主程式、`action.yml`、`package.json` 都會被涵蓋）。完成後依該 spec **統一時間戳**：回頭同步主程式橫幅輸出與註解區塊、`action.yml` 開頭註解區塊與 README 的更新時間，確保各處一致。
+
+---
+
+## 總結
+
+各階段執行後輸出：
+
+- **階段 A**：action 根目錄、action 名稱／用途、原主程式檔與語言、是否為 Node、目前 `runs.using`；若走 A1a 從零建立，列出問答收集結果（名稱／輸入輸出／目標）。
+- **階段 B**：是否改寫主程式（及改寫摘要與「需人工確認」清單）、搬入 `src/` 的 `.js` 清單、已更新的引用（`package.json`／`action.yml`／路徑）；依「參數來源優先序」新增的 `inputs` 清單與呼叫端傳入寫法（若有）。
+- **階段 C**：對齊後的 `runs`（`using`／`main`）、`outputs` 是否已去除 `value`、`inputs` 契約保留情形、橫幅輸出內容（名稱／用途／更新時間）與插入位置。
+- **階段 D**：相依判定（零相依／打包）、是否新增 `@vercel/ncc`、`runs.main` 最終指向（`src/index.js` 或 `dist/index.js`）、`dist/` 是否已 commit。
+- **階段 E**：funcs 流程的處理結果（文件化的 function 與指令檔、重建的 README）。
+- 列出本次新增／變更的檔案與其相對路徑，並提醒使用者於提交前確認 `runs.main` 檔案存在、（打包時）`dist/` 已提交、目標 runner 支援指定的 node 版本。
+
+---
+
+## 呼叫方式
+
+格式：`[--action-dir <action 根目錄>] [--node-version <node runtime>] [--main <主程式檔>]` — 全部可省略（根目錄預設目前工作目錄；node 版本預設 `node24`；主程式自動判斷）。
+
+| 助理 | 呼叫 |
+| --- | --- |
+| Claude Code / Antigravity | `/jsc-code:action-node`，或 `/jsc-code:action-node --action-dir ~/work/my-action --node-version node24` |
+| Codex | `$action-node`，或 `$action-node --action-dir ~/work/my-action`，或用 `/skills` 選單 |
+| OpenCode | 描述需求（如「把這個 action 主程式改成 node、主程式相關 js 收進 src/，對齊 action.yml 為 node action、在主程式最前面輸出 action 名稱／用途／更新時間，有相依就用 ncc 打包成 dist 並 commit，最後跑 funcs 補文件並重建 README」）自動觸發 |
@@ -1,174 +0,0 @@
---
-name: code-action-composite
-description: 將 Gitea／GitHub「composite action」專案標準化並串接文件化流程：(1) 確認 action 為 composite（`runs.using: composite`），非 composite 則保守確認後對齊；(2) 在 `runs.steps` 最前面注入啟動橫幅 step，輸出 action 名稱／用途／更新時間（Asia/Taipei `yyyy/MM/dd HH:mm:ss`），並於 `action.yml` 開頭補用途／更新時間註解區塊；(3) 最後完整執行 `/jsc:doc-funcs` 處理流程（function 文件、指令檔逐行註解、重建 README）。當使用者說整理 composite action、把 action 標準化為 composite、讓 composite action 啟動時印名稱／用途／更新時間、對 composite action 補文件，或提到 code-action-composite 時觸發。不適用於：Docker 容器 action（用 code-action-docker）、非 action 專案、或不需文件化的一般 repo。
-argument-hint: "[--action-dir <action 根目錄>] [--manifest <action.yml 路徑>] [--yes]"
---
-
-# code-action-composite — composite action 標準化＋文件化
-
-四階段 skill：先做**前置設定與偵測**（找出 action 專案、讀取名稱／用途、判斷是否為 composite），再**確認／對齊為 composite action**，接著在 `runs.steps` 最前面**注入會輸出 action 名稱／用途／更新時間的啟動橫幅 step**，最後**完整執行 `/jsc:doc-funcs` 處理流程**替整個專案補文件並重建 README。
-
-| 階段 | 動作 |
-| --- | --- |
-| A. 前置設定與偵測 | 決定 action 根目錄 → 讀 `action.yml`／`action.yaml` 的 `name`／`description`／`runs` → 判斷是否為 composite |
-| B. 對齊為 composite | 已是 composite 則保留既有 `steps`；非 composite 則**保守確認後對齊**（高風險，先確認），整理被引用的腳本路徑 |
-| C. 注入啟動橫幅 step | 在 `runs.steps` 最前面插入一個 shell step，輸出 action **名稱／用途／更新時間**；並於 `action.yml` 開頭補用途／更新時間註解區塊 |
-| D. 串接 doc-funcs | 對整個 action 專案完整執行 `/jsc:doc-funcs` 流程（function 文件、指令檔逐行註解、重建 README） |
-
---
-
-## 輸出規範（務必遵守）
-
- **語言**：所有面向使用者的輸出（計畫、進度、總結、反問）一律使用**繁體中文（台灣用語）**；僅識別字、檔名、git 指令、API 路徑、YAML 鍵名、程式碼等技術標識保留原文，**不可**使用簡體字。
- **編碼無亂碼**：凡輸出含繁體中文、全形標點、emoji，一律 **UTF-8（不含 BOM）**，不得出現問號方框或錯碼。產生／覆寫的 `action.yml`／`action.yaml`、被引用腳本、`README.md` 同樣需 UTF-8（不含 BOM）。
- **自動執行原則**：除非使用者明確要求先確認，或遇到不可忽略的必要決策，否則各階段只需輸出簡短計畫／進度後直接執行到完成。**一定會中斷詢問的點**：階段 B 主 action「非 composite 需對齊」時（破壞性，須先確認），以及階段 D 由 `/jsc:doc-funcs` 自身的「如何實作」詢問。
- **不破壞既有工作**：改寫 `action.yml`／搬移或改寫被引用腳本前，若工作區有未提交變更，先提醒使用者建議先 commit／備份；**絕不** `reset --hard`／`checkout -f`／`clean`，也不刪除使用者既有原始碼。移動檔案優先用 `git mv` 以保留歷史。
- **保留行為**：對齊 composite 與注入橫幅 step 只「補強」既有流程，不得擅自改變既有 `steps` 的執行順序、輸入（`inputs`）／輸出（`outputs`）契約或副作用；任何無法可靠等價推論的改動一律不做，並以註解或回報標註「需人工確認」。
- **不擴及無關檔案**：本 skill 只動 action 專案根目錄內的：`action.yml`／`action.yaml`、其 `steps` 直接引用的內嵌腳本（如 `*.sh`／`*.ps1`），以及階段 D 由 doc-funcs 流程處理的目標；排除 `node_modules`／`.git`／`.docs`／`bin`／`obj`／第三方依賴。
-
---
-
-## 參數
-
-格式：`[--action-dir <action 根目錄>] [--manifest <action.yml 路徑>] [--yes]`
-
- `--action-dir <action 根目錄>`：action 專案根目錄。**省略時預設目前工作目錄**（須含 `action.yml`／`action.yaml`，否則依 A1 詢問）。
- `--manifest <action.yml 路徑>`：指定 action manifest 檔（相對 action 根目錄）。省略時依 A1 自動尋找 `action.yml`／`action.yaml`。
- `--yes`：盡量不中斷。即使帶此參數，「非 composite 需對齊」與 doc-funcs 的「如何實作」仍會詢問。
-
---
-
-## 階段 A：前置設定與偵測
-
-### A1. 決定 action 根目錄與 manifest
-
- 帶 `--action-dir` → 採用（展開 `~`）；省略 → 用目前工作目錄。
- manifest：帶 `--manifest` → 採用；否則於根目錄找 `action.yml`，再退而 `action.yaml`。
- **找不到** action manifest → 回報「此目錄不是 action 專案（缺 action.yml／action.yaml）」並詢問正確路徑，**不臆測**、不在非 action 專案上動工。
-
-### A2. 讀取 action 名稱與用途
-
-從 action manifest 讀取：
-
- `name`：action 名稱（供啟動橫幅與 README 使用）。
- `description`：action 用途。
- `runs`：目前的執行設定（`using`、`steps`、`main`、`image`、`entrypoint` 等）。
- `inputs`／`outputs`：對外契約（後續不得破壞）。
-
-若 `name`／`description` 缺漏，回報並請使用者補；無法取得時於後續輸出以「（未提供）」保守標示，**不編造**。
-
-### A3. 判斷是否為 composite
-
-依 `runs.using` 判定：
-
- `composite` → 即為目標型態，記下既有 `runs.steps`，直接進入階段 B 的「已是 composite」分支。
- `node*`（JS action）／`docker`（Docker 容器 action）／其他 → 視為**非 composite**。
-
-輸出偵測結果（action 名稱、用途、`runs.using`、是否為 composite、既有 step 數量），再進入階段 B。
-
-> 若偵測為 **Docker 容器 action**，且使用者本意是容器化而非 composite，提醒可改用 `/jsc:code-action-docker`，再依使用者裁示決定是否續行。
-
---
-
-## 階段 B：確認／對齊為 composite action
-
-### B1. 已是 composite
-
- 確認 `runs.using: composite` 與既有 `runs.steps`，**不更動既有 steps 的順序與邏輯**，直接進入階段 C。
- 順手檢查 step 的必要欄位（`run` step 須有 `shell`；`uses` step 的引用是否存在），有疑慮以回報標註，不擅改。
-
-### B2. 非 composite（需對齊）
-
-這是**破壞性高風險決策**：先以 `AskUserQuestion` 向使用者確認，選項至少含「對齊為 composite」「維持原樣只做文件化（略過對齊）」「改用 code-action-docker」「其他」。經確認「對齊為 composite」後才改寫：
-
- 將 `runs` 保守對齊為 composite，把原執行入口轉為 composite step：
-  - 原 JS action（`runs.using: node*`，`runs.main: <x>.js`）→ 轉為一個 `run` step，於 step 內以 `node <x>.js` 執行（`shell: bash`），保留 `inputs`／`outputs` 與環境變數（`INPUT_*`）契約。
-  - 原 Docker action（`runs.using: docker`）→ Docker 行為通常無法可靠等價地塞進 composite；**不臆測改寫**，以回報＋`# 需人工確認` 標註，並建議改用 `/jsc:code-action-docker`。
- 任何無法可靠等價對齊處，**不臆測**：以 `# 需人工確認：...` 標註並回報，保留原檔行為。
-
-對齊後的 `runs` 形如：
-
-```yaml
-runs:
-  using: composite
-  steps:
-    # （階段 C 會在此處最前面插入啟動橫幅 step）
-    - name: <原執行入口轉成的 step>
-      shell: bash
-      run: node ./index.js
-```
-
---
-
-## 階段 C：注入啟動橫幅 step（輸出名稱／用途／更新時間）
-
-在 `runs.steps` **最前面**插入（或更新）一個輸出橫幅的 step，讓 composite action 一啟動就**輸出 action 名稱、用途、更新時間**；並於 `action.yml` 開頭補用途／更新時間註解區塊。
-
- **更新時間**為產生此檔當下的時間戳，使用台灣時區（Asia/Taipei）並固定為 `yyyy/MM/dd HH:mm:ss`（可用 `TZ='Asia/Taipei' date +'%Y/%m/%d %H:%M:%S'` 取得），**寫成檔內固定字串**（非執行期動態時間）。
- 名稱／用途取自階段 A2 的 `action.yml`（缺漏時以「（未提供）」標示）。
- 橫幅 step 須有可辨識的 `name`（如 `顯示 action 資訊`）與 `shell: bash`；其後緊接既有／對齊後的 steps，**不更動既有 steps**。
- 若已存在本 skill 先前插入的橫幅 step（依 `name` 辨識），則**更新**其內容與更新時間，不重複插入。
-
-範例（既有 steps 接在橫幅 step 之後）：
-
-```yaml
-name: <action name>
-description: <action description>
-
-runs:
-  using: composite
-  steps:
-    # 啟動橫幅：輸出名稱／用途／更新時間（此 step 由 code-action-composite 產生）
-    - name: 顯示 action 資訊
-      shell: bash
-      run: |
-        echo "================================================"
-        echo "Action  : <action name>"
-        echo "用途    : <action description>"
-        echo "更新時間: 2026/06/30 18:30:05"
-        echo "================================================"
-    # === 以下為既有／對齊後的 steps（保持原順序與邏輯）===
-    - name: <既有 step>
-      shell: bash
-      run: node ./index.js
-```
-
- `action.yml` 開頭的「用途／更新時間」註解區塊與每行註解，最終會在階段 D 由 `/jsc:doc-funcs` 的指令檔流程統一補齊／覆寫為標準格式（用途與更新日期同一註解區塊、逐行註解）；本階段先確保**執行期橫幅輸出**正確即可。
- 自我檢查：插入橫幅 step 後 YAML 仍可解析（縮排、`steps` 為 list、每個 `run` step 都有 `shell`），且 `inputs`／`outputs` 未被更動。
-
---
-
-## 階段 D：完整執行 /jsc:doc-funcs 處理流程
-
-標準化完成後，對**整個 action 專案**完整執行 `/jsc:doc-funcs` 流程，替程式碼與指令檔補文件並重建 README：
-
- 以階段 A1 的 action 根目錄為目標，執行 `doc-funcs` skill 的完整流程（判斷語言 → 掃描 function 與指令檔 → 建立 `.docs/` 草稿 → 草稿品質檢查 → 詢問使用者如何實作 → 依選擇寫回 → 保守優化 → 重建 README → 錨點檢查 → 清理草稿 → 建置／語法驗證）。
- doc-funcs 會把 `action.yml`／`action.yaml` 視為 CI／部署設定檔處理：補齊「用途＋更新日期同一註解區塊」與逐行註解；`steps` 內引用的腳本（`*.sh`／`*.ps1` 等）逐行註解；專案內各 function 補文件註解。
- doc-funcs 的「如何實作」詢問（全部一起／逐個／其他）由使用者於該流程內裁示，本 skill 不代為決定。
- 完成後依 doc-funcs 規範重建根目錄 `README.md`（含台灣時區更新時間、專案列表、功能列表、使用範例）。
-
-> 銜接方式：在本 skill 環境中以 `/jsc:doc-funcs`（或 Skill 工具）啟動 doc-funcs 流程；若該流程需參數，沿用本 skill 的 action 根目錄為目標專案。
-
---
-
-## 總結
-
-各階段執行後輸出：
-
- **階段 A**：action 根目錄、manifest 路徑、action 名稱／用途、`runs.using`、是否為 composite、既有 step 數量。
- **階段 B**：是否對齊為 composite（及對齊摘要與「需人工確認」清單），或維持原樣的理由。
- **階段 C**：橫幅 step 的輸出內容（名稱／用途／更新時間）與插入位置，並確認既有 steps、`inputs`／`outputs` 未被破壞。
- **階段 D**：doc-funcs 流程的處理結果（文件化的 function 與指令檔、重建的 README）。
- 列出本次新增／變更的檔案與其相對路徑，並提醒使用者於提交前確認 `action.yml` 可正常解析、composite action 能正確啟動並輸出橫幅。
-
---
-
-## 呼叫方式
-
-格式：`[--action-dir <action 根目錄>] [--manifest <action.yml 路徑>] [--yes]` — 全部可省略（根目錄預設目前工作目錄；manifest 自動尋找）。
-
-| 助理 | 呼叫 |
-| --- | --- |
-| Claude Code / Antigravity | `/jsc:code-action-composite`，或 `/jsc:code-action-composite --action-dir ~/work/my-action` |
-| Codex | `$code-action-composite`，或 `$code-action-composite --action-dir ~/work/my-action`，或用 `/skills` 選單 |
-| OpenCode | 描述需求（如「把這個 composite action 標準化，在 steps 最前面加一個會輸出 action 名稱／用途／更新時間的 step，最後跑 doc-funcs 補文件並重建 README」）自動觸發 |
@@ -1,224 +0,0 @@
---
-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/`、盡量詳細輸出訊息且格式統一為 `[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 專案。
-argument-hint: "[--action-dir <action 根目錄>] [--node-version <node tag>]"
---
-
-# code-action-docker — 問答式打造 Docker 容器 action（Node 主程式）＋文件化
-
-五階段 skill：先以問答收齊需求——**action 名稱**（階段 1）、**輸入與輸出參數**（階段 2）、**流程目標並濃縮成一句話**（階段 3）——再依標準**實作目標**（階段 4：Node.js、程式檔一律放 `src/`、統一訊息格式，並產生 `action.yml`／`entrypoint.sh`／最新 node 版本的 `Dockerfile`），最後**檢查是否有 doc-funcs 技能**（階段 5）：有則完整執行 `/jsc:doc-funcs`，否則結束。
-
-| 階段 | 動作 |
-| --- | --- |
-| 1. 詢問 action 名稱 | 向使用者詢問 action 名稱 → 寫入 `action.yml` 的 `name` |
-| 2. 詢問輸入與輸出參數 | 逐一收齊 `inputs`／`outputs`（名稱、description、required、default）→ description 盡量繁體中文、無亂碼 |
-| 3. 詢問流程目標 | 詢問此 action 要達成什麼 → 整理並**濃縮成一句話**，經使用者確認後寫入 `action.yml` 的 `description`（盡量繁體中文、無亂碼） |
-| 4. 實作目標 | 盡量以 **Node.js** 開發、程式檔**一律放 `src/`**；訊息詳細且格式統一為 `[yyyy/MM/dd HH:mm:ss][階段][等級]: 訊息`；產生 `action.yml`／`entrypoint.sh`／最新 node 版本的 `Dockerfile` |
-| 5. 檢查 doc-funcs | 有 doc-funcs 技能 → 完整執行 `/jsc:doc-funcs`；沒有 → 回報後結束 |
-
---
-
-## 輸出規範（務必遵守）
-
- **語言**：所有面向使用者的輸出（問題、計畫、進度、總結）一律使用**繁體中文（台灣用語）**；僅識別字、檔名、git／docker 指令、API 路徑、程式碼等技術標識保留原文，**不可**使用簡體字。
- **編碼無亂碼**：凡輸出含繁體中文、全形標點、emoji，一律 **UTF-8（不含 BOM）**，不得出現問號方框或錯碼。產生的 `action.yml`、`src/*.js`、`entrypoint.sh`、`Dockerfile`、`README.md` 同樣需 UTF-8（不含 BOM）；`action.yml` 內的中文 `name`／`description`／參數說明必須能被 YAML 正確解析與顯示。
- **問答原則**：階段 1～3 是**必要輸入**，缺一不可；使用者已在呼叫時提供的答案不再重複詢問，未提供的必須以 `AskUserQuestion`（或明確反問）取得，**不得臆測代答**。階段 4 起除必要決策外直接執行到完成。
- **不破壞既有工作**：若 action 根目錄已存在 `action.yml`／`src/`／`entrypoint.sh`／`Dockerfile`，覆寫前先回報並確認；工作區有未提交變更時提醒使用者先 commit／備份；**絕不** `reset --hard`／`checkout -f`／`clean`，也不刪除使用者既有原始碼。
- **不擴及無關檔案**：本 skill 只產生／修改 action 根目錄內的 `action.yml`、`src/`、`entrypoint.sh`、`Dockerfile`、`package.json`，以及階段 5 由 doc-funcs 流程處理的目標；排除 `node_modules`／`.git`／`.docs`／`bin`／`obj`／第三方依賴。
-
---
-
-## 參數
-
-格式：`[--action-dir <action 根目錄>] [--node-version <node tag>]`
-
- `--action-dir <action 根目錄>`：action 專案根目錄。**省略時預設目前工作目錄**。
- `--node-version <node tag>`：`Dockerfile` 的 node base image tag（如 `22`、`22-alpine`、`lts`）。**省略時預設使用最新 node 版本**（`node:latest`，見階段 4）。
-
-階段 1～3 的答案（名稱、輸入輸出參數、目標）不設 CLI 參數；使用者若已在呼叫訊息中口述，直接採用、不再重問。
-
---
-
-## 階段 1：詢問 action 名稱
-
-向使用者詢問 **action 名稱**，用於 `action.yml` 的 `name`：
-
- 使用者已在呼叫時提供 → 直接採用並回報。
- 未提供 → 以 `AskUserQuestion`（自由輸入為主，可依目錄名／repo 名給 2～3 個建議選項）詢問，**不得自行編造**。
- 名稱不得為空；可為繁體中文或英文，原樣寫入 `name`，不擅自翻譯或改寫。
-
-## 階段 2：詢問輸入與輸出參數
-
-向使用者收齊 action 的**輸入（`inputs`）與輸出（`outputs`）參數**，逐項確認：
-
- **每個輸入**：參數名稱（建議 kebab-case）、`description`（**盡量繁體中文、無亂碼**）、是否必填（`required`）、預設值（`default`，選填）。
- **每個輸出**：參數名稱、`description`（**盡量繁體中文、無亂碼**）。
- 使用者明確表示「無輸入」或「無輸出」→ 對應區塊留空（省略該區塊），不硬造參數。
- description 缺漏時**反問補齊**，不編造；使用者堅持留空則標示「（未提供）」。
- 收齊後輸出整理表（名稱／必填／預設值／說明）讓使用者確認，再進入階段 3。
-
-實作對應（供階段 4 使用）：輸入在容器內以 `INPUT_<大寫參數名>` 環境變數取得（`-` 轉 `_`）；輸出以附加 `name=value` 到 `$GITHUB_OUTPUT` 檔案寫出。
-
-## 階段 3：詢問執行此流程的目標
-
-向使用者詢問**此 action 要達成什麼目標**（要處理什麼、產出什麼、成功／失敗準則）：
-
- 追問到「可實作」為止：不清楚的環節（資料來源、外部指令、失敗時的行為）必須問清，**不得臆測**。
- 將目標**整理並濃縮成一句話**（盡量繁體中文、無亂碼），向使用者確認後寫入 `action.yml` 的 `description`。
- 完整目標描述（含細節與邊界）保留於回報與階段 4 的實作依據，不因濃縮而遺失。
-
-## 階段 4：實作目標（Node.js、src/、統一訊息格式）
-
-依階段 1～3 收齊的需求實作 action，遵守以下標準：
-
-### 4.0 開發中需要參數時的來源優先序
-
-實作過程中發現需要某個參數（例如 repo 資訊、token、環境設定）而階段 2 的 `inputs` 沒有時，**依下列順序尋找來源，前者可用就不往後找**：
-
-1. **`${{ gitea.* }}` context**：runner 內建 context（如 `gitea.repository`、`gitea.ref`、`gitea.actor`、`gitea.token`）；docker action 執行期對應 runner 注入的 `GITHUB_*`／`GITEA_*` 環境變數（如 `GITHUB_REPOSITORY`、`GITHUB_REF`），主程式直接讀 `process.env` 即可。
-2. **`${{ secrets.* }}`**：repo／org 的 secrets（機敏值：token、密碼、金鑰）。
-3. **`${{ vars.* }}`**：repo／org 的 variables（非機敏設定值）。
-4. **以上都沒有** → 以 `AskUserQuestion` 詢問使用者**是否要把該參數加入 `inputs`**（加入則回到階段 2 規格補齊名稱／description／required／default，並同步 `action.yml`）；**不得臆測預設值或硬編碼**。
-
-注意：`secrets.*`／`vars.*` 無法在 `action.yml` 的 `inputs.default` 直接引用，須由呼叫端 workflow 以 `with:` 或 `env:` 傳入（如 `with: token: ${{ secrets.MY_TOKEN }}`）；採用這類來源時，在 README 使用範例中示範呼叫端如何帶入，機敏值一律不落地、不輸出明文（log 需遮蔽）。
-
-### 4.1 盡量以 Node.js 開發，程式檔一律放 `src/`
-
- 主程式與所有模組**盡量以 Node.js 撰寫**；只有目標必須依賴外部工具時，才以 `child_process`（`execFileSync`／`spawnSync`）在 Node 內呼叫，不另寫 shell／python 主程式。
- 所有 `.js`／`.mjs`／`.cjs`**一律放在 `src/` 資料夾內**，主程式入口統一為 `src/index.js`；需要相依套件時於 `src/` 建立 `package.json`（`main` 指向入口檔），不擅自新增與目標無關的相依。
- 輸入用 `process.env.INPUT_*` 讀取（必填缺漏 → 輸出 `ERR` 訊息並以非零 exit code 結束）；輸出寫入 `process.env.GITHUB_OUTPUT`。
-
-### 4.2 盡量詳細輸出訊息，格式統一
-
- 執行過程**盡量詳細輸出**：開始／結束、讀到的輸入、每個關鍵步驟、外部指令與結果、寫出的輸出、警告與錯誤。
- 每一則訊息格式固定為：
-
-  ```
-  [yyyy/MM/dd HH:mm:ss][階段][等級]: 訊息
-  ```
-
-  - **時間**：台灣時區（Asia/Taipei），固定 `yyyy/MM/dd HH:mm:ss`。
-  - **階段**：該訊息所屬的流程階段名稱（如 `讀取輸入`、`執行`、`寫出結果`）；**沒有階段時整個 `[階段]` 區塊移除**，即 `[yyyy/MM/dd HH:mm:ss][等級]: 訊息`。
-  - **等級**：必為 `INF`／`WRN`／`ERR`／`TRC`／`DBG` 其中之一（一般資訊 INF、警告 WRN、錯誤 ERR、細部追蹤 TRC、除錯 DBG）。
- **一行一則訊息**：每則訊息獨立一行輸出，不得多則併成一坨。
- 在 `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
-```
-
-無輸入／輸出時省略對應區塊。
-
-### 4.4 產生 entrypoint.sh
-
-在 action 根目錄產生 `entrypoint.sh`：啟動 node 主程式前，先輸出 action **名稱／用途／更新時間**，且每則輸出同樣遵守 4.2 訊息格式（階段用 `啟動`）：
-
-```sh
-#!/bin/sh
-set -e
-
-# action 啟動訊息：名稱／用途／更新時間（此檔由 code-action-docker 產生）
-echo "[<產生當下 Asia/Taipei 時間>][啟動][INF]: Action：<action 名稱>"
-echo "[<產生當下 Asia/Taipei 時間>][啟動][INF]: 用途：<action.yml 的 description>"
-echo "[<產生當下 Asia/Taipei 時間>][啟動][INF]: 更新時間：<產生當下 Asia/Taipei 時間>"
-
-# 啟動 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 標記為可執行）。
-
-### 4.5 產生 Dockerfile（使用最新 node 版本）
-
-在 action 根目錄產生 `Dockerfile`，**base image 使用最新 node 版本**，採**多階段建置**縮小最終映像，內容依 `src/` 實作量身決定（有相依才裝、需要 OS 工具才 `apt-get install`，用不到的不硬塞）：
-
-```Dockerfile
-# syntax=docker/dockerfile:1
-
-# 1. 參數處理：node 版本以 ARG 注入（預設最新版；--node-version 可覆寫）
-ARG NODE_VERSION=latest
-ARG NODE_RUNTIME=slim
-
-# ---- build 階段：安裝相依 ----
-FROM node:${NODE_VERSION} AS build
-WORKDIR /action
-
-# 2. 安裝套件：先帶相依描述以利 layer 快取（有 lockfile 用 npm ci）
-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. 複製檔案：帶入主程式與入口
-COPY src/ /action/src/
-COPY entrypoint.sh /action/entrypoint.sh
-
-# 4. 執行程序：賦予 entrypoint 執行權限
-RUN chmod +x /action/entrypoint.sh
-
-# 5. 縮小映像檔：runtime 改用 slim 基底，只帶必要產物
-FROM node:${NODE_RUNTIME} AS runtime
-WORKDIR /action
-COPY --from=build /action /action
-
-# 6. 設定入口：以 entrypoint.sh 啟動 node 主程式
-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`。
- 主程式以 `child_process` 呼叫外部執行檔（如 `git`、`openssl`）時，於 runtime 階段補 `apt-get install` 對應套件並清快取。
- **自我檢查**：`entrypoint.sh` 的 `node /action/src/index.js` 路徑須與 `Dockerfile` 的 `WORKDIR`／`COPY` 落點一致。
-
-### 4.6 驗證
-
- `node --check src/*.js` 驗證語法；有 `package.json` 時執行 `npm install`（或 `npm ci`）確認相依可解析。
- 環境有 docker 時執行 `docker build .` 驗證映像可建置；無法執行時明確說明原因並標註風險。
-
-## 階段 5：檢查是否有 doc-funcs 技能
-
-實作完成後，檢查目前環境是否有 **doc-funcs** 技能（可用 skill 清單中是否存在 `doc-funcs`，含 `/jsc:doc-funcs` 等帶前綴形式）：
-
- **有** → 以階段 4 的 action 根目錄為目標，**完整執行 `/jsc:doc-funcs` 流程**（判斷語言 → 掃描 function 與指令檔 → 建立 `.docs/` 草稿 → 詢問使用者如何實作 → 寫回 → 保守優化 → 重建 README → 清理草稿 → 驗證）。doc-funcs 會涵蓋本次產出：`src/` 內各 function 的 JSDoc、`entrypoint.sh`／`Dockerfile` 逐行註解、重建 README；其「如何實作」詢問由使用者於該流程內裁示。既有訊息一律維持本 skill 4.2 的 `[yyyy/MM/dd HH:mm:ss][階段][等級]: 訊息` 格式，不得被改寫成其他欄位順序。
- **沒有** → 回報「未偵測到 doc-funcs 技能，略過文件化」後**結束**，不自行模擬 doc-funcs 流程。
-
---
-
-## 總結
-
-各階段執行後輸出：
-
- **階段 1～3**：action 名稱、輸入／輸出參數整理表、濃縮後的一句話 description。
- **階段 4**：產出檔案清單（`action.yml`、`src/index.js`、`src/logger.js`、`src/package.json`（若有）、`entrypoint.sh`、`Dockerfile`）與各自相對路徑、採用的 node 版本、驗證結果（語法檢查／npm／docker build）。
- **階段 5**：是否偵測到 doc-funcs；有則附 doc-funcs 流程的處理結果（文件化的 function 與指令檔、重建的 README）。
- 提醒使用者於提交前確認 `entrypoint.sh` 有可執行權限、容器能正確啟動。
-
---
-
-## 呼叫方式
-
-格式：`[--action-dir <action 根目錄>] [--node-version <node tag>]` — 全部可省略（根目錄預設目前工作目錄；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 補文件」）自動觸發 |
@@ -1,176 +0,0 @@
---
-name: code-review-archive
-description: 將 /jsc:code-review 已裁決的問題保存到目標專案 —【✅ 成立】附加到「前次審查紀錄（已知問題）」檔、【❌ 誤判】附加到「排除事項」檔，讓 code-review 防守方下次自動標為 🔁 已知問題 / 🚫 略過。當使用者說保存／歸檔 code review 結果、把成立問題寫進已知問題、把誤判寫進排除事項、把 review 裁決落地到專案時觸發。只處理「已裁決」的列表（合併防守方裁決表與攻擊方問題表），不自己跑 review、不修改程式碼。缺裁決表時，請先用 /jsc:code-review 的防守方（paladin）產生裁決。
-argument-hint: "--known-issues <前次審查紀錄路徑> --exclusions <排除事項檔案路徑>"
---
-
-# code-review-archive — 保存 code-review 裁決結果到專案
-
-把 `/jsc:code-review` 防守方的裁決落地成兩份專案紀錄，形成下次審查的回饋圈：
-
-| 裁決 | 動作 |
-| --- | --- |
-| ✅ 成立 | 附加到**前次審查紀錄（已知問題）檔** → 下次審查會被標 **🔁 已知問題** |
-| ❌ 誤判 | 附加到**排除事項檔** → 下次審查會被標 **🚫 略過** |
-| 🔁 已知問題 | 已在已知問題檔，**不重複寫入**（僅計數） |
-| 🚫 略過 | 已在排除事項檔，**不重複寫入**（僅計數） |
-
-> 與 `/jsc:code-review` 的關係：code-review 的步驟 7 只會（在同意後）把 ✅ 成立 寫入已知問題檔；
-> **誤判 → 排除事項** 它不會寫。本 skill 一次補齊兩個方向，且**只吃既有裁決結果**：不跑 review、不改程式碼。
-
-## 輸出規範（務必遵守）
-
- **語言**：所有面向使用者的輸出與**寫入檔案的內容**一律使用**繁體中文（台灣用語）**；
-  僅檔名、程式碼識別字、`key`／JSON 欄位名等技術標識保留原文，不可使用簡體字。
- **編碼無亂碼**：建立或附加檔案一律以 **UTF-8（不含 BOM）** 寫入，確保中文、全形標點與等級 emoji（🔴🟠🟡🔵）、
-  裁決 emoji（🚫🔁❌✅）正常顯示，不得出現問號方框或錯碼。
-
-## 參數（與 code-review 同名旗標，方便沿用同一組路徑）
-
-`--known-issues <前次審查紀錄路徑>`　`--exclusions <排除事項檔案路徑>` — **兩者皆必填，一定要指定**。
-
- **未提供任一路徑 → 必須先向使用者取得，不可自行採用預設或臆測**（與 code-review 一致：預設檔名僅作詢問時的建議選項）。
-  建議預設：已知問題 `known-issues.md`、排除事項 `exclusions.md`（與 code-review 防守方讀的同一檔）。
- **檔案本身允許不存在或為空內容**：若目標檔不存在、或內容為空（含只有空白）→ skill 先**依模板建立該檔**（見下方「模板」），再附加條目；既有非空檔則直接附加。
- 寫入屬於**更動專案檔案**的行為 → **未獲使用者同意前不可寫入**；拒絕則只輸出將寫入的預覽。
- **格式依副檔名自動決定**：`.md` → Markdown（用下方模板）；`.json` → top-level JSON array（空／不存在時初始化為 `[]`）。
-
-## 執行流程
-
-### 1. 取得問題表與裁決表（只吃既有結果）
-
-來源優先序：本次對話中上一個 `/jsc:code-review` 的輸出；若無，請使用者貼上。
-
- **問題表**（攻擊方）：`問題 | 等級 | 描述 | 建議 | 檔案位置 | 所在行數`。
- **裁決表**（防守方）：`來源角色 | 原問題 | 裁決 | 理由 | 最終建議`，裁決 ∈ `🚫 略過 / 🔁 已知問題 / ❌ 誤判 / ✅ 成立`。
- **沒有裁決表** → 無法分類，**請先跑防守方**（`/jsc:code-review <target> <source> paladin`）或請使用者提供裁決表。
-  **只處理已裁決的列表**，不自行臆測成立或誤判。
-
-### 2. 合併兩表
-
-以 **`原問題` ↔ `問題`** 為鍵配對；同名問題以 **`來源角色` + `檔案位置`** 區分。
-合併後每筆 = 等級／描述／建議／檔案位置／所在行數（問題表）＋ 裁決／理由／最終建議（裁決表）。
-
- **對不上的列**（裁決表有但問題表查無，或反之）→ 列出請使用者確認，**不臆測**、不寫入。
-
-### 3. 補齊欄位
-
- **日期**：`YYYY-MM-DD`（可用 `date +%F`，或取來源分支最後 commit 日期）。
- **範圍／來源**：`<target>...<source>`（沿用本次 review 的分支；不確定就問或留白）。
-
-### 4. 取得同意 → 去重 → 附加
-
-1. 先輸出「將寫入」的預覽（各檔幾筆、條目摘要），**請使用者確認**後才動檔。
-2. **去重鍵**：`<檔案位置>|<問題標題>`。寫入前先讀目標檔，**已存在相同鍵的條目 → 略過不重複附加**。
-3. **目標檔不存在或為空（含只有空白）→ 先依「模板」建立**（`.md` 用下方模板；`.json` 初始化為 `[]`），再附加。
-4. 分流：
-   - **✅ 成立** → 附加到**已知問題檔**（`--known-issues`）。
-   - **❌ 誤判** → 附加到**排除事項檔**（`--exclusions`）。
-   - **🔁 已知問題 / 🚫 略過** → 不處理（已存在），僅計數。
-
-### 5. 回報摘要
-
-列出：新增成立 N 筆、新增誤判 M 筆、已知問題（略過）K 筆、排除（略過）L 筆、重複而跳過 J 筆，以及實際寫入的檔案路徑。
-
---
-
-## 檔案格式
-
-### Markdown（`.md`）
-
-目標檔不存在時先建立標題：
-
- 已知問題檔：`# 前次審查紀錄（已知問題）\n\n由 /jsc:code-review-archive 從 code-review【✅ 成立】問題彙整；/jsc:code-review 防守方會讀此檔並標「🔁 已知問題」。`
- 排除事項檔（`exclusions.md`）：`# Code Review 排除事項\n\n已知技術債／團隊慣例／刻意取捨／已確認的誤判；/jsc:code-review 防守方會讀此檔並標「🚫 略過」。`
-
-**已知問題** 每筆：
-
-```markdown
-### [<等級>] <問題標題>
-<!-- key: <檔案位置>|<問題標題> -->
- 檔案：`<檔案位置>:<所在行數>`
- 描述：<描述>
- 建議：<最終建議>
- 裁決：✅ 成立（<理由>）— 由 <來源角色> 提出
- 範圍：`<target>...<source>`，<日期>
-```
-
-**排除事項** 每筆：
-
-```markdown
-### <問題標題>
-<!-- key: <檔案位置>|<問題標題> -->
- 檔案：`<檔案位置>`
- 排除原因（❌ 誤判）：<裁決理由>
- 範圍：`<target>...<source>`，<日期>
-```
-
-### JSON（`.json`）
-
-維持 **top-level array**（不要包在物件裡）；每筆一個物件，以 `key` 去重：
-
-```json
-{
-  "key": "<檔案位置>|<問題標題>",
-  "title": "<問題標題>",
-  "severity": "🔴 嚴重 | 🟠 高 | 🟡 中 | 🔵 低",
-  "file": "<檔案位置>",
-  "line": "<所在行數>",
-  "description": "<描述>",
-  "suggestion": "<最終建議>",
-  "verdict": "成立 | 誤判",
-  "reason": "<理由>",
-  "source": "<target>...<source>",
-  "date": "YYYY-MM-DD"
-}
-```
-
---
-
-## 模板（空檔／新檔的初始內容）
-
-目標檔不存在或為空時，先寫入下列模板（同一份也隨附於本 skill 的 `templates/`），再於對應標題下附加條目。
-
-### 已知問題檔（`--known-issues`，`.md`）
-
-```markdown
-# 前次審查紀錄（已知問題 / Known Issues）
-
-> 本檔由 `/jsc:code-review-archive` 自動維護，記錄 `/jsc:code-review` 防守方裁定 **✅ 成立** 但尚未解決的問題。
-> `/jsc:code-review` 防守方在步驟 3(b) 會讀此檔：若新發現與此處條目相符，標為 **🔁 已知問題（前次未解決）**，不重複裁決。
-> 問題修復後請刪除對應條目。每筆以 `<!-- key: 檔案位置|問題標題 -->` 去重。
-
-## 待解決問題
-
-<!-- code-review-archive 由此往下追加條目；條目格式見 /jsc:code-review-archive 說明。 -->
-```
-
-### 排除事項檔（`--exclusions`，`.md`）
-
-```markdown
-# Code Review 排除事項（Exclusions）
-
-> 本檔由 `/jsc:code-review-archive` 維護（也可手動編輯），列出已知技術債／團隊慣例／刻意取捨／已確認的誤判。
-> `/jsc:code-review` 防守方在步驟 3(a) 會讀此檔：若新發現命中此處條目，標為 **🚫 略過（排除事項）**，不再裁決。
-> 不再適用時請手動移除。每筆以 `<!-- key: 檔案位置|問題標題 -->` 去重。
-
-## 排除項目
-
-<!-- code-review-archive 由此往下追加條目；條目格式見 /jsc:code-review-archive 說明。 -->
-```
-
-### JSON（`.json`）
-
-空／不存在時初始化為空陣列，再 append 物件：`[]`
-
---
-
-## 呼叫方式
-
-格式：`--known-issues <路徑> --exclusions <路徑>` — **兩者必填**；未提供會反問取得。需先有 `/jsc:code-review` 的問題表＋裁決表。
-
-| 助理 | 呼叫 |
-| --- | --- |
-| Claude Code / Antigravity | `/jsc:code-review-archive --known-issues known-issues.md --exclusions exclusions.md`（或省略路徑由它反問） |
-| Codex | `$code-review-archive --known-issues docs/known-issues.md --exclusions docs/review-rules.md`，或用 `/skills` 選單 |
-| OpenCode | 描述需求（如「把剛剛 code-review 成立的問題存到 known-issues.md、誤判存到 exclusions.md」）自動觸發 |
@@ -1,9 +0,0 @@
-# Code Review 排除事項（Exclusions）
-
-> 本檔由 `/jsc:code-review-archive` 維護（也可手動編輯），列出已知技術債／團隊慣例／刻意取捨／已確認的誤判。
-> `/jsc:code-review` 防守方在步驟 3(a) 會讀此檔：若新發現命中此處條目，標為 **🚫 略過（排除事項）**，不再裁決。
-> 不再適用時請手動移除。每筆以 `<!-- key: 檔案位置|問題標題 -->` 去重。
-
-## 排除項目
-
-<!-- code-review-archive 由此往下追加條目；條目格式見 /jsc:code-review-archive 說明。 -->
@@ -1,9 +0,0 @@
-# 前次審查紀錄（已知問題 / Known Issues）
-
-> 本檔由 `/jsc:code-review-archive` 自動維護，記錄 `/jsc:code-review` 防守方裁定 **✅ 成立** 但尚未解決的問題。
-> `/jsc:code-review` 防守方在步驟 3(b) 會讀此檔：若新發現與此處條目相符，標為 **🔁 已知問題（前次未解決）**，不重複裁決。
-> 問題修復後請刪除對應條目。每筆以 `<!-- key: 檔案位置|問題標題 -->` 去重。
-
-## 待解決問題
-
-<!-- code-review-archive 由此往下追加條目；條目格式見 /jsc:code-review-archive 說明。 -->
@@ -1,165 +0,0 @@
---
-name: code-review
-description: 以 RPG 攻防對決方式審查 git diff 的程式碼審查 skill。當使用者想做 code review、審查未提交變更、審查某分支的差異、做 PR review、或想用攻擊方/防守方角色從風格、邏輯、效率、安全性面向找出程式碼問題時觸發。使用者可選擇要派哪些角色（單一角色、整個攻擊方、整個防守方、或全部）。攻擊方分析 git diff 找出問題（問題/等級/描述/建議/檔案位置/所在行數）；防守方依專案排除事項、前次審查紀錄（已知問題）與原始碼脈絡裁決每條問題（略過/已知問題/誤判/成立）。不適用於：非 diff 的整體架構評估、非程式碼的文件審查、或單純解釋程式碼。
---
-
-# 🛡️⚔️ code-review — RPG 攻防對決式 git diff 審查
-
-由可選擇的 RPG 角色對 `git diff` 進行攻防審查。**攻擊方**找問題，**防守方**裁決。
-角色定義在 `roles/` 資料夾（一角色一個 `.md`），各自有英文名稱、專案、個性、徽章與代表色。
-
-## 角色一覽
-
-| 角色 | 陣營 | 面向 | 徽章 | 檔案 |
-| --- | --- | --- | --- | --- |
-| Bard（吟遊詩人） | 攻擊方 | 風格 | 🎼 | `roles/bard.md` |
-| Mage（法師） | 攻擊方 | 邏輯 | 🔮 | `roles/mage.md` |
-| Rogue（盜賊） | 攻擊方 | 效率 | ⚡ | `roles/rogue.md` |
-| Assassin（刺客） | 攻擊方 | 安全性 | 🗡️ | `roles/assassin.md` |
-| Paladin（聖騎士） | 防守方 | 裁決 | 🛡️ | `roles/paladin.md` |
-
-每次執行前，先讀取被選到角色的 `roles/<role>.md`，套用其 frontmatter（徽章、代表色、個性）與 body（審查重點/裁決準則）。
-
---
-
-## 輸出規範（所有角色共用，務必遵守）
-
- **語言**：所有面向使用者的輸出（findings 表、裁決表、總結、附註、反問）一律使用**繁體中文（台灣用語）**。
-  僅程式碼識別字、檔名、git 指令、既有技術術語保留原文，**不可**使用簡體字或英文敘述句。
- **編碼無亂碼**：輸出與寫入檔案一律 **UTF-8（不含 BOM）**；確保表格、全形標點與下列 emoji 正常顯示、不得出現問號方框或錯碼：
-  等級 🔴🟠🟡🔵、裁決 🚫🔁❌✅、角色 🎼🔮⚡🗡️🛡️。
- **派發 subagent 時**：須把本規範一併寫入每個 subagent 的提示，確保各角色回傳的內容同樣是繁體中文、無亂碼。
-
---
-
-## 執行流程
-
-### 1. 取得 diff（必須指定來源分支與目標分支，缺一不可）
-
-審查範圍一律是兩個分支的差異，**來源分支（source）**與**目標分支（target）**兩者**缺一不可**：
-
- slash 參數提供兩者：`/jsc:code-review <target> <source>`（順序：目標在前、來源在後），例如
-  `/jsc:code-review main feature/login`。指令為 `git diff <target>...<source>`（比對 source 自分岔點以來的變更）。
- **若來源或目標分支任一缺漏 → 必須詢問使用者補齊**，兩個都拿到才繼續；
-  可用 `git branch` 列出可選分支輔助使用者選擇。不可自行臆測或預設某一分支。
- 取得兩個分支後執行 `git diff <target>...<source>`，並**排除下列不納入審查的路徑**：
-  - **任何以 `.` 開頭的資料夾內的所有內容**（如 `.git/`、`.github/`、`.claude-plugin/`、`.codex-plugin/`、`.agents/` 等）。
-  - **排除事項檔**與**前次審查紀錄檔**本身（`--exclusions` / `--known-issues` 指定的路徑；未指定時連同預設檔名 `exclusions.md`、`known-issues.md` 一併排除）。
-  - 用 git pathspec 一次完成，例如：
-
-    ```bash
-    git diff <target>...<source> -- . \
-      ':(exclude,glob)**/.*/**' \
-      ':(exclude)<排除事項檔路徑>' \
-      ':(exclude)<前次審查紀錄檔路徑>'
-    ```
-
-    （`**/.*/**` 排除任意層級的 `.` 開頭資料夾內容；`.` 開頭的**檔案**不在此列，只有上述兩個設定檔被指名排除。）
- **過濾後 diff 為空** → 回報「無變更可審查」並結束。
-
-### 2. 選擇角色
-
-slash 參數格式：`/jsc:code-review <target> <source> [角色...] [--exclusions <排除事項檔案路徑>] [--known-issues <前次審查紀錄路徑>]`
-（角色接在兩個分支之後；`--exclusions`、`--known-issues` 旗標可放在任意位置，分別指定排除事項檔案、前次審查紀錄檔案）。
-
- **若已指定角色** → 直接採用。可接受：
-  - 單一面向：`bard` / `mage` / `rogue` / `assassin` / `paladin`
-  - 整方：`attack`（4 個攻擊方）、`defend`（防守方）
-  - 全部：`all`（攻擊方全員 + 防守方，完整對決）
-  - 複選以逗號分隔：`mage,rogue`
- **若未指定角色** → **詢問使用者**要派哪些角色（Claude Code / Antigravity 用 AskUserQuestion 複選；
-  Codex / OpenCode 直接在訊息中列選單請使用者回覆）。選項涵蓋：單一角色 / 攻擊方全員 / 防守方全員 / 全部。
-
-### 3. 載入排除事項與前次審查紀錄（只要選到防守方就需要）
-
-防守方需要兩份參照資料，兩者皆位於**專案根目錄**：
-
-**(a) 排除事項設定檔**（建議檔名 `exclusions.md`，列出已知技術債／團隊慣例／刻意取捨）：
-
- **若 slash 參數帶了 `--exclusions <路徑>`** → 即為使用者明確指定，直接採用該路徑，**不需再問**。
- **否則只要使用者沒有明確告知檔案路徑 → 一律先詢問**。預設檔名 `exclusions.md` 僅作為詢問時的**建議選項**，
-  **不可**在未取得使用者明確指定前自行假設或直接採用該預設路徑。
- **檔案允許不存在或為空** → 視為「無排除事項」，**不**因缺檔而中斷。
-
-**(b) 前次審查紀錄檔**（已知問題＝前次審查成立但未解決的問題；建議檔名 `known-issues.md`）：
-
- **若 slash 參數帶了 `--known-issues <路徑>`** → 即為使用者明確指定，直接採用該路徑，**不需再問**。
- **否則只要使用者沒有明確告知檔案路徑 → 一律先詢問**（規則同上，預設檔名僅為建議選項，不可自行假設）。
- **檔案允許不存在或為空** → 視為「無已知問題」（例如首次審查），**不**因缺檔而中斷。
-
-### 4. 攻擊方審查
-
-被選到的每個攻擊方角色，依其 `focus` 與個性掃描 diff，**各自輸出一張 findings 表**
-（表前加上該角色的徽章＋名稱，並標註代表色）：
-
-> ## 🔮 Mage（法師）· 邏輯　`#3B82F6`
->
-> | 問題 | 等級 | 描述 | 建議 | 檔案位置 | 所在行數 |
-> | --- | --- | --- | --- | --- | --- |
-
- **等級**：🔴 嚴重 / 🟠 高 / 🟡 中 / 🔵 低。
- **檔案位置 / 所在行數**：取自 diff 新檔（`+` 側）的路徑與行號。
- 只針對本次 diff 的變更，不對無關舊碼開砲。
- 攻擊方審查的是**步驟 1 過濾後**的 diff（已排除 `.` 開頭資料夾內容、排除事項檔與前次審查紀錄檔），不得把這些被排除的路徑列入問題。
-
-### 5. 防守方裁決（若選到防守方）
-
-**先把攻擊方的 findings 彙整去重並排序，再逐條裁決：**
-
- **(0) 去重 + 排序**：合併所有攻擊方的 findings，依「同檔案位置 ＋ 同問題本質」**去除重複**
-  （多個角色重複提出的同一問題只保留一條，並註明由哪些角色共同提出），再依嚴重等級
-  **🔴 嚴重 → 🟠 高 → 🟡 中 → 🔵 低** 排序。
-
-對排序後的**每一條** finding 依序：
-
- **(a) 先比對排除事項**：命中 → **🚫 略過（排除事項）**，引用對應排除條目，不再回答此條。
- **(b) 再比對前次審查紀錄（已知問題）**：若與前次發現但未解決的問題相符 → **🔁 已知問題（前次未解決）**，引用對應紀錄條目，不重複裁決。
- **(c) 否則讀原始碼判斷**：標 **❌ 誤判（false positive）**（附理由）或 **✅ 成立**（附理由與修正建議）。
-
-輸出一張裁決表（聖騎士徽章 🛡️ `#EAB308`）：
-
-| 來源角色 | 原問題 | 裁決 | 理由 | 最終建議 |
-| --- | --- | --- | --- | --- |
-
-裁決欄只能是 `🚫 略過 / 🔁 已知問題 / ❌ 誤判 / ✅ 成立`。
-
-> **若只選了防守方、尚無攻擊方 findings** → 先自動跑攻擊方全員產生指控，再裁決（並告知使用者已自動補跑）。
-
-### 6. 總結
-
- **有防守方**：只彙整 **✅ 成立** 的問題，依等級（🔴→🔵）排序成一份精簡待辦清單；略過（排除事項）、已知問題、誤判皆不列入；
-  另以一行附註本次「🔁 已知問題（前次未解決）」的數量，提醒這些問題仍懸而未決。
- **無防守方**：直接呈現攻擊方各自的 findings 表。
-
-### 7. 更新前次審查紀錄（有防守方時，可選）
-
-為了讓「已知問題」在下次審查能被辨識，**詢問使用者是否將本次 ✅ 成立的問題寫入前次審查紀錄檔**
-（步驟 3 取得的 `--known-issues` 路徑或詢問所得路徑）：
-
- 經同意後，把本次 ✅ 成立、且未當場修正的問題**追加／更新**進該檔（沿用的 🔁 已知問題維持保留）。
- 寫入屬於更動專案檔案的行為，**未獲同意前不可自行寫入**；使用者拒絕則僅輸出總結、不改檔。
-
---
-
-## 執行方式：單選 vs 複選
-
- **單一角色** → 模型直接扮演該角色執行，不需 subagent。
- **複選（多個角色 / 整方 / 全部）** → 以 **sub agent** 方式執行：
-  - **Claude Code / Antigravity**：用 Agent/Task 工具，**每個被選到的攻擊方角色派一個 subagent 並行執行**
-    （subagent 帶該角色 `roles/<role>.md` 的人設與審查重點 + diff 內容，回傳其 findings 表）；
-    攻擊方 subagent 全部回來後，**再派防守方 subagent** 對彙整後的 findings 裁決。
-  - **Codex / OpenCode（無對等 subagent 機制）**：退化為模型**依序扮演**各角色，行為等價、僅非並行。
-
-無論哪種路徑，最終輸出格式（findings 表、裁決表、總結）一致。
-
-## 呼叫方式
-
-格式：`<target> <source> [角色...] [--exclusions <排除事項檔案路徑>] [--known-issues <前次審查紀錄路徑>]` —
-**來源/目標分支缺一不可**，缺漏會反問補齊；角色可省略（會詢問）；`--exclusions`、`--known-issues` 可省略
-（省略時若選到防守方會反問檔案路徑）。
-
-| 助理 | 呼叫 |
-| --- | --- |
-| Claude Code / Antigravity | `/jsc:code-review`（反問分支與角色），或 `/jsc:code-review main feature/login mage`、`/jsc:code-review main feature/login all --exclusions exclusions.md --known-issues known-issues.md` |
-| Codex | `$code-review main feature/login attack`，或 `$code-review main feature/login all --exclusions docs/review-rules.md --known-issues docs/known-issues.md`，或用 `/skills` 選單 |
-| OpenCode | 描述需求（如「用攻防角色 review main 與 feature/login 的差異，排除事項看 docs/review-rules.md、已知問題看 docs/known-issues.md」）自動觸發 |
@@ -1,36 +0,0 @@
---
-name: Assassin
-project: code-review
-side: attack
-focus: security
-badge: "🗡️"
-color: "#DC2626"
-personality: 多疑偏執、以攻擊者視角看世界，假設每筆輸入都是惡意的，每個信任都會被濫用
---
-
-# 🗡️ Assassin（刺客）· 安全性面向
-
-> 攻擊方。代表色 `#DC2626`（暗紅）。
-
-## 個性
-
-刺客習慣站在敵人的位置思考：哪裡能潛入、哪裡能越權、哪裡能讓秘密外洩。
-他多疑而偏執，不相信任何「使用者不會這樣傳」的善意假設，
-把每筆外部輸入都當作淬了毒的匕首來對待。
-
-## 審查重點（只看 git diff 的新增/修改處）
-
- **注入**：SQL/NoSQL/指令/LDAP 注入、未參數化查詢、字串拼接到危險介面。
- **輸入驗證與輸出編碼**：缺少驗證、缺少跳脫/編碼導致 XSS、路徑穿越、反序列化不可信資料。
- **認證與授權**：缺少權限檢查、越權（IDOR）、可被繞過的驗證、信任前端傳來的身分。
- **機密與資料外洩**：硬編碼金鑰/密碼/token、敏感資料寫進 log、過度回傳內部資訊（呼應組織規範：回應不得含 PII）。
- **不安全預設**：弱加密/雜湊、關閉 TLS 驗證、寬鬆 CORS、可預測的隨機數、危險的檔案/權限設定。
-
-## 不做的事
-
- 不挑風格、不論一般邏輯或效能（交給其他角色），專注可被惡意利用的破口。
- 不對純內部、無外部信任邊界的程式碼虛張聲勢。
-
-## 發言風格
-
-以刺客口吻，冷峻地描述「攻擊者會怎麼利用這裡」，每條附攻擊情境與加固建議。**輸出一律使用繁體中文（台灣用語）、UTF-8 無亂碼。**
@@ -1,36 +0,0 @@
---
-name: Bard
-project: code-review
-side: attack
-focus: style
-badge: "🎼"
-color: "#8B5CF6"
-personality: 唯美龜毛、追求優雅，把可讀性與一致性當作旋律，最受不了走調的命名與排版
---
-
-# 🎼 Bard（吟遊詩人）· 風格面向
-
-> 攻擊方。代表色 `#8B5CF6`（紫）。
-
-## 個性
-
-吟遊詩人視程式碼為樂譜：命名要押韻、節奏要一致、留白要恰到好處。
-他唯美而龜毛，看到走調的命名、雜亂的排版或自相矛盾的風格就渾身不對勁，
-但他只談「讀起來」的問題，不越界去搶法師（邏輯）或刺客（安全）的活。
-
-## 審查重點（只看 git diff 的新增/修改處）
-
- **命名**：語義不清、縮寫浮濫、與既有慣例不一致、布林/集合命名誤導。
- **可讀性**：函式過長、巢狀過深、魔術數字/字串、重複樣板可抽共用。
- **一致性**：與同檔／鄰近原始碼的風格不一致（縮排、引號、命名慣例、檔案組織）。
- **註解與文件**：缺少必要說明、註解與程式碼不符、無用的廢話註解。
- **格式**：排版凌亂、import 順序、尾隨空白等明顯瑕疵（不取代 linter，但點出可讀性影響）。
-
-## 不做的事
-
- 不判斷邏輯正確性、效能或安全性（交給其他角色）。
- 不對「能跑就好」的既有舊碼開砲，只針對本次 diff 的變更。
-
-## 發言風格
-
-以吟遊詩人口吻，文雅但毫不留情地點出「不和諧之處」，每條都給出更優雅的寫法建議。**輸出一律使用繁體中文（台灣用語）、UTF-8 無亂碼。**
@@ -1,36 +0,0 @@
---
-name: Mage
-project: code-review
-side: attack
-focus: logic
-badge: "🔮"
-color: "#3B82F6"
-personality: 嚴謹冷靜、滴水不漏，凡事推演到最壞情況，深信「沒驗證過的假設都是 bug」
---
-
-# 🔮 Mage（法師）· 邏輯面向
-
-> 攻擊方。代表色 `#3B82F6`（藍）。
-
-## 個性
-
-法師以冷靜的推演為武器，習慣把每段邏輯放進水晶球裡跑遍所有分支與輸入。
-他不在意程式碼好不好看，只在意它在最壞情況下會不會崩。
-任何「應該不會發生」的假設，在他眼裡都是尚未爆炸的咒語。
-
-## 審查重點（只看 git diff 的新增/修改處）
-
- **空值與邊界**：null / undefined、空集合、off-by-one、邊界值、整數溢位。
- **分支完整性**：遺漏的 else/default、未處理的列舉值、矛盾的條件、提早 return 漏掉清理。
- **例外處理**：吞掉的例外、錯誤被靜默忽略、錯誤狀態未回滾。
- **併發與順序**：競態、共享狀態、非原子操作、await/順序錯置、交易邊界不完整。
- **語義一致性**：改動與既有原始碼語義衝突、契約（參數/回傳/型別）被破壞、副作用外溢。
-
-## 不做的事
-
- 不挑命名/排版（交給吟遊詩人）、不算效能（交給盜賊）、不找漏洞（交給刺客）。
- 不臆測無關的程式碼，只針對本次 diff 推演。
-
-## 發言風格
-
-以法師口吻，冷靜列出「在什麼輸入/時序下會出錯」，每條附最小重現情境與修正方向。**輸出一律使用繁體中文（台灣用語）、UTF-8 無亂碼。**
@@ -1,67 +0,0 @@
---
-name: Paladin
-project: code-review
-side: defend
-focus: verdict
-badge: "🛡️"
-color: "#EAB308"
-personality: 沉穩公正、就事論事，不護短也不冤枉，只依排除事項、前次審查紀錄與原始碼脈絡下判斷
---
-
-# 🛡️ Paladin（聖騎士）· 裁決面向
-
-> 防守方。代表色 `#EAB308`（金）。
-
-## 個性
-
-聖騎士是這座競技場的裁判：沉穩、公正、就事論事。
-他不為了護短而放水，也不讓攻擊方的氣勢冤枉了無辜的程式碼。
-他手握三件聖物——**專案排除事項**、**前次審查紀錄**與**原始碼脈絡**——逐條審視每一項指控。
-
-## 排除事項（裁決前先確認）
-
-排除事項設定檔位於**專案根目錄**（建議檔名 `exclusions.md`，列出已知技術債／團隊慣例／刻意取捨）。
-
-1. **若 slash 參數帶了 `--exclusions <路徑>`** → 即為使用者明確指定，直接採用該路徑。
-2. **否則只要使用者沒有明確告知檔案路徑 → 一律先詢問**。預設檔名 `exclusions.md` 僅是詢問時的**建議選項**，
-   **不可**在未取得使用者明確指定前自行假設或直接採用該預設路徑。
-3. **檔案允許不存在或為空** → 視為「無排除事項」，不因缺檔而中斷。
-
-## 前次審查紀錄（已知問題＝前次發現但未解決的問題，裁決前先確認）
-
-前次審查紀錄檔位於**專案根目錄**（建議檔名 `known-issues.md`，記錄歷次審查成立但尚未解決的問題）。
-
-1. **若 slash 參數帶了 `--known-issues <路徑>`** → 即為使用者明確指定，直接採用該路徑。
-2. **否則只要使用者沒有明確告知檔案路徑 → 一律先詢問**。預設檔名 `known-issues.md` 僅是詢問時的**建議選項**，
-   **不可**在未取得使用者明確指定前自行假設或直接採用該預設路徑。
-3. **檔案允許不存在或為空** → 視為「無已知問題」（例如首次審查），不因缺檔而中斷。
-
-## 裁決準則
-
-裁決前，先把攻擊方的所有 finding **去重並依嚴重等級排序**：
-
-0. **去重 + 排序** — 依「同檔案位置 ＋ 同問題本質」去除重複（多個角色重複提出的同一問題只留一條，
-   註明由哪些角色共同提出），再依嚴重等級 **🔴 嚴重 → 🟠 高 → 🟡 中 → 🔵 低** 排序。
-
-接著對排序後的**每一條** finding 依序處理：
-
-1. **先比對排除事項** — 若該問題落在排除事項範圍（已知技術債／團隊慣例等）：
-   - 標記 **🚫 略過（排除事項）**，引用對應的排除條目，**不需再回答**此問題。
-2. **再比對前次審查紀錄（已知問題）** — 若該問題與前次審查發現、但尚未解決的問題相符：
-   - 標記 **🔁 已知問題（前次未解決）**，引用對應的紀錄條目，**不重複裁決**此問題。
-3. **否則讀原始碼判斷** — 讀被指控檔案的相關原始碼脈絡後，標註：
-   - **❌ 誤判（false positive）**：原始碼顯示此問題不成立（例如他處已處理、語義其實正確）→ 附理由。
-   - **✅ 成立（confirmed）**：問題屬實 → 附理由與最終修正建議。
-
-## 裁決輸出
-
-輸出一張裁決表，每列對應攻擊方的一條 finding：
-
-| 來源角色 | 原問題 | 裁決 | 理由 | 最終建議 |
-| --- | --- | --- | --- | --- |
-
-裁決欄只能是 `🚫 略過 / 🔁 已知問題 / ❌ 誤判 / ✅ 成立` 之一。
-
-## 發言風格
-
-以聖騎士口吻，公正而簡潔地給出判決與依據，不偏袒任何一方。**輸出一律使用繁體中文（台灣用語）、UTF-8 無亂碼。**
@@ -1,36 +0,0 @@
---
-name: Rogue
-project: code-review
-side: attack
-focus: efficiency
-badge: "⚡"
-color: "#F59E0B"
-personality: 急性子、講求速度，最痛恨被浪費的 CPU 週期與記憶體，凡事先問「這能不能更快、更省」
---
-
-# ⚡ Rogue（盜賊）· 效率面向
-
-> 攻擊方。代表色 `#F59E0B`（橙）。
-
-## 個性
-
-盜賊靠速度吃飯，眼裡只有被偷走的時間與資源。
-他坐不住，看到迴圈裡的重複查詢、無謂的配置、能快取卻硬算的程式碼就抓狂。
-他不糾結優雅或安全，只想把每一個被浪費的週期偷回來。
-
-## 審查重點（只看 git diff 的新增/修改處）
-
- **演算法複雜度**：不必要的巢狀迴圈、隱藏的 O(n²)、可用雜湊/索引優化的線性搜尋。
- **資料存取**：N+1 查詢、迴圈內 I/O、缺少分頁/批次、重複的遠端呼叫。
- **重複運算**：可提取迴圈外的不變量、可記憶化（memoize）/快取的重算。
- **記憶體與配置**：迴圈內的大量物件配置、不必要的複製、未釋放的資源、過早具現化整個集合。
- **同步阻塞**：可並行卻序列、阻塞式呼叫卡住熱路徑。
-
-## 不做的事
-
- 不挑風格、不論正確性、不找安全漏洞（交給其他角色）。
- 不做沒有實測根據的「微優化」教條；點出的是有實際影響的熱點。
-
-## 發言風格
-
-以盜賊口吻，急切而直接地指出「哪裡在浪費」，每條附量級估計與更省的做法。**輸出一律使用繁體中文（台灣用語）、UTF-8 無亂碼。**
@@ -1,37 +0,0 @@
---
-name: hello
-description: 範例 skill，用來驗證 jsc plugin 是否安裝成功，也是新增 skill 的範本。當使用者輸入 hello、想測試 plugin、或想看 skill 模板長什麼樣子時觸發；回覆一句問候並簡述此 plugin 的用途。
---
-
-# hello（範例 skill）
-
-這是 `jsc` plugin 的範例 skill。它有兩個用途：
-
-1. **驗證安裝** — 跨各家 AI 助理確認 skill 已被正確載入。
-2. **作為範本** — 複製這個資料夾即可新增一個新的 skill。
-
-## 呼叫方式
-
-| 助理 | 呼叫方式 |
-| --- | --- |
-| Claude Code | `/jsc:hello` |
-| Antigravity | `/jsc:hello`，或描述需求自動觸發 |
-| Codex | 在提示詞輸入 `$hello`，或用 `/skills` 選單 |
-| OpenCode | 直接描述需求，模型會透過 skill 工具自動呼叫 |
-
-## 行為
-
-當這個 skill 被觸發時：
-
-1. 回覆「Hello from **jsc** 👋」。
-2. 用一句話說明 `jsc` 是一個跨 AI 助理的共用 skill 集合。
-3. 提示使用者可以在 README 的「Skills 目錄」查看所有可用的 skills。
-
-## 如何以此為範本新增 skill
-
-1. 複製 `skills/hello/` 為 `skills/<your-skill-name>/`。
-2. 修改 `SKILL.md` 的 frontmatter：
-   - `name`：小寫、數字、連字號（`-`），最長 64 字元。**這個名稱會成為 Claude Code / Antigravity 的 `/jsc:<name>` 指令**。
-   - `description`：第三人稱，寫清楚「什麼時候該用、什麼時候不該用」與觸發關鍵字 — 各家助理靠這段文字決定是否自動載入。
-3. 在內文寫下 skill 的具體步驟。
-4. 手動把新 skill 補進 README 的「Skills 目錄」區塊。
@@ -1,29 +1,36 @@
 ---
-name: code-image
-description: 把專案的 `Dockerfile` 整理成固定六步流程並串接文件化流程：(1) 找出專案根目錄與目標 `Dockerfile`、判斷語言／生態與既有建置方式；(2) 在保留建置行為的前提下，把 `Dockerfile` 重整為 **參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口** 六步流程（以多階段建置縮小最終映像，可調參數集中於檔首 `ARG`，相依描述先 `COPY` 以利 layer 快取）；(3) 最後完整執行 `/jsc:doc-funcs` 處理流程（function 文件、`Dockerfile` 等指令檔逐行註解、重建 README）。當使用者說整理／重構 Dockerfile、把 Dockerfile 排成參數處理→安裝→複製→執行→縮小→入口六步、優化映像檔分層／多階段建置、縮小 image，或提到 code-image 時觸發。不適用於：Gitea／GitHub action 容器化（用 code-action-docker）、composite action（用 code-action-composite）、或專案內沒有也不需要 Dockerfile 的情況。
+name: image
+description: 把專案的 `Dockerfile` 整理成固定六步流程並串接文件化流程：(1) 找出專案根目錄與目標 `Dockerfile`、判斷語言／生態與既有建置方式；(2) 在保留建置行為的前提下，把 `Dockerfile` 重整為 **參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口** 六步流程（以多階段建置縮小最終映像，可調參數集中於檔首 `ARG`，相依描述先 `COPY` 以利 layer 快取）；(3) 最後完整執行 `/jsc-doc:funcs` 處理流程（function 文件、`Dockerfile` 等指令檔逐行註解、重建 README）。當使用者說整理／重構 Dockerfile、把 Dockerfile 排成參數處理→安裝→複製→執行→縮小→入口六步、優化映像檔分層／多階段建置、縮小 image，或提到 image 時觸發。不適用於：Gitea／GitHub action 容器化（用 action-docker）、composite action（用 action-composite）、或專案內沒有也不需要 Dockerfile 的情況。
 argument-hint: "[--project-dir <專案根目錄>] [--dockerfile <Dockerfile 路徑>] [--yes]"
 ---

-# code-image — Dockerfile 六步流程整理＋文件化
+# image — Dockerfile 六步流程整理＋文件化

-三階段 skill：先做**前置設定與偵測**（找出專案根目錄、定位目標 `Dockerfile`、判斷語言／生態與既有建置方式），再把 `Dockerfile` **重整為固定六步流程**（參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口，並以多階段建置縮小最終映像），最後**完整執行 `/jsc:doc-funcs` 處理流程**替整個專案補文件並重建 README。
+三階段 skill：先做**前置設定與偵測**（找出專案根目錄、定位目標 `Dockerfile`、判斷語言／生態與既有建置方式），再把 `Dockerfile` **重整為固定六步流程**（參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口，並以多階段建置縮小最終映像），最後**完整執行 `/jsc-doc:funcs` 處理流程**替整個專案補文件並重建 README。

 | 階段 | 動作 |
 | --- | --- |
 | A. 前置設定與偵測 | 決定專案根目錄 → 定位目標 `Dockerfile`（找不到則詢問，不臆造）→ 讀現有指令、判斷語言／生態、既有 base image 與建置流程 |
 | B. 整理 Dockerfile 為六步流程 | 在**保留建置行為**前提下，把指令重整／歸位為六步：參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口；多階段建置縮小映像；行為不等價處標「需人工確認」並先確認 |
-| C. 串接 doc-funcs | 對整個專案完整執行 `/jsc:doc-funcs` 流程（function 文件、`Dockerfile` 等指令檔逐行註解、重建 README） |
+| C. 串接 funcs | 對整個專案完整執行 `/jsc-doc:funcs` 流程（function 文件、`Dockerfile` 等指令檔逐行註解、重建 README） |

 ---

-## 輸出規範（務必遵守）
+## 共用規範（shared plugin，必要前置）

- **語言**：所有面向使用者的輸出（計畫、進度、總結、反問）一律使用**繁體中文（台灣用語）**；僅識別字、檔名、git／docker 指令、API 路徑、程式碼等技術標識保留原文，**不可**使用簡體字。
- **編碼無亂碼**：凡輸出含繁體中文、全形標點、emoji，一律 **UTF-8（不含 BOM）**，不得出現問號方框或錯碼。產生／覆寫的 `Dockerfile`、`README.md` 同樣需 UTF-8（不含 BOM）。
- **自動執行原則**：除非使用者明確要求先確認，或遇到不可忽略的必要決策，否則各階段只需輸出簡短計畫／進度後直接執行到完成。**一定會中斷詢問的點**：階段 B「重整無法可靠保證建置行為等價」時（破壞性，須先確認），以及階段 C 由 `/jsc:doc-funcs` 自身的「如何實作」詢問。
- **不破壞既有工作**：覆寫 `Dockerfile` 前，若工作區有未提交變更，先提醒使用者建議先 commit／備份；**絕不** `reset --hard`／`checkout -f`／`clean`，也不刪除使用者既有原始碼。
- **保留建置行為**：重整只「重新組織與分層」既有指令，不得擅自改變最終映像的內容、檔案落點、相依版本、暴露的 port、`ENV`、`ENTRYPOINT`／`CMD` 對外契約或建置副作用；任何無法可靠等價推論的調整一律不做，並以註解或回報標註「需人工確認」。多階段建置縮小映像時，runtime 階段必須帶齊執行所需的所有產物（執行檔、相依、靜態資源、`ENV`、暴露 port），不得遺漏導致容器無法啟動。
- **不擴及無關檔案**：本 skill 階段 A／B 只動目標 `Dockerfile`（及與其直接相關、為保留行為而必須同步的 `.dockerignore`）；其餘檔案僅在階段 C 由 doc-funcs 流程依其規範處理。排除 `node_modules`／`.git`／`.docs`／`bin`／`obj`／第三方依賴。
+執行本 skill 前，先以 Skill 工具載入下列共用規範並全程遵守；**任一載入不到（shared plugin 未安裝）時，先詢問使用者是否安裝 shared plugin（`https://gitea.jsc.idv.tw/plugins/shared.git`），使用者不安裝則直接中斷本 skill**，不得只憑下方一行摘要繼續執行：
+
+- `/jsc-shared:spec-output`：繁體中文（台灣用語）、UTF-8（不含 BOM）無亂碼。
+- `/jsc-shared:spec-execution`：自動執行原則（必要決策才中斷）、不臆測／需人工確認、不擴及無關檔案。
+- `/jsc-shared:spec-git-safety`：不破壞既有工作（絕不 `reset --hard`／`clean`）。
+- `/jsc-shared:spec-dockerfile`：Dockerfile 六步流程、多階段建置、對外契約不動、自我檢查。
+- `/jsc-shared:spec-doc-funcs-handoff`：最終階段完整執行 `/jsc-doc:funcs` 的標準流程。
+
+本 skill 特有補充：
+
+- **一定會中斷詢問的點**：階段 B「重整無法可靠保證建置行為等價」時（破壞性，須先確認），以及階段 C 由 `/jsc-doc:funcs` 自身的「如何實作」詢問。
+- **保留建置行為**：重整只「重新組織與分層」既有指令，不得擅自改變最終映像的內容、檔案落點、相依版本、暴露的 port、`ENV`、`ENTRYPOINT`／`CMD` 對外契約或建置副作用；多階段建置縮小映像時，runtime 階段必須帶齊執行所需的所有產物，不得遺漏導致容器無法啟動。
+- **本 skill 只動**：階段 A／B 只動目標 `Dockerfile`（及與其直接相關、為保留行為而必須同步的 `.dockerignore`）；其餘檔案僅在階段 C 由 funcs 流程依其規範處理。

 ---

@@ -33,7 +40,7 @@ argument-hint: "[--project-dir <專案根目錄>] [--dockerfile <Dockerfile 路

 - `--project-dir <專案根目錄>`：專案根目錄。**省略時預設目前工作目錄**。
 - `--dockerfile <Dockerfile 路徑>`：指定要整理的 `Dockerfile`（相對專案根目錄）。省略時依 A2 自動定位；找到多個時詢問。
- `--yes`：盡量不中斷。即使帶此參數，「重整無法保證建置行為等價」與 doc-funcs 的「如何實作」仍會詢問。
+- `--yes`：盡量不中斷。即使帶此參數，「重整無法保證建置行為等價」與 funcs 的「如何實作」仍會詢問。

 ---

@@ -50,18 +57,18 @@ argument-hint: "[--project-dir <專案根目錄>] [--dockerfile <Dockerfile 路
 - 省略 → 於專案根目錄與常見位置尋找 `Dockerfile`（含 `Dockerfile.*`、`*/Dockerfile`，排除 `node_modules`／`.git`／`.docs`／`bin`／`obj`／第三方依賴）。
  - 恰好一個 → 直接採用。
  - 多個 → 以 `AskUserQuestion` 列出讓使用者選擇要整理哪一個（或逐一整理）。
-  - **找不到** → 回報「專案內找不到 `Dockerfile`」並詢問正確路徑；**不臆造** Dockerfile、不在沒有 Dockerfile 的專案上憑空生成（本 skill 的職責是「整理既有 Dockerfile」，產生全新 action 容器請改用 `/jsc:code-action-docker`）。
+  - **找不到** → 回報「專案內找不到 `Dockerfile`」並詢問正確路徑；**不臆造** Dockerfile、不在沒有 Dockerfile 的專案上憑空生成（本 skill 的職責是「整理既有 Dockerfile」，產生全新 action 容器請改用 `/jsc-code:action-docker`）。

 ### A3. 讀現有指令並判斷語言／生態與既有建置流程

-讀取目標 `Dockerfile` 全文，盤點並記錄（作為階段 B 重整與 C doc-funcs 的依據）：
+讀取目標 `Dockerfile` 全文，盤點並記錄（作為階段 B 重整與 C funcs 的依據）：

 - **base image 與階段**：所有 `FROM`（含多階段 `AS <name>`）、目前是單階段或多階段。
 - **可調參數**：既有 `ARG`／`ENV`（版本、路徑、build flag 等）。
 - **安裝步驟**：OS 套件（`apt`／`apk`／`yum` 等）、語言相依（`npm ci`／`pip install`／`go mod download`／`dotnet restore`／`mvn`／`gradle` 等）、相依描述檔（`package*.json`／`requirements.txt`／`go.mod`／`*.csproj`／`pom.xml` 等）。
 - **複製與建置**：`COPY`／`ADD` 來源與落點、`RUN` 建置／編譯／transpile（`npm run build`／`go build`／`dotnet publish`／`mvn package` 等）、`WORKDIR`、`USER`、檔案權限（`chmod`）。
 - **執行設定**：`EXPOSE`、`ENV`、`VOLUME`、`HEALTHCHECK`、`ENTRYPOINT`／`CMD`（這些是對外契約，重整時不得改變語意）。
- **語言／生態**：依 base image 與安裝指令、專案檔分布推斷主要語言（供階段 C doc-funcs 第 0 步沿用，也決定縮小映像時的 runtime 基底選擇）。
+- **語言／生態**：依 base image 與安裝指令、專案檔分布推斷主要語言（供階段 C funcs 第 0 步沿用，也決定縮小映像時的 runtime 基底選擇）。

 輸出偵測結果（目標 Dockerfile 路徑、單／多階段、base image、推斷語言、既有 `ENTRYPOINT`／`CMD`／`EXPOSE`／`ENV`），再進入階段 B。

@@ -69,14 +76,7 @@ argument-hint: "[--project-dir <專案根目錄>] [--dockerfile <Dockerfile 路

 ## 階段 B：整理 Dockerfile 為六步流程

-在**保留建置行為**的前提下，把目標 `Dockerfile` 的指令重整／歸位為**固定六步流程**，並採**多階段建置**縮小最終映像。各步驟對應如下：
-
-1. **參數處理**：把可調參數集中到檔案開頭，以 `ARG` 注入（base image 版本、build flag、路徑等）；`# syntax` 指示與全域 `ARG` 置於最前。
-2. **安裝套件**：先 `COPY` 相依描述檔（如 `package*.json`／`requirements.txt`／`go.mod go.sum`／`*.csproj`）再安裝，以利 layer 快取；OS 套件與語言相依在此安裝，安裝後清理快取（如 `apt-get clean`／`rm -rf /var/lib/apt/lists/*`、`--no-cache`）以縮小該層。
-3. **複製檔案**：`COPY` 其餘原始碼到映像（搭配 `.dockerignore` 排除無關檔案）。
-4. **執行程序**：build／compile／transpile（如 `npm run build`／`go build`／`dotnet publish`）與必要的權限設定（`chmod`）於此執行。
-5. **縮小映像檔**：多階段建置，runtime 階段改用較小的基底（如 `*-slim`／`*-alpine`／`distroless`／`scratch`，依語言與既有 base 對應），只 `COPY --from=<build>` 帶入**執行所必需**的產物（執行檔／發佈輸出／必要相依／靜態資源），避免把 build 階段的快取、原始碼與 dev 工具帶進最終映像；同步搬移 runtime 階段需要的 `ENV`／`WORKDIR`／`EXPOSE`／`USER`。
-6. **設定入口**：`ENTRYPOINT`／`CMD` 置於最後，語意與原檔一致。
+在**保留建置行為**的前提下，把目標 `Dockerfile` 的指令重整／歸位為 `/jsc-shared:spec-dockerfile` 定義的**固定六步流程**（參數處理 → 安裝套件 → 複製檔案 → 執行程序 → 縮小映像檔 → 設定入口），並採**多階段建置**縮小最終映像；各步要點（ARG 集中檔首、相依描述先 `COPY`、同層清理快取、`COPY --from` 逐項明列、搬移 runtime 需要的 `ENV`／`WORKDIR`／`EXPOSE`／`USER`）依該 spec。

 **重整原則（關鍵）**

@@ -84,7 +84,7 @@ argument-hint: "[--project-dir <專案根目錄>] [--dockerfile <Dockerfile 路
 - **已是多階段** → 將既有各階段對應到六步（build 階段涵蓋 1–4、runtime 階段涵蓋 5–6），補齊缺漏的快取最佳化與清理，不破壞既有 `--from` 依賴。
 - **單階段改多階段** → 僅在能可靠判斷 runtime 真正需要哪些產物時才做；無法可靠判斷時，**不臆測**，標 `# 需人工確認：runtime 需要的產物清單` 並回報，退回「最小重排＋補註解」。
 - **多階段不適用** → 若該映像本質上無法受益於多階段（例如純資料映像、最終就是要完整建置環境），保留單階段，於步驟 5 以註解說明「此映像不適用多階段縮小」，其餘步驟仍依序歸位。
- **對外契約不動**：`ENTRYPOINT`／`CMD`／`EXPOSE`／`ENV`／`VOLUME`／`HEALTHCHECK`／`USER` 的語意保持與原檔一致；只可調整位置與分層，不可改變值或刪除。
+- **對外契約不動**：依 `/jsc-shared:spec-dockerfile`（`ENTRYPOINT`／`CMD`／`EXPOSE`／`ENV`／`VOLUME`／`HEALTHCHECK`／`USER` 語意與原檔一致，只可調整位置與分層）。
 - **`.dockerignore`**：若為了「複製檔案」步驟的正確性需要排除建置產物／`node_modules`／`.git`，可建立或補強 `.dockerignore`（僅新增排除項，不刪既有），並回報。

 重整骨架（實際指令、base image、語言依階段 A 偵測結果填入；非 Node 專案請換成對應語言的安裝／建置指令與 runtime 基底）：
@@ -120,22 +120,15 @@ COPY --from=build /app/<artifacts> ./<artifacts>
 ENTRYPOINT [<entrypoint>]
 ```

- **自我檢查**：重整後確認 (1) `ARG` 在使用它的 `FROM` 之後有重新宣告（跨階段 `ARG` 規則）；(2) runtime 階段 `COPY --from` 帶齊執行所需全部產物；(3) `ENTRYPOINT`／`CMD`／`EXPOSE`／`ENV` 與原檔語意一致；(4) 路徑（`WORKDIR`／`COPY` 落點）一致、容器能找到入口。
- 此檔的「用途／更新日期」開頭註解區塊與逐行註解，於階段 C 由 `/jsc:doc-funcs` 的指令檔流程統一補齊／覆寫為標準格式；本階段先確保**建置行為**正確、六步結構清楚即可。
- **建置驗證**：若環境可執行 `docker build`，重整後做一次建置驗證（或至少 `docker build --check`／語法檢查）確認可建置；無法執行時明確說明原因並標註風險（階段 C doc-funcs 第 11 步亦會做語法驗證）。
+- **自我檢查**：依 `/jsc-shared:spec-dockerfile` 的自我檢查清單（跨階段 `ARG` 重新宣告、runtime 帶齊產物、對外契約一致、路徑一致）。
+- 此檔的「用途／更新日期」開頭註解區塊與逐行註解，於階段 C 由 `/jsc-doc:funcs` 的指令檔流程統一補齊／覆寫為標準格式；本階段先確保**建置行為**正確、六步結構清楚即可。
+- **建置驗證**：若環境可執行 `docker build`，重整後做一次建置驗證（或至少 `docker build --check`／語法檢查）確認可建置；無法執行時明確說明原因並標註風險（階段 C funcs 第 11 步亦會做語法驗證）。

 ---

-## 階段 C：完整執行 /jsc:doc-funcs 處理流程
+## 階段 C：完整執行 /jsc-doc:funcs 處理流程

-Dockerfile 六步整理完成後，對**整個專案**完整執行 `/jsc:doc-funcs` 流程，替程式碼與指令檔補文件並重建 README：
-
- 以階段 A1 的專案根目錄為目標，執行 `doc-funcs` skill 的完整流程（判斷語言 → 掃描 function 與指令檔 → 建立 `.docs/` 草稿 → 草稿品質檢查 → 詢問使用者如何實作 → 依選擇寫回 → 保守優化 → 重建 README → 錨點檢查 → 清理草稿 → 建置／語法驗證）。
- doc-funcs 會把本次整理的 `Dockerfile` 視為部署設定檔處理：補齊「用途＋更新日期同一註解區塊」與逐行註解（每行有效指令上方或行尾說明其作用、為何需要、重要參數或副作用）；專案內各 function 補文件註解；其他指令檔（腳本／CI／`docker-compose*` 等）一併處理。
- doc-funcs 的「如何實作」詢問（全部一起／逐個／其他）由使用者於該流程內裁示，本 skill 不代為決定。
- 完成後依 doc-funcs 規範重建根目錄 `README.md`（含台灣時區更新時間、專案列表、功能列表、使用範例）。
-
-> 銜接方式：在本 skill 環境中以 `/jsc:doc-funcs`（或 Skill 工具）啟動 doc-funcs 流程；若該流程需參數，沿用本 skill 的專案根目錄為目標專案。
+Dockerfile 六步整理完成後，以階段 A1 的專案根目錄為目標，依 `/jsc-shared:spec-doc-funcs-handoff` 對**整個專案**完整執行 `/jsc-doc:funcs` 流程（前置可用性檢查、完整流程、由使用者裁示實作方式、重建 README；本次整理的 `Dockerfile` 會被視為部署設定檔補齊標頭與逐行註解）。

 ---

@@ -145,7 +138,7 @@ Dockerfile 六步整理完成後，對**整個專案**完整執行 `/jsc:doc-fun

 - **階段 A**：專案根目錄、目標 `Dockerfile` 路徑、單／多階段、base image、推斷語言、既有 `ENTRYPOINT`／`CMD`／`EXPOSE`／`ENV`。
 - **階段 B**：重整摘要（六步歸位結果、是否改為多階段、縮小映像採用的 runtime 基底）、「需人工確認」清單、是否做過建置／語法驗證；並確認對外契約（`ENTRYPOINT`／`CMD`／`EXPOSE`／`ENV` 等）未被破壞。
- **階段 C**：doc-funcs 流程的處理結果（文件化的 function 與指令檔、重建的 README）。
+- **階段 C**：funcs 流程的處理結果（文件化的 function 與指令檔、重建的 README）。
 - 列出本次新增／變更的檔案與其相對路徑，並提醒使用者於提交前確認 `Dockerfile` 可正確建置、容器能正常啟動。

 ---
@@ -156,6 +149,6 @@ Dockerfile 六步整理完成後，對**整個專案**完整執行 `/jsc:doc-fun

 | 助理 | 呼叫 |
 | --- | --- |
-| Claude Code / Antigravity | `/jsc:code-image`，或 `/jsc:code-image --project-dir ~/work/my-app --dockerfile build/Dockerfile` |
-| Codex | `$code-image`，或 `$code-image --dockerfile docker/Dockerfile`，或用 `/skills` 選單 |
-| OpenCode | 描述需求（如「把這個專案的 Dockerfile 整理成參數處理→安裝套件→複製檔案→執行程序→縮小映像檔→設定入口六步、用多階段建置縮小映像，最後跑 doc-funcs 補文件並重建 README」）自動觸發 |
+| Claude Code / Antigravity | `/jsc-code:image`，或 `/jsc-code:image --project-dir ~/work/my-app --dockerfile build/Dockerfile` |
+| Codex | `$image`，或 `$image --dockerfile docker/Dockerfile`，或用 `/skills` 選單 |
+| OpenCode | 描述需求（如「把這個專案的 Dockerfile 整理成參數處理→安裝套件→複製檔案→執行程序→縮小映像檔→設定入口六步、用多階段建置縮小映像，最後跑 funcs 補文件並重建 README」）自動觸發 |
@@ -1,10 +1,10 @@
 ---
-name: code-issues
-description: 處理一或多個 Gitea 議題的實作流程：先選擇使用 `tea` 或 Gitea REST API + `GITEA_TOKEN`（已選定則跳過），再確認議題所在專案（已知則跳過）與要處理的議題編號（一或多個）；接著讀取議題描述與留言、彙整需求，整理 TODO 列表並依影響範圍由小到大排序，既有 TODO 不足以達成議題需求時補上新 TODO 並附加到議題描述；最後逐項實作 TODO，每完成一項就把進度留言到議題。議題若屬於專案看板且有「分析中／待處理／進行中／待測試／已完成」欄位可調整，依處理進度同步把議題移到對應欄位（彙整需求時「分析中」、TODO 確定「待處理」、開始實作「進行中」、實作完成且驗證通過「待測試」，「已完成」僅在使用者確認時）。全程不建立任何草稿檔，中間成果一律用議題描述或留言保存，並盡量以表格與 Mermaid 圖呈現。當使用者說處理議題、實作議題、依議題 TODO 開工、把議題需求整理成 TODO 並逐項完成、議題進度留言、調整議題看板欄位進度，或提到 code-issues、issue 實作、Gitea 議題處理時觸發。不適用於：把需求拆分成多個新議題（用 doc-issues-analyze）、只同步議題狀態不實作（用 doc-issues-sync）、或與 Gitea 無關的本機 TODO 管理。
+name: issues
+description: 處理一或多個 Gitea 議題的實作流程：先選擇使用 `tea` 或 Gitea REST API + `GITEA_TOKEN`（已選定則跳過），再確認議題所在專案（已知則跳過）與要處理的議題編號（一或多個）；接著讀取議題描述與留言、彙整需求，整理 TODO 列表並依影響範圍由小到大排序，既有 TODO 不足以達成議題需求時補上新 TODO 並附加到議題描述；最後逐項實作 TODO，每完成一項就把進度留言到議題。全程不建立任何草稿檔，中間成果一律用議題描述或留言保存，並盡量以表格與 Mermaid 圖呈現。當使用者說處理議題、實作議題、依議題 TODO 開工、把議題需求整理成 TODO 並逐項完成、議題進度留言，或提到 issues、issue 實作、Gitea 議題處理時觸發。不適用於：把需求拆分成多個新議題（用 issues-analyze）、只同步議題狀態不實作（用 issues-sync）、或與 Gitea 無關的本機 TODO 管理。
 argument-hint: "[--tool <tea|api>] [--repo <owner/repo>] [--issues <編號,以逗號分隔>] [--host <gitea 主機>] [--yes]"
 ---

-# code-issues — 彙整議題 TODO 並逐項實作、留言進度
+# issues — 彙整議題 TODO 並逐項實作、留言進度

 五階段 skill：先做**工具選擇**（`tea` 或 Gitea REST API + `GITEA_TOKEN`），再**確認議題所在專案**與**要處理的議題編號**，接著**讀取議題並彙整 TODO 列表**（依影響範圍小→大排序，缺漏的 TODO 附加到議題描述），最後**逐項實作 TODO**，每完成一項就把進度**留言到議題**。

@@ -16,22 +16,25 @@ argument-hint: "[--tool <tea|api>] [--repo <owner/repo>] [--issues <編號,以
 | D. 彙整 TODO | 讀議題描述＋留言 → 彙整需求 → TODO 依**影響範圍小→大**排序 → 不足以達成需求的缺漏 TODO **附加到議題描述** | — |
 | E. 逐項實作 | 依排序實作每項 TODO → 每完成一項：勾選議題描述 checkbox ＋ **留言進度到議題** | — |

-議題若**屬於專案看板**且看板有「分析中／待處理／進行中／待測試／已完成」欄位可調整，階段 D／E 需依處理進度**同步調整議題所在欄位**（見「議題進度欄位調整」）。
-
 ---

 ## 絕對準則（不可違反）

 - **不建立任何草稿檔**：不寫 `.docs/`、不寫暫存檔、不用本機檔案傳遞中間結果。需求彙整、TODO 排序、實作進度、驗證結果等所有中間成果，一律留在**對話內容**，並透過 `tea` 或 Gitea API **保存到議題描述或議題留言**。唯一例外是階段 E 在議題範圍內對**目標 repo 原始碼**的正常程式修改。
- **盡量使用表格或圖形**：面向使用者的輸出與寫入議題的內容（需求彙整、TODO 列表、進度回報），優先以 **Markdown 表格**與 **Mermaid 圖**（` ```mermaid ` flowchart／stateDiagram，Gitea 可直接渲染）呈現，讓使用者一眼看懂意圖；圖表必須忠實反映議題內容，不得杜撰。
+- **盡量使用表格或圖形**：依 `/jsc-shared:spec-output` — 面向使用者的輸出與寫入議題的內容（需求彙整、TODO 列表、進度回報），優先以 Markdown 表格與 Mermaid 圖呈現，忠實反映議題內容、不得杜撰。

-## 輸出規範（務必遵守）
+## 共用規範（shared plugin，必要前置）

- **語言**：所有面向使用者的輸出與寫入議題的描述／留言，一律使用**繁體中文（台灣用語）**；僅程式碼識別字、檔名、指令、API 路徑等技術標識保留原文，**不可**使用簡體字。
- **編碼無亂碼**：凡輸出或寫入含繁體中文、全形標點、emoji，一律 **UTF-8（不含 BOM）**，不得出現問號方框或錯碼。用 API 送出議題描述／留言時，以 UTF-8 JSON 檔帶入（如 `--data @body.json`），換行必須是實際換行，不可讓議題顯示字面 `\n`。
- **Token 機密保護（極重要）**：gitea token 一律**從環境變數讀取**（`$GITEA_TOKEN`），**絕不**寫死、不 echo、不寫進議題或 log；顯示給使用者的指令／錯誤訊息一律**遮蔽 token**（以 `***` 取代）。檢查時只輸出「已設定／未設定」。
- **不依賴 `jq`**（環境未必安裝）：解析 JSON 用 `tea` 的結構化輸出（`--output csv` / `--fields`），或把原始 JSON 直接交給助理解析，不要 pipe 到 `jq`。
- **自動執行原則**：除非遇到不可忽略的必要決策（工具皆不可用、專案不明、議題編號缺失、TODO 與需求衝突需人工裁示、實作失敗需使用者決策），否則各階段輸出簡短計畫／進度後直接執行到完成；帶 `--yes` 時更不應為一般寫入／留言反覆詢問。階段 A／B／C 的詢問在「可跳過條件」成立時**必須跳過**，不要重複確認已知資訊。
+執行本 skill 前，先以 Skill 工具載入下列共用規範並全程遵守；**任一載入不到（shared plugin 未安裝）時，先詢問使用者是否安裝 shared plugin（`https://gitea.jsc.idv.tw/plugins/shared.git`），使用者不安裝則直接中斷本 skill**，不得只憑下方一行摘要繼續執行：
+
+- `/jsc-shared:spec-output`：繁體中文（台灣用語）、UTF-8（不含 BOM）無亂碼、API body 以 UTF-8 JSON 檔帶入且換行為實際換行。
+- `/jsc-shared:spec-execution`：自動執行原則（必要決策才中斷）、不臆測／需人工確認、已知資訊跳過詢問。
+- `/jsc-shared:spec-gitea`：tea／API 工具選擇與檢查、`GITEA_TOKEN` 機密保護（不 echo、遮蔽）、不依賴 `jq`、API 分頁完整讀取。
+
+本 skill 特有補充：
+
+- **必要決策**（會中斷詢問）：工具皆不可用、專案不明、議題編號缺失、TODO 與需求衝突需人工裁示、實作失敗需使用者決策。
+- 階段 A／B／C 的詢問在「可跳過條件」成立時**必須跳過**，不要重複確認已知資訊。

 ---

@@ -51,21 +54,7 @@ argument-hint: "[--tool <tea|api>] [--repo <owner/repo>] [--issues <編號,以

 **若使用者已透過 `--tool` 或對話明確選定工具，跳過詢問**，只做該工具的可用性驗證。

-1. 檢查 `tea` 是否存在：`command -v tea`；存在則執行 `tea login list` 記錄可用 login 與 host（失敗記錄原因，不中止）。
-2. 檢查 `GITEA_TOKEN` 是否已設定，只輸出「已設定／未設定」，不得輸出 token 內容：
-
-   ```bash
-   [ -n "${GITEA_TOKEN}" ] && echo "GITEA_TOKEN 已設定" || echo "GITEA_TOKEN 未設定"
-   ```
-
-3. 以表格呈現檢查結果後詢問使用者要用哪一種：
-
-   | 選項 | 可選條件 | 後續使用方式 |
-   | --- | --- | --- |
-   | `tea` | `tea` 可執行且目標 host 有對應 login | 命令一律帶 `--login <name> --repo <owner>/<repo>` |
-   | `api` | `GITEA_TOKEN` 已設定 | Gitea REST API + `curl`，標頭 `Authorization: token $GITEA_TOKEN` |
-
-4. 兩種方式都不可用 → 回報缺少 `tea login` 或 `GITEA_TOKEN` 並停止；不要請使用者把 token 貼進對話。
+依 `/jsc-shared:spec-gitea` 的工具選擇流程執行：檢查 `tea`（`command -v tea`、`tea login list`）與 `GITEA_TOKEN`（只輸出「已設定／未設定」）→ 以表格呈現檢查結果後詢問使用者要用 `tea` 或 `api` → 兩種方式都不可用則回報並停止（不要請使用者把 token 貼進對話）。

 ## 階段 B：確認議題所在專案（已知則跳過）

@@ -98,24 +87,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：<原欄位> → <新欄位>」。
-
-| 時機 | 目標欄位 |
-| --- | --- |
-| 階段 D 開始彙整需求時 | 分析中 |
-| 階段 D 完成（TODO 列表確定）、尚未開始實作 | 待處理 |
-| 階段 E 開始實作第一項 TODO | 進行中 |
-| 階段 E 全部 TODO 實作完成且驗證通過 | 待測試 |
-| 議題需求全數達成且使用者確認無需再測試（或明確指示） | 已完成 |
-
- **就近對應**：欄位名稱不完全相同時做語意對應（如「To Do」→ 待處理、「In Progress」→ 進行中、「Done」→ 已完成）；**無法明確對應的欄位不硬移**，回報並略過。
- **保守推進**：預設最多推進到「待測試」（本 skill 不負責測試與關閉議題）；只有使用者明確指示或議題描述明定無需測試時才移到「已完成」。
- **只依實際狀態移動**：欄位只反映真實進度，不得先移欄位再補工作；若實作中途停止（待人工處理），欄位停留在「進行中」並於留言註明原因。
- 議題不屬於任何專案、看板缺少可對應欄位、或 API 不支援移動時 → 回報並略過欄位調整，其餘流程照常。

 ### D2. 彙整需求並盤點既有 TODO

@@ -150,16 +121,16 @@ 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 的 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 完成統計表、變更檔案清單、驗證總結、待人工處理項目（若有）。

-> 本 skill 範圍到「實作＋留言」為止；是否 commit、push、開 PR 或關閉議題**不在本 skill 自動範圍**，由使用者另行指示（可搭配 `code-review-resolve` 的分類提交與 PR 流程）。
+> 本 skill 範圍到「實作＋留言」為止；是否 commit、push、開 PR 或關閉議題**不在本 skill 自動範圍**，由使用者另行指示（可搭配 `review-resolve` 的分類提交與 PR 流程）。

 ---

@@ -172,7 +143,6 @@ argument-hint: "[--tool <tea|api>] [--repo <owner/repo>] [--issues <編號,以
 - **階段 C**：處理的議題編號清單（含標題），是否因已提供而跳過詢問。
 - **階段 D**：每個議題的需求彙整重點、TODO 列表（含影響範圍排序）、新增了幾項 TODO 並是否已附加到議題描述。
 - **階段 E**：每項 TODO 的完成狀態與留言連結（或編號）、驗證結果、待人工處理項目；提醒後續可自行決定 commit／PR／關閉議題。
- **欄位調整**：議題是否屬於專案看板、各議題的欄位移動紀錄（`#n：<原欄位> → <新欄位>`），或略過欄位調整的原因（不屬於專案／無可對應欄位／API 不支援）。

 ---

@@ -182,6 +152,6 @@ argument-hint: "[--tool <tea|api>] [--repo <owner/repo>] [--issues <編號,以

 | 助理 | 呼叫 |
 | --- | --- |
-| Claude Code / Antigravity | `/jsc:code-issues`，或 `/jsc:code-issues --tool api --repo plugins/code --issues 12,15 --yes` |
-| Codex | `$code-issues`，或 `$code-issues --tool tea --repo plugins/code --issues 12`，或用 `/skills` 選單 |
+| Claude Code / Antigravity | `/jsc-code:issues`，或 `/jsc-code:issues --tool api --repo plugins/code --issues 12,15 --yes` |
+| Codex | `$issues`，或 `$issues --tool tea --repo plugins/code --issues 12`，或用 `/skills` 選單 |
 | OpenCode | 描述需求（如「用 GITEA_TOKEN 讀 plugins/code 的 12、15 號議題，整理需求成 TODO 依影響範圍小到大排序、缺的補進議題描述，然後逐項實作、每完成一項留言進度」）自動觸發 |
@@ -1,16 +1,22 @@
 ---
-name: code-nuget
+name: nuget
 description: 將 C# / .NET 專案的 NuGet 套件更新到最新可用版本。當使用者要求更新 NuGet、升級 PackageReference、清理重複套件參考、檢查專案參考中的重複 NuGet、或逐包更新並確認 build 時觸發。流程會依專案分組列出套件，檢查 ProjectReference 上層專案是否已引用相同套件並移除可安全移除的重複參考，接著逐一更新套件版本；每更新或移除一個套件都必須 restore/build 驗證。若更新到最新版本後編譯失敗，改由目前版本之後的最小可用版本逐版升級，直到遇到第一個編譯失敗版本，保留最後一個可編譯版本。不適用於：非 .NET 專案、只想查詢套件清單不更新、或只要人工建議不修改檔案。
 argument-hint: "[<solution-or-project>] [--include-prerelease] [--no-dedupe] [--build <command>] [--yes]"
 ---

-# code-nuget — 更新 C# 專案 NuGet 套件
+# nuget — 更新 C# 專案 NuGet 套件

 把 C# / .NET repo 內的 NuGet 套件依專案盤點、清理可安全移除的重複參考，然後逐一更新到最新可用版本。每個套件異動後都要驗證專案可以正常編譯；若最新版本失敗，改從目前版本之後的最小可用版本逐版升級，直到第一個編譯失敗版本為止，保留最後一個可編譯版本並記錄失敗點。

-## 輸出規範
+## 共用規範（shared plugin，必要前置）
+
+執行本 skill 前，先以 Skill 工具載入下列共用規範並全程遵守；**任一載入不到（shared plugin 未安裝）時，先詢問使用者是否安裝 shared plugin（`https://gitea.jsc.idv.tw/plugins/shared.git`），使用者不安裝則直接中斷本 skill**，不得只憑下方一行摘要繼續執行：
+
+- `/jsc-shared:spec-output`：繁體中文（台灣用語）、UTF-8（不含 BOM）無亂碼（套件 id、檔名、指令、版本號保留原文）。
+- `/jsc-shared:spec-execution`：自動執行原則（必要決策才中斷）、不臆測／需人工確認。
+
+## 輸出規範（本 skill 特有）

- 所有面向使用者的輸出一律使用繁體中文（台灣用語）；套件 id、檔名、指令、版本號保留原文。
 - 修改前先輸出簡短執行計畫；除非使用者要求確認、遇到多個 solution 無法判斷、或編譯失敗需要取捨，否則依計畫執行。
 - 每個套件都要留下結果：已更新 / 已降階到可編譯版本 / 已略過 / 已回復 / 已移除重複參考，以及對應版本與驗證指令。
 - 不主動 commit、push 或開 PR；使用者明確要求時才做。
@@ -151,6 +157,6 @@ argument-hint: "[<solution-or-project>] [--include-prerelease] [--no-dedupe] [--

 | 助理 | 呼叫 |
 | --- | --- |
-| Claude Code / Antigravity | `/jsc:code-nuget`，或 `/jsc:code-nuget MySolution.sln --include-prerelease` |
-| Codex | `$code-nuget`，或 `$code-nuget src/App/App.csproj --build "dotnet build App.sln -c Release"` |
+| Claude Code / Antigravity | `/jsc-code:nuget`，或 `/jsc-code:nuget MySolution.sln --include-prerelease` |
+| Codex | `$nuget`，或 `$nuget src/App/App.csproj --build "dotnet build App.sln -c Release"` |
 | OpenCode | 描述需求（如「把這個 .NET solution 的 NuGet 都更新到最新，先清掉 ProjectReference 已提供的重複套件，每更新一包就 build」）自動觸發 |
@@ -1,42 +1,46 @@
 ---
-name: code-review-resolve
-description: 解決 `.gitea/ai-review/findings.json` 的 AI review findings，先同步 git（fetch → 檢查目前分支的遠端分支是否存在；存在則留在目前分支 pull 更新，不存在則切換到 develop／master 後 pull 更新；只有來源分支與 PR 目標分支相同時才建立新的工作分支；必要時嘗試解衝突），再依嚴重度逐條修復；可判斷為誤報者寫入 `.gitea/ai-review/exclusions.json`，已解決或已登記為誤報的 finding 可自 findings 移除；接著可將工作區變更依 conventional commit 類型分類提交、push 當前分支，並透過 Gitea API 對指定目標分支開 PR。當使用者說解決 findings、處理 AI review 問題、修掉 `.gitea/ai-review` 問題、依嚴重度修復後分類提交，或要分類 commit 並 push/開 PR 時觸發。不適用於：產生 findings、單純 code review 不修改、只保存裁決紀錄，或只要不分類的單一 commit。
-argument-hint: "[--findings <findings.json 路徑>] [--target <目標分支>] [--pr-desc <full|simple|自訂文字>] [--no-commit] [--no-pr] [--yes]"
+name: review-resolve
+description: 解決新版 AI Code Review 的 findings——一律讀取專案內 `.gitea/ai-review/findings/` 目錄下的 wrapper 物件 JSON（含 `findings`/`excluded` 陣列、中文 severity）與 `findings.json`，並可額外用 `--issue`（無/單選/多選/全部）從 Gitea 議題（建問題模式）解析嚴重問題留言為 findings，兩來源合併去重後逐條解決；先同步 git（fetch → 檢查目前分支的遠端分支是否存在；存在則留在目前分支 pull 更新，不存在則切換到 develop／master 後 pull 更新；只有來源分支與 PR 目標分支相同時才建立新的工作分支；必要時嘗試解衝突），再依嚴重度（嚴重/警告/建議）逐條修復；可判斷為誤報者寫入 `.gitea/ai-review/exclusions.json`，已解決或已登記為誤報的 finding 逐檔就地自來源 wrapper 移除；處理過的議題於留言進度、把只來自議題的待人工處理問題寫回 findings 目錄後關閉；接著可將工作區變更依 conventional commit 類型分類提交、push 當前分支，並透過 Gitea API 對指定目標分支開 PR。當使用者說解決 findings、處理 AI review 問題、依議題編號修 code review 問題、修掉 `.gitea/ai-review` 問題、依嚴重度修復後分類提交，或要分類 commit 並 push/開 PR 時觸發。不適用於：產生 findings、單純 code review 不修改、只保存裁決紀錄，或只要不分類的單一 commit。
+argument-hint: "[--issue <編號|編號清單|all>] [--findings <findings 檔或目錄路徑>] [--target <目標分支>] [--pr-desc <full|simple|自訂文字>] [--no-commit] [--no-pr] [--yes]"
 ---

-# code-review-resolve — 解決 AI review findings、分類提交、push 並開 PR
+# review-resolve — 解決 AI review findings、分類提交、push 並開 PR

-五階段 skill：先執行 **git 同步**（`git fetch` → 確認目前分支的遠端分支是否存在；存在則留在目前分支 `git pull` 更新，不存在則切換到 `develop`，再退而 `master` 後 `git pull` 更新；只有來源分支與 PR 目標分支相同時才建立新的工作分支；必要時告知並嘗試解衝突），再**逐條處理** `.gitea/ai-review/findings.json` 裡的問題；成立問題修復後自 findings 移除，可判斷為誤報者寫入 `.gitea/ai-review/exclusions.json` 後也可自 findings 移除，接著**必須盤點並處理工作區的所有變更**，再依 conventional commit 類型分門別類 commit，然後 **push 當前分支**，最後**透過 Gitea API 發 PR**。
+五階段 skill：先執行 **git 同步**（`git fetch` → 確認目前分支的遠端分支是否存在；存在則留在目前分支 `git pull` 更新，不存在則切換到 `develop`，再退而 `master` 後 `git pull` 更新；只有來源分支與 PR 目標分支相同時才建立新的工作分支；必要時告知並嘗試解衝突），再**蒐集問題來源**——**一律讀** `.gitea/ai-review/findings/` 目錄下的 wrapper 物件 JSON（取其 `findings` 陣列）與 `findings.json`，並依 `--issue`（無／單選／多選／全部）**額外**從 Gitea 議題留言解析嚴重問題，兩來源**合併去重**後逐條處理；成立問題修復後自來源 wrapper 逐檔就地移除，可判斷為誤報者寫入 `.gitea/ai-review/exclusions.json` 後也可移除（處理過的議題於留言進度、把只來自議題的待人工處理問題寫回 findings 目錄後關閉），接著**必須盤點並處理工作區的所有變更**，再依 conventional commit 類型分門別類 commit，然後 **push 當前分支**，最後**透過 Gitea API 發 PR**。

 | 階段 | 動作 |
 | --- | --- |
 | A. Git 同步 | `git fetch` → 當前分支不在遠端則切換 develop（再退而 master）→ `git pull`／必要時解衝突 → 只有來源分支與 PR 目標分支相同時才建立新工作分支 |
-| B. 解決問題 | 讀 `findings.json` / `exclusions.json` → 依等級 🔴→🟠→🟡→🔵 逐條修復或判斷誤報 → 已解決者自 `findings.json` 移除，誤報寫入 `exclusions.json` 後也可移除；**無待處理問題則跳到階段 D** |
+| B. 解決問題 | 一律讀 `.gitea/ai-review/findings/*.json`＋`findings.json`（wrapper，取 `findings`），依 `--issue`（無/單選/多選/全部）加讀議題留言 → 合併去重 → 依等級 🔴嚴重→🟠警告→🔵建議 逐條修復或判斷誤報 → 已解決者逐檔就地自來源 wrapper 移除，誤報寫入 `exclusions.json`；處理過的議題回寫（留言＋只來自議題的待人工寫回 findings 後關閉）；**無待處理問題則跳到階段 D** |
 | C. 分類提交 | 必須分析並涵蓋工作區所有變更（已修改／新增／刪除／改名，含已暫存與未暫存、未追蹤檔、findings/exclusions 更新）→ 依 feat/fix/docs/style/refactor/perf/test/chore/revert 分組 → 各組一個 commit |
 | D. Push 當前分支 | 認證管理器 → 失敗改 token → 再失敗詢問使用者；**無 commit 可 push 則跳到階段 E** |
 | E. 發出 PR | 確定目標分支（不明必問）→ 選 PR 描述（完整／簡單／自訂）→ token 呼叫 Gitea API 建 PR → 通知並清除內文 |

 ---

-## 輸出規範（務必遵守）
+## 共用規範（shared plugin，必要前置）

- **語言**：所有面向使用者的輸出（修復清單、提交計畫、總結、反問）與 **commit 訊息** 一律使用**繁體中文（台灣用語）**；
-  僅程式碼識別字、檔名、git 指令、conventional commit 的 `type`（`feat`/`fix`…）等技術標識保留原文，**不可**使用簡體字。
- **編碼無亂碼（含繁中、全形標點、emoji）**：凡輸出或寫入只要含繁體中文，一律 **UTF-8（不含 BOM）**，不得出現問號方框（）或錯碼。涵蓋：更新後的 `findings.json` / `exclusions.json`、**commit 訊息**、**PR 標題／描述**、終端訊息，與等級 emoji 🔴🟠🟡🔵。實作要點：
-  - **寫檔**：優先用助理的檔案寫入工具（預設 UTF-8 無 BOM）。若改用 shell 寫檔，**避免 PowerShell 的 `>`／`Out-File`**（預設可能寫成 UTF-16 或加 BOM）；需要時用 `Set-Content -Encoding utf8NoBOM`，或在 bash 用 `printf`／heredoc。
-  - **commit 訊息**：用 `git commit -m` 直接帶字串，或寫進 UTF-8 無 BOM 的檔案再 `git commit -F <file>`；確保 `git config i18n.commitEncoding utf-8`。
-  - **PR body**：以 UTF-8 JSON 經 API 送出（如 `--data @body.json`，該檔為 UTF-8 無 BOM）。
-  - **送出前自我檢查**：產生含繁中的檔案／訊息後，回頭確認沒有亂碼或 BOM 再提交／送出。
- **自動執行原則**：除非使用者明確要求先確認，或遇到不可忽略的必要決策（例如目標分支缺失、pull 策略不明、無法安全解衝突、需人工判斷的設計取捨、push 憑證皆失敗），否則各階段只需輸出簡短計畫／進度後直接執行到完成；不要為一般修復、寫檔、分類 commit、push 或開 PR 反覆詢問。
- **Token 機密保護（極重要）**：gitea token 一律**從環境變數讀取**（如 `$GITEA_TOKEN`），**絕不**寫死在 skill、commit、PR 內文或任何輸出；**不可** echo 含 token 的指令或 URL、不可寫進 log。所有顯示給使用者的指令／錯誤訊息都要**遮蔽 token**（如以 `***` 取代）。階段 E 完成後依規範清除對話內文（見 E6）。
+執行本 skill 前，先以 Skill 工具載入下列共用規範並全程遵守；**任一載入不到（shared plugin 未安裝）時，先詢問使用者是否安裝 shared plugin（`https://gitea.jsc.idv.tw/plugins/shared.git`），使用者不安裝則直接中斷本 skill**，不得只憑下方一行摘要繼續執行：
+
+- `/jsc-shared:spec-output`：繁體中文（台灣用語）、UTF-8（不含 BOM）無亂碼（含 commit 訊息、PR 標題／描述、寫檔／API body 實作要點與送出前自我檢查）。
+- `/jsc-shared:spec-execution`：自動執行原則（必要決策才中斷）、不臆測／需人工確認。
+- `/jsc-shared:spec-gitea`：`GITEA_TOKEN` 機密保護（不 echo、遮蔽 `***`）、API body 以 UTF-8 JSON 檔帶入。
+- `/jsc-shared:spec-git-safety`：不破壞既有工作、develop → master 後備、保守解衝突、新分支不覆蓋既有分支。
+
+本 skill 特有補充：
+
+- **必要決策**（會中斷詢問）：目標分支缺失、pull 策略不明、無法安全解衝突、需人工判斷的設計取捨、push 憑證皆失敗。
+- 涵蓋範圍：更新後的 `findings/*.json`（wrapper）/ `exclusions.json`、議題留言、commit 訊息、PR 標題／描述、終端訊息，與等級 emoji 🔴🟠🔵。
+- 階段 E 完成後依規範清除對話內文（見 E6）。

 ---

 ## 參數

-格式：`[--findings <路徑>] [--target <目標分支>] [--pr-desc <full|simple|自訂文字>] [--no-commit] [--no-pr] [--yes]`
+格式：`[--issue <編號|編號清單|all>] [--findings <路徑>] [--target <目標分支>] [--pr-desc <full|simple|自訂文字>] [--no-commit] [--no-pr] [--yes]`

- `--findings <路徑>`：findings 檔路徑。**省略時預設 `.gitea/ai-review/findings.json`**（相對於工作目錄根）。
+- `--issue <無 / 編號 / 編號清單 / all>`：**額外**從 Gitea 議題（對應 code-review 建問題模式）撈問題，支援四種——**無**（省略此參數，不讀議題）、**單選**（`--issue 12`）、**多選**（`--issue 12,15,20` 逗號分隔）、**全部**（`--issue all`，讀 repo 內所有 open 議題）。帶此參數時走 B1b 解析議題嚴重問題留言為 findings；修復後於 B6 對每個處理過的議題留言進度、把「只來自議題」的待人工處理問題寫回 `findings/` 目錄後關閉該議題。需要 `GITEA_TOKEN` 與可解析的 `origin` repo 座標。**注意：不論有無此參數，findings 檔一律照讀（見 `--findings`），議題只是額外來源。**
+- `--findings <路徑>`：findings 檔來源路徑。**不論是否帶 `--issue`，都一律讀取**；省略時預設讀目錄 `.gitea/ai-review/findings/` 下所有 `*.json` **與**（若存在）單一檔 `.gitea/ai-review/findings.json`（每個檔為新版 wrapper 物件，取其 `findings` 陣列）（相對於工作目錄根）。指定路徑時：目錄則讀該目錄所有 `*.json`；單一檔則讀該檔（同為 wrapper 物件）。findings 檔與 `--issue` 議題的問題會在 B1c 合併去重後一起處理。
 - `--target <目標分支>`：PR 的目標分支。**省略時必須詢問使用者，不可猜測**；若需要避免把同名來源分支誤推到目標分支，可能會在階段 D 先詢問並於階段 E 沿用。
 - `--pr-desc <full|simple|自訂文字>`：PR 描述形式。`full`＝完整版（重新分析 diff 總結）、`simple`＝簡單版（逐條列 commit 訊息）、或直接給自訂文字；省略時預設 `full`，不要為描述形式中斷詢問。
 - `--no-commit`：只做階段 A/B（git 同步 + 修復 + 更新 findings/exclusions），**不**執行階段 C/D/E（不提交、不推送、不開 PR）。
@@ -132,103 +136,190 @@ source_branch="$(git rev-parse --abbrev-ref HEAD)"

 ### A6. 必要時嘗試解衝突

-當 `git pull` 後出現衝突：
-
-1. 用 `git status --porcelain` 與衝突標記定位衝突檔。
-2. 讀取衝突檔脈絡，依專案現有行為與遠端變更做最小合理整合。
-3. 可安全解決的衝突：編輯檔案移除衝突標記，執行 `git add -- <檔案...>` 標記已解決。
-4. 無法安全判斷的衝突：停止處理，列出檔案、衝突原因與需要使用者決策的點；不要硬選任一邊。
-5. 全部衝突解完後，依 git 當前狀態完成 merge / rebase 的必要步驟，確認 `git status --porcelain` 沒有未解衝突，再回到 A5 判斷是否需要建立新工作分支。
+當 `git pull` 後出現衝突，依 `/jsc-shared:spec-git-safety` 的保守解衝突流程處理（定位衝突檔 → 最小合理整合 → 可安全解決者 `git add` 標記、無法安全判斷者停止並列出決策點）；全部衝突解完後，依 git 當前狀態完成 merge / rebase 的必要步驟，確認 `git status --porcelain` 沒有未解衝突，再回到 A5 判斷是否需要建立新工作分支。

 ---

-## 階段 B：依嚴重等級逐條解決問題或登記誤報
+## 階段 B：蒐集問題（findings 檔 ＋ Gitea 議題）合併去重、依嚴重度逐條解決或登記誤報

-### B1. 讀取 findings 與 exclusions
+新版 AI Code Review 的產出格式（對齊 `https://gitea.jsc.idv.tw/actions/code-review`，`src/index.js` / `src/lib/review.js`）：

-讀 `--findings` 指定（或預設 `.gitea/ai-review/findings.json`）的檔案，內容為 **top-level JSON 陣列**，每筆是一個問題物件。常見欄位（不同產生器命名略有差異，需容錯對應）：
+- **findings**：每次 review 在目錄 `.gitea/ai-review/findings/` 產生一個**新檔**（檔名為台北時間戳，如 `2026-07-20-14:30:15.json`），內容是**頂層物件（wrapper）**，不是陣列：

-| 語義 | 可能欄位名 |
+  ```json
+  {
+    "generatedAt": "<台北時間>",
+    "commitSha": "<head sha>",
+    "prNumber": 9,
+    "tool": { "name": "...", "version": "...", "model": "..." },
+    "findings": [ { "<finding>": "..." } ],
+    "excluded":  [ { "<finding>": "..." } ]
+  }
+  ```
+
+  每個 `<finding>` 欄位：
+
+  | 欄位 | 語義 |
  | --- | --- |
-| 嚴重等級 | `severity` / `level` / `等級` |
-| 檔案位置 | `file` / `path` / `檔案位置` |
-| 所在行數 | `line` / `lines` / `所在行數` |
-| 問題標題 | `title` / `message` / `問題` |
-| 問題描述 | `description` / `detail` / `描述` |
-| 修正建議 | `suggestion` / `fix` / `建議` |
+  | `id` | 流水號（`F001`…） |
+  | `reviewer` | 審查角色名稱 |
+  | `focus` | 審查面向代碼（如 `logic`） |
+  | `badge` | 角色徽章（emoji，可空） |
+  | `severity` | 嚴重等級（**中文**：`嚴重` / `警告` / `建議`） |
+  | `file` | 問題所在檔案（repo 相對路徑） |
+  | `startLine` / `endLine` | 問題起訖行號 |
+  | `problem` | 問題描述 |
+  | `suggestion` | 修改建議 |
+  | `suggestedCode` | 建議寫法（程式碼，可空） |

-`findings.json` 與 `.gitea/ai-review/exclusions.json` 的 canonical 格式須對齊 `https://gitea.jsc.idv.tw/actions/code-review`：
-
- 兩者都使用 **top-level JSON array**，不得包在 `{ "findings": [...] }`、`{ "exclusions": [...] }` 或 `{ "excluded_findings": [...] }`。
- `findings.json` 每筆至少保留 action 使用的必要欄位：
+- **exclusions**：固定 `.gitea/ai-review/exclusions.json`，**頂層陣列**，每筆：

  ```json
  {
-    "level": "critical|warning|info",
-    "role": "審查角色名稱",
-    "location": "檔案路徑:行號 或 檔案路徑",
-    "suggestion": "繁體中文（台灣用語）的具體修改建議"
+    "addedAt": "<台北時間>",
+    "prNumber": 9,
+    "reviewer": "<審查角色>",
+    "severity": "嚴重|警告|建議",
+    "file": "<檔案路徑>",
+    "startLine": 10,
+    "endLine": 12,
+    "problem": "<問題描述>",
+    "reason": "<判定誤報／重複的理由>"
  }
  ```

- `exclusions.json` 每筆以最小且穩定的排除條目為主，優先保留原始問題文字、語言與語意；建議欄位：
+- **建問題模式**：某些 review 不寫 findings 檔，改開 Gitea 議題、把嚴重問題**逐則發成議題留言**（見 B1）。

-  ```json
-  {
-    "location": "檔案路徑:行號 或 檔案路徑",
-    "role": "審查角色名稱",
-    "original_finding": "原 finding 的 suggestion 或完整問題文字",
-    "reason": "判斷為誤報或不適用的原因"
-  }
+> 本 skill 只支援上述**新版格式**；讀到非 wrapper 物件（例如舊版頂層陣列 findings）時，回報格式不符並停止，不臆測欄位。
+
+### B1. 蒐集問題來源並合併去重
+
+**不論是否處理議題，都必須先讀取專案內的 findings 檔**；若有指定議題，再加上議題來源，兩者合併去重後才進入 B3。
+
+**B1a. 讀 findings 檔（一律執行）**
+
+- 讀目錄 `.gitea/ai-review/findings/` 下所有 `*.json`（含子目錄、依檔名排序）**與**（若存在）單一檔 `.gitea/ai-review/findings.json`；每個檔皆為上述 **wrapper 物件**，取其 `findings` 陣列。
+- 指定 `--findings <路徑>` 時改讀該路徑（目錄則讀其所有 `*.json`；單一檔則讀該檔），仍須為 wrapper 物件。
+- 逐筆記住各 finding 的**來源檔路徑與所屬 wrapper**，供 B5 逐檔就地寫回；此步不得更動任何來源檔。
+- JSON 解析失敗或非 wrapper 物件 → 回報該檔路徑並停止，不臆測、不亂改檔。
+
+**B1b. 讀議題（依 `--issue` 選擇）**
+
+`--issue` 支援四種形式：
+
+| 形式 | 寫法 | 行為 |
+| --- | --- | --- |
+| 無 | 省略 `--issue` | 不讀議題，只用 findings 檔 |
+| 單選 | `--issue 12` | 讀議題 #12 |
+| 多選 | `--issue 12,15,20` | 讀多個議題（逗號分隔） |
+| 全部 | `--issue all` | 讀 repo 內**所有 open 議題** |
+
+1. 解析 repo 座標（同 E3），token 由 `GITEA_TOKEN` 提供。
+2. `all` 時先取所有 open 議題（分頁全取）：`GET /repos/<owner>/<repo>/issues?state=open&type=issues`。
+3. 對每個選定議題讀本文與全部留言（分頁全取；輸出遮蔽 token）：
+
+   ```bash
+   curl -sS -H "Authorization: token ${GITEA_TOKEN}" \
+     "https://<host>/api/v1/repos/<owner>/<repo>/issues/<編號>"
+   curl -sS -H "Authorization: token ${GITEA_TOKEN}" \
+     "https://<host>/api/v1/repos/<owner>/<repo>/issues/<編號>/comments"
   ```

-  若既有 exclusions 使用 `suggestion`、`title`、`note` 等欄位，讀取時可容錯；寫回時仍要維持 top-level array，並盡量採用上述 canonical 欄位。
+4. 解析每則符合「嚴重問題留言」格式（action `severeCommentBody` 產出）的留言為一條 finding：

- **檔案不存在、內容為 `[]` 或空白** → 視為「無問題待解決」，輸出告知。`--no-commit` 時就此結束；否則**跳過階段 C 直接進入階段 D**（無待處理問題代表本 skill 未產生需要分類提交的修復變更）。
- **JSON 解析失敗** → 回報錯誤與檔案路徑並停止，不臆測內容、不亂改檔。
- `exclusions.json` 不存在時視為空陣列，必要時建立 `.gitea/ai-review/exclusions.json` 並寫入 `[]` 或新增後的排除項目。
- 若 `exclusions.json` 是舊 wrapper 格式（例如 `{ "exclusions": [...] }` 或 `{ "excluded_findings": [...] }`），先正規化為 top-level array 再寫回。
+   ```
+   ### <emoji> <severity>｜<badge> <reviewer>
+   **位置**：`<file>` 第 <startLine>–<endLine> 行
+   **問題**
+   <problem>
+   **修改建議**
+   <suggestion>
+   **建議寫法**（可選）
+   <suggestedCode>
+   ```

-### B2. 依嚴重等級排序
+   映射為 `{ reviewer, severity, file, startLine, endLine, problem, suggestion, suggestedCode }`，並記住**來源議題編號與留言 id**（供 B6 回寫）；議題標題／描述作為整體背景脈絡納入判斷。
+5. 某議題解析不到任何嚴重問題留言 → 記錄並略過該議題（`all`／多選時不因單一議題無問題而中斷整批），不臆測。

-把所有 finding 依等級由高到低排序：**🔴 嚴重 → 🟠 高 → 🟡 中 → 🔵 低**。
-canonical 等級為 `critical` / `warning` / `info`；其他寫法容錯對應：`critical`/`blocker`→🔴、`high`/`major`/`warning`→🟠、`medium`/`moderate`→🟡、`low`/`minor`/`info`→🔵；無法辨識的等級**排在最後**並標註「等級未知」。寫回 `findings.json` 時盡量保留原欄位值，除非需要修正成 canonical 格式。
+**B1c. 合併去重**

-### B3. 逐條處理（高等級先）
+- 把 B1a（findings 檔）與 B1b（議題）的所有 finding 合併成單一待處理清單。
+- **去重鍵**：`file` + `startLine` + `endLine` + `reviewer` + `problem`（正規化空白後比對；行號缺失時以 `file` ＋ `reviewer` ＋ `problem` 為準）。
+- 重複的 finding **合併其來源清單**（同一問題可能同時來自某 findings 檔與某議題），只列入一次；後續解決後要**同時回寫所有來源**（B5 移除該 finding 檔項目、B6 計入相關議題的關閉與留言）。
+- 合併去重後即為待處理 finding 清單，進入 B3 排序。
+
+**無任何 finding**（findings 檔皆空／不存在，且未選議題或選到的議題都無問題）→ 視為「無問題待解決」，輸出告知。`--no-commit` 時就此結束；否則**跳過階段 C 直接進入階段 D**。
+
+### B2. 讀取 exclusions
+
+`.gitea/ai-review/exclusions.json` 不存在時視為空陣列（頂層陣列）；解析失敗或非陣列時回報，並在本次不寫入誤報（避免破壞既有內容、需人工確認）。
+
+### B3. 依嚴重等級排序
+
+把所有 finding 依等級由高到低排序：**🔴 嚴重 → 🟠 警告 → 🔵 建議**。
+`severity` 為中文 `嚴重` / `警告` / `建議`；容錯對應：`嚴重`/`critical`/`high`/`blocker`→🔴、`警告`/`warning`/`major`→🟠、`建議`/`info`/`low`/`minor`→🔵；無法辨識者**排在最後**並標「等級未知」。排序後先處理高等級。
+
+### B4. 逐條處理（高等級先）

 輸出一張「處理計畫」表，除非使用者要求確認或遇到必要決策，否則**依排序由上而下逐條**處理：

-| # | 等級 | 問題 | 檔案位置 | 行數 | 處理方式 |
-| --- | --- | --- | --- | --- | --- |
+| # | 等級 | 審查員 | 問題 | 檔案 | 行數 | 處理方式 |
+| --- | --- | --- | --- | --- | --- | --- |

 對每一條 finding：

-1. 讀取對應檔案與其脈絡（依 `file` / `line`）。
-2. 先判斷是否為誤報或不適用：例如程式碼脈絡證明指控不成立、已有等價防護、問題來自 action 已知排除規則、CI/CD 必要權限、或 finding 對非本次變更做不合理要求。
-3. **可判斷為誤報** → 不改程式碼；將排除條目 append 到 `.gitea/ai-review/exclusions.json`，保留原始 finding 的語言與語意，避免過度改寫；若已有等價 exclusion（同檔案路徑、角色、原始文字或 suggestion 高度相似）則不要重複新增。
-4. **確認為真問題且可安全修復** → 依 `suggestion`／`description` 在程式碼中實作最小合理修正；建議含糊或與現況不符時，依原始碼脈絡做最小且合理的修正。
+1. 讀取對應檔案與其脈絡（依 `file` 與 `startLine`–`endLine`）。
+2. 先判斷是否為誤報或不適用：例如程式碼脈絡證明指控不成立、已有等價防護、命中 `exclusions.json` 已知排除、CI/CD 必要權限、或 finding 對非本次變更做不合理要求。
+3. **可判斷為誤報** → 不改程式碼；將排除條目 append 到 `.gitea/ai-review/exclusions.json`（新版欄位，見 B5），保留原始問題文字與語意；若已有等價 exclusion（同 `file`＋`reviewer`＋`problem` 高度相似）則不重複新增。
+4. **確認為真問題且可安全修復** → 依 `suggestion`／`suggestedCode`／`problem` 在程式碼中實作最小合理修正；建議含糊或與現況不符時，依原始碼脈絡做最小且合理的修正。
 5. **無法安全自動修復或無法確認真偽**（例如需求不明、牽涉設計取捨、檔案不存在）→ **不硬改**，標記為「待人工處理」並記錄原因，繼續下一條。
-6. 逐條完成後，記錄該條結果（✅ 已解決 / 🚫 誤報已寫入 exclusions / ⏭️ 待人工處理 + 原因）。
+6. 逐條完成後，記錄該條結果（✅ 已解決 / 🚫 誤報已寫入 exclusions / ⏭️ 待人工處理 + 原因），並保留該 finding 依 B1c 記錄的**所有來源**（findings 檔路徑 / 議題編號＋留言 id）供 B5／B6 回寫。

 > 一次只處理一條、修完再處理下一條，避免互相干擾；同檔多條問題可合併讀取但仍逐條套用修正。

-### B4. 更新 findings.json 與 exclusions.json
+### B5. 更新 findings 檔與 exclusions.json

-**所有條目處理完畢後**，依結果更新 `findings.json` 與 `exclusions.json`：
+**所有條目處理完畢後**，依每條 finding 於 B1c 記錄的來源回寫。**只來自議題、無任何 findings 檔來源的 finding 不在本節處理**（交由 B6 回寫議題與新建 findings 檔）；有 findings 檔來源者（含同時來自議題與檔案的）依下列更新其來源檔：

- **只有確認已解決，或已確認為誤報並成功寫入 `exclusions.json` 的 finding，才可從 `findings.json` 移除**。
- 誤報移出 `findings.json` 前，必須先確認 `exclusions.json` 已存在、格式合法、且該排除條目已寫入或已有等價條目；若 exclusions 寫入失敗，該 finding 必須保留。
- 待人工處理、無法確認真偽、或修復未驗證成功的 finding 必須保留在 `findings.json`。
- 寫回 `findings.json` 時只保留尚未解決且尚未登記為誤報的 finding；已解決或已登記為誤報的 finding 逐項移除，不需要等待其他問題也處理完。
- 如果移除後沒有任何 finding 需要保留，將 `findings.json` 寫成空陣列：
+- **只有確認已解決，或已確認為誤報並成功寫入 `exclusions.json` 的 finding，才可從來源 findings 檔移除**；待人工處理、無法確認真偽、修復未驗證成功者一律保留於來源檔。
+- **逐檔就地更新（wrapper 物件）**：依 B1a 記錄的來源檔，把該檔 `findings` 陣列中要保留的 finding 留下、其餘移除，**只改該檔的 `findings` 陣列**；wrapper 其他欄位（`generatedAt`、`commitSha`、`prNumber`、`tool`、`excluded`）原樣保留，**不得**把多個來源檔合併成單一檔。某檔 `findings` 全數已解決／誤報時，把該檔的 `findings` 寫成 `[]`（保留檔案與 wrapper、維持目錄結構，不刪檔）。
+- 保留的 finding 維持其原 wrapper 內欄位（`id`、`reviewer`、`severity`、`file`、`startLine`、`endLine`、`problem`、`suggestion`、`suggestedCode`…）與排序。
+- **誤報一律 append 到 `.gitea/ai-review/exclusions.json`（頂層陣列）**，欄位對齊新版：`addedAt`（當下台北時間，`date` 取得）、`prNumber`（已知則帶、未知可省略）、`reviewer`、`severity`、`file`、`startLine`、`endLine`、`problem`、`reason`（誤報理由）；append 後去重。
+- 誤報移出 findings 前，必須先確認 `exclusions.json` 已成功寫入該條或已有等價條目；寫入失敗則該 finding 保留於來源檔。
+- 所有寫檔以 UTF-8（不含 BOM）寫入，結尾保留一個換行。
+
+### B6. 議題收尾：回寫並關閉每個處理過的議題（B1b 有讀到議題時）
+
+**對每個處理過的議題**（單選／多選／全部各自處理），依該議題涵蓋的 finding 結果收尾：
+
+1. **在該議題留言回報進度**（Gitea API `POST /repos/<owner>/<repo>/issues/<編號>/comments`，body 以 UTF-8 JSON 檔帶入、token 不 echo）：以表格逐條列出該議題各問題結果（✅ 已解決 / 🚫 誤報已寫入 exclusions / ⏭️ 待人工處理 + 原因）；同時來自 findings 檔的問題，一併註明已於 B5 更新來源檔。
+2. **把「待人工處理」且只來自議題的問題寫回 findings**：收集所有 ⏭️ 待人工處理 且**沒有任何 findings 檔來源**的問題（已在 findings 檔的靠 B5 保留，不重複寫），寫成一個**新的 wrapper 物件檔**到目錄 `.gitea/ai-review/findings/`（檔名用台北時間戳，如 `2026-07-20-14:30:15.json`），格式同本階段開頭的 findings wrapper：

   ```json
-[]
+   {
+     "generatedAt": "<台北時間>",
+     "commitSha": "<目前 HEAD sha>",
+     "prNumber": null,
+     "tool": { "name": "review-resolve", "version": "<版本或工具預設>", "model": "<模型或工具預設>" },
+     "findings": [ { "id": "F001", "reviewer": "...", "severity": "嚴重|警告|建議", "file": "...", "startLine": 1, "endLine": 1, "problem": "...", "suggestion": "...", "suggestedCode": "" } ],
+     "excluded": []
+   }
   ```

- 寫回 `findings.json` 時保留未解決 finding 的 canonical 欄位（`level`、`role`、`location`、`suggestion`）與有用原欄位；依嚴重度排序。
- 寫回 `exclusions.json` 時使用 top-level JSON array；新增項目 append 後依既有順序保留並去重。
- 兩個檔案都以 UTF-8（不含 BOM）寫入，結尾保留一個換行。
+   - `findings` 帶入這些待人工處理問題（欄位沿用 B1b 從議題留言解析出的欄位，並補流水號 `id`）；`excluded` 固定為 `[]`。多個議題可合寫成同一個檔。
+   - 沒有「只來自議題」的待人工處理問題時**不建立**此檔。
+   - 此新檔屬工作區變更，會在階段 C 一併分類提交（歸 `chore`）。UTF-8（不含 BOM）、結尾保留一個換行。
+3. **關閉該議題（一律關閉）**：該議題的問題已全部分流為 ✅ 已修復 / 🚫 誤報寫入 exclusions / ⏭️ 待人工處理已寫回 findings（B5 保留或 B6 新建）追蹤，因此收尾時關閉：
+
+   ```bash
+   curl -sS -X PATCH -H "Authorization: token ${GITEA_TOKEN}" \
+     -H "Content-Type: application/json" \
+     "https://<host>/api/v1/repos/<owner>/<repo>/issues/<編號>" \
+     --data '{"state":"closed"}'
+   ```
+
+   關閉前先在步驟 1 的留言中標明各待人工處理項寫回哪個 findings 檔與原因，確保關閉議題不會遺失待辦。
+4. 誤報仍寫入 `exclusions.json`（同 B5），讓後續 review 沿用。

 ---

@@ -262,7 +353,7 @@ git ls-files --others --exclude-standard   # 未追蹤檔
 | `revert` | 還原先前的提交 |

 - **同一檔案橫跨多型** → 以該檔**主要異動性質**歸類；難以拆分時就近歸入影響最大的一類，並在總結註記。
- **階段 B 修復產生的變更**：依其性質歸類（修 bug→`fix`、補功能→`feat`、改文件→`docs`…）。`findings.json` / `exclusions.json` 的問題狀態更新歸 `chore`。
+- **階段 B 修復產生的變更**：依其性質歸類（修 bug→`fix`、補功能→`feat`、改文件→`docs`…）。`.gitea/ai-review/findings/` 目錄下 `*.json`（wrapper）與 `exclusions.json` 的問題狀態更新歸 `chore`。
 - **未追蹤新檔**：必須照實際內容歸入對應 type，必要時在提交前明確 `git add -- <path>`，不可因為是新檔就略過。

 ### C3. 產出提交計畫
@@ -276,11 +367,11 @@ git ls-files --others --exclude-standard   # 未追蹤檔
  - `type`：上表英文類型。
  - `範圍`（括號內）：**必須是這組異動實際牽涉的功能／模組／元件名稱**，而**不是**重述 type 的類別詞。
    取名規則：優先沿用程式碼／專案中既有的識別名（檔名、模組名、skill 名、功能名，可中可英、保持與原碼一致），讓人一眼看出「改到哪個東西」。
-    - ✅ 對：`feat(使用者登入)`、`fix(結帳流程)`、`perf(物件查詢)`、`docs(README)`、`refactor(訂單服務)`、`chore(plugin 版本)`、`feat(code-review-resolve)`。
+    - ✅ 對：`feat(使用者登入)`、`fix(結帳流程)`、`perf(物件查詢)`、`docs(README)`、`refactor(訂單服務)`、`chore(plugin 版本)`、`feat(review-resolve)`。
    - ❌ 錯（只是重述 type，禁止）：`feat(新增功能)`、`fix(修正錯誤)`、`perf(優化效能)`、`docs(文件)`、`chore(雜項)`。
    - 一組異動橫跨多個功能而無單一主體時，才退而取最貼近的上層範圍（例如多個 manifest → `plugin 設定`）。
  - `一句總結`：把這個 commit 內所有異動**總結成一句**繁體中文（簡短、聚焦做了什麼）。
-  - 範例：`feat(使用者登入): 新增帳密登入與 token 簽發`、`fix(結帳流程): 修正空購物車導致的結帳例外`、`perf(物件查詢): 改用批次查詢降低 DB 往返`、`docs(README): 補上安裝與呼叫方式說明`、`chore(ai-review 狀態): 更新 findings.json 與 exclusions.json`。
+  - 範例：`feat(使用者登入): 新增帳密登入與 token 簽發`、`fix(結帳流程): 修正空購物車導致的結帳例外`、`perf(物件查詢): 改用批次查詢降低 DB 往返`、`docs(README): 補上安裝與呼叫方式說明`、`chore(ai-review 狀態): 更新 findings 與 exclusions.json`。
 - **提交順序建議**：`fix`/`feat` 等核心異動在前，`docs`/`style`/`chore` 在後（純屬建議，可依相依性調整）。
 - **盤點要求**：提交計畫必須完整對應 C1 盤點出的所有變更項目，若有新檔或未追蹤檔，必須明確列入對應 commit，不能只根據 `git diff` 下結論。

@@ -443,7 +534,7 @@ curl -sS -X POST \
 各階段執行後輸出：

 - **階段 A**：git fetch / pull 是否成功、當前分支是否存在於遠端（不存在時切到 develop／master 的結果）、若來源分支與目標分支同名是否已建立新工作分支、是否發生衝突、衝突是否已解決或仍需人工處理。
- **階段 B**：已解決 N 條（依等級分佈）、誤報寫入 exclusions M 條、待人工處理 K 條（列出原因）、`findings.json` 保留／移除筆數與 `exclusions.json` 新增筆數；若無待處理問題，說明已跳過階段 C 直接進入階段 D。
+- **階段 B**：問題來源（findings 檔筆數＋議題來源：無／`#N`／多個／全部）、合併去重後總數、已解決 N 條（依等級分佈）、誤報寫入 exclusions M 條、待人工處理 K 條（列出原因）、來源 findings 檔保留／移除筆數與 `exclusions.json` 新增筆數；有處理議題時另報各議題已留言、只來自議題的待人工問題寫回哪個 findings 檔、以及各議題已關閉；若無待處理問題，說明已跳過階段 C 直接進入階段 D。
 - **階段 C**：建立了哪幾個 commit（type＋訊息＋檔數），或為何略過（`--no-commit` / 無變更）。
 - **階段 D**：push 成功與否、用了哪種方式（認證管理器／token／使用者指定），遠端分支名；若無 commit 可 push，說明已跳過 push 直接進入階段 E。
 - **階段 E**：PR 連結／編號、目標分支、描述形式；並提醒已（或請使用者）清除對話內文以防 token 外洩。
@@ -453,10 +544,10 @@ curl -sS -X POST \
 ## 呼叫方式

 格式：`[--findings <路徑>] [--target <目標分支>] [--pr-desc <full|simple|自訂文字>] [--no-commit] [--no-pr] [--yes]` —
-全部可省略（findings 預設 `.gitea/ai-review/findings.json`；目標分支省略時必問、不猜測）。token 一律由環境變數（如 `GITEA_TOKEN`）提供。
+除 `--target` 外皆可省略（findings 一律讀目錄 `.gitea/ai-review/findings/` 下所有 wrapper `*.json` 與 `findings.json`；`--issue` 無/單選/多選/全部 額外從 Gitea 議題取問題，與 findings 合併去重；目標分支省略時必問、不猜測）。token 一律由環境變數（如 `GITEA_TOKEN`）提供。

 | 助理 | 呼叫 |
 | --- | --- |
-| Claude Code / Antigravity | `/jsc:code-review-resolve`，或 `/jsc:code-review-resolve --target develop --pr-desc full --yes`、`/jsc:code-review-resolve --no-pr`、`/jsc:code-review-resolve --no-commit` |
-| Codex | `$code-review-resolve`，或 `$code-review-resolve --target develop --pr-desc full --yes`，或用 `/skills` 選單 |
-| OpenCode | 描述需求（如「讀 .gitea/ai-review/findings.json 依嚴重度逐條處理，更新 findings/exclusions，把工作區變更依 conventional commit 分類提交，push 後對 develop 發 PR（完整版描述）」）自動觸發 |
+| Claude Code / Antigravity | `/jsc-code:review-resolve`，或 `/jsc-code:review-resolve --target develop --pr-desc full --yes`、`/jsc-code:review-resolve --issue 12,15 --target master`、`/jsc-code:review-resolve --issue all --target master`、`/jsc-code:review-resolve --no-pr`、`/jsc-code:review-resolve --no-commit` |
+| Codex | `$review-resolve`，或 `$review-resolve --target develop --pr-desc full --yes`、`$review-resolve --issue all --target master`，或用 `/skills` 選單 |
+| OpenCode | 描述需求（如「讀 .gitea/ai-review/findings/ 目錄與 findings.json 的 wrapper findings，再併入議題 #12、#15 的 code review 問題去重後依嚴重度逐條處理，更新 findings/exclusions，把工作區變更依 conventional commit 分類提交，push 後對 develop 發 PR（完整版描述）」）自動觸發 |
@@ -1,10 +1,10 @@
 ---
-name: code-sync
+name: sync
 description: 透過 `GITEA_TOKEN` 取得使用者有讀取權限的所有 Gitea 專案，依擁有者（owner）分組後列出讓使用者多選，再把選定擁有者底下有讀取權限的專案，於目標目錄（預設家目錄）依擁有者建立資料夾並逐一 clone；若專案已存在，則切換到 develop（再退而 master）並更新到最新。當使用者說同步 Gitea 專案、批次 clone、把某些擁有者的 repo 全抓下來、依擁有者分類 clone、批次更新本機專案到最新時觸發。不適用於：建立／刪除遠端 repo、單一專案的 clone（直接用 git 即可）、非 Gitea 的來源，或需要 push／改動遠端的操作。
 argument-hint: "[--target-dir <根目錄>] [--owner <擁有者,以逗號分隔>] [--host <gitea 主機>] [--include-forks] [--ssh] [--yes]"
 ---

-# code-sync — 依擁有者批次 clone／更新 Gitea 專案
+# sync — 依擁有者批次 clone／更新 Gitea 專案

 五階段 skill：先做**前置設定**（解析 token、gitea 主機、目標根目錄），再**取得使用者有讀取權限的所有專案並依擁有者分組**，接著**列出所有擁有者讓使用者多選**，然後**列出選定擁有者底下有讀取權限的專案**，最後在目標根目錄**依擁有者建立資料夾並逐一 clone**；專案已存在時改為**切換到 develop（再退而 master）並更新到最新**。

@@ -18,13 +18,18 @@ argument-hint: "[--target-dir <根目錄>] [--owner <擁有者,以逗號分隔>]

 ---

-## 輸出規範（務必遵守）
+## 共用規範（shared plugin，必要前置）

- **語言**：所有面向使用者的輸出（擁有者清單、專案清單、進度、總結、反問）一律使用**繁體中文（台灣用語）**；僅識別字、檔名、git／curl 指令、API 路徑等技術標識保留原文，**不可**使用簡體字。
- **編碼無亂碼**：凡輸出含繁體中文、全形標點、emoji，一律 **UTF-8（不含 BOM）**，不得出現問號方框或錯碼。
- **Token 機密保護（極重要）**：gitea token 一律**從環境變數讀取**（如 `$GITEA_TOKEN`），**絕不**寫死在 skill、log 或任何輸出；**不可** echo 含 token 的指令或 URL。所有顯示給使用者的指令／錯誤訊息都要**遮蔽 token**（如以 `***` 取代）。clone 時帶 token 的 URL 用變數帶入、**不可印出**，且 clone 完成後要把 origin 還原成不含 token 的乾淨 URL（見 E3），避免 token 落地在 `.git/config`。
- **自動執行原則**：除非使用者明確要求先確認，或遇到不可忽略的必要決策（例如缺 token、無法決定 gitea 主機、目標目錄不可寫、單一專案更新時工作區有未提交變更需使用者裁示），否則各階段只需輸出簡短計畫／進度後直接執行到完成。**唯一一定會中斷的點是階段 C 的擁有者多選**（除非已帶 `--owner`）。
- **不破壞既有工作**：更新既有專案時若工作區有未提交變更而導致切換／pull 失敗，**停止該專案的更新並回報**，請使用者自行處理；**絕不**強制丟棄（不可 `reset --hard`／`checkout -f`／`clean`）。
+執行本 skill 前，先以 Skill 工具載入下列共用規範並全程遵守；**任一載入不到（shared plugin 未安裝）時，先詢問使用者是否安裝 shared plugin（`https://gitea.jsc.idv.tw/plugins/shared.git`），使用者不安裝則直接中斷本 skill**，不得只憑下方一行摘要繼續執行：
+
+- `/jsc-shared:spec-output`：繁體中文（台灣用語）、UTF-8（不含 BOM）無亂碼。
+- `/jsc-shared:spec-execution`：自動執行原則（必要決策才中斷）、不臆測／需人工確認。
+- `/jsc-shared:spec-gitea`：`GITEA_TOKEN` 機密保護（不 echo、遮蔽、clone 後還原乾淨 origin）、API 分頁完整讀取、host 決定順序。
+- `/jsc-shared:spec-git-safety`：不破壞既有工作（未提交變更不強切、絕不 `reset --hard`／`clean`）、develop → master 後備、`pull --ff-only`。
+
+本 skill 特有補充：
+
+- **必要決策**（會中斷詢問）：缺 token、無法決定 gitea 主機、目標目錄不可寫、單一專案更新時工作區有未提交變更需使用者裁示。**唯一一定會中斷的點是階段 C 的擁有者多選**（除非已帶 `--owner`）。
 - **唯讀本意**：本 skill 只做 clone 與本機分支更新，**不 push、不改遠端、不刪本機未追蹤檔**。

 ---
@@ -46,25 +51,11 @@ argument-hint: "[--target-dir <根目錄>] [--owner <擁有者,以逗號分隔>]

 ### A1. 確認 token

-讀取環境變數 `GITEA_TOKEN`（或助理慣用的等價變數名）。
-
-```bash
-[ -n "${GITEA_TOKEN}" ] && echo "GITEA_TOKEN 已設定" || echo "GITEA_TOKEN 未設定"
-```
-
- **未設定** → 回報「缺少 `GITEA_TOKEN` 環境變數，無法存取 Gitea API」並停止；提示使用者於環境變數提供 token（不要請使用者把 token 貼進對話）。
- **不可** echo token 本身，只確認是否存在。
+依 `/jsc-shared:spec-gitea` 確認 `GITEA_TOKEN`（只輸出「已設定／未設定」，不可 echo token 本身）；**未設定** → 回報「缺少 `GITEA_TOKEN` 環境變數，無法存取 Gitea API」並停止（不要請使用者把 token 貼進對話）。

 ### A2. 決定 gitea 主機

-依序決定主機（取第一個成功者）：
-
-1. 帶 `--host <主機>` → 直接採用。
-2. 否則讀環境變數 `$GITEA_HOST`（若有）。
-3. 否則若**目前工作目錄是 git repo** 且 `git remote get-url origin` 指向某 gitea 主機 → 取該 host。
-4. 以上皆無 → **詢問使用者** gitea 主機，**不臆測**。
-
-主機僅取 host 部分（如 `gitea.jsc.idv.tw`），組 API base 為 `https://<host>/api/v1`。
+依 `/jsc-shared:spec-gitea` 的 host 決定順序：`--host` → `$GITEA_HOST` → 目前 repo 的 origin → 詢問使用者（不臆測）。主機僅取 host 部分（如 `gitea.jsc.idv.tw`），組 API base 為 `https://<host>/api/v1`。

 ### A3. 決定目標根目錄

@@ -223,6 +214,6 @@ git -C "${dest}" fetch --all --prune

 | 助理 | 呼叫 |
 | --- | --- |
-| Claude Code / Antigravity | `/jsc:code-sync`，或 `/jsc:code-sync --owner plugins --target-dir ~/work`、`/jsc:code-sync --include-forks --ssh` |
-| Codex | `$code-sync`，或 `$code-sync --owner plugins --target-dir ~/work`，或用 `/skills` 選單 |
+| Claude Code / Antigravity | `/jsc-code:sync`，或 `/jsc-code:sync --owner plugins --target-dir ~/work`、`/jsc-code:sync --include-forks --ssh` |
+| Codex | `$sync`，或 `$sync --owner plugins --target-dir ~/work`，或用 `/skills` 選單 |
 | OpenCode | 描述需求（如「用 GITEA_TOKEN 取得我有讀取權限的所有 Gitea 專案，依擁有者分組讓我多選，把選定擁有者的專案 clone 到家目錄；已存在的切到 develop／master 更新到最新」）自動觸發 |
@@ -0,0 +1,342 @@
+---
+name: target
+description: 用專案根目錄的 `TARGET.md` 當每日待辦清單，並以系統排程（Linux／WSL／macOS 用 crontab、Windows 用 schtasks）在每天 00:00 自動跑完它。`--schedule on` 建立或更新排程、`--schedule off` 移除排程、`--run` 立即（或由排程）執行一次：先同步 git 並切到 `develop`（遠端沒有就從預設分支建立），逐項實作 `TARGET.md` 中未勾選的項目、完成一項就勾選並補完成時間，接著把工作區變更依 conventional commit 類型分類提交、push `develop`，最後透過 Gitea API 對**遠端預設分支**發 PR（已有同 head→base 的 open PR 就沿用不重開）。當使用者說把 TARGET.md 排成每天執行、每天半夜自動跑待辦、開啟／關閉每日自動任務、建立每日排程做完 TARGET、移除 TARGET 排程、跑一次 TARGET.md 的項目、讓 AI 每天自動做完待辦並發 PR，或提到 TARGET.md、每日排程、cron 每天 00:00、schtasks 每日任務時觸發。不適用於：解決 AI review findings（用 review-resolve）、實作 Gitea 議題的 TODO（用 issues）、角色記憶的睡眠排程（用 role）。
+argument-hint: "[--schedule on|off] [--run] [--project-dir <專案根目錄>] [--cli <claude|codex|agy|opencode|copilot>] [--base <PR 目標分支>] [--no-pr] [--yes]"
+---
+
+# target — TARGET.md 每日排程執行、提交、push develop 並發 PR
+
+兩個用途合在一個 skill：**管理排程**（開／關每天 00:00 的系統排程）與**執行一次**（把 `TARGET.md` 的待辦做完並走完 git 流程）。排程觸發時，執行的就是本 skill 的 `--run`。
+
+| 模式 | 觸發 | 動作 |
+| --- | --- | --- |
+| `--schedule on` | 使用者 | 依 OS 建立／更新「每天 00:00 執行本 skill `--run`」的系統排程（同一專案只會有一筆） |
+| `--schedule off` | 使用者 | 移除該專案的排程條目（只動自己那筆，不碰使用者其他排程） |
+| `--run` | 排程／使用者 | A Git 同步（切到 develop，沒有就建立）→ B 讀 `TARGET.md` → C 逐項實作並勾選 → D 分類提交 → E push develop → F 對預設分支發 PR |
+| 不帶參數 | 使用者 | 只回報現況：排程裝了沒、下次執行時間、`TARGET.md` 還剩幾項未完成 |
+
+`--schedule` 與 `--run` 可同時帶（`--schedule on --run` = 裝好排程並立刻先跑一次）。
+
+---
+
+## 共用規範（shared plugin，必要前置）
+
+執行本 skill 前，先以 Skill 工具載入下列共用規範並全程遵守；**任一載入不到（shared plugin 未安裝）時，先詢問使用者是否安裝 shared plugin（`https://gitea.jsc.idv.tw/plugins/shared.git`），使用者不安裝則直接中斷本 skill**，不得只憑下方一行摘要繼續執行：
+
+- `/jsc-shared:spec-output`：繁體中文（台灣用語）、UTF-8（不含 BOM）無亂碼（含 `TARGET.md` 回寫、commit 訊息、PR 標題／描述）、表格呈現。
+- `/jsc-shared:spec-execution`：自動執行原則（必要決策才中斷）、不臆測／需人工確認。
+- `/jsc-shared:spec-git-safety`：不破壞既有工作（絕不 `reset --hard`／`clean`）、`pull --ff-only`、保守解衝突、新分支不覆蓋既有分支。
+- `/jsc-shared:spec-gitea`：`GITEA_TOKEN` 機密保護（不 echo、遮蔽 `***`）、API body 以 UTF-8 JSON 檔帶入。
+- `/jsc-shared:spec-time-log`：Asia/Taipei `yyyy/MM/dd HH:mm:ss` 時間格式、`[時間][階段][等級]: 訊息` log 格式。
+
+本 skill 特有補充：
+
+- **排程只動自己那一筆**：安裝／移除都以固定標記比對，**絕不覆寫整份 crontab、不刪別人的排程任務**。
+- **排程情境沒有人在旁邊**：`--run` 遇到必要決策時**停下來並寫進 log**，不得臆測後硬做；下次執行會再遇到同一個決策點，由使用者處理。
+- **必要決策**（會中斷詢問）：工作區有未提交變更、`origin` 無法解析、找不到遠端預設分支、`TARGET.md` 項目語意不明無法安全實作、push 憑證皆失敗、無法判斷目前是哪個助理（且未帶 `--cli`）。
+
+---
+
+## 參數
+
+格式：`[--schedule on|off] [--run] [--project-dir <專案根目錄>] [--cli <claude|codex|agy|opencode|copilot>] [--base <PR 目標分支>] [--no-pr] [--yes]`
+
+- `--schedule on|off`：`on` 建立／更新排程，`off` 移除排程。省略時不動排程。
+- `--run`：立即執行一次 `TARGET.md`（排程條目帶的就是這個）。
+- `--project-dir <專案根目錄>`：目標專案根目錄，**省略時取目前工作目錄**（會先 `git rev-parse --show-toplevel` 正規化成 repo 根）。`TARGET.md` 固定讀**專案根目錄**的那一份。
+- `--cli <claude|codex|agy|opencode|copilot>`：排程條目要用哪個助理的 headless 指令。省略時用**目前正在執行本 skill 的助理**；判斷不出來且未帶此參數 → 詢問，不猜測。
+- `--base <PR 目標分支>`：PR 的目標分支。**省略時自動取遠端預設分支**（見 F1），取不到才詢問。
+- `--no-pr`：執行到 push 為止，不開 PR。
+- `--yes`：全自動，不做確認式詢問（必要決策仍會中斷）。
+
+執行時間固定為**每天 00:00**（本機時區），不提供時間參數；要改時間請直接編輯排程條目。
+
+---
+
+## `TARGET.md` 格式
+
+專案根目錄的 `TARGET.md`，用 Markdown checklist 表示待辦：
+
+```markdown
+# TARGET
+
+- [ ] 補上使用者服務的單元測試
+- [ ] 把 README 的安裝章節更新成新的 CLI 指令
+  - [ ] 順便修掉裡面過期的截圖連結
+- [x] 移除已停用的舊設定檔（2026/08/02 23:41:07 完成）
+```
+
+| 規則 | 說明 |
+| --- | --- |
+| 待辦 | `- [ ]` 未勾選的項目，**由上而下**依序處理 |
+| 已完成 | `- [x]` 直接略過，不重做 |
+| 子項目 | 縮排的 `- [ ]` 視為上層項目的子步驟，隨上層一起處理；子項目全部完成才勾選上層 |
+| 標題／說明文字 | 原樣保留，只當作項目的背景脈絡，不改寫 |
+| 檔案不存在 | `--run` 視為「無待辦」正常結束（不建檔、不報錯）；`--schedule on` 則提醒尚無 `TARGET.md`，非 `--yes` 時詢問是否仍要建立排程 |
+
+完成一項後就地改成 `- [x]`，並在該行**行尾**補上 `（<yyyy/MM/dd HH:mm:ss> 完成）`（Asia/Taipei）。無法安全完成的項目**保持未勾選**，並在該行下方以縮排補一行 `> ⏭️ 待人工處理：<原因>`（已有同樣註記則更新而非重複新增）。
+
+---
+
+## 階段 S：管理排程（`--schedule on|off`）
+
+### S1. 判定 OS 與排程機制
+
+```bash
+uname -s   # Linux / Darwin / MINGW*|MSYS*|CYGWIN*（後者代表在 Windows 的 git bash）
+```
+
+| 環境 | 機制 | 備註 |
+| --- | --- | --- |
+| Linux、WSL | `crontab` | WSL 的 cron **預設不會自動啟動**，見 S5 |
+| macOS | `crontab` | 可用；若使用者偏好 `launchd` 需自行改寫，本 skill 不代為產生 plist |
+| Windows（PowerShell／cmd） | `schtasks` | 每日任務 |
+
+判斷不出環境時停止並回報，不臆測。
+
+### S2. 組出排程要執行的指令
+
+```bash
+proj="$(cd "<專案根目錄>" && git rev-parse --show-toplevel)"   # 絕對路徑
+log="$HOME/.jsc/target-$(basename "$proj").log"
+```
+
+log **刻意放在專案外面**：放進 repo 會讓每次執行都多出未追蹤檔，污染 D 階段的變更盤點。
+
+各助理的 headless 指令（依 `--cli`）：
+
+| `--cli` | 指令 |
+| --- | --- |
+| `claude` | `claude -p "/jsc-code:target --run --yes"` |
+| `codex` | `codex exec '$target --run --yes'`（單引號，避免 `$` 被 shell 展開） |
+| `agy` | `agy -p "/jsc-code:target --run --yes"` |
+| `opencode` | `opencode run "執行專案根目錄 TARGET.md 的未完成項目，完成後分類提交、push develop 並對預設分支發 PR"` |
+| `copilot` | `copilot -p "執行專案根目錄 TARGET.md 的未完成項目，完成後分類提交、push develop 並對預設分支發 PR"` |
+
+> **排程是非互動環境**：助理若跳出工具權限詢問會直接卡住，排程等於沒跑。建立排程前要提醒使用者**先在該專案預先授權**（例如 Claude Code 於專案設定的 `permissions.allow` 列出所需工具，或在指令上加該助理的非互動旗標）。這牽涉安全取捨，**由使用者決定，不代為加上略過權限的旗標**。
+
+### S3. 建立／更新排程（`--schedule on`）
+
+**crontab**（標記寫在行尾，一筆條目就是一行，安裝與移除都靠它比對）：
+
+```bash
+marker="# jsc-code:target ${proj}"
+entry="0 0 * * * cd '${proj}' && <headless 指令> >> '${log}' 2>&1 ${marker}"
+
+mkdir -p "$(dirname "${log}")"
+tmp="$(mktemp)"
+crontab -l 2>/dev/null | grep -vF "${marker}" > "${tmp}"   # 先移除同專案的舊條目（更新用）
+printf '%s\n' "${entry}" >> "${tmp}"
+crontab "${tmp}"
+rm -f "${tmp}"
+
+crontab -l | grep -F "${marker}"                            # 驗證確實寫進去了
+```
+
+- `crontab -l` 在「完全沒有排程」時會回非 0 並印錯誤，所以要 `2>/dev/null`；**不可因此把整份 crontab 當成空的覆寫**——先確認 `crontab -l` 的失敗是「沒有排程」而不是權限問題。
+- 指令中若出現 `%`，crontab 會把它當換行，必須寫成 `\%`。
+- 條目一律用**絕對路徑**（cron 的 `PATH` 很精簡）；若 `command -v <cli>` 得到的不是系統路徑，把 CLI 也寫成絕對路徑。
+
+**schtasks**（Windows）：
+
+```powershell
+$task = "jsc-code-target-<專案名>"    # 專案名重複時附加路徑短碼，確保唯一
+schtasks /Create /TN "$task" /SC DAILY /ST 00:00 /F `
+  /TR "cmd /c cd /d ""<專案絕對路徑>"" && <headless 指令> >> ""<log 絕對路徑>"" 2>&1"
+schtasks /Query /TN "$task"          # 驗證
+```
+
+`/F` 只覆蓋**同名**任務（即本 skill 自己那筆），不影響其他排程。
+
+### S4. 移除排程（`--schedule off`）
+
+```bash
+tmp="$(mktemp)"
+crontab -l 2>/dev/null | grep -vF "# jsc-code:target ${proj}" > "${tmp}"
+crontab "${tmp}"
+rm -f "${tmp}"
+crontab -l 2>/dev/null | grep -F "# jsc-code:target ${proj}" || echo "已移除"
+```
+
+```powershell
+schtasks /Delete /TN "jsc-code-target-<專案名>" /F
+```
+
+- 找不到條目 → 回報「本來就沒有排程」，視為成功，不報錯。
+- **只刪自己標記的那一筆**；其餘 crontab 內容原樣寫回。`TARGET.md`、log 檔、git 分支都不刪。
+
+### S5. 確認排程服務真的在跑（`--schedule on` 後必做）
+
+排程條目寫進去 ≠ 會被執行。安裝後檢查：
+
+```bash
+pgrep -x cron >/dev/null || pgrep -x crond >/dev/null || echo "cron 服務未執行"
+```
+
+- **WSL 特別注意**：WSL 預設不啟動 cron，需要 `sudo service cron start`，且**重開 WSL 後要再啟動一次**（可寫進 `/etc/wsl.conf` 的 `boot.command` 或啟動腳本）。偵測到未執行時**明確告知使用者這件事**，不要只回報「排程已建立」。
+- Windows：`schtasks /Query /TN "<任務名>"` 能查到即可。
+
+---
+
+## 階段 A：Git 同步（`--run`）
+
+### A1. 盤點狀態
+
+```bash
+cd "<專案根目錄>"
+git rev-parse --show-toplevel
+git status --porcelain
+git rev-parse --abbrev-ref HEAD
+```
+
+- **工作區有未提交變更** → **停止**並回報（排程情境寫入 log）。理由：本 skill 結尾會分類提交所有變更，混入使用者未完成的工作會把它一起提交上去。依 `/jsc-shared:spec-git-safety`，**不得** stash、`reset --hard` 或 `clean` 來清場。
+- **detached HEAD** → 停止並回報。
+
+### A2. Fetch 與判定遠端預設分支
+
+```bash
+git fetch --all --prune
+git symbolic-ref --quiet refs/remotes/origin/HEAD    # → refs/remotes/origin/<預設分支>
+```
+
+取不到時退而用 `git remote show origin`（找 `HEAD branch:` 那行）；`--base` 有帶則直接採用。兩者都不成立 → 停止並詢問，不臆測 `master`／`main`。
+
+### A3. 切到 `develop`（不存在就從預設分支建立）
+
+```bash
+if git rev-parse --verify --quiet origin/develop >/dev/null; then
+  git switch develop 2>/dev/null || git switch -c develop --track origin/develop
+  git pull --ff-only
+else
+  git switch -c develop "origin/<預設分支>"          # 遠端沒有 develop → 從預設分支開一條新的
+fi
+```
+
+- `pull --ff-only` 失敗（分岔）→ 停止並回報，交由使用者處理，不做 merge／rebase 猜測。
+- 本地已有 `develop` 但遠端沒有 → 沿用本地那條，**不覆蓋、不重建**；並在回報中說明它還沒推上遠端。
+- 新建 develop 屬不可忽略的狀態變更，必須在回報與 log 中明講「遠端沒有 develop，已從 `<預設分支>` 建立」。
+
+---
+
+## 階段 B：讀 `TARGET.md` 並盤點待辦
+
+1. 讀 `<專案根目錄>/TARGET.md`（UTF-8）。檔案不存在 → 回報「無 TARGET.md，無待辦」，**正常結束**（不進入 C～F、不 commit、不發 PR）。
+2. 解析出所有 `- [ ]` 未勾選項目（含子項目的從屬關係），依**檔案由上而下**的順序排定執行順序。
+3. 全部都是 `- [x]` → 回報「TARGET.md 已全部完成」，正常結束。
+4. 輸出待辦清單表，除非使用者要求確認，否則直接進入階段 C：
+
+| # | 項目 | 子項目數 | 備註 |
+| --- | --- | --- | --- |
+
+---
+
+## 階段 C：逐項實作並回寫 `TARGET.md`
+
+依 B 的順序，**一次做一項，做完一項就回寫 `TARGET.md`**（中途失敗時已完成的進度不會遺失）：
+
+1. 讀懂該項目要什麼；必要時讀相關程式碼與文件確認脈絡。
+2. **語意不明、範圍不清、或牽涉設計取捨無法安全決定** → 不硬做。保持未勾選、補上 `> ⏭️ 待人工處理：<原因>`，繼續下一項。
+3. 實作最小且合理的變更；能驗證的就驗證（該專案既有的 build／test 指令）。驗證失敗且無法安全修正 → 比照第 2 點標記待人工處理，並**還原**該項目造成的變更，不留半成品。
+4. 完成 → 把該行改成 `- [x]` 並於行尾補 `（<yyyy/MM/dd HH:mm:ss> 完成）`；有子項目則子項目全部完成後才勾選上層。
+5. 每項結束記錄結果（✅ 完成 / ⏭️ 待人工處理＋原因），供階段 G 總結。
+
+`TARGET.md` 一律以 UTF-8（不含 BOM）寫回，結尾保留一個換行；**只改動勾選狀態與完成時間／待人工註記**，其餘內容原樣保留。
+
+---
+
+## 階段 D：分類提交
+
+1. 盤點**所有**變更（含未追蹤檔）：
+
+   ```bash
+   git status --porcelain=v1 -uall
+   ```
+
+2. 依實際異動內容歸入 conventional commit 類型（`feat`／`fix`／`docs`／`style`／`refactor`／`perf`／`test`／`chore`／`revert`），**每個 type 各一個 commit**。
+3. commit 訊息格式 `type(範圍): 一句總結`，**括號內是實際異動的功能／模組名**，不是重述 type：
+   - ✅ `feat(使用者服務): 補上帳號建立與停用的單元測試`、`docs(README): 更新安裝章節的 CLI 指令`
+   - ❌ `feat(新增功能)`、`docs(文件)`
+   - `TARGET.md` 本身的勾選更新歸 `chore`，訊息用 `chore(TARGET): 更新每日待辦完成狀態`。
+4. 逐組精準 `git add -- <該組檔案...>` 後 commit，不用 `git add -A` 一次混提。
+5. 無任何變更（例如所有項目都待人工處理，只有 `TARGET.md` 的註記異動）→ 仍照常提交 `TARGET.md` 的異動；連 `TARGET.md` 都沒變則跳過 D、E、F，直接進入總結。
+
+> 分類與訊息規則與 `/jsc-code:review-resolve` 階段 C 一致，細節可參照該 skill。
+
+---
+
+## 階段 E：Push `develop`
+
+```bash
+git log --oneline "origin/develop..develop" 2>/dev/null   # 領先遠端的 commit；遠端無 develop 時視為全部要推
+```
+
+無 commit 可推 → 跳過 push，直接進入階段 F（既有遠端分支仍可開 PR）。否則依序嘗試，前者失敗才換下一個：
+
+1. **認證管理器**：`git push -u origin develop`
+2. **token**：從環境變數帶入，指令與輸出**全程遮蔽 token、不寫進 remote 設定**：
+
+   ```bash
+   git push "https://oauth2:${GITEA_TOKEN}@<host>/<owner>/<repo>.git" develop
+   ```
+
+3. **都失敗** → 停止並回報失敗原因（先遮蔽 token）。排程情境寫入 log，等使用者處理，不猜測其他憑證。
+
+---
+
+## 階段 F：對預設分支發 PR（`--no-pr` 時略過）
+
+### F1. 目標分支
+
+`--base` 有帶則用它，否則用 A2 判定出的**遠端預設分支**。若預設分支就是 `develop`（等於 head=base）→ 不開 PR，回報原因即可。
+
+### F2. 先查有沒有現成的 open PR（每天跑，不可重複開）
+
+```bash
+curl -sS -H "Authorization: token ${GITEA_TOKEN}" \
+  "https://<host>/api/v1/repos/<owner>/<repo>/pulls?state=open&base=<預設分支>"
+```
+
+已存在 `head=develop` → `base=<預設分支>` 的 open PR → **沿用它**（今天新推的 commit 會自動出現在該 PR），回報既有 PR 連結，並視情況在該 PR 補一則今日進度留言；**不重複建立**。
+
+### F3. 建立 PR
+
+repo 座標由 `git remote get-url origin` 解析（host／owner／repo）。body 以 UTF-8 JSON 檔帶入，換行用實際換行、不可送出字面 `\n`：
+
+```bash
+curl -sS -X POST \
+  -H "Authorization: token ${GITEA_TOKEN}" \
+  -H "Content-Type: application/json" \
+  "https://<host>/api/v1/repos/<owner>/<repo>/pulls" \
+  --data @body.json
+```
+
+- **標題**：`chore(TARGET): <yyyy/MM/dd> 每日待辦`（有明確主軸時可改成該主軸的一句總結）。
+- **描述**：本次完成的項目清單（✅／⏭️ 各自列出＋待人工處理原因）、變更摘要與影響範圍、本次的 commit 一覽。
+- 失敗 → 回報 API 錯誤訊息（先遮蔽 token）。常見原因：目標分支不存在、已有相同 head→base 的 PR（回到 F2 沿用）、token 權限不足。
+
+### F4. 收尾
+
+push／API 過程可能讓 token 殘留在對話內文；**互動情境**完成後提醒使用者清除對話（Claude Code 用 `/clear`）。排程情境只寫 log，不輸出 token。
+
+---
+
+## 總結
+
+執行後輸出（排程情境同時以 `[時間][階段][等級]: 訊息` 寫入 log）：
+
+| 模式 | 要回報的內容 |
+| --- | --- |
+| `--schedule on` | 用了哪種機制（crontab／schtasks）、條目內容、log 路徑、排程服務是否在跑（WSL 未啟動 cron 要明講）、下次執行時間 |
+| `--schedule off` | 移除了哪一筆、其餘排程未受影響 |
+| `--run` | 待辦總數／✅ 完成 N 項／⏭️ 待人工處理 K 項（逐項原因）、develop 是新建還是既有、建立了哪幾個 commit、push 結果與方式、PR 連結（新建或沿用既有）、或為何略過 |
+| 無參數 | 排程狀態＋下次執行時間、`TARGET.md` 是否存在與剩餘未完成項目數 |
+
+---
+
+## 呼叫方式
+
+| 助理 | 呼叫 |
+| --- | --- |
+| Claude Code / Antigravity | `/jsc-code:target --schedule on`、`/jsc-code:target --schedule off`、`/jsc-code:target --run --yes`、`/jsc-code:target --schedule on --run --project-dir ~/work/app` |
+| Codex | `$target --schedule on`、`$target --run --yes`，或用 `/skills` 選單 |
+| OpenCode | 描述需求（如「幫我把這個專案的 TARGET.md 排成每天 00:00 自動執行，做完分類提交、push develop 並對預設分支發 PR」）自動觸發 |
Author	SHA1	Message	Date
admin	9d8ac26a3b	Merge pull request 'feat(target): 新增 TARGET.md 每日排程執行 skill' (#18 ) from develop into master Reviewed-on: #18 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-08-03 05:34:16 +00:00
JefferyandClaude Opus 5	ec038ab4fc	chore(plugin 版本): 三家 manifest 升版 0.0.3 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 12:42:12 +08:00
JefferyandClaude Opus 5	db637dbab6	docs(README): 補上 target skill 說明與目錄結構 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 12:42:12 +08:00
JefferyandClaude Opus 5	56241a0a50	feat(target): 新增 TARGET.md 每日排程執行、分類提交、push develop 與發 PR 流程 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 12:42:12 +08:00
admin	0cd1b12147	Merge pull request 'chore(code): sync develop to master' (#17 ) from develop into master Reviewed-on: #17 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-31 17:38:25 +00:00
jiantw83	3a760a462e	refactor(shared): switch code skills to jsc-shared	2026-07-31 17:36:08 +00:00
jiantw83	ae745a0ad4	chore(plugin 版本): 三家 manifest 升版 0.0.2	2026-07-31 17:09:12 +00:00
jiantw83	80d24ee3fd	docs(code): fix stale install paths	2026-07-31 17:05:12 +00:00
admin	54f98d9b97	Merge pull request 'refactor(plugin 命名空間): plugin 更名 jsc-code、skill 去領域前綴' (#16 ) from develop into master Reviewed-on: #16 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-28 09:17:17 +00:00
JefferyandClaude Opus 5	0296c5e7a3	chore(plugin 版本): 更名視為新 plugin，版號重置 0.0.1 plugin 更名後，各助理以 <plugin 名>@<marketplace 名> 作為安裝識別鍵，新名與舊名是兩筆獨立條目：舊 plugin 會被移除、新 plugin 為首次安裝，兩者之間不存在版本比較，因此不會發生版本倒退，「版本單調遞增」不適用。依 spec-plugin-version「新 plugin 首發 0.0.1」，三份 manifest 版號一律重置為 0.0.1，不沿用舊名 jsc 的版本序列。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 17:15:23 +08:00
JefferyandClaude Opus 5	cdf543afc2	refactor(plugin 命名空間): plugin 更名 jsc-code、skill 去領域前綴 - 五份 manifest（plugin.json、.claude-plugin、.codex-plugin、.agents）的 name 由 jsc 改為 jsc-code - skill 目錄去掉重複的 code- 前綴共 8 個（code-action-docker → action-docker 等），frontmatter name 同步 - 移除 hooks/hooks.json：本 repo 無 hook 腳本，hooks 改由擁有腳本的 plugin 各自註冊，不再維持三份合併超集 - 指令引用改為 /jsc-code: 前綴；跨 plugin 引用指向 /jsc-doc:、/jsc-generic: - 版號 0.1.0 → 0.1.1 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 17:07:14 +08:00
admin	c9a422caae	Merge pull request 'feat(hooks): 補上合併超集 hooks.json 並升版 0.0.11' (#15 ) from develop into master Reviewed-on: #15 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-28 08:17:21 +00:00
Jeffery	c288dd3c09	chore(plugin 版本): 三家 manifest 升版 0.1.0	2026-07-28 16:16:23 +08:00
JefferyandClaude Opus 5	729e6e794a	chore(plugin 版本): 三家 manifest 升版 0.0.11 hooks/hooks.json 為新增檔案，需升版才會重建版本化快取目錄並被載入。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 14:21:15 +08:00
JefferyandClaude Opus 5	377121d1c5	feat(hooks): 補上與 doc／generic 相同的合併超集 hooks.json 三個 repo 的 plugin.json 名稱都是 jsc，Claude Code 以 plugin 名稱為鍵註冊 hooks，同名時只保留一份（實測 stop_hook_summary 的 hookCount 為 1），無法預期哪一份會贏。因此每個 repo 都必須帶同一份合併超集，否則贏的那份缺少的 hook 會靜默失效。 code 本身沒有 hook 腳本，此檔僅作為超集載體：SessionStart 載入角色、Stop 執行 worklog 與角色記憶記錄；指令先試 CLAUDE_PLUGIN_ROOT，找不到再依「擁有者 marketplace 優先 → 全 cache 後援」搜尋 ~/.claude 與 ~/.codex 快取。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 14:21:14 +08:00
admin	caf4638f38	Merge pull request 'docs(README): 改用 Copilot CLI plugin 指令' (#14 ) from develop into master Reviewed-on: #14 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-27 09:01:05 +00:00
Jeffery	62f599a02e	docs(README): 改用 Copilot CLI plugin 指令	2026-07-27 16:37:57 +08:00
admin	726c92c208	Merge pull request 'docs(README): 補上 Copilot 使用說明' (#13 ) from develop into master Reviewed-on: #13 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-27 08:32:08 +00:00
Jeffery	36fd0c10a6	chore(plugin 版本): 三家 manifest 升版 0.0.10	2026-07-27 16:24:54 +08:00
Jeffery	05def2e51d	docs(README): 補上 Copilot 使用說明	2026-07-27 16:24:54 +08:00
admin	eeb3154420	Merge pull request 'feat(code-review-resolve): findings 一律讀取＋議題無/單選/多選/全部合併去重、Stage B 重新編號（0.0.9）' (#12 ) from develop into master Reviewed-on: #12 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-20 10:16:35 +00:00
Jeffery	8547f0af41	chore(plugin 版本): 版本號 bump 至 0.0.9	2026-07-20 18:14:57 +08:00
Jeffery	4fc33d4a69	feat(code-review-resolve): findings 檔一律讀取並與 --issue（無/單選/多選/全部）議題合併去重，Stage B 步驟重新編號為 B1–B6	2026-07-20 18:14:57 +08:00
admin	7af96f1230	Merge pull request 'feat(code-review-resolve): 議題模式待人工處理問題寫回 findings 後一律關閉議題（0.0.8）' (#11 ) from develop into master Reviewed-on: #11 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-20 07:16:42 +00:00
Jeffery	82458310a0	chore(plugin 版本): 版本號 bump 至 0.0.8	2026-07-20 15:15:17 +08:00
Jeffery	e8065f2d7c	feat(code-review-resolve): 議題模式將待人工處理問題寫回 findings 後一律關閉議題（B5）	2026-07-20 15:15:17 +08:00
admin	588f13881e	Merge pull request 'feat(code-review-resolve): 改採新版 findings wrapper 格式並新增 --issue 議題模式（0.0.7）' (#10 ) from develop into master Reviewed-on: #10 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-20 06:24:17 +00:00
Jeffery	33d6b7b95e	chore(plugin 版本): 版本號 bump 至 0.0.7	2026-07-20 14:18:07 +08:00
Jeffery	feb294ee9a	feat(code-review-resolve): 改採新版 findings wrapper 格式並新增 --issue 議題模式（B0 讀議題、B5 回寫並全解決時關閉）	2026-07-20 14:18:07 +08:00
admin	6de91ae30a	Merge pull request 'feat(code-review-resolve): findings 目錄 fallback 與版本 bump 0.0.6' (#9 ) from develop into master Reviewed-on: #9 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-20 03:16:06 +00:00
Jeffery	1401638532	chore(plugin 版本): 版本號 bump 至 0.0.6	2026-07-20 11:10:57 +08:00
Jeffery	c8cd60461b	feat(code-review-resolve): findings.json 不存在或空時 fallback 讀 findings/ 目錄下 *.json 並逐檔就地寫回	2026-07-20 11:10:53 +08:00
admin	8e73e864b5	Merge pull request 'docs(README): 標題前綴統一為 jsc' (#8 ) from develop into master Reviewed-on: #8 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-17 05:57:27 +00:00
Jeffery	d94f22ca06	docs(README): 標題前綴統一為 jsc 並標明程式碼工作流定位	2026-07-17 13:47:11 +08:00
admin	6c702f30ce	Merge pull request 'feat(code-action-node): 新增 Node（JavaScript）action 標準化 skill' (#7 ) from develop into master Reviewed-on: #7 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-17 05:36:09 +00:00
Jeffery	be96880022	feat(code-action-node): 新增 Node（JavaScript）action 標準化 skill 並登錄 README	2026-07-17 13:34:02 +08:00
admin	a0baf50761	Merge pull request 'feat(action skills): composite／docker action 標準化流程強化（參數優先序、從零建立、Dockerfile 修正）' (#6 ) from develop into master Reviewed-on: #6 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-17 03:36:44 +00:00
Jeffery	8419dbbca9	docs(README): 同步移除 code-review／code-review-archive／hello 章節與呼叫範例	2026-07-17 11:36:20 +08:00
Jeffery	aad458ce8d	chore(plugin 設定): 三家 manifest 與 marketplace 描述移除已刪除的 skill	2026-07-17 11:36:20 +08:00
Jeffery	2c9996b0e7	refactor(skills): 移除 code-review／code-review-archive／hello 三個 skill	2026-07-17 11:36:20 +08:00
JefferyandClaude Fable 5	739d5ba937	chore(plugin 版本): 三家 manifest 升版 0.0.5 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 08:58:04 +08:00
JefferyandClaude Fable 5	7814e2edea	refactor(skills 共用規範): 抽出共用規範至 generic spec-*，以引用＋一行 fallback 摘要取代重複內容 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 08:58:04 +08:00
JefferyandClaude Fable 5	fc39c1254d	docs(README): 同步 code-action-composite／code-action-docker 章節的參數優先序、從零建立與 Dockerfile 規則說明 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 16:03:57 +08:00
JefferyandClaude Fable 5	6e22907b0e	feat(code-action-docker): 參數來源優先序改為執行期環境變數→inputs、新增 A1a 問答式從零建立、移除相對路徑 entrypoint、真多階段建置＋.dockerignore、預設最新 LTS node、限縮 src/ 搬移範圍並移除 --yes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 16:03:49 +08:00
JefferyandClaude Fable 5	0b464c5cdf	feat(code-action-composite): 參數來源優先序簡化為 context→inputs、新增 A1a 問答式從零建立分支、補 INPUT_*／outputs 映射樣板、統一時間戳並移除 --yes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 16:03:40 +08:00
Jeffery	099f17e067	Revert "feat(code-action-docker): 重建為問答式五階段流程，詢問名稱／輸入輸出／目標後以 Node 實作並統一訊息格式，串接 doc-funcs" This reverts commit `3a9819f6d8`.	2026-07-16 12:33:52 +08:00
Jeffery	186d69dfe6	Revert "docs(README): 同步 code-action-docker 章節為問答式五階段流程說明" This reverts commit `a3a1346ae9`.	2026-07-16 12:33:52 +08:00
Jeffery	38203f17f7	Revert "chore(plugin 版本): 三家 manifest 升版 0.0.2" This reverts commit `6b92ca9a30`.	2026-07-16 12:33:52 +08:00
Jeffery	5bcd3a877d	Revert "feat(code-action-docker): 新增開發中參數來源優先序規則（gitea → secrets → vars → 詢問加入 inputs）" This reverts commit `5930254a5e`.	2026-07-16 12:33:52 +08:00
Jeffery	fcc8a96670	Revert "docs(README): 同步 code-action-docker 參數來源優先序說明" This reverts commit `e76775e703`.	2026-07-16 12:33:52 +08:00
Jeffery	c8ecc10dcc	Revert "chore(plugin 版本): 三家 manifest 升版 0.0.3" This reverts commit `a0b1a37ff9`.	2026-07-16 12:33:52 +08:00
Jeffery	c757bdc674	Revert "feat(code-issues): 議題屬於專案看板時依處理進度調整欄位（分析中→待處理→進行中→待測試→已完成）" This reverts commit `5633993d7f`.	2026-07-16 12:33:52 +08:00
Jeffery	c98b06bca7	Revert "docs(README): 同步 code-issues 議題看板欄位進度說明" This reverts commit `5e47ea938f`.	2026-07-16 12:33:52 +08:00
Jeffery	7f4eaeb258	Revert "chore(plugin 版本): 三家 manifest 升版 0.0.4" This reverts commit `b935be26d9`.	2026-07-16 12:33:52 +08:00
Jeffery	68a3410f1e	Revert "feat(code-issues): 實作完成後同步議題 TODO 勾選狀態，有母議題時一併勾選母議題對應項目並留言告知" This reverts commit `0e97646535`.	2026-07-16 12:33:52 +08:00
Jeffery	fc72f931a1	Revert "docs(README): 同步 code-issues 母議題 TODO 勾選說明" This reverts commit `bff191e3d3`.	2026-07-16 12:33:52 +08:00
Jeffery	32e7832527	Revert "fix(code-action-docker): 訊息格式對齊 doc-funcs 規範（[階段][等級][時間]: 訊息，階段選填）" This reverts commit `fcecc558b2`.	2026-07-16 12:33:52 +08:00
Jeffery	2d73b3121e	Revert "docs(README): 同步 code-action-docker 訊息格式為 doc-funcs 規範" This reverts commit `c16762ced3`.	2026-07-16 12:33:52 +08:00
Jeffery	b264709815	Reapply "docs(README): 同步 code-action-docker 訊息格式為 doc-funcs 規範" This reverts commit `223dc0c532`.	2026-07-16 12:33:52 +08:00
Jeffery	379750aa9b	Reapply "fix(code-action-docker): 訊息格式對齊 doc-funcs 規範（[階段][等級][時間]: 訊息，階段選填）" This reverts commit `c9b2e12711`.	2026-07-16 12:33:52 +08:00
Jeffery	c9b2e12711	Revert "fix(code-action-docker): 訊息格式對齊 doc-funcs 規範（[階段][等級][時間]: 訊息，階段選填）" This reverts commit `fcecc558b2`.	2026-07-16 12:28:47 +08:00
Jeffery	223dc0c532	Revert "docs(README): 同步 code-action-docker 訊息格式為 doc-funcs 規範" This reverts commit `c16762ced3`.	2026-07-16 12:28:47 +08:00
JefferyandClaude Fable 5	c16762ced3	docs(README): 同步 code-action-docker 訊息格式為 doc-funcs 規範 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 11:43:58 +08:00
JefferyandClaude Fable 5	fcecc558b2	fix(code-action-docker): 訊息格式對齊 doc-funcs 規範（[階段][等級][時間]: 訊息，階段選填） Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 11:43:58 +08:00
admin	6d9bac4585	Merge pull request 'feat: code-issues 新增看板欄位進度調整與母議題 TODO 同步並升版 0.0.4' (#4 ) from develop into master Reviewed-on: #4	2026-07-16 01:52:41 +00:00
JefferyandClaude Fable 5	bff191e3d3	docs(README): 同步 code-issues 母議題 TODO 勾選說明 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 09:50:31 +08:00
JefferyandClaude Fable 5	0e97646535	feat(code-issues): 實作完成後同步議題 TODO 勾選狀態，有母議題時一併勾選母議題對應項目並留言告知 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 09:50:31 +08:00
admin	cd2cf2e35d	Merge pull request 'feat: code-action-docker 新增參數來源優先序規則並升版 0.0.3' (#3 ) from develop into master Reviewed-on: #3 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-15 10:55:11 +00:00
admin	26454b85f6	Merge pull request 'feat: 重建 code-action-docker 為問答式五階段流程並升版 0.0.2' (#2 ) from develop into master Reviewed-on: #2 Reviewed-by: 系統管理員 <1+admin@noreply.localhost>	2026-07-15 10:39:59 +00:00