ワンクリックでManusで任意のスキルを実行

issue-spec-prep

スター16

フォーク2

更新日2026年6月14日 16:16

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

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

Yomiamy

Yomiamy/flutter_inspector_kit

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Issue Spec Prep

在 branch-ticket-issue-doc 之後使用此 skill。

目標：從 issue 文件與當前 worktree 程式碼脈絡，建立或更新 docs/issues/specs/<ticket-id>.md。

不要在此變更產品程式碼。不要在此執行實作重構。

前置條件

確認當前目錄是 ticket-id-dev-prep 選定的開發工作區。
從使用者輸入、branch 名稱或既有 issue docs 解析 ticket id。
先讀取 docs/issues/<ticket-id>.md。
若 issue doc 缺少，停止並先執行 branch-ticket-issue-doc。
若 docs/issues/specs/ 不存在則建立。

工作流程

讀取 docs/issues/<ticket-id>.md。
擷取：
- 問題陳述
- 預期與實際行為
- 受影響的流程
- 已知事實、推論與未解問題
只檢視足以讓 spec 可執行的程式碼：
- 可能的檔案或模組
- 當前邏輯邊界
- 既有 tests 或缺漏的測試面
- 共用工具或重複的流程

agy 優先策略：收集完 issue doc 內容與程式碼觀察後，優先委派 antigravity-cli（agy）生成 spec 文件本文：

透過 Bash 以 stdin 管道委派（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。

（Fallback）自行依照 Spec Template 撰寫並 create or update docs/issues/specs/<ticket-id>.md。
讓 acceptance criteria 可測試。
讓 open questions 保持可見；不要把未知項目轉成需求。
在實作前停止。

檔案命名

使用：

docs/issues/specs/<TICKET-ID>-<description-suffix>.md

其中 <description-suffix> 取自當前 branch 名稱的最後一段路徑，並移除開頭的 ticket id 部分。

範例：

Branch：fix/202605/BUG-2362-some-feature-fix
最後一段：BUG-2362-some-feature-fix
Description suffix：some-feature-fix
檔案：docs/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 的大小寫。

Spec Template

使用此結構：

# <TICKET-ID> Spec

## 背景

## 目標

## 非目標

## 目前行為

## 目標行為

## 修正策略

## 影響範圍

### Affected Files / Modules

## Acceptance Criteria

## Test Plan

### Automated

### Manual

## Regression Risk

## Open Questions

偏好簡短、具體的條列。

Spec 規則

需求以 issue doc 為依據。
用程式碼檢視來提升可行性，而非發明產品意圖。
僅在已檢視或有強烈跡象時才提及確切檔案。
acceptance criteria 必須描述可觀察的行為。
test plan 應指明可能的 unit、widget、bloc、integration 或 manual 檢查。
若某個 open question 阻塞實作，清楚說明。

輸出規則

偏好的輸出：

Spec：建立或更新的路徑
依據：issue doc 路徑與已檢視的程式碼脈絡
修正方向：簡短摘要
測試重點
阻塞：僅在 open questions 阻塞實作時
Next：唯有不存在阻塞性問題時，才能開始實作

風格規則

主要語言：zh-tw
保留必要的 en-us 技術術語，例如 Acceptance Criteria、Test Plan、API、UI、Widget、Bloc
精簡且以 spec 為導向

このリポジトリの他の Skills

同じリポジトリ

gen-dev-workflow

Yomiamy/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

2026-07-2216

gen-commit

Yomiamy/flutter_inspector_kit

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

2026-07-2216

gen-update-publish-info

Yomiamy/flutter_inspector_kit

當使用者要為已合入 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」。

2026-07-1716

gen-pr-reply

Yomiamy/flutter_inspector_kit

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

2026-07-1716

issue-id-dev-prep

Yomiamy/flutter_inspector_kit

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

2026-07-1016

worktree-close-cleanup

Yomiamy/flutter_inspector_kit

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

2026-07-0216

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 doc，僅在需要時檢視程式碼，且不進行程式碼實作變更。

Issue Spec Prep

在 branch-ticket-issue-doc 之後使用此 skill。

目標：從 issue 文件與當前 worktree 程式碼脈絡，建立或更新 docs/issues/specs/<ticket-id>.md。

不要在此變更產品程式碼。不要在此執行實作重構。

前置條件

確認當前目錄是 ticket-id-dev-prep 選定的開發工作區。
從使用者輸入、branch 名稱或既有 issue docs 解析 ticket id。
先讀取 docs/issues/<ticket-id>.md。
若 issue doc 缺少，停止並先執行 branch-ticket-issue-doc。
若 docs/issues/specs/ 不存在則建立。

工作流程

讀取 docs/issues/<ticket-id>.md。
擷取：
- 問題陳述
- 預期與實際行為
- 受影響的流程
- 已知事實、推論與未解問題
只檢視足以讓 spec 可執行的程式碼：
- 可能的檔案或模組
- 當前邏輯邊界
- 既有 tests 或缺漏的測試面
- 共用工具或重複的流程

agy 優先策略：收集完 issue doc 內容與程式碼觀察後，優先委派 antigravity-cli（agy）生成 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。

（Fallback）自行依照 Spec Template 撰寫並 create or update docs/issues/specs/<ticket-id>.md。
讓 acceptance criteria 可測試。
讓 open questions 保持可見；不要把未知項目轉成需求。
在實作前停止。

檔案命名

使用：

docs/issues/specs/<TICKET-ID>-<description-suffix>.md

其中 <description-suffix> 取自當前 branch 名稱的最後一段路徑，並移除開頭的 ticket id 部分。

範例：

Branch：fix/202605/BUG-2362-some-feature-fix
最後一段：BUG-2362-some-feature-fix
Description suffix：some-feature-fix
檔案：docs/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 的大小寫。

Spec Template

使用此結構：

# <TICKET-ID> Spec

## 背景

## 目標

## 非目標

## 目前行為

## 目標行為

## 修正策略

## 影響範圍

### Affected Files / Modules

## Acceptance Criteria

## Test Plan

### Automated

### Manual

## Regression Risk

## Open Questions

偏好簡短、具體的條列。

Spec 規則

需求以 issue doc 為依據。
用程式碼檢視來提升可行性，而非發明產品意圖。
僅在已檢視或有強烈跡象時才提及確切檔案。
acceptance criteria 必須描述可觀察的行為。
test plan 應指明可能的 unit、widget、bloc、integration 或 manual 檢查。
若某個 open question 阻塞實作，清楚說明。

輸出規則

偏好的輸出：

Spec：建立或更新的路徑
依據：issue doc 路徑與已檢視的程式碼脈絡
修正方向：簡短摘要
測試重點
阻塞：僅在 open questions 阻塞實作時
Next：唯有不存在阻塞性問題時，才能開始實作

風格規則

主要語言：zh-tw
保留必要的 en-us 技術術語，例如 Acceptance Criteria、Test Plan、API、UI、Widget、Bloc
精簡且以 spec 為導向