競爭產品重新設計是做什麼的？

如果 LOCAL.md 檔案與此 SKILL.md 相鄰，請先閱讀它——它包含此工作區的具體細節（路徑、工具、範例）並會覆蓋下方的通用預設值。

研究 → 決策 → 設計。平行子 agent 截取「我們的功能」以及 2-3 個競爭對手的產品畫面，研究結果會變成一份差距分析報告，並附上批次決策供使用者選擇。選定的方向會轉化為一個設計畫布：當前 UI 截圖與重新設計的圖板並排顯示，並標記所有差異。產出結果是「決策 + 設計」（+ 可選的實作計劃）——此技能不會撰寫任何產品程式碼。

下方提到的「參考運行」是此技能的首次實際運行（錄音庫重新設計）；當 LOCAL.md 存在時，它會指向該次運行。這僅是一個可行的範例——它證明了流程形狀並校準了深度；請勿將其用於新功能的內容。

第一階段——平行研究（使用較便宜模型的子 agent，最多同時 3 個）

在一則訊息中啟動最多 3 個子 agent——使用 Agent 工具、general-purpose、model: "sonnet"（較便宜的模型對於基礎研究工作已經足夠；切勿超過 3 個同時執行——速率限制會扼殺大量生成）：

我們的——在我們自己的應用程式上截取該功能的畫面。
- 1. 競爭對手——使用者提到的產品優先填補這些位置，每個 agent 負責一個。剩餘的位置（使用者提到 0 或 1 個）：由一個「調查」agent 負責，它會挑選 2-3 個在相關功能領域擁有最豐富公開文件的競爭對手。使用者提到 3 個以上：將主要的那個交給一個 agent，其餘的作為一個批次交給另一個 agent。

在它們執行的同時，請在主執行緒上深入了解我們的程式碼庫：該功能的 schema、讀取/操作層以及頁面。建議必須對應到真實的欄位（「project 標籤存在，但 UI 從未顯示它」）——未經程式碼基礎的競爭對手研究只會產出無人能建置的願望清單。

子 agent 的任務簡報——遺漏時會出錯的部分：

僅使用 Playwright MCP，絕對不要用 Browser 面板——Browser 面板的螢幕截圖無法儲存到磁碟，並且對編排者是不可見的。明確告知 agent：使用 mcp__playwright__playwright_screenshot 搭配 savePng: true 以及 downloadsDir 設定為每個 agent 專用的暫存子目錄（如 ours/、loom/、competitors/），執行 mkdir -p 先建立目錄，並使用 ls 驗證後回報絕對路徑。
並行 agent 共享同一個 Playwright 瀏覽器，並且一定會交叉污染工作階段（一個 agent 可能會截取到另一個 agent 的頁面——參考運行中就發生過）。讓每個 agent 都清楚：在保留截圖前，先視覺確認每張截圖與它剛剛導航到的 URL 相符；如果抓到過時或外部的畫面，請關閉 Playwright 瀏覽器，重新開啟，重新截取。
Playwright chromium 可能缺失（「Executable doesn't exist …」）：從 MCP 的 npx 快取目錄執行 npx playwright install chromium，然後繼續（這是個持續存在的問題，即使在版本更新後也可能發生）。
我們應用程式的登入：提供 agent 確切的步驟——例如一個僅限開發環境的登入表單（在 /login 路徑，使用 email + 密碼），該 email 必須是開發資料庫中「存在的活躍使用者」，密碼則來自開發伺服器的環境變數。在啟動 agent 之前，請親自驗證這兩項（讀取開發伺服器上的 env 值，查詢開發資料庫中的活躍使用者）。參考運行因為使用了不存在於開發資料庫中的 email，導致整個 agent 耗費在 CredentialsSignin 錯誤上。請在應用程式的 AGENTS.md / README 中尋找開發環境的認證路徑。切勿讓 agent 指向正式環境。
競爭對手的產品庫位於登入牆後方——指示 agent 使用幫助中心文章、行銷/功能頁面以及文件（例如 support.loom.com 等），不要嘗試註冊。要求產出一個結構化的功能清單（組織、探索/搜尋、分享、工作流程、AI、管理） + 哪些功能是核心/受歡迎的，哪些是企業版限制的 + 一份「值得借鏡的獨特點子」清單。

第二階段——整合 + 批次決策

為使用者彙整一則訊息：

當前狀態——我們的功能有哪些、缺少哪些，並且要與截圖和程式碼（引用檔案）進行交叉驗證。
競爭對手的做法——每個產品幾行說明，僅限可移植的部分。
分階段的建議——最便宜、槓桿最高的先做：(a) 揭露程式碼已支援但 UI 未顯示的功能，(b) 小型遷移的組織功能，(c) 工作流程功能。包含使用者在提示中提出的原始點子。標記刻意跳過的項目（企業級功能、YAGNI 原則）。
批次多選決策：2-4 個會改變最終成果的分叉點，每個選項以字母標示 + 推薦選擇。不要零散地提出問題。

停下來等待使用者決策。在範圍未決定之前，不要開始設計。

第三階段——選定方向的設計畫布

必備子技能： design 技能（Claude Design 畫布 → Artifact）。它負責畫布的操作機制；此階段新增比較慣例：

當前 UI 截圖作為獨立的圖板（「當前——X」）與重新設計的圖板（「重新設計——X」）並排顯示。在嵌入前，將截圖降取樣至約 70-100 KB 的 JPEG（使用 sips -Z 900 -s format jpeg -s formatOptions 60 …）。
重新設計圖板需符合應用程式真實的設計系統——先讀取 token 檔案和元件，複製精確的值（字型、顏色 token、卡片圓角半徑、按鈕形狀）。
標記每一處差異：使用應用程式強調色繪製虛線外框 + 在每個目前不存在的元素上加上小的「NEW」標籤（對於被修改的元素，使用「CHANGED」標籤變體）。未更改的區域則不加任何裝飾——這種留白正是讓標記清晰可讀的關鍵。
畫布上的便利貼總結每個圖板的差異 + 一個總覽備註。Mockup 中使用範例資料即可；並在交接時說明清楚。
靜態 mockup 是預設的交付成果；僅在使用者要求時才建立可點擊的原型。

第四階段（僅在使用者要求時）——實作計劃

必備子技能： superpowers:writing-plans。將每項任務建立於第一階段的程式碼閱讀基礎上；逐字引用分階段的範圍和決策；最後提供執行模式選項（平行 fan-out / subagent / 內聯），不要在未經提示的情況下開始建置。

陷阱（所有問題都在參考運行中發生過）

症狀	修復方式
Agent 回報已截圖，但編排者看不到檔案	使用了 Browser 面板——重新指示：使用 Playwright MCP 的 `savePng` + `downloadsDir`
螢幕截圖顯示的是與 agent 導航到的不同的網站	共享的 Playwright 工作階段污染——關閉瀏覽器，重新開啟，重新截取，並視覺確認
開發環境登入出現 `CredentialsSignin`	Email 不是開發資料庫中的活躍使用者——查詢開發資料庫，使用一個存在的使用者
「Executable doesn't exist … chromium」	執行 `npx playwright install chromium`（在每個快取目錄中，Playwright 更新後重新執行）
Fan-out 回傳空結果 / 被速率限制	同時執行超過 3 個 agent——分為 ≤3 個一波，重試失敗的部分，大聲回報部分結果
建議與程式碼不符	跳過了第一階段的主執行緒程式碼基礎研究——在整合前先完成它

競爭產品重新設計