適用情境
一件功能要在工作區裡做完並合回主線。這是 bundled workflow 之一：bundled workflows guide project setup, design brainstorming, and shipping a pull request — pushing the workspace branch and opening or updating its GitHub PR through your own gh.
核心步驟
- 計畫先行——對話裡讓代理提計畫（spec-first：邊界、契約、驗收先講清楚）。計畫是共用文件：代理更新、你編輯，改到同意才動工。
- 逐步實作、逐步 commit——
each completed step can be committed and reviewed on its own。不要讓代理一次改完才看：每步一個 commit，diff 好審，回滾也容易。 - 逐輪審查——工作台看這一輪的 diff；有意見就在檔案或 diff 上釘註解，送回對話當結構化 context。審的是 turn，不是聊天記錄。
- 開 PR——topbar 一鍵 publish / push / open PR。PR 描述來源可選：計畫、commits、repo 的 PR template，或代理寫的草稿。推送走你機器上的
gh與你的 GitHub 憑證。 - 盯 CI、處理 review——topbar 顯示 CI checks 與 review decision。紅了？把失敗的 checks 或分岔的分支直接交給代理修（hand them to the agent）；可標 ready、重開 PR、或刪遠端分支。
- 合併——用 repo 上次用的合併方式（merge/squash/rebase 保持一致）合併。PR 一合併，工作區自動 settle 到 shelf，分支生命週期收尾。
提醒
- PR 描述用「計畫」生成的好處：reviewer 看到的是當初同意的 spec，不是事後補的作文。
- 合併前把這次改動寫回規格圖——意圖跟著程式碼一起進主線。