Files
cli/.codex-plugin/plugin.json
T
jiantw83 f2029d4cd0 feat(cli): 新增 model-config.sh 的 resolve 子指令
What:
在 `tools/model-config.sh` 新增 `resolve {stage}` 子指令。這個指令會取出某個 SDLC 階段的模型鏈(跟 `get {stage}` 用同樣的解析規則:先讀專案的 `.jsc/models`,找不到再讀 `$JSC_HOME/models.conf`),然後印出鏈中第一個模型名稱,當作目前這個 CLI 可用的模型。同時新增 `current_cli()` 這個輔助函式,透過各家 CLI 的環境變數,判斷目前是在 claude、codex、copilot、antigravity、還是 kiro 底下執行。這個版本先把 `current_cli()` 的結果記錄下來,還沒有拿它去過濾模型鏈中不可用的模型,這件事留到之後再做,因為要判斷某個模型是否可用,需要 LLM 層級的判斷,不是單純的 shell script 能做到的。之後的計畫是拿 `current_cli()` 的結果,對照 `references/model-tags.md` 和 `detect-clis.sh`,跳過模型鏈裡不可用的模型。另外,把 README.md 裡 `tools/model-config.sh` 的工具說明表格,加上新的 `resolve {stage}` 子指令說明。版本號也從 0.0.2 升到 0.0.3,同步改了 `plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` 這三份清單檔,這是這個 repo 的慣例:新增功能時要一併升版號。

Why:
jsc-meta:skill-check 這次稽核發現,jsc-sdlc 底下 plan、analyze、implement、maintain 這四個階段的技能,各自都要幫自己的階段挑一個模型,來做 gate check。如果沒有 `resolve` 這個子指令,這四個技能就要各自在技能說明裡,重複寫一次「讀模型鏈、選一個候補模型」的邏輯。這樣容易寫錯,也難維護。

How:
在既有的 `get`/`list` 邏輯基礎上,加一個 `resolve` 子指令,直接回傳模型鏈的第一個模型。同時加上 `current_cli()`,先把偵測 CLI 的能力做出來,但先不接上過濾邏輯,用註解說明後續要怎麼接。文件和版本號一併更新。

Who:
這個功能是給 jsc-sdlc 的四個階段技能(plan、analyze、implement、maintain)用的。它們可以直接呼叫 `resolve {stage}`,取得一個可用的模型名稱,不用各自重複寫模型鏈的判斷邏輯。
2026-08-24 14:49:28 +08:00

7 lines
146 B
JSON

{
"name": "jsc-cli",
"version": "0.0.3",
"description": "CLI 偵測、模型能力標籤與技能庫批次部署",
"skills": "./skills"
}