refactor(skills 共用規範): 抽出共用規範至 generic spec-*,以引用+一行 fallback 摘要取代重複內容
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Fable 5
parent
fc39c1254d
commit
7814e2edea
@@ -18,32 +18,29 @@ argument-hint: "[--action-dir <action 根目錄>] [--node-version <node tag>] [-
|
||||
|
||||
---
|
||||
|
||||
## 輸出規範(務必遵守)
|
||||
## 共用規範(generic plugin,必要前置)
|
||||
|
||||
- **語言**:所有面向使用者的輸出(計畫、進度、總結、反問)一律使用**繁體中文(台灣用語)**;僅識別字、檔名、git/docker 指令、API 路徑、程式碼等技術標識保留原文,**不可**使用簡體字。
|
||||
- **編碼無亂碼**:凡輸出含繁體中文、全形標點、emoji,一律 **UTF-8(不含 BOM)**,不得出現問號方框或錯碼。產生/覆寫的 `entrypoint.sh`、`Dockerfile`、`action.yml`、`README.md` 同樣需 UTF-8(不含 BOM)。
|
||||
- **自動執行原則**:除非使用者明確要求先確認,或遇到不可忽略的必要決策,否則各階段只需輸出簡短計畫/進度後直接執行到完成。**一定會中斷詢問的點**:階段 B 主程式「非 Node 需改寫」時(破壞性,須先確認),以及階段 E 由 `/jsc:doc-funcs` 自身的「如何實作」詢問。
|
||||
- **不破壞既有工作**:移動 `.js`、改寫主程式、覆寫 `entrypoint.sh`/`Dockerfile`/`action.yml` 前,若工作區有未提交變更,先提醒使用者建議先 commit/備份;**絕不** `reset --hard`/`checkout -f`/`clean`,也不刪除使用者既有原始碼。移動檔案優先用 `git mv` 以保留歷史。
|
||||
- **保留行為**:Node 化只「翻譯」既有邏輯,不得擅自改變對外行為、輸入輸出契約或副作用;任何無法可靠等價推論的改動一律不做,並以註解或回報標註「需人工確認」。新增 `input` 僅限依「參數來源優先序」經使用者同意後為之。
|
||||
- **不擴及無關檔案**:本 skill 只動 action 專案根目錄內的:主程式、主程式依賴鏈的 `.js`(搬移到 `src/`)、`package.json`、`action.yml`/`action.yaml`、`entrypoint.sh`、`Dockerfile`、`.dockerignore`,以及階段 E 由 doc-funcs 流程處理的目標;排除 `node_modules`/`.git`/`.docs`/`bin`/`obj`/第三方依賴。
|
||||
執行本 skill 前,先以 Skill 工具載入下列共用規範並全程遵守;**任一載入不到(generic plugin 未安裝)時,先詢問使用者是否安裝 generic plugin(`https://gitea.jsc.idv.tw/plugins/generic.git`),使用者不安裝則直接中斷本 skill**,不得只憑下方一行摘要繼續執行:
|
||||
|
||||
- `/jsc:spec-output`:繁體中文(台灣用語)、UTF-8(不含 BOM)無亂碼。
|
||||
- `/jsc:spec-execution`:自動執行原則(必要決策才中斷)、不臆測/需人工確認、不擴及無關檔案。
|
||||
- `/jsc:spec-git-safety`:不破壞既有工作(絕不 `reset --hard`/`clean`)、`git mv` 保留歷史。
|
||||
- `/jsc:spec-action-params`:action 參數來源優先序(環境變數 → 經同意新增 `inputs`)、`secrets`/`vars` 一律視為不可用。
|
||||
- `/jsc:spec-time-log`:更新時間 Asia/Taipei `yyyy/MM/dd HH:mm:ss`、完成後統一同步時間戳。
|
||||
- `/jsc:spec-dockerfile`:Dockerfile 六步流程、多階段建置、固定版號、自我檢查。
|
||||
- `/jsc:spec-doc-funcs-handoff`:最終階段完整執行 `/jsc:doc-funcs` 的標準流程。
|
||||
|
||||
本 skill 特有補充:
|
||||
|
||||
- **一定會中斷詢問的點**:階段 B 主程式「非 Node 需改寫」時(破壞性,須先確認),以及階段 E 由 `/jsc:doc-funcs` 自身的「如何實作」詢問。
|
||||
- **保留行為**:Node 化只「翻譯」既有邏輯,不得擅自改變對外行為、輸入輸出契約或副作用;任何無法可靠等價推論的改動一律不做,並以註解或回報標註「需人工確認」。新增 `input` 僅限依 `/jsc:spec-action-params` 經使用者同意後為之。
|
||||
- **本 skill 只動**:action 專案根目錄內的主程式、主程式依賴鏈的 `.js`(搬移到 `src/`)、`package.json`、`action.yml`/`action.yaml`、`entrypoint.sh`、`Dockerfile`、`.dockerignore`,以及階段 E 由 doc-funcs 流程處理的目標。
|
||||
|
||||
---
|
||||
|
||||
## 參數來源優先序(開發中需要新參數時)
|
||||
|
||||
從零建立(A1a)、主程式 Node 化(階段 B)、產生 `entrypoint.sh`(階段 C)或產生 `Dockerfile`(階段 D)的過程中,若需要新的參數值,依下列順序處理,**前一項可取得就不往下**:
|
||||
|
||||
1. **runner 注入的執行期環境變數(`gitea.*`/`github.*` context 的同源資訊)**:Docker 容器 action 的 `action.yml` 內 expression 幾乎只有 `inputs`/`env` context 可用,但 runner 會把 `gitea.*`/`github.*` 的同源資訊以**執行期環境變數注入容器**——Node 主程式以 `process.env.GITHUB_*` 讀取(如 `GITHUB_REPOSITORY`、`GITHUB_SERVER_URL`、`GITHUB_REF_NAME`、`GITHUB_EVENT_PATH`;Gitea 亦提供 `GITEA_*` 同義變數),`entrypoint.sh` 內以 `$GITHUB_*` 讀取。為同時相容 GitHub Actions,程式內建議讀 `GITHUB_*`。
|
||||
2. **環境變數無法取得 → 詢問使用者新增 `inputs`**:以 `AskUserQuestion` 詢問使用者是否新增對應 `input`(名稱/description/`required`/`default`),經同意後於 `inputs` 宣告,容器內以 `INPUT_<大寫名稱>` 環境變數取用(Node 主程式讀 `process.env.INPUT_<NAME>`);未經同意**不得**擅自更動 `inputs`/`outputs` 契約。
|
||||
|
||||
**secrets/vars 一律視為不可用,不列入優先序**:`${{ secrets.* }}`/`${{ vars.* }}` context 在 Docker 容器 action 的 `action.yml`(`runs.args`/`runs.env`)內於 GitHub 為不可用(官方文件僅記載 `inputs` context 可用;runner 也不會把呼叫端的 secrets 自動注入容器);Gitea act_runner 未嚴格檢查 context 可用性、行為無保證。為求兩邊相容,本 skill 一律視為不可用——參數值本質上屬 secrets/vars 者,直接依第 2 項宣告為 `input`,回報時附上呼叫端 workflow 的傳入寫法:
|
||||
|
||||
```yaml
|
||||
- uses: <owner>/<action>@<ref>
|
||||
with:
|
||||
token: ${{ secrets.MY_TOKEN }} # secrets 由呼叫端 workflow 傳入
|
||||
registry: ${{ vars.MY_REGISTRY }} # vars 亦同
|
||||
```
|
||||
從零建立(A1a)、主程式 Node 化(階段 B)、產生 `entrypoint.sh`(階段 C)或產生 `Dockerfile`(階段 D)的過程中,若需要新的參數值,一律依 `/jsc:spec-action-params` 的優先序處理:Docker 容器 action 優先取 runner 注入的執行期環境變數(Node 主程式讀 `process.env.GITHUB_*`、`entrypoint.sh` 讀 `$GITHUB_*`;Gitea 亦提供 `GITEA_*` 同義變數,建議讀 `GITHUB_*` 以相容兩邊),取不到才以 `AskUserQuestion` 經使用者同意新增 `inputs`(容器內以 `INPUT_<大寫名稱>` 取用);`secrets`/`vars` 一律視為不可用,需要時宣告為 `input` 由呼叫端 workflow 傳入(範例見該 spec)。
|
||||
|
||||
---
|
||||
|
||||
@@ -142,7 +139,7 @@ runs:
|
||||
|
||||
在 action 根目錄產生(或覆寫)`entrypoint.sh`:**啟動 node 主程式前,先輸出 action 名稱、用途、更新時間**。
|
||||
|
||||
- **更新時間**語意為「本檔最後由本 skill 產生/更新的時間」,使用台灣時區(Asia/Taipei)並固定為 `yyyy/MM/dd HH:mm:ss`(可用 `TZ='Asia/Taipei' date +'%Y/%m/%d %H:%M:%S'` 取得),**寫成檔內固定字串**(非執行期動態時間)。本階段先寫入暫定時間戳,**階段 E 完成後會統一同步各處時間戳**(見階段 E)。
|
||||
- **更新時間**依 `/jsc: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 "$@"`)。
|
||||
@@ -193,7 +190,7 @@ exec node /action/src/index.js "$@"
|
||||
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 版本:**預設使用產生當下的最新 LTS major 固定 tag**(如 build 基底 `node:22`、runtime 基底 `node:22-slim`)——docker action 每次執行都由 runner 現場 build,用 `latest` 會隨 base 無預警跳版而行為漂移、跨 runner 不一致、無法重現除錯;可查詢 Docker Hub(`https://hub.docker.com/_/node`)確認當前 LTS 版號。帶 `--node-version <tag>` 時改用 `node:<tag>` 與 `node:<tag>-slim`;`latest` 僅在**使用者明確要求**時使用(此時 runtime 用 `node:slim`,因為沒有 `node:latest-slim` 這個 tag)。
|
||||
base image 版本依 `/jsc: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 套件等視主程式需要增刪:
|
||||
|
||||
@@ -234,7 +231,7 @@ 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)。
|
||||
- **版號對齊**:runtime 基底版號需與 build 基底一致。預設 LTS 固定 tag(如 `NODE_VERSION=22`、`NODE_RUNTIME=22-slim`);帶 `--node-version` 時同理對應。tag 已是 `-alpine`/`-slim` 變體(如 `22-alpine`)時,build 與 runtime **直接沿用同一 tag**、不再另組 `-slim`(沒有 `node:22-alpine-slim` 這種 tag)。使用者明確要求 `latest` 時 runtime 用 `node:slim`(**沒有 `node:latest-slim`**)。故一律以獨立的 `NODE_RUNTIME` 參數帶入、不要用 `${NODE_VERSION}-slim` 組裝。
|
||||
- **版號對齊**:依 `/jsc: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 由 doc-funcs 指令檔流程統一補齊。
|
||||
|
||||
@@ -242,16 +239,7 @@ ENTRYPOINT ["/action/entrypoint.sh"]
|
||||
|
||||
## 階段 E:完整執行 /jsc:doc-funcs 處理流程
|
||||
|
||||
容器化與 Node 化完成後,對**整個 action 專案**完整執行 `/jsc:doc-funcs` 流程,替程式碼與指令檔補文件並重建 README:
|
||||
|
||||
- **前置檢查**:先確認 doc-funcs skill 可用(`/jsc:doc-funcs`);不可用則回報並**略過本階段**,於總結標註「未文件化」。
|
||||
- 以階段 A1 的 action 根目錄為目標,執行 `doc-funcs` skill 的完整流程(判斷語言 → 掃描 function 與指令檔 → 建立 `.docs/` 草稿 → 草稿品質檢查 → 詢問使用者如何實作 → 依選擇寫回 → 保守優化 → 重建 README → 錨點檢查 → 清理草稿 → 建置/語法驗證)。
|
||||
- doc-funcs 會涵蓋本次新增/變更的指令檔:`entrypoint.sh`(補齊「用途+更新日期同一註解區塊」與逐行註解)、`Dockerfile`(逐行註解);以及 `src/` 內 Node 主程式與各 function 的文件註解。
|
||||
- doc-funcs 的「如何實作」詢問(全部一起/逐個/其他)由使用者於該流程內裁示,本 skill 不代為決定。
|
||||
- 完成後依 doc-funcs 規範重建根目錄 `README.md`(含台灣時區更新時間、專案列表、功能列表、使用範例)。
|
||||
- **統一時間戳**:doc-funcs 全部完成後,以完成當下的 Asia/Taipei 時間(`yyyy/MM/dd HH:mm:ss`)回頭同步 `entrypoint.sh` 橫幅輸出與註解區塊、`Dockerfile` 註解區塊與 README 的更新時間,**確保各處時間戳一致**。
|
||||
|
||||
> 銜接方式:在本 skill 環境中以 `/jsc:doc-funcs`(或 Skill 工具)啟動 doc-funcs 流程;若該流程需參數,沿用本 skill 的 action 根目錄為目標專案。
|
||||
容器化與 Node 化完成後,以階段 A1 的 action 根目錄為目標,依 `/jsc:spec-doc-funcs-handoff` 對**整個 action 專案**完整執行 `/jsc:doc-funcs` 流程(前置可用性檢查、完整流程、由使用者裁示實作方式、重建 README;本次新增/變更的 `entrypoint.sh`、`Dockerfile` 與 `src/` 內 Node 主程式都會被涵蓋)。完成後依該 spec **統一時間戳**:回頭同步 `entrypoint.sh` 橫幅輸出與註解區塊、`Dockerfile` 註解區塊與 README 的更新時間,確保各處一致。
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user