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 碼、大寫。
+`{HASH}` = first 8 chars of the SHA-1 of `{owner}/{repo}`, uppercase.
-所有 wiki 讀寫一律經由 `jsc-gitea:wiki`。
+All wiki reads and writes go through `jsc-gitea:wiki`.
 
-## 流程
+## Steps
 
-1. **模型能力檢查**：依 `jsc-cli:models` 的能力標籤確認目前模型具備「分析」能力。不適合就阻擋流程，並告知使用者建議改用的模型。
+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. 經由 `jsc-gitea:wiki` 讀取 `PLAN_CONTENTS` 的**未分析**計畫（名稱與 HASH），並讀取 `ANALYZE_CONTENTS` 的既有分析。
+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. 依 `jsc-ask:ask` 規則讓使用者選擇：**補充既有分析**或**分析新計畫**。每個選項標明影響範圍。
+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. 搭配**現況**，依 `jsc-ask:ask` 決策樹逐條分析計畫頁的使用者故事，直到補全所有疑慮；只要還沒達成共識就繼續詢問。現況定義：
+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. 工作目錄的所有檔案。
+   1. Every file in the working directory.
-   2. **盡量複用既有方法或端點**：
+   2. **Reuse existing methods and endpoints whenever possible**:
-      - 優先查 `REPO_{HASH}` 盤點頁。若功能與端點不存在，或紀錄的 commit sha 與目前不同，就重新盤點。
+      - 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.
-      - 重新盤點**必須以 sub agent 執行**：分析該存取庫的功能與端點，加上目前 commit sha，套用 `templates/repo-page.md` 寫回 `REPO_{HASH}`，並依 `templates/repo-contents.md` 更新 `REPO_CONTENTS`。
+      - 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. 執行**工作分解結構（WBS）**：把使用者故事拆成工作包，每個工作包給編號（`WP-01`、`WP-02` 依序遞增）並標明相依關係。
+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. 以**關鍵路徑法（CPM）**估算每個工作包的工時與天數，標出關鍵路徑。
+6. Estimate every work package's effort in hours and days with the **Critical Path Method (CPM)**, and mark the critical path.
-7. 以**測試驅動開發（TDD）**把每個工作包拆解成多個待辦事項，格式 `[ ]`（未完成）/ `[x]`（完成），每項為一個垂直切片（一個接縫、一個測試、一個最小實作）；接縫與反模式見 `references/tdd.md`。
+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. 套用 `templates/analyze-page.md` 產生或更新分析頁，經由 `jsc-gitea:wiki` 寫回。
+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. 若是新的分析頁：依 `templates/analyze-contents.md` 加入 `ANALYZE_CONTENTS`，並把 `PLAN_CONTENTS` 對應計畫的狀態改為「已分析」。
+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 狀態**。
+Goal: complete the analysis page's todos one by one; **update the wiki status immediately after every completed item**.
-所有 wiki 讀寫一律經由 `jsc-gitea:wiki`。
+All wiki reads and writes go through `jsc-gitea:wiki`.
 
-## 流程
+## Steps
 
-1. **模型能力檢查**：依 `jsc-cli:models` 的能力標籤確認目前模型具備「實作」能力。不適合就阻擋流程，並告知使用者建議改用的模型。
+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. **產生工作證**：格式 `TICKET_{session id 前 8 碼}_{yyyyMMddHHmmss}`，並嘗試將目前 session 重新命名為工作證名稱（CLI 不支援時略過）。
+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. 經由 `jsc-gitea:wiki` 讀取 `ANALYZE_CONTENTS`，列出未完成的：計畫名稱、HASH、工作包編號、未完成項目數量。可選的工作包必須同時滿足：**未完成、無相依（或相依都已完成）、無工作證**。
+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. 依 `jsc-ask:ask` 規則讓使用者選擇要實作的工作包（選項標明未完成項目數與預估工時）。把工作證寫入分析頁該工作包的「工作證」欄位並寫回 wiki，**成功標上工作證才可以進入下一步**。
+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. 列出該工作包所有未完成項目，**逐項實作**：
+5. List every open item of the work package and implement them **one at a time**:
-   - 依 TDD 循環：先紅後綠、一次一片；規則與反模式見 `references/tdd.md`（重構留給審查階段）。
+   - 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).
-   - 每完成一項，立即把分析頁該項 `[ ]` 改為 `[x]` 並寫回 wiki，才可以進行下一項。
+   - After each item, flip its `[ ]` to `[x]` on the analysis page and save to the wiki before starting the next item.
-6. 全部完成後呼叫 `jsc-review:code-review` 等待程式碼審查；審查未過就修正並重新審查。
+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. 依 `jsc-ask:ask` 規則詢問是否將本專案加入維護：套用 `templates/maintain-contents.md` 加入 `MAINTAIN_CONTENTS`。必填：存取庫名稱 `{owner}/{repo}`、維護方式、維護起始日。選填：維護截止日（NULL = 永久維護）、前次維護時間。
+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
 
-- 工作證是互斥鎖：看到已有工作證的工作包一律跳過，不可搶占。
+- The work ticket is a mutex: always skip work packages that already hold a ticket; never take one over.
-- 不可一次完成多項才批次更新 wiki；一項一更新。
+- 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
 
-目標：逐項完成維護目錄內專案的例行維護。
+Goal: run routine maintenance for every project in the maintenance contents page.
-所有 wiki 讀寫一律經由 `jsc-gitea:wiki`。
+All wiki reads and writes go through `jsc-gitea:wiki`.
 
-## 流程
+## Steps
 
-1. **模型能力檢查**：依 `jsc-cli:models` 的「SDLC 階段需求」表確認目前模型適合維護階段（維護接受任意標籤，但模型必須列於對照表）。不適合就阻擋流程，並告知使用者建議改用的模型。
+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. 經由 `jsc-gitea:wiki` 讀取 `MAINTAIN_CONTENTS`，篩出**仍在維護期間內**的專案：維護起始日 ≤ 今天，且（維護截止日為 NULL 或 ≥ 今天）。
+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. 每一個專案**必須啟動一個 sub agent** 依以下流程執行：
+3. Every project **MUST run as a sub agent** with this flow:
-   1. 將專案切換到 `develop` 分支，沒有就切 `master`，並更新到最新。
+   1. Switch the project to the `develop` branch, falling back to `master`, and pull to latest.
-   2. 提供**至少五種**建議的維護方法，依專案狀況取捨執行，例如：
+   2. Propose **at least five** maintenance methods and apply the ones that fit the project, for example:
-      - 相依套件更新（複用 `jsc-pkg:pkg-update`）
+      - dependency updates (reuse `jsc-pkg:pkg-update`)
-      - 安全性弱點掃描與修補
+      - security vulnerability scan and patching
-      - 死碼與過期註解清理
+      - dead code and stale comment cleanup
-      - 測試覆蓋率補強
+      - test coverage reinforcement
-      - 文件與 README 同步
+      - docs and README synchronization
-      - 建置警告消除
+      - build warning elimination
-   3. 依 `jsc-git:commit` 把變更 commit 到新分支，push 後依 `jsc-git:pr` 建立 PR 回 develop 或 master。
+   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. 更新 `MAINTAIN_CONTENTS` 中該專案的「前次維護時間」為今天。
+   4. Update the project's last-maintained field (the zh-TW column 「前次維護時間」) in `MAINTAIN_CONTENTS` to today.
-4. 主 agent 彙整回報：每個專案執行了哪些維護方法、PR 連結、失敗原因。
+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 碼、大寫。
+`{HASH}` = first 8 chars of the SHA-1 of `{owner}/{repo}`, uppercase.
-所有 wiki 讀寫一律經由 `jsc-gitea:wiki`。
+All wiki reads and writes go through `jsc-gitea:wiki`.
 
-## 流程
+## Steps
 
-1. **模型能力檢查**：依 `jsc-cli:models` 的能力標籤確認目前模型具備「規劃」能力。不適合就阻擋流程，並告知使用者建議改用的模型。
+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. 經由 `jsc-gitea:wiki` 讀取 `PLAN_CONTENTS`，列出**未分析**的計畫名稱與 HASH。
+2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` and list the plans whose status is the literal 「未分析」 (not analyzed), with names and HASH.
-3. 依 `jsc-ask:ask` 規則讓使用者選擇：**補充既有計畫**（列出未分析計畫為選項）或**新建計畫**。每個選項標明影響範圍。
+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. 依 `jsc-ask:ask` 決策樹詢問，補全以下三項直到沒有疑慮；只要還沒達成共識就繼續詢問：
+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. 由共識產生**使用者故事**（身為⋯⋯我想要⋯⋯以便⋯⋯），逐條列出。
+5. Turn the consensus into **user stories** (the zh-TW pattern 「身為⋯⋯我想要⋯⋯以便⋯⋯」), one per line.
-6. 套用 `templates/plan-page.md` 產生或更新計畫頁，經由 `jsc-gitea:wiki` 寫回。
+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. 若是新的計畫頁，套用 `templates/plan-contents.md` 的條目格式，將其加入 `PLAN_CONTENTS`（狀態=未分析）。
+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.