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

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

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

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

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

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

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

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

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

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

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

委派清單沒有加進審核檢查清單。那份清單每一項都是逐 domain 判定,委派清單是整輪一份、只存在於中樞存放庫;加進去會讓每個 domain 的 sub agent 各判一次同一個檔。改成在例行稽核裡明寫它不是那幾項之一。
This commit is contained in:
2026-09-03 14:43:15 +08:00
parent 737e3560f3
commit 1a34529231
6 changed files with 107 additions and 55 deletions
+16 -6
View File
@@ -20,8 +20,9 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
- Trigger (when to use, when not to, trigger keywords)
- Input and output (can a standard input/output flow move down to `tools/`; does it need Gitea operations — if so, make the skill use `jsc-gitea/tools/gitea.sh` + token)
- Owning domain (offer the domain list from the step 1.1 `domain<TAB>path` rows — the domains registered in the canonical marketplace)
- Delegation verdict — the five decision-tree questions of [`../../references/delegate-criteria.md`](../../references/delegate-criteria.md), in the order that file lists them, plus a sixth question for the `next` column: which skill should run after this one. Ask all six through this same `jsc-ask:ask` tree; never answer them from the model's own reading of the draft flow. Every option states its impact scope: a `full` verdict lets the background assistant run the skill unattended, a `slice` or `cond` verdict leaves the other half in the user's hands, `none` keeps the whole skill there. The `next` question applies to all four verdicts, `none` included — `none` says the assistant does not run this skill for the user, which says nothing about what should follow it — so offer the step 1.1 skill rows as its options and the answer then names a skill that exists.
Completion condition: goal, trigger, input/output and owning domain each have a recorded answer.
Completion condition: goal, trigger, input/output, owning domain and the delegation verdict each have a recorded answer, and the verdict carries a value for every column `delegate-criteria.md` marks mandatory for that verdict, `-` where it marks the column unused.
2. If the domain does not exist (`tools/sync-domains.sh` clones every domain **registered in the marketplace**, so a missing directory means the domain is unregistered — the repository itself may already exist on Gitea):
1. Propose one short English word for the new domain (a single word preferred) and confirm it with the user. Completion condition: the user confirms the domain word.
2. Check before creating: run `jsc-gitea/tools/gitea.sh clone-url plugins/{domain}`. A URL comes back when the repository already exists — clone it, skip creation, and go on to step 2.3 to fill in whatever content is missing. Only when no URL comes back create the repository through the tool, never by hand: `gitea.sh api POST /orgs/plugins/repos` when `plugins` is an organization, `POST /user/repos` when `plugins` is the token's own account (`tea repo create` does the same job). Only when the call is refused (403 — the token has write but not admin rights on the owner) ask the user to create `plugins/{domain}` by hand, then continue. Completion condition: `gitea.sh clone-url plugins/{domain}` prints a URL and cloning it succeeds.
@@ -36,11 +37,20 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
3. Generate the skill per guidelines.md — this step MUST run as a sub agent:
- `skills/{name}/SKILL.md`: entirely in English (description within either cap — ≤ 5 sentences or ≤ 5 steps — and stating when to use and when not to; body in STE100-style English)
- Rules enforceable by hooks go to `jsc-hooks` (never scattered in this domain); standard input/output flows go to `tools/`
- `jsc-meta/tools/delegate-spec.tsv`: append this skill's row, built from the step 1.2 verdict — one skill one row, the eleven tab-separated columns in the order that file's header lists. A column the verdict does not use holds a single `-`; an empty cell and a cell holding a space both fail the checker. `origin` is `judged`, because the verdict came from the decision tree in this same run, and `version` is the version the three manifests carry after the `sync-skill-manifest.sh` run below. **A skill with no row is not created.** The row is the only thing that tells the background assistant this skill exists, so without it every later round is blind to it, and no later step recreates it. The file lives in `plugins/meta` whichever domain gained the skill, so a skill added to another domain changes two repos and step 5 opens the second Push Request for this one.
- `references/behaviors.md`: add one `## {name}` section for the new skill, placed in dictionary order among the existing sections, carrying the five rows the guidelines' 「技能行為清單」 section defines — 觸發時機、關鍵步驟、外部呼叫、完成條件、可驗證跡象. Write what the skill really does; do not copy the `description`. A read-only skill still fills 可驗證跡象 with 「無寫入跡象,只有回報內容」. The behavior list ships in this same PR — a skill added without its section leaves the domain's list out of sync the moment this PR merges. When the domain has no `references/behaviors.md` yet, create it with the header line `# jsc-{domain} 技能行為清單`.
Then run `tools/sync-skill-manifest.sh {domain-path}` directly (no sub agent needed) to sync the domain README's 「Skills 目錄」 section and bump the version in all three manifests. Route each exit code: 0 — the README block and all three manifests are synced; 1 — the domain path, `skills/`, `README.md`, the `JSC-SKILLS` markers, a `SKILL.md`, a manifest, or a manifest `version` field is missing, so fix the named cause on stderr and rerun; 2 — usage error, the script takes exactly one argument; any other code — the script runs under `set -e`, so treat it as an environment fault and stop, never as a successful sync. Completion condition: `skills/{name}/SKILL.md` exists, `references/behaviors.md` holds a `## {name}` section with all five rows filled, the README lists the skill, and all three manifests show the same new version.
4. Self-check every item of the guidelines.md audit checklist; fix anything that fails. Run `tools/check-behaviors.sh {domain-path}` for the behavior-list item instead of comparing by eye, and route each exit code: 0 — the list matches `skills/` and all five rows are filled; 1 — every mismatch is printed on stderr as `{檔案}:{技能名}:{說明}`, so fix each one and rerun; 2 — usage error, the tool takes exactly one argument; 3 — nothing was checked, because `references/behaviors.md` is missing, `skills/` is missing, or no `SKILL.md` was found, so create the missing file and rerun. **Exit 3 is never a pass.** Completion condition: every checklist item passes and `tools/check-behaviors.sh {domain-path}` exits 0.
5. Call `jsc-git:pr` to open a Push Request. Completion condition: a PR URL comes back and is reported with the table format in [`../../references/pr-report.md`](../../references/pr-report.md).
Then run `tools/sync-skill-manifest.sh {domain-path}` directly (no sub agent needed) to sync the domain README's 「Skills 目錄」 section and bump the version in all three manifests. Route each exit code: 0 — the README block and all three manifests are synced; 1 — the domain path, `skills/`, `README.md`, the `JSC-SKILLS` markers, a `SKILL.md`, a manifest, or a manifest `version` field is missing, so fix the named cause on stderr and rerun; 2 — usage error, the script takes exactly one argument; any other code — the script runs under `set -e`, so treat it as an environment fault and stop, never as a successful sync. Completion condition: `skills/{name}/SKILL.md` exists, `references/behaviors.md` holds a `## {name}` section with all five rows filled, `tools/delegate-spec.tsv` holds this skill's row with every mandatory column filled, the README lists the skill, and all three manifests show the same new version.
4. Self-check every item of the guidelines.md audit checklist; fix anything that fails. Run `tools/check-behaviors.sh {domain-path}` for the behavior-list item instead of comparing by eye, and route each exit code: 0 — the list matches `skills/` and all five rows are filled; 1 — every mismatch is printed on stderr as `{檔案}:{技能名}:{說明}`, so fix each one and rerun; 2 — usage error, the tool takes exactly one argument; 3 — nothing was checked, because `references/behaviors.md` is missing, `skills/` is missing, or no `SKILL.md` was found, so create the missing file and rerun. **Exit 3 is never a pass.**
Then run `tools/check-delegate.sh` for the delegation-list item. It takes the plugins root, not a domain path, and the list is one file covering every domain, so it runs **once for the whole flow** — a second run per domain checks the same file again and reports the same lines. Route each exit code:
- 0 — the list matches the skills on this machine and every mandatory column is filled. **A run that printed lines on stdout and exited 0 still passed.** Those lines are hints, not defects: `origin=seed` marks a row seeded from the earlier inventory and awaiting review, and a version-behind line marks a row whose `version` trails its domain's current one. The version number is per domain, so bumping one skill's domain marks every other skill in it — reading those lines as failures paints the whole domain red on every release until nobody reads them at all. Report the hints, fix nothing for them, and treat this item as passed.
- 1 — a missing row, a duplicate row, a row for a skill this machine does not have, an empty column, a column value outside its vocabulary, or a `next` pointing at a skill that does not exist. Every one is printed on stderr as `{清單路徑}:{domain}/{技能名}:{說明}`; fix each and rerun. The new skill's own missing row is the expected finding when step 3 skipped its write, and the fix is that write, not an edit here.
- 2 — usage error: the script takes at most one argument. Fix the call and rerun.
- 3 — nothing was checked, because `tools/delegate-spec.tsv` is missing, the root could not be derived, or `list-skills.sh` listed no skill. Read stderr and fix the named cause; set `JSC_PLUGINS_ROOT` to the directory holding the domain repos for the root case, as in step 1.1. **Exit 3 is never a pass** — it means the check looked nowhere, so a new skill with no row would sail through it.
Completion condition: every checklist item passes, `tools/check-behaviors.sh {domain-path}` exits 0, and `tools/check-delegate.sh` exits 0 with the new skill's row present, its hint lines reported as hints.
5. Call `jsc-git:pr` to open a Push Request. When the new skill went into a domain other than `meta`, the `tools/delegate-spec.tsv` row is a change to `plugins/meta` and needs its own Push Request against that repo — two repos changed, two PRs, neither waiting on the other. Completion condition: a PR URL comes back for every repo this run changed, `plugins/meta` included when the row landed there, and each is reported with the table format in [`../../references/pr-report.md`](../../references/pr-report.md).
6. Deploy the new skill, verify it runs, then report:
1. Follow [`../../references/deploy-verify.md`](../../references/deploy-verify.md) from section 1 to section 5: `tools/deploy-route.sh {domain-path}` picks the route, the deploy route or the worktree route runs, and the verification then runs in a **fresh CLI process**, never in the session that ran the deploy. That session raised the restart gate itself and still holds the old skill body, so verifying inside it either gets blocked or passes on stale behavior. Verify the added skill's row in `tools/list-skills.sh`, every tool the skill added, and one minimal prompt per checkable CLI — the per-CLI prompts run in parallel. Completion condition: every completion condition in `deploy-verify.md` sections 1 to 5 holds for this domain repo.
2. Write the change report to the wiki — this part MUST run as a sub agent. It is two pages in two repos, and they must not be mixed up.
@@ -88,10 +98,10 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
| status | Use it when |
| --- | --- |
| `ok` | the new `SKILL.md` and its behavior-list section are in place, the checklist passes, the PR is open, `deploy-verify.md` sections 1 to 5 hold, and both wiki writes exited 0 |
| `ok` | the new `SKILL.md`, its behavior-list section and its `delegate-spec.tsv` row are in place, the checklist passes, every PR this run needed is open, `deploy-verify.md` sections 1 to 5 hold, and both wiki writes exited 0 |
| `blocked` | a gate or a missing prerequisite stopped the run before any file was created — `sync-domains.sh` never reached exit 0, or Gitea refused the repository creation and nobody created it by hand |
| `failed` | the run broke mid-way — `sync-marketplace.sh` or `sync-skill-manifest.sh` kept failing, or a wiki write failed again after its one retry |
| `degraded` | the skill landed with a part missing — the content page was written while its `SKILLSET_CONTENTS` block was not, or a CLI could not be verified and the reason was recorded |
| `degraded` | the skill landed with a part missing — the content page was written while its `SKILLSET_CONTENTS` block was not, the skill's PR is open while the `delegate-spec.tsv` PR is not, or a CLI could not be verified and the reason was recorded |
| `aborted` | the user stopped the run, or a prerequisite turned out not to hold and this skill stopped on its own |
`{exit code}` is this run's own result as a number: `0` for `ok`, non-zero otherwise. `detail` is optional, one line, at most 200 characters.