@laitszkin/apollo-toolkit 3.11.8 → 3.12.1

package/enhance-existing-features/SKILL.md

@@ -1,77 +1,40 @@
 ---
 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；所有非平凡變更必須經過 test-case-strategy。
 ---
 
-# Enhance Existing Features
+## 技能目標
 
-## Dependencies
+在不打亂既有系統邊界的前提下，為 brownfield 專案安全地增強功能或調整行為，以合適的 spec 流程與測試策略將風險控制在可驗證範圍內。
 
-- 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.
+## 驗收條件
 
-## Non-negotiables
+- 變更範圍明確：已讀懂受影響模組、入口點、整合邊界與變更爆炸半徑。
+- 已正確判斷直接實作或必須先走 `generate-spec`，並在不需要 spec 時給出明確理由。
+- 每個非平凡變更都經過 `test-case-strategy`，留下清楚的 oracle、驗證方式與通過證據。
+- 若使用 spec：批准、實作、回填與計劃文件狀態同步全部完成。
+- 若未使用 spec：最終摘要足以說明風險、測試結果與剩餘限制。
+- `test-case-strategy` 不可用時必須停止；需要 spec 但 `generate-spec` 不可用時必須停止。
 
-- **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.
+## 工作流程
 
-## Standards (summary)
+1. 完整閱讀受影響模組、資料流、整合點與現有測試，明確界定變更的爆炸半徑。
+2. 判斷是否需要 spec：涉及新的或改變使用者可見行為、跨模組協調、高風險敏感流程、重大歧義時走 `generate-spec`。不需 spec 時明確說出理由。
+3. 若需要 spec，必須等批准後才能改產品程式碼。
+4. 查閱變更依賴的官方文件或 API spec，以最小差異實作需求，不順手做額外重構或範圍擴張。
+5. 使用 `test-case-strategy` 選擇測試組合，跑測試並修正失敗。
+6. 若使用 spec，回填所有計劃文件；若未使用，輸出簡潔的結果摘要、測試證據與剩餘限制。
 
-- **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.
+## 使用範例
 
-## Workflow
+- 「新增一套影響 API、資料庫與 UI 的權限模型」→ 先走 `generate-spec`，批准後再實作，並補上跨層測試。交付物包含已批准的 spec、通過的測試證據、回填完成的計劃文件。
+- 「修正分頁 off-by-one，讓行為回到 README 描述」→ 不開 spec，直接修復並加回歸測試。交付物為修復後的代碼與測試通過證據。
 
-**Chain-of-thought:** **`Pause →`** after explorations and spec decision—wrong classification wastes days.
 
-### 1) Explore codebase
+## 參考資料索引
 
-- Map modules, integrations, blast radius.
-  - **Pause →** Can I state **one paragraph** concrete change surface before editing?
+- `generate-spec`：需要書面批准時的 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?
-
-### 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
+- `test-case-strategy`：非平凡變更的測試選型與 oracle 設計。
+- `commit-and-push`：使用者要求提交或推送時的最終交付流程。

package/generate-spec/SKILL.md

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

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

@@ -1,84 +1,60 @@
 ---
 name: implement-specs-with-worktree
-description: >-
-  Like **`implement-specs`** (same read order, full `tasks.md`/`checklist.md`, sequential multi-spec per `coordination.md`) but all writes in a dedicated worktree+feature branch; `pwd` must match `git rev-parse --show-toplevel`; parent checkout read-only for deliverables; honor `preparation.md` and `coordination.md` collision rules. Use when isolation is required; otherwise **`implement-specs`**.
+description: 當你需要在獨立分支和工作樹之中實作spec時，使用這個技能。
 ---
 
-# Implement Specs with Worktree
+## 技能目標
 
-## Dependencies
+在獨立分支及工作樹實作用戶指定的spec。確保所有任務都被完成，用戶所有需求都被滿足。
 
-- Required: `implement-specs` for the shared discovery / implementation / backfill / **submit** / reporting lifecycle; **`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.
-- Fallback: If any required dependency skill is unavailable, **MUST** stop and report it.
+## 驗收條件
 
-## Non-negotiables
+- 在所有被用戶要求實作的spec之中，所有的 `checklist.md`, `tasks.md`, `spec.md` 當中所有非用戶填寫的任務相關checkboxes全部被勾選為完成狀態
 
-- **MUST** perform every write (product code, tests, and spec-document backfill) inside the active worktree: after each `cd`, **MUST** confirm `pwd` equals `git rev-parse --show-toplevel` for that worktree before editing.
-- **MUST NOT** edit implementation files from the parent checkout except for creating or listing worktrees and read-only inspection; the parent checkout is write-prohibited for this spec’s deliverables.
-- **MUST** follow the **`implement-specs` Workflow** for discovery, implementation, backfill, commit discipline, and completion reporting—**except** that branch/worktree restrictions in `implement-specs` Non-negotiables are replaced by this skill’s worktree rules.
-- **MUST** create the implementation branch from the **same parent branch** the user/session identified as the baseline (often the branch that will receive the merge—not necessarily `main` unless that branch is verified as the base).
-- **MUST** use the spec directory name (`change_name`) as the canonical basename for the worktree path and branch stem; branch **`type`/name** must follow `references/branch-naming.md`.
-- **MUST** use `git show-ref` and `git worktree list --porcelain` (not shell guesses) when checking whether a branch or worktree already exists; if creation fails ambiguously, **MUST** re-query those commands before retrying.
-- When `preparation.md` exists: **MUST** treat it as an already-committed shared baseline for parallel work; **MUST NOT** redo its tasks inside the member spec unless the preparation commit is missing or the document states the prerequisite is still blocked. If baseline assumptions break, **MUST** update `preparation.md` or stop for coordination—**MUST NOT** silently move prerequisite work into the member spec.
-- **`tasks.md` completeness (hard stop)**: **MUST** satisfy the **`implement-specs` Non-negotiable** on **`tasks.md`**: execute **every** actionable line in the in-scope `tasks.md`, with **no** early exit for workload, duration, or breadth; partial task lists are **not** a mergeable or committable state. If a line cannot be met under contracts, **MUST** halt with evidence and resolve the plan through approved planning updates before claiming completion.
-- **`checklist.md` wrap-up / acceptance (hard stop for “spec complete”)**: **MUST** satisfy the **`implement-specs` Non-negotiable** on **`checklist.md`**: the spec is **not** **complete** and **must not** be merged or treated as finished until **all** checklist-defined wrap-up, acceptance, and closing obligations for the change are **done** and honestly recorded—**no** workload exemption.
-- **MUST** complete the same quality bar as `implement-specs`: on top of full `tasks.md` and **complete checklist wrap-up**, relevant tests, honest backfill, no sibling-spec scope creep, revert formatter-only noise outside owned files before commit.
-- **MUST NOT** `git push` **outside** **`commit-and-push`** unless the user explicitly requests remote update through that workflow (or a release/PR skill the user named).
-- For targeted Rust tests: **MUST** pass at most one positional `cargo test` filter per invocation; use separate commands or a broader confirmed filter when multiple selectors are needed.
+## 工作流程
 
-## Standards (summary)
+### 1. 定位實作範圍
 
-- **Evidence**: Read full spec set plus `coordination.md` and `preparation.md` when present; verify whether the spec is already implemented on the baseline before opening a new worktree; if the plan is missing in the worktree, sync the authoritative copy and re-read before coding.
-- **Execution**: Isolated worktree only; branch naming per `references/branch-naming.md`; check sibling worktrees before editing shared boundaries in a parallel batch.
-- **Quality**: Same as `implement-specs` (including **all** `tasks.md` items **and** **all** `checklist.md` wrap-up obligations—no workload excuse), plus collision awareness with sibling worktrees per `coordination.md`.
-- **Output**: Clean local branch in the worktree with intended commits only; parent working tree unchanged by this implementation.
+閱讀用戶指定的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:** Answer each **`Pause →`** question before leaving the phase; if any answer conflicts with Non-negotiables, fix state first (right directory, right root, right baseline).
+按照以上文件，閱讀repo，理解本次spec的實作範圍。
 
-### A) Specs and baseline
+### 2. 創建子分支及worktree
 
-- Run **`implement-specs` Workflow steps 1–2** in spirit: resolve paths, read all core files and `coordination.md`; run `git status` / `git worktree list` as needed. If the plan files are absent in the target worktree, sync them in, then re-read in that tree.
-- Read `preparation.md` when present; apply the Non-negotiable baseline rule above.
-  - **Pause →** Where will authoritative plan text live **for this session**—parent tree, worktree after sync—and have I opened that copy end-to-end?
-  - **Pause →** Does `coordination.md` / `preparation.md` imply **anything** I must not redo or must assume stable before coding?
+從當前分支創建子分支及worktree。分支以規格文檔的實際變更命名，並且需要符合通用開發規範(e.g. feat/event-bus-backend)
 
-### B) Worktree and branch
+### 3. 實作spec任務
 
-- If the requested scope is already implemented and verified on the baseline, **MUST** report `no-op` with evidence instead of creating duplicate work.
-- Otherwise: ensure the shell is in the correct worktree (create one if required):
-  - Derive `change_name`; branch pattern `<type>/<spec-name>` per `references/branch-naming.md`; worktree directory `../<spec-name>` (or an equivalent path the user approves).
-  - `git branch <branch-name> <parent-branch>` then `git worktree add <path> <branch-name>`; `cd` into it; verify `pwd` vs `git rev-parse --show-toplevel`.
-- Before editing shared modules in a batch, check `git worktree list --porcelain` and `coordination.md` for sibling ownership; read sibling diffs when the same file is touched.
-  - **Pause →** Why is **`parent-branch`** definitely the correct baseline—not an unexamined assumption that `main` is default?
-  - **Pause →** Could this work duplicate an **already-merged** implementation; what **evidence** (`git log`, tests, code search) did I use to rule that in or out?
-  - **Pause →** After `cd`, do `pwd` and `git rev-parse --show-toplevel` **match**; if not, why am I not stopping before any write?
-  - **Pause →** Which sibling worktree might already own the shared file I am about to touch, and did I inspect their diff?
+嚴格按照 `tasks.md` 之中定義的任務，逐項完成實作。如果有多份 `tasks.md` 存在於多份spec之中，則依照 `coordination.md` 之中建議的merge順序進行實作。
+在確認完成所有任務之後，將 `tasks.md` 之中的所有checkboxes勾選為完成。
 
-### C) Implement, backfill, commit, report
+如果實作的spec是batch spec，且有 `preparation.md`，在開始實作之前需要先完成 `preparation.md` 之中所規定的任務內容，並在驗收條件滿足之後回填 `preparation.md`。
 
-- Execute **`implement-specs` Workflow steps 3–6** (implement—including **full** `tasks.md` and checklist-backed work per Non-negotiables—backfill—including **complete** `checklist.md` wrap-up before submit—**submit via `commit-and-push`**, report) **entirely from the worktree root**, honoring the same **`spec.md` / `design.md` / `contract.md` / `checklist.md` / `tasks.md`** read-and-execute rules as **`implement-specs`** (including **one directory at a time** to completion when the request spans multiple member specs on the same integration cadence—typically **one worktree lifecycle per directory** unless the user batches otherwise).
-- In the report, **MUST** include branch name, worktree path, commit hash, tests run, backfilled docs, and an explicit statement that the parent checkout was not modified for implementation files.
-  - **Pause →** Am I honoring **implement-specs** step 3–6 **constraints** literally while respecting that all writes happen **only** under this worktree root?
-  - **Pause →** If I used Rust `cargo test` filters, did I violate the **single positional filter** rule; how would I split the commands?
+### 4. 驗證實作
 
-## Sample hints
+按照 `checklist.md` 之中定義的驗收標準，逐項驗收並檢查任務是否完成。對於未達到驗收標準的任務，必須重新實作及重新驗收，並在完成驗收之後將所有 `checklist.md` 之中的checkboxes勾選為完成。
 
-- **Root check** (must print the same path twice before edits):
-  ```bash
-  pwd && git rev-parse --show-toplevel
-  ```
-- **Skeleton commands** (`change_name` `oauth-scope`, parent `feature/x`, type `feat`):
-  ```bash
-  git branch feat/oauth-scope feature/x
-  git worktree add ../oauth-scope feat/oauth-scope
-  cd ../oauth-scope
-  ```
-- **Cargo** (two filters ⇒ two commands): run `cargo test parser::` **and separately** `cargo test cache::`, not `cargo test parser:: cache::`.
+### 5. 回填spec
 
-## References
+確保所有實作任務完成並通過驗收之後，更新 `spec.md` 之中的需求checkboxes反應實際代碼實作狀態。
 
-- `implement-specs`: shared lifecycle (locate → read bundle in order → implement → backfill → **`commit-and-push`** → report)
-- `references/branch-naming.md`: branch naming
+### 6. 提交變更
+
+使用 `commit-and-push` 將變更提交到子分支上。不需要將變更推送到remote。
+
+## 範例
+
+- "用戶指定了一份有四份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。"
+
+## 參考資料
+
+- `references/branch-naming.md` - 建議分支命名方式