設計產品行銷網站
建立一個網站，其內容、視覺選擇和互動方式能解釋這個特定產品。支援 SaaS、微 SaaS、服務、工具和其他產品，而不強制使用特定框架、固定頁面數量或 SaaS 視覺範本。
確定實際任務
在修改任何內容之前，先閱讀使用者的請求、儲存庫說明、已核准的產品定義（例如 project.md）和現有的行銷網站。如果沒有產品定義，請從授權來源確定目標受眾、產品價值、可用功能和網站目標；僅針對缺少重大決策的部分提出問題。確定任務是屬於簡報、編碼代理實作、外部建置工具交接，還是範圍內的更新。保留現有的產品決策、架構和授權範圍。對於一般的網站編輯，不要重新開始探索。
已核准的產品定義擁有產品事實、範圍、商業決策和就緒狀態的所有權；保留其現有名稱和位置。一個獨立的 marketing-site-brief.md 則負責網站的資訊架構、內容/設計要求、互動方式和可發現性計畫；在產品定義（例如 project.md）中引用它。不要複製整個產品定義或建立另一個競爭的產品事實來源。現有的規格文件仍負責其實作工作。
檢查實際的框架、路由、渲染、元件、依賴項和託管限制。對於新網站，根據內容、渲染/索引需求、整合、可維護性和團隊限制，推薦一個相容的做法。解釋重要的取捨，而不是自動選擇最新的框架。設計技能是工作指南，不是框架或執行時期依賴項；SaaS 是產品模式，而 Sass 是樣式工具。
產出可轉移的設計簡報
在建立簡報時，使用 英文簡報範本 或 阿拉伯文範本；根據專案調整各章節，而不是用虛構的事實填滿它們。識別會阻礙有用工作的未知事項，並針對非阻塞性的細節，繼續使用已宣告的假設。
為每個建議的頁面提供一個明確的訪客問題、有用的內容和下一個動作。合併內容薄弱或重複的頁面。包含頁面文案、公開功能就緒狀態、證據限制、導覽、內部連結、預覽標籤、表單行為、響應式/RTL 要求、無障礙性、元資料、JSON-LD 適用性、效能和驗收檢查。多頁面網站應具有有意義的路由和內容，而不是只有一個重新命名的錨點或多個幾乎相同的關鍵字頁面。
定義一個可識別的視覺方向：目標受眾和個性、參考原則、字體排印、色彩/間距代碼、構圖、素材、動態效果和有意的限制。避免對每個產品都套用相同的英雄區塊/卡片/漸層/儀表板公式。不要複製其他產品的品牌或偽造客戶證明。包含推理過程，以便其他工具能連貫地執行設計。
在選擇框架、可選設計技能或建置工具時，請閱讀 設計工具選擇。在調用設計技能之前，先檢查可用的設計技能。為任務選擇最小且有用的組合，解釋重疊部分，並保留其實際的宿主相容性。不要假設一個命名技能已安裝。可選的外部技能可能改善藝術指導或審查，但此工作流程在沒有它們的情況下仍然有效。不要僅僅因為其名稱出現在簡報中，就下載、安裝或執行第三方套件。如果一個可選技能建立了諸如 PRODUCT.md 或 DESIGN.md 之類的檔案，請明確將其映射為在已核准參考下的衍生工具輸出或工作設計筆記；不要默默地引入競爭的產品/行銷權威。在啟動啟動器、初始化程式、鉤子或支援網路的輔助工具之前，請先檢查目前的進入點和相容性；不要假設設計技能僅限於 Markdown。
直接建置或交接相同的簡報
- 編碼代理路線： 按照現有的專案慣例實作已核准的網站簡報。建立共享的基礎、具代表性的頁面和功能導覽，然後再完成其他頁面和狀態。當現有的設計系統是產品識別的一部分時，請使用它；除非有基於任務的理由，否則不要取代它。
- 外部建置工具路線，例如 Lovable： 使用該工具實際支援的輸入，提供相同的已清理簡報和必要的素材。提供一個範圍有限的指令，以保留產品事實，並區分實際的互動和預覽。工具無法僅因為其名稱被提及就讀取本機檔案。在承諾特定的匯入/匯出、框架或同步行為之前，請先驗證目前的文件。在合併之前，檢查收到的程式碼和整合要求；不要透過假設來覆寫應用程式或移動其後端。
對於任一路線，都要審查實際產生的結果，並在有限的迭代中修正觀察到的問題。不要預先編寫工具的回答，或從其完成訊息中聲稱成功。批准簡報並不意味著發佈、花費、佈建服務或安裝所選工作流程以外的依賴項。任務已授權的常規可逆編輯不需要重複批准。
驗證行為和可發現性
使用 接受度指南 進行實作和最終審查。測試實際的路由和關鍵操作、相關的阿拉伯文/拉丁文方向、行動裝置/桌上型電腦版面、鍵盤使用、有意義的載入/錯誤/成功狀態以及面向生產環境的元資料。區分前端示範和實際儲存提交。在聲稱實際註冊之前，先驗證真實紀錄，並將私人資料與索引控制項分開保護。
選擇適合可見頁面和目前搜尋資格的結構化資料。不要為了填滿 schema 而虛構評論、價格、組織、可用性或評分。驗證語法和適用的搜尋要求；有效的 JSON-LD 並不保證豐富結果或排名。不要將 llms.txt、框架選擇或自動化 SEO 評分視為可見性保證。
報告實際執行的檢查、環境/版本、觀察到的失敗和未測試的區域。螢幕截圖證明了該視口的外觀，而不是功能儲存、生產索引或現場效能。
強制性最終審查
在聲稱簡報、交接或網站完成之前，請針對請求的模式執行 最終審查。將實際的訪客體驗或可轉移的簡報與接受的範圍和參考方向進行比較。修正發現的問題並重新檢查受影響的輸出、記錄簡潔的證據並揭露遺漏的檢查。僅憑檔案存在、產生的螢幕截圖和綠燈建置並不能建立一個有用的網站。
保持產品和網站一致
當任務包含持續維護時，請根據專案的實際路徑調整 英文 AGENTS 片段 或 阿拉伯文片段。對於已核准的產品變更，請檢查影響圖，並在授權的儲存庫工作中更新受影響的網站內容、導覽、元資料、結構化資料和測試。準確標記已規劃和已交付的功能；已實作的功能不會自動向每位訪客發佈。
如果產品事實、商業條款或外部依賴項未解決，請標記該決策，而不是默默地發明它。如果網站位於其他地方，請確定確切需要進行的後續工作，而不是聲稱它已更改。將儲存庫編輯與部署和公開發佈區分開來。