把已確認開發計畫裡未完成的任務拆成 GitHub 子 Issue，先檢核與預覽，再依授權發布；發布後由人工 develop 開工。單一需求卡改用 request-feature。
commit 前執行格式化檢查與靜態分析，自動修復可修的錯誤
規劃或實作前查核相關 codebase 的行為與需求差異，區分實作、測試、部署及實際可用證據。
收集 PR 的 CI 與 reviewer feedback，由 AI 查證、分類與修訂後交人審核；依既有授權修正與發布。
以 issue 為單位的隔離平行開發流程。每個 issue 在 worktrees/編號-slug/ 建立獨立 worktree（或 clone）+ task.md manifest，多個 session 可同時開發不同 issue 互不干擾。Use when starting development on a GitHub issue, running parallel multi-issue development, or resuming a task from worktrees/. Trigger words: 開發 issue、開工、develop、平行開發、接手任務、發 PR、任務收尾。取代已退役的 dev-branch-workflow。
從想法、Issue、PRD、FRD、POC 或開發分支查核現況，起草與補齊一份可驗收的 PRD。適用需求規劃、規格整理與需求補洞。
Use when committing changes - drafts a Why/How commit message from git diff and conversation context, shows it once for approval, then executes git commit. Only asks the user when the reasoning genuinely can't be inferred.
島島阿學 Planning Board 狀態操作與稽核：七欄語意（含 PM 驗收的 Acceptance）、bin/pipeline/board.ts set／remove／audit、GitHub 內建 workflow 限制與除錯。
依實際 PR 與驗收狀態草擬關聯 Issue 更新，僅在明確授權留言或關閉時發布並回讀。
把操作異常、截圖、對話或 CI 錯誤整理成可追蹤的 bug 草稿，查核現況與重複卡，依授權建立 GitHub Issue。適用非工程人員通報，不要求先知道 repo 或根因。想要新功能改用 request-feature。
把想法、PRD、FRD 或 POC 整理成島島阿學的需求 Issue，掛上 Planning board；開新功能時依 AC 拆好子卡。使用於「開 issue」「開卡」「新增任務」「提需求」「create issue」。東西壞了改用 report-bug；確認好的計畫要批次拆任務改用 break-down-plan。
由 AI 查核 branch 變更與多引擎 findings，自審並在授權範圍修正後交人審核。
PM 驗收：用 Codex 內建瀏覽器測試 Planning board 上 Status=Acceptance 的 daodao issue，將截圖直接貼到 issue 驗收留言；PASS 關 issue、FAIL 移 Need Fix、受阻留 Acceptance 加 acceptance:blocked。
PR merge 後由 AI 查核合併、驗收與部署證據，更新適用文件並自審，交人審閱未完成事項。
實際操作產品 Web App，驗證指定功能的使用者路徑、背景副作用與可檢視證據。沿用隔離 runtime、Playwright 與既有 feature map；不以後端測試代替畫面旅程。