Azure DevOps 工作項目啟動器

啟動工作項目

將貼上的 ADO 票證轉換為：一個新的（或正確復用的）分支、一份可讓後續工作階段繼續進行的上下文記憶、紮根於程式碼庫的探索，以及根因分析或功能佈局。它停在一個檢查點——呈現發現並等待。此技能不會撰寫任何修復或功能程式碼；使用者先核准方向，因為一個快速出貨但錯誤的 RCA 會耗掉完整的 QA 來回成本。

0. 載入本機設定

在解析票證之前，先讀取此技能資料夾中的 config.local.md。它承載了此技能刻意不寫死的名詞：分支前綴、基礎分支、專案的分層文件、調查存放位置、程式碼索引盲點，以及值得指出的過去記憶。探索品質取決於這些細節，所以不要跳過。

如果該檔案不存在（全新安裝），請推斷你能得到的資訊——從 git remote show origin 推斷基礎分支（HEAD 分支），從使用者的現有分支推斷前綴（git branch --list "*/*"）——告知使用者你推斷的內容，並提議將其儲存為 config.local.md（請參閱 config.example.md）。

記憶目錄是你的系統提示中為此專案指定的目錄；程式碼庫就是你正在工作的那個。這兩者都不需要設定。

1. 解析票證

從貼上的內容中提取資訊。ADO 的頁面複製貼上通常很雜亂：第一行是大寫的類型與 ID（USER STORY 12345、BUG 12346），每個欄位標籤單獨一行，下一行是值（State / Dev In Progress），標籤以裸行形式出現在頂部附近，還有一些 UI 裝飾需要忽略（Save、Follow、Click to add …、switch to HTML editor、空的 TestRail 區段）。圖片和附件無法透過貼上保留下來。

• ID（數字）與工作項目類型——Bug 與 User Story / Feature / PBI / Task。如果未明確說明類型，請推斷它（重現步驟 + 預期/實際結果 ⇒ bug；「As a … I want」或驗收標準 ⇒ feature）並說明你推斷的依據。
• 標題、狀態、區域/路徑（如有）
• Bug：重現步驟、預期與實際結果、組建編號、平台/裝置/作業系統、深層連結、提到的附加日誌名稱、螢幕截圖
• Feature：描述、驗收標準、連結的設計稿、功能旗標/實驗名稱
• 討論/留言：先前的嘗試、QA 備註及其日期、PR 編號

如果沒有 ID，請在建立任何東西之前要求提供——ID 用於分支和記憶名稱。記下任何被提及但不可見的內容（螢幕截圖、日誌），以便你可以在檢查點要求提供，而不是猜測其內容。

2. 分支

在你正在工作的程式碼庫中執行 git（如果工作階段位於工作目錄或另一個克隆中，請使用那個——永遠不要 cd 離開它）：

git status --porcelain

如果工作目錄是髒的，請停止。 列出檔案和目前分支，並詢問如何處理（攜帶、暫存或提交到舊分支）。一個項目的未提交檔案會洩漏到下一個項目的提交中；由使用者決定，而不是你。

當工作目錄乾淨時：

git fetch origin
git branch --list "<prefix>/<id>*"; git branch -r --list "origin/<prefix>/<id>*"

如果該 ID 沒有分支存在，則從 origin/<base> 建立 <prefix>/<id> 並記錄短 SHA（git rev-parse --short HEAD）。

如果 <prefix>/<id> 或 <prefix>/<id>-N 已存在（本地或遠端），請先查看最新的那個，再決定——同一個 ID 可能在三種非常不同的時刻出現：

git log --oneline origin/<base>..<prefix>/<id>[-N]   # 未合併的提交？
git log --oneline origin/<base> --grep=<id>           # "Merged PR NNNN: ... <id>" = 已合併

ADO 使用壓縮合併，所以一個已合併的分支仍然會顯示其提交「領先」於基礎分支——基礎分支上的 Merged PR 行才是告訴你它已合併的資訊。請將它與票證的狀態以及最新 QA 留言的日期與分支最後一次提交的日期一起解讀。

最新的現存分支	典型票證狀態	該怎麼做
沒有超出 origin/<base> 的提交（通常就是您目前所在的分支——使用者在貼上之前已建立它）	新增 / 開發進行中	復用它。 檢出它，然後執行 git merge --ff-only origin/<base>。
已合併（基礎分支上有一個針對此 ID 的 Merged PR）且 QA 之後已使其失敗	作用中/重新開啟，失敗的 QA 留言日期晚於合併日期	建立下一個後綴（-1、-2、…）從 origin/<base>；先前的嘗試成為主要的探索素材。
未合併的提交（已推送或未推送），或 PR 仍開啟	PR 審查 / 待測試 / 進行中	處理中——不要建立分支。 報告分支上的內容（提交、是否已推送、落後基礎分支多遠），使其成為探索的主題，並詢問是否要繼續或開始新的嘗試。

如果訊號不一致（例如狀態顯示「新增」，但有一個未合併的分支），請將其視為處理中並詢問——建立重複的分支是代價高昂的錯誤。如果 git fetch 失敗（VPN / 驗證），請說明原因，並使用本機的 origin/<base>，同時註明基礎分支可能是過時的。

不要推送也不要提交——使用者尚未要求。

3. 上下文記憶（現在寫入，稍後更新）

在探索之前寫入記憶，狀態為 ⏳，這樣即使工作階段在調查過程中意外中斷，該項目也是可繼續的。使用 references/memory-template.md。

• Bug → bug-<id>-context.md，feature/story/task → feature-<id>-context.md
• 如果此 ID 已存在記憶檔案，請更新它而不是建立第二個——並修正其中任何與 git 狀態現在相矛盾的內容。
• 在 MEMORY.md 中添加一行指標。沒有它，後續的工作階段永遠找不到此記憶。

4. 程式碼庫探索

目標是找到票證所觸及的實際程式碼路徑以及相關的歷史——足夠讓 RCA/佈局引用 file:line，而不是猜測。

• 使用程式碼索引（如果有的話）（CodeGraph、LSP）：從對票證名詞（頁面、控制項、服務、DTO）的上下文查詢開始，然後對其呈現的結果執行一次探索呼叫；對可疑符號的呼叫者/影響進行檢查。檢查設定檔中索引的盲點（它無法解析的檔案類型）並改用 grep 搜尋這些檔案。
• 路由和 UI 名稱：頁面路由、元件名稱、CSS 類別以及票證中的深層連結方案是很好的 grep 搜尋詞。
• 先前的工作：git log --oneline --all --grep=<id>、git log --oneline -20 -- <可疑檔案>、專案的 docs/investigations 資料夾（設定檔）以及記憶目錄中關於相同區域的說明文件。一個針對相同症狀但 QA 失敗的早期修復是你所能找到的最有價值的東西。
• 比較通過和失敗的情況。 當 QA 列出通過的案例和一個失敗的案例時，在確定機制之前，先找出程式碼中兩者實際上的不同之處——主機頁面、資料路徑、時機。
• 每個頭端/平台：如果 UI 跨多個主機（手機殼層、網頁）共用，請檢查票證是否特定於某個平台，以及程式碼是否也是如此。
• 在探索期間不要進行建置。 在這裡閱讀程式碼就夠了；建置很慢且屬於實作階段。

對於跨多個資料夾的廣泛搜尋，使用 Explore 子代理程式是可行的；對於已知區域，直接執行。

5a. Bug → 根因分析

如果 superpowers:systematic-debugging 技能可用，請使用其方法。標準是可測量的，而非猜測的：命名機制和確切的 file:line，並解釋為什麼它會恰好產生報告的症狀，而不是其他症狀（為什麼失敗的案例會失敗，而通過的案例會通過）。

• 追蹤從重現步驟中的使用者操作到錯誤狀態的路徑。引用相關的行。
• 在可行的情況下無需裝置即可重現：用於狀態/標記的元件測試、用於版面/滾動/CSS 問題的無頭瀏覽器靜態複製品（設定檔可能指向描述現有測試工具的記憶）。如果你無法重現，請坦率說明，陳述你的信心程度，以及哪些證據可以確認它（例如來自 QA 的特定日誌行或螢幕截圖）。
• 將根因與促成因素以及屬於其他票證的相鄰問題分開。
• 提出一個修復方向（或 2–3 個選項並附帶建議）以及能夠鎖定它的迴歸測試——但還不要撰寫它們。
• 處理中的項目（步驟 2）：RCA 變成對分支上已有修復的審查——它是否解決了最新的 QA 失敗？還有哪些殘留風險會使其在裝置上失敗？建議繼續使用它，並說明哪個 QA 結果足以證明新的嘗試是合理的。

5b. Feature → 佈局與詳細說明

如果 superpowers:brainstorming 技能可用，請將其用於設計對話。

首先判斷驗收標準是否足夠。當以下條件成立時，它們就是足夠的：

• 每個 AC 都可以轉換為具體的測試斷言並對應到一個要修改的檔案，並且
• UI 狀態（載入中、空白、錯誤、停用）、每個平台的行為、分析事件和功能旗標都已指定或明顯不適用。

如果它們足夠，不要為了問而問——直接佈局功能。如果它們不足，則需要詳細說明：只問關於缺口的部分，集中在一個 AskUserQuestion 中（最多 4 個問題，具體選項，先給一個推薦的預設值）。對模糊的 AC 進行猜測會產生返工。

在提問之前先對每個缺口進行分類：如果答案會改變設計（顯示什麼、資料從哪裡來、使用者點擊時看到什麼），那就是一個問題。如果有些事有顯然的慣例——功能旗標鍵、分析事件名稱、DI 註冊——選擇慣用的值，在佈局中將其寫為假定：，以便使用者可以一目了然地修正它，然後不要問。這批 4 個問題就是全部；不要在其後添加「另外，請確認…」的尾巴，因為那只是更多沒有選項的問題。

佈局包含：

• 要新增/修改的檔案，根據專案的分層放置（設定檔指向定義分層的文件），包括每個主機中的 DI 註冊
• 資料流：資料來自哪裡，哪個服務擁有狀態，它如何到達元件
• AC → 測試對應，為每個測試專案命名
• 平台差異、分析/旗標、風險與未解決問題

6. 檢查點

使用你的發現更新記憶檔案（狀態 🔄、根因摘要或功能佈局摘要、未解決問題），然後呈現給使用者：

Bug：

## Bug <id>: <title>
分支：<prefix>/<id> (from origin/<base> @ <sha>)   — 或：處理中於 <branch>，無新分支
記憶：bug-<id>-context.md

### 根因
<機制、file:line、為何符合症狀> — 信心程度：<高/中/低 + 什麼可以提高>

### 證據
<程式碼引用、重現結果、歷史：先前的 PR/嘗試>

### 建議修復
<方向或選項 + 建議；要新增的迴歸測試；要修改的檔案>

### 需要您提供
<缺少的螢幕截圖/日誌、決策>

功能：

## Feature <id>: <title>
分支 / 記憶：...

### AC 的內容 vs. 缺少的內容
### 提建議的佈局（檔案、資料流、AC → 測試、每個平台、假定：…）
### 問題  （或「無——AC 已足夠」）

然後停止並等待核准。如果 RCA 或佈局涉及 5 個以上檔案或變更架構，請提議將其寫入專案的 docs/investigations 資料夾（設定檔）——提議，不要自動建立。