plugins/meta
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(skill-check): 加入流程效率稽核

Browse Source
This commit is contained in:
jiantw83
2026-08-28 09:30:27 +08:00
parent b0ea356ff5
commit 08a7d23a12
4 changed files with 25 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/skill-check/SKILL.md
+22 -7
View File
@@ -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`.