skills/analyze/SKILL.md

@@ -3,32 +3,32 @@ 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_{yyyyMMdd}_{HHmmss}_{HASH}. Logic only - never write code or modify files. Use after planning and before implementation.
 ---
 
-# analyze — 分析
+# analyze
 
-目標：產出或補充 WIKI 分析頁 `ANALYZE_{yyyyMMdd}_{HHmmss}_{HASH}`。
-本技能是**純邏輯**階段：不可以出現任何程式碼，也**禁止修改任何檔案**。
+Goal: create or extend the wiki analysis page `ANALYZE_{yyyyMMdd}_{HHmmss}_{HASH}`.
+This skill is a **logic-only** stage: never output code, and **never modify any file**.
 
-`{HASH}` = `{owner}/{repo}` 的 SHA-1 前 8 碼、大寫。
-所有 wiki 讀寫一律經由 `jsc-gitea:wiki`。
+`{HASH}` = first 8 chars of the SHA-1 of `{owner}/{repo}`, uppercase.
+All wiki reads and writes go through `jsc-gitea:wiki`.
 
-## 流程
+## Steps
 
-1. **模型能力檢查**：依 `jsc-cli:models` 的能力標籤確認目前模型具備「分析」能力。不適合就阻擋流程，並告知使用者建議改用的模型。
-2. 經由 `jsc-gitea:wiki` 讀取 `PLAN_CONTENTS` 的**未分析**計畫（名稱與 HASH），並讀取 `ANALYZE_CONTENTS` 的既有分析。
-3. 依 `jsc-ask:ask` 規則讓使用者選擇：**補充既有分析**或**分析新計畫**。每個選項標明影響範圍。
-4. 搭配**現況**，依 `jsc-ask:ask` 決策樹逐條分析計畫頁的使用者故事，直到補全所有疑慮；只要還沒達成共識就繼續詢問。現況定義：
-   1. 工作目錄的所有檔案。
-   2. **盡量複用既有方法或端點**：
-      - 優先查 `REPO_{HASH}` 盤點頁。若功能與端點不存在，或紀錄的 commit sha 與目前不同，就重新盤點。
-      - 重新盤點**必須以 sub agent 執行**：分析該存取庫的功能與端點，加上目前 commit sha，套用 `templates/repo-page.md` 寫回 `REPO_{HASH}`，並依 `templates/repo-contents.md` 更新 `REPO_CONTENTS`。
-      - 對候選的複用目標，先確認檔案路徑與方法名稱，再分析邏輯是否符合需求。
-5. 執行**工作分解結構（WBS）**：把使用者故事拆成工作包，每個工作包給編號（`WP-01`、`WP-02` 依序遞增）並標明相依關係。
-6. 以**關鍵路徑法（CPM）**估算每個工作包的工時與天數，標出關鍵路徑。
-7. 以**測試驅動開發（TDD）**把每個工作包拆解成多個待辦事項，格式 `[ ]`（未完成）/ `[x]`（完成），每項為一個垂直切片（一個接縫、一個測試、一個最小實作）；接縫與反模式見 `references/tdd.md`。
-8. 套用 `templates/analyze-page.md` 產生或更新分析頁，經由 `jsc-gitea:wiki` 寫回。
-9. 若是新的分析頁：依 `templates/analyze-contents.md` 加入 `ANALYZE_CONTENTS`，並把 `PLAN_CONTENTS` 對應計畫的狀態改為「已分析」。
+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.
+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.
+   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 「已分析」.
 
-## 禁止事項
+## Hard limits
 
-- 不可輸出任何程式碼片段（檔案路徑與方法名稱可以）。
-- 不可修改工作目錄的任何檔案。
+- Never output a code snippet (file paths and method names are allowed).
+- Never modify any file in the working directory.

skills/implement/SKILL.md

@@ -3,24 +3,25 @@ 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.
 ---
 
-# implement — 實作
+# implement
 
-目標：逐項完成分析頁的待辦事項；**每完成一項就必須立即更新 WIKI 狀態**。
-所有 wiki 讀寫一律經由 `jsc-gitea:wiki`。
+Goal: complete the analysis page's todos one by one; **update the wiki status immediately after every completed item**.
+All wiki reads and writes go through `jsc-gitea:wiki`.
 
-## 流程
+## Steps
 
-1. **模型能力檢查**：依 `jsc-cli:models` 的能力標籤確認目前模型具備「實作」能力。不適合就阻擋流程，並告知使用者建議改用的模型。
-2. **產生工作證**：格式 `TICKET_{session id 前 8 碼}_{yyyyMMddHHmmss}`，並嘗試將目前 session 重新命名為工作證名稱（CLI 不支援時略過）。
-3. 經由 `jsc-gitea:wiki` 讀取 `ANALYZE_CONTENTS`，列出未完成的：計畫名稱、HASH、工作包編號、未完成項目數量。可選的工作包必須同時滿足：**未完成、無相依（或相依都已完成）、無工作證**。
-4. 依 `jsc-ask:ask` 規則讓使用者選擇要實作的工作包（選項標明未完成項目數與預估工時）。把工作證寫入分析頁該工作包的「工作證」欄位並寫回 wiki，**成功標上工作證才可以進入下一步**。
-5. 列出該工作包所有未完成項目，**逐項實作**：
-   - 依 TDD 循環：先紅後綠、一次一片；規則與反模式見 `references/tdd.md`（重構留給審查階段）。
-   - 每完成一項，立即把分析頁該項 `[ ]` 改為 `[x]` 並寫回 wiki，才可以進行下一項。
-6. 全部完成後呼叫 `jsc-review:code-review` 等待程式碼審查；審查未過就修正並重新審查。
-7. 依 `jsc-ask:ask` 規則詢問是否將本專案加入維護：套用 `templates/maintain-contents.md` 加入 `MAINTAIN_CONTENTS`。必填：存取庫名稱 `{owner}/{repo}`、維護方式、維護起始日。選填：維護截止日（NULL = 永久維護）、前次維護時間。
+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.
+2. **Generate a work ticket**: format `TICKET_{first 8 chars of session id}_{yyyyMMddHHmmss}`. 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.
+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
 
-- 工作證是互斥鎖：看到已有工作證的工作包一律跳過，不可搶占。
-- 不可一次完成多項才批次更新 wiki；一項一更新。
+- 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.
+- Everything the skill writes out (wiki content, commit messages, PR descriptions) stays Traditional Chinese per the STE100 rule.

skills/maintain/SKILL.md

@@ -3,24 +3,24 @@ name: maintain
 description: SDLC maintenance stage. Gate on model capability tags, 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 — 維護
+# maintain
 
-目標：逐項完成維護目錄內專案的例行維護。
-所有 wiki 讀寫一律經由 `jsc-gitea:wiki`。
+Goal: run routine maintenance for every project in the maintenance contents page.
+All wiki reads and writes go through `jsc-gitea:wiki`.
 
-## 流程
+## Steps
 
-1. **模型能力檢查**：依 `jsc-cli:models` 的「SDLC 階段需求」表確認目前模型適合維護階段（維護接受任意標籤，但模型必須列於對照表）。不適合就阻擋流程，並告知使用者建議改用的模型。
-2. 經由 `jsc-gitea:wiki` 讀取 `MAINTAIN_CONTENTS`，篩出**仍在維護期間內**的專案：維護起始日 ≤ 今天，且（維護截止日為 NULL 或 ≥ 今天）。
-3. 每一個專案**必須啟動一個 sub agent** 依以下流程執行：
-   1. 將專案切換到 `develop` 分支，沒有就切 `master`，並更新到最新。
-   2. 提供**至少五種**建議的維護方法，依專案狀況取捨執行，例如：
-      - 相依套件更新（複用 `jsc-pkg:pkg-update`）
-      - 安全性弱點掃描與修補
-      - 死碼與過期註解清理
-      - 測試覆蓋率補強
-      - 文件與 README 同步
-      - 建置警告消除
-   3. 依 `jsc-git:commit` 把變更 commit 到新分支，push 後依 `jsc-git:pr` 建立 PR 回 develop 或 master。
-   4. 更新 `MAINTAIN_CONTENTS` 中該專案的「前次維護時間」為今天。
-4. 主 agent 彙整回報：每個專案執行了哪些維護方法、PR 連結、失敗原因。
+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.
+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.
+   2. Propose **at least five** maintenance methods and apply the ones that fit the project, for example:
+      - dependency updates (reuse `jsc-pkg:pkg-update`)
+      - security vulnerability scan and patching
+      - dead code and stale comment cleanup
+      - test coverage reinforcement
+      - docs and README synchronization
+      - build warning elimination
+   3. Commit the changes to a new branch per `jsc-git:commit`, push, then open a PR back to develop or master per `jsc-git:pr`.
+   4. Update the project's last-maintained field (the zh-TW column 「前次維護時間」) in `MAINTAIN_CONTENTS` to today.
+4. The main agent reports the summary: maintenance methods applied per project, PR links, and failure reasons. The report and all generated wiki content, commits, and PR descriptions stay Traditional Chinese per the STE100 rule.

skills/plan/SKILL.md

@@ -3,29 +3,29 @@ 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_{yyyyMMdd}_{HHmmss}_{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 — 規劃
+# plan
 
-目標：產出或補充 WIKI 計畫頁 `PLAN_{yyyyMMdd}_{HHmmss}_{HASH}`。
-本技能是**純邏輯**階段：不可以出現任何程式碼，也**禁止修改任何檔案**。
+Goal: create or extend the wiki plan page `PLAN_{yyyyMMdd}_{HHmmss}_{HASH}`.
+This skill is a **logic-only** stage: never output code, and **never modify any file**.
 
-`{HASH}` = `{owner}/{repo}` 的 SHA-1 前 8 碼、大寫。
-所有 wiki 讀寫一律經由 `jsc-gitea:wiki`。
+`{HASH}` = first 8 chars of the SHA-1 of `{owner}/{repo}`, uppercase.
+All wiki reads and writes go through `jsc-gitea:wiki`.
 
-## 流程
+## Steps
 
-1. **模型能力檢查**：依 `jsc-cli:models` 的能力標籤確認目前模型具備「規劃」能力。不適合就阻擋流程，並告知使用者建議改用的模型。
-2. 經由 `jsc-gitea:wiki` 讀取 `PLAN_CONTENTS`，列出**未分析**的計畫名稱與 HASH。
-3. 依 `jsc-ask:ask` 規則讓使用者選擇：**補充既有計畫**（列出未分析計畫為選項）或**新建計畫**。每個選項標明影響範圍。
-4. 依 `jsc-ask:ask` 決策樹詢問，補全以下三項直到沒有疑慮；只要還沒達成共識就繼續詢問：
-   - 計畫目標：要解決什麼問題、成功的判斷標準。
-   - 計畫範圍：包含什麼、排除什麼、涉及哪些存取庫。
-   - 可行性：系統架構與資料來源是否支撐目標。
-5. 由共識產生**使用者故事**（身為⋯⋯我想要⋯⋯以便⋯⋯），逐條列出。
-6. 套用 `templates/plan-page.md` 產生或更新計畫頁，經由 `jsc-gitea:wiki` 寫回。
-7. 若是新的計畫頁，套用 `templates/plan-contents.md` 的條目格式，將其加入 `PLAN_CONTENTS`（狀態=未分析）。
+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.
+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:
+   - Goal: the problem to solve and the criteria for success.
+   - Scope: what is included, what is excluded, which repositories are involved.
+   - Feasibility: whether the system architecture and data sources support the goal.
+5. Turn the consensus into **user stories** (the zh-TW pattern 「身為⋯⋯我想要⋯⋯以便⋯⋯」), one per line.
+6. Apply `templates/plan-page.md` to create or update the plan page, and write it back via `jsc-gitea:wiki`. The page content is Traditional Chinese, exactly as the template dictates.
+7. If the plan page is new, add it to `PLAN_CONTENTS` using the entry format of `templates/plan-contents.md`, with status set to the literal 「未分析」.
 
-## 禁止事項
+## Hard limits
 
-- 不可輸出任何程式碼片段。
-- 不可修改工作目錄的任何檔案。
-- 不可跳過決策樹直接假設需求。
+- Never output a code snippet.
+- Never modify any file in the working directory.
+- Never skip the decision tree and assume requirements.