Merge pull request '發佈 jsc-meta 技能檢查更新到 master' (#41) from develop into master

Reviewed-on: #41
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "jsc-meta",
-  "version": "0.1.8",
+  "version": "0.2.1",
   "description": "技能組自我管理：新建、更新、刪除技能與技能準則",
   "skills": "./skills",
   "author": {

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "jsc-meta",
-  "version": "0.1.8",
+  "version": "0.2.1",
   "description": "技能組自我管理：新建、更新、刪除技能與技能準則",
   "skills": "./skills",
   "jsc": {

README.md

@@ -42,7 +42,7 @@ Marketplace 統一為 `jsc`（https://gitea.jsc.idv.tw/plugins/meta.git），安
 
 ### `skill-check`
 
-例行稽核——沒有變更需求時，把整個技能組逐一對照準則的審核檢查清單，再分開跑流程優化審查。優化面向包含可平行化、可下放工具、重複來回、冗餘步驟、過早或過晚的閘門；不符項目與優化建議分開回報，逐項決策樹確認後才套用，最後逐 repo 開 PR。有變更需求改用 skillset-update。
+例行稽核——沒有變更需求時，先跑腳本語法檢查與 hook smoke，再把整個技能組逐一對照準則的審核檢查清單，並分開跑流程優化審查。優化面向包含可平行化、可下放工具、重複來回、冗餘步驟、過早或過晚的閘門；不符項目與優化建議分開回報，逐項決策樹確認後才套用，最後逐 repo 開 PR。有變更需求改用 skillset-update。
 
 ### `ste100-sync`
 

plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "jsc-meta",
-  "version": "0.1.8",
+  "version": "0.2.1",
   "description": "技能組自我管理：新建、更新、刪除技能與技能準則",
   "skills": "./skills/",
   "jsc": {

references/guidelines.md

@@ -209,6 +209,8 @@ PR 開立、更新、留言修正的收尾回報格式只看 [`references/pr-rep
 - [ ] gitea 操作透過 gitea.sh 或 tea
 - [ ] wiki repo 與 Gitea 認證先讀目前 shell 繼承的環境變數；只有缺值或無法解析時才詢問；頁面類型不得跨用其他 `JSC_WIKI_REPO_{TYPE}`
 - [ ] 問詢透過 jsc-ask 決策樹規則
+- [ ] `tools/` 與 `hooks/` 內的 shell 腳本都通過 `sh -n`；技能直接呼叫的腳本都存在、可執行，且退出碼有分流
+- [ ] hook 相關變更已用 `jsc-hooks/tools/wire-cli.sh smoke {cli}` 實測；沒有偵測到 CLI 時，至少跑 `smoke codex` 並標明是預設 hook smoke
 - [ ] SKILL.md 整份為英文（要原樣輸出的繁中字面除外）；README、AGENTS、templates、references 為 STE100 繁中；UTF-8 無亂碼
 - [ ] 所有非程式碼輸出（程式碼註解、commit 訊息、PR 描述、wiki 頁、回報、文件）為繁體中文、UTF-8、無亂碼、無簡體字，且 `tools/ste100-lint.sh` 對該 domain 全綠
 - [ ] 已同步更新該 domain 的 README「Skills 目錄」與三份 manifest 的 version

skills/skill-check/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: skill-check
-description: Routine compliance and flow-efficiency audit of the whole jsc skill set with no change request in hand. Sync every domain repo from the Gitea canonical marketplace, audit every skill against guidelines.md, then run a separate optimization review for parallelism, tool extraction, repeated interaction, redundant checks, and misplaced gates. Confirm compliance fixes and optimization suggestions with the user before applying them, re-check until accepted fixes pass, then open a PR per affected repo via jsc-git pr. Use for periodic or on-demand skill-set checks; not for applying a change request (use skillset-update) or editing one skill (use skill-update).
+description: Routine compliance, script, hook, and flow-efficiency audit of the whole jsc skill set with no change request in hand. Sync every domain repo from the Gitea canonical marketplace, validate scripts and hook smoke, audit every skill against guidelines.md, then review parallelism, tool extraction, repeated interaction, redundant checks, and misplaced gates. Confirm compliance fixes and optimization suggestions before applying them, re-check until accepted fixes pass, then open a PR per affected repo via jsc-git pr. Use for periodic or on-demand skill-set checks; not for applying a change request (use skillset-update) or editing one skill (use skill-update).
 ---
 
 # skill-check — audit compliance and flow efficiency
@@ -10,14 +10,21 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
 ## Flow
 
 1. Run `tools/sync-domains.sh` to sync every domain repo of the Gitea canonical marketplace. Completion condition: the script exits 0 and prints one `domain<TAB>path` line per marketplace domain — exit 0 is the only code that means every repo is present and current. Exit 3 means some repos were not updated: reconcile every path named on stderr (commit or stash the dirty tree, or fix the failing pull) and rerun; when the user confirms a dirty tree is intentional local work, record that decision and continue on the local version — never read exit 3 as current. Exit 2 means a domain could not be cloned and exit 1 means the canonical marketplace was unreadable — resolve either before continuing.
-2. Audit every skill of every domain against the guidelines.md audit checklist — this step MUST run as a sub agent, one sub agent per domain repo. Each sub agent reports its findings: skill, failed checklist item, evidence (file:line), proposed fix. Cover the checklist's four flow checks by name, not only the naming and language items:
+2. Validate scripts and hooks before reading skill text:
+   1. For every synced domain repo, run `find {domain-path}/tools {domain-path}/hooks -type f -name '*.sh' -exec sh -n {} \;` for directories that exist. Report each script that fails with path and parser output. Missing `tools/` or `hooks/` directories are not failures.
+   2. For every shell script directly named by a touched or audited SKILL.md, confirm the script exists, is executable when it is meant to be called directly, and documents or implements every exit code the skill routes. Report evidence as `skill file:line -> script path`.
+   3. When the `jsc-hooks` domain is present, run `jsc-hooks/tools/wire-cli.sh smoke {cli}` for every CLI reported by `jsc-cli/tools/detect-clis.sh`. When no CLI is detected, run `jsc-hooks/tools/wire-cli.sh smoke codex` as the minimum hook behavior check and label it 「預設 hook smoke」 in the report. Use `smoke`, not `purge` or rewiring actions.
+   4. When a hook or script smoke fails, route it as a compliance failure with script name, exit code, output summary, and proposed fix. Do not continue to report the affected hook as compliant.
+
+   Completion condition: every domain has a script syntax verdict, every named script has an existence and exit-code-routing verdict, and the `jsc-hooks` domain has a hook smoke verdict.
+3. Audit every skill of every domain against the guidelines.md audit checklist — this step MUST run as a sub agent, one sub agent per domain repo. Each sub agent reports its findings: skill, failed checklist item, evidence (file:line), proposed fix. Cover the checklist's four flow checks by name, not only the naming and language items:
    1. Every step number, file path and section title the skill references — inside itself and in other files — really exists (the pointer points at something).
    2. Every step ends in a checkable completion condition, with no vague wording.
    3. Every external call (script, API, other skill) states what to do on failure and routes every exit code.
    4. No gate the skill installs blocks the only path that lifts that gate.
 
    Completion condition: every domain has an audit result that names a verdict for all checklist items, the four flow checks included.
-3. Run a separate flow optimization review after the compliance audit. Each aspect **MUST run as a sub agent**, and the five aspects may run in parallel:
+4. Run a separate flow optimization review after the compliance audit. Each aspect **MUST run as a sub agent**, and the five aspects may run in parallel:
 
    | Aspect | Scope |
    | --- | --- |
@@ -28,18 +35,18 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
    | 5 Gate timing | Gates that run too early or too late, causing wasted work before a block or blocking the only path that clears the gate |
 
    Each optimization finding reports skill, aspect, evidence (file:line), current flow step count, proposed flow step count, what time or interaction it saves, whether correctness decreases, and which protection would be weakened if any. Keep optimization findings separate from compliance failures. Completion condition: every aspect has returned a verdict for every domain; aspects with no findings return 「無發現」.
-4. Present compliance failures and optimization findings separately via the `jsc-ask:ask` decision tree:
+5. Present compliance failures and optimization findings separately via the `jsc-ask:ask` decision tree:
    - Compliance failure options: apply the proposed fix / skip / custom fix. Every option states its impact scope, for example skipping leaves the skill non-compliant until the next audit.
    - Optimization options: apply / defer / custom. Any suggestion that weakens a protection must name the protection it removes and must not be applied unless the user explicitly accepts that tradeoff.
 
    Completion condition: every compliance failure and every optimization finding has a recorded decision.
-5. Apply the confirmed fixes and accepted optimizations — the file-change part MUST run as a sub agent, one sub agent per affected domain repo: modify the files per the recorded decision. Then run `tools/sync-skill-manifest.sh {domain-path}` directly (no sub agent needed) for each affected domain repo to refresh that domain README's 「Skills 目錄」 section and bump the version in all three manifests. Completion condition: every affected repo carries the changes and the manifest bump.
+6. Apply the confirmed fixes and accepted optimizations — the file-change part MUST run as a sub agent, one sub agent per affected domain repo: modify the files per the recorded decision. Then run `tools/sync-skill-manifest.sh {domain-path}` directly (no sub agent needed) for each affected domain repo to refresh that domain README's 「Skills 目錄」 section and bump the version in all three manifests. Completion condition: every affected repo carries the changes and the manifest bump.
-6. Sync the canonical marketplace — a **required** step, never optional. The canonical pair lives in `plugins/meta` and every domain repo carries a byte-identical copy, so a fix that leaves the copies apart makes some repos register a stale plugin set. Run `tools/sync-marketplace.sh {domain} {repo-url} {description}` once with an existing entry's own current values (rewriting the same entry is idempotent); the script rewrites both canonical files and copies them into every domain repo. Route each exit code:
+7. Sync the canonical marketplace — a **required** step, never optional. The canonical pair lives in `plugins/meta` and every domain repo carries a byte-identical copy, so a fix that leaves the copies apart makes some repos register a stale plugin set. Run `tools/sync-marketplace.sh {domain} {repo-url} {description}` once with an existing entry's own current values (rewriting the same entry is idempotent); the script rewrites both canonical files and copies them into every domain repo. Route each exit code:
    - Exit 3 — written, but some domain repo is not present locally. Run `tools/sync-domains.sh`, then rerun this step.
    - Exit 2 — usage error: the script takes exactly three arguments. Fix them and rerun.
    - Exit 1 — missing python3, an unreadable canonical file, or a byte mismatch between copies. Read stderr, fix the named cause (install python3 for the first), then rerun.
    - Exit 0 — every copy holds identical bytes; the script verifies that itself.
 
    Completion condition: the script exits 0 and prints the touched paths.
-7. Re-check the guidelines.md audit checklist for every touched skill, then re-run the optimization aspect that produced each accepted optimization. On any compliance failure, **return to step 4**: confirm and fix again, until all accepted compliance fixes pass. On an accepted optimization that does not produce the promised step reduction or still weakens correctness beyond the recorded decision, return to step 4 for a new decision. Completion condition: all checklist items pass, and every accepted optimization has a matching verification result.
+8. Re-run the script and hook validation from step 2, re-check the guidelines.md audit checklist for every touched skill, then re-run the optimization aspect that produced each accepted optimization. On any compliance failure, **return to step 5**: confirm and fix again, until all accepted compliance fixes pass. On an accepted optimization that does not produce the promised step reduction or still weakens correctness beyond the recorded decision, return to step 5 for a new decision. Completion condition: all script and hook checks pass, all checklist items pass, and every accepted optimization has a matching verification result.
-8. Call `jsc-git:pr` once per affected domain repo to open a Push Request. Completion condition: every affected repo has a PR URL, and all URLs are reported in one table with the format in `references/pr-report.md`.
+9. Call `jsc-git:pr` once per affected domain repo to open a Push Request. Completion condition: every affected repo has a PR URL, and all URLs are reported in one table with the format in `references/pr-report.md`.

skills/skill-delete/SKILL.md

@@ -32,5 +32,5 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
    1. Force the change into the session — which of the two routes applies depends on where the change has reached, because the marketplace and `version-guard.sh` both read the repository's **default branch** (`master`), so `jsc-cli:deploy` cannot see anything that stopped at `develop`:
       - The PR is merged all the way to `master`: call `jsc-cli:deploy` in update mode so every installed CLI loads the version without the skill, and restart the CLI when it asks (the deploy writes `$JSC_HOME/restart-required`; see guidelines.md「部署後重啟閘門」). When the deploy cannot update a CLI, record which CLIs did load the new version and carry on with one of those; when none did, stop and report the deletion as unverified. Completion condition: `claude plugin list` (or the equivalent command of another installed CLI) prints `jsc-{domain}` at the version the three manifests now carry.
       - The PR is still short of `master` (waiting on review, or merged only into `develop`): deploying is pointless and its completion condition is unreachable, so verify against the **worktree** instead — run the next sub-step against `/root/plugins/{domain}` rather than the installed copy, mark the report as 「工作樹驗證、尚未部署」, and say plainly which release PR still has to merge before the deletion reaches any CLI. Until it merges the skill is still installed and still callable, so say that too. Completion condition: the verification sub-step passed against the worktree and the outstanding release PR is named in the report.
-   2. Verify the function concretely: run `tools/list-skills.sh` and confirm no row carries the deleted `{domain}/{name}`, rerun `tools/verify-skill-removed.sh {domain} {name}` for exit 0, then run every tool and skill that step 5 fixed and confirm each still finishes with its documented exit code — a fix that broke a caller shows up here, not earlier. On any mismatch — the deleted skill still listed, a leftover from exit 1, a fixed caller that now fails — fix the cause and rerun this step from 9.1. Completion condition: the skill is absent from the list, the verification script exits 0 (or its exit 3 stays reported as「無處可查」), and every fixed caller ran.
+   2. Verify the function concretely: run `tools/list-skills.sh` and confirm no row carries the deleted `{domain}/{name}`, rerun `tools/verify-skill-removed.sh {domain} {name}` for exit 0, then run every tool and skill that step 5 fixed and confirm each still finishes with its documented exit code — a fix that broke a caller shows up here, not earlier. 用 `jsc-cli/tools/detect-clis.sh` 偵測已安裝的測試環境 CLI；每個支援非互動 Prompt 的 CLI 都要實際送出一個最小 Prompt，確認 `/jsc-{domain}:{name}` 已消失，或確認替代路徑仍可用，並記錄 CLI 結束碼與 stderr。Prompt 若因 CLI 工具、plugin 安裝、hook 接線、模型標籤表或設定而失敗，先跑 `jsc-cli:doctor`，再用 `jsc-cli:setup` 修復待修項目，然後重跑同一個 Prompt。hook 冒煙測試若失敗，交給 `jsc-hooks:hooks-install`，由它把 hook 接線或執行期錯誤轉給 `jsc-hooks:repair`。若根因是技能組本身的規格、工具或 hook 實作，修正對應 domain，跑 manifest 同步與驗證，然後用 `jsc-git:pr develop` 開 PR；PR 送出後回到本步驟重跑同一個 Prompt。只有每個可測 CLI Prompt 都得到預期結果且沒有非預期 stderr，或該 CLI 以明確原因列為不可測，才能停止。On any mismatch — the deleted skill still listed, a leftover from exit 1, a fixed caller that now fails, a prompt failure, or unexpected stderr — fix the cause and rerun this step from 9.1. Completion condition: the skill is absent from the list, the verification script exits 0 (or its exit 3 stays reported as「無處可查」), every fixed caller ran, every checkable test-environment CLI completed the prompt with the expected result, and every untestable CLI has a stated reason.
    3. Write the change report to wiki page `SKILLSET_{HASH}` — this part MUST run as a sub agent. Call `jsc-gitea:wiki`; `{HASH}` comes from the `{owner}/{repo}` of the domain repo that lost the skill, and the wiki repo resolves through `JSC_WIKI_REPO_SKILLSET` first, then `JSC_WIKI_REPO`. **Append** a section for this change — date, 「刪除」, skill name, changed files (the step 5 inventory verdicts included), PR URL, the step 9.2 verification result per item — and keep every earlier section. Add the page to `SKILLSET_CONTENTS` when it is new. When the write fails — no `{owner}/{repo}` resolves, or `jsc-gitea:wiki` reports an API error — hand the page name and the unwritten entry back to the user and leave this step open; never close the flow on an unwritten report. Completion condition: the page holds the new section plus all earlier sections, and `SKILLSET_CONTENTS` links it.

skills/skill-new/SKILL.md

@@ -38,5 +38,5 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
    1. Force the change into the session — which of the two routes applies depends on where the change has reached, because the marketplace and `version-guard.sh` both read the repository's **default branch** (`master`), so `jsc-cli:deploy` cannot see anything that stopped at `develop`:
       - The PR is merged all the way to `master`: call `jsc-cli:deploy` in update mode so every installed CLI loads the new version, and restart the CLI when it asks (the deploy writes `$JSC_HOME/restart-required`; see guidelines.md「部署後重啟閘門」). When the deploy cannot update a CLI, record which CLIs did load the new version and carry on with one of those; when none did, stop and report the change as unverified. Completion condition: `claude plugin list` (or the equivalent command of another installed CLI) prints `jsc-{domain}` at the version the three manifests now carry.
       - The PR is still short of `master` (waiting on review, or merged only into `develop`): deploying is pointless and its completion condition is unreachable, so verify against the **worktree** instead — run step 6.2 against `/root/plugins/{domain}` rather than the installed copy, mark the report in 6.3 as 「工作樹驗證、尚未部署」, and say plainly which release PR still has to merge before the change reaches any CLI. Completion condition: step 6.2 passed against the worktree and the outstanding release PR is named in the report.
-   2. Verify the function concretely: run `tools/list-skills.sh` and see the `{domain}<TAB>{name}` row for the new skill, then run every tool the skill added with real arguments and compare each exit code against its documented meaning. Invoke `/jsc-{domain}:{name}` once and confirm the CLI loads the SKILL.md body instead of reporting an unknown command. On any mismatch — a missing row, an exit code the tool's own documentation does not describe, an unknown command — fix the cause and rerun this step from 6.1. Completion condition: the row is printed, every added tool ran with an expected exit code, and the command loaded.
+   2. Verify the function concretely: run `tools/list-skills.sh` and see the `{domain}<TAB>{name}` row for the new skill, then run every tool the skill added with real arguments and compare each exit code against its documented meaning. Invoke `/jsc-{domain}:{name}` once and confirm the CLI loads the SKILL.md body instead of reporting an unknown command. 用 `jsc-cli/tools/detect-clis.sh` 偵測已安裝的測試環境 CLI；每個支援非互動 Prompt 的 CLI 都要實際送出一個最小 Prompt，呼叫 `/jsc-{domain}:{name}`，並記錄 CLI 結束碼與 stderr。Prompt 若因 CLI 工具、plugin 安裝、hook 接線、模型標籤表或設定而失敗，先跑 `jsc-cli:doctor`，再用 `jsc-cli:setup` 修復待修項目，然後重跑同一個 Prompt。hook 冒煙測試若失敗，交給 `jsc-hooks:hooks-install`，由它把 hook 接線或執行期錯誤轉給 `jsc-hooks:repair`。若根因是技能組本身的規格、工具或 hook 實作，修正對應 domain，跑 manifest 同步與驗證，然後用 `jsc-git:pr develop` 開 PR；PR 送出後回到本步驟重跑同一個 Prompt。只有每個可測 CLI Prompt 都沒有非預期 stderr，或該 CLI 以明確原因列為不可測，才能停止。On any mismatch — a missing row, an exit code the tool's own documentation does not describe, an unknown command, a prompt failure, or unexpected stderr — fix the cause and rerun this step from 6.1. Completion condition: the row is printed, every added tool ran with an expected exit code, the command loaded, every checkable test-environment CLI completed the prompt without unexpected stderr, and every untestable CLI has a stated reason.
    3. Write the change report to wiki page `SKILLSET_{HASH}` — this part MUST run as a sub agent. Call `jsc-gitea:wiki`; `{HASH}` comes from the `{owner}/{repo}` of the domain repo that gained the skill, and the wiki repo resolves through `JSC_WIKI_REPO_SKILLSET` first, then `JSC_WIKI_REPO`. **Append** a section for this change — date, 「新增」, skill name, changed files, PR URL, the step 6.2 verification result per item — and keep every earlier section. Add the page to `SKILLSET_CONTENTS` when it is new. When the write fails — no `{owner}/{repo}` resolves, or `jsc-gitea:wiki` reports an API error — hand the page name and the unwritten entry back to the user and leave this step open; never close the flow on an unwritten report. Completion condition: the page holds the new section plus all earlier sections, and `SKILLSET_CONTENTS` links it.

skills/skill-update/SKILL.md

@@ -20,5 +20,5 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
    1. Force the change into the session — which of the two routes applies depends on where the change has reached, because the marketplace and `version-guard.sh` both read the repository's **default branch** (`master`), so `jsc-cli:deploy` cannot see anything that stopped at `develop`:
       - The PR is merged all the way to `master`: call `jsc-cli:deploy` in update mode so every installed CLI loads the new version, and restart the CLI when it asks (the deploy writes `$JSC_HOME/restart-required`; see guidelines.md「部署後重啟閘門」). When the deploy cannot update a CLI, record which CLIs did load the new version and carry on with one of those; when none did, stop and report the change as unverified. Completion condition: `claude plugin list` (or the equivalent command of another installed CLI) prints `jsc-{domain}` at the version the three manifests now carry.
       - The PR is still short of `master` (waiting on review, or merged only into `develop`): deploying is pointless and its completion condition is unreachable, so verify against the **worktree** instead — run the next sub-step against `/root/plugins/{domain}` rather than the installed copy, mark the report as 「工作樹驗證、尚未部署」, and say plainly which release PR still has to merge before the change reaches any CLI. Completion condition: the verification sub-step passed against the worktree and the outstanding release PR is named in the report.
-   2. Verify the function concretely: run `tools/list-skills.sh` and see the updated `description` in the skill's row, then run every tool this change touched with real arguments and compare each exit code against its documented meaning. Invoke `/jsc-{domain}:{name}` once and confirm the CLI loads the changed SKILL.md body. On any mismatch — a stale row, an exit code the tool's own documentation does not describe, an unchanged body — fix the cause and rerun this step from 8.1. Completion condition: the row shows the new description, every touched tool ran with an expected exit code, and the command loaded.
+   2. Verify the function concretely: run `tools/list-skills.sh` and see the updated `description` in the skill's row, then run every tool this change touched with real arguments and compare each exit code against its documented meaning. Invoke `/jsc-{domain}:{name}` once and confirm the CLI loads the changed SKILL.md body. 用 `jsc-cli/tools/detect-clis.sh` 偵測已安裝的測試環境 CLI；每個支援非互動 Prompt 的 CLI 都要實際送出一個最小 Prompt，呼叫 `/jsc-{domain}:{name}`，並記錄 CLI 結束碼與 stderr。Prompt 若因 CLI 工具、plugin 安裝、hook 接線、模型標籤表或設定而失敗，先跑 `jsc-cli:doctor`，再用 `jsc-cli:setup` 修復待修項目，然後重跑同一個 Prompt。hook 冒煙測試若失敗，交給 `jsc-hooks:hooks-install`，由它把 hook 接線或執行期錯誤轉給 `jsc-hooks:repair`。若根因是技能組本身的規格、工具或 hook 實作，修正對應 domain，跑 manifest 同步與驗證，然後用 `jsc-git:pr develop` 開 PR；PR 送出後回到本步驟重跑同一個 Prompt。只有每個可測 CLI Prompt 都沒有非預期 stderr，或該 CLI 以明確原因列為不可測，才能停止。On any mismatch — a stale row, an exit code the tool's own documentation does not describe, an unchanged body, a prompt failure, or unexpected stderr — fix the cause and rerun this step from 8.1. Completion condition: the row shows the new description, every touched tool ran with an expected exit code, the command loaded, every checkable test-environment CLI completed the prompt without unexpected stderr, and every untestable CLI has a stated reason.
    3. Write the change report to wiki page `SKILLSET_{HASH}` — this part MUST run as a sub agent. Call `jsc-gitea:wiki`; `{HASH}` comes from the `{owner}/{repo}` of the changed domain repo, and the wiki repo resolves through `JSC_WIKI_REPO_SKILLSET` first, then `JSC_WIKI_REPO`. **Append** a section for this change — date, 「更新」, skill name, changed files, PR URL, the step 8.2 verification result per item — and keep every earlier section. Add the page to `SKILLSET_CONTENTS` when it is new. When the write fails — no `{owner}/{repo}` resolves, or `jsc-gitea:wiki` reports an API error — hand the page name and the unwritten entry back to the user and leave this step open; never close the flow on an unwritten report. Completion condition: the page holds the new section plus all earlier sections, and `SKILLSET_CONTENTS` links it.

skills/skillset-update/SKILL.md

@@ -18,5 +18,5 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
    1. Force the change into the session — which of the two routes applies depends on where the change has reached, because the marketplace and `version-guard.sh` both read each repository's **default branch** (`master`), so `jsc-cli:deploy` cannot see anything that stopped at `develop`:
       - Every affected repo's PR is merged all the way to `master`: call `jsc-cli:deploy` in update mode so every installed CLI loads the new version of **every** affected plugin, and restart the CLI when it asks (the deploy writes `$JSC_HOME/restart-required`; see guidelines.md「部署後重啟閘門」). When the deploy cannot update a CLI, record which CLIs did load the new versions and carry on with one of those; when none did, stop and report the change as unverified. Completion condition: `claude plugin list` (or the equivalent command of another installed CLI) prints every affected `jsc-{domain}` at the version its three manifests now carry.
       - Any affected repo is still short of `master` (waiting on review, or merged only into `develop`): deploying is pointless and its completion condition is unreachable, so verify against the **worktree** instead — run the next sub-step against each `/root/plugins/{domain}` rather than the installed copies, mark the report as 「工作樹驗證、尚未部署」, and list every release PR that still has to merge before the change reaches any CLI. A change spanning several repos reaches the CLIs only when the last of them merges, so name them all. Completion condition: the verification sub-step passed against every affected worktree and every outstanding release PR is named in the report.
-   2. Verify the function concretely: run `tools/list-skills.sh` and check the row of every touched skill against the change, then run every tool this change touched with real arguments and compare each exit code against its documented meaning. Invoke one touched skill per affected domain as `/jsc-{domain}:{name}` and confirm the CLI loads the changed SKILL.md body. On any mismatch — a stale row, an exit code the tool's own documentation does not describe, an unchanged body — fix the cause and rerun this step from 6.1. Completion condition: every touched skill's row matches the change, every touched tool ran with an expected exit code, and one command per affected domain loaded.
+   2. Verify the function concretely: run `tools/list-skills.sh` and check the row of every touched skill against the change, then run every tool this change touched with real arguments and compare each exit code against its documented meaning. Invoke one touched skill per affected domain as `/jsc-{domain}:{name}` and confirm the CLI loads the changed SKILL.md body. 用 `jsc-cli/tools/detect-clis.sh` 偵測已安裝的測試環境 CLI；每個支援非互動 Prompt 的 CLI，都要對每個受影響 domain 實際送出一個最小 Prompt，呼叫一個被異動的技能，並記錄 CLI 結束碼與 stderr。Prompt 若因 CLI 工具、plugin 安裝、hook 接線、模型標籤表或設定而失敗，先跑 `jsc-cli:doctor`，再用 `jsc-cli:setup` 修復待修項目，然後重跑同一個 Prompt。hook 冒煙測試若失敗，交給 `jsc-hooks:hooks-install`，由它把 hook 接線或執行期錯誤轉給 `jsc-hooks:repair`。若根因是技能組本身的規格、工具或 hook 實作，修正對應 domain，跑 manifest 同步與驗證，然後用 `jsc-git:pr develop` 開 PR；PR 送出後回到本步驟重跑同一個 Prompt。只有每個可測 CLI Prompt 都沒有非預期 stderr，或該 CLI 以明確原因列為不可測，才能停止。On any mismatch — a stale row, an exit code the tool's own documentation does not describe, an unchanged body, a prompt failure, or unexpected stderr — fix the cause and rerun this step from 6.1. Completion condition: every touched skill's row matches the change, every touched tool ran with an expected exit code, one command per affected domain loaded, every checkable test-environment CLI completed the prompt without unexpected stderr, and every untestable CLI has a stated reason.
    3. Write the change report to wiki page `SKILLSET_{HASH}` — this part MUST run as a sub agent, one sub agent per affected domain repo. Call `jsc-gitea:wiki`; `{HASH}` comes from that repo's `{owner}/{repo}`, and the wiki repo resolves through `JSC_WIKI_REPO_SKILLSET` first, then `JSC_WIKI_REPO`. **Append** a section for this change — date, 「批次更新」, the change request in one line, touched skills, changed files, PR URL, the step 6.2 verification result per item — and keep every earlier section. Add each page to `SKILLSET_CONTENTS` when it is new. When a write fails — no `{owner}/{repo}` resolves, or `jsc-gitea:wiki` reports an API error — hand the page name and the unwritten entry back to the user and leave this step open; never close the flow on an unwritten report. Completion condition: every affected repo's page holds the new section plus all earlier sections, and `SKILLSET_CONTENTS` links them all.