JiangWay · AdrianTheopold · Jun 22, 2026
diff --git a/superpowers-bridge/templates/brainstorm.md b/superpowers-bridge/templates/brainstorm.md
@@ -1,12 +1,14 @@
 <!--
 Raw capture of superpowers:brainstorming output.
 
-本檔原樣捕捉 brainstorming skill 的產出，不強制結構。
-Skill 的自然產出通常是 decision log 格式（背景 → 決議鏈 Q1-Qn → 設計取捨），
-但依對話內容可能有不同組織方式。
+This file captures the brainstorming skill's output as-is, without forcing
+any structure. The skill's natural output is typically a decision-log format
+(background → decision chain Q1-Qn → design trade-offs), but the organization
+may vary with the conversation.
 
-design.md 從本檔萃取並重新整理為結構化設計文件。
+design.md is extracted and reorganized from this file into a structured
+design document.
 
-不要將本檔的內容複製到 design.md — design.md 是獨立的重組產物，
-兩者互補但不重疊。
+Do NOT copy this file's content into design.md — design.md is an independent
+reorganized artifact. The two are complementary, not overlapping.
 -->
diff --git a/superpowers-bridge/templates/design.md b/superpowers-bridge/templates/design.md
@@ -1,49 +1,51 @@
-## Context
-
-<!--
-Background, current state, constraints, stakeholders.
-brainstorm.md 記錄了探索過程（替代方案 + 選定方向）；
-本檔承接選定方向，展開完整技術設計。
--->
-
-## Goals / Non-Goals
-
-**Goals:**
-<!-- What this design aims to achieve -->
-
-**Non-Goals:**
-<!-- What is explicitly out of scope -->
-
-## Decisions
-
-<!--
-所有技術決策的唯一來源（single source of truth）。
-brainstorm.md 的 Agreed Approach 記錄了「選了哪條路」，
-本段記錄「那條路上的每個岔口怎麼選的」。
-
-每個決策建議結構：
-### D1：<決策標題>
-- **選擇**：<採用的做法>
-- **理由**：<為何這樣選>
-- **已考慮 alternative**：<被拒方案 + 拒絕原因>
--->
-
-## Risks / Trade-offs
-
-<!--
-Known risks and trade-offs.
-Format: [Risk] <描述> → Mitigation: <緩解措施>
-[Trade-off] <取捨描述> → 接受理由
--->
-
-## Migration Plan
-
-<!--
-部署順序、rollback 策略、驗收條件。
-若本 change 不涉及部署變更（純加套件、無 endpoint / DB 變更），
-可寫「N/A — 本 change 不涉及部署變更」。
--->
-
-## Open Questions
-
-<!-- Outstanding decisions or unknowns to resolve -->
+## Context
+
+<!--
+Background, current state, constraints, stakeholders.
+brainstorm.md records the exploration process (alternatives considered +
+chosen direction); this file picks up the chosen direction and expands it
+into the full technical design.
+-->
+
+## Goals / Non-Goals
+
+**Goals:**
+<!-- What this design aims to achieve -->
+
+**Non-Goals:**
+<!-- What is explicitly out of scope -->
+
+## Decisions
+
+<!--
+Single source of truth for all technical decisions.
+brainstorm.md's Agreed Approach records *which road was chosen*;
+this section records *how each fork along that road was decided*.
+
+Suggested structure per decision:
+### D1: <decision title>
+- **Choice**: <the approach adopted>
+- **Rationale**: <why it was chosen>
+- **Alternatives considered**: <rejected option + reason for rejection>
+-->
+
+## Risks / Trade-offs
+
+<!--
+Known risks and trade-offs.
+Format: [Risk] <description> → Mitigation: <mitigation>
+[Trade-off] <description of the trade-off> → reason for accepting it
+-->
+
+## Migration Plan
+
+<!--
+Deployment order, rollback strategy, acceptance conditions.
+If this change involves no deployment changes (pure dependency additions,
+no endpoint / DB changes), write "N/A — this change involves no deployment
+changes".
+-->
+
+## Open Questions
+
+<!-- Outstanding decisions or unknowns to resolve -->
diff --git a/superpowers-bridge/templates/proposal.md b/superpowers-bridge/templates/proposal.md
@@ -3,36 +3,40 @@
 <!--
 Explain the motivation for this change. What problem does this solve? Why now?
 
-硬限制：50 ≤ 字元數 ≤ 1000（OpenSpec zod schema 會 validate）
-- 太短：會收到 `Why section must be at least 50 characters` error
-- 太長：會收到 `Why section should not exceed 1000 characters` error
+Hard limit: 50 ≤ character count ≤ 1000 (validated by OpenSpec's zod schema)
+- Too short: you'll get a `Why section must be at least 50 characters` error
+- Too long: you'll get a `Why section should not exceed 1000 characters` error
 
-建議結構：現況痛點 → 為什麼現在處理 → 預期收益（各 1-2 句）
+Suggested structure: current pain point → why address it now → expected
+benefit (1-2 sentences each)
 -->
 
 ## What Changes
 
 <!--
 Describe what will change. Be specific about new capabilities, modifications, or removals.
 
-對於有明確前後對比的行為變更，使用 From/To 格式（markdown 無 inline diff）：
+For behavior changes with a clear before/after contrast, use the From/To
+format (markdown has no inline diff):
 
 **<Section or Behavior Name>**
 - From: <current state / requirement>
 - To: <future state / requirement>
 - Reason: <why this change is needed>
 - Impact: <breaking / non-breaking, who's affected>
 
-多個變更可重複此 block；純新增或純刪除可用簡單列表描述。
+Repeat this block for multiple changes; pure additions or pure removals can
+be described with a simple list.
 -->
 
 ## Capabilities
 
 ### New Capabilities
 <!--
 Capabilities being introduced. Replace <name> with kebab-case identifier.
-命名規則見 openspec/specs/README.md：使用複合名詞（至少 2 個 word），
-例如 `user-auth`、`data-export`、`api-rate-limiting`，不用純單詞。
+Naming rule (see openspec/specs/README.md): use a compound noun (at least
+2 words), e.g. `user-auth`, `data-export`, `api-rate-limiting` — not a single
+bare word.
 Each creates specs/<name>/spec.md
 -->
 - `<name>`: <brief description of what this capability covers>

diff --git a/superpowers-bridge/templates/retrospective.md b/superpowers-bridge/templates/retrospective.md
@@ -8,21 +8,23 @@
 
 ## 0. Evidence
 
-> 量化前置數據 — 後續 Wins / Misses bullets 直接引用,避免每行重複 [evidence: ...]。
-> 冷寫場景(retro 寫於 cycle 結束之後一段時間),只用 `git log` + `tasks.md` +
-> commit messages 也應能重建本節。
+> Quantitative front-matter — the Wins / Misses bullets below reference it
+> directly, avoiding a repeated [evidence: ...] on every line.
+> Cold-write scenario (retro written some time after the cycle ends): this
+> section should be reconstructable from `git log` + `tasks.md` + commit
+> messages alone.
 
 - **Commit range**: `<base-sha>..<head-sha>` (<n> commits)
 - **Diff size**: <+X / -Y lines across N files>
-- **Tasks done**: <x>/<y> (`grep -cE '^\s*- \[x\]' tasks.md` → x;regex 容許 sub-task 縮排)
+- **Tasks done**: <x>/<y> (`grep -cE '^\s*- \[x\]' tasks.md` → x; the regex allows sub-task indentation)
 - **Active hours**: <estimate>
 - **Subagent dispatches**: <count or "n/a">
 - **New external dependencies**: <list, with license + version, or "none">
 - **Bugs encountered post-merge**: <count, one-line each, or "none">
 - **OpenSpec validate state at archive**: <pass / fail / not-run>
 - **Test coverage signal**: <e.g. jacoco %, pytest count, vitest count, or "n/a">
 
-Commit chain (時序):
+Commit chain (chronological):
 
 ```
 <base-sha> <one-line summary>
@@ -60,59 +62,64 @@ Commit chain (時序):
 | (transitive) superpowers:requesting-code-review  |      |
 | superpowers:finishing-a-development-branch       |      |
 
-> **Default expectation**: 全部 ✓。每個 skill 都是 schema 設計的一部分,
-> 跳過屬於異常情境。任一項 ✗ 都必須在下方
-> `### Deliberately Skipped Skills` subsection 提出原因與預防方案。
+> **Default expectation**: all ✓. Every skill is part of the schema's design;
+> skipping one is an exceptional situation. Any ✗ must be justified in the
+> `### Deliberately Skipped Skills` subsection below, with cause and prevention.
 
 ### Deliberately Skipped Skills
 
-> 跳過 skill 是設計的 escape hatch,不是常規路徑。每個 ✗ 必須回答以下三題;
-> 整節空白(全綠)是預期狀態。
+> Skipping a skill is the design's escape hatch, not the normal path. Each ✗
+> must answer the three questions below; a blank section (all green) is the
+> expected state.
 
 - **`<skill name>`**
-  - **What was skipped**: <具體跳過了整個 skill,還是某個 sub-step>
-  - **Why this cycle**: <具體 cycle 條件 — 不可寫「不需要」/「太小」/「沒時間」/「被外部 dep 擋住」/「skill 輸出看起來不對」之類含糊理由;要寫實際 trigger(具體 commit / log line / 觀察到的行為)>
-  - **How to prevent recurrence**: 下一個 cycle 在同類條件下怎麼不再跳?選一:
-    - `schema graph fix` — 寫具體要改 schema.yaml 的哪一段
-    - `skill description tightening` — 寫具體要改哪個 skill 的 frontmatter / instruction
-    - `CLAUDE.md trigger` — 寫具體要在 adopter CLAUDE.md.fragment 加哪段判讀規則
-    - `scope-judgment rule` — 寫具體 cycle 的 scope 應該被怎麼判讀
-    - `one-off — schema boundary case, no prevention possible` — 但需明寫為何 boundary(不接受含糊保留)
-
-> **與 §6 Promote candidates 的關係**:多個 cycle 同 skill 同 `How to prevent`
-> 答案 → 該模式應 promote 到 §6,直接觸發 schema / skill PR,不可累積成「常態」。
+  - **What was skipped**: <the specific skill, or a sub-step within it>
+  - **Why this cycle**: <the concrete cycle condition — vague reasons like "not needed" / "too small" / "no time" / "blocked by an external dep" / "the skill's output looked off" are not acceptable; name the actual trigger (a specific commit / log line / observed behavior)>
+  - **How to prevent recurrence**: how should the next cycle in the same situation avoid skipping? Pick one:
+    - `schema graph fix` — name the specific part of schema.yaml to change
+    - `skill description tightening` — name which skill's frontmatter / instruction to tighten
+    - `CLAUDE.md trigger` — name the interpretation rule to add to the adopter's CLAUDE.md.fragment
+    - `scope-judgment rule` — state how this cycle's scope should have been judged
+    - `one-off — schema boundary case, no prevention possible` — but state explicitly why it's a boundary case (vague reservations not accepted)
+
+> **Relationship to §6 Promote candidates**: if multiple cycles skip the same
+> skill with the same `How to prevent` answer, that pattern should be promoted
+> to §6 and trigger a schema / skill PR directly — it must not accumulate into
+> a "norm".
 
 ## 5. Surprises
 
 - <assumption that turned out wrong>
 
 ## 6. Promote candidates → long-term learning
 
-每條 candidate 用 `- [ ]` checklist:
+Each candidate uses a `- [ ]` checklist:
 
-- 標題:嚴重程度 emoji(🔴/🟡/📌)+ 一句話 learning
-- `→ **Promote to** <destination>`(memory / CLAUDE.md / schema / skill / one-off)
-- 兩行 body(對應 superpowers feedback memory body schema):
+- Title: severity emoji (🔴/🟡/📌) + a one-sentence learning
+- `→ **Promote to** <destination>` (memory / CLAUDE.md / schema / skill / one-off)
+- Two body lines (matching the superpowers feedback memory body schema):
   - `> **Why**: <reason; often a past incident or strong preference>`
   - `> **How to apply**: <when/where this guidance kicks in>`
 
-未勾選的 `- [ ]` 表示 candidate 尚未 promote — 可帶到下一個 cycle 的 retro 重評估,
-或保留作為跨 cycle 的觀察點。
+An unchecked `- [ ]` means the candidate hasn't been promoted yet — it can be
+carried to the next cycle's retro for re-evaluation, or kept as a cross-cycle
+observation point.
 
-> **Carry-forward 機制**:下個 cycle 寫 retro 時,可
-> `grep -A 5 '^- \[ \]' openspec/changes/archive/*/retrospective.md` 取出
-> 既往 unchecked candidates,逐筆判斷要 carry-forward 到本 cycle §6、就地
-> promote、或標 stale 不再追蹤。
+> **Carry-forward mechanism**: when writing the next cycle's retro, run
+> `grep -A 5 '^- \[ \]' openspec/changes/archive/*/retrospective.md` to pull
+> prior unchecked candidates, and decide per item whether to carry it forward
+> into this cycle's §6, promote it on the spot, or mark it stale and stop
+> tracking it.
 
-範例:
+Example:
 
 - [ ] 🔴 **<short rule>** → **Promote to memory** (type: feedback)
   > **Why**: <past incident or strong preference that motivated this rule>
   > **How to apply**: <which file / cycle phase / decision moment this kicks in>
 
-- [ ] 🟡 **<another candidate>** → **Promote to project CLAUDE.md** (`<path/to/CLAUDE.md>` 段)
+- [ ] 🟡 **<another candidate>** → **Promote to project CLAUDE.md** (`<path/to/CLAUDE.md>` section)
   > **Why**: ...
   > **How to apply**: ...
 
-- [ ] 📌 **<third candidate>** → **One-off** (記錄即可,不 promote)
+- [ ] 📌 **<third candidate>** → **One-off** (record only, do not promote)
   > **Why**: <why it doesn't generalize>