Use Rustify Docs

用 Rustify Docs 交付可阅读、可部署的静态站点。文档站让读者找到答案并完成操作；Landing Page 让目标客户第一眼理解价值、愿意继续了解并采取行动。

实现与设计边界

• 面向站点作者，在用户的目标项目工作；不要求克隆或修改 Rustify UI 仓库。默认采用静态 HTML/CSS 的 DOM 路径，纯内容站不编译站点 Rust、不加载 wasm，也不需要 Node、Tailwind CLI 或 Makepad。只有具体的交互组件或 demo 需求才选 components 模板与 DOM islands；不预建 GPU 路径。
• 保留用户的产品事实、品牌、已有设计和技术选择。普通创建、局部修改不扩成框架开发、整站迁移、后端、统计服务或发布。仅咨询时只读。
• 实际调用 phoenix-ui 做设计：从当前技能目录找到并读取其 SKILL.md，按其流程执行；文档面选择 Read，营销落地页选择 Persuade。Rustify 自身的 Theme Studio 外观不约束客户站点。
• Landing Page 必须实际调用 ui-loop：读取当前可用的 ui-loop/SKILL.md 并执行其流程，不能用本文件的检查表代替调用。phoenix-ui 负责设计方向与实现；落地页按用户要求接续 ui-loop，不以通用自检轮数上限跳过所需迭代。
• 找不到上述依赖时先说明缺少哪个 skill、影响哪个阶段及如何补齐；继续可独立完成的内容与构建，不擅自安装、不声称已调用，缺少 ui-loop 时不能宣布 Landing Page 设计验收完成。

确定站点与入口

1. 读目标项目的 AGENTS、README、PRODUCT、DESIGN、工具链配置及相关计划，核对工作树和现有站点。确定工作目录、文档站 / Landing Page / 两者组合、受众、语言、品牌素材、部署 base，以及本次主要行动的真实目标。
2. 文档站确认读者要完成的任务与现有内容；Landing Page 确认卖给谁、解决什么问题、有什么可用证据、希望客户下一步做什么。可从材料查明的先查；会改变价值主张或 CTA 的缺项才询问，先推进不依赖答案的工作。不得虚构客户、评价、数据或产品能力。
3. 创建或配置前读 Rustify Docs 作者契约，核对实际 CLI 的 --version、--build-info 和 --help。复用现有版本和项目入口；安装、组件配对、主题、落地页配置按该参考执行，不猜不存在的参数或配置键。
4. 现有站点只改对应源文件、配置与资源；新站用 rustify-docs new 创建到新目录或空目录。先说明内容 / components 选择及依据，再落地最小完整路径。