应用网站
将用户提供的设计交付为独立的静态网站，附带可重现的 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
捆绑的启动器包含经过验证的构建/预览脚本和 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 或静默替换其他应用的法律条款。
将规范 URL、Open Graph、JSON-LD、robots 和 site map 中的原型源替换为预期的生产环境源。一致地保留页面路径。对于按钮颜色请求，检查渲染的资产以及 CSS：填充的 SVG 可能隐藏了 CSS 背景。仅更改预期的 SVG 背景路径，并保留徽标/文字路径、可访问名称和链接目标。
公司页脚和法律页面
对于应与 AceCut 对齐的 SWINK 应用网站，请使用 © <year> SWINK AI INC.、可见的 mailto:[email protected] 联系链接以及每个页面（包括功能页面和法律页面本身）上有效的 /terms 和 /privacy 链接。保持当前应用的品牌和视觉风格。使用相对于根路径的资产和导航，以便嵌套路由正常工作；确保法律链接无需 JavaScript 即可访问。让页脚链接在平板电脑上可换行，并在移动设备上使用紧凑布局，避免水平溢出。
当用户请求对齐时，使用被引用应用的条款/隐私结构和确认的公司/联系详情，然后调整应用名称、实际特性、日期、规范 URL 和交叉链接。不要盲目转移其他应用的分析提供商、上传行为、存储/保留承诺或设置。检查可用的产品证据以验证此类声明；对未经确认的细节予以省略，而非捏造。保持条款和隐私作为可读的独立页面，将两者都添加到站点地图中，并在本地工具和 Vercel 中验证干净的 URL。
对于页脚/法律更改，检查所有受影响的页面在桌面、平板和窄手机宽度下的显示；验证公司文本、mailto 目标、两个法律链接、可读文本、无溢出以及移动导航。保留请求的下载按钮颜色。推送后，验证新的生产部署并通过 HTTPS 获取实际的 /terms 和 /privacy 页面，然后才能报告它们已上线。
构建并验证
bun run build
bun run preview
本地服务器支持目录索引路由和 .html 干净 URL、GET 和 HEAD 方法，并为缺失文件返回 404。通过 HTTP 验证每个页面和本地资产；确认站点地图和规范 URL。检查桌面和窄手机宽度（例如 1440、768、390 和 320 像素）、溢出、加载的图像、浏览器错误、菜单、制表符/键盘控制、常见问题解答、过滤器和下载目标（如适用）。在 public/ 外部捕获审查截图。当颜色由 SVG 表示时，检查其路径或截图像素以及计算出的 CSS。
GitHub 发布和机器访问
在 SWI 机器上，AceCut 是使用现有 GitHub CLI 登录（Linux 用户 ubuntu，GitHub 身份 CC-AIMI）推送的。使用 gh repo view <owner>/<repo> --json viewerPermission,defaultBranchRef,isEmpty 确认当前身份和仓库写入权限，然后才能依赖此先例。网络/代理错误不是无效登录的证据。如果 Git 在 gh 登录正常工作的情况下仍然要求用户名，请在该已认证的 Linux 帐户中使用单命令凭据辅助程序：git -c credential.helper='!gh auth git-credential' push origin <branch>。这重用了现有登录，不会暴露其令牌或更改全局 Git 配置。不要在不同帐户之间复制凭据，也不要在本技能、shell 参数、源文件或日志中包含密码/令牌。
当用户授权管理员帐户解决 Unix 权限问题时，检查 id 和 getfacl，仅授予所需的项目访问权限（例如 setfacl -m u:<executor>:rwx,d:u:<executor>:rwx <project>）。保留所有者/组和无关权限。管理员登录不会对 Vercel 或 GoDaddy 进行身份验证。
如果明确请求的仓库已存在，请先克隆它并保留其历史记录；不要强制推送无关的初始提交。将网站文件放在仓库根目录，而不是另一个 website/ 层中。在传输准备好的源代码时，排除 .git、.vercel、dist、node_modules、验证截图和机密信息。如果通过另一个授权的 Linux 帐户发布，请使用该帐户拥有的临时检出，并仅授予对源代码所需的读取权限。在本地配置仓库的预期作者，检查暂存文件，提交，推送到预期分支，并验证远程 SHA。之后保持主工作检出同步。
对于独立仓库（例如 diifan/golfcut-website），Vercel 必须使用根目录 ./ 导入该仓库。仅仅推送 GitHub 不会自动创建 Vercel 项目。
Vercel 和 DNS
启动器使用框架 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 和名称服务器。在替换现有无关记录之前，解决所有权/冲突问题。仅在 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 远程的网站检出目录运行这些命令。当匹配的项目已存在时，跳过创建步骤。git connect --yes 使用该远程；如果没有 --yes，代理模式 CLI 可能在确认提示处退出而实际未连接。link 可能创建包含 OIDC 令牌的 .env.local 和 .vercel/；将两者都保持忽略状态。切勿打印或提交它们。
立即发送新生成的设备登录 URL，保留登录进程，并等待其明确成功。如果用户报告代码无效/已过期，请停止旧的登录，发出新的登录并保持轮次处于有效状态以进行授权；不要一直返回过期的 URL。
READY 部署和自定义域名别名并不证明公共 DNS 有效。测试公共 <project>.vercel.app URL（无需身份验证）以及请求的域名。domains verify 返回确切推荐的 CNAME；如果用户管理 DNS，则记录该值。在 DNS 待定时保持公共预览可用。当 Git 已连接时，后续推送应触发部署；如果声称特定新提交已上线，请验证部署状态。
交接
在网站 README 中记录源来源、命令、构建输出、验证证据和剩余限制。将生成的输出、本地验证工件、环境文件和提供商凭据保留在 Git 之外。仅在成功部署后报告实际的上线 URL；否则提供就绪的项目和确切的阻塞点。