원클릭으로 Manus에서 모든 스킬 실행

branch-ticket-issue-doc

스타0

포크0

업데이트2026년 6월 17일 14:37

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

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

Yomiamy

Yomiamy/AI-Chat

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Branch Ticket Issue Doc

在 ticket-id-dev-prep 選定的開發工作區中使用此 skill。

目標：建立或更新 docs/issues/<ticket-id>.md，作為該 branch 的正規問題文件。

不要在此建立 specs。不要在此變更產品程式碼。

前置條件

確認當前目錄是預期的開發工作區。
確認當前 branch 含 ticket id，或使用者明確提供 ticket id。
優先使用來自 branch-ticket-solution-advisor 的已解析 brief。
若無已解析 brief，閱讀 GitHub issue，並僅檢視足以記錄問題的程式碼脈絡。
若 docs/issues/ 不存在則建立。

若 ticket-id-dev-prep 選定了不同的工作區，在寫入前切換過去。若選定策略為 current-branch 或 current-worktree-new-branch，則允許在當前工作區寫入。

工作流程

解析 ticket id。
若存在則讀取既有的 docs/issues/<ticket-id>.md。
若存在則讀取 docs/issues/template.md，並保留本地文件風格。
蒐集來源素材：
- advisor 已解析的 brief
- GitHub issue 標題與描述
- 相關欄位，例如 State、Type、Priority、Subsystem
- 透過針對性檢視得到的當前 worktree 程式碼觀察

agy 優先策略：收集完所有資料後，優先委派 antigravity-cli（agy）生成 issue doc 本文：

透過 Bash 以 stdin 管道委派（printf '%s' "<填入下方 prompt>" | agy -p --print-timeout 180s），prompt 如下（以實際資料填入；務必在結尾要求「只輸出文件本文，不要任何開場白或人設評論」）：

你是一位資深 Flutter 工程師，請根據以下 ticket 資料與程式碼觀察，用繁體中文撰寫一份問題文件（保留英文技術術語與 issue key）。

Ticket: <ticket-id> - <ticket summary>
State: <state>
Type: <type>
Priority: <priority>

Ticket 描述摘要：
<ticket description 摘要>

Advisor 解析摘要（如有）：
<branch-ticket-solution-advisor parsed brief，若無則填「無」>

程式碼觀察（已檢視的相關模組、邏輯路徑）：
<Claude 的 rg / file read 觀察摘要>

請嚴格按照以下 markdown 結構輸出：

# <TICKET-ID> <title>

## Issue

- URL:
- State:
- Type:
- Priority:

## 問題描述

## 影響範圍

## 重現步驟

1.

## 預期結果

## 實際結果

## 環境

- App 版本：
- 裝置：
- OS 版本：
- 測試帳號：

## 程式碼現況

## 已知事實

## 推論

## 待確認

## 截圖 / 錄影

## 備註

規則：
- 不要發明 ticket 中未提及的資訊
- 無法確認的項目一律填入「待確認」
- 保留原始錯誤訊息、欄位名稱、使用者可見字串
- 若程式碼觀察與 ticket 敘述有矛盾，在「備註」中記錄不一致之處
只輸出文件內容，不要其他說明。

若 agy 成功回傳包含 ## 問題描述 與 ## 已知事實 的結構，採用其內容。
後處理（必做）：agy 會讀取全域 CLAUDE.md 而附加 Linus 人設框架，且可能在生成時順手建立暫存檔。採用前須剝除人設包裝、只取目標 markdown 結構；並確認 agy 未在工作區誤建檔案（如有則刪除）。docs/issues/<ticket-id>.md 一律由 Claude 自行 Write 寫入，不依賴 agy 落檔。
若 agy 不在 PATH、呼叫失敗或回傳格式不合法，回退至步驟 6 自行撰寫 issue doc。

（Fallback）自行依照 Issue Doc Template write or update docs/issues/<ticket-id>.md。
區分事實、推論與未解問題。
讓 issue doc 聚焦於問題與當前行為。
除了簡短的程式碼脈絡觀察外，不要加入實作策略。

檔案命名

使用：

docs/issues/<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/BUG-2362-some-feature-fix.md

以下列指令解析 suffix：

git rev-parse --abbrev-ref HEAD | sed 's|.*/||' | sed -E 's/^([A-Z][A-Z0-9]*-)?[0-9]+-//'

保留 ticket id 的大小寫。

Issue Doc Template

除非本地 template 要求更貼合的格式，否則使用此結構：

# <TICKET-ID> <title>

## Issue

- URL:
- State:
- Type:
- Priority:

## 問題描述

## 影響範圍

## 重現步驟

1.

## 預期結果

## 實際結果

## 環境

- App 版本：
- 裝置：
- OS 版本：
- 測試帳號：

## 程式碼現況

## 已知事實

## 推論

## 待確認

## 截圖 / 錄影

## 備註

僅在章節確實不適用時才省略空白章節。寧可填 待確認，也不要發明細節。

品質規則

問題文件必須不需讀完整 ticket 就能理解。
不要逐字複製冗長的 ticket 文字。
相關時保留確切的錯誤訊息、標籤、欄位名稱與使用者可見字串。
明確註記缺漏的重現資料。
若程式碼脈絡與 ticket 矛盾，記錄此不一致。

輸出規則

偏好的輸出：

Issue Doc：建立或更新的路徑
來源：advisor brief、GitHub issue、程式碼檢視
重點：一段簡短的問題摘要
待確認：僅在存在時
Next：執行 issue-spec-prep

風格規則

主要語言：zh-tw
保留必要的 en-us 技術術語，例如 GitHub、State、API、UI、Backend、QA
精簡且以文件為導向

이 저장소의 다른 Skills

같은 저장소

gen-commit

Yomiamy/AI-Chat

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

2026-07-220

gen-dev-workflow

Yomiamy/AI-Chat

完整開發流程編排器。使用者說「幫我做 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-220

issue-dev-workspace-prep

Yomiamy/AI-Chat

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

2026-06-170

branch-diff-code-review

Yomiamy/AI-Chat

當使用者想對當前分支自其 base 分支分岔以來的所有變更做一般性程式碼審查、且不將審查範圍預設為 origin/main 時，使用此 skill。它應判定分支的 fork point、檢視完整的 branch diff、優先處理 bug 與回歸風險，並以 zh-tw 呈現審查結果，同時遵循 repository 的 .gemini/styleguide.md 程式碼審查人設與結尾儀式。

2026-06-140

code-review-commons

Yomiamy/AI-Chat

執行高品質程式碼審查時的共通準則、人設與關鍵限制。在執行 /code-review 或 /pr-code-review 指令時使用此 skill。

2026-06-140

issue-spec-prep

Yomiamy/AI-Chat

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

2026-06-140

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

Branch Ticket Issue Doc

在 ticket-id-dev-prep 選定的開發工作區中使用此 skill。

目標：建立或更新 docs/issues/<ticket-id>.md，作為該 branch 的正規問題文件。

不要在此建立 specs。不要在此變更產品程式碼。

前置條件

確認當前目錄是預期的開發工作區。
確認當前 branch 含 ticket id，或使用者明確提供 ticket id。
優先使用來自 branch-ticket-solution-advisor 的已解析 brief。
若無已解析 brief，閱讀 GitHub issue，並僅檢視足以記錄問題的程式碼脈絡。
若 docs/issues/ 不存在則建立。

若 ticket-id-dev-prep 選定了不同的工作區，在寫入前切換過去。若選定策略為 current-branch 或 current-worktree-new-branch，則允許在當前工作區寫入。

工作流程

解析 ticket id。
若存在則讀取既有的 docs/issues/<ticket-id>.md。
若存在則讀取 docs/issues/template.md，並保留本地文件風格。
蒐集來源素材：
- advisor 已解析的 brief
- GitHub issue 標題與描述
- 相關欄位，例如 State、Type、Priority、Subsystem
- 透過針對性檢視得到的當前 worktree 程式碼觀察

agy 優先策略：收集完所有資料後，優先委派 antigravity-cli（agy）生成 issue doc 本文：

你是一位資深 Flutter 工程師，請根據以下 ticket 資料與程式碼觀察，用繁體中文撰寫一份問題文件（保留英文技術術語與 issue key）。

Ticket: <ticket-id> - <ticket summary>
State: <state>
Type: <type>
Priority: <priority>

Ticket 描述摘要：
<ticket description 摘要>

Advisor 解析摘要（如有）：
<branch-ticket-solution-advisor parsed brief，若無則填「無」>

程式碼觀察（已檢視的相關模組、邏輯路徑）：
<Claude 的 rg / file read 觀察摘要>

請嚴格按照以下 markdown 結構輸出：

# <TICKET-ID> <title>

## Issue

- URL:
- State:
- Type:
- Priority:

## 問題描述

## 影響範圍

## 重現步驟

1.

## 預期結果

## 實際結果

## 環境

- App 版本：
- 裝置：
- OS 版本：
- 測試帳號：

## 程式碼現況

## 已知事實

## 推論

## 待確認

## 截圖 / 錄影

## 備註

規則：
- 不要發明 ticket 中未提及的資訊
- 無法確認的項目一律填入「待確認」
- 保留原始錯誤訊息、欄位名稱、使用者可見字串
- 若程式碼觀察與 ticket 敘述有矛盾，在「備註」中記錄不一致之處
只輸出文件內容，不要其他說明。

若 agy 成功回傳包含 ## 問題描述 與 ## 已知事實 的結構，採用其內容。
後處理（必做）：agy 會讀取全域 CLAUDE.md 而附加 Linus 人設框架，且可能在生成時順手建立暫存檔。採用前須剝除人設包裝、只取目標 markdown 結構；並確認 agy 未在工作區誤建檔案（如有則刪除）。docs/issues/<ticket-id>.md 一律由 Claude 自行 Write 寫入，不依賴 agy 落檔。
若 agy 不在 PATH、呼叫失敗或回傳格式不合法，回退至步驟 6 自行撰寫 issue doc。

（Fallback）自行依照 Issue Doc Template write or update docs/issues/<ticket-id>.md。
區分事實、推論與未解問題。
讓 issue doc 聚焦於問題與當前行為。
除了簡短的程式碼脈絡觀察外，不要加入實作策略。

檔案命名

使用：

docs/issues/<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/BUG-2362-some-feature-fix.md

以下列指令解析 suffix：

git rev-parse --abbrev-ref HEAD | sed 's|.*/||' | sed -E 's/^([A-Z][A-Z0-9]*-)?[0-9]+-//'

保留 ticket id 的大小寫。

Issue Doc Template

除非本地 template 要求更貼合的格式，否則使用此結構：

# <TICKET-ID> <title>

## Issue

- URL:
- State:
- Type:
- Priority:

## 問題描述

## 影響範圍

## 重現步驟

1.

## 預期結果

## 實際結果

## 環境

- App 版本：
- 裝置：
- OS 版本：
- 測試帳號：

## 程式碼現況

## 已知事實

## 推論

## 待確認

## 截圖 / 錄影

## 備註

僅在章節確實不適用時才省略空白章節。寧可填 待確認，也不要發明細節。

品質規則

問題文件必須不需讀完整 ticket 就能理解。
不要逐字複製冗長的 ticket 文字。
相關時保留確切的錯誤訊息、標籤、欄位名稱與使用者可見字串。
明確註記缺漏的重現資料。
若程式碼脈絡與 ticket 矛盾，記錄此不一致。

輸出規則

偏好的輸出：

Issue Doc：建立或更新的路徑
來源：advisor brief、GitHub issue、程式碼檢視
重點：一段簡短的問題摘要
待確認：僅在存在時
Next：執行 issue-spec-prep

風格規則

主要語言：zh-tw
保留必要的 en-us 技術術語，例如 GitHub、State、API、UI、Backend、QA
精簡且以文件為導向