メニュー
在 branch-ticket-issue-doc 已於所選開發工作區建立 docs/issues/<ticket-id>.md、且 Codex 需要建立或更新 docs/issues/specs/<ticket-id>.md 作為該 issue 的實作 spec 時使用此 skill；先讀 issue 文件，僅在必要時檢視程式碼，且不實作程式碼變更。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
分析 unstaged/staged 的 git 變更，依功能相關性將檔案分組，並建立多個語意化的單元 commit。當使用者說 "commit"、"gen-commit"、"依功能 commit"、"幫我 commit"、"進行功能單元 commit"，或任何要求智慧分組並 commit 目前變更的變體時使用。也適用於使用者想把變更檔案以有意義、結構良好、依功能領域組織的訊息 commit 時。
完整開發流程編排器。使用者說「幫我做 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
在 context-collector 產出 issue context 後、且使用者想準備開發分支或 worktree 時使用。以 .agent-output/context/* 作為 issue id、slug、work type 與 blockers 的來源；建立新的 worktree 時，必須在任何 issue-doc-writer 或 issue-spec-writer 執行前，把目前的 context 輸出複製到新的 worktree。
在 ticket-id-dev-prep 已選定或準備好開發工作區，且 Codex 需從 advisor 解析的 brief、GitHub issue 細節與當前工作區程式碼脈絡建立或更新 docs/issues/<issue-id>.md 時使用此 skill；只聚焦於記錄問題，不撰寫 specs 或程式碼。
當使用者想對當前分支自其 base 分支分岔以來的所有變更做一般性程式碼審查、且不將審查範圍預設為 origin/main 時，使用此 skill。它應判定分支的 fork point、檢視完整的 branch diff、優先處理 bug 與回歸風險，並以 zh-tw 呈現審查結果，同時遵循 repository 的 .gemini/styleguide.md 程式碼審查人設與結尾儀式。
執行高品質程式碼審查時的共通準則、人設與關鍵限制。在執行 /code-review 或 /pr-code-review 指令時使用此 skill。
| name | issue-spec-prep |
| description | 在 branch-ticket-issue-doc 已於所選開發工作區建立 docs/issues/<ticket-id>.md、且 Codex 需要建立或更新 docs/issues/specs/<ticket-id>.md 作為該 issue 的實作 spec 時使用此 skill；先讀 issue 文件，僅在必要時檢視程式碼，且不實作程式碼變更。 |
在 branch-ticket-issue-doc 之後使用此 skill。
目標：從 issue 文件與當前 worktree 的程式碼脈絡，建立或更新 docs/issues/specs/<ticket-id>.md。
在此處不要變更產品程式碼。在此處不要執行實作重構。
ticket-id-dev-prep 所選的開發工作區。docs/issues/<ticket-id>.md。branch-ticket-issue-doc。docs/issues/specs/ 不存在則建立。docs/issues/<ticket-id>.md。agy）生成 spec 文件本文：
printf '%s' "<填入下方 prompt>" | agy -p --print-timeout 180s），prompt 如下（以實際資料填入；務必在結尾要求「只輸出 spec 本文，不要任何開場白或人設評論」）：
你是一位資深 Flutter 工程師，請根據以下問題描述與程式碼觀察，用繁體中文撰寫一份實作規格文件（保留英文技術術語）。
Ticket: <ticket-id> - <ticket summary>
Issue 文件內容：
<docs/issues/<ticket-id>.md 完整內容>
程式碼觀察（已檢視的相關模組、邏輯邊界、測試缺口）：
<Claude 的 rg / file read 觀察摘要>
請嚴格按照以下 markdown 結構輸出，每個段落用簡潔的條列式說明：
# <TICKET-ID> Spec
## 背景
## 目標
## 非目標
## 目前行為
## 目標行為
## 修正策略
## 影響範圍
### Affected Files / Modules
## Acceptance Criteria
## Test Plan
### Automated
### Manual
## Regression Risk
## Open Questions
規則：
- Acceptance Criteria 必須描述可觀察的行為
- Test Plan 需具體指出 unit / widget / bloc / integration / manual 類型
- 若有未知項目會阻塞實作，在 Open Questions 中清楚標記
- 不要發明 issue 文件中未提及的需求
只輸出 spec 文件內容，不要其他說明。
agy 成功回傳包含 ## 背景 與 ## Acceptance Criteria 的 spec 結構，採用其內容。agy 會讀取全域 CLAUDE.md 而附加 Linus 人設框架，且可能在生成時順手建立暫存檔。採用前須剝除人設包裝、只取目標 spec 結構；並確認 agy 未在工作區誤建檔案（如有則刪除）。docs/issues/specs/<ticket-id>.md 一律由 Claude 自行 Write 寫入，不依賴 agy 落檔。agy 不在 PATH、呼叫失敗或回傳格式不合法，回退至步驟 5 自行撰寫 spec。docs/issues/specs/<ticket-id>.md，依照 Spec Template。使用：
docs/issues/specs/<TICKET-ID>-<description-suffix>.md
其中 <description-suffix> 取自當前分支名稱的最後一段路徑，並移除開頭的 ticket id 部分。
範例：
fix/202605/BUG-2362-some-feature-fixBUG-2362-some-feature-fixsome-feature-fixdocs/issues/specs/BUG-2362-some-feature-fix.md執行以下指令解析 suffix：
git rev-parse --abbrev-ref HEAD | sed 's|.*/||' | sed 's/^[A-Z][A-Z]*-[0-9]*-//'
保留 ticket id 的大小寫。
使用此結構：
# <TICKET-ID> Spec
## 背景
## 目標
## 非目標
## 目前行為
## 目標行為
## 修正策略
## 影響範圍
### Affected Files / Modules
## Acceptance Criteria
## Test Plan
### Automated
### Manual
## Regression Risk
## Open Questions
偏好簡短、具體的條列。
偏好的輸出：
Spec：建立或更新的路徑依據：issue 文件路徑與已檢視的程式碼脈絡修正方向：簡短摘要測試重點阻塞：僅當 open questions 阻塞實作時Next：只有在沒有阻塞性問題殘留時，實作才能開始zh-twen-us 技術術語，例如 Acceptance Criteria、Test Plan、API、UI、Widget、Bloc