應用程式網站
將使用者提供的設計，交付為一個獨立的靜態網站，並包含可重現的 Bun 開發/建置指令以及明確的部署狀態。保留要求的託管提供商。此工作流程源自 AceCut (/data/swi-algo/Swi-App-Factory/Acecut/website) 與 GolfCut；這些專案僅為範例，並非必要依賴項。
建立輸入
讀取適用的 AGENTS.md，並檢查原型、現有網站與部署文件。識別應用程式名稱、目標目錄、正式網域、真實的 App Store URL 以及要求的視覺變更。重複使用現有的品牌與內容。及早檢查檔案系統寫入權限與託管/DNS 驗證；若無法取得部署存取權，則繼續進行本機準備工作。請勿將無法取得的驗證視為部署成功。
準備 Bun 專案
對於新的靜態網站，初始化一個空目錄：
python3 <skill-directory>/scripts/init_site.py <app-directory>/website --slug <app-slug>
cd <app-directory>/website
bun install
捆綁的 starter 包含經過驗證的建置/預覽腳本與 Vercel 配置。在適當情況下保留現有專案的工具。public/ 包含原始碼；scripts/build.mjs 將其複製到 dist/；生產環境不需要 Bun 伺服器。純 HTML/CSS/JS 不需要任何依賴項。若 PATH 中沒有 Bun，請在安裝任何東西之前檢查 ~/.bun/bin/bun。請勿從另一個應用程式複製 .git、.vercel、憑證或身份。
轉換原型
優先使用授權的來源匯出或儲存庫。若僅有公開的靜態原型可用，則擷取 HTML，並遞迴檢查同源的 HTML src/href 與 CSS url() 依賴項，包含功能頁面、圖示、SVG 與腳本。若主機拒絕 Python HTTP 用戶端，則使用 curl 取得。在缺少資源時明顯地失敗；請勿將錯誤主體儲存為圖片。將目錄路由對應到 public/<route>/index.html。
保留資源在本機。從取得的 HTML 中移除託管注入的 Cloudflare 挑戰腳本與僅限預覽的中繼資料，保留應用程式 JS。請勿複製服務憑證或在未經要求的情況下添加分析功能。檢閱外部依賴項，例如 Google Fonts。保留原型的應用程式連結；絕不虛構 App Store ID 或默默地替換另一個應用程式的法律條款。
將正式網址、Open Graph、JSON-LD、robots 與 sitemap 中的原型來源網域，替換為預期的生產環境網域。一致地保留頁面路徑。對於按鈕顏色要求，請檢查渲染後的資源以及 CSS：一個填滿的 SVG 可能隱藏了 CSS 背景。僅變更預期的 SVG 背景路徑，並保留標誌/文字路徑、可存取的名稱與連結目標。
公司頁尾與法律頁面
對於應與 AceCut 對齊的 SWINK 應用程式網站，請使用 © <year> SWINK AI INC.、一個可見的 mailto:[email protected] 聯絡連結，以及可在每個頁面上使用的 /terms 與 /privacy 連結，包含功能頁面與法律頁面本身。保持當前應用程式的品牌與視覺風格。使用根目錄相對的資源與導覽，以便巢狀路由能正常運作；讓法律連結在無 JavaScript 的情況下也可到達。讓頁尾連結在平板電腦上可換行，並使用緊湊的行動裝置版面配置，避免水平溢出。
當使用者要求對齊時，使用被引用應用程式的條款/隱私權結構以及確認的公司/聯絡詳細資料，然後調整應用程式名稱、實際功能、日期、正式網址與交叉連結。請勿盲目轉移另一個應用程式的分析提供商、上傳行為、儲存/保留承諾或設定。檢查可用的產品證據以驗證此類聲明；省略未經確認的細節，而不是虛構它們。將條款與隱私權保持為可讀的獨立頁面，將兩者都加入 sitemap，並在本機工具與 Vercel 中驗證簡潔的 URL。
對於頁尾/法律變更，請在桌面、平板與狹窄手機寬度下檢查所有受影響的頁面；驗證公司文字、mailto 目標、兩個法律連結、可讀的文字、無溢出以及行動導覽。保留要求的下載按鈕顏色。推送後，驗證新的生產部署，並在報告它們上線之前，透過 HTTPS 取得真實的 /terms 與 /privacy。
建置與驗證
bun run build
bun run preview
本機伺服器支援目錄索引路由與 .html 簡潔 URL、GET 與 HEAD 方法，並對缺少的檔案回傳 404。驗證每個頁面與本機資源是否可透過 HTTP 存取；確認 sitemap 與正式網址。檢查桌面與狹窄手機寬度（例如 1440、768、390 與 320）、溢出、已載入的圖片、瀏覽器錯誤、選單、Tab/鍵盤控制、常見問題、篩選器與下載目標（視情況而定）。將審查螢幕截圖儲存在 public/ 之外。當顏色由 SVG 表示時，請檢查其路徑或螢幕截圖像素以及計算後的 CSS。
GitHub 發布與機器存取
在 SWI 機器上，AceCut 是使用 Linux 使用者 ubuntu（GitHub 身份 CC-AIMI）下現有的 GitHub CLI 登入來推送的。在依賴此先例之前，請使用 gh repo view <owner>/<repo> --json viewerPermission,defaultBranchRef,isEmpty 確認當前身份與儲存庫寫入權限。網路/代理錯誤並非無效登入的證據。如果 Git 在 gh 登入正常運作的情況下仍要求輸入使用者名稱，請在相同已驗證的 Linux 帳戶中使用每個指令的憑證輔助程式：git -c credential.helper='!gh auth git-credential' push origin <branch>。這會重複使用現有登入，而不會暴露其 token 或變更全域 Git 配置。請勿在帳戶之間複製憑證，或將密碼/token 放入此技能、shell 參數、原始碼檔案或日誌中。
當使用者授權一個管理員帳戶來解決 Unix 權限問題時，請檢查 id 與 getfacl，並僅授予所需的專案存取權限（例如 setfacl -m u:<executor>:rwx,d:u:<executor>:rwx <project>）。保留擁有者/群組與不相關的權限。管理員登入無法驗證 Vercel 或 GoDaddy。
如果明確要求的儲存庫已存在，請先複製它並保留其歷史記錄；請勿強制推送不相關的初始提交。將網站檔案放在儲存庫根目錄，而不是另一層 website/。在傳輸準備好的原始碼時，排除 .git、.vercel、dist、node_modules、驗證螢幕截圖與機密。如果透過另一個授權的 Linux 帳戶發布，請使用該帳戶擁有的暫存 checkout，並僅授予原始碼所需的讀取權限。在本機配置儲存庫的預期作者，檢查暫存檔案，提交，推送到預期分支，並驗證遠端 SHA。之後保持主要工作 checkout 同步。
對於獨立儲存庫，例如 diifan/golfcut-website，Vercel 必須匯入該儲存庫，並將根目錄設為 ./。僅 GitHub 推送並不會建立 Vercel 專案。
Vercel 與 DNS
Starter 使用架構 null（儀表板：Other）、bun install、bun run build、輸出目錄 dist、cleanUrls: true、trailingSlash: false。在獨立網站儲存庫中，將 Vercel 根目錄設為 ./；在應用程式 monorepo 中，使用 website/。如果已驗證的 Vercel CLI/API 可以直接部署，則 GitHub 整合為非必要。遵循使用者的授權發布範圍，無需添加另一個核准關卡。
在建立或連結之前，檢查已驗證的帳戶/團隊與現有專案。如果需要 CLI 登入，請執行 bun x vercel login 並將當前設備授權 URL 傳送給使用者；在完成獨立工作時保持程序存活。即使缺少 bunx shim，bun x 也能運作。在 CLI 確認之前，絕不能聲稱登入成功。登入後，檢查可用的團隊與 AceCut 的專案，選擇相同預期的範圍，建立/連結新的應用程式專案，連接其精確的 GitHub 儲存庫，然後部署。如果連接的 Vercel 外掛程式能提供這些功能，則優先使用。請勿重複使用已過期的設備代碼或假設建議的外掛程式已連接。絕不重複使用另一個應用程式的專案 ID。部署已建置的網站，並驗證其回傳的部署 URL。對於要求的 app.goswie.com，將該確切網域新增到其 Vercel 專案，然後取得專案當前的 DNS 建議。在授權的 DNS 提供商（AceCut 文件記錄為 GoDaddy）上，僅建立/更新要求的應用程式記錄，通常是 CNAME 主機 app。使用 Vercel 回傳的目標，而非猜測或複製的 AceCut 目標。保留不相關的記錄，特別是 @、www、MX 與 nameserver。在取代現有不相關的記錄之前，先解決所有權/衝突問題。僅在 Vercel 要求時，新增要求的驗證 TXT 記錄。
驗證公共 DNS、Vercel 網域狀態、HTTPS 與已部署的頁面。如果缺少憑證，請完成建置並記錄確切的剩餘帳戶操作；區分已準備的配置、已完成的部署與已驗證的網域。絕不能將計畫中的網域標記為已上線。
當前官方參考資料（進行部署工作時請查閱）：
已驗證的 CLI 順序
GolfCut 是使用 Vercel CLI 65.4.0 部署的。在已驗證的登入之後，如果旗標不同，請使用當前的 --help。替換已驗證的範圍、專案與儲存庫；用於 AceCut 與 GolfCut 的實際 SWI 範圍是 diifans-projects。
bun x vercel teams list
bun x vercel project list --scope <scope>
bun x vercel project create <project> --scope <scope>
bun x vercel link --yes --project <project> --scope <scope>
bun x vercel git connect --yes --scope <scope>
bun x vercel project update <project> --framework other --build-command 'bun run build' --install-command 'bun install' --output-directory dist --yes --scope <scope>
bun x vercel --prod --yes --scope <scope>
bun x vercel domains add <app-domain> <project> --scope <scope>
bun x vercel domains verify <app-domain> --scope <scope>
從具有正確 Git 遠端的網站 checkout 執行這些指令。當匹配的專案已存在時，跳過建立步驟。git connect --yes 使用該遠端；不使用 --yes 時，代理模式 CLI 可能會在確認提示處退出，而不實際連接。link 可能會建立包含 OIDC token 的 .env.local 與 .vercel/；將兩者都保留在忽略清單中。絕不列印或提交它們。
立即傳送新產生的設備登入 URL，保留登入程序，並等待其明確成功。如果使用者回報無效/過期的代碼，請停止舊的登入，發起一個新的登入，並保持輪次處於待授權狀態；請勿持續回傳過時的 URL。
READY 部署與自訂網域別名並不能證明公共 DNS 運作正常。同時測試公開的 <project>.vercel.app URL（無需驗證）以及要求的網域。domains verify 會回傳精確建議的 CNAME；如果使用者管理 DNS，請為他們記錄該值。在 DNS 待處理期間，保留公開預覽可用。當 Git 連接後，後續的推送應觸發部署；如果聲稱某個特定的新提交已上線，請驗證部署狀態。
交接
在網站 README 中記錄原始碼來源、指令、建置輸出、驗證證據與剩餘的限制。將產生的輸出、本機驗證成果、環境檔案與提供商憑證保留在 Git 之外。僅在成功部署後報告實際的線上 URL；否則提供已準備好的專案與精確的阻礙因素。