委派判定接進五支技能異動流程，清單不再會與實際技能脫節 #69

2026-09-03T07:03:42Z

jiantw83 commented

2026-09-03 07:03:42 +00:00

摘要

需求描述：上一輪建好了判準文件、委派清單與檢核腳本，但沒有任何一支技能會去用它。清單不接進流程，過幾天就跟實際技能脫節，回到手工盤點的老問題。這張 PR 把判定接進五支技能異動流程。
計畫名稱：無
計畫頁：無
分析頁：無

變更內容

檔案	為什麼改
`skills/skill-new/SKILL.md`	決策樹加委派判定與接續技能那一題，產出判定列並列為完成條件——沒有那一列不算建立完成
`skills/skill-update/SKILL.md`	動到流程或描述就重判，只改文案可沿用但要更新版本號；改名時連動別列的接續欄
`skills/skill-delete/SKILL.md`	刪掉清單那一列並連動別列的接續欄；待辦簿那一半據實標記尚未接線
`skills/skillset-update/SKILL.md`	逐支重判一支都不能跳；sub agent 只回傳判定列，主 agent 收齊一次併檔
`skills/skill-check/SKILL.md`	清單一致性排進第一組檢查，成為新的子項
`references/behaviors.md`	五支技能各四欄跟著改，觸發時機未動
三份 manifest	版號 0.3.2 升到 0.3.3

設計重點

「回 0 但帶提示」在五支裡都寫成同一句話的變體。 版本落後與待複核的種入列都回結束碼 0，那是提示不是缺失，不能因為看到輸出就判成失敗。理由每一支都寫：版本號是 domain 層級，改一支會標到整個 domain，當成缺失看每次發版整片紅，提示很快就沒人看。各支另外點名該支唯一該動手的提示形態——例如修改技能時，指名本次改到那幾支的版本落後，代表該搬的版本號沒搬。
檢核腳本吃的是根目錄、不是 domain 路徑，所以整輪只跑一次。 五支都寫明這一點，避免被寫成逐 domain 跑。

接線時撞到的四個問題，一併處理

這四個都不在原本的規格裡，是接線過程中才浮現的。不處理的話接線會是半殘的。

跨存取庫 PR。 清單放在技能組的中樞存放庫，但改的技能常在別的存放庫。四支異動技能各加一條「不在中樞時另開一條清單 PR」，並把「技能 PR 開了、清單 PR 沒開」列進部分完成。不加的話清單改動沒有落地路徑。
併發寫入。 一次改多支那一支是平行處理，每個 sub agent 改自己的存放庫。那個設計在各改各的檔案時完全正確，一加入全技能組共用的單一清單就變成資料競爭——多個 sub agent 各寫各的會互相蓋掉，最後留下誰的是隨機的、出事重現不出來。改成 sub agent 只回傳判定列，主 agent 收齊後一次併檔。例行稽核那一支同樣的問題同樣處理。
改名與刪除的連動。 技能改名或刪除之後，別列指過來的接續欄會變成指向不存在的技能，那正是檢核腳本會抓出來的一種缺失。修改與刪除兩支都加了連動處理。
參照盤點重複處理。 刪除那一支的盤點工具會撈到清單那一列，盤點步驟與刪除步驟都可能去改它。明寫留給刪除步驟，盤點步驟的完成條件多一種合法結論。

另外補一個判準與清單結構之間的縫：清單十一欄沒有備註欄，多寫一欄會被檢核以「這一列有十二欄」擋下，所以「沿用前一輪判定」寫進 PR 描述與異動報告，列上只動版本號。

兩件刻意沒做的事

委派清單沒有加進審核檢查清單。 那份清單每一項都是逐 domain 判定，各 domain 的 sub agent 逐項對照；委派清單是整輪一份、根目錄層級、只存在於中樞存放庫。加進去會讓每個 domain 的 sub agent 各判一次同一個檔，正是把它排進第一組要避免的事。改成在例行稽核裡明寫它不是那幾項之一。要它進審核清單的話，得同時處理「逐 domain 清單裡放一個整輪項目」的合併規則，那是另一輪的工。
待辦簿那一半據實標記尚未接線。 規格要求刪除技能時「移除待辦簿裡引用它的內建項」，但待辦簿本身還不存在。文件寫明這一半還沒接、本技能不去找它，並要求把這件事帶進異動報告，免得日後被讀成已經清乾淨。寫死一個指向不存在東西的步驟，比誠實標記未完成更糟。

測試結果

lint-scripts.sh、check-behaviors.sh、ste100-lint.sh 對這個存放庫都回結束碼 0。
check-delegate.sh 回結束碼 0，35 列對 35 支。
順手多跑兩支：lint-frontmatter.sh 回 0（例行稽核那一支的描述多了一個工具名，句數沒增加）、check-link-format.sh 回 0（新加的判準文件連結都是正確形式，相對路徑從技能目錄指得到）。
例行稽核那一支的子項重新編號（原本的 7、8、9 順移為 8、9、10），改之前確認過全檔與其他檔案都沒有以編號引用那三項。
這一批只改文件，沒有可執行的腳本變動。
附帶一個活例：中樞存放庫那七列的版本號還是上一版、落後現行版本，檢核照樣回 0 只印提示。那正好證明「回 0 帶提示」的路由是對的。

前置 Push Request

無（上一輪的地基已合併進 develop）

## 摘要 - 需求描述：上一輪建好了判準文件、委派清單與檢核腳本，但沒有任何一支技能會去用它。清單不接進流程，過幾天就跟實際技能脫節，回到手工盤點的老問題。這張 PR 把判定接進五支技能異動流程。 - 計畫名稱：無 - 計畫頁：無 - 分析頁：無 ## 變更內容 | 檔案 | 為什麼改 | | --- | --- | | `skills/skill-new/SKILL.md` | 決策樹加委派判定與接續技能那一題，產出判定列並列為完成條件——沒有那一列不算建立完成 | | `skills/skill-update/SKILL.md` | 動到流程或描述就重判，只改文案可沿用但要更新版本號；改名時連動別列的接續欄 | | `skills/skill-delete/SKILL.md` | 刪掉清單那一列並連動別列的接續欄；待辦簿那一半據實標記尚未接線 | | `skills/skillset-update/SKILL.md` | 逐支重判一支都不能跳；sub agent 只回傳判定列，主 agent 收齊一次併檔 | | `skills/skill-check/SKILL.md` | 清單一致性排進第一組檢查，成為新的子項 | | `references/behaviors.md` | 五支技能各四欄跟著改，觸發時機未動 | | 三份 manifest | 版號 0.3.2 升到 0.3.3 | ## 設計重點 - **「回 0 但帶提示」在五支裡都寫成同一句話的變體。** 版本落後與待複核的種入列都回結束碼 0，那是提示不是缺失，不能因為看到輸出就判成失敗。理由每一支都寫：版本號是 domain 層級，改一支會標到整個 domain，當成缺失看每次發版整片紅，提示很快就沒人看。各支另外點名該支唯一該動手的提示形態——例如修改技能時，指名本次改到那幾支的版本落後，代表該搬的版本號沒搬。 - **檢核腳本吃的是根目錄、不是 domain 路徑，所以整輪只跑一次。** 五支都寫明這一點，避免被寫成逐 domain 跑。 ## 接線時撞到的四個問題，一併處理這四個都不在原本的規格裡，是接線過程中才浮現的。不處理的話接線會是半殘的。 - **跨存取庫 PR。** 清單放在技能組的中樞存放庫，但改的技能常在別的存放庫。四支異動技能各加一條「不在中樞時另開一條清單 PR」，並把「技能 PR 開了、清單 PR 沒開」列進部分完成。不加的話清單改動沒有落地路徑。 - **併發寫入。** 一次改多支那一支是平行處理，每個 sub agent 改自己的存放庫。**那個設計在各改各的檔案時完全正確，一加入全技能組共用的單一清單就變成資料競爭**——多個 sub agent 各寫各的會互相蓋掉，最後留下誰的是隨機的、出事重現不出來。改成 sub agent 只回傳判定列，主 agent 收齊後一次併檔。例行稽核那一支同樣的問題同樣處理。 - **改名與刪除的連動。** 技能改名或刪除之後，別列指過來的接續欄會變成指向不存在的技能，那正是檢核腳本會抓出來的一種缺失。修改與刪除兩支都加了連動處理。 - **參照盤點重複處理。** 刪除那一支的盤點工具會撈到清單那一列，盤點步驟與刪除步驟都可能去改它。明寫留給刪除步驟，盤點步驟的完成條件多一種合法結論。另外補一個判準與清單結構之間的縫：清單十一欄沒有備註欄，多寫一欄會被檢核以「這一列有十二欄」擋下，所以「沿用前一輪判定」寫進 PR 描述與異動報告，列上只動版本號。 ## 兩件刻意沒做的事 - **委派清單沒有加進審核檢查清單。** 那份清單每一項都是**逐 domain** 判定，各 domain 的 sub agent 逐項對照；委派清單是整輪一份、根目錄層級、只存在於中樞存放庫。加進去會讓每個 domain 的 sub agent 各判一次同一個檔，正是把它排進第一組要避免的事。改成在例行稽核裡明寫它不是那幾項之一。要它進審核清單的話，得同時處理「逐 domain 清單裡放一個整輪項目」的合併規則，那是另一輪的工。 - **待辦簿那一半據實標記尚未接線。** 規格要求刪除技能時「移除待辦簿裡引用它的內建項」，但待辦簿本身還不存在。文件寫明這一半還沒接、本技能不去找它，並要求把這件事帶進異動報告，免得日後被讀成已經清乾淨。寫死一個指向不存在東西的步驟，比誠實標記未完成更糟。 ## 測試結果 - `lint-scripts.sh`、`check-behaviors.sh`、`ste100-lint.sh` 對這個存放庫都回結束碼 0。 - `check-delegate.sh` 回結束碼 0，35 列對 35 支。 - 順手多跑兩支：`lint-frontmatter.sh` 回 0（例行稽核那一支的描述多了一個工具名，句數沒增加）、`check-link-format.sh` 回 0（新加的判準文件連結都是正確形式，相對路徑從技能目錄指得到）。 - 例行稽核那一支的子項重新編號（原本的 7、8、9 順移為 8、9、10），改之前確認過全檔與其他檔案都沒有以編號引用那三項。 - 這一批只改文件，沒有可執行的腳本變動。 - 附帶一個活例：中樞存放庫那七列的版本號還是上一版、落後現行版本，檢核照樣回 0 只印提示。那正好證明「回 0 帶提示」的路由是對的。 ## 前置 Push Request - 無（上一輪的地基已合併進 `develop`）

jiantw83 added 2 commits 2026-09-03 07:03:42 +00:00

feat(meta): 委派判定接進五支技能異動流程 1a34529231

上一輪建好了判準文件、清單與檢核腳本，但沒有任何一支技能會去用它。清單不接進流程，過幾天就跟實際技能脫節，回到手工盤點的老問題。

新增技能要走完決策樹五題加接續技能那一題，產出判定結果寫進清單，沒有那一列不算建立完成。修改技能動到流程或描述就重判，只改文案可沿用舊結論但要更新版本號。刪除技能要刪掉那一列。一次改多支要逐支重判，一支都不能跳。例行稽核把清單一致性排進第一組檢查。

檢核腳本的四個結束碼在五支裡逐一路由。特別寫清楚「回 0 但帶提示」那一種：版本落後與待複核的種入列都回 0，那是提示不是缺失，不能因為看到輸出就判成失敗。版本號是 domain 層級，改一支會標到整個 domain，當成缺失看每次發版整片紅，提示很快就沒人看。

接線時撞到四個原本沒看到的問題，一併處理：

清單放在技能組的中樞存放庫，但改的技能常在別的存放庫，所以四支異動技能各加一條「不在中樞時另開一條清單 PR」，並把「技能 PR 開了、清單 PR 沒開」列進部分完成。不加的話清單改動沒有落地路徑。

一次改多支那一支是平行處理，每個 sub agent 改自己的存放庫。那個設計在各改各的檔案時正確，一加入全技能組共用的單一清單就變成資料競爭。改成 sub agent 只回傳判定列，主 agent 收齊後一次併檔。

技能改名或刪除時，別列指過來的接續欄會變成指向不存在的技能，那正是檢核腳本會抓出來的一種缺失。修改與刪除兩支都加了連動處理。

刪除那一支的參照盤點會撈到清單那一列，盤點步驟與刪除步驟都可能去改它。明寫留給刪除步驟，盤點步驟的完成條件多一種合法結論。

清單十一欄沒有備註欄，多寫一欄會被檢核擋下，所以「沿用前一輪判定」寫進 PR 描述與異動報告，列上只動版本號。

刪除技能還要「移除待辦簿裡引用它的內建項」，但待辦簿本身還不存在，那一半據實寫成尚未接線，並要求帶進異動報告，免得日後被讀成已經清乾淨。

委派清單沒有加進審核檢查清單。那份清單每一項都是逐 domain 判定，委派清單是整輪一份、只存在於中樞存放庫；加進去會讓每個 domain 的 sub agent 各判一次同一個檔。改成在例行稽核裡明寫它不是那幾項之一。

chore(plugin): 三份 manifest 升版至 0.3.3 f1825fd653

委派判定的接線要靠版號才傳得到機器端。

三份 manifest 由 sync-skill-manifest.sh 同步，只動版本欄位。

admin merged commit 9877e19bbd into develop

2026-09-03 07:24:28 +00:00

admin deleted branch feat/wire-delegate-spec-into-change-skills

2026-09-03 07:24:28 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: plugins/meta#69