@laitszkin/apollo-toolkit 3.11.8 → 3.12.0

package/discover-security-issues/SKILL.md

@@ -1,88 +1,54 @@
 ---
 name: discover-security-issues
 description: >-
-  Discovery-only adversarial audit: map trust boundaries, run module catalogs (`agent-system`, `financial-program`, `software-system`, `combined`), reproduce exploitable behavior with payloads/commands and `path:line` evidence; prioritize impact × exploitability—**no code edits, no PRs, no auto-remediation**.
-  Use for security review, vuln hunting, SQLi/XSS/auth/IDOR checks, agent prompt-injection/tool abuse, money-path races **STOP** when user wants patches shipped—hand off findings… BAD single vague “looks fine”… GOOD two-pass repro, hypothesis vs confirmed…
+  面向選定範圍的只讀安全審查技能。先界定信任邊界，再依 `agent-system`、`financial-program`、`software-system` 或 `combined` 攻擊目錄執行可重現的對抗性驗證，要求以 payload、請求形狀、命令或運行結果配合 `path:line` 證據支撐結論；不允許修改代碼、提交 PR 或直接修復漏洞。
 ---
 
-# Discover Security Issues
-
-## Dependencies
-
-- Required: none.
-- Conditional: none.
-- Optional: none.
-- Fallback: not applicable.
-
-## Non-negotiables
-
-- **Discovery-only**: **MUST NOT** edit code, apply patches, open PRs, or run “fix workflows.”
-- **MUST** keep only **reproducible** issues with exploit evidence; separate **hypotheses** from **confirmed** findings.
-- **MUST** reproduce each confirmed exploit **at least twice** on the same path; use nearby payload variants for high-risk sinks.
-- **MUST** discard authorship bias—treat all code as untrusted until evidence proves behavior.
-
-## Standards (summary)
-
-- **Evidence**: Payload/precondition, observable failure, `path:line`, commands or requests that reproduce.
-- **Execution**: Pick modules → boundaries → scenarios from references → validate → prioritize → report only.
-- **Quality**: Rank by impact, exploitability, reach; unknowns listed under residual risk.
-- **Output**: Findings (severity-ordered), attack evidence, risk notes, hardening **advice** (not patches), residual risk.
-
-## Workflow
-
-**Chain-of-thought:** After each step, satisfy **`Pause →`** before continuing; halt on missing scope or contradictory module choice.
-
-### 1) Scope and modules
-
-- Choose one or more of: `agent-system`, `financial-program`, `software-system`, `combined` (cross-boundary chains).
-- List untrusted inputs, privileged actions, and protected assets; state invariants that must hold.
-   - **Pause →** Which module catalogs did I **open** (file names)—not guessed from memory?
-
-### 2) Execute scenarios from references
-
-- **Agent**: `references/agent-attack-catalog.md`; optional `references/security-test-patterns-agent.md` (prompt injection, tool abuse, memory/exfil paths).
-- **Financial**: `references/red-team-extreme-scenarios.md`, `references/risk-checklist.md`; optional `references/security-test-patterns-finance.md` (authz, replay/race, idempotency, precision, lifecycle).
-- **Software**: `references/common-software-attack-catalog.md` (SQL/NoSQL/command injection, XSS, CSRF, SSRF, traversal, upload, session/JWT, IDOR/BOLA, deserialization, misconfig).
-- **Combined**: relevant subsets **plus** chains (e.g. injection → privileged API).
-   - **Pause →** Did I record **payload + preconditions + observed behavior** for each candidate—not just “maybe vulnerable”?
-
-### 3) Validate reproducibility
-
-- Re-run each confirmed path twice; add encoding/casing/delimiter variants on hot sinks.
-   - **Pause →** Is anything still “likely” without a second repro—downgrade to hypothesis?
-
-### 4) Prioritize
-
-- Order Critical/High → Medium → Low using impact, exploitability, blast radius (multi-tenant / cross-tenant called out).
-
-### 5) Report only
-
-Deliver (see **Output shape** below): findings, attack evidence, prioritization, hardening guidance (advisory), residual risk.
-
-## Minimum coverage (apply per selected module)
-
-- **Core**: trust boundaries, authn/authz, input → dangerous sink paths, secrets/sensitive data handling.
-- **Agent**: prompt/indirect injection, unauthorized tools/actions, exfil, memory poisoning resistance.
-- **Financial**: object-level authz, replay/race/idempotency, precision, oracle/side-effect safety, failure consistency.
-- **Software**: injection families, XSS/CSRF/SSRF, traversal/upload, session/JWT, brute-force/rate limits, debug/CORS/secrets exposure.
-- **Combined**: module checks + realistic cross-boundary chains.
-
-## Output shape
-
-1. **Findings** (high → low): title, severity, evidence (`path:line`), reproduction steps/payload, impacted invariant/asset.
-2. **Attack evidence**: preconditions, commands/requests, observed insecure behavior, variant results.
-3. **Risk prioritization**: impact, exploitability, reach; why it matters in **this** system.
-4. **Hardening guidance** (advice only): fix direction, validation focus post-remediation.
-5. **Residual risk**: hypotheses, assumptions, follow-up probes.
-
-## Sample hints
-
-- **Module**: Web API + Claude tool-use → `combined` (software + agent); deposits/withdrawals → include `financial-program`.
-- **Evidence**: “SQLi possible” without two runs + exact parameter → stays **hypothesis** until repro’d.
-- **Stop line**: User says “patch it now” → finish report; hand off to implementation skills—**do not** self-patch here.
-
-## References
-
-- `references/agent-attack-catalog.md`, `references/security-test-patterns-agent.md`
-- `references/red-team-extreme-scenarios.md`, `references/risk-checklist.md`, `references/security-test-patterns-finance.md`
-- `references/common-software-attack-catalog.md`, `references/test-snippets.md` (optional snippets)
+## 目標
+輸出一份只讀的安全審查報告，僅保留可重現、可利用、可定位的安全問題。報告需要包含攻擊前提、攻擊步驟、觀察到的不安全行為、`path:line` 證據、嚴重度排序、建議性加固方向與剩餘風險；本技能不負責修補漏洞。
+
+## 驗收條件
+- 審查開始前已明確定義範圍：所選模組目錄、信任邊界、不可信輸入、受保護資產、特權操作與必須成立的安全不變式。
+- 每個已確認問題都包含 payload 或請求形狀、前置條件、實際觀察到的不安全行為，以及精確的 `path:line` 證據。
+- 每個已確認漏洞都在同一路徑下成功重現至少兩次；對高風險熱點還要補做相鄰變體驗證。無法穩定重現者只能作為假設或剩餘風險。
+- 問題排序基於影響、可利用性與波及範圍，並對資金流、權限提升、跨租戶資料暴露與破壞性操作給予更高權重。
+- 最終交付物是按嚴重度排序的安全報告，只包含已確認發現、攻擊證據、風險解釋、建議性加固方向與剩餘風險。
+- 全流程保持只讀：不得修改代碼、補丁、測試、PR 或直接執行修復工作流。
+
+## 工作流程
+1. 先定義安全審查範圍。
+   - 根據目標選擇 `agent-system`、`financial-program`、`software-system` 或 `combined`。
+   - 列出所有不可信輸入、受保護資產、特權操作與關鍵安全不變式。
+   - 在挑選攻擊場景前，先打開對應參考資料，不依賴記憶臆測。
+2. 選擇合適的攻擊目錄。
+   - `agent-system`：聚焦提示注入、間接注入、工具濫用、記憶污染、資料外洩與 agent handoff 攻擊。
+   - `financial-program`：聚焦授權繞過、重放、競態、精度、生命週期、外部依賴與資金流濫用。
+   - `software-system`：聚焦注入、XSS、CSRF、SSRF、路徑穿越、檔案上傳、Session/Token、存取控制與配置錯誤。
+   - `combined`：合併多個目錄，驗證跨邊界的真實攻擊鏈。
+3. 執行可確定的攻擊驗證。
+   - 對每條候選路徑記錄 payload、前置條件、入口點、可觀察結果與能解釋結果的代碼路徑。
+   - 只保留有證據支撐的候選；「看起來像漏洞」不能直接進報告。
+4. 確認或降級。
+   - 對每個候選問題做同路徑二次重現。
+   - 對 parser 邊界、授權檢查、查詢構造、命令執行、資金流與 prompt/tool 路由等熱點補做相鄰變體。
+   - 若第二次重現失敗或證據鏈不足，將其降級為假設或剩餘風險。
+5. 按嚴重度排序並只輸出報告。
+   - 依影響、可利用性與波及範圍從高到低排序。
+   - 交付內容只包含已確認問題、攻擊證據、排序理由、建議性加固方向與剩餘風險。
+   - 若使用者要求修復，先完成本技能報告，再交由實作型技能處理。
+
+## 使用範例
+- 「審查這個 Web API 是否有 SQLi、IDOR、SSRF 和 token 問題」-> 選擇 `software-system`，圍繞輸入邊界、查詢構造與授權控制執行可重現驗證。
+- 「審查這個帶 retrieval、memory 和 tool call 的 agent」-> 選擇 `agent-system`，聚焦提示注入、間接注入、工具濫用、資料外洩與記憶污染。
+- 「審查結算、清算或餘額流程是否能被 replay、race 或 precision abuse 利用」-> 選擇 `financial-program`，優先驗證資金守恆、生命週期原子性與精度邊界。
+- 「幫我看 prompt injection 能不能一路打到特權 API」-> 選擇 `combined`，設計跨 agent 與後端邊界的真實攻擊鏈。
+- 「這裡可能有 SQLi，但我只有模糊直覺」-> 若沒有二次重現與精確參數路徑，只能在報告中標記為假設，不能算作已確認漏洞。
+
+## 參考資料索引
+- `references/agent-attack-catalog.md`：AI agent 安全攻擊目錄，涵蓋直接/間接注入、工具濫用、記憶污染、資料外洩與 handoff 攻擊。
+- `references/security-test-patterns-agent.md`：AI agent 安全測試模式，用於描述驗證思路與後續補強方向。
+- `references/red-team-extreme-scenarios.md`：金融與高風險系統的極端攻擊場景，聚焦重放、競態、生命週期、預言機與安全開關濫用。
+- `references/risk-checklist.md`：金融系統風險檢查清單與嚴重度規則，涵蓋授權、資金完整性、依賴風險與運維控制。
+- `references/security-test-patterns-finance.md`：金融系統安全測試模式，涵蓋 replay、授權、精度、陳舊資料與狀態機失敗。
+- `references/common-software-attack-catalog.md`：通用軟體與 Web/API 攻擊目錄，涵蓋主流注入、瀏覽器端與存取控制問題。
+- `references/test-snippets.md`：可重現 payload 與測試模板範例，用於補充報告中的攻擊形狀與驗證描述。

package/enhance-existing-features/SKILL.md

@@ -1,77 +1,56 @@
 ---
 name: enhance-existing-features
 description: >-
-  Extend brownfield systems only after reading the real modules involved: choose **`generate-spec`**/`recover-missing-plan` when user-visible scope, ambiguity, coordination, or sensitive flows demand written approval; otherwise implement directly but still run **`test-case-strategy`** on every non-trivial delta (property/adversarial/integration as risk dictates) and never check off plans without commit+test evidence.
-  Use for backlog work that mutates production behavior; reroute pure regressions, copy/style-only tweaks, or single-pocket config nits that restore documented intent without new surface area.
-  Bad: multi-service permission change with zero spec… Good: contract captures external API limits + property tests cover invariants… Single-file pagination fix matching README → targeted regression only…
+  用於在既有系統上增強或調整產品行為。必須先讀懂實際受影響的模組，再決定是直接實作，
+  還是先走 `generate-spec` / `recover-missing-plan`；所有非平凡變更都要經過 `test-case-strategy`。
 ---
 
-# Enhance Existing Features
+# 增強既有功能
 
 ## Dependencies
 
-- Required: `test-case-strategy` for risk selection, oracles, drift checks.
-- Conditional: **`generate-spec`** when spec triggers below fire; **`recover-missing-plan`** when user-named `docs/plans/...` is missing/archived/mismatched; **`commit-and-push`** when the user requests **git commit** and/or **push** to persist completed work—**MUST** delegate final submission to **`commit-and-push`** (often via **`implement-specs`** / **`implement-specs-with-worktree`** when a spec path is active).
-- Optional: none.
-- Fallback: **`test-case-strategy`** unavailable ⇒ **stop**. Spec path required but **`generate-spec`** unavailable ⇒ **stop**. If the user requested **commit/push** and **`commit-and-push`** is unavailable, **MUST** stop and report.
+- Required: `test-case-strategy`
+- Conditional: `generate-spec`、`recover-missing-plan`、`commit-and-push`
+- Optional: 無
+- Fallback: `test-case-strategy` 不可用時必須停止；需要spec但 `generate-spec` 或 `recover-missing-plan` 不可用時也必須停止；若使用者要求提交或推送但 `commit-and-push` 不可用，必須說明後停止
 
-## Non-negotiables
+## Standards
 
-- **MUST** explore relevant code (entrypoints, flows, integrations) **before** deciding process or editing—**MUST NOT** spec-dump or code-dump from titles alone.
-- Spec path **when** any: new/changed **user-visible** behavior (not mere restore of old intent); ambiguity needing approval; multi-module alignment; critical/sensitive/irreversible/migration risk; traceability materially reduces error.
-- **MUST NOT** open **`generate-spec`** for clearly tiny/localized work: pure regression to prior intent; polish-only UI copy/style; one-area config/constant/flag; narrow CRUD/validation tweak; internal refactor/observability **without** behavior change—**implement + `test-case-strategy` directly**.
-- If specs: **MUST** complete **`generate-spec`** lifecycle (approval before code; backfill after); **≤3 modules** per spec set—split independent non-dependent sets + batch `coordination.md` when coordinated parallelism; **MUST NOT** code pre-approval.
-- **MUST NOT** yield with approved in-scope **`tasks.md`/`checklist.md`** undone except user deferral or documented external blocker (record in plans).
-- **`test-case-strategy` required** for non-trivial deltas—property/adversarial/integration etc. per risk; meaningful oracles; drift check or explicit **`N/A`** with reason per non-trivial logic task.
-- External deps: **`contract.md`** records official-backed obligations when material.
+- Evidence: 先閱讀實際程式碼、整合點與外部文件，再決定流程與修改方案
+- Execution: 探索範圍 -> 判斷是否需要 spec -> 查官方資料 -> 最小實作 -> 測試 -> 回填或總結
+- Quality: 不因怕麻煩而跳過 spec，也不為小改動硬開 spec；只做與需求直接相關的修改
+- Output: 交付符合需求的行為變更、可追溯的測試結果，以及在需要時保持誠實的計劃文件狀態
 
-## Standards (summary)
+## 技能目標
 
-- **Evidence**: Code exploration + official docs/APIs where touched.
-- **Execution**: Explore → decide specs → docs/officials → implement → test → backfill/summary.
-- **Quality**: No speculative scope expansion; reuse patterns.
-- **Output**: Behavior matches ask; traceable tests; plans honest if specs used.
+在不打亂既有系統邊界的前提下，為 brownfield 專案安全地增強功能或調整行為，並用合適的spec流程與測試策略把風險控制在可驗證範圍內。
 
-## Workflow
+## 驗收條件
 
-**Chain-of-thought:** **`Pause →`** after explorations and spec decision—wrong classification wastes days.
+- 在動手前已讀懂受影響模組、入口點、整合邊界與變更爆炸半徑
+- 已正確判斷這次工作是直接實作還是必須先走 `generate-spec` / `recover-missing-plan`
+- 每個非平凡變更都經過 `test-case-strategy`，並留下清楚的 oracle、驗證方式與 `N/A` 理由
+- 若使用了 spec，則批准、實作、回填與真實狀態同步全部完成；若未使用 spec，則最終摘要足以說明風險、測試與限制
 
-### 1) Explore codebase
+## 工作流程
 
-- Map modules, integrations, blast radius.
-  - **Pause →** Can I state **one paragraph** concrete change surface before editing?
+1. 先完整閱讀相關模組、資料流、整合點與現有測試，明確界定這次變更會影響哪些地方
+2. 判斷是否需要spec流程；若涉及新的或改變後的使用者可見行為、跨模組協調、高風險敏感流程、重大歧義，則走 `generate-spec`；如果使用者指定的 plan 路徑缺失或不一致，先用 `recover-missing-plan`
+3. 若不需要 spec，明確說出不開 spec 的理由；若需要 spec，必須等批准後才能改產品程式碼
+4. 查閱變更所依賴的官方文件、API spec或工具文件，尤其是外部整合與契約邏輯
+5. 以最小差異實作需求，不順手做額外重構或範圍擴張
+6. 使用 `test-case-strategy` 選擇單元、回歸、property、integration、E2E 或 adversarial 測試，跑測試並修正失敗
+7. 若使用了 spec，回填 `spec.md`、`tasks.md`、`checklist.md`、`contract.md`、`design.md` 與任何 `coordination.md`；若未使用 spec，輸出簡潔的結果摘要、測試證據與剩餘限制
 
-### 2) Decide specs
+## 使用範例
 
-- Apply Non-negotiable triggers above; if doubt favors **implement-only** **only when** genuinely low-risk localized.
-- If specs: broken path ⇒ **`recover-missing-plan`** then **`generate-spec`** (templates, clarification loop, approval). Parallel batch rules per **`generate-spec`**. If **not** specs: complete step 2 with “no specs” rationale, then continue with steps 3–6 (still run official-doc pass when external surfaces change).
-  - **Pause →** Am I dodging specs just to avoid bureaucracy while scope is multi-team/critical?
+- 「新增一套影響 API、資料庫與 UI 的權限模型」-> 先走 `generate-spec`，批准後再實作，並補上跨層測試
+- 「修正分頁 off-by-one，讓行為回到 README 描述」-> 不開 spec，直接修復並加回歸測試
+- 「目前指定的 `docs/plans/...` 不見了，但使用者要沿著它繼續做」-> 先用 `recover-missing-plan` 還原或重建，再繼續
 
-### 3) Authoritative docs
+## 參考資料索引
 
-- Official docs / Context7 / web for libs used in change.
-
-### 4) Implement
-
-- Minimal diffs preserving behavior unless tasked otherwise; specs ⇒ every in-scope unchecked item delivered; intermediate milestones ≠ user’s final asked outcome unless rescoped.
-
-### 5) Testing (always for non-trivial)
-
-- **`test-case-strategy`**: inventory risk → tests with oracles → run/fix.
-
-### 6) Completion
-
-- With specs: backfill **`spec.md`/`tasks.md`/`checklist.md`/`contract.md`/`design.md`** (+ **`coordination.md`** if batch truth moved). **`spec.md`** requirement status honest. Strip template noise / `N/A` properly.
-- Without specs: concise summary citing tests/results/`N/A` reasons.
-
-## Sample hints
-
-- **Spec yes**: Adds new permission model affecting API+DB+UI—the blast radius crosses layers.
-- **Spec no**: Off-by-one in existing pagination restoring documented behavior—fix + regression test.
-- **Split**: Touches auth, billing, infra—**three plans** capped modules, **`coordination.md`** collision map.
-
-## References
-
-- **`generate-spec`**: planning/backfill lifecycle
-- **`test-case-strategy`**: tests + drift philosophy
-- **`recover-missing-plan`**: heal missing dirs
+- `generate-spec`：需要書面批准時的spec流程
+- `recover-missing-plan`：修復缺失或不一致的計劃檔
+- `test-case-strategy`：非平凡變更的測試選型與 oracle 設計
+- `commit-and-push`：使用者要求提交或推送時的最終交付流程

package/generate-spec/SKILL.md

@@ -6,19 +6,17 @@ description: >-
   preparation files. Use for drafting or restructuring specs, not implementation.
 ---
 
-# 生成規格
-
 ## 目標
-將用戶需求轉化為明確、有清晰完成條件的規格文檔。
+將用戶需求轉化為明確、有清晰完成條件的spec。
 
 ## 驗收條件
-- 已經產出了嚴格遵循模板格式的規格文檔。
-- 為規格文檔當中的需求制定了明確的驗收條件及測試策略
+- 已經產出了嚴格遵循模板格式的spec。
+- 為spec當中的需求制定了明確的驗收條件及測試策略
 
 ## 工作流程
-1. 理解用戶需求並閱讀代碼庫
-分析用戶需求，並在代碼庫之中搜索、列出可能相關的內容。完成搜索之後，深入閱讀相關代碼，識別變更範圍。
-如果外部環境存在subagents功能，建議通過調度subagents來完成深入閱讀代碼庫的任務。
+1. 理解用戶需求並閱讀repo
+分析用戶需求，並在repo之中搜索、列出可能相關的內容。完成搜索之後，深入閱讀相關代碼，識別變更範圍。
+如果外部環境存在subagents功能，建議通過調度subagents來完成深入閱讀repo的任務。
 
 2. 拆分用戶需求及設計業務架構
 將用戶需求轉化、拆分為明確、存在邊界的工程需求。結合現有代碼，設計業務架構。在設計的過程中，你需要考慮包括但不限於以下設計事項：
@@ -26,7 +24,7 @@ description: >-
 - 測試策略
 - 模塊之間的呼叫、回傳
 - 資料流
-在這個階段，如果用戶有任何不清晰的需求，且該需求會影響你的設計方案，你需要紀錄並在稍後填入規格文檔，等待用戶的回答。
+在這個階段，如果用戶有任何不清晰的需求，且該需求會影響你的設計方案，你需要紀錄並在稍後填入spec，等待用戶的回答。
 
 3. 將整個設計方案拆分成可執行任務
 將上一步之中你構思的完整設計方案拆分為精確到函式或檔案級別的任務。你必須確保每一個任務都是可以直接執行，且沒有歧義的。以此確保執行設計方案的開發者不會偏離設計方案。
@@ -35,13 +33,13 @@ description: >-
 為任務制定基於測試的驗收條件，確保每一個任務在完成之後都能夠被驗證。
 同時，為需求制定驗收條件，確保用戶需求能夠被測試清晰地驗收、檢驗成果。
 
-5. 使用 `apltk` cli工具協助完成規格文檔
-使用cli工具，產生規格文檔的模板。將你的完整計劃填入到模板之中，並通過cli工具生成完整架構圖讓用戶審閱。
-如果該規格文檔設計超過三個模塊，則需要創建規格批次。
+5. 使用 `apltk` cli工具協助完成spec
+使用cli工具，產生spec的模板。將你的完整計劃填入到模板之中，並通過cli工具生成完整架構圖讓用戶審閱。
+如果該spec設計超過三個模塊，則需要創建batch spec。
 
 ## 範例
-- "製作一個網頁德州撲克小遊戲" -> "拆分成多個模塊：遊戲本體邏輯、前端頁面渲染、前端頁面交互邏輯；制定單元測試、整合測試等策略，並製作一份單一的規格文檔指導實作工作。"
-- "提升現有系統的性能" -> "識別目前代碼庫之中拖累性能的代碼。製作規格批次文檔，將代碼庫的全量優化拆分為以三個模塊為一組的優化。對於必須改動業務邏輯才可以做到的性能提升，填寫clarification questions，並等待用戶回答之後更新規格文檔。"
+- "製作一個網頁德州撲克小遊戲" -> "拆分成多個模塊：遊戲本體邏輯、前端頁面渲染、前端頁面交互邏輯；制定單元測試、整合測試等策略，並製作一份單一的spec指導實作工作。"
+- "提升現有系統的性能" -> "識別目前repo之中拖累性能的代碼。製作batch spec文檔，將repo的全量優化拆分為以三個模塊為一組的優化。對於必須改動業務邏輯才可以做到的性能提升，填寫clarification questions，並等待用戶回答之後更新spec。"
 
 ## 參考資料
 - `scripts/create-specs` - `apltk create-specs` 背後使用的模板產生器。
@@ -54,3 +52,5 @@ description: >-
 - `references/templates/preparation.md` - batch root 的前置工作模板。
 - `references/TEMPLATE_SPEC.md` - `apltk` cli工具相關格式指引。
 - `test-case-strategy/SKILL.md` - 測試策略選擇技能。
+- `apltk create-specs --help` - spec生成相關cli工具的指引命令
+- `apltk architecture --help` - 架構圖生成相關cli工具的指引命令

package/generate-spec/references/templates/coordination.md

@@ -9,7 +9,6 @@
 
 - Batch members: [[spec-name-1], [spec-name-2]]
 - Shared outcome: [what the batch delivers when all spec sets land]
-- Parallel readiness: [Yes / No; if No, list blocking items or link to preparation.md]
 - Out of scope: [shared exclusions for the batch]
 
 ## Design Principles

package/implement-specs/SKILL.md

@@ -1,83 +1,48 @@
 ---
 name: implement-specs
-description: >-
-  Land approved `docs/plans/{YYYY-MM-DD}/{change}` (or batch member path) on the current branch: resolve path by user pointer or evidence-backed latest (no guesses); read spec→design→contract→checklist then run every `tasks.md` line and all `checklist.md` wrap-up; multi-directory work follows `coordination.md`—one directory fully done before the next; backfill plans; **`commit-and-push`** for final commit (no branch/worktree unless user rescopes). Isolation: **`implement-specs-with-worktree`**; delegation: **`implement-specs-with-subagents`**.
+description: 當你需要在當前分支之中實作spec時，使用這個技能。
 ---
 
-# Implement Specs
+## 技能目標
 
-## Dependencies
+實作用戶指定的spec。確保所有任務都被完成，用戶所有需求都被滿足。
 
-- Required: **`commit-and-push`** for the **final** implementation commit (and push when the user explicitly requests remote update).
-- Conditional: `generate-spec` if spec files need clarification or updates; `recover-missing-plan` if the requested plan path is missing from the current checkout.
-- Optional: none.
-- Fallback: If **`commit-and-push`** is unavailable, **MUST** stop immediately and report the missing dependency. Do not improvise substitute standards or ungated `git commit`.
+## 驗收條件
 
-## Non-negotiables
+- 在所有被用戶要求實作的spec之中，所有的 `checklist.md`, `tasks.md`, `spec.md` 當中所有非用戶填寫的任務相關checkboxes全部被勾選為完成狀態
 
-- **MUST** read and understand the full in-scope planning set and the parent `coordination.md` when its path applies, **before** editing product code or tests for this spec. Read for meaning in this order: **`spec.md`** (requirements / intent), **`design.md`** (high-level architecture + coarse `INT-###` anchors—**guidance for structuring work**), **`contract.md`** (cite-backed external facts/constraints + `EXT-###` anchors), **`checklist.md`**, then treat **`tasks.md`** as **the authoritative ordered runnable checklist**. **MUST NOT** start coding until that read pass is complete for the current in-scope directory.
-- **MUST** execute **every** **`tasks.md`** line in listed order—the **executable source of truth** for what to ship. **`design.md` / `contract.md`** **inform** decomposition and forbid contradictions (**`INT-###` / `EXT-###`** when present are **constraints/anchors referenced from tasks**, not a second queue). **MUST NOT** silently wire alternate module flows or vendor surfaces that conflict with approved **`design`** / **`contract`**; resolve conflicts via **`generate-spec`** / explicit approved plan edits first.
-- **MUST** when multiple spec directories apply to one request, follow parent **`coordination.md`** merge / sequencing guidance (or the user’s explicit order if coordination is absent or defers to them) and **complete** one directory end-to-end—**all** of its `tasks.md` lines **and** **all** of its `checklist.md` wrap-up / acceptance work—**before** starting implementation work in the next directory. **MUST NOT** interleave partial implementation across sibling specs.
-- **MUST NOT** create a branch, switch branches, or add or use a `git worktree` for this work unless the user explicitly changes the request in the same conversation.
-- **`tasks.md` completeness (hard stop)**: **MUST** execute **every** actionable item listed in the in-scope `tasks.md` for this request—**no exceptions** for perceived size, duration, file count, refactor depth, or session length. **MUST NOT** stop early, “defer” unchecked tasks while claiming the spec is done, collapse multiple task lines into a partial summary, or substitute narrative progress for completing a remaining line. If a line is truly impossible under written contracts, **MUST** stop with evidence and **MUST NOT** treat the implementation pass as complete until the plan is amended through the governing planning workflow (`generate-spec` / user-approved update) and the revised `tasks.md` is then fully satisfied.
-- **`checklist.md` wrap-up / acceptance (hard stop for “spec complete”)**: **MUST** complete **all** `checklist.md` obligations that constitute **wrap-up, acceptance, verification, release-prep, doc or index sync, or other closing/hand-off** work tied to this change—**same no-exemption bar as `tasks.md`** (workload, duration, or breadth **do not** waive checklist-only items). The **entire** in-scope spec is **not** **complete** until those checklist items are **actually satisfied** and truthfully marked. **MUST NOT** treat “implementation done” or proceed to final **`commit-and-push`** / completion reporting while checklist-defined closing work remains open or is waved away with narrative. If a checklist item is impossible under contracts or facts on the ground, **MUST** stop with evidence and **MUST NOT** declare the spec complete until the plan is amended through the governing workflow and the revised `checklist.md` is then fully satisfied.
-- **MUST** treat the approved `tasks.md`, `checklist.md`, and contracts as the scope boundary: on top of the rules above, run the relevant checklist-backed verifications and tests, and **MUST** backfill the planning documents with factual completion status (no aspirational checkboxes).
-- **MUST NOT** expand scope to unrelated sibling spec directories solely because they share a batch folder.
-- **MUST** finalize the implementation through **`commit-and-push`** after staging the intended change set (shared readiness, reviews per that skill’s classification, conventional commit message); **MUST NOT** complete the deliverable with a bare `git commit`, IDE-only commit, or other shortcut that skips **`submission-readiness-check`** / mandated gates.
-- **MUST NOT** `git push`, tag, or perform release steps **outside** **`commit-and-push`** (unless **`version-release`** / **`open-source-pr-workflow`** explicitly applies per user request).
-- If the plan path is missing or ambiguous: **MUST** use `recover-missing-plan` or other verifiable repository evidence to locate the authoritative plan; **MUST NOT** substitute a nearby path by guess. After recovery, **MUST** re-read the recovered files before coding so implementation and backfill target the same snapshot.
+## 工作流程
 
-## Standards (summary)
+### 1. 定位實作範圍
 
-- **Evidence**: Same as Non-negotiables: no coding until the spec set is fully read; no guessed plan paths.
-- **Execution**: Current checkout only; **`tasks.md`** defines runnable order and file targets; **`spec`/`design`/`contract`** constrain meaning and forbid contradictory wiring—implement and test until obligations are met—no parallel branch or worktree (unless the user rescopes to another skill).
-- **Quality**: **All** `tasks.md` lines **and** **all** `checklist.md` wrap-up / acceptance obligations for this scope satisfied (see Non-negotiables—workload is not an excuse); tests and checklist verifications executed as required; docs reflect reality; no scope creep into sibling specs.
-- **Output**: Current branch contains a clean, reviewable implementation of this spec only.
+閱讀用戶指定的spec：
 
-## Workflow
+- `spec.md` 定義了用戶的需求
+- `tasks.md` 定義了詳細的實作任務
+- `checklist.md` 定義了任務的完成和驗收條件
+- `contract.md` 定義了spec的外部依賴
+- `design.md` 定義了相關業務鏈路的架構設計
+- `coordination.md`（如有）定義了batch spec之中各份spec各自的實作邊界
+- `preparation.md`（如有）定義了實作batch spec之前各spec的共用準備工作
 
-**Chain-of-thought:** Before advancing each numbered step, answer the **`Pause →`** questions (even if only internally). A “no” or “unknown” answer **MUST** be resolved or surfaced as a blocker before continuing.
+按照以上文件，閱讀repo，理解本次spec的實作範圍。
 
-1. **Locate and read** — Resolve `docs/plans/{YYYY-MM-DD}/{change_name}/` or `docs/plans/{YYYY-MM-DD}/{batch_name}/{change_name}/` using the path the **user** gave **or**, when none is given, the **most recent** plan location proven by repository evidence (issue links, manifests, `docs/plans` listing—**MUST NOT** pick a sibling folder by guess). Read parent `coordination.md` when present (merge order, parallelism rules, collisions). For **each** in-scope directory, before any code edits, read the five core files for substance in this order: `spec.md` → `design.md` → `contract.md` → `checklist.md` → `tasks.md` (execution list). If multiple directories are in scope, establish their **sequence** from `coordination.md` (or the user) and plan to implement **one directory at a time** to full completion (Non-negotiables).
-   - **Pause →** Is this directory the **exact** scope—or ordered list—the user (or coordination) requires, verified by listing or viewing those five files—not a sibling “similar” folder?
-   - **Pause →** Have I explicitly linked each material requirement / task to evidence I understood from **spec** / **design** / **contract** (still no code edits)?
-   - **Pause →** If the path were missing or wrong, what **verifiable** step would locate the authoritative plan—and have I executed it?
+### 2. 實作spec任務
 
-2. **Branch sanity** — Run `git status -sb`. Do not modify unrelated dirty files; surface blockers. Confirm the current branch is where this work should land.
-   - **Pause →** Would creating or switching branches or a worktree right now **violate** the Non-negotiables—and am I resisting that temptation?
-   - **Pause →** What dirty paths are **out of scope**, and how will I avoid touching them inadvertently?
-   - **Pause →** Is the integration target branch (where the user expects work) identical to what `git status -sb` shows?
+嚴格按照 `tasks.md` 之中定義的任務，逐項完成實作。如果有多份 `tasks.md` 存在於多份spec之中，則依照 `coordination.md` 之中建議的merge順序進行實作。
+在確認完成所有任務之後，將 `tasks.md` 之中的所有checkboxes勾選為完成。
 
-3. **Implement** — Execute **the entire** approved `tasks.md` (every line) for the **current** in-scope directory only, honoring requirements and design you read in step 1; do not close this step until **no** applicable unchecked tasks remain **for that directory**. Run relevant tests and **any** verification commands or artifact steps that `checklist.md` already assigns to the implementation phase (do not postpone checklist-only closing items that belong here). When the request spans multiple directories, **repeat** steps 3–4 **per directory** in the coordination order **after** the previous directory’s tasks **and** checklist obligations are satisfied.
-   - **Pause →** Have I listed **every** remaining `tasks.md` line—and is the count **zero** before I leave this step?
-   - **Pause →** For the next task item, what is the **single** concrete change and its **single** primary verification—before I type code?
-   - **Pause →** Am I about to touch a file that belongs to a **sibling** spec or an unrelated module without an in-scope task line?
-   - **Pause →** After this chunk of work, which test command **proves** I did not break the contract’s stated behavior?
+如果實作的spec是batch spec，且有 `preparation.md`，在開始實作之前需要先完成 `preparation.md` 之中所規定的任務內容，並在驗收條件滿足之後回填 `preparation.md`。
 
-4. **Backfill** — Update `checklist.md` / `tasks.md` (and any other plan files your standards require) so completion status matches what you actually did. **MUST NOT** advance to **Submit** until **every** checklist item that defines wrap-up or acceptance for this spec is **done** or the batch is an honest documented halt per Non-negotiables.
-   - **Pause →** If I checked a box, can I point to **commit + test run** (or equivalent) that makes that check true—no wishful checking?
-   - **Pause →** Are **zero** checklist obligations that mean “before spec complete” still open—validated by re-reading `checklist.md`, not from memory?
-   - **Pause →** Did any scope shrink or shift during implementation; if so, is the plan text updated **honestly**?
+### 3. 驗證實作
 
-5. **Submit** — Stage the intended implementation/backfill diff. Run **`commit-and-push`** through commit using that staged intent (and **push** only when the user explicitly requested remote update). Keep scope to this spec only; split into multiple submission passes only when an unavoidable checkpoint requires separate commits. **Only** reach this step when **both** `tasks.md` and `checklist.md` Non-negotiable closures are satisfied.
-   - **Pause →** Does `git diff --cached` (or the equivalent staged view) show only this spec’s intended surface, or do I need to unstage/revert noise first?
-   - **Pause →** Am I on the **same** branch I named in step 2, without a silent branch switch?
+按照 `checklist.md` 之中定義的驗收標準，逐項驗收並檢查任務是否完成。對於未達到驗收標準的任務，必須重新實作及重新驗收，並在完成驗收之後將所有 `checklist.md` 之中的checkboxes勾選為完成。
 
-6. **Report** — State current branch, commit hash, tests run, which plan files were backfilled, and explicit confirmation that **`tasks.md` and checklist-defined wrap-up work are complete** for this in-scope spec (or cite the documented blocker).
-   - **Pause →** Would another engineer **reproduce** my conclusion from the branch name, commit hash, and test commands I listed alone?
+### 4. 回填spec
 
-If this skill directory contains `references/implement-specs-common.md`, treat it as an optional extension to the steps above; if it is absent, the Workflow section here is authoritative.
+確保所有實作任務完成並通過驗收之後，更新 `spec.md` 之中的需求checkboxes反應實際代碼實作狀態。
 
-## Sample hints
+## 範例
 
-- **Resolve path**: user says “implement `oauth-scope`”; read `docs/plans/2026-05-01/oauth-scope/` first, **not** a sibling folder like `docs/plans/2026-05-01/batch/oauth-scope/` unless that is where the five files actually live per user or manifest.
-- **Read order**: keep the mandated sequence (**spec → design → contract → checklist → tasks**); use **`checklist.md`** after **spec/design/contract** so acceptance checks map to stated requirements and boundaries.
-- **Multi-directory batch (same branch)**: `coordination.md` says merge order `api-layer` then `cli-wrapper` — finish **`api-layer`** `tasks.md` **and** **`api-layer`** `checklist.md` completely, then start **`cli-wrapper`**; do not split half of each.
-- **Branch sanity excerpt**: expect `git status -sb` like `## feature/x …` plus a dirty `README.md` you do **not** own — leave that file untouched; implement only paths from `tasks.md`.
-- **Completion report sketch**: `Branch: feature/x · Commit: a1b2c3d · Tests: npm test -- lib/auth.test.js · Backfill: tasks.md (done), checklist.md (R1.3 → passed).`
-- **Anti-pattern**: `git checkout -b impl/oauth-scope` for this skill — **wrong** unless the user changed scope mid-conversation.
-
-## References
-
-- `recover-missing-plan`: missing or mismatched plan recovery
-- **`commit-and-push`**: final commit/readiness (push only when user requests remote update)
+- "用戶指定了一份有四份spec的batch spec並要求實作這份batch spec。同時，`coordination.md` 之中建議merge順序是 spec 1 -> spec 2 -> spec 3 -> spec 4。" -> "從spec 1開始進行完整的實作流程，並在完成回填spec之後再開始實作spec 2，直至4份spec都被完成"
+- "用戶指定了一份有2份spec的batch spec並要求實作這份batch spec。同時，`coordination.md` 之中的建議merge順序是spec 2 -> spec 1，並且 `preparation.md` 存在於該batch spec之中。" -> "先實作 `preparation.md` 之中要求的任務並按照當中的驗收標準進行驗收。確定完成之後，從spec 2開始完整的實作流程。並在完成spec 2之後再實作 spec 1。"

package/implement-specs-with-subagents/SKILL.md

@@ -1,92 +1,49 @@
 ---
 name: implement-specs-with-subagents
-description: >-
-  Coordinator-only workflow for multispec batches: ingest `coordination.md`/`preparation.md`, run prerequisite work yourself, derive topological phases, launch **`implement-specs-with-worktree`** workers (one `{change}` each; **full** `tasks.md` + **full** `checklist.md` wrap-up—no partial handoff), **`merge-changes-from-local-branches`** after every phase succeeds, ledger every branch/test/merge—not for solo specs unless user explicitly insists on delegation overload. **Multi-phase: do not declare done until every non-blocked spec is merged across all phases** (or pipeline stopped on explicit blocker).
-  Wrong tool for one directory without parallel mandate—pick **`implement-specs-with-worktree`** / **`implement-specs`** depending on isolation. Publication/versioning stays outside this orchestration layer unless another skill attaches.
-  Ledger sample: `oauth-scope | phase=1 | merged | npm test ✅`.
+description: 當有多份規格文檔需要被實作時，且環境允許使用subagents，建議使用本技能調度subagents完成任務
 ---
 
-# Implement Specs with Subagents (Multi-Phase)
+## 目標
 
-## Dependencies
+調度多個subagents完成規格文檔的實作。
 
-- Required: `implement-specs-with-worktree` (every implementation subagent **MUST** follow this skill for its assigned directory); `merge-changes-from-local-branches` (phase integration **MUST NOT** skip this between phases); **`commit-and-push`** (integration-branch **preparation** commits and **any** post-merge submission the user expects on that branch—**MUST NOT** bypass for bare `git commit` / ungated push when this skill owns the branch).
-- Conditional: `generate-spec` if the batch is not implementation-ready; `review-change-set` only when the user asks for post-merge review.
-- Fallback: If independent subagents cannot run, **MUST** report that limitation. Serial `implement-specs-with-worktree` across specs is allowed **only** after the user explicitly approves that fallback.
+## 驗收條件
 
-## Non-negotiables
+- 在所有被用戶要求實作的spec之中，所有的 `checklist.md`, `tasks.md`, `spec.md` 當中所有非用戶填寫的checkboxes全部被勾選為完成狀態
+- 所有變更已經從各個subagents的工作分支合併回當前所在分支
+- 所有subagents創建的工作分支及工作樹已經被清理
 
-- **MUST NOT** delegate until `coordination.md`, when present, explicitly allows parallel implementation—or when absent, until you have verified no contradiction to parallel work.
-- **MUST** enumerate exact in-scope spec directories **before** any subagent starts; **MUST NOT** delegate archived, sibling, or “nearest guess” directories unless the user explicitly includes them.
-- **MUST** verify each delegated directory contains `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, and `design.md` before launch.
-- **MUST** complete, verify, and **finalize** documented shared preparation on the integration branch **through `commit-and-push`** before any implementation subagent starts when `preparation.md` exists or specs mandate pre-work; the coordinating agent **MUST NOT** delegate that preparation. Subagents **MUST NOT** start until this branch is clean at the preparation commit (or there is no required preparation).
-- **MUST** build a directed dependency graph from `coordination.md` plus each spec’s `spec.md` / `design.md` (edges: *provider spec must merge before consumer spec*). **MUST** partition specs into phases by topological **layers**: Phase 1 = specs with **no** in-batch prerequisites; for *k* ≥ 2, Phase *k* = specs whose in-batch prerequisites all appear in phases before *k*. **MUST NOT** start phase *k* until phase *k − 1* is fully merged into the integration branch (or you have an explicit user override). If the graph has a cycle, **MUST** stop and report it.
-- **MUST** assign **exactly one** spec directory per implementation subagent; **MUST NOT** assign multiple directories to one implementation subagent.
-- **`tasks.md` + `checklist.md` completeness (hard stop)**: Every implementation subagent **MUST** finish **all** actionable items in its assigned directory’s `tasks.md` **and** **all** `checklist.md` wrap-up, acceptance, verification, and closing obligations before reporting success—**no** partial completion, **no** “good enough” stops for large batches, **no** deferrals disguised as done. The coordinating agent **MUST NOT** merge a phase branch, advance the ledger to **`merged`**, or treat a spec as complete while **any** in-scope `tasks.md` line **or** checklist-defined closing item remains undone unless the batch is explicitly **`blocked`** with documented user/contract halt. **MUST** repeat this mandate in **every** subagent envelope so workers cannot interpret scope loosely.
-- **MUST** give each subagent only task-local context (repo root, exact spec path, `coordination.md` path if relevant, instruction to run `implement-specs-with-worktree`, explicit **`tasks.md` full-completion** and **`checklist.md` wrap-up full-completion** requirements, baseline commit when preparation exists, requirement to read the full bundle before edits, worktree isolation, tests, backfill, local commit, and reporting branch/worktree/commit/tests/blockers). **MUST NOT** leak unrelated reasoning or other subagents’ private diffs unless resolving a concrete conflict.
-- After each phase: **MUST** merge every **completed** spec branch from that phase into the integration branch via `merge-changes-from-local-branches` before starting the next phase; **MUST** resolve conflicts using spec contracts as the correctness tie-breaker; **MUST** record merge result in the ledger; if merge is blocked, **MUST** stop the pipeline and report.
-- **Multi-phase completion**: When the planned ledger has **more than one** phase, **MUST** loop steps **5→6→7** until **every** in-scope spec is either **`merged`** on the integration branch or explicitly **`blocked`** with a documented stop (user abort, irresolvable conflict, failed dependency, etc.). **MUST NOT** yield, summarize as “phase complete”, or imply the batch is finished while **any** phase still has a successful, unmerged branch or **`pending`** / **`in_progress`** rows for specs that should run—unless the coordinating agent is halted by a preceding Non-negotiable blocker **and** that halt is stated plainly.
-- Model: If the user names a model, **MUST** use it for implementation subagents when the platform allows; if not supported, **MUST** state that fact and continue only if the default is acceptable to the user’s intent.
+## 工作流程
 
-## Standards (summary)
+### 1. 定位實作範圍
 
-- **Evidence**: Batch read (`coordination.md`, `preparation.md`, every in-scope `spec.md` / `design.md`) before scheduling; ledger stays live.
-- **Execution**: Preparation → dependency graph → **repeat** (run phase *k* → merge phase *k*) until all phases reconciled on the integration branch; never skip merges between dependent phases; **multi-phase ⇒ no early “done” narrative** until ledger proves full merge-set (or documented blockers).
-- **Quality**: No duplicate delegation; subagents base on the branch that already contains preparation (and prior phases); **every** spec lands with **complete** `tasks.md` execution **and** **complete** `checklist.md` wrap-up, or a documented **blocked** state—workload is never a merge excuse; pause on shared file collisions, batch-wide defects, or rate-limit pressure.
-- **Output**: Concise ledger: per spec → phase, depends-on, subagent id/label, branch/worktree, commit or blocker, tests, merge status.
+閱讀用戶指定的spec：
 
-## Workflow
+- `spec.md` 定義了用戶的需求
+- `tasks.md` 定義了詳細的實作任務
+- `checklist.md` 定義了任務的完成和驗收條件
+- `contract.md` 定義了spec的外部依賴
+- `design.md` 定義了相關業務鏈路的架構設計
+- `coordination.md`（如有）定義了batch spec之中各份spec各自的實作邊界
+- `preparation.md`（如有）定義了實作batch spec之前各spec的共用準備工作
 
-**Chain-of-thought:** After **each** numbered step below, briefly answer **`Pause →`** items; escalate to halt or revise the plan whenever the answer violates Non-negotiables or exposes a blocker.
+按照以上文件，閱讀repo，理解本次spec的實作範圍。
 
-1. **Batch intake** — Resolve `docs/plans/{YYYY-MM-DD}/{batch_name}/`. Read `coordination.md` (first) and `preparation.md` when present. List only in-scope spec directories; verify the five required files each. If coordination blocks parallel work, **stop** and report. If preparation is required, go to step 2; else go to step 3.
-   - **Pause →** Can I quote **verbatim** why each enumerated directory is in scope—not “probably related”?
-   - **Pause →** What **exact sentence** from `coordination.md` gates parallel readiness, if any—or what absence did I infer from—and is that justified?
+### 2. 完成前置準備工作（如有）
 
-2. **Preparation (blocking when required)** — Coordinating agent executes shared prep only: read tasks/outputs/verification hooks, satisfy scope, run listed checks, **finalize on the integration branch through `commit-and-push`** (push only if the user requested remote update), record prep commit hash in ledger, leave working tree clean. If prep fails, **stop** (no subagents).
-   - **Pause →** Am I silently delegating preparation to a **subagent** when the coordinating agent owns it—is that happening?
-   - **Pause →** What **commit hash** and **clean-tree** confirmation will subagents inherit as baseline?
+如果實作的batch spec 有 `preparation.md`，你需要在開始實作之前需要先完成 `preparation.md` 之中所規定的任務內容，並在驗收條件滿足之後回填 `preparation.md`。使用 `commit-and-push` 技能並遵守當中的流程將前置準備工作提交，不需要推送到remote。
 
-3. **Dependency graph** — Extract ordering obligations; assign each spec a phase index via topological layering. Persist `depends-on` / `depended-by` in the ledger. Cycles ⇒ **stop**.
-   - **Pause →** For each edge (A must land before B), what **sentence** from spec/design/coordination supports it?
-   - **Pause →** If I flattened phases wrong, which later spec would start **without** its merged predecessor—how do I detect that now?
+### 3. 規劃subagents調度順序
 
-4. **Plan launches** — For each phase, queue one item per spec. Ledger fields: phase, paths, deps, planned branch/worktree basename, status (`pending` / `in_progress` / `merged` / `blocked`), commit, tests, blockers, prep-commit baseline note. Fix model policy per Non-negotiables.
-   - **Pause →** Is there **exactly one** spec directory per queued subagent—never two in one prompt?
-   - **Pause →** What will I **repeat** in every subagent envelope so they cannot “improvise” the wrong skill or wrong path?
+識別各份spec之間的依賴關係，並建立調度順序。將多份spec的實作切分為多個實作批次。每一個實作批次內部的spec之間沒有互相依賴。完成實作批次的建立之後，為每一個subagents分配僅一份spec，並且開始實作。
 
-5. **Run phase *k*** — Launch subagents for each spec in the phase with task-local payloads (see Non-negotiables). Monitor ledger; pause new launches on shared blockers; on conflicting edits to shared files, resolve ownership using `coordination.md` before more launches; if one spec fails and others depend on it, **MUST NOT** start those dependents until resolved; batch-wide planning failure ⇒ stop all scheduling.
-   - **Pause →** Does every active subagent have a **distinct** spec directory assignment—no duplicate or overlapping paths?
-   - **Pause →** Did two running subagents report **overlapping** paths; if yes, did I stop launching until ownership is clear?
+在開始實作一個新的實作批次之前，你需要使用 `merge-changes-from-local-branches` 技能，遵守當中的流程，將前一個實作批次的變更從本地其他分支合併回來。
 
-6. **Merge phase *k*** — When every item in phase *k* is **done or explicitly blocked**, merge **each successful** branch via `merge-changes-from-local-branches`; rerun critical tests if your standards say so; update ledger. Merge failure ⇒ **stop** before phase *k+1*. **“Done”** here **requires** full `tasks.md` completion **and** full `checklist.md` wrap-up / acceptance per Non-negotiables—not merely a subagent “looks finished” report.
-   - **Pause →** For **each** spec I am about to merge, can I cite **evidence** (branch + `tasks.md` **and** `checklist.md` state) that **zero** applicable task lines **and** **zero** outstanding checklist closing items remain—or is this a documented **`blocked`** outcome instead?
-   - **Pause →** Has **every** successful branch in this phase been merged into the **same** integration branch I will use to **start** phase *k+1*?
-   - **Pause →** If a merge conflict touches a **contract** field, which spec’s `contract.md` / `design.md` is the tie-breaker I will apply?
+### 4. 驗收工作
 
-7. **Repeat until batch reconciled** — After step 6, if **any** later phase still has specs not yet run or not yet merged: **MUST** increment *k* and **return to step 5** on the **same** integration branch (now including phase *k* merges). Next phase starts only on that branch. **MUST NOT** end the coordinator run with a “wrapped up” message if the ledger still shows remaining phases or unmerged successful work. **Only** when every in-scope spec is **`merged`** or explicitly **`blocked`** may you treat implementation coordination as **complete** (then optional handoff to submit/review skills per user).
-   - **Pause →** How many phases remain after this merge—is the count **zero**? If not, **immediately** plan step 5 for *k+1*.
-   - **Pause →** Before launching phase *k+1*, can I **name** the merge commit or branch state that contains **all** prerequisites for every spec in that phase?
-   - **Pause →** Can I cite **ledger lines** proving **merged** for every non-blocked spec in **every** phase?
+完成所有實作批次的合併之後，你需要閱讀所有spec之中的 `checklist.md`, `tasks.md`, `spec.md`，並確保當中非用戶填寫的任務相關checkboxes都被勾選為完成。
 
-## Out of scope
+## 範例
 
-- **MUST NOT** use this skill for a single spec unless the user explicitly requests subagent delegation.
-
-**Repository regression check:** The coordinating agent must complete and commit explicitly documented prerequisite preparation on the integration branch before launching implementation subagents when `preparation.md` or equivalent mandates it.
-
-## Sample hints (subagent scheduling)
-
-- **Parallel batch (independent specs)** — The batch has multiple member directories and `coordination.md` allows parallel implementation with **no** in-batch prerequisites. Treat them as **one phase**: assign **exactly one** spec per subagent, launch one **`implement-specs-with-worktree`** worker per spec, each finishing **all** of its directory’s **`tasks.md`** and **`checklist.md`** before reporting success; when **every** branch in the phase is green, run **`merge-changes-from-local-branches`** to bring **every** member into the integration branch **before** declaring the batch done or starting a follow-on phase.
-
-- **Preparation plus A → {B, C}** — Specs **A**, **B**, and **C** share a batch with **`preparation.md`**; `coordination.md` / design shows **B** and **C** depend on merged work from **A**. Coordinating agent: (1) complete **preparation** on the integration branch and **`commit-and-push`** (push only if the user asked); (2) **Phase 1**: launch **one** subagent for **A** only; **`merge-changes-from-local-branches`** for **A** when it passes; (3) **Phase 2**: launch **two** subagents for **B** and **C** from the branch that already contains **A**’s merge; (4) merge **B** and **C** when both finish. **MUST NOT** start **B** or **C** until **A** is merged into the baseline they branch from.
-
-- **Ledger reminder** — One row per spec remains mandatory (`phase`, `depends-on`, branch/worktree, `merged` / `blocked`, tests); see Non-negotiables for full fields.
-
-## References
-
-- `implement-specs-with-worktree`: per-spec execution environment
-- `merge-changes-from-local-branches`: phase merge integration (and downstream submit flow when that skill is invoked)
-- `generate-spec`: repair planning when the batch is not ready
-- `coordination.md`, `preparation.md`: batch-level ordering and prerequisites
-- `review-change-set`: optional post-merge review
+- "用戶要求實作一份batch spec。該batch spec有5份spec。spec 2依賴於 spec 1，spec 4依賴於spec 3，spec 5依賴於spec 2, spec 4。" -> "將batch spec切分為3個實作批次。第一批，先派發兩個subagents各自實作spec 1, spec 3，並將變更合併回當前分支；第二批派發兩個subagents個字實作spec 2, spec 4，並將變更合併回當前分支；第三批派發subagent實作spec 5，並將變更合併回當前分支。完成驗證工作之後向用戶回報成果。"
+- "用戶要求實作一份batch spec。該batch spec有3份spec，並且存在 `preparation.md`。3份spec之間各自無依賴關係。" -> "先完成 `preparation.md` 的實作並提交。然後啟動三個subagents並行完成三份spec的任務。完成之後，將變更合併回當前分支。完成驗證工作之後向用戶回報結果。"