From 2705771c20cf3ea9d40d9a989a77374f94ecdf7a Mon Sep 17 00:00:00 2001 From: Jeffery Date: Mon, 24 Aug 2026 11:36:33 +0800 Subject: [PATCH 1/8] =?UTF-8?q?feat(gate):=20=E5=9B=9B=E9=9A=8E=E6=AE=B5?= =?UTF-8?q?=E6=A8=A1=E5=9E=8B=E9=96=98=E9=96=80=E6=94=B9=E7=82=BA=E6=8C=87?= =?UTF-8?q?=E5=AE=9A=E6=A8=A1=E5=9E=8B=E5=84=AA=E5=85=88=E3=80=81=E8=83=BD?= =?UTF-8?q?=E5=8A=9B=E6=A8=99=E7=B1=A4=E5=82=99=E6=8F=B4=EF=BC=8C=E4=B8=A6?= =?UTF-8?q?=E4=BB=A5=20sdlc-gate=20=E4=B8=8A=E9=8E=96?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit What：plan、analyze、implement、maintain 四個 SKILL.md 的第一步從單純的能力標籤檢查，改為「模型閘門與階段上鎖」三段流程：先以 jsc-cli/tools/model-config.sh get {stage} 解析該階段的指定模型鏈，鏈上第一個當前 CLI 可用的模型即為必用模型；沒有設定指定模型時才退回 jsc-cli:models 的能力標籤檢查。閘門通過後執行 jsc-hooks/hooks/sdlc-gate.sh lock {stage} {current-model} 寫入鎖檔，並以 sdlc-gate.sh report 驗證。 Why：原本只驗能力標籤，同一標籤下模型可任意替換，階段中途換模型也無人攔阻，導致產出品質與可重現性不穩定。改為指定模型鏈優先可讓團隊明確指派每階段用哪個模型，標籤備援則保留未設定時的彈性；上鎖後由 hook 在每次 prompt 強制檢查，階段內換模型會被擋下。 How：每個技能的步驟一拆成三小步（解析模型鏈、驗證當前模型、上鎖並驗證鎖檔），各小步附完成條件；maintain 另加第四小步，明確規定只在換階段時重跑閘門，維護階段內跨專案不重複驗證。frontmatter description 同步更新。鎖定自 plan 起手生效，直到下一階段（如 analyze）的閘門重新上鎖前，強制沿用同一模型。 Who：jsc-sdlc 的 plan／analyze／implement／maintain 四個技能，及依賴其閘門行為的 jsc-hooks sdlc-gate hook。 Co-Authored-By: Claude Fable 5 --- skills/analyze/SKILL.md | 7 +++++-- skills/implement/SKILL.md | 7 +++++-- skills/maintain/SKILL.md | 8 ++++++-- skills/plan/SKILL.md | 7 +++++-- 4 files changed, 21 insertions(+), 8 deletions(-) diff --git a/skills/analyze/SKILL.md b/skills/analyze/SKILL.md index 7000f34..ea19d5c 100644 --- a/skills/analyze/SKILL.md +++ b/skills/analyze/SKILL.md @@ -1,6 +1,6 @@ --- name: analyze -description: SDLC analysis stage. Gate on model capability tags, pick a plan from PLAN_CONTENTS, analyze user stories against the current state (working directory plus REPO_{HASH} inventory for reuse). Run WBS to produce numbered work packages, estimate them with CPM, split each into TDD todos, and write wiki page ANALYZE_{HASH}. Logic only - never write code or modify files. Use after planning and before implementation. +description: SDLC analysis stage. Gate on the designated model (model-config) or capability tags, lock the model for the stage via sdlc-gate, pick a plan from PLAN_CONTENTS, analyze user stories against the current state (working directory plus REPO_{HASH} inventory for reuse). Run WBS to produce numbered work packages, estimate them with CPM, split each into TDD todos, and write wiki page ANALYZE_{HASH}. Logic only - never write code or modify files. Use after planning and before implementation. --- # analyze @@ -13,7 +13,10 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model capability gate**: check the capability tags from `jsc-cli:models` and confirm the current model qualifies for analysis. If not, block the flow and tell the user which model to switch to. +1. **Model gate and stage lock**: + 1. Resolve the analyze stage's designated model chain: run `jsc-cli/tools/model-config.sh get analyze`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (analysis requires the reasoning-high tag). + 2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. + 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock analyze {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. 2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` for plans whose status is the literal 「未分析」 (name and HASH), and read `ANALYZE_CONTENTS` for existing analyses. 3. Let the user choose per `jsc-ask:ask` rules: **extend an existing analysis** or **analyze a new plan**. State the impact scope on every option. 4. Analyze the plan page's user stories one by one against the **current state**, questioning via the `jsc-ask:ask` decision tree until no doubt remains; keep asking while consensus is missing. Current state means: diff --git a/skills/implement/SKILL.md b/skills/implement/SKILL.md index a7b20db..6f29dea 100644 --- a/skills/implement/SKILL.md +++ b/skills/implement/SKILL.md @@ -1,6 +1,6 @@ --- name: implement -description: SDLC implementation stage. Gate on model capability tags, claim a ready work package from ANALYZE_CONTENTS with a work ticket, then complete its TDD todos one by one, updating the wiki after every item. Ends with jsc-review code-review and an optional MAINTAIN_CONTENTS entry. Use when analysis is done and code must be written; not for planning or analysis. +description: SDLC implementation stage. Gate on the designated model (model-config) or capability tags, lock the model for the stage via sdlc-gate, claim a ready work package from ANALYZE_CONTENTS with a work ticket, then complete its TDD todos one by one, updating the wiki after every item. Ends with jsc-review code-review and an optional MAINTAIN_CONTENTS entry. Use when analysis is done and code must be written; not for planning or analysis. --- # implement @@ -10,7 +10,10 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model capability gate**: check the capability tags from `jsc-cli:models` and confirm the current model qualifies for implementation. If not, block the flow and tell the user which model to switch to. +1. **Model gate and stage lock**: + 1. Resolve the implement stage's designated model chain: run `jsc-cli/tools/model-config.sh get implement`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (implementation requires the coding tag). + 2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. + 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock implement {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. 2. **Resolve environment first**: inspect `JSC_WIKI_REPO_ANALYZE`, `JSC_WIKI_REPO`, `JSC_WIKI_REPO_QUESTION`, `GITEA_HOST`, and `GITEA_TOKEN` before asking the user anything. Use inherited shell values first. If the env vars are present but the tool cannot read them, check the current shell environment before asking. 3. **Generate a work ticket**: format `TICKET_{yyyyMMdd}_{HHmmss}_{HASH}`. Use the shared wiki hash for `{owner}/{repo}` for `{HASH}`: take the first 8 uppercase hex chars of its SHA-1, then replace a leading digit or `A`/`B`/`C` with `H` plus the next 7 chars. Try to rename the current session to the ticket name (skip when the CLI does not support it). 4. Read `ANALYZE_CONTENTS` via `jsc-gitea:wiki` and list what is unfinished: plan name, HASH, work package number, count of open items. A selectable work package must satisfy all three: **unfinished, dependency-free (or all dependencies done), and not holding a work ticket**. diff --git a/skills/maintain/SKILL.md b/skills/maintain/SKILL.md index 4243fb8..06499c2 100644 --- a/skills/maintain/SKILL.md +++ b/skills/maintain/SKILL.md @@ -1,6 +1,6 @@ --- name: maintain -description: SDLC maintenance stage. Gate on model capability tags for the maintenance stage, read projects still inside their maintenance window from MAINTAIN_CONTENTS, then run one sub agent per project: switch to develop or master, propose at least five maintenance actions, commit to a new branch, push, and PR. Update the last-maintained timestamp afterward. Use for periodic upkeep of delivered projects. +description: SDLC maintenance stage. Gate on the designated model (model-config) or capability tags for the maintenance stage, lock the model via sdlc-gate, read projects still inside their maintenance window from MAINTAIN_CONTENTS, then run one sub agent per project: switch to develop or master, propose at least five maintenance actions, commit to a new branch, push, and PR. Update the last-maintained timestamp afterward. Use for periodic upkeep of delivered projects. --- # maintain @@ -10,7 +10,11 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model capability gate**: check the 「SDLC 階段需求」 table from `jsc-cli:models` and confirm the current model qualifies for maintenance (any tag qualifies, but the model must be listed in the mapping table). If not, block the flow and tell the user which model to switch to. Re-check only when the stage changes. +1. **Model gate and stage lock**: + 1. Resolve the maintain stage's designated model chain: run `jsc-cli/tools/model-config.sh get maintain`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the 「SDLC 階段需求」 table from `jsc-cli:models` (any listed model qualifies for maintenance). + 2. If the current model is not the required model, or is missing from the mapping table, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. + 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock maintain {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. + 4. Run this gate only when the stage changes; inside the maintenance stage the lock already enforces the model, so never re-gate between projects. 2. Read `MAINTAIN_CONTENTS` via `jsc-gitea:wiki` and filter projects **still inside their maintenance window**: start date ≤ today, and (end date is NULL or ≥ today). 3. Every project **MUST run as a sub agent** with this flow: 1. Switch the project to the `develop` branch, falling back to `master`, and pull to latest. diff --git a/skills/plan/SKILL.md b/skills/plan/SKILL.md index cc9180a..e01b3a3 100644 --- a/skills/plan/SKILL.md +++ b/skills/plan/SKILL.md @@ -1,6 +1,6 @@ --- name: plan -description: SDLC planning stage. Gate on model capability tags, pick or create a plan from PLAN_CONTENTS, then run a decision tree until goal, scope, and feasibility reach consensus. Produce user stories into wiki page PLAN_{HASH}. Logic only - never write code or modify files. Use when the user wants to start or refine a plan; not for analysis or implementation. +description: SDLC planning stage. Gate on the designated model (model-config) or capability tags, lock the model for the stage via sdlc-gate, pick or create a plan from PLAN_CONTENTS, then run a decision tree until goal, scope, and feasibility reach consensus. Produce user stories into wiki page PLAN_{HASH}. Logic only - never write code or modify files. Use when the user wants to start or refine a plan; not for analysis or implementation. --- # plan @@ -13,7 +13,10 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model capability gate**: check the capability tags from `jsc-cli:models` and confirm the current model qualifies for planning. If not, block the flow and tell the user which model to switch to. +1. **Model gate and stage lock**: + 1. Resolve the plan stage's designated model chain: run `jsc-cli/tools/model-config.sh get plan`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (planning requires the reasoning-high tag). + 2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. + 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock plan {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. 2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` and list the plans whose status is the literal 「未分析」 (not analyzed), with names and HASH. 3. Let the user choose per `jsc-ask:ask` rules: **extend an existing plan** (list the not-analyzed plans as options) or **create a new plan**. State the impact scope on every option. 4. Question via the `jsc-ask:ask` decision tree until no doubt remains on all three items; keep asking while consensus is missing: From 91d88df37b347cadc24eb7903931a545c365424e Mon Sep 17 00:00:00 2001 From: Jeffery Date: Mon, 24 Aug 2026 11:36:49 +0800 Subject: [PATCH 2/8] =?UTF-8?q?docs(readme):=20=E8=AA=AA=E6=98=8E=E6=8C=87?= =?UTF-8?q?=E5=AE=9A=E6=A8=A1=E5=9E=8B=E9=8F=88=E9=96=98=E9=96=80=E8=88=87?= =?UTF-8?q?=20sdlc-gate=20=E9=9A=8E=E6=AE=B5=E9=8E=96=E5=AE=9A=E6=A9=9F?= =?UTF-8?q?=E5=88=B6?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit What：README 開頭的階段模型檢查說明改寫：每次切換階段先以 jsc-cli/tools/model-config.sh get {stage} 解析指定模型鏈（專案 .jsc/models 優先於 $JSC_HOME/models.conf），未設定才退回能力標籤檢查；通過後由 jsc-hooks 的 sdlc-gate hook 鎖定模型直到下一階段重新上鎖。「相關 domain」清單同步更新：jsc-cli 條目補上指定模型鏈工具，新增 jsc-hooks 條目說明 sdlc-gate 階段模型鎖定。 Why：四個技能的閘門邏輯已改為指定模型優先、標籤備援並上鎖，README 若仍描述舊的「僅檢查能力標籤」流程會誤導使用者，也漏掉新依賴的 jsc-hooks domain。 How：改寫首段的階段檢查敘述，補明設定檔優先序與鎖定生效範圍（同一階段內換模型會被擋下）；相關 domain 章節加入 jsc-hooks 連結並擴充 jsc-cli 條目。 Who：jsc-sdlc domain 的 README 文件，服務安裝與使用此技能組的使用者。 Co-Authored-By: Claude Fable 5 --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index fce5bf4..e121310 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # jsc-sdlc — 開發生命週期 -jsc 技能組的 sdlc domain：規劃 → 分析 → 實作 → 維護四個階段，全程以 wiki 頁追蹤（`PLAN_CONTENTS`、`PLAN_{HASH}`、`ANALYZE_CONTENTS`、`ANALYZE_{HASH}`、`REPO_CONTENTS`、`REPO_{HASH}`、`MAINTAIN_CONTENTS`）。另有異常頁（`ERROR_CONTENTS`、`ERROR_{HASH}`）記錄 hook 或流程失敗。每次切換階段才重新檢查該階段需要的模型能力標籤；同一階段內不重複變更。 +jsc 技能組的 sdlc domain：規劃 → 分析 → 實作 → 維護四個階段，全程以 wiki 頁追蹤（`PLAN_CONTENTS`、`PLAN_{HASH}`、`ANALYZE_CONTENTS`、`ANALYZE_{HASH}`、`REPO_CONTENTS`、`REPO_{HASH}`、`MAINTAIN_CONTENTS`）。另有異常頁（`ERROR_CONTENTS`、`ERROR_{HASH}`）記錄 hook 或流程失敗。每次切換階段先解析該階段的指定模型鏈（`jsc-cli/tools/model-config.sh get {stage}`，專案 `.jsc/models` 優先於 `$JSC_HOME/models.conf`）；沒有設定才退回模型能力標籤檢查。通過閘門後由 `jsc-hooks` 的 sdlc-gate hook 鎖定模型，直到下一階段的閘門重新上鎖；同一階段內換模型會被擋下。 ## 安裝、更新、移除 @@ -59,7 +59,8 @@ HASH 規則：一律先算 `{owner}/{repo}` 的 SHA-1 前 8 碼並轉大寫； ## 相關 domain -- [`jsc-cli`](https://gitea.jsc.idv.tw/plugins/cli)：模型能力標籤（`jsc-cli:models`） +- [`jsc-cli`](https://gitea.jsc.idv.tw/plugins/cli)：指定模型鏈（`tools/model-config.sh`）與模型能力標籤（`jsc-cli:models`） +- [`jsc-hooks`](https://gitea.jsc.idv.tw/plugins/hooks)：sdlc-gate 階段模型鎖定 - [`jsc-gitea`](https://gitea.jsc.idv.tw/plugins/gitea)：wiki 讀寫 - [`jsc-review`](https://gitea.jsc.idv.tw/plugins/review)：實作完成後的程式碼審查 - [`jsc-git`](https://gitea.jsc.idv.tw/plugins/git) / [`jsc-pkg`](https://gitea.jsc.idv.tw/plugins/pkg)：維護階段的 commit / PR 與套件更新 From 923fb8e83e2c6dca48539a22a57b76eae97912f3 Mon Sep 17 00:00:00 2001 From: Jeffery Date: Mon, 24 Aug 2026 11:37:01 +0800 Subject: [PATCH 3/8] =?UTF-8?q?chore(manifest):=20=E4=B8=89=E4=BB=BD=20plu?= =?UTF-8?q?gin.json=20=E7=89=88=E6=9C=AC=E5=8D=87=E8=87=B3=200.0.3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit What：plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json 三份 manifest 的 version 由 0.0.2 升為 0.0.3。 Why：本次加入指定模型閘門與 sdlc-gate 階段鎖定屬功能性變更，需要提升版本號讓各 AI CLI 的 plugin 更新機制偵測到新版並重新安裝。 How：同步修改三份 manifest 的 version 欄位，維持三處版本一致。 Who：jsc-sdlc plugin 的安裝與更新流程（jsc-cli:deploy 及各 CLI 原生 plugin 指令）。 Co-Authored-By: Claude Fable 5 --- .claude-plugin/plugin.json | 2 +- .codex-plugin/plugin.json | 2 +- plugin.json | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index d087e35..46e8904 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.2", + "version": "0.0.3", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills", "author": { diff --git a/.codex-plugin/plugin.json b/.codex-plugin/plugin.json index 7be74c9..91aae39 100644 --- a/.codex-plugin/plugin.json +++ b/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.2", + "version": "0.0.3", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills" } diff --git a/plugin.json b/plugin.json index 4ce9145..1a89807 100644 --- a/plugin.json +++ b/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.2", + "version": "0.0.3", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills/" } From da64e97e28deb7004124e94602a3c15b7ae5a86e Mon Sep 17 00:00:00 2001 From: Jeffery Date: Mon, 24 Aug 2026 14:50:12 +0800 Subject: [PATCH 4/8] =?UTF-8?q?fix(marketplace):=20=E5=90=8C=E6=AD=A5=20ma?= =?UTF-8?q?rketplace.json=20=E4=B8=AD=E7=B9=BC=E8=B3=87=E6=96=99=E8=87=B3?= =?UTF-8?q?=20canonical=20=E7=89=88=E6=9C=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit What（做了什麼）： 修正 .claude-plugin/marketplace.json 與 .agents/plugins/marketplace.json 兩份 marketplace 清單，使其欄位與格式與 plugins/jsc 的 canonical marketplace.json 一致。.agents/plugins/marketplace.json 補上缺漏的頂層 description、owner 欄位，並為全部 11 個 plugin 項目（jsc-ask、jsc-cli、jsc-git、jsc-gitea、jsc-hooks、jsc-log、jsc-meta、jsc-pkg、jsc-review、jsc-sdlc）補上各自的繁體中文用途描述；.claude-plugin/marketplace.json 則將 jsc-meta 描述中的斜線寫法（「新建/更新/刪除技能」）改為 canonical 的頓號寫法（「新建、更新、刪除技能與技能準則」）。 Why（為什麼改）： 兩份清單長期與 canonical marketplace.json 不同步，缺欄位與描述格式不一致，會造成各 AI CLI 讀到不完整或不一致的 plugin 資訊，也不符合 jsc-meta:skill-check 的稽核基準。 How（怎麼改的）： 以 plugins/jsc 的 canonical marketplace.json 為基準逐欄比對，補齊缺漏欄位、統一描述文字格式，純屬中繼資料調整，不涉及任何 skill 行為邏輯變更。 Who（誰／哪個需求）： jsc-meta:skill-check 例行合規稽核中的 marketplace 中繼資料同步項目。 --- .agents/plugins/marketplace.json | 34 ++++++++++++++++++++++---------- .claude-plugin/marketplace.json | 2 +- 2 files changed, 25 insertions(+), 11 deletions(-) diff --git a/.agents/plugins/marketplace.json b/.agents/plugins/marketplace.json index 12df680..a9b4e66 100644 --- a/.agents/plugins/marketplace.json +++ b/.agents/plugins/marketplace.json @@ -1,75 +1,89 @@ { "name": "jsc", + "description": "jsc 跨 AI 助理技能組的統一 marketplace（claude / codex / copilot / antigravity / kiro）。", + "owner": { + "name": "JSC" + }, "plugins": [ { "name": "jsc-ask", "source": { "source": "url", "url": "https://gitea.jsc.idv.tw/plugins/ask.git" - } + }, + "description": "決策樹問詢與問詢紀錄（QUESTION_* wiki 頁）" }, { "name": "jsc-cli", "source": { "source": "url", "url": "https://gitea.jsc.idv.tw/plugins/cli.git" - } + }, + "description": "CLI 偵測、模型能力標籤與技能庫批次部署" }, { "name": "jsc-git", "source": { "source": "url", "url": "https://gitea.jsc.idv.tw/plugins/git.git" - } + }, + "description": "Commit 分組認可與 Push Request 建立" }, { "name": "jsc-gitea", "source": { "source": "url", "url": "https://gitea.jsc.idv.tw/plugins/gitea.git" - } + }, + "description": "Gitea API 工具、Wiki 讀寫與存取庫批次同步" }, { "name": "jsc-hooks", "source": { "source": "url", "url": "https://gitea.jsc.idv.tw/plugins/hooks.git" - } + }, + "description": "跨 CLI hooks：STE100 語言強制、工時計時、技能用量記錄" }, { "name": "jsc-log", "source": { "source": "url", "url": "https://gitea.jsc.idv.tw/plugins/log.git" - } + }, + "description": "工作日誌（LOG_* wiki 頁）與技能使用統計" }, { "name": "jsc-meta", "source": { "source": "url", "url": "https://gitea.jsc.idv.tw/plugins/meta.git" - } + }, + "description": "技能組自我管理：新建、更新、刪除技能與技能準則" }, { "name": "jsc-pkg", "source": { "source": "url", "url": "https://gitea.jsc.idv.tw/plugins/pkg.git" - } + }, + "description": "套件批次更新（nodejs/python/dotnet），失敗還原" }, { "name": "jsc-review", "source": { "source": "url", "url": "https://gitea.jsc.idv.tw/plugins/review.git" - } + }, + "description": "程式碼審查：Refactoring 壞味道六組 + 註解規範 + 淺模組" }, { "name": "jsc-sdlc", "source": { "source": "url", "url": "https://gitea.jsc.idv.tw/plugins/sdlc.git" - } + }, + "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）" } ] } diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 28bb223..a9b4e66 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -59,7 +59,7 @@ "source": "url", "url": "https://gitea.jsc.idv.tw/plugins/meta.git" }, - "description": "技能組自我管理：新建/更新/刪除技能與技能準則" + "description": "技能組自我管理：新建、更新、刪除技能與技能準則" }, { "name": "jsc-pkg", From 8d2b71599560307d6959caeb55509158a0cc7fa1 Mon Sep 17 00:00:00 2001 From: Jeffery Date: Mon, 24 Aug 2026 14:50:22 +0800 Subject: [PATCH 5/8] =?UTF-8?q?refactor(sdlc):=20=E6=B6=88=E9=99=A4?= =?UTF-8?q?=E5=9B=9B=E5=80=8B=20SDLC=20skill=20=E9=96=93=E9=87=8D=E8=A4=87?= =?UTF-8?q?=E9=82=8F=E8=BC=AF=EF=BC=8C=E6=94=B9=E7=82=BA=E5=A7=94=E6=B4=BE?= =?UTF-8?q?=E5=94=AF=E4=B8=80=E6=AC=8A=E5=A8=81=E4=BE=86=E6=BA=90?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit What（做了什麼）： 1. 移除 plan、analyze、implement 三個 skill 及 README.md 中各自重述的 wiki hash 演算法說明（原本各處都各自寫一遍「取 SHA-1 前 8 碼大寫十六進位，開頭若為數字或 A/B/C 則替換為 H 加後 7 碼」），改為統一指向唯一權威工具 jsc-gitea/tools/hash-id（透過 jsc-gitea:wiki 使用）。 2. 移除 plan、analyze、implement、maintain 四個 skill 中重複的 model chain fallback 選擇邏輯說明（原本各自描述「執行 jsc-cli/tools/model-config.sh get {stage}，若印出 chain 則取目前 CLI 可用的第一個，fallback 依 chain 順序套用」），改為統一呼叫新的共用子指令 jsc-cli/tools/model-config.sh resolve {stage}，由該子指令自行封裝解析邏輯（此 resolve 子指令由另一位 agent 同時在 sibling repo jsc-cli 開的配套 PR 新增，本 PR 依賴該 PR）。 3. implement/SKILL.md 移除自身多餘的「先解析環境變數」步驟（原第 2 步，手動檢查 JSC_WIKI_REPO_ANALYZE、JSC_WIKI_REPO、JSC_WIKI_REPO_QUESTION、GITEA_HOST、GITEA_TOKEN 後才詢問使用者），因為此解析已由 implement 其他步驟委派的 jsc-gitea:wiki 正確處理，屬於死重複邏輯；後續步驟由 2-8 重新編號為 2-7。 4. maintain/SKILL.md 在 frontmatter description 欄位加入明確的負向觸發說明，釐清此 skill 僅用於已交付、仍在維護窗口內的專案，「不適用於仍在實作中或尚未登錄於 MAINTAIN_CONTENTS 的專案」。 5. plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json 三份版本號檔案，由 0.0.3 升版至 0.0.4。 Why（為什麼改）： 四個 SDLC skill 各自重述相同的 hash 演算法與 model chain fallback 邏輯，違反 jsc-meta:skill-check 稽核準則中「單一權威來源」的要求，日後維護容易改一處漏一處；implement 的環境變數解析步驟與其他步驟委派的 jsc-gitea:wiki 功能重疊，屬死碼；maintain 的觸發時機描述不夠明確，容易被誤用在尚未進入維護窗口的專案上。 How（怎麼改的）： 將重複邏輯抽離，改為指向或呼叫唯一權威工具/skill（jsc-gitea/tools/hash-id、jsc-cli/tools/model-config.sh resolve、jsc-gitea:wiki），移除 implement 中的死步驟並重新編號，於 maintain frontmatter 補上負向觸發描述，並同步升版三份 plugin.json。全程不改變任何對外行為，純屬重構。 Who（誰／哪個需求）： jsc-meta:skill-check 對 plan、analyze、implement、maintain 四個 SDLC skill 的例行合規稽核修正。 --- .claude-plugin/plugin.json | 2 +- .codex-plugin/plugin.json | 2 +- README.md | 4 ++-- plugin.json | 2 +- skills/analyze/SKILL.md | 4 ++-- skills/implement/SKILL.md | 15 +++++++-------- skills/maintain/SKILL.md | 4 ++-- skills/plan/SKILL.md | 4 ++-- 8 files changed, 18 insertions(+), 19 deletions(-) diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index 46e8904..4a6d966 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.3", + "version": "0.0.4", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills", "author": { diff --git a/.codex-plugin/plugin.json b/.codex-plugin/plugin.json index 91aae39..039436f 100644 --- a/.codex-plugin/plugin.json +++ b/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.3", + "version": "0.0.4", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills" } diff --git a/README.md b/README.md index e121310..8961b8f 100644 --- a/README.md +++ b/README.md @@ -36,7 +36,7 @@ Marketplace 統一為 `jsc`（https://gitea.jsc.idv.tw/plugins/jsc.git），安 ### `maintain` -維護：讀取維護期內的專案，每個專案一個 sub agent：切 develop/master → 至少五種建議維護方法 → commit / push / PR → 更新前次維護時間。 +維護：讀取維護期內的專案，每個專案一個 sub agent：切 develop/master → 至少五種建議維護方法 → commit / push / PR → 更新前次維護時間。僅適用於維護期內已交付的專案；尚在實作中或未登記於 `MAINTAIN_CONTENTS` 的專案不適用。 @@ -55,7 +55,7 @@ Marketplace 統一為 `jsc`（https://gitea.jsc.idv.tw/plugins/jsc.git），安 Wiki 位置：`PLAN_{HASH}` / `PLAN_CONTENTS` 只讀 `JSC_WIKI_REPO_PLAN`，再退回 `JSC_WIKI_REPO`；`ANALYZE_{HASH}` / `ANALYZE_CONTENTS` 只讀 `JSC_WIKI_REPO_ANALYZE`，再退回 `JSC_WIKI_REPO`；`REPO_{HASH}` / `REPO_CONTENTS` 只讀 `JSC_WIKI_REPO_REPO`，再退回 `JSC_WIKI_REPO`；`MAINTAIN_CONTENTS` 只讀 `JSC_WIKI_REPO_MAINTAIN`，再退回 `JSC_WIKI_REPO`。不同類型不可互相代用；兩者都未設定才詢問（見 `jsc-gitea`）。 -HASH 規則：一律先算 `{owner}/{repo}` 的 SHA-1 前 8 碼並轉大寫；若第一碼是數字，或 `A`、`B`、`C`，就改成 `H` 加上原 SHA-1 前 7 碼，總長維持 8 碼。 +HASH 規則：`{owner}/{repo}` 的共用 wiki hash 一律由 `jsc-gitea/tools/hash-id` 計算（見 `jsc-gitea:wiki`），此 domain 不重複實作演算法。 ## 相關 domain diff --git a/plugin.json b/plugin.json index 1a89807..a0ca998 100644 --- a/plugin.json +++ b/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.3", + "version": "0.0.4", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills/" } diff --git a/skills/analyze/SKILL.md b/skills/analyze/SKILL.md index ea19d5c..0bc991c 100644 --- a/skills/analyze/SKILL.md +++ b/skills/analyze/SKILL.md @@ -8,13 +8,13 @@ description: SDLC analysis stage. Gate on the designated model (model-config) or Goal: create or extend the wiki analysis page `ANALYZE_{HASH}`. This skill is a **logic-only** stage: never output code, and **never modify any file**. -`{HASH}` = the shared wiki hash for `{owner}/{repo}`: take the first 8 uppercase hex chars of its SHA-1. If the first char is a digit, or `A`/`B`/`C`, replace it with `H` and keep the next 7 chars. +`{HASH}` = the shared wiki hash for `{owner}/{repo}` used to build the `ANALYZE_{HASH}` page name, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`). All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps 1. **Model gate and stage lock**: - 1. Resolve the analyze stage's designated model chain: run `jsc-cli/tools/model-config.sh get analyze`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (analysis requires the reasoning-high tag). + 1. Run `jsc-cli/tools/model-config.sh resolve analyze` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (analysis requires the reasoning-high tag). 2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock analyze {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. 2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` for plans whose status is the literal 「未分析」 (name and HASH), and read `ANALYZE_CONTENTS` for existing analyses. diff --git a/skills/implement/SKILL.md b/skills/implement/SKILL.md index 6f29dea..9fa2a66 100644 --- a/skills/implement/SKILL.md +++ b/skills/implement/SKILL.md @@ -11,18 +11,17 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps 1. **Model gate and stage lock**: - 1. Resolve the implement stage's designated model chain: run `jsc-cli/tools/model-config.sh get implement`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (implementation requires the coding tag). + 1. Run `jsc-cli/tools/model-config.sh resolve implement` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (implementation requires the coding tag). 2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock implement {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. -2. **Resolve environment first**: inspect `JSC_WIKI_REPO_ANALYZE`, `JSC_WIKI_REPO`, `JSC_WIKI_REPO_QUESTION`, `GITEA_HOST`, and `GITEA_TOKEN` before asking the user anything. Use inherited shell values first. If the env vars are present but the tool cannot read them, check the current shell environment before asking. -3. **Generate a work ticket**: format `TICKET_{yyyyMMdd}_{HHmmss}_{HASH}`. Use the shared wiki hash for `{owner}/{repo}` for `{HASH}`: take the first 8 uppercase hex chars of its SHA-1, then replace a leading digit or `A`/`B`/`C` with `H` plus the next 7 chars. Try to rename the current session to the ticket name (skip when the CLI does not support it). -4. Read `ANALYZE_CONTENTS` via `jsc-gitea:wiki` and list what is unfinished: plan name, HASH, work package number, count of open items. A selectable work package must satisfy all three: **unfinished, dependency-free (or all dependencies done), and not holding a work ticket**. -5. Let the user pick a work package per `jsc-ask:ask` rules (options state open-item count and estimated effort). Write the ticket into that work package's ticket column (the zh-TW field 「工作證」) on the analysis page and save it back to the wiki. **Only after the ticket is saved successfully may you proceed.** -6. List every open item of the work package and implement them **one at a time**: +2. **Generate a work ticket**: format `TICKET_{yyyyMMdd}_{HHmmss}_{HASH}`. `{HASH}` = the shared wiki hash for `{owner}/{repo}`, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`). Try to rename the current session to the ticket name (skip when the CLI does not support it). +3. Read `ANALYZE_CONTENTS` via `jsc-gitea:wiki` and list what is unfinished: plan name, HASH, work package number, count of open items. A selectable work package must satisfy all three: **unfinished, dependency-free (or all dependencies done), and not holding a work ticket**. +4. Let the user pick a work package per `jsc-ask:ask` rules (options state open-item count and estimated effort). Write the ticket into that work package's ticket column (the zh-TW field 「工作證」) on the analysis page and save it back to the wiki. **Only after the ticket is saved successfully may you proceed.** +5. List every open item of the work package and implement them **one at a time**: - Follow the TDD loop: red before green, one slice at a time; rules and anti-patterns in `references/tdd.md` (refactoring belongs to the review stage). - After each item, flip its `[ ]` to `[x]` on the analysis page and save to the wiki before starting the next item. -7. When all items are done, call `jsc-review:code-review` and wait for the review; on failure, fix and re-review until it passes. -8. Ask per `jsc-ask:ask` rules whether to register this project for maintenance: append to `MAINTAIN_CONTENTS` with `templates/maintain-contents.md`. Required: repository `{owner}/{repo}`, maintenance method, start date. Optional: end date (NULL = maintain forever), last-maintained time. +6. When all items are done, call `jsc-review:code-review` and wait for the review; on failure, fix and re-review until it passes. +7. Ask per `jsc-ask:ask` rules whether to register this project for maintenance: append to `MAINTAIN_CONTENTS` with `templates/maintain-contents.md`. Required: repository `{owner}/{repo}`, maintenance method, start date. Optional: end date (NULL = maintain forever), last-maintained time. ## Rules diff --git a/skills/maintain/SKILL.md b/skills/maintain/SKILL.md index 06499c2..6083262 100644 --- a/skills/maintain/SKILL.md +++ b/skills/maintain/SKILL.md @@ -1,6 +1,6 @@ --- name: maintain -description: SDLC maintenance stage. Gate on the designated model (model-config) or capability tags for the maintenance stage, lock the model via sdlc-gate, read projects still inside their maintenance window from MAINTAIN_CONTENTS, then run one sub agent per project: switch to develop or master, propose at least five maintenance actions, commit to a new branch, push, and PR. Update the last-maintained timestamp afterward. Use for periodic upkeep of delivered projects. +description: SDLC maintenance stage. Gate on the designated model (model-config) or capability tags for the maintenance stage, lock the model via sdlc-gate, read projects still inside their maintenance window from MAINTAIN_CONTENTS, then run one sub agent per project: switch to develop or master, propose at least five maintenance actions, commit to a new branch, push, and PR. Update the last-maintained timestamp afterward. Use for periodic upkeep of delivered projects inside their maintenance window; not for projects still mid-implementation or not yet registered in MAINTAIN_CONTENTS. --- # maintain @@ -11,7 +11,7 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps 1. **Model gate and stage lock**: - 1. Resolve the maintain stage's designated model chain: run `jsc-cli/tools/model-config.sh get maintain`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the 「SDLC 階段需求」 table from `jsc-cli:models` (any listed model qualifies for maintenance). + 1. Run `jsc-cli/tools/model-config.sh resolve maintain` to get the required model; if it prints nothing, fall back to the 「SDLC 階段需求」 table from `jsc-cli:models` (any listed model qualifies for maintenance). 2. If the current model is not the required model, or is missing from the mapping table, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock maintain {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. 4. Run this gate only when the stage changes; inside the maintenance stage the lock already enforces the model, so never re-gate between projects. diff --git a/skills/plan/SKILL.md b/skills/plan/SKILL.md index e01b3a3..59d57d2 100644 --- a/skills/plan/SKILL.md +++ b/skills/plan/SKILL.md @@ -8,13 +8,13 @@ description: SDLC planning stage. Gate on the designated model (model-config) or Goal: create or extend the wiki plan page `PLAN_{HASH}`. This skill is a **logic-only** stage: never output code, and **never modify any file**. -`{HASH}` = the shared wiki hash for `{owner}/{repo}`: take the first 8 uppercase hex chars of its SHA-1. If the first char is a digit, or `A`/`B`/`C`, replace it with `H` and keep the next 7 chars. +`{HASH}` = the shared wiki hash for `{owner}/{repo}` used to build the `PLAN_{HASH}` page name, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`). All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps 1. **Model gate and stage lock**: - 1. Resolve the plan stage's designated model chain: run `jsc-cli/tools/model-config.sh get plan`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (planning requires the reasoning-high tag). + 1. Run `jsc-cli/tools/model-config.sh resolve plan` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (planning requires the reasoning-high tag). 2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock plan {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. 2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` and list the plans whose status is the literal 「未分析」 (not analyzed), with names and HASH. From 8df6948c5c48c133ac833aa1cbf8fb52f8812010 Mon Sep 17 00:00:00 2001 From: Jeffery Date: Mon, 24 Aug 2026 16:05:18 +0800 Subject: [PATCH 6/8] =?UTF-8?q?feat(SDLC=20=E9=9A=8E=E6=AE=B5):=20?= =?UTF-8?q?=E9=96=98=E9=96=80=E6=94=B9=E7=82=BA=E8=83=BD=E5=8A=9B=E6=A8=99?= =?UTF-8?q?=E7=B1=A4=E7=A8=8B=E5=BC=8F=E5=88=A4=E5=AE=9A=EF=BC=8C=E5=88=86?= =?UTF-8?q?=E6=9E=90=E8=88=87=E5=AF=A6=E4=BD=9C=E5=85=88=E7=A2=BA=E8=AA=8D?= =?UTF-8?q?=E5=88=86=E6=94=AF=EF=BC=8C=E4=BA=A4=E6=8E=A5=E5=B7=A5=E4=BD=9C?= =?UTF-8?q?=E5=8C=85=E5=84=AA=E5=85=88?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 (1M context) --- skills/analyze/SKILL.md | 54 +++++++++++++++++++++++++++++---------- skills/implement/SKILL.md | 30 ++++++++++++++-------- skills/maintain/SKILL.md | 12 ++++----- skills/plan/SKILL.md | 11 ++++---- templates/analyze-page.md | 16 ++++++++---- 5 files changed, 82 insertions(+), 41 deletions(-) diff --git a/skills/analyze/SKILL.md b/skills/analyze/SKILL.md index 0bc991c..f1a5919 100644 --- a/skills/analyze/SKILL.md +++ b/skills/analyze/SKILL.md @@ -1,6 +1,6 @@ --- name: analyze -description: SDLC analysis stage. Gate on the designated model (model-config) or capability tags, lock the model for the stage via sdlc-gate, pick a plan from PLAN_CONTENTS, analyze user stories against the current state (working directory plus REPO_{HASH} inventory for reuse). Run WBS to produce numbered work packages, estimate them with CPM, split each into TDD todos, and write wiki page ANALYZE_{HASH}. Logic only - never write code or modify files. Use after planning and before implementation. +description: SDLC analysis stage. Gate on capability tags enforced in code by sdlc-gate (analyze requires reasoning-max, verified against the transcript's actual model id), confirm the source branch with the user, pick a plan from PLAN_CONTENTS, analyze user stories against the current state (working directory plus REPO_{HASH} inventory for reuse). Run WBS with handover work packages ranked first (spec before implementation), estimate them with CPM, split each into TDD todos, and write wiki page ANALYZE_{HASH} with real sample data. Logic only - never write code or modify files. Use after planning and before implementation. --- # analyze @@ -13,25 +13,51 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model gate and stage lock**: - 1. Run `jsc-cli/tools/model-config.sh resolve analyze` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (analysis requires the reasoning-high tag). - 2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. - 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock analyze {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. -2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` for plans whose status is the literal 「未分析」 (name and HASH), and read `ANALYZE_CONTENTS` for existing analyses. -3. Let the user choose per `jsc-ask:ask` rules: **extend an existing analysis** or **analyze a new plan**. State the impact scope on every option. -4. Analyze the plan page's user stories one by one against the **current state**, questioning via the `jsc-ask:ask` decision tree until no doubt remains; keep asking while consensus is missing. Current state means: - 1. Every file in the working directory. +1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed): + 1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`. + 2. Run `jsc-hooks/hooks/sdlc-gate.sh lock analyze`. The script reads the **actual** model id from the transcript, compares it against this stage's required tags (`reasoning-max`), and locks the stage only when they match. + 3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that. + 4. Exit 0 means the stage is locked. From now until the next stage's gate runs, the sdlc-gate hook blocks every prompt whose model stops satisfying the tags. +2. **Confirm the source branch** — the branch whose code counts as the current state: + 1. Report the working directory's current branch, plus the remote branches available (`git branch -r`) and whether the working tree is clean. + 2. Ask per `jsc-ask:ask` rules which branch the analysis reads from; state the impact scope on every option (analysing the wrong branch produces work packages for code that does not exist). + 3. When the chosen branch is not the current one, **stop and ask the user to switch**. This stage never switches branches, never stashes, and never touches the working tree — see `/jsc-shared:spec-git-safety`. + 4. Record the confirmed branch and its head sha on the analysis page. Completion condition: the user has confirmed the branch explicitly; never infer it from the current checkout alone. +3. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` for plans whose status is the literal 「未分析」 (name and HASH), and read `ANALYZE_CONTENTS` for existing analyses. +4. Let the user choose per `jsc-ask:ask` rules: **extend an existing analysis** or **analyze a new plan**. State the impact scope on every option. +5. Analyze the plan page's user stories one by one against the **current state**, questioning via the `jsc-ask:ask` decision tree until no doubt remains; keep asking while consensus is missing. Current state means: + 1. Every file in the working directory, on the branch confirmed in step 2. 2. **Reuse existing methods and endpoints whenever possible**: - Check the `REPO_{HASH}` inventory page first. Re-inventory when the feature or endpoint is missing, or when the recorded commit sha differs from the current one. - Re-inventory **MUST run as a sub agent**: analyze the repository's features and endpoints, attach the current commit sha, write back to `REPO_{HASH}` with `templates/repo-page.md`, and update `REPO_CONTENTS` per `templates/repo-contents.md`. - For each reuse candidate, confirm the file path and method name first, then analyze whether its logic fits the requirement. -5. Run a **Work Breakdown Structure (WBS)**: split the user stories into work packages, number them sequentially (`WP-01`, `WP-02`, ...) and mark dependencies. -6. Estimate every work package's effort in hours and days with the **Critical Path Method (CPM)**, and mark the critical path. -7. Split every work package into todos with **Test-Driven Development (TDD)**, formatted `[ ]` (open) / `[x]` (done). Each todo is one vertical slice: one seam, one test, one minimal implementation. Seams and anti-patterns: `references/tdd.md`. -8. Apply `templates/analyze-page.md` to create or update the analysis page and write it back via `jsc-gitea:wiki`. The page content is Traditional Chinese, exactly as the template dictates. -9. If the analysis page is new: add it to `ANALYZE_CONTENTS` per `templates/analyze-contents.md`, and flip the plan's status in `PLAN_CONTENTS` to the literal 「已分析」. +6. Run a **Work Breakdown Structure (WBS)**: split the user stories into work packages, number them sequentially (`WP-01`, `WP-02`, ...) and mark dependencies. +7. **Rank handover work packages first** — see 「交接優先」 below. Spec-shaped packages ship before implementation-shaped ones. +8. Estimate every work package's effort in hours and days with the **Critical Path Method (CPM)**, and mark the critical path. +9. Split every work package into todos with **Test-Driven Development (TDD)**, formatted `[ ]` (open) / `[x]` (done). Each todo is one vertical slice: one seam, one test, one minimal implementation. Seams and anti-patterns: `references/tdd.md`. +10. Apply `templates/analyze-page.md` to create or update the analysis page and write it back via `jsc-gitea:wiki`. The page content is Traditional Chinese, exactly as the template dictates. +11. If the analysis page is new: add it to `ANALYZE_CONTENTS` per `templates/analyze-contents.md`, and flip the plan's status in `PLAN_CONTENTS` to the literal 「已分析」. + +## 交接優先（handover first） + +A work package is a **handover package** when someone else — another person, another CLI, another team — has to act on its output. Interfaces, schemas, spec documents, acceptance criteria and sample payloads are handover output; endpoint bodies and UI wiring are not. + +- Mark every work package as 交接 `是` / `否` in the WBS table. +- **Order handover packages before implementation packages**, so the receiving side gets the spec while implementation is still open. Implementation packages are the backup queue (實作候補): they are still numbered, estimated and kept on the page, just ranked later. +- Dependencies still win: never place a package before one it depends on. Within the same dependency level, handover packages come first. +- Do not merge a spec and its implementation into one package — that removes the ability to hand the spec over early. Split them. + +## 範例資料（sample data） + +Every sample value on the analysis page — request and response payloads, field values, config snippets, test fixtures — follows this order: + +1. **Real data first.** Take values from an actual source: the database schema and rows, a real API response, an existing config or fixture file, logs. Record where each sample came from in the WBS table's 資料來源 column (for example `真實：dbo.Member`). +2. **Only when no source exists**, derive the value by reasoning from the surrounding logic — and label it as inferred (for example `推論：無來源`), so the receiving side knows it is unverified. +3. Never invent a plausible-looking value and present it as real, and never leave the origin of a sample unstated. +4. Real data goes on the page as **structure and format only**: field names, types, shapes. Never copy personal data onto the wiki — mask any personal identifier, and prefer describing the format over pasting the value. ## Hard limits - Never output a code snippet (file paths and method names are allowed). - Never modify any file in the working directory. +- Never switch, create or clean branches in this stage; ask the user to do it. diff --git a/skills/implement/SKILL.md b/skills/implement/SKILL.md index 9fa2a66..82f7b4d 100644 --- a/skills/implement/SKILL.md +++ b/skills/implement/SKILL.md @@ -1,6 +1,6 @@ --- name: implement -description: SDLC implementation stage. Gate on the designated model (model-config) or capability tags, lock the model for the stage via sdlc-gate, claim a ready work package from ANALYZE_CONTENTS with a work ticket, then complete its TDD todos one by one, updating the wiki after every item. Ends with jsc-review code-review and an optional MAINTAIN_CONTENTS entry. Use when analysis is done and code must be written; not for planning or analysis. +description: SDLC implementation stage. Gate on capability tags enforced in code by sdlc-gate (implement requires coding, verified against the transcript's actual model id), confirm the target branch with the user before writing any file, then claim a ready work package from ANALYZE_CONTENTS with a work ticket and complete its TDD todos one by one, updating the wiki after every item. Ends with jsc-review code-review and an optional MAINTAIN_CONTENTS entry. Use when analysis is done and code must be written; not for planning or analysis. --- # implement @@ -10,21 +10,29 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model gate and stage lock**: - 1. Run `jsc-cli/tools/model-config.sh resolve implement` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (implementation requires the coding tag). - 2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. - 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock implement {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. -2. **Generate a work ticket**: format `TICKET_{yyyyMMdd}_{HHmmss}_{HASH}`. `{HASH}` = the shared wiki hash for `{owner}/{repo}`, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`). Try to rename the current session to the ticket name (skip when the CLI does not support it). -3. Read `ANALYZE_CONTENTS` via `jsc-gitea:wiki` and list what is unfinished: plan name, HASH, work package number, count of open items. A selectable work package must satisfy all three: **unfinished, dependency-free (or all dependencies done), and not holding a work ticket**. -4. Let the user pick a work package per `jsc-ask:ask` rules (options state open-item count and estimated effort). Write the ticket into that work package's ticket column (the zh-TW field 「工作證」) on the analysis page and save it back to the wiki. **Only after the ticket is saved successfully may you proceed.** -5. List every open item of the work package and implement them **one at a time**: +1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed): + 1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`. + 2. Run `jsc-hooks/hooks/sdlc-gate.sh lock implement`. The script reads the **actual** model id from the transcript, compares it against this stage's required tags (`coding`), and locks the stage only when they match. + 3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that. + 4. Exit 0 means the stage is locked. From now until the next stage's gate runs, the sdlc-gate hook blocks every prompt whose model stops satisfying the tags. +2. **Confirm the target branch** — do this **before writing any file**: + 1. Report the current branch, whether the working tree is clean, and which of `origin/develop` / `origin/master` exist, plus the remote default branch resolved per `/jsc-shared:spec-git-safety`. + 2. Ask per `jsc-ask:ask` rules which branch this work merges into; state the impact scope on every option (the answer decides the PR target and, when it collides with the current branch, forces a new working branch). + 3. Uncommitted changes in the working tree → warn first and let the user commit or back them up; never discard them. + 4. Apply `/jsc-shared:spec-git-safety` to the confirmed target: source branch and target branch sharing a name means creating a new working branch instead of committing on the target; report the resulting branch name. + 5. Record the confirmed target branch on the analysis page next to the work ticket, and reuse it as the PR target in `jsc-git:pr`. Completion condition: the user has confirmed the target branch explicitly; never fall back to `develop` silently. +3. **Generate a work ticket**: format `TICKET_{yyyyMMdd}_{HHmmss}_{HASH}`. `{HASH}` = the shared wiki hash for `{owner}/{repo}`, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`). Try to rename the current session to the ticket name (skip when the CLI does not support it). +4. Read `ANALYZE_CONTENTS` via `jsc-gitea:wiki` and list what is unfinished: plan name, HASH, work package number, count of open items. A selectable work package must satisfy all three: **unfinished, dependency-free (or all dependencies done), and not holding a work ticket**. +5. Let the user pick a work package per `jsc-ask:ask` rules (options state open-item count and estimated effort). **List handover packages (交接 `是`) first** — the analysis page ranks spec delivery ahead of implementation, so keep that order in the options. Write the ticket into that work package's ticket column (the zh-TW field 「工作證」) on the analysis page and save it back to the wiki. **Only after the ticket is saved successfully may you proceed.** +6. List every open item of the work package and implement them **one at a time**: - Follow the TDD loop: red before green, one slice at a time; rules and anti-patterns in `references/tdd.md` (refactoring belongs to the review stage). - After each item, flip its `[ ]` to `[x]` on the analysis page and save to the wiki before starting the next item. -6. When all items are done, call `jsc-review:code-review` and wait for the review; on failure, fix and re-review until it passes. -7. Ask per `jsc-ask:ask` rules whether to register this project for maintenance: append to `MAINTAIN_CONTENTS` with `templates/maintain-contents.md`. Required: repository `{owner}/{repo}`, maintenance method, start date. Optional: end date (NULL = maintain forever), last-maintained time. +7. When all items are done, call `jsc-review:code-review` and wait for the review; on failure, fix and re-review until it passes. +8. Ask per `jsc-ask:ask` rules whether to register this project for maintenance: append to `MAINTAIN_CONTENTS` with `templates/maintain-contents.md`. Required: repository `{owner}/{repo}`, maintenance method, start date. Optional: end date (NULL = maintain forever), last-maintained time. ## Rules - The work ticket is a mutex: always skip work packages that already hold a ticket; never take one over. - Never batch wiki updates across items; one item, one update. +- Sample data written into code or fixtures follows the analysis page's 資料來源 column: real data where a source exists, reasoned values labelled as inferred where none does. Never invent a value and present it as real, and never copy personal data into fixtures — keep the format, drop the identity. - Everything the skill writes out (wiki content, commit messages, PR descriptions) stays Traditional Chinese per the STE100 rule. diff --git a/skills/maintain/SKILL.md b/skills/maintain/SKILL.md index 6083262..92404e3 100644 --- a/skills/maintain/SKILL.md +++ b/skills/maintain/SKILL.md @@ -1,6 +1,6 @@ --- name: maintain -description: SDLC maintenance stage. Gate on the designated model (model-config) or capability tags for the maintenance stage, lock the model via sdlc-gate, read projects still inside their maintenance window from MAINTAIN_CONTENTS, then run one sub agent per project: switch to develop or master, propose at least five maintenance actions, commit to a new branch, push, and PR. Update the last-maintained timestamp afterward. Use for periodic upkeep of delivered projects inside their maintenance window; not for projects still mid-implementation or not yet registered in MAINTAIN_CONTENTS. +description: SDLC maintenance stage. Gate on capability tags enforced in code by sdlc-gate (maintenance requires no specific tag, but the actual model id must be determinable from the transcript), read projects still inside their maintenance window from MAINTAIN_CONTENTS, then run one sub agent per project: switch to develop or master, propose at least five maintenance actions, commit to a new branch, push, and PR. Update the last-maintained timestamp afterward. Use for periodic upkeep of delivered projects inside their maintenance window; not for projects still mid-implementation or not yet registered in MAINTAIN_CONTENTS. --- # maintain @@ -10,11 +10,11 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model gate and stage lock**: - 1. Run `jsc-cli/tools/model-config.sh resolve maintain` to get the required model; if it prints nothing, fall back to the 「SDLC 階段需求」 table from `jsc-cli:models` (any listed model qualifies for maintenance). - 2. If the current model is not the required model, or is missing from the mapping table, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. - 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock maintain {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. - 4. Run this gate only when the stage changes; inside the maintenance stage the lock already enforces the model, so never re-gate between projects. +1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed): + 1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`. + 2. Run `jsc-hooks/hooks/sdlc-gate.sh lock maintain`. The script reads the **actual** model id from the transcript and checks it against this stage's required tags — maintenance requires no specific tag, so the gate passes as long as the actual model can be determined at all. + 3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that. + 4. Exit 0 means the stage is locked. Run this gate only when the stage changes; inside the maintenance stage the lock already covers every project, so never re-gate between projects. 2. Read `MAINTAIN_CONTENTS` via `jsc-gitea:wiki` and filter projects **still inside their maintenance window**: start date ≤ today, and (end date is NULL or ≥ today). 3. Every project **MUST run as a sub agent** with this flow: 1. Switch the project to the `develop` branch, falling back to `master`, and pull to latest. diff --git a/skills/plan/SKILL.md b/skills/plan/SKILL.md index 59d57d2..a2e1b59 100644 --- a/skills/plan/SKILL.md +++ b/skills/plan/SKILL.md @@ -1,6 +1,6 @@ --- name: plan -description: SDLC planning stage. Gate on the designated model (model-config) or capability tags, lock the model for the stage via sdlc-gate, pick or create a plan from PLAN_CONTENTS, then run a decision tree until goal, scope, and feasibility reach consensus. Produce user stories into wiki page PLAN_{HASH}. Logic only - never write code or modify files. Use when the user wants to start or refine a plan; not for analysis or implementation. +description: SDLC planning stage. Gate on capability tags enforced in code by sdlc-gate (plan requires reasoning-max, verified against the transcript's actual model id), pick or create a plan from PLAN_CONTENTS, then run a decision tree until goal, scope, and feasibility reach consensus. Produce user stories into wiki page PLAN_{HASH}. Logic only - never write code or modify files. Use when the user wants to start or refine a plan; not for analysis or implementation. --- # plan @@ -13,10 +13,11 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model gate and stage lock**: - 1. Run `jsc-cli/tools/model-config.sh resolve plan` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (planning requires the reasoning-high tag). - 2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate. - 3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock plan {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`. +1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed): + 1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`. + 2. Run `jsc-hooks/hooks/sdlc-gate.sh lock plan`. The script reads the **actual** model id from the transcript, compares it against this stage's required tags (`reasoning-max`), and locks the stage only when they match. + 3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that. + 4. Exit 0 means the stage is locked. From now until the next stage's gate runs, the sdlc-gate hook blocks every prompt whose model stops satisfying the tags. 2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` and list the plans whose status is the literal 「未分析」 (not analyzed), with names and HASH. 3. Let the user choose per `jsc-ask:ask` rules: **extend an existing plan** (list the not-analyzed plans as options) or **create a new plan**. State the impact scope on every option. 4. Question via the `jsc-ask:ask` decision tree until no doubt remains on all three items; keep asking while consensus is missing: diff --git a/templates/analyze-page.md b/templates/analyze-page.md index a0639e8..3ea0e87 100644 --- a/templates/analyze-page.md +++ b/templates/analyze-page.md @@ -4,6 +4,7 @@ - HASH：`{HASH}` - 對應計畫：[[PLAN_{HASH}]] - 存取庫：`{owner}/{repo}` +- 來源分支：`{使用者確認的分支}`（head sha：`{sha}`） - 狀態：未完成 - 建立時間：{yyyy-MM-dd HH:mm:ss} @@ -15,12 +16,17 @@ ## 工作分解結構（WBS） -| 編號 | 工作包名稱 | 相依 | 工時(h) | 天數 | 工作證 | 狀態 | -| --- | --- | --- | --- | --- | --- | --- | -| WP-01 | {名稱} | - | {h} | {d} | | 未完成 | -| WP-02 | {名稱} | WP-01 | {h} | {d} | | 未完成 | +交接工作包（規格、介面、驗收條件）排在實作工作包之前；實作為候補。相依關係優先於交接排序。 +資料來源欄記錄範例資料的出處：`真實：{來源}` 或 `推論：無來源`。 -- 關鍵路徑：{WP-01 → WP-02 → ⋯⋯}，總天數 {d} +| 編號 | 工作包名稱 | 交接 | 相依 | 工時(h) | 天數 | 資料來源 | 工作證 | 狀態 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | +| WP-01 | {規格類名稱} | 是 | - | {h} | {d} | 真實：{來源} | | 未完成 | +| WP-02 | {交接文件名稱} | 是 | WP-01 | {h} | {d} | 真實：{來源} | | 未完成 | +| WP-03 | {實作類名稱} | 否 | WP-01 | {h} | {d} | 推論：無來源 | | 未完成 | + +- 關鍵路徑：{WP-01 → WP-03 → ⋯⋯}，總天數 {d} +- 交接批次：{WP-01、WP-02}；實作候補：{WP-03、⋯⋯} ## 待辦事項（TDD） From ef4cbc8f8890d7f23b0da74ed2adf8695b056365 Mon Sep 17 00:00:00 2001 From: Jeffery Date: Mon, 24 Aug 2026 16:05:19 +0800 Subject: [PATCH 7/8] =?UTF-8?q?docs(README):=20=E6=9B=B4=E6=96=B0=E9=9A=8E?= =?UTF-8?q?=E6=AE=B5=E9=96=98=E9=96=80=E5=88=A4=E5=AE=9A=E8=88=87=E5=88=86?= =?UTF-8?q?=E6=94=AF=E7=A2=BA=E8=AA=8D=E8=AA=AA=E6=98=8E?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 8961b8f..63532e7 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # jsc-sdlc — 開發生命週期 -jsc 技能組的 sdlc domain：規劃 → 分析 → 實作 → 維護四個階段，全程以 wiki 頁追蹤（`PLAN_CONTENTS`、`PLAN_{HASH}`、`ANALYZE_CONTENTS`、`ANALYZE_{HASH}`、`REPO_CONTENTS`、`REPO_{HASH}`、`MAINTAIN_CONTENTS`）。另有異常頁（`ERROR_CONTENTS`、`ERROR_{HASH}`）記錄 hook 或流程失敗。每次切換階段先解析該階段的指定模型鏈（`jsc-cli/tools/model-config.sh get {stage}`，專案 `.jsc/models` 優先於 `$JSC_HOME/models.conf`）；沒有設定才退回模型能力標籤檢查。通過閘門後由 `jsc-hooks` 的 sdlc-gate hook 鎖定模型，直到下一階段的閘門重新上鎖；同一階段內換模型會被擋下。 +jsc 技能組的 sdlc domain：規劃 → 分析 → 實作 → 維護四個階段，全程以 wiki 頁追蹤（`PLAN_CONTENTS`、`PLAN_{HASH}`、`ANALYZE_CONTENTS`、`ANALYZE_{HASH}`、`REPO_CONTENTS`、`REPO_{HASH}`、`MAINTAIN_CONTENTS`）。另有異常頁（`ERROR_CONTENTS`、`ERROR_{HASH}`）記錄 hook 或流程失敗。每次切換階段先過模型閘門：由 `jsc-hooks/hooks/sdlc-gate.sh lock {stage}` 從 transcript 讀出**實際**模型 id，比對該階段的必要能力標籤（plan、analyze 需 `reasoning-max`；implement 需 `coding`；maintain 任意），不符就拒絕上鎖、該階段不得執行。判定全在程式層，模型不得自評標籤。通過後鎖定到下一階段的閘門重新上鎖；同一階段內把模型換成不合格的，下一輪提示會被 hook 以 exit 2 擋下。分析前先與使用者確認來源分支，寫檔前先確認目標分支。 ## 安裝、更新、移除 @@ -59,7 +59,7 @@ HASH 規則：`{owner}/{repo}` 的共用 wiki hash 一律由 `jsc-gitea/tools/ha ## 相關 domain -- [`jsc-cli`](https://gitea.jsc.idv.tw/plugins/cli)：指定模型鏈（`tools/model-config.sh`）與模型能力標籤（`jsc-cli:models`） +- [`jsc-cli`](https://gitea.jsc.idv.tw/plugins/cli)：模型能力標籤與階段閘門判定（`tools/model-tags.sh`、`references/model-tags.md`、`jsc-cli:models`）、偏好模型鏈（`tools/model-config.sh`） - [`jsc-hooks`](https://gitea.jsc.idv.tw/plugins/hooks)：sdlc-gate 階段模型鎖定 - [`jsc-gitea`](https://gitea.jsc.idv.tw/plugins/gitea)：wiki 讀寫 - [`jsc-review`](https://gitea.jsc.idv.tw/plugins/review)：實作完成後的程式碼審查 From 9a6ca0f9ee21bfe20b5fd873c2c4d3bdfd856d5f Mon Sep 17 00:00:00 2001 From: Jeffery Date: Mon, 24 Aug 2026 16:05:19 +0800 Subject: [PATCH 8/8] =?UTF-8?q?chore(plugin=20=E7=89=88=E6=9C=AC):=20?= =?UTF-8?q?=E4=B8=89=E4=BB=BD=20manifest=20=E5=8D=87=E7=89=88=E8=87=B3=200?= =?UTF-8?q?.0.5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 (1M context) --- .claude-plugin/plugin.json | 2 +- .codex-plugin/plugin.json | 2 +- plugin.json | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index 4a6d966..620cf13 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.4", + "version": "0.0.5", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills", "author": { diff --git a/.codex-plugin/plugin.json b/.codex-plugin/plugin.json index 039436f..73ee9a9 100644 --- a/.codex-plugin/plugin.json +++ b/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.4", + "version": "0.0.5", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills" } diff --git a/plugin.json b/plugin.json index a0ca998..f6ed278 100644 --- a/plugin.json +++ b/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.4", + "version": "0.0.5", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills/" }