FReptar0/design-guard

为使用 Google Stitch 的 Web 项目生成一份完整的 DESIGN.md。

说明

0. 发现检查（必须优先执行）：
   • 检查 .dg-research/ 目录是否存在并包含 JSON 文件。
   • 如果 .dg-research/ 不存在，并且用户提到了特定的企业名称、公司、品牌、咖啡馆、餐厅、商店或现实世界中的实体：
     • 停止运行。告诉用户：“我建议先运行 /dg-discover 来研究 [企业名称]。这样生成的 DESIGN.md 将基于真实的市场和竞品数据，而非 AI 默认值。您希望我先运行 /dg-discover 吗？”
     • 只有当用户明确表示要跳过研究时，才继续执行 /dg-design。
   • 如果 .dg-research/ 存在并包含 JSON 文件：读取 .dg-research/latest.json 以获取业务简介、竞品分析和品牌颜色。这些研究数据是关于业务背景的首选来源——应优先于项目级别的任何背景（来自 CLAUDE.md）。然后继续执行步骤 1。
   • 如果用户的请求是通用的（未提具体企业，例如“创建一个作品集网站”或“创建一个 SaaS 仪表盘”）：直接跳到步骤 1。研究仅适用于真实企业，不用于通用项目。

上下文隔离（关键——生成前阅读）

生成 DESIGN.md 时，请区分两种上下文：

1. 宿主项目——您当前在其内运行的代码库（Design Guard）。CLAUDE.md 描述的是当前项目。它的业务模式、功能、CLI 命令、测试计数和技术架构均属于 Design Guard，与用户的目标业务无关。

2. 目标业务——用户需要为其生成 DESIGN.md 的业务。此上下文来自：

   • 用户提供的品牌简介（步骤 1）
   • .dg-research/latest.json 中的研究数据（如果有来自 /dg-discover 的数据——这是首选来源）
   • 关于目标业务的 WebSearch/WebFetch 结果

规则：

• 如果目标业务不同于 Design Guard：

  • 不要使用 CLAUDE.md 中的业务描述、功能列表、统计数据或技术细节
  • 不要将 CLI 命令、测试计数、TypeScript、Node.js、MCP 或 Stitch 作为目标业务的特性提及
  • 不要将目标描述为“开源”、“设计智能”或 CLAUDE.md 项目概览中的任何短语
  • DESIGN.md 中的每个业务事实都必须来自用户简介或研究数据
  • 如果项目根目录已存在 DESIGN.md，不得将其颜色、字体或业务上下文复制到新文件中——需要根据简介和研究数据全新生成

• 如果目标业务就是 Design Guard 本身：

  • 可将 CLAUDE.md 作为有效的业务上下文来源，与用户简介结合使用

• 无论目标业务是什么，都必须始终遵循 CLAUDE.md 中 DESIGN.md 的 8 节规范和验证规则。格式规则始终适用；需要隔离的仅仅是业务上下文。

1. 如果用户提供了品牌简介作为参数，则直接使用。否则，询问以下信息：

   • 公司/产品名称
   • 行业或领域
   • 目标受众
   • 美学方向（例如“高端企业”、“趣味初创”、“极简 SaaS”）

2. 生成一份包含以下 8 个部分的 DESIGN.md：

   1. 视觉主题与氛围——2-3 句富有感染力的句子，描述整体美学风格。使用具体的形容词和参考，避免泛泛而谈。
   2. 色彩调色板与角色——Markdown 表格，列名为：角色、名称、十六进制色值、用途。至少包含 5 个角色（主色、辅助色、表面色、表面上的文本色、错误色）。所有颜色均使用十六进制值，不要使用“可信的蓝色”这类描述。为每种颜色指定一个描述性名称（例如“深海军蓝”，而不仅仅是“主色”）。
   3. 排版——从 Google Fonts 中选择字体（避免将 Inter 或 Poppins 设为主要字体——它们会暴露 AI 生成的设计）。尺寸使用 rem/px，字重使用数字（400/600/700），行高。包含标题、正文和等宽字体。使用衬线/无衬线字体的组合来形成对比。
   4. 间距与布局——基本单位（例如 4px）、缩放比例、最大内容宽度、网格系统、断点。
   5. 组件模式——至少 3 个组件（按钮、卡片、输入框等），包含结构和样式规则。变化 border-radius 和阴影样式。
   6. 图标——样式（线框/实心/双色）、默认尺寸、来源库。
   7. 图像指南——照片风格、插图风格、宽高比。具体说明图像所传达的信息。
   8. 应做与不应做——至少各 3 条。必须包含以下反模式默认规则：

   应做

   • 至少在一个功能区使用非对称或非标准布局
   • 卡片大小和间距要有变化，以营造视觉节奏
   • 严格使用指定的色彩调色板（不使用 AI 选定的颜色）
   • 所有文本保持高对比度（最低 4.5:1）
   • 变化节背景（在浅色/深色表面之间交替）

   不应做

   • 不要将 Inter、Poppins 或系统无衬线字体作为主要字体
   • 不要在任何地方使用紫蓝色渐变
   • 不要在所有元素上使用统一的 border-radius（大于 12px）
   • 不要在页面第二部分使用标准的三列图标网格
   • 不要将超过 2 行的正文文本居中
   • 不要使用通用的库存照片插图（3D 斑点、抽象形状）

3. 验证规则：

   • 所有颜色必须为十六进制值（#RRGGBB）
   • 字体尺寸仅限 rem 或 px
   • 至少 5 个颜色角色、3 个组件模式、3 条应做和 3 条不应做
   • 总长度保持在约 3000 tokens 以内（Stitch 在每次生成时将其作为上下文读取）

4. 如果 DESIGN.md 已存在，在覆盖前需询问用户。

5. 将文件写入项目根目录下的 DESIGN.md。

6. 写入完成后，使用 mcp__stitch__list_design_systems 检查是否存在 Stitch 设计系统。如果用户已有 Stitch 项目：

   • 提供使用 mcp__stitch__create_design_system 创建设计系统的选项
   • 或者使用 mcp__stitch__update_design_system 更新现有系统
   • 使用 mcp__stitch__apply_design_system 将其应用到项目，以便所有未来的生成都能遵循该系统

7. 下一步：建议运行 /dg-generate，使用新的设计系统创建第一个屏幕。

参考：有关完整规范，请参见 docs/design-md-guide.md。