设计产品营销网站
创建一个网站，其内容、视觉选择和交互来解释这个特定产品。支持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 片段 或 阿拉伯语片段。对于已批准的产品更改，检查影响范围，并在授权仓库工作中更新受影响的网站内容、导航、元数据、结构化数据和测试。准确标记已计划和已交付的功能；已实现的功能不会自动向每个访客发布。
如果产品事实、商业条款或外部依赖项未解决，请标记该决策，而不是默默编造。如果网站位于别处，请确定确切需要跟进的事项，而不是声称它已更改。保持仓库编辑与部署和公开发布之间的区别。