Merge pull request 'feat/change-requests/main' (#31) from feat/change-requests/main into develop
Reviewed-on: #31
This commit was merged in pull request #31.
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "jsc-meta",
|
||||
"version": "0.1.5",
|
||||
"version": "0.1.6",
|
||||
"description": "技能組自我管理：新建、更新、刪除技能與技能準則",
|
||||
"skills": "./skills",
|
||||
"author": {
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "jsc-meta",
|
||||
"version": "0.1.5",
|
||||
"version": "0.1.6",
|
||||
"description": "技能組自我管理：新建、更新、刪除技能與技能準則",
|
||||
"skills": "./skills"
|
||||
}
|
||||
|
||||
@@ -26,11 +26,11 @@ Marketplace 統一為 `jsc`（https://gitea.jsc.idv.tw/plugins/meta.git），安
|
||||
|
||||
### `skill-new`
|
||||
|
||||
新建技能：決策樹問細節（目標、觸發、輸入輸出、domain）→ 缺 domain 時依 template 結構建立新存取庫 → sub agent 依準則產生技能 → 審核清單自檢 → PR。
|
||||
新建技能：決策樹問細節（目標、觸發、輸入輸出、domain）→ 缺 domain 時依 template 結構建立新存取庫 → sub agent 依準則產生技能 → 審核清單自檢 → PR，並依 `references/pr-report.md` 回報。
|
||||
|
||||
### `skill-update`
|
||||
|
||||
更新技能：先查 Gitea 正本 marketplace 取得 domain 清單並補 clone 缺少的存取庫，列出全部技能 → 使用者選擇 → 決策樹問更新細節 → 更新後依審核檢查清單逐項檢查，不符就回到詢問 → PR。
|
||||
更新技能：先查 Gitea 正本 marketplace 取得 domain 清單並補 clone 缺少的存取庫，列出全部技能 → 使用者選擇 → 決策樹問更新細節 → 更新後依審核檢查清單逐項檢查，不符就回到詢問 → PR，並依 `references/pr-report.md` 回報。
|
||||
|
||||
### `skill-delete`
|
||||
|
||||
@@ -38,11 +38,11 @@ Marketplace 統一為 `jsc`（https://gitea.jsc.idv.tw/plugins/meta.git），安
|
||||
|
||||
### `skillset-update`
|
||||
|
||||
批次更新——把一份變更需求套用到整個技能組的多個技能／domain，先檢查工具化、sub agent 與環境變數優先規則，再逐 repo 開 PR；單一技能改用 skill-update。
|
||||
批次更新——把一份變更需求套用到整個技能組的多個技能／domain，先檢查工具化、sub agent 與環境變數優先規則，再逐 repo 開 PR；PR 回報格式見 `references/pr-report.md`；單一技能改用 skill-update。
|
||||
|
||||
### `skill-check`
|
||||
|
||||
例行稽核——沒有變更需求時，把整個技能組逐一對照準則的審核檢查清單：sub agent 逐 domain 稽核 → 不符項目逐項決策樹確認 → sub agent 套用修正並複檢 → 逐 repo 開 PR。有變更需求改用 skillset-update。
|
||||
例行稽核——沒有變更需求時，把整個技能組逐一對照準則的審核檢查清單，再分開跑流程優化審查。優化面向包含可平行化、可下放工具、重複來回、冗餘步驟、過早或過晚的閘門；不符項目與優化建議分開回報，逐項決策樹確認後才套用，最後逐 repo 開 PR。有變更需求改用 skillset-update。
|
||||
|
||||
### `ste100-sync`
|
||||
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "jsc-meta",
|
||||
"version": "0.1.5",
|
||||
"version": "0.1.6",
|
||||
"description": "技能組自我管理：新建、更新、刪除技能與技能準則",
|
||||
"skills": "./skills/"
|
||||
}
|
||||
|
||||
@@ -27,6 +27,8 @@
|
||||
5. 功能主幹 `{類型}/{功能}/main` 不在 origin 上時，自動從 `develop` 建立並推上去，收尾要回報建立了哪一條分支。
|
||||
6. 階梯最後一級不能省：`develop` 併進 `master` 才會生效，marketplace 與 `version-guard.sh` 都讀存取庫的**預設分支**。
|
||||
|
||||
PR 開立、更新、留言修正的收尾回報格式只看 [`references/pr-report.md`](pr-report.md)。所有會產生 PR 的技能都引用那份文件，不在技能內各自抄欄位。
|
||||
|
||||
## Description 規則
|
||||
|
||||
1. frontmatter 的 `description` 為一行英文，不超過 5 句或 5 個步驟——**兩個上限滿足任一個就算通過**，句數與步驟數都超過才要精簡。
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
# PR 收尾回報
|
||||
|
||||
所有會建立或更新 PR 的技能都用本頁格式回報。不要在各技能複製欄位定義。
|
||||
|
||||
## PR 資訊表格
|
||||
|
||||
只要本輪建立 PR、找到既有 PR，或更新既有 PR，就在回報中列出同一張表。
|
||||
|
||||
| {owner}/{repo} | PR 編號 | PR 連結 | PR 簡述 |
|
||||
| --- | --- | --- | --- |
|
||||
| `{owner}/{repo}` | `{number}` | `{url}` | `{title or one-line summary}` |
|
||||
|
||||
同一輪有多支 PR 時，全部放在同一張表。沒有 PR 時不要印空表，改用一句話說明沒有建立或更新 PR。
|
||||
|
||||
## 留言回覆
|
||||
|
||||
依 PR 留言完成修正、判定不需修正，或判定無法修正後，必須回覆原留言。
|
||||
|
||||
回覆一律走 `jsc-gitea/tools/gitea.sh comment-reply`。不要自行拼 API。
|
||||
|
||||
`pr-comments` 第三欄會標出留言類型與 id。呼叫 `comment-reply` 時使用下列對應。
|
||||
|
||||
| `pr-comments` 第三欄 | `comment-reply` 類型 |
|
||||
| --- | --- |
|
||||
| `留言#{id}` | `issue` |
|
||||
| `審查#{id}` | `review` |
|
||||
| `行內#{id}(...)` | `inline` |
|
||||
|
||||
回覆內容固定包含兩項：
|
||||
|
||||
| 項目 | 內容 |
|
||||
| --- | --- |
|
||||
| 處理結果 | 已修、不需修，或無法修 |
|
||||
| 依據 | commit、檔案，或不修理由 |
|
||||
|
||||
完成條件：本輪處理過的每一則留言，都有對應的回覆連結或明確的回覆失敗原因。
|
||||
@@ -1,9 +1,9 @@
|
||||
---
|
||||
name: skill-check
|
||||
description: Routine compliance 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 the guidelines.md audit checklist via sub agents, confirm each failed item with the user via decision tree, apply the confirmed fixes and re-check until all items pass, then open a PR per affected repo via jsc-git pr. Use for periodic or on-demand compliance checks of the skill set; not for applying a change request (use skillset-update) or editing one skill (use skill-update).
|
||||
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).
|
||||
---
|
||||
|
||||
# skill-check — audit the skill set against the guidelines
|
||||
# skill-check — audit compliance and flow efficiency
|
||||
|
||||
Single source of guidelines: [`../../references/guidelines.md`](../../references/guidelines.md).
|
||||
|
||||
@@ -17,14 +17,29 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
|
||||
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. Present each failed item via the `jsc-ask:ask` decision tree (apply the proposed fix / skip / custom fix). Every option states its impact scope (example: skipping leaves the skill non-compliant until the next audit). Completion condition: every finding has a recorded decision.
|
||||
4. Apply the confirmed fixes — the fix-application part MUST run as a sub agent, one sub agent per affected domain repo: modify the files per the confirmed fix. 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 fixes and the manifest bump.
|
||||
5. 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:
|
||||
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:
|
||||
|
||||
| Aspect | Scope |
|
||||
| --- | --- |
|
||||
| 1 Parallelism | Steps that run in series today but have no data dependency and can run in parallel |
|
||||
| 2 Tool extraction | SKILL.md text flows with clear inputs and outputs that should move to `tools/`, including hook-enforceable rules that still rely on prompts |
|
||||
| 3 Repeated interaction | The same user question, repository fact, wiki page, API result, or file content being collected more than once |
|
||||
| 4 Redundant checks | Completion conditions or verification steps that overlap, or a later step that necessarily covers an earlier check |
|
||||
| 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:
|
||||
- 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. 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.
|
||||
6. Re-check the guidelines.md audit checklist for every touched skill. On any failure, **return to step 3**: confirm and fix again, until all items pass. Completion condition: all checklist items pass.
|
||||
7. Call `jsc-git:pr` once per affected domain repo to open a Push Request. Completion condition: every affected repo has a PR URL.
|
||||
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. 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`.
|
||||
|
||||
@@ -27,7 +27,7 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
|
||||
- Exit 0 — no leftover in the locations listed on stderr.
|
||||
|
||||
Completion condition: the script exits 0, or exit 3 is reported to the user and recorded in the PR.
|
||||
8. Call `jsc-git:pr` to open a Push Request. Completion condition: a PR URL comes back.
|
||||
8. 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`.
|
||||
9. Apply the deletion to the current working session, verify it took, then report:
|
||||
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.
|
||||
|
||||
@@ -33,7 +33,7 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
|
||||
|
||||
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. Completion condition: `skills/{name}/SKILL.md` exists, 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. Completion condition: every checklist item passes.
|
||||
5. Call `jsc-git:pr` to open a Push Request. Completion condition: a PR URL comes back.
|
||||
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`.
|
||||
6. Apply the new skill to the current working session, verify it works, then report:
|
||||
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.
|
||||
|
||||
@@ -15,7 +15,7 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
|
||||
4. Ask for update details via the `jsc-ask:ask` decision tree (change the goal? the trigger? the flow? move rules down to a hook or a tool?). Every option states its impact scope (example: renaming breaks the existing invocation command). Completion condition: every question has a recorded answer.
|
||||
5. Update the skill — the modification part MUST run as a sub agent: modify SKILL.md and related files. 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. Completion condition: the skill files carry the change and all three manifests show the same new version.
|
||||
6. Check every item of the guidelines.md audit checklist. On any failure, **return to step 4**: ask again and fix, until all items pass. Completion condition: every checklist item passes.
|
||||
7. Call `jsc-git:pr` to open a Push Request. Completion condition: a PR URL comes back.
|
||||
7. 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`.
|
||||
8. Apply the update to the current working session, verify it works, then report:
|
||||
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.
|
||||
|
||||
@@ -13,7 +13,7 @@ Single source of guidelines: [`../../references/guidelines.md`](../../references
|
||||
2. 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.
|
||||
3. Apply the change to every affected skill — the modification part MUST run as a sub agent, one sub agent per affected domain repo: modify SKILL.md and related files and tools. Then run `tools/sync-skill-manifest.sh {domain-path}` directly (no sub agent needed) for each affected domain repo to sync that domain README's 「Skills 目錄」 section and bump the version in all three manifests. Completion condition: every affected domain repo carries the change, the README sync, and the manifest bump.
|
||||
4. Check every item of the guidelines.md audit checklist for each touched skill. On any failure, **return to step 1**: ask again and fix, until all items pass. Completion condition: every checklist item passes for every touched skill.
|
||||
5. Call `jsc-git:pr` once per affected domain repo to open a Push Request. Completion condition: every affected repo has a PR URL.
|
||||
5. 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`.
|
||||
6. Apply the batch change to the current working session, verify it works, then report:
|
||||
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.
|
||||
|
||||
@@ -24,7 +24,7 @@ Keep `references/ste100.md` in sync with its upstream source, [speak-human-tw](h
|
||||
7. If the replacement table or the cliché list changed, update the `TERMS`, `CLICHES` and `SIMPLIFIED` patterns in `tools/ste100-lint.sh`. Completion condition: `sh -n tools/ste100-lint.sh` passes and each newly adopted term hits on a test string.
|
||||
8. Run `tools/ste100-lint.sh` over every jsc repo (`tools/sync-domains.sh` prints the repo paths). Fix hits in files this repo owns. Completion condition: the lint exits 0 for this repo, and hits in other repos are reported with `file:line` for their owners.
|
||||
9. Run `tools/sync-skill-manifest.sh .` to sync the README's 「Skills 目錄」 section and bump the manifests. Completion condition: all three manifests show the same new version.
|
||||
10. Open a PR via `jsc-git:pr`. Completion condition: a PR URL comes back.
|
||||
10. Open a PR via `jsc-git:pr`. Completion condition: a PR URL comes back and is reported with the table format in `references/pr-report.md`.
|
||||
|
||||
## Notes
|
||||
|
||||
|
||||
Reference in New Issue
Block a user