diff --git a/skills/commit/SKILL.md b/skills/commit/SKILL.md
index eb396a1..2543d6d 100644
--- a/skills/commit/SKILL.md
+++ b/skills/commit/SKILL.md
@@ -3,38 +3,38 @@ name: commit
 description: Group all pending file changes by conventional type and feature, then commit each group as {type}({scope}): {message}. Message style is full (What/Why/How/Who), brief (one line from git diff), or custom, chosen via decision tree. Use whenever changes must be committed; not for push or PR creation.
 ---
 
-# commit — 分組認可檔案變更
+# commit — group and commit file changes
 
-## 步驟
+## Steps
 
-1. 追蹤所有檔案變更：先 `git status --porcelain` 檢視全部變更，再逐組 `git add`（不可盲目 `git add -A` 後一次 commit）。
-2. 依「同類型 + 同需求/功能」將檔案變更分組，一組一個 commit。
-3. 每組依格式認可：`{類型}({需求 or 功能}): {訊息}`。
+1. Track every file change: inspect all changes with `git status --porcelain` first, then `git add` group by group. Never `git add -A` and commit everything at once.
+2. Group the changes by same type plus same requirement or feature. One group is one commit.
+3. Commit each group with the format `{type}({requirement or feature}): {message}`.
 
-## 類型表
+## Type table
 
-| 類型 | 用途 |
+| Type | Purpose |
 | --- | --- |
-| feat | 新增/修改功能 |
-| fix | 修補 bug |
-| docs | 文件 |
-| style | 格式（不影響程式碼運行的變動） |
-| refactor | 重構（既不是新增功能，也不是修補 bug 的程式碼變動） |
-| perf | 改善效能 |
-| test | 增加測試 |
-| chore | 建構程序或輔助工具的變動 |
-| revert | 撤銷先前的 commit |
+| feat | add or change a feature |
+| fix | fix a bug |
+| docs | documentation |
+| style | formatting; no change to how the code runs |
+| refactor | code change that neither adds a feature nor fixes a bug |
+| perf | improve performance |
+| test | add tests |
+| chore | build process or tooling change |
+| revert | revert an earlier commit |
 
-## 訊息格式（三選一）
+## Message format (pick one of three)
 
-依 `jsc-ask:ask` 規則詢問使用者；問詢紀錄或本 session 已有慣例就不再問。
+Ask the user per the `jsc-ask:ask` rules. Skip the question when the question record or this session already holds a convention.
 
-1. **完整版**：包含做什麼（What）、為什麼做（Why）、怎麼做（How）、哪個功能做（Who）。
-2. **簡易版**：根據 `git diff` 總結出一句描述。
-3. **自訂**：使用者自行輸入訊息。
+1. **Full**: covers What, Why, How, and Who (which feature).
+2. **Brief**: one sentence summarized from `git diff`.
+3. **Custom**: the user types the message.
 
-## 規則
+## Rules
 
-1. 分組與訊息草擬的細節**必須以 sub agent 執行**，主 agent 只確認分組結果與執行 commit。
-2. 訊息一律 UTF-8 繁體中文（類型與 scope 除外）。
-3. 不可 push；push 與 PR 由 `jsc-git:pr` 負責。
+1. The grouping and message drafting details **MUST run as a sub agent**. The main agent only confirms the grouping and runs the commits.
+2. Write messages in UTF-8 Traditional Chinese (the type and scope stay in English), per the STE100 output rule.
+3. Never push. Push and PR belong to `jsc-git:pr`.
diff --git a/skills/pr/SKILL.md b/skills/pr/SKILL.md
index 28a58e2..1832ce9 100644
--- a/skills/pr/SKILL.md
+++ b/skills/pr/SKILL.md
@@ -3,27 +3,27 @@ name: pr
 description: Commit all changes via jsc-git:commit, create a target branch named from the highest-priority commit type plus a summarized title, push, then open a Gitea PR with the templated description. Branch priority is revert > fix > feat > perf > refactor > test > docs > style > chore. Use when work is ready for review; not for plain commits.
 ---
 
-# pr — 建立 Push Request
+# pr — create a Push Request
 
-## 步驟
+## Steps
 
-1. 呼叫 `jsc-git:commit` 將所有檔案變更認可完成。
-2. 決定來源分支：遠端存在 `develop` 就用 `develop`，否則用 `main`（再否則用 `master`）。
-3. 從遠端來源分支建立目標分支：
-   1. 類型取所有 commit 中優先度最高者：`revert > fix > feat > perf > refactor > test > docs > style > chore`。
-   2. 標題從所有 commit 的訊息總結出一句。
-   3. 分支名**只允許 ASCII**，一律 slug 化：`{類型}/{需求 or 功能}-{標題}`。需求/功能與標題先翻譯成英文短語，再轉小寫、非 `a-z0-9` 字元以連字號取代、連續連字號合併、頭尾連字號移除（例：`feat/order-匯出報表` → `feat/order-export-report`）。不可含空白、括號、冒號與任何非 ASCII 字元。
-4. `git push -u origin {目標分支}`。
-5. 建立 PR：`jsc-gitea/tools/gitea.sh pr-create {owner}/{repo} {目標分支} {來源分支} "{分支名}" {描述檔}`。
-   - 標題 = 分支名。
-   - 描述先套用 `templates/pr-description.md` 寫入暫存檔再帶入。
-6. **前置 PR 阻擋**：描述中有前置 Push Request 時，執行
-   `jsc-gitea/tools/gitea.sh pr-depend {owner}/{repo} {本 PR 編號} {前置 owner}/{repo} {前置 PR 編號}`
-   把本 PR 掛上依賴；前置 PR 未關閉前 Gitea 會阻擋合併，避免誤合併。API 不可用時降級：PR 標題加 `WIP:` 前綴（Gitea 原生阻擋合併），前置完成後移除。
-7. 回報 PR URL。
+1. Call `jsc-git:commit` to commit every file change first.
+2. Pick the base branch: use `develop` when it exists on the remote, else `main`, else `master`.
+3. Create the target branch from the remote base branch:
+   1. Take the type with the highest priority across all commits: `revert > fix > feat > perf > refactor > test > docs > style > chore`.
+   2. Summarize one title from all commit messages.
+   3. Branch names allow **ASCII only**; always slugify as `{type}/{requirement or feature}-{title}`. Translate the requirement and title into a short English phrase first, then lowercase, replace every character outside `a-z0-9` with a hyphen, collapse consecutive hyphens, and trim leading and trailing hyphens (example: `feat/order-匯出報表` → `feat/order-export-report`). No spaces, parentheses, colons, or any non-ASCII character.
+4. Run `git push -u origin {target branch}`.
+5. Create the PR: `jsc-gitea/tools/gitea.sh pr-create {owner}/{repo} {target branch} {base branch} "{branch name}" {description file}`.
+   - Title = branch name.
+   - Write the description into a temp file first, using `templates/pr-description.md` (a Traditional Chinese template; the generated description stays in Traditional Chinese per the STE100 output rule).
+6. **Prerequisite PR blocking**: when the description lists a prerequisite Push Request, run
+   `jsc-gitea/tools/gitea.sh pr-depend {owner}/{repo} {this PR number} {prerequisite owner}/{repo} {prerequisite PR number}`
+   to add the dependency. Gitea then blocks merging until the prerequisite PR closes. If the API is unavailable, degrade: prefix the PR title with `WIP:` (Gitea blocks merging natively) and remove it once the prerequisite is done.
+7. Report the PR URL.
 
-## 規則
+## Rules
 
-1. 描述範本各節不可留空：沒有計畫/分析頁就填「無」，沒有前置 PR 就填「無」。
-2. 計畫頁與分析頁連結由 `jsc-sdlc` 的 wiki 頁取得；分析頁連結必須導向工作包標題錨點。
-3. 描述草擬的細節**必須以 sub agent 執行**。
+1. No template section may stay empty: fill the literal 「無」 when there is no plan page, analyze page, or prerequisite PR.
+2. Take the plan page and analyze page links from the `jsc-sdlc` wiki pages; the analyze link must point at the work package heading anchor.
+3. The description drafting details **MUST run as a sub agent**.