jiantw83
f586a6b69f
What：README.md、references/behaviors.md 與 skills/hooks-install/SKILL.md 同步這一批的接線事實。 Why： - 文件寫著「這些 CLI 沒有 pre-tool hook」。那句話是錯的，也正是三支 CLI 長期沒有守門的原因。照著它報告，會讓使用者以為只有 claude 有保護、其餘四支本來就接不上。 - kiro 的 degraded 原本被寫成接線缺東西，實際上是那支 CLI 擋不下技能叫用。兩件事的處理方式完全不同。 How： - 一支 CLI 一列，列出接線位置、事件與 matcher、阻擋形態與判定，並寫明 claude、codex、copilot、antigravity 回 wired，kiro 回 degraded。 - 新增驗證等級表，把「形狀」與「觸發」分開記：形狀是那支 CLI 真的讀得懂設定，觸發是 hook 真的被叫用過。copilot 的形狀未證、antigravity 與 codex 的觸發未驗證，一律照實列出，不含糊帶過。 - README 補上 hooks/skill-name.sh 與 hooks/deny.sh 兩列，並補 COPILOT_HOME、KIRO_HOME、JSC_ANTIGRAVITY_HOOKS、JSC_COPILOT_INSTRUCTIONS、JSC_ANTIGRAVITY_RULES 幾個環境變數。 - kiro 的接線位置從 .kiro/hooks/jsc-hooks.json 全面改寫成 ~/.kiro/agents/jsc.json。 - 講明 write-guard.sh 三個模式與 SDLC 模型鎖在另外三支上是「還沒接」，不是「沒有 hook 可接」。 - behaviors.md 的完成條件與可驗證跡象跟著改，repair 那一列加上「技能名解析改 skill-name.sh、阻擋形態改 deny.sh，兩支是唯一真實來源」。 Who：codex、copilot、antigravity、kiro 四支 CLI 的 pre-tool hook 接線修正。
4.8 KiB
4.8 KiB
jsc-hooks 技能行為清單
本頁記錄 jsc-hooks 每支技能的行為基準，供技能驗證比對。技能異動時，在同一個 PR 內一起更新這一頁。
hooks-install
| 項目 | 內容 |
|---|---|
| 觸發時機 | 裝好或更新完 jsc 技能組之後，要把九支 hook 接線到每一支已安裝的 CLI 時用；jsc-cli:deploy 收尾會把偵測到的 CLI 清單交給它。不用於撰寫新的 hook，也不用於單獨修一支壞掉的 hook，那是 jsc-hooks:repair 的事 |
| 關鍵步驟 | 取得 CLI 清單（呼叫端交來的優先，沒有才自己跑 detect-clis.sh）、第一支 CLI 單獨跑完整條管線（它負責更新共用的 $JSC_HOME/current/jsc-hooks 連結）、其餘 CLI 一支一個 sub agent 並行、每支 CLI 依序走 purge、接線、status、smoke、scan 五道關卡、讀每道關卡自己印的第一行判定、任一關卡出錯就寫 ERROR_{HASH} 並轉給 jsc-hooks:repair、逐 CLI 回報五道關卡的結果 |
| 外部呼叫 | tools/wire-cli.sh purge、tools/wire-cli.sh {cli}、tools/wire-cli.sh status、tools/wire-cli.sh smoke、tools/scan-hook-errors.sh、tools/report-error.sh、jsc-cli/tools/detect-clis.sh、jsc-hooks:repair 技能、jsc-gitea:wiki（寫 ERROR_{HASH} 時經 report-error.sh）；接線腳本內部另呼叫 hooks/skill-name.sh 與 hooks/deny.sh 做冒煙斷言 |
| 完成條件 | 每一支偵測到的 CLI 都有五道關卡各一行判定，沒有任何一道回結束碼 2，smoke 的 lines 條數與它自己的斷言相符，claude、codex、copilot、antigravity 回 wired 而 kiro 回 degraded（CLI 擋不下技能叫用），四支非 claude 的執行期錯誤掃描一律據實回 unavailable，各 CLI 的形狀與觸發驗證等級分開寫進回報（codex、antigravity、kiro 形狀實證，copilot 形狀未證；kiro 觸發部分實證，其餘未驗證），而且每一筆錯誤都帶一個 ERROR_{HASH} 結果與一條對 develop 的修正 PR 連結 |
| 可驗證跡象 | 各 CLI 的設定檔多出 jsc 段落：codex 的 config.toml 標記段落、hooks/codex-hooks.json（從 hooks/hooks.json 推導，matcher Skill 換成 Bash）與 .codex-plugin/plugin.json 指過去的 hooks 路徑字串、copilot 的 ~/.copilot/settings.json 頂層 hooks 鍵（matcher skill，合併不覆寫，enabledPlugins 與第三方條目原樣保留）與 $COPILOT_HOME 底下的指引檔、antigravity 的 ~/.gemini/config/hooks.json 的 jsc 段落（PreToolUse 為 Grouped、matcher ^view_file$，PreInvocation 維持 Flat）、kiro 的 ~/.kiro/agents/jsc.json（hooks 為 agentSpawn、userPromptSubmit、stop 三個合法事件加 timeout_ms、兩層 skill:// glob 的 resources、明列的 tools，並通過 kiro-cli agent validate）與 ~/.kiro/settings/cli.json 的 chat.defaultAgent=jsc；四支非 claude 的接線命令都以 JSC_CLI={代號} 前綴自帶 CLI 代號，缺了它兩道閘門解不出技能名、一律安靜放行，所以 status 把它列成單獨一項；另有 $JSC_HOME/current/jsc-hooks 符號連結建立或更新、$JSC_HOME/backup/hooks/{cli}/{時間戳}/ 留下 purge 前的備份、出錯時 wiki 多一頁 ERROR_{HASH} 並在 ERROR_CONTENTS 補一列、修正路徑留下一條對 develop 的 PR |
repair
| 項目 | 內容 |
|---|---|
| 觸發時機 | hooks-install 或 report-error.sh 回報某一支 hook 失敗時用，或是重新接線之後那支 hook 還是一直失敗時用。不用於例行接線，也不用於與 hook 無關的修改 |
| 關鍵步驟 | 從 ERROR_{HASH} 讀失敗情境（沒有頁就讀失敗的 status= 那一行，讀不到就停下來問）、跑 detect-clis.sh、每一支偵測到的 CLI 各開一個唯讀 sub agent 診斷並交回根因、要改的檔案與驗證指令、挑最小的修正改進 hooks 存取庫（技能名解析改 hooks/skill-name.sh、阻擋形態改 hooks/deny.sh，兩支是唯一真實來源，不在閘門裡各補一份）、跑 wire-cli.sh smoke {cli} 驗到 exit 0、跑 sync-skill-manifest.sh . 同步版本、以 jsc-git:pr 對 develop 開 PR |
| 外部呼叫 | jsc-gitea:wiki、jsc-cli/tools/detect-clis.sh、tools/wire-cli.sh smoke、jsc-meta/tools/sync-skill-manifest.sh、jsc-git:pr；診斷階段另以 sub agent 叫用各支已安裝的 AI CLI |
| 完成條件 | 修正已經落在磁碟上、wire-cli.sh smoke 對受影響的 CLI 回 exit 0、sync-skill-manifest.sh 回 exit 0 而且三份 manifest 版本一致，最後拿到一條對 develop 的 PR 連結；開不出 PR 時要講明修正已套用但尚未合併、帶上分支名與失敗原因 |
| 可驗證跡象 | hooks 存取庫多一個修正提交與一條推上去的分支、develop 上多一條 PR、三份 manifest 與 README 技能清單版本一致、wire-cli.sh smoke 由失敗轉為 exit 0 |