flutter_inspector_kit

完整開發流程編排器。使用者說「幫我做 X 功能」時觸發，自動依序驅動所有 agent 直到 PR 建立，只在關鍵決策點暫停確認。 也可用既有 GitHub issue id 直接進入 STAGE 1（跳過 STAGE 0a/0b 規劃），例如「開發 issue #42」「處理 #54」。 PR 實際合併後，可另外觸發 STAGE 6 清理該 PR 對應的 worktree（branch 一律保留不刪除）。 小修正可走 quick 模式（單暫停點、不建 worktree），例如「快速修正 <描述>」「/gen-dev-workflow quick #54」。 觸發條件：dev workflow, 開始開發, 新功能開發, 幫我做 X 功能, 繼續, 繼續上次, 繼續開發, /gen-dev-workflow, 開發 issue #<id>, 處理 #<id>, 快速修正, quick fix, PR #<id> 合併了 清理 worktree

分析 unstaged/staged 的 git 變更，依功能相關性將檔案分組，並建立多個語意化的單元 commit。當使用者說 "commit"、"gen-commit"、"依功能 commit"、"幫我 commit"、"進行功能單元 commit"，或任何要求智慧分組並 commit 目前變更的變體時使用。也適用於使用者想把變更檔案以有意義、結構良好、依功能領域組織的訊息 commit 時。

當使用者要為已合入 main 的變更發布新版本——更新版號（pubspec.yaml / README.md）、把使用者可見的新功能同步進 README、補上 CHANGELOG、並打 git tag 推上去時使用。觸發語如「更新版本資訊」、「bump 版號」、「調整版號為 vX.Y.Z 下 tag push」、「release vX.Y.Z」、「gen-update-publish-info vX.Y.Z」。

讀取 GitHub PR 的 review inline comments，自行判斷每則意見是否需要修復——技術正確且合理者修復後 commit、push 並回覆附 commit SHA；不需修復者直接以中文回覆技術理由。觸發時機：使用者說「回覆 PR comment」、「針對 review 回覆修正」、「gen-pr-reply PR {number}」，或要針對 code review 的每個 inline comment 回覆修正 commit。

當使用者提供 GitHub issue id 連同已解析的 issue brief，並希望 Codex 從安全的 base 建立新的 git branch 與 worktree、沿用既有命名規則、且不依賴當前 branch 名稱即完成最小開發設定時，使用此 skill。

用於安全地關閉、移除、清理 git worktree 的收尾流程。檢查 worktree 狀態，乾淨且無殘留變更時直接移除、 不需再詢問是否刪除；不觸碰任何 issue 或 ticket 的 State；只移除 worktree，對應 branch 一律保留不刪除。 觸發條件：關閉 worktree, 移除 worktree, 清理 worktree, worktree 收尾, close worktree, remove worktree

分析指定 branch 到 main 的差異，並依照 pr-comment.md 格式產出 PR comment 寫入 pr-desc.md。 觸發條件：gen pr-comment <branch-name>

在 ticket-id-dev-prep 已選定或準備好開發工作區，且 Codex 需從 advisor 解析的 brief、GitHub issue 細節與當前工作區程式碼脈絡建立或更新 docs/issues/<issue-id>.md 時使用此 skill；只聚焦於記錄問題，不撰寫 specs 或程式碼。

當使用者想要分析當前 branch slug、檢視當前 repo 中的相關程式碼路徑、把任務濃縮成清楚的實作 brief，並在不發明缺漏需求的前提下提出務實的開發、bug-fix 或改善方向時，使用此 skill。

當 Codex 需要在 issue docs、specs、workspace prep、實作或工作流程路由之前，從 GitHub issues、使用者 briefs、QA 報告、branch 脈絡或聚焦的 repo 證據進行正規 issue context 蒐集時使用。在不修改 source、tests、specs、PRs 或 GitHub state 的前提下，產生或更新 .agent-output/context/<issue-id-or-slug>.md 作為 facts/inference/open-questions 的主要來源。

根據程式碼痛點與分析，以中文生成一個結構化、直指核心的 GitHub Issue 描述，符合 Problem/Root Cause/Fix/Out of Scope/Verification 風格。

讀取一份 execute plan 文件，理解內容後在 GitHub 建立一個英文標題的 issue， 接著呼叫 gen-branch 以該 issue 編號建立分支並 checkout。 觸發條件：gen issue-from-plan <plan-file-path>

當使用者想要針對合併至 origin/main 的變更撰寫、改寫、縮短或標準化 Pull Request (PR) 描述草稿時，請使用此技能。在審閱後可選擇發布 PR。此技能會產出精簡的 zh-tw Markdown，並保留必要的 en-us 技術術語。若未明確指定基準分支，預設與 origin/main 進行比較。若分支名稱開頭包含可解析的 GitHub 議題編號，則會在 Summary 中自動加上議題資訊。

在 context-collector 產出 issue context 後、且使用者想準備開發分支或 worktree 時使用。以 .agent-output/context/* 作為 issue id、slug、work type 與 blockers 的來源；建立新的 worktree 時，必須在任何 issue-doc-writer 或 issue-spec-writer 執行前，把目前的 context 輸出複製到新的 worktree。

當使用者想要對當前 branch 自從與其 base branch 分歧以來的所有變更進行一般性 code review，且不要把審查範圍預設為 origin/main 時，使用此 skill。它應判定 branch fork point、檢視完整的 branch diff、優先處理 bugs 與 regression 風險，並以 zh-tw 呈現審查發現，同時遵循 repository 的 .gemini/styleguide.md code review persona 與收尾儀式。

進行高品質 code review 時的共用準則、persona 與關鍵限制。在執行 /code-review 或 /pr-code-review 指令時使用此 skill。

在 branch-ticket-issue-doc 已於選定的開發工作區建立 docs/issues/<ticket-id>.md，且 Codex 需建立或更新 docs/issues/specs/<ticket-id>.md 作為該 issue 的實作 spec 時使用此 skill；先讀 issue doc，僅在需要時檢視程式碼，且不進行程式碼實作變更。

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

依據 GitHub Issue 編號建立以 main 為 base 的「純本地分支」（不追蹤任何 remote）， 命名格式對齊 <category>/YYYYMM/<ISSUE-NUMBER>-<kebab-case-summary>。 觸發條件：gen branch <ISSUE-NUMBER>

對 PR 或指定 Branch 進行深度代碼審查，僅將修改建議顯示在 Terminal 中。 觸發條件：gen pr-review <pr-number/branch-name>

當使用者輸入 /list-work-dir，或詢問「目前工作目錄有哪些」、「working directory 有什麼」時使用。

Use when executing implementation plans with independent tasks in the current session

Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

Use when you have a spec or requirements for a multi-step task, before touching code