Files
cli/skills/setup/SKILL.md
jiantw83 e655f9a963 feat(setup): 新增引導與自動設定技能
What: 新增 jsc-cli:setup,讀 doctor 的待修清單逐項確認後修復,並新增 tools/apply-config.sh 負責實際寫入。
Why: 體檢找得出問題,修還是得靠人一個一個查文件。修法又分三種:算得出來的、要人給值的、只能手動的,混在一起講不清楚。
How: 依規格表的 fix 欄分流,auto 直接寫、ask 先用決策樹問到值、manual 印步驟。複合修復交回原主(deploy、hooks-install、models)。apply-config.sh 只動 rc 檔的 # jsc-config 標記段落,寫前備份到 $JSC_HOME/backup/config/,寫後重讀驗證,fish 自動改用 set -gx 語法。
Who: 體檢與修復流程,接在 jsc-cli:doctor 之後。
2026-08-26 10:43:50 +08:00

4.2 KiB


name: setup description: Fix what jsc-cli:doctor found, one confirmed item at a time. Read the 待修項目 table from wiki CHECK_{HASH}, or rebuild it with tools/scan-config.sh and jsc-hooks/tools/wire-cli.sh status when no page exists. Route each item by its fix column - auto writes it through tools/apply-config.sh, ask collects the value through the jsc-ask decision tree first, manual prints the steps for the operator. Delegate compound repairs to their owners: jsc-cli:deploy for a plugin whose version is behind, jsc-hooks:hooks-install for unwired hooks, jsc-cli:models for a missing model-tags.tsv. Re-verify every item after writing and rewrite the CHECK page; use when doctor reports something to fix, not for a read-only checkup.

setup — guide or apply the fixes doctor found

This skill writes. Every write is confirmed first, backed up, and verified afterwards.

1. Get the work list

Read the 待修項目 table from wiki CHECK_{HASH} — repo from jsc-gitea/tools/gitea.sh wiki-repo CHECK, page name from gitea.sh hash-id "{hostname}/{user}".

No page, or wiki-repo exits 3 → rebuild the list here: tools/scan-config.sh scan all for settings, jsc-hooks/tools/wire-cli.sh status {cli} per detected CLI for wiring, jsc-hooks/hooks/version-guard.sh report for versions. Rebuilding MUST run as a sub agent.

State which source the list came from. A stale page and a live scan can disagree, and the operator has to know which one is on screen.

Done when every item carries its scope, verdict and fix route.

2. Confirm each item

Ask per the jsc-ask:ask decision tree, one item at a time, in the table's order. Every option states its impact scope: which file gets written, which skills start working, what stays broken when skipped.

An ask item needs its value in the same question — the wiki repo as {owner}/{repo}, the Gitea host, the directory path. Never invent one.

Skipping is always an option and is recorded as skipped, not as fixed.

Done when every item is either confirmed with a value or recorded as skipped.

3. Apply

Route Action
auto on a variable tools/apply-config.sh set {KEY} {VALUE}
auto on a directory tools/apply-config.sh mkdir {PATH}
ask same two commands, with the value the user just gave
manual print the exact steps and the file to edit; the operator does it
domain 落後 call jsc-cli:deploy, mode update
hook unwired call jsc-hooks:hooks-install
$JSC_HOME/model-tags.tsv missing call jsc-cli:models

apply-config.sh writes into the # jsc-config block of every existing shell rc file, backs each one up to $JSC_HOME/backup/config/{timestamp}/ before touching it, and rewrites the block whole. It never edits anything outside that block.

Report the backup path it prints. That path is the whole undo story for this run.

Done when every confirmed item has a wrote, created or delegated result.

4. Re-verify

Rerun the check that produced each item — tools/scan-config.sh scan {scope} for settings, wire-cli.sh status {cli} for wiring, version-guard.sh report for versions.

An item that still fails is reported as 未修好 with the reason. Never mark it fixed because the write succeeded: writing the variable and the variable verifying are two different facts.

A newly written rc block does not affect the running shell. Tell the operator to open a new shell or source the rc file, and give them the export line for the current session. A re-verify that reads the current environment will still show the variable unset — say so rather than reporting a false failure.

Done when every applied item has a fresh verdict from its own checker.

5. Record

Rewrite CHECK_{HASH} through jsc-gitea:wiki with the post-fix state, per templates/check-page.md, and refresh the CHECK_CONTENTS row. The page keeps only the latest run, so this overwrites the pre-fix picture on purpose.

No wiki repo configured → report the tables on screen and say the record was skipped.

Then state the counts: fixed, skipped, delegated, and 未修好. Recommend /jsc-cli:doctor for a clean re-check when anything was delegated.

Done when the page is written or the skip is reported, and the four counts are stated.